7. Отношения между классами в UML. Примеры.

 

            Классы могут находиться между собой в различных отношениях (связях). Базовыми отношениями являются:

·         отношения зависимости (dependency relationship);

·         отношения ассоциации (association relationship);

·         отношения обобщения (generalization relationship);

·         отношения реализации (realization relationship).

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

            В зависимость включаются все виды связей, кроме ассоциаций, обобщений и реализаций. Зависимость может иметь имя, но часто его не ставят, учитывая, что из контекста ясна семантика отношения. Зависимость изображается пунктирной строкой от клиента (зависимого класса) к поставщику (независимому классу) (рисунок 3). На рисунке 3 класс А вызывает операции классов В и С; класс С создаёт экземпляры класса В, пользуясь его конструктором; операция класса  D может иметь доступ в порядке исключения к содержимому класса В.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рисунок 3 – Зависимости между классами

 

Отношение ассоциации (ассоциация,  association) – описывает связи между экземплярами классов (объектами) - в отличие от зависимости, которая относится к классу в целом. В ассоциации проставляется множественность участия экземпляров в связи (один или много).

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

На рисунке 4 экземпляром отношения является, например, пара «Иванов – ООО «Ракурс»».

 

 

 

 

Рисунок 4 – Бинарная ассоциация

 

Важной характеристикой ассоциации является кратность (множественность и обязательность связи). Обозначение “*” обозначает “0. .*”, т.е. необязательность связи «много».

Важным частным случаем отношения ассоциации, выделяемым в отдельную группу, является отношение агрегации.

Отношение агрегации (агрегация, aggregation) (рисунок 5) – один из классов (агрегат) состоит из  других классов или его характеристиками являются другие классы (отношение часть/ целое, part of). Это отношение является фундаментальным при моделировании системы, позволяет декомпозировать систему на составные части. В агрегации принцип наследования не соблюдается. Каждая часть или характеристика обладает своими атрибутами и поведением. Агрегация в UML обозначается ромбом, примыкающим к агрегату.

 

 

 

 

 

 

 

 

 

 

Рисунок   5 -  Агрегат и его части

 

У полюсов связей может быть указана множественность. Любая часть может входить в несколько различных агрегатов.

Частным случаем агрегации является композиция.

Композиция (composition) – усиленная форма агрегации, в которой агрегат, называемый композитом, несёт полную ответственность за создание и уничтожение своих частей, т.е. самостоятельно классы -  части композита   существовать не могут. Таким образом, время жизни частей не превышает времени жизни агрегата – композита (она может быть меньше). Композиция обозначается закрашенным ромбом.

 

 

 

 

 

                                                         

 

 

 

 

Рисунок 6 – Отношение композиции

 

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

Отношение обобщения (обобщение, generalization) – обычное таксономическое отношение между родителем (предком) и частными примерами (дочерьми, детьми, сыновьями, потомками).

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

 

 

 

 

 

 

           

 

 

 

                      Рисунок 7   -  Пример обозначения обобщения

 

Обозначается оно прямой линией с треугольной незакрашенной стрелкой, направленной к обобщению (родителю). Многоточие означает, что все возможные потомки пока не перечислены и могут появиться другие потомки (свойство «неполный», incomplete). Отсутствие многоточия говорит о полном перечислении потомков (свойство «полный», complete).

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

Отношение реализации (реализация, realization) возникает между классами в том случае, когда один класс задает требования к поведению системы (функциональную спецификацию), а другой является полной или частичной программной или аппаратной реализацией этого поведения. Примерами классов, задающих спецификации поведения, являются варианты использования. Кроме того, в UML определены специальные классы - интерфейсы, предназначенные для отдельного перечисления множества видимых операций одного или совокупности других классов без указания деталей реализации. Поскольку одна и та же спецификация может быть реализована многими способами, а реализация может относиться к нескольким спецификациям, то множественность этой связи М:N («многие ко многим»).   Тот, кто реализует, называется клиентом, а носитель спецификации называется источником (поставщиком). Клиент не наследует операции источника, он их определяет вновь или наследует от своего предка, однако для полноты должны быть объявлены все операции источника.   Отношение реализации изображается пунктирной стрелкой с незакрашенным треугольным наконечником, идущей от реализации к спецификации (от клиента к поставщику). В реализацию могут быть добавлены дополнительные операции (по сравнению со спецификацией), если они способствуют выполнению основных операций.

 

Уточнения отношений

Уточнение имеет отношение к уровню детализации. Один пакет уточняет другой, если в нем содержатся те же самые элементы, но в более подробном представлении. Например, при написании книги вы наверняка начнете с формулировки предложения, в котором кратко букет представлено содержание каждой главы. Предположим, что резюме к каждой главе в качестве отдельного элемента входит в пакет «Предложение». Допустим также, что «Завершённая книга» — это пакет, элементами которого являются законченные главы. В этом контексте пакет «Завершённая книга» является уточнением пакета «Предложение».

Мощность отношений

Мощность отношения (мулитипликатор) означает число связей между каждым экземпляром класса (объектом) в начале линии с экземпляром класса в ее конце. Различают следующие типичные случаи :

нотация	объяснение	пример
0..1	Ноль или один экземпляр	кошка имеет или не имеет хозяина
1	Обязательно один экземпляр	у кошки одна мать
0..* или *	Ноль или более экземпляров	у кошки может быть, а может и не быть котят
1..*	Один или более экземпляров	у кошки есть хотя бы одно место, где она спит