Диаграммы кооперации и их нотация

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

Следует отметить, что здесь имеет место некоторая терминологическая путаница. В оригинале такие диаграммы называются Collaboration Diagram. Слово "collaboration", конечно же, синоним слова "cooperation", но в "русском" варианте звучит хуже. Поэтому в русскоязычных учебниках говорят "диаграмма кооперации", а не "коллаборации". Кроме этого, само это название немного устарело - в UML 2.x подобные диаграммы называются Communication Diagram. Впрочем, все три слова - "cooperation", "collaboration" и "communication" - являются синонимами, так что довольно часто используется "старое" название. Часто даже, говоря "диаграммы взаимодействия", подразумевают именно диаграммы кооперации.

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

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

Говоря о диаграммах кооперации, часто упоминают два "уровня" таких диаграмм - уровень экземпляров (примеров, Instance-Level) и уровень спецификации (Specification-Level). В чем же разница? Ответ прост: уровень экземпляров отображает взаимодействия между объектами (экземплярами классов); такая диаграмма обычно создается, чтобы исследовать внутреннее устройство объектно-ориентированной системы. Уровень же спецификации используется для изучения ролей, исполняемых в системе основными классами. В любом случае, диаграмма взаимодействия не отображает процесс. Она показывает взаимодействие между объектами, которое, как мы уже знаем, осуществляется путем посылки и приема сообщений. При этом точная последовательность сообщений не так хорошо видна, как на диаграмме последовательностей, так что если для вас важно отобразить именно порядок отправки и приемов сообщений, используйте диаграмму последовательностей.

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

Итак, кооперация (collaboration). Это статическая конструкция для моделирования набора сущностей, взаимодействующих друг с другом. Кооперация определяет набор взаимодействующих ролей, используемых вместе, чтобы показать некую функциональность. Кооперация часто реализует некоторый паттерн (шаблон проектирования). Впрочем, о шаблонах проектирования мы сейчас говорить не будем, поскольку они выходят за рамки этого курса и первого теста программы OCUP. Заинтригованным читателям мы предложим попробовать ввести словосочетание "design patterns" в адресную строку браузера. Спорим, попадете на статью "Design pattern (computer science)" из "Википедии"?

Кооперация изображается в виде эллипса с пунктирной границей, причем символ этот может использоваться двумя способами. Вот первый способ (рис.7.11):

Рис. 7.11. Изображение кооперации

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

Рис. 7.12. Обозначение ролей в кооперации

Все ведь понятно, правда? Видно, кто какую роль играет и в каком взаимодействии (кооперации). А еще показана генерализация и кооперации, и самих исполнителей.

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

Поскольку диаграмма кооперации - всего лишь альтернативная форма представления той же информации, которая содержится в диаграмме последовательностей, то и обозначения объектов (классов) в ней, по сути, такие же, как и на диаграмме последовательностей (и на других диаграммах). Чтобы проиллюстрировать это утверждение, приведем пример диаграммы взаимодействия, позаимствованный нами с сайта http://www.agilemodeling.com/ (а точнее, http://www.agilemodeling.com/style/collaborationDiagram.htm) (рис.7.13):

Рис. 7.13. Пример диаграммы взаимодействия

Как видите, диаграмма иллюстрирует покупку некоторого товара (вероятно, в онлайне) и оплату с помощью кредитной карты. Еще одна интересная вещь, которую можно увидеть на этой диаграмме - это сообщения, вернее, то, как они изображаются. Сообщения показаны в виде текста (названия метода) со стрелкой. Но есть один нюанс: на диаграмме последовательностей было легко показать последовательность отправки сообщений, так как линии жизни служили одновременно "осями времени", направленными вниз, и, естественно, было видно, что нижние сообщения отправлены позже верхних. В диаграммах кооперации проблему отображения очередности сообщений решили просто - перед названием каждого сообщения просто пишут его номер. Выглядит эта конструкция так: номер:название_сообщения. Причем часто используют и составные номера. Например, объект отправил другому объекту сообщение с номером 1. Когда объект-получатель в свою очередь отправляет сообщения другим объектам, они получают номера 1.1, 1.2 и т. д. Иногда нужно показать одновременную отправку сообщений. Чтобы отметить параллельные потоки сообщений, их номера предваряют буквами A, B, C, D и т. д. Вот пример таких обозначений, позаимствованный опять-таки с http://www.agilemodeling.com/ (рис.7.14):

Рис. 7.14. Обозначение параллельных потоков сообщений

Еще одна "мелочь", на которую хотелось бы обратить внимание пользователя - это мультиобъекты. Мультиобъект показывает, что на "дальнем" конце ассоциации находится не один, а целый набор объектов. Такая конструкция используется, чтобы показать операцию, которая нацелена на целый набор объектов. Мультиобъект изображается как два прямоугольника, смещенных по отношению друг к другу, что создает впечатление "колоды карт". Сообщение, отправленное мультиобъекту, означает сообщение к набору объектов, например, операция выбора - поиска определенного объекта. Пример подобной диаграммы показан на рисунке (рис.7.15):

Рис. 7.15. Пример диаграммы с мультиобъектом

Смысл диаграммы вполне понятен: для печати документа из некоторого приложения необходимо выбрать из всех доступных некий конкретный принтер. Символ композиции применен для того, чтобы показать, что принтер входит в состав набора объектов. Предположим теперь, что у нас доступны несколько сетевых принтеров и один локальный. Как показать, что выбран именно он? Легко. Для этого используют связи со стереотипами. Чтобы показать, что выбран локальный принтер, чуть изменим предыдущую диаграмму (рис.7.16):

Рис. 7.16. Обозначение выбора локального принтера

Следует отметить, что иногда вместо фигурных скобок используются угловые кавычки (как мы привыкли делать, указывая стереотип в названии компонента или класса), но чаще все же применяют фигурные скобки. Измененная диаграмма стала еще более понятной, не правда ли? Чтобы закрепить полученные знания о связях со стереотипами, приведем еще один пример (рис.7.17):

Рис. 7.17.

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

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

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

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

Рис. 7.18. Обозначение композитного объекта

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

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

Рис. 7.19. Активный объект на диаграмме

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

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

Рис. 7.20. Пример композитной структурной диаграммы

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

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

Рис. 7.21. Обозначение портов на диаграмме

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

Дата добавления: 2014-02-26; просмотров: 947; Нарушение авторских прав

Мы поможем в написании ваших работ!