2. Отношения между классами

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

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

Ассоциация (association) ­ произвольное отношение или взаимосвязь между классами. Бинарная ассоциация (ассоциация между двумя классами) обозначается сплошной линией. В качестве дополнительных символов могут использоваться: имя ассоциации, имена, видимость и кратность концов ассоциации (рис. 2). Частным случаем бинарной ассоциации является рефлексивная ассоциация (класс связывается сам с собой).

Рис. 2. Графическое изображение ненаправленной бинарной ассоциации между классами

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

На рис. 2 конец ассоциации класса Сотрудник имеет имя работник, общедоступную видимость и кратность 1..*. Конец ассоциации класса Компания имеет имя работодатель, общедоступную видимость и кратность 1. Наличие указанных кратностей будет означать, что в рамках рассматриваемой модели любой конкретной компании может соответствовать несколько конкретных сотрудников. Этот факт может быть интерпретирован так: в компании работают несколько сотрудников, общее число которых заранее неизвестно и ничем не ограничено. С другой стороны, любому сотруднику будет всегда соответствовать единственная компания. Это означает, что в рамках рассматриваемой модели недопустима одновременная работа сотрудников в нескольких компаниях. Заметим, что символ кратности 0..* означает, что отдельные компании могут совсем не иметь сотрудников в своем штате.

Вернемся к модели на рис. 2: параметры установленной связи (ненаправленная ассоциация, ее видимость и кратность) при генерации программного кода классов не добавляет никаких атрибутов в классы (рис. 3).

Рис. 3. Программный код, сгенерированный по модели на рис.2

В качестве примера ассоциации со специфицированной навигацией рассмотрим отношение между классами Многоугольник и Линия (рис. 4). Классы связаны бинарной ассоциацией с навигацией, т.е. класс Многоугольник должен содержать информацию о своих сторонах. Программный код, сгенерированный на основании модели показан на рис. 5.

Рис. 4. Графическое изображение бинарной ассоциации с навигацией

При генерации программного кода для ассоциации с навигацией происходит добавление в код класса нового атрибута с именем рассматриваемого конца ассоциации, имеющий соответствующую видимость и кратность (рис. 5).

Рис.5. Программный код, сгенерированный для классов рис. 4

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

Рис.6. Варианты изображение двусторонней ассоциации

Более общий случай представляет собой n-арная ассоциация, которая связывает некоторым отношением ассоциации более двух классов. В качестве значения n может выступать произвольное натуральное число больше 1. N-арная ассоциация графически обозначается ромбом, от которого ведут линии к классам. Имя n-арной ассоциации пишется рядом с ромбом. Порядок классов в такой ассоциации не фиксируется.

На рис. 7 рассмотрен пример 4-арной ассоциации Игра между классами ФутбольнаяКоманда, Год и Дата.

Рис.7. Графическое изображение 4-арной ассоциации

Обобщение (generalization) ­ отношение между более общим классификатором (родителем или предком) и более специальным классификатором (дочерним или потомком).

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

Отношение обобщения является направленным (стрелка указывает на общий класс) и может использоваться для представления иерархических взаимосвязей между классами. На рис.8 показано отношение обобщения классов Квадрат и Прямоугольник. Класс Квадрат наследует от класса Прямоугольник все атрибуты. Класс Квадрат имеет дополнительный атрибут цветКонтура.

Рис. 8. Графическое изображение отношения обобщения в UML

Отношение обобщения, которое называют также отношением классификации или наследования, допускает, чтобы от одного класса-предка одновременно наследовали несколько классов-потомков (рис.9). В нотации UML 2.1.1 допускается также, чтобы класс-потомок наследовал от нескольких классов-предков (множественное наследование).

Рис. 9. Пример графического изображения отношения обобщения для нескольких классов-потомков

Агрегация (aggregation) ­ направленное отношение между двумя классами, предназначенное для представления ситуации, когда один из классов представляет собой некоторую сущность, которая включает в себя в качестве составных частей другие сущности. Агрегация имеет фундаментальное значение для описания структуры сложных систем, поскольку применяется для представления системных взаимодействий типа «часть-целое».

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

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

Графическое изображение агрегации показано на рис.10. Незакрашенный (пустой) ромб размещается на агрегированном конце ассоциации.

Рис.10. Диаграмма классов для иллюстрации отношения агрегации на примере ПК

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

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

Графически отношение композиции представлено на рис.11. Ромб с заливкой указывает на класс-композит.

Рис.11. Диаграмма классов для иллюстрации отношения композиции

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

Зависимость (dependency) ­ отношение, предназначенное для описания ситуации, когда отдельному элементу модели или множеству элементов модели требуются другие элементы модели для своей спецификации или реализации.

Зависимость означает отношение типа «поставщик/клиент» между элементами модели, т.е. модификация элемента-поставщика оказывает влияние на элемент­клиент. Клиент­ зависимый в некотором контексте от поставщика элемент модели. Семантика клиента не является полной без поставщика.

Наличие отношения зависимости в модели не имеет никакой семантики времени выполнения, поскольку задается в терминах элементов модели, которые принимают участие в этом отношении, а не в терминах их экземпляров.

Отношение зависимости графически отображается пунктирной направленной линией (рис.12). Стрелка направлена от класса-клиента (от зависимого класса) к классу­поставщику (независимому классу).

Рис.12. Пример отношения зависимости класса-клиента (Этап) от класса-поставщика (Договор)

Реализация (realization) ­ специализированное отношение зависимости между двумя элементами модели, один из которых представляет некоторую спецификацию (поставщик), а другой представляет его реализацию (клиент).

Отношение реализации означает, что множество элементов клиента является реализацией множества элементов поставщика, которое служит в качестве спецификации. Зависимость изображается в форме пунктирной линии с треугольником на конце (к реализуемому элементу). На рис.13 показан пример отношения реализации.

Рис.13. Графическое изображение отношения реализации на диаграмме классов