Диаграммы взаимодействия

Лекция 5:

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

Рекомендации по построению диаграмм взаимодействия. Диаграммы взаимодействия и их место среди других диаграмм UML. Смысл диаграмм взаимодействия интуитивно нам, конечно же, понятен. Однако посмотрим, что о таких диаграммах говорили классики, например Буч. А вот что:

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

Несмотря на то величайшее уважение, которое мы питаем к Г. Бучу, это определение не кажется нам уж очень удачным. Хотя суть понятия оно передает. Наиболее важное слово в этом определении - это слово "сообщения". Действительно, как люди программирующие, мы понимаем, что взаимодействие-то как раз и состоит в обмене сообщениями между объектами! И к вопросу о сообщениях мы в этой лекции еще не раз вернемся. А пока же посмотрим, что Буч говорит дальше.

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

Диаграмма последовательностей - диаграмма взаимодействия, в которой основной акцент сделан на упорядочении сообщений во времени.

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

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

Рекомендуемые материалы

А какое же место диаграммы взаимодействия занимают среди других диаграмм UML? На этот вопрос можно ответить двояко. Можно просто говорить о построении диаграмм взаимодействия как об определенном этапе в процессе моделирования. А можно вспомнить о фазах жизненного цикла разработки ПО и посмотреть, где же диаграммы взаимодействия окажутся в таком случае. Да, кстати, кто помнит, какая диаграмма UML наилучшим образом подходит для описания процессов? Хм, что-то не видно леса рук... Ах да, видим одну руку - девушка, сидящая в дальнем углу зала, за колонной... Правильно! Диаграмма активностей. Что ж, попробуем нарисовать диаграмму активностей, описывающую процесс построения модели системы. Вот вариант такой диаграммы, предложенный одним из наших студентов (рис. 5.1):

Рис. 5.1.

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

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

Рис. 5.2.

И опять все вроде бы логично - мы строим диаграммы взаимодействия во время анализа поведения системы. Кстати, из рисунка (сказать "диаграмма" язык не поворачивается) очень хорошо видно, что диаграмма последовательностей и диаграмма кооперации взаимозаменяемы и являются альтернативными друг другу шагами процесса.

Диаграммы последовательностей и их нотация

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

Еще одна вещь, которую можно увидеть на диаграммах последовательностей - это длинные прерывистые полосы на линиях жизни. Таким образом обозначаются периоды времени, когда объект имеет фокус управления, т. е. выполняет некоторое действие (причем неважно как - непосредственно или путем вызова некоей подчиненной операции). Фокус управления на диаграммах последовательностей часто не изображают: ведь и так понятно, где он должен располагаться, достаточно взглянуть на положение стрелок, изображающих сообщения. Рисовать фокус или нет - дело привычки каждого проектировщика. Впрочем, многие средства UML- моделирования рисуют фокус автоматически, так что человеку не нужно заботиться о его изображении. Если объект в процессе взаимодействия разрушается, этот факт помечают на его линии жизни крестиком, который, собственно, эту линию и заканчивает. Да, все мы смертны. Иногда так и тянется рука написать "R.I.P." рядом с таким крестиком...

Не полагаясь на выразительную силу и образность наших описаний, все же покажем примеры всех этих обозначений (рис. 5.3).

Рис. 5.3.

А вот еще парочка обозначений. Первое из них - это анонимный эктор, которого изображают, если нужно показать использование объектов системы некоей внешней сущностью или абстрактным пользователем. Второе - это рефлексивное сообщение. Помните, что такое рефлексия? Правильно, самосозерцание! Тут, в принципе, происходит нечто подобное: объект посылает сообщение самому себе. Так рисуют, если нужно показать действие, выполняемое самим объектом (или внутри него), либо то, что объектсам себя вводит в некоторое состояние (рис. 5.4).

Рис. 5.4.

И еще одно - мы легко можем представить ситуацию посылки сообщения в зависимости от истинности некоторого условия. Например, если цена приглянувшейся нам в магазине вещи меньше ста условных единиц, мы вполне можем приобрести ее за наличные. Покупку на сумму от 100 до 1000 долларов можно оплатить кредитной картой, а чтобы купить нечто, стоящее дороже 1000 у. е., придется брать кредит. А как изобразить такие ситуации ( ветвления ) на диаграмме последовательностей? Да легко (рис. 5.5)!

Рис. 5.5.

Впрочем, ветвление - конструкция для диаграмм последовательностей непопулярная и используется она в них очень редко. Считается, что ветвления более присущи диаграммам деятельностей...

Ранее мы говорили, что сообщение посылается объектом в расчете на определенную реакцию, на то, что за этим последует некоторая деятельность. Например, посылка ответного сообщения. А как на диаграммах последовательностей изображаются ответные сообщения? Обычно их изображают пунктирной линией со стрелкой, хотя часто они имеют точно такой же вид, как и обычные сообщения, только направлены в противоположную сторону. Как именно их рисовать - пунктирной линией или сплошной - решать вам. Это абсолютно не принципиально (рис. 5.6).

Рис. 5.6.

Хм, картина усложняется. Мы уже видели два вида стрелок. И соответственно, два вида сообщений - прямое и ответное. Может быть, есть еще какие-то виды сообщений, о которых мы пока не знаем? Да, есть. Сами по себе сообщения бывают синхронными и асинхронными. Синхронные сообщения приостанавливают поток выполнения до тех пор, пока не будет получен ответ. Все сообщения, которые мы рассматривали в наших примерах, были именно синхронными. Пусть мы и не везде рисовали ответное сообщение, но оно подразумевалось: банк выносит решение о предоставлении кредита и сообщает его вам, терминал кредитных карт подтверждает транзакцию и печатает чек, на котором вы ставите подпись, кассир выдает вам подтверждение платежа - кассовый чек. Синхронные сообщения изображаются сплошной линией с треугольной закрашенной стрелкой на конце.

Другой вид сообщений - асинхронные сообщения. Они не ждут ответа, не приостанавливают поток выполнения - сразу после их посылки происходит немедленный переход к следующему шагу, и последовательность продолжается. Входя в офис поутру и говоря коллегам "hello, how are you?", вы ведь не ждете, что они остановят вас и начнут в течение часа рассказывать о своих проблемах? Это просто формальное приветствие, не предусматривающее ответа (асинхронное). Асинхронные сообщения изображаются сплошной линией с обычной (составленной из двух отрезков) стрелкой на конце. А как изображаются ответные сообщения, мы уже знаем (рис. 5.7):

Рис. 5.7.

И еще. Возможны случаи, когда нам известен адресат сообщения, но неизвестен его отправитель. С примерами таких сообщений (в бумажном виде) в советские времена довольно часто встречались секретари госучреждений. Такие сообщения называютнайденными. Или обратный случай: отправитель известен, а получатель - нет. Пример? Да хотя бы записки, запечатанные в бутылки, которые когда-то бросали в море жертвы кораблекрушений! Такие сообщения называют... Да-да, именно - потерянными. На диаграммах они изображаются без особых изысков (рис. 5.8).

Рис. 5.8.

Рассмотрим, наконец, "полный" пример диаграммы последовательностей. И конечно же, этот пример мы возьмем с сайта шуток наUML http://www.umljokes.com (рис. 5.9).

увеличить изображение
Рис. 5.9.

Не правда ли, очень жизненный анекдот? А вот еще один пример, показывающий, что, задав вопрос "сколько будет два плюс два?", вы не всегда услышите в ответ "четыре". Ответ на любой вопрос всегда сильно зависит от личности, настроения, уровня интеллекта отвечающего, даже от его профессии. И вот вам тому доказательство (рис. 5.10).

увеличить изображение
Рис. 5.10.

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

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

Следует отметить, что здесь имеет место некоторая терминологическая путаница. В оригинале такие диаграммы называются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):

увеличить изображение
Рис. 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.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 - вспомните условия в квадратных скобках под сообщениями на диаграмме последовательностей с ветвлением!

Выводы

· Диаграмма последовательностей - диаграмма взаимодействия, в которой основной акцент сделан на упорядочении сообщений во времени.

· Диаграмма кооперации - альтернативная форма представления информации, содержащейся в диаграмме последовательностей.

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

· Существуют различные типы сообщений: синхронные, асинхронные и ответные, потерянные и найденные.

· Диаграммы кооперации бывают двух "уровней" - уровня экземпляров и уровня спецификации.

· Кооперация - это статическая конструкция для моделирования набора сущностей, взаимодействующих друг с другом.

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

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

· Может ли диаграмма последовательностей содержать объект с линией жизни, но без фокуса управления?

Рекомендация для Вас - Назначение, классификация и организация АЛУ.

· Чем отличаются представления кооперации на уровне спецификации и на уровне примеров?

· В чем разница между активными и пассивными объектами?

· Чем асинхронное сообщение отличается от синхронного?

· Что такое мультиобъект?

· Что такое композитный объект и как он связан с понятием кооперации?

· Как можно избежать усложнения диаграммы взаимодействия с разветвленным потоком управления?