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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации по построению диаграмм классов

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

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

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

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