Диаграммы взаимодействия: крупным планом

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

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

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

Посмотрим же, как это выглядит на примере (рис. 5.18):

Рис. 5.18.

Не правда ли, эта упрощенная модель графического окна проста и понятна? Окно имеет заголовок, рабочую область и две полосы прокрутки - горизонтальную и вертикальную, которые ее перемещают. Все просто!

Композитный объект лишь близок по значению к кооперации, но не встречается на диаграммах взаимодействия "в чистом виде". На диаграммах взаимодействия иногда можно увидеть очень близкую по смыслу конструкцию, а именно активный объект. Активными называют объекты, которые владеют собственным потоком управления и могут инициировать выполнение действий. Пассивные объекты содержат данные, но не могут инициировать выполнение. Конечно, пассивные объекты могут посылать сообщения в процессе обработки полученных запросов. Активный объект (или, вернее, его роль) выглядит на диаграмме как прямоугольный символ объекта, но с утолщенными границами. Часто активный объект изображается как композитный объект, содержащий объекты-части. Посмотрите, например, на эту диаграмму, позаимствованную нами с http://etna.intevry.fr/COURS/UML/notation/notation8a.html (рис. 5.19):

Рис. 5.19.

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

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

Рис. 5.20.

Прекрасная модель велосипеда! Узнаете старых знакомых - композитные объекты?

К сожалению, композитные структурные диаграммы находятся за пределами тематики экзамена UM0-100, поэтому больше о них мы здесь говорить не будем. Однако напоследок скажем, что, кроме внутренних частей, на таких диаграммах можно увидеть еще одно новшество UML 2 - порты. Порт - это типизированный элемент, который представляет "видимую снаружи" часть содержащего его элемента. Порт, как это и следует из названия, определяет взаимодействие элемента модели с окружающей его средой. Порт может размещаться на границе части, класса или композитной структуры. Порт может описывать сервисы, предоставляемые элементом модели (и требуемые окружающей его средой). Изображается порт как именованный (недаром же мы ранее сказали "типизированный") прямоугольник на границе содержащего его элемента модели (впрочем, иногда можно увидеть символ порта и внутри символа класса - тогда говорят, что класс имеет скрытый порт ). Чтобы покончить с этими отступлениями от темы, покажем, как все это выглядит на диаграмме, и вернемся к диаграммам взаимодействия (рис. 5.21).

Рис. 5.21.

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

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

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

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

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

Если же хочется еще больше детализировать диаграмму, можно ввести временные ограничения на выполнение отдельных действий. Впрочем, для простых асинхронных сообщений временные ограничения, скорее всего, не нужны. А вот необходимость синхронизации сложных потоков управления часто требует использования таких ограничений. Запись их должна следовать правилам языка объектных ограничений (OCL, Object Constraint Language). Рассмотрение OCL выходит за рамки нашего курса и экзамена UM0-100, для подготовки к которому он написан. Хотя, сами того не зная, мы уже использовали OCL - вспомните условия в квадратных скобках под сообщениями на диаграмме последовательностей с ветвлением!

Выводы

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

Контрольные вопросы

• Может ли диаграмма последовательностей содержать объект с линией жизни, но без фокуса управления?
• Чем отличаются представления кооперации на уровне спецификации и на уровне примеров?
• В чем разница между активными и пассивными объектами?
• Чем асинхронное сообщение отличается от синхронного?
• Что такое мультиобъект?
• Что такое композитный объект и как он связан с понятием кооперации?
• Как можно избежать усложнения диаграммы взаимодействия с разветвленным потоком управления?