Введение в UML 2.0, часть II

Диаграммы объектов (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) определяет контекст - процедуру установки соединения между абонентом и станцией, а роли этих классов "берут" из самих классов ту функциональность, которая реализует эту процедуру. Ведь кроме этой функциональности в данных классах может быть много разной другой. Роль занимает промежуточное место между классом и его экземплярами^{2Подробнее роль будет рассмотрена в лекциях, посвященных моделированию систем реального времени.}. На рис. 4.12, а и б представлены примеры двух альтернативных способов задания кооперации.

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

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

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

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

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

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

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