Отношения и их графическое изображение на диаграмме классов.

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

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

Базовые отношения, изображаемые на диаграммах классов:

1. отношение ассоциации (association relationship);

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

3. отношение агрегации (aggregation relationship);

4. отношение композиции (composition relationship).

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

Отношение ассоциации

Определение 11. Ассоциация (association) – семантическое отношение между двумя и более классами, которое специфицирует характер связи между соответствующими экземплярами этих классов.

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

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

Наиболее простой случай данного отношения – бинарная ассоциация (binary association), которая служит для представления произвольного отношения между двумя классами. Она связывает в точности два различных класса и может быть ненаправленным (симметричным) или направленным отношением. Частный случай бинарной ассоциации – рефлексивная ассоциация, которая связывает класс с самим собой, т.е. один экземпляр класса обращается к другому экземпляру этого же класса. На рисунке 12 показано изображение рефлексивного отношения.

Рис. 12. Рефлексивная ассоциация.

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

В качестве простого примера ненаправленной бинарной ассоциации можно рассмотреть отношение между двумя классами – классом Компания и классом Сотрудник (рис. 13). Они связаны между собой бинарной ассоциацией, которая при движении от сотрудника к компании читается как Работает на, а при движении от компании к сотруднику – Использует труд. Имя ассоциации указано на рисунке рядом с линией, изображающей ассоциацию.

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

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

Направленная (однонаправленная) бинарная ассоциация изображается сплошной линией с простой стрелкой на одной из ее концевых точек. Направление этой стрелки указывает на то, какой класс является первым, а какой – вторым.

В качестве простого примера направленной бинарной ассоциации можно рассмотреть отношение между двумя классами – классом Клиент и классом Счет (рис. 14). Они связаны между собой бинарной ассоциацией с именем Имеет, для которой определен порядок следования классов. Это означает, что конкретный объект класса Клиент всегда должен указываться первым при рассмотрении взаимосвязи с объектом класса Счет. Другими словами, эти объекты классов образуют кортеж элементов, например, <клиент, счет_1, счет_2,…, счет_n>.

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

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

Частный случай отношения ассоциации – так называемая исключающая ассоциация (Xor-association). Семантика данной ассоциации указывает на то, что из нескольких потенциально возможных вариантов данной ассоциации в каждый момент времени может использоваться только один. На диаграмме классов исключающая ассоциация изображается пунктирной линией, соединяющей две и более ассоциации (рис. 15), рядом с которой записывается ограничение в форме строки текста в фигурных скобках: {xor}.

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

Определение 12. N-арная ассоциация (n-ary association) – ассоциация между тремя и большим числом классов. (Тернарная ассоциация связывает отношением три класса.)

Графически n-арная ассоциация обозначается ромбом, от которого ведут линии к символам классов данной ассоциации. Сам же ромб соединяется с символами классов сплошными линиями. Обычно линии проводятся от вершин ромба или от середины его сторон. Имя n-арной ассоциации записывается рядом с ромбом соответствующей ассоциации. Однако порядок классов в n-арной ассоциации на диаграмме не фиксируется.

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

Рис. 16. Графическое изображение тернарной ассоциации между тремя классами.

Класс может быть присоединен к линии ассоциации пунктирной линией. Это означает, что данный класс обеспечивает поддержку свойств соответствующей n-арной ассоциации, а сама n-арная ассоциация имеет атрибуты, операции и/или ассоциации. Другими словами, такая ассоциация является классом с соответствующим обозначением в виде прямоугольника и самостоятельным элементом языка UML – ассоциативным классом (Association Class).

Определение 13. Класс-ассоциация(association class) – модельный элемент, который одновременно является ассоциацией и классом. Ассоциация-класс может рассматриваться как ассоциация, которая обладает свойствами класса, или как класс, имеющий также свойства ассоциации.

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

Рис. 17. Представление ассоциации в виде класса с атрибутами.

Отдельный класс в ассоциации может играть определенную роль в данной ассоциации. Эта роль может быть явно указана на диаграмме классов. С этой целью в языке UML вводится в рассмотрение специальный элемент – концевая точка ассоциации или конец ассоциации (Association End), который графически соответствует точке соединения линии ассоциации с отдельным классом.

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

Определение 14. Роль(role) – имеющее имя специфическое поведение некоторой сущности, рассматриваемой в определенном контексте.

Роль может бытьстатическойилидинамической.

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

Рис. 18. Указание роли класса при отношении ассоциации.

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

Примеры индикаторов мощности:

0..1 – ноль или один;

1 – ровно один;

1..* – один или много;

2..5 – 2,3,4 или 5

6..8,10 – 6,7,8 или 10

Так, для примера на рис. 13 кратность "1" для класса Компания означает, что каждый сотрудник может работать только в одной компании. Кратность "1..*" для класса Сотрудник означает, что в каждой компании могут работать несколько сотрудников, общее число которых заранее неизвестно и ничем не ограничено. Вместо кратности "1..*" нельзя записать только символ "*", поскольку последний означает кратность "0..*". Для данного примера это означало бы, что отдельные компании могут совсем не иметь сотрудников в своем штате. Как видно из примера, читать кратность класса нужно на противоположном конце связи.

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

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

Отношение обобщения.

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

Иногда обобщение называют отношениями типа "является", имея в виду, что одни сущности (например, круг, квадрат, треугольник) являются воплощением более общей сущности (например, класса "геометрическая фигура").

Данное отношение используется для представления иерархических взаимосвязей между различными элементами языка UML, такими как пакеты, классы, варианты использования. Применительно к диаграмме классов данное отношение описывает иерархическое строение классов и наследование их свойств и поведения.

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

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

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

Рис. 19. Обозначение отношения обобщения между классами.

Процедуру моделирования наследования можно проводить в следующей последовательности:

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

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

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

От одного класса-предка одновременно могут наследовать несколько классов-потомков. В этом случае на диаграмме классов для подобного отношения обобщения указывается несколько линий со стрелками. Например, класс Транспортное средство (курсив обозначает абстрактный класс) может выступать в качестве суперкласса для подклассов, соответствующих конкретным транспортным средствам, таким как: Автомобиль, Автобус, Трактор и другим. Это может быть представлено графически в форме диаграммы классов следующего вида (рис. 20).

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

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

Рис. 21. Альтернативный вариант графического изображения отношения обобщения классов для случая объединения отдельных линий.

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

В качестве ограничений могут быть использованы следующие ключевые слова языка UML:

1. {complete} – означает, что в данном отношении обобщения специфицированы все классы-потомки, и других классов-потомков у данного класса-предка быть не может.

2. {incomplete} – означает случай, противоположный первому. А именно, предполагается, что на диаграмме указаны не все классы-потомки. В последующем возможно разработчик восполнит их перечень, не изменяя уже построенную диаграмму.

3. {disjoint} – означает, что классы-потомки не могут содержать объектов, одновременно являющихся экземплярами двух или более классов.

4. {overlapping} – случай, противоположный предыдущему. А именно, предполагается, что отдельные экземпляры классов-потомков могут принадлежать одновременно нескольким классам.

С учетом дополнительного использования стандартного ограничения диаграмма классов, изображенная на рисунке 21, может быть уточнена (рис. 22).

Рис. 22. Вариант уточненного графического изображения отношения обобщения классов с использованием строки-ограничения.

Рассмотрим пример, иллюстрирующий процедуру моделирования наследования (рис. 23).

Рис. 23.

На первый взгляд, кажется странным, что класс "точка" не имеет никаких атрибутов, а круг имеет только радиус. С прямоугольником, вроде бы, все понятно - ширина и высота, но вот только где он расположен в пространстве, этот прямоугольник? Давайте попробуем следовать процедуре моделирования наследования. Итак, положение всех трех фигур можно однозначно определить с помощью пары чисел. Для точки - это вообще единственные ее характеристики, для круга и прямоугольника - их центры (под центром прямоугольника мы понимаем точку пересечения его диагоналей). Вот они, общие атрибуты! Таким образом, мы создали суперкласс "Фигура", имеющий два атрибута - координаты центра. Все остальные классы на этой диаграмме связаны с классом "Фигура" отношением обобщения, т. е. в них нужно доопределить только "недостающие" атрибуты - радиус, ширину и высоту. Атрибуты, описывающие координаты центра, эти классы имеют изначально как потомки класса "Фигура" - они их наследуют. Заметим, что операции классов мы тут не рассматриваем: понятно, что с ними была бы та же история.

Классы-потомки ведь наследуют атрибуты и операции суперкласса? Таким образом, они могут наследовать и их интерфейсы - то есть объекты абсолютно разной природы могут иметь один и тот же интерфейс! Так как же тогда определить, какого же все-таки класса объект?

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

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

Отношение агрегации.

Определение 17. Агрегация (простая агрегация, aggregation) - специальная форма ассоциации, которая служит для представления отношения типа "часть-целое" между агрегатом (целое) и его составной частью.

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

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

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

Графически отношение агрегации изображается сплошной линией, один из концов которой представляет собой не закрашенный внутри ромб. Этот ромб указывает на тот класс, который представляет собой "целое" или класс-контейнер. Остальные классы являются его "частями" (рис. 24).

Рис. 24. Графическое изображение отношения агрегации в языке UML.

В качестве примера отношения агрегации можно рассмотреть взаимосвязь типа "часть-целое", которая имеет место между классом Системный блок персонального компьютера и его составными частями: Процессор, Материнская плата, Оперативная память, Жесткий диск и Дисковод гибких дисков. Используя обозначения языка UML, компонентный состав системного блока можно представить в виде соответствующей диаграммы классов (рис. 25), которая в данном случае иллюстрирует отношение агрегации.

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

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

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

Отношение композиции.

Определение 18. Композиция (composition) - разновидность отношения агрегации, при которой составные части целого имеют такое же время жизни, что и само целое. Эти части уничтожаются вместе с уничтожением целого.

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

Определение 19. Композит(composite)-класс, который связан отношением композиции с одним или большим числом классов.

Графически отношение композиции изображается сплошной линией, один из концов которой представляет собой закрашенный внутри ромб. Этот ромб указывает на тот класс, который представляет собой класс-композит. Остальные классы являются его "частями" (рис. 26).

Рис. 26. Графическое изображение отношения композиции в языке UML.

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

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