Агрегирование

У конца ассоциации может быть одно важное свойство под названием агрегирование (aggregation), которое обозначает наличие связи "целое/часть" (part of) между экземплярами классов. Объект -часть в той или или иной форме включается в объект -целое. Так, например, на рис. 4.1 показано, что объекты классаCOperator входят в объект класса COperatorList (то есть первый класс агрегируется вторым). Таким образом, агрегирование, как частный случай ассоциации, также обязательно переходит в связи между экземплярами классов.

С помощью агрегирования, например, нельзя определить nested-класс в Java-приложении. Подобный недостаток выразительных средств UML (в частности, для Java) является предметом обширной дискуссии и приводит к созданию диалектов UML, которые являются менее общими, но точнее отражают нужды конкретных платформ реализации. Эти специализации можно создавать, используя встроенные в UML средства - механизм профайлов и extention-механизм. А можно создавать свой собственный визуальный язык и реализовать его, пользуясь DSM -средствами, которых сейчас много - например, Microsoft DSL Tools или Eclipse/GMF. Подробнее об этом будет рассказано в следующих лекциях.

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

Рис. 4.8. Пример композиции

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

Агрегирование принципиально отличается от наследования. Это важно, поскольку при моделировании предметной области с помощью диаграмм классов UML можно заметить их определенное сходство: (i) оба позволяют строить древообразную иерархию классов; (ii) предок, так же как и агрегируемый класс, добавляет функциональности в потомок/агрегат; (iii) изображения обоих отношений чем-то похожи визуально. И мне как-то раз пришлось в непростом диалоге убеждать аналитиков, что наследование и агрегирование - это не одно и то же. И вот почему.

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

2. Наследование модифицирует класс-предок, непосредственно добавляя, "вливая" в него новые свойства (атрибуты, методы, реализацию методов). Агрегирование никак не затрагивает агрегат, и у последнего могут быть свои собственные методы и атрибуты. В случае агрегирования части не "растворяются" в целом, оставаясь отдельными частями в его составе.

Диаграммы пакетов (package diagrams)

Пакет (package) - это конструкция UML, предназначенная для упорядочивания UML -моделей, а также для группировки классов.

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

Во-вторых, в пакеты традиционно помещают классы системы, особенно если проект большой и их много. При этом пакеты UML могут соответствовать, например, проектам (projects) Microsoft Visual Studio. Однако пакеты UML могут быть многократно вложены друг в друга, а проекты Microsoft Visual Studio вложенными быть не могут.

В Microsoft Visual Studio есть так называемые рабочие области (solutions), которые содержат в себе проекты. Но на компьютере каждого разработчика проекта могут быть созданы свои собственные рабочие области, содержащие нужные ему проекты, а рабочая область всего приложения, используемая для целостной сборки приложения, может быть вообще другой. Так что рабочие области являются плохими кандидатами на роль пакетов, включающие в себя пакеты-проекты.

Пакеты связываются друг с другом специальным отношением - зависимостью (dependence). Это направленное отношение, и идет оно от того пакета, который зависит, к пакету, который необходим тому, первому, зависимому. Это означает, что используемый пакет содержит описание конструкций, которые зависимый пакет импортирует, а не реализует сам. Зависимость не ограничивается только диаграммами пакетов, но может быть использована и для связи других UML -конструкций, например, может связывать два случая использования: один из них может зависеть от другого.

Пример диаграммы пакетов изображен на рис. 4.9. Пакет Client содержит два пакета - ClientGUI, в котором находится описание пользовательского интерфейса, и ClientNetwork, отвечающий за сетевое взаимодействие с сервером. При этом первый пакет зависит от второго. В данном случае зависимость означает обычную зависимость проектов в Visual Studio.

увеличить изображение
Рис. 4.9. Пример диаграммы пакетов

Пакет Server содержит все проекты приложения, которые реализуют работу сервера. ServerBusinessLogic содержит весь код, реализующий бизнес-логику сервера, ServerNetwork реализует сетевое сообщение с клиентом, RequestDB - примитивы доступа и логику работы с базой данных запросов. ПакетUtil является служебным пакетом где находятся все вспомогательные типы данных, классы, операции и т. д., которые используются всеми пакетами сервера.

На рис. 4.10 средствами диаграмм классов UML показано содержимое пакета ServerBusinessLogic.

Рис. 4.10. Содержимое пакета ServerBusinessLogic в терминах диаграмм классов

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

Необходимо отметить, что при проектировании больших приложений, с большим количеством классов и пакетов (в смысле projects в Microsoft Visual Studio), целесообразно создавать диаграммы пакетов. Полезно как-то предварительно прикинуть структуру проектов приложения, хотя, конечно, потом это видение может меняться. Однако ошибки при проектировании структуры пакетов большого приложения приводят к значительным неудобствам, дополнительной работе и к потере концептуальной целостности приложения.

Диаграммы объектов (object diagrams)

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

Рис. 4.11. Пример диаграммы объектов

На этом рисунке изображена следующая конфигурация сервера службы телефонных заявок: один диспетчер (объект ':CDispatcher '), один объект, работающий с PBX (':PBX_Agent ') и два оператора – объекты ' Tester1:COperator ' и ' Tester2:CSubOperator '. Для двух первых объектов не указаны имена, поскольку в системе одновременно может быть только по одному такому объекту. Два других объекта соответствуют тестовым операторам, один из которых является "продвинутым" (Tester2, принадлежащий классу CSubOperator).>

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

Общее правило для отображения имен экземпляров таково:

<идентификатор1>: <идентификатор2>,

где <Идентификатор1> - это имя экземпляра, а <Идентификатор2> - имя его классификатора. Строка с именем должна быть подчеркнута.

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

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

Нужно отметить, что изображение имен классов у объектов, как правило, можно отключать, но это не означает, что их нет.

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

Кооперации (collaborations)

Так в UML называется описание определенной задачи (например, какой-либо пользовательской функции системы, или внутренней задачи самого ПО, или же какого-либо алгоритма предметной области) в терминах взаимодействующих элементов. Описывается не поведение, а взаимодействующие стороны и их связи. Кооперации показываются на специальном типе диаграмм - на диаграммах композитных структур (composite structure diagrams). Эти диаграммы могут использоваться также для моделирования композитных компонент, как это будет показано в лекциях, посвященных моделированию систем реального времени.

Общающиеся стороны задаются ролями, которые описывают некоторую часть функциональности класса, используемого данным контекстом (в данном случае таким контекстом является кооперация). Например, для двух классов - Абонент и Станция - кооперация "Соединение" (см. рис. 4.13) определяет контекст - процедуру установки соединения между абонентом и станцией, а роли этих классов "берут" из самих классов ту функциональность, которая реализует эту процедуру. Ведь кроме этой функциональности в данных классах может быть много разной другой. Роль занимает промежуточное место между классом и его экземплярами². На рис. 4.12, а и б представлены примеры двух альтернативных способов задания кооперации.

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

увеличить изображение
Рис. 4.12. Способы задания кооперации

Рис. 4.13. Пример использования кооперации на диаграмме объектов

Кооперация "Соединение" может быть использована на других диаграммах - на диаграмме объектов, как на рис. 4.13, а также при определении других коопераций (см. рис. 4.14). Использование кооперации (collaboration use) - это новая конструкция UML, которая ссылается на определение кооперации и подставляет вместо ее ролей другие роли или объекты, совместимые с ней.

На рис. 4.14 изображено использование кооперации "Соединение" на диаграмме коопераций для создания более сложной кооперации под названием "Соединение абонентов станции". У этой кооперации есть три роли - "Вызывающий абонент ", "Вызываемый абонент " и "Своя станция" ("своя" означает, что оба абонента принадлежат одной станции - речь здесь не идет об установлении межстанционного соединения). Эти роли принадлежат классам " Абонент ", " Абонент ", "Станция" соответственно и подставляются в кооперацию "Станция", образуя два использования этой кооперации - "Исходящее соединение" и "Входящее соединение".

Рис. 4.14. Пример использования кооперации при определении другой кооперации

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

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

Диаграммы конечных автоматов (statechart diagrams)

На рис. 4.15 приведен пример диаграммы конечных автоматов. Эта диаграмма описывает алгоритм поведения объектов класса COperator системы "Телефонной службы приема заявок", изображенного на рис. 4.1.

Рис. 4.15. Пример диаграммы конечных автоматов

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

Из состояния WaitingForConnection объект может перейти в состояние Idle, если ожидание соединения с оператором превысит время T12.

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

В состоянии Connected объект может получить четыре сигнала Disconnect, не реагируя на них, но при получении пятого он переходит в состояние Idle.

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