Как составить диаграмму взаимодействия

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

Общие сведения о диаграммах взаимодействия

Реализация отдельного варианта использования требует участия и взаимодействия определенных экземпляров актеров и классов. Наиболее подходящий инструмент для описания такого взаимодействия – это диаграммы последовательности и коммуникации, которые, по сути, отображают одну и ту же информацию. В связи с этим большинство Case-средств позволяет после построения одной из диаграмм автоматически получить другую, а также выполнять синхронизацию этих диаграмм между собой.

Общими элементами диаграмм являются:

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

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

Способ обозначения	Характеристика	Пример
Имя объекта:Имя класса	Полное обозначение.	Вася:Программист
:Имя класса	Анонимный объект.	:Программист
Имя объекта	Предполагается, что имя класса известно.	Вася
Имя объекта:	Объект-сирота.	Считается, что имя класса неизвестно. Вася:

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

Взаимодействие между экземплярами актеров и объектами моделируется посредством передачи сообщений. Сообщение (англ. message) – это спецификация факта передачи информации между сущностями с ожиданием выполнения определенных действий со стороны принимающей сущности. Сущность, отправляющую сообщение, называют клиентом, а принимающую – сервером. Таким образом, сообщения не только передают некоторую информацию, но и требуют или предполагают выполнения сервером определенных действий или передачу (возврат) клиенту необходимой информации. Если принимающей сообщение сущностью является объект, то оно представляет собой операцию (метод) объекта-сервера. Прием сообщения обычно трактуется, как возникновение события на сервере. Сообщения изображаются стрелкой с обязательным указанием направления (остриё стрелки указывает на принимающую сторону) и спецификации.

Ниже рассматриваются особенности построения диаграмм взаимодействия.

Назначение и состав диаграммы последовательности

Диаграмма последовательности (sequence diagram) наглядно отображает временной аспект взаимодействия. Она имеет два измерения. Одно измерение (слева-направо) указывает на порядок вовлечения экземпляров сущностей во взаимодействие. Крайним слева на диаграмме отображается экземпляр актера или объект, который является инициатором взаимодействия. Правее отображается другой экземпляр сущности, который непосредственно взаимодействует с первым и т.д. Второе измерение (сверху-вниз) указывает на порядок обмена сообщениями. Начальному моменту времени соответствует самая верхняя часть диаграммы. Масштаб на оси времени не указывается, поскольку диаграмма отображает лишь временную упорядоченность взаимодействия типа «раньше-позже».

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

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

   Не обязательно создавать все объекты в начальный момент времени. Отдельные объекты в системе могут создаваться по мере необходимости, существенно экономя ресурсы системы и повышая ее производительность. В этом случае объект изображается не в верхней части диаграммы, а в том месте, где он создается. Для обозначения факта уничтожения объекта в UML используется специальный символ X. Как правило, уничтожаются объекты, созданные на основе граничных и управляющих классов. Экземпляры актеров и объекты классов сущностей остаются в системе после окончания взаимодействия.

   

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

   – синхронное сообщение (англ. synchronous message). Клиент посылает сообщение серверу и ждёт, пока тот примет и обработает сообщение. Как правило, один объект передает синхронное сообщение второму, второй – третьему и т.д., образуя вложенный поток сообщений. В любом случае клиент, инициирующий поток сообщений, должен дождаться его завершения, т.е. возврата управления. Это самый распространенный тип сообщений;

   – асинхронное сообщение (англ. asynchronous message). Клиент посылает сообщение серверу и, не дожидаясь ответа, продолжает выполнять следующие операции;

   – возвращающее сообщение (англ. reply message), обозначающее возврат значения или управления от сервера обратно клиенту. Стрелки этого вида зачастую отсутствуют на диаграммах, поскольку неявно предполагается их существование после окончания процесса выполнения операции.

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

   Сообщения, получаемые от внешнего источника (англ. found message) и передаваемые внешнему приемнику (англ. lost message), должны, соответственно, начинаться и заканчиваться закрашенным кружком.

   UML регламентирует также два часто встречаемых вида сообщений — на создание и уничтожение объектов. Первое отображается как возвращающее сообщение со стереотипом «create», второе — как синхронное сообщение со стереотипом «destroy». После получения сообщения на уничтожение объекта его линия жизни заканчивается символом X.

   Каждое сообщение должно иметь имя по одному из следующих вариантов:

   • произвольная строка текста. Применяется на начальных стадиях проектирования или концептуальных диаграммах;

   • указание стереотипа для некоторых стандартных действий:

     • «create» (англ. – создать) – возвращающее сообщение, требующее создания объекта;
     • «destroy» (англ. – уничтожить) – синхронное сообщение с требованием уничтожить соответствующий объект;
     • «call» (англ. – вызвать) – синхронное сообщение, требующее выполнения операции принимающего объекта;
     • «send» (англ. – послать) – асинхронное сообщение, обозначающее посылку сигнала серверу;
     • «return» (англ. – возвратить) или «reply» (англ. – ответить)– возвращающее сообщение;

   • указание спецификации вызываемого метода объекта-получателя в формате:

     [переменная =] имя([список параметров]) [:возвращаемое значение].

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

   Имя сообщения (обязательный параметр) – имя вызываемого метода объекта-получателя.

   Список аргументов – список аргументов, разделенных запятыми и передаваемых для выполнения метода.

   Возвращаемое значение – константа или имя переменной, являющиеся результатом вызываемого метода.

3. Отправка и прием сообщений сопровождаются активностью объектов. Для явного выделения этого факта, на диаграмме можно использовать фокус управления (англ. focus of control). Он изображается в форме вытянутого узкого прямоугольника, верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а нижняя сторона – окончание фокуса управления (окончание активности). Условные операторы, циклы, рекурсия и вызов собственных методов (отправка рефлексивных сообщений) инициируют вложенные потоки управления у одного и того же объекта, что можно отобразить на диаграмме с помощью вложенных фокусов управления.

   

4. Для моделирования особенностей взаимодействия (условных операторов, циклов и т.п.) вместо вложенных фокусов управления лучше использовать фрагменты (англ. fragments). Фрагмент отображается прямоугольной рамкой вокруг сообщения (группы сообщений) с указанием в левом верхнем углу типа фрагмента.

   

   UML определяет следующие типы фрагментов:

   • alt (alternatives) — вызовы альтернативных сообщений (выполнение взаимоисключающих операций). Альтернативные сообщения (группы сообщений) отделяются друг от друга горизонтальными штриховыми линиями. Используется для моделирования условного оператора (if-then-else) и операторов выбора (case или switch);

   • opt (option) — вызов дополнительного сообщения (группы сообщений) при некотором условии. Аналогичен фрагменту с типом «alt» для случая, когда используется сокращенный условный оператор (if-then);

   • par (parallel) — параллельная обработка сообщений. Параллельно обрабатываемые сообщения (группы сообщений) отделяются друг от друга горизонтальными штриховыми линиями;

   • loop — циклическая обработка сообщений. Используется для моделирования циклов;

   • break — досрочное прерывание обработки сообщений при некотором условии. Используется как составная часть других фрагментов (как правило, «loop»);

   • critical — эксклюзивно обрабатываемое сообщение (группа сообщений). Используется как составная часть других фрагментов (как правило, «par»). Подразумевает приостановку обработки любых сообщений в более общем фрагменте на время обработки сообщений внутри подфрагмента «critical»;

   • neg (negative) — сообщение или событие, сгенерированное в результате невозможности обработки другого принятого сообщения. Например, если при запросе пароля getPassword() истекло время на его ввод, то вместо возврата пароля будет сгенерировано сообщение «время вышло» (англ. «timeout»);

   • assert (assertion) — сообщение (группа сообщений), выполняемое после предварительной проверки некоторого условия. Если условие отрицательно, то сообщение не посылается. В программировании такой прием часто используется для локализации ошибок;

   • strict — строгая последовательная обработка сообщений. Последовательно обрабатываемые сообщения (группы сообщений) отделяются друг от друга горизонтальными штриховыми линиями и обрабатываются строго по очереди сверху-вниз;

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

   • ignore — игнорирование сообщений. После слова «ignore» в фигурных скобках перечисляются сообщения, возникновение которых во фрагменте потенциально возможно наряду с явно отображенными и которые должны быть проигнорированы;

   • consider — игнорирование других сообщений. После слова «consider» в фигурных скобках перечисляются сообщения, которые явно отображены во фрагменте, а также возникновение которых во фрагменте потенциально возможно наряду с явно отображенными. Остальные потенциально возможные сообщения должны быть проигнорированы;

   • ref (reference) — ссылка на часть взаимодействия, определенную в другом месте (на другой диаграмме). Данный элемент подобен предопределенным процессам на блок-схемах или скрытым составным состояниям на диаграммах автоматов.

Назначение и состав диаграммы коммуникации

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

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

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

При разработке диаграмм следует придерживаться следующих правил и рекомендаций.

1. Для выбранного варианта использования необходимо перенести с диаграммы классов анализа все участвующие в нем классы, а с диаграммы вариантов использования – актеров.

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

3. Для отображения основного и альтернативного потоков событий (наборов сообщений) в рамках варианта использования следует использовать фрагмент с типом «alt».

4. На стадии анализа имена сообщениям можно давать произвольно (например, «Записать данные о клиенте») или в виде стереотипов. В дальнейшем (в модели проектирования) имена сообщений должны соответствовать методам классов.

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

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

Примеры построения диаграмм взаимодействия

На следующем рисунке с помощью диаграммы последовательности показано взаимодействие при выполнении процедуры идентификации/аутентификации пользователя, которая возможна двумя способами: путем ввода имени и пароля или с использованием ID-карты.

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

Пример диаграммы коммуникации

Табличные данные после загрузки заносятся в атрибут data объекта propertyTable, представляющий собой двумерный массив объектов Object[][].

Во взаимодействии участвуют следующие объекты:

• Object – инициирует загрузку данных;
• propertyTable – хранит описание таблицы и ее полей, а также загруженные данные в атрибуте data;
• connectDB – отвечает за установку, поддержку и закрытие соединения с БД;
• statement – выполняет и возвращает результаты запросов к БД.

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

Во взаимодействии следующая последовательность сообщений (вызова методов):

• Object инициирует загрузку данных getData();
• создается соединение с БД в виде объекта connectDB посредством вызова конструктора класса ConnectDB. Созданный объект запоминается в переменной connect;
• создается объект statement для выполнения запросов к БД и запоминается в переменной statement;
• посредством вызова метода checkChangeData() проверяется признак изменения данных на сервере. Если данные изменились, то;
  • из атрибута data объекта propertyTable удаляются старые данные clear();
  • выполняется запрос к БД executeQuere() и запрошенные данные запоминаются в переменной rs;
  • в цикле while() записи из переменной rs переносятся в атрибут data с помощью метода add();
• удаляется объект statement – на диаграмме указано стереотипное сообщение «destroy»;
• закрывается соединение с БД closeConnect().

В качестве иллюстрации правил построения диаграммы последовательности на ней показаны:

• два варианта создания объекта – с помощью конструктора <constructor>() для объекта connectDB и с помощью стереотипного сообщения «create» для объекта statement;
• два варианта уничтожения объекта – с помощью вызова деструктора closeConnect() для объекта connectDB и с помощью стереотипного сообщения «destroy» для объекта statement;
• два варианта вызова методов, возвращающих значения – вызов конструктора объекта connectDB с занесением результата (созданного объекта) в переменную connect с помощью двух сообщений и выполнением запроса к БД executeQuere() с занесением результата в переменную rs с помощью одного сообщения.

Получение товара клиентом (задание с семинара)

Постройте UML-диаграммы ПО, автоматизирующего процесс покупки товара в магазине отделочных материалов с отдельным складом.

Описание процесса: Продавец выписывает клиенту ордер, где указывает код товара, его наименование и количество. Клиент оплачивает в кассе стоимость товара. Для этого кассир должна найти в БД товар по его коду и подсчитать его стоимость. В результате клиент получает кассовый чек и накладную для получения товара на складе и едет на склад. Там он вручает накладную кладовщику, который отыскивает товар по его коду и отпускает клиенту нужное его количество. После этого кладовщик делает отметку в книге учета товаров о том, что товар отпущен и его количество соответственно уменьшилось.

Необходимо построить:

• диаграмму вариантов использования для всей системы;
• диаграмму последовательности для процесса получения товара на складе;
• диаграмму деятельности оплаты заказа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 1.11.
Элементы временной диаграммы

В языке UML существует
четыре вида диаграмм взаимодействия:
диаграмма последовательностей, диаграмма
коммуникации, обзорная диаграмма
взаимодействия и временная диаграмма
(в пособии не рассматривается – рис.
1.11).

Эти типы диаграмм дополняют друг друга,
представляя взаимодействие элементов
системы в динамике, но под различными
углами зрения.

1.6.1.
Диаграмма последовательностей

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

Рис. 1.12.
Пример диаграммы

последовательностей

При построении диаграммы последовательностей
в первую очередь отражается временная
последовательность происходящих
событий. На рис. 1.13 представлен пример
диаграммы последовательностей, которая
имеет два измерения: вертикальное
направление представляет время,
горизонтальное – различные объекты.

Объект (Object) – это
экземпляр класса, конкретная сущность
или образец, он может инициировать
некоторые события, которые могут влиять
на систему. На диаграмме последовательностей
все объекты расположены последовательно
в верхней части диаграммы, за исключением
объектов, создаваемых в результате тех
или иных сообщений (примером последнего
является объект Payment на
рис. 1.14). От каждого объекта вниз отходит
штриховая линия, называемая линией
жизни (Lifeline) объекта.
На ней показывают все, что происходит
с объектом с момента его создания и до
разрушения. Частным случаем объекта
может быть актер, он используется в том
случае, когда необходимо показать связь
участников и прецедентов.

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

Рис. 1.13.
Пример диаграммы последовательностей

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

Управляющая информация может быть
представлена в виде условия, которое
указывает, когда сообщение может быть
передано, либо при помощи маркера
итерации, который показывает, что
сообщение посылается множество раз.
Такая итерация указывается в следующем
виде: *[условие итерации].

В зависимости от типа сообщения оно
изображается при помощи различных
типов линий:

• вызов процедуры или другого потока
  управления (рис.1.14а);

• поток управления (рис. 1.14б) показывает
  направление потока управления и
  последовательности шагов;

• асинхронное стимулирующее воздействие
  (рис.1.14в)

• возврат из процедуры (рис.1.14г)
  используется для того, чтобы показать,
  что каждая процедура возвращает
  управление после своего завершения.
  Обычно стрелка возврата указывается
  только в том случае, если это вносит в
  диаграмму дополнительную ясность.

Рис. 1.14.
Виды стрелок сообщений

В качестве элементов диаграммы
последовательностей могут применяться
т.н. фрагменты взаимодействия
(InteractionFragment), которые по
своим свойствам не отличаются от полного
взаимодействия объектов и позволяют
наглядным образом группировать
последовательности сообщений.

Включение (InteractionUse)
представляет собой ссылку на имеющееся
в модели взаимодействие вместо
копирования последнего на диаграмму,
что поддерживает декомпозицию и
повторное использование отдельных
взаимодействий. Включение обозначается
как фрагмент взаимодействия с оператором
“ref”, содержимое которого
состоит из названия соответствующего
взаимодействия.

Комбинированный фрагмент
(CombinedFragment) представляет
собой выражение над фрагментами
взаимодействия, состоящее из оператора
и операндов – фрагментов взаимодействия.
С каждым операндом может быть связано
сторожевое условие. В языке UML
над фрагментами взаимодействий
определены следующие основные операторы:

• alt – выполняется не
  более одного операнда, для которого
  сторожевое условие истинно;

• opt – необходимость
  выполнения единственного операнда
  определяется его сторожевым условием;

• break – единственный
  операнд выполняется вместо всех
  остальных сообщений в объемлющем
  фрагменте взаимодействия в случае,
  если его сторожевое условие истинно;

• loop – циклическое
  выполнение единственного операнда,
  минимальное и максимальное количество
  итераций указывается в операнде;

• par – параллельное
  выполнение операндов при сохранении
  последовательности сообщений в каждом
  из них;

• strict – строго
  последовательное выполнение операндов;

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

• critical – критический
  участок, операнды выполняются без
  перекрытия во времени с любыми другими
  сообщениями, которые относятся к тем
  же линиям жизни, которые задействованы
  в операндах;

• neg – единственный
  операнд представляет неправильную
  последовательность сообщений;

• assert – операнды
  представляют собой единственные
  допустимые продолжения взаимодействия;

• ignore {} – определяет
  множество сообщений, которые не показаны
  в данном фрагменте и могут быть
  проигнорированы при выполнении
  взаимодействия;

• consider {} – определяет
  множество сообщений, которые должны
  быть приняты во внимание в данном
  фрагменте, все остальные сообщения
  игнорируются.

Три последних оператора позволяют
использовать диаграммы последовательности
не только для спецификации поведения
системы, но и для описания тестов.

На рис. 1.13 приведен пример условного
комбинированного фрагмента alt,
включающего два операнда, для которых
определены необходимые сторожевые
условия.

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

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

1.6.2.
Диаграмма коммуникации

Диаграмма коммуникации (communication
diagram) отображает ту же
информацию, что и диаграмма
последовательностей, но на диаграмме
коммуникации зависимость от времени
указывается посредством нумерации
сообщений. На диаграмме коммуникации
отражается распределение процессов
между объектами и их зависимости друг
от друга, что является очень полезным
при разработке различных проектов.
Основной целью построения данной
диаграммы является понимание структурной
организации занятых в системе объектов,
принимающих и передающих сообщения.
На рис. 1.15 показан пример
диаграммы коммуникации.

Рис. 1.15.
Пример диаграммы коммуникации

В UML применяется десятичная
схема нумерации, её использование
позволяет понять, какая из операций
вызывает другую операцию. Независимо
от нумерации на диаграмме кооперации,
также как и на диаграмме последовательностей,
можно разместить управляющую информацию.

1.6.3.
Обзорная диаграмма взаимодействия

Обзорная диаграмма взаимодействия
(interaction overview
diagram) отражает потоки
управления, возникающие при реализации
некоторого прецедента (см. рис. 1.16).

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

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

Обзорная диаграмма взаимодействия
позволяет альтернативным способом
представить следующие виды комбинированных
фрагментов взаимодействия: фрагменты
alt и opt
заменяются узлом разветвления и парным
ему узлом слияния; фрагмент par
заменяется узлом разделения и парным
ему узлом объединения; фрагмент loop
представляется в виде простого цикла.
В силу этого в рассматриваемых диаграммах
условные и параллельные потоки управления
должны быть строго вложенными.

Рис. 1.17. Элементы обзорной
диаграммы взаимодействия

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #

  06.06.201523.75 Mб22Calligraphy — The Calligrapher’s Bible.pdf

• #
• #
• #
• #
• #
• #

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

Выводы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Из термина «Взаимодействие» ясно, что диаграмма используется для описания некоторого типа взаимодействий между различными элементами в модели. Это взаимодействие является частью динамического поведения системы.

Это интерактивное поведение представлено в UML двумя диаграммами, известными как диаграмма последовательности и диаграмма сотрудничества . Основное назначение обеих диаграмм схожи.

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

Назначение диаграмм взаимодействия

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

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

Целью диаграммы взаимодействия является –

• Чтобы зафиксировать динамическое поведение системы.

• Для описания потока сообщений в системе.

• Для описания структурной организации объектов.

• Для описания взаимодействия между объектами.

Чтобы зафиксировать динамическое поведение системы.

Для описания потока сообщений в системе.

Для описания структурной организации объектов.

Для описания взаимодействия между объектами.

Как нарисовать диаграмму взаимодействия?

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

У нас есть два типа диаграмм взаимодействия в UML. Одна – это диаграмма последовательности, а другая – диаграмма сотрудничества. Диаграмма последовательности фиксирует временную последовательность потока сообщений от одного объекта к другому, а диаграмма сотрудничества описывает организацию объектов в системе, участвующих в потоке сообщений.

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

• Объекты, принимающие участие во взаимодействии.

• Потоки сообщений среди объектов.

• Последовательность, в которой сообщения передаются.

• Организация объекта.

Объекты, принимающие участие во взаимодействии.

Потоки сообщений среди объектов.

Последовательность, в которой сообщения передаются.

Организация объекта.

Ниже приведены две диаграммы взаимодействия, моделирующие систему управления заказами. Первая диаграмма – это диаграмма последовательности, а вторая – диаграмма сотрудничества.

Диаграмма последовательности

Диаграмма последовательности имеет четыре объекта (Customer, Order, SpecialOrder и NormalOrder).

На следующем рисунке показана последовательность сообщений для объекта SpecialOrder, и то же самое можно использовать в случае объекта NormalOrder . Важно понимать временную последовательность потоков сообщений. Поток сообщений – это не что иное, как вызов метода объекта.

Первый вызов – sendOrder (), который является методом объекта Order . Следующий вызов – метод verify (), который является методом объекта SpecialOrder, а последний вызов – Dispatch (), который является методом объекта SpecialOrder . Следующая диаграмма в основном описывает вызовы методов от одного объекта к другому, и это также фактический сценарий, когда система работает.

Диаграмма сотрудничества

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

Вызовы методов аналогичны вызовам диаграмм последовательности. Однако различие в том, что диаграмма последовательности не описывает организацию объекта, тогда как диаграмма сотрудничества показывает организацию объекта.

Чтобы выбрать между этими двумя диаграммами, акцент делается на тип требования. Если временная последовательность важна, тогда используется диаграмма последовательности. Если требуется организация, используется диаграмма сотрудничества.

Где использовать диаграммы взаимодействия?

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

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

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

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

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

Для моделирования потока управления по временной последовательности.

Моделировать поток управления структурными организациями.

Для форвард инжиниринга.

Для реверс-инжиниринга.