Санкт-Петербургский государственный университет
Опубликован: 04.12.2007 | Доступ: свободный | Студентов: 2738 / 336 | Оценка: 4.30 / 3.65 | Длительность: 16:28:00
ISBN: 978-5-94774-823-9
Лекция 4:

Введение в UML 2.0, часть II

< Лекция 3 || Лекция 4: 12345 || Лекция 5 >

N-арные ассоциации и класс-ассоциации

В этом курсе рассматриваются в основном бинарные ассоциации (binary association) - то есть те, которые связывают два класса. Выше были рассмотрены также рефлексивные ассоциации. Вместе с тем в UML возможны n-арные ассоциации (n-ary associations), которые связывают между собой несколько классов. Например, ассоциация под названием "Семья" может связывать следующие классы: "Муж", "Жена", "Ребенок", как показано на рис. 4.6.

Пример N-арной ассоциации

Рис. 4.6. Пример N-арной ассоциации

В этом примере муж и жена должны присутствовать в семье обязательно (значение множественности у соответствующего конца ассоциации "Cемья" равно 1 ), а детей может быть произвольное количество, в том числе и не быть вовсе (значение множественности у соответствующего конца ассоциации равно 0..* ).

Ассоциация не может иметь атрибутов, но во многих случаях это крайне желательно. Например, если студент связан ассоциацией "многие-ко-многим" с курсом, то этой ассоциации целесообразно иметь атрибут под названием "оценка". Это достигается связыванием с ассоциацией специального класса - класса-ассоциации (association class), в котором и указываются все нужные атрибуты, как показано на рис. 4.7.

Пример класса-ассоциации

Рис. 4.7. Пример класса-ассоциации

Агрегирование

У конца ассоциации может быть одно важное свойство под названием агрегирование (aggregation), которое обозначает наличие связи "целое/часть" (part of) между экземплярами классов. Объект-часть в той или иной форме включается в объект-целое. Так, например, на рис. 4.1 показано, что объекты класса COperator входят в объект класса COperatorList (то есть первый класс агрегируется вторым). Таким образом, агрегирование, как частный случай ассоциации, также обязательно переходит в связи между экземплярами классов.

С помощью агрегирования, например, нельзя определить nested-класс в Java-приложении. Подобный недостаток выразительных средств UML (в частности, для Java) является предметом обширной дискуссии и приводит к созданию диалектов UML, которые являются менее общими, но точнее отражают нужды конкретных платформ реализации. Эти специализации можно создавать, используя встроенные в UML средства - механизм профайлов и extention-механизм. А можно создавать свой собственный визуальный язык и реализовать его, пользуясь DSM-средствами, которых сейчас много - например, Microsoft DSL Tools или Eclipse/GMF. Подробнее об этом будет рассказано в следующих лекциях.

Агрегирование может быть "слабым", как в примере на рис. 4.1, и "сильным". В последнем случае оно называется композицией (composition) и означает, что объект-агрегат несет полную ответственность за создание и удаление, а также существование объектов, которые связаны с ним композицией, а также один объект в каждый момент своего существования может одновременно быть частью только одного агрегата. Если в примере с классами COperator и COperatorList последний строго контролирует доступ к каждому оператору из своего списка (создание, удаление, обращение к оператору по номеру в списке и пр.), то можно обозначить связывающую их ассоциацию агрегирования как композицию:

Пример композиции

Рис. 4.8. Пример композиции
Семантика агрегирования и композиции не определена строго в UML. Отношение "целое-часть" - вот что можно считать определением агрегирования. Ведь на практике существует множество самых разных вариантов такой семантики. Например, "отец" всегда создает и удаляет свои части сам, или только создает, а удалять могут и другие. "Отец" может также поддерживать целостность и корректность своих частей, а может и не заниматься этим. При удалении "отца" "дети" могут удаляться, а могут и нет. "Отец" может брать на себя все взаимодействие своих частей с внешним контекстом (так, что это внешний контекст даже не "видит" его частей) и т. д.

Агрегирование принципиально отличается от наследования. Это важно, поскольку при моделировании предметной области с помощью диаграмм классов UML можно заметить их определенное сходство: (i) оба позволяют строить древообразную иерархию классов; (ii) предок, также как и агрегируемый класс, добавляет функциональности в потомок/агрегат; (iii) изображения обоих отношений чем-то похожи визуально. И мне как-то раз пришлось в непростом диалоге убеждать аналитиков, что наследование и агрегирование - это не одно и то же. И вот почему.

  1. Наследование является только отношением между классами и не переходит в отношение между экземплярами классов, в отличие от агрегирования. Объект, порожденный от класса-наследника, содержит в себе объект класса-предка, но никаких отношений между ними нет – второй есть несамостоятельная часть первого1Вместе с тем у класса-предка могут быть отдельные экземпляры (если он, конечно, не является абстрактным), и эти экземпляры могут взаимодействовать с экземплярами класса-предка. В этом случае между классом-предком и классом-потомком надо рисовать отдельную ассоциацию, а отношение наследования между ними не имеет никакого касательства к этому взаимодействию..
  2. Наследование модифицирует класс-предок, непосредственно добавляя, "вливая" в него новые свойства (атрибуты, методы, реализацию методов). Агрегирование никак не затрагивает агрегат, и у последнего могут быть свои собственные методы и атрибуты. В случае агрегирования части не "растворяются" в целом, оставаясь отдельными частями в его составе.
< Лекция 3 || Лекция 4: 12345 || Лекция 5 >
Ольга Зырянова
Ольга Зырянова

Здравствуйте, не могу найти ссылку на скачивание курса  «Визуальное моделирование: теория и практика»

 

Номер платежа 6400454020565

Анна Митюрёва
Анна Митюрёва

http://www.intuit.ru/studies/courses/1041/218/info

С мобильного приложения доступ есть, а через сайт не отображается. Печально =(