Опубликован: 23.05.2008 | Доступ: свободный | Студентов: 10366 / 2990 | Оценка: 4.39 / 4.02 | Длительность: 09:14:00
ISBN: 978-5-94774-878-9
Лекция 6:

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

< Лекция 5 || Лекция 6: 1234 || Лекция 7 >

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

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

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

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

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

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

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

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

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


Рис. 5.11.

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


Рис. 5.12.

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

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

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

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


Рис. 5.14.

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


Рис. 5.15.

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


Рис. 5.16.

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


Рис. 5.17.
< Лекция 5 || Лекция 6: 1234 || Лекция 7 >
Дарья Федотова
Дарья Федотова
Сергей Березовский
Сергей Березовский

В рамках проф. переподготовки по программе "Программирование"

Есть курсы, которые я уже прошел. Но войдя в курс я вижу, что они не зачтены (Язык Ассемблера и архитектура ЭВМ, Программирование на С++ для профессионалов). Это как?

Анатолий Федоров
Анатолий Федоров
Россия, Москва, Московский государственный университет им. М. В. Ломоносова, 1989
Георгий Козлов
Георгий Козлов
Россия, НИУ ГУ-ВШЭ, 2013