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

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

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

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

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

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

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

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

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

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

Рис. 4.8. Пример композиции

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

1. Наследование является только отношением между классами и не переходит в отношение между экземплярами классов, в отличие от агрегирования. Объект, порожденный от класса-наследника, содержит в себе объект класса-предка, но никаких отношений между ними нет – второй есть несамостоятельная часть первого^{1Вместе с тем у класса-предка могут быть отдельные экземпляры (если он, конечно, не является абстрактным), и эти экземпляры могут взаимодействовать с экземплярами класса-предка. В этом случае между классом-предком и классом-потомком надо рисовать отдельную ассоциацию, а отношение наследования между ними не имеет никакого касательства к этому взаимодействию.}.
2. Наследование модифицирует класс-предок, непосредственно добавляя, "вливая" в него новые свойства (атрибуты, методы, реализацию методов). Агрегирование никак не затрагивает агрегат, и у последнего могут быть свои собственные методы и атрибуты. В случае агрегирования части не "растворяются" в целом, оставаясь отдельными частями в его составе.