Отношения

В языке UML определены четыре типа отношений:

• зависимость;
• ассоциация;
• обобщение;
• реализация.

Эти отношения являются основными связующими строительными блоками в UML и применяются для создания корректных моделей.

Зависимость (Dependency) - это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой. Графически зависимость изображается в виде прямой пунктирной линии, часто со стрелкой, которая может содержать метку.

Самым распространенным видом отношения зависимости является соединение между классами, когда один класс использует другой в качестве параметра операции. Для моделирования такого отношения изображается зависимость, направленная от класса с операцией к классу, используемому в качестве ее параметра.

Например, в системе, управляющей распределением студентов и преподавателей на курсах обучения, используются классы Schedule (Расписание занятий) и Course (Курс). Между классами существует отношение зависимости, поскольку класс Course используется в операциях add и remove класса Schedule. Таким образом, зависимость должна быть направлена от класса Schedule к классу Course.

Рекомендуется применять зависимости, если требуется показать, что одна сущность использует другую.

Для большинства отношений вполне достаточно обычной зависимости без каких-либо дополнений. Но если необходимо передать некий смысловой нюанс, то стоит учесть, что в UML определен целый ряд стереотипов, применимых к зависимостям [1].

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

Разновидностью ассоциации является агрегирование (Aggregation) - структурное отношение между целым и его частями.

Агрегирование является простой концепцией с достаточно глубокой семантикой. Простое агрегирование представляет собой чисто концептуальное отношение, только позволяющее отличить "целое" от "части", в частности, агрегирование не изменяет смысла навигации по ассоциации между целым и его частями и не накладывает никаких ограничений на соотношение времен жизни целого и частей.

Существует вариация простого агрегирования, называемой композиция, которая добавляет к семантике агрегирования новые важные особенности. Композицией называется форма агрегирования с четко выраженным отношением владения, причем время жизни частей и целого совпадают. Части с нефиксированной кратностью могут быть созданы уже после самого композита, но, будучи созданы, живут и умирают вместе с ним. Впрочем, части могут быть удалены явным образом еще до уничтожения композита.

Это означает, что в случае композитного агрегирования объект в любой момент времени может быть частью только одного композита. Например, в оконной системе класс Frame (Рама) принадлежит только одному классу Window (Окно), тогда как при простом агрегировании "часть" может принадлежать одновременно нескольким "целым". К примеру, в модели дома объект Wall(Стена) может принадлежать нескольким объектам Room (Комната).

Кроме того, в композитном агрегировании целое отвечает за диспозицию своих частей, то есть композит должен управлять их созданием и уничтожением. Например, создав объект Frame в системе окон, вы должны присоединить его к объемлющему окну. Когда объект Window удаляется, он в свою очередь должен уничтожить принадлежащие ему объекты Frame.

Например, в модели информационной системы вуза можно выделить классы University (Вуз), Student (Студент), Department (Факультет), Course (Курс) и Instructor (Преподаватель) (см. рис 2.7).

Между классами Student и Course существует ассоциация, показывающая, что студенты посещают курсы. Каждый студент может посещать любое число курсов, и на каждый курс может приходить любое количество студентов.

Аналогичным образом между классами Course и Instructor определена ассоциация, показывающая, что преподаватель читает курс. Для каждого курса должен быть хотя бы один преподаватель, и каждый преподаватель может вести любое количество курсов (в том числе и ни одного).

Графически ассоциация изображается в виде линии, соединяющей класс сам с собой или с другими классами.

Отношения между классом University и классами Student и Department отличаются друг от друга, хотя оба являются отношениями агрегирования.

В вузе может быть любое количество студентов, и каждый студент может обучаться в одном или нескольких вузах, вуз может состоять из одного или нескольких факультетов, но каждый факультет относится исключительно к одному вузу.

Отношение между классами University и Department называют композицией. В принципе можно было бы обойтись без отношений агрегирования и использовать простые ассоциации, но определяя при этом University как целое, а Student и Department как его части, показывается какой из классов организационно стоит выше остальных. Так, вузы в какой-то степени определяются своими студентами и факультетами. В то же время студенты и факультеты вообще не могут существовать вне связи со своим вузом, и в какой-то мере он формирует их статус (так, юноша, не учащийся в вузе, лишается права именоваться студентом и может стать объектом класса Warrior).

Рис. 2.7 Виды ассоциаций

Как показано на рис. 2.7, композиция является просто частным случаем ассоциации и обозначается путем дополнения ассоциации закрашенным ромбом на конце со стороны "целого".

Обобщение (Generalization) - это отношение "специализация/обобщение", при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка). Таким образом, потомок наследует структуру и поведение своего родителя.

В моделировании системы часто приходится работать с классами, похожими на другие по структуре и поведению. В принципе их можно моделировать как различные, независимые друг от друга абстракции. Но лучше выделить одинаковые свойства и сформировать на их основе общие классы, которым наследуют специализированные.

Моделирование отношений наследования осуществляется в следующем порядке:

1. Найти атрибуты, операции и обязанности, общие для двух или более классов из данной совокупности.

2. Вынести эти элементы в некоторый общий класс, а при необходимости создать новый.

3. Назначить более специализированные классы потомками общих классов, проведя связь обобщения, направленное от каждого потомка к его родителю.

Графически отношение обобщения изображается в виде линии с не закрашенной треугольной стрелкой, указывающей на родителя.

Реализация (Realization) - это семантическое отношение между классификаторами, при котором один классификатор определяет соглашение ("контракт"), а другой гарантирует его выполнение.

Отношения реализации встречаются в двух случаях: во-первых, между интерфейсами и реализующими их классами или компонентами, а во-вторых, между прецедентами и реализующими их кооперациями.

Реализации настолько отличаются от зависимостей, обобщений и ассоциаций, что выделяются в отдельный тип отношений. Семантически реализация является нечто средним между обобщением и зависимостью, и нотация для нее несет в себе черты того и другого. Реализации употребляются в двух ситуациях: в контексте интерфейсов и в контексте коопераций.

Чаще всего реализации используют для определения отношений между интерфейсом и классом или компонентом, который предоставляет объявленные в интерфейсе операции или услуги (интерфейс является набором операций, которые применяются для специфицирования услуг, предоставляемых классом или компонентом). Таким образом, интерфейс определяет обязательства, которые должен выполнять компонент или класс. Один интерфейс может реализовываться несколькими классами или компонентами, а с другой стороны, класс или компонент может реализовывать несколько интерфейсов.

Самой главной особенностью интерфейсов является то, что они позволяют отделить спецификацию контракта (сам интерфейс) от их реализации (классом или компонентом). Кроме того, интерфейсы могут пересекать границу между логическими и физическими частями системной архитектуры. Например, класс для представления системы с точки зрения проектирования (AccountBusinessRules в системе ввода заказов) может осуществлять реализацию интерфейса (IRuleAgent). Однако тот же самый интерфейс может быть реализован и компонентом (файлом acctrule.dll) вида системы с точки зрения реализации.

Отношение реализации изображается в виде пунктирной линии с не закрашенной треугольной стрелкой, как нечто среднее между отношениями обобщения и зависимости.

Четыре описанных элемента являются основными типами отношений, которые можно включать в модели UML. Существуют также их вариации, например уточнение (Refinement), трассировка (Trace), включение и расширение (для зависимостей).