Отношения
В UML используются четыре основных типа отношений:
зависимость (dependency);
ассоциация (association);
обобщение (generalization);
реализация (realization)
Зависимость
Зависимость — это наиболее общий тип отношения между двумя сущностями. Отношение зависимости указывает на то, что изменение независимой сущности каким-то образом влияет на зависимую сущность. В случае классов зависимости появляются по разным причинам: один класс посылает сообщение другому классу; один класс владеет другим классом как частью своих данных; один класс использует другой класс в качестве параметра операции.
Графически отношение зависимости изображается в виде пунктирной линии со стрелкой, направленной от зависимой сущности к независимой (например, как на рис. 3). Как правило, семантика конкретной зависимости уточняется в модели с помощью дополнительной информации. Например, зависимость со стереотипом «use» означает, что зависимая сущность использует (скажем, вызывает операцию) независимую сущность.
Рис.3. Пример зависимости
Ассоциация
Ассоциация — это наиболее часто используемый тип отношения между сущностями.
Отношение ассоциацииимеет место, если одна сущность непосредственно связана с другой (или с другими — ассоциация может быть не только бинарной).
Ассоциация - это другая ипостась свойства. Значительная часть информации, которую можно указать в атрибуте, появляется в ассоциации. На рис. 4 и 5 показаны одни и те же свойства, представленные в различных обозначениях.
Рис. 4. Представление свойств заказа в виде атрибутов
Графически ассоциация изображается в виде сплошной непрерывной линии между двумя классами, направленная от исходного класса к целевому классу. Имя свойства (вместе с кратностью) располагается на целевом конце ассоциации. Целевой конец ассоциации указывает на класс, который является типом свойства. Большая часть информации в обоих представлениях одинакова,но некоторые элементы отличаются друг от друга. В частности, ассоциация может показывать кратность на обоих концах линии.
Рис. 5. Представление свойств заказа в виде ассоциаций
Естественно, возникает вопрос: «Когда следует выбирать то или иное представление свойств?». Как правило, небольшие элементы, такие как даты или логические значения, – главным образом, типы значений, обозначаются при помощи атрибутов, а ассоциации обозначают более значимые классы, такие как клиенты или заказы. Предпочтительно также использовать прямоугольники классов для наиболее значимых классов диаграммы, а ассоциации и атрибуты для менее важных элементов.
Двунаправленные ассоциации
Двунаправленная ассоциация, показанная на рис. 6, – это пара свойств, связанных в противоположных направлениях. Класс Car (Автомобиль) имеет свойство owner:Person[1], а класс Person (Личность) имеет свойство cars:Car[*]. (Обратите внимание, что использована множественная форма имени свойства cars по причине того, что у свойства кратность больше 1.)
Рис. 6. Двунаправленная ассоциация
Агрегация и композиция
Простая ассоциация между двумя классами отражает структурное отношение между равноправными сущностями, когда оба класса находятся на одном концептуальном уровне и ни один не является более важным, чем другой. Но иногда приходится моделировать отношение типа "часть/целое", в котором один из классов имеет более высокий ранг (целое) и состоит из нескольких меньших по рангу (частей). К примеру, можно сказать, что двигатель и колеса представляют собой части автомобиля.Отношение такого типа называют агрегированием (aggregation); оно причислено к отношениям типа "имеет" (с учетом того, что объект-целое имеет несколько объектов-частей). Агрегирование является частным случаем ассоциации и изображается в виде простой ассоциации с незакрашенным ромбом со стороны "целого" (рис. 7).
Наряду с агрегацией в языке UML есть более определенное свойство – композиция(composition). Композиция — более строгий вариант агрегации. Композиция имеет жёсткую зависимость времени существования экземпляров класса-контейнера и экземпляров содержащихся классов. Если контейнер будет уничтожен, то всё его содержимое будет также уничтожено. Графически представляется так же, как и агрегация, но с закрашенным ромбиком.
На рис. 8 экземпляр класса Point (Точка) может быть частью многоугольника, а может представлять центр окружности, но он не может быть и тем и другим одновременно. Главное правило состоит в том, что хотя класс может быть частью нескольких других классов, но любой экземпляр может принадлежать только одному владельцу. На диаграмме классов можно показать несколько классов потенциальных владельцев, но у любого экземпляра класса есть только один объект-владелец.
Можно заметить, что на рис. 8 не показаны обратные кратности. В большинстве случаев, как и здесь, они равны 0..1. Единственной альтернативой является значение 1, когда класс-компонент разработан таким образом, что у него только один класс-владелец.
Правило «нет совместного владения» является ключевым в композиции. Другое допущение состоит в том, что если удаляется многоугольник (Polygon), то автоматически должны удалиться все точки (Points), которыми он владеет.
Рис. 7. Агрегация
Рис. 8. Композиция