Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Старое ПППП / Лабораторная работа №1. UML / Лабораторная работа №1. UML.docx
Скачиваний:
41
Добавлен:
17.04.2018
Размер:
678.96 Кб
Скачать

Отношения

В UML используются четыре основных типа отношений:

  1. зависимость (dependency);

  2. ассоциация (association);

  3. обобщение (generalization);

  4. реализация (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. Композиция