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

13.01.202318.01.2023 admin 0 Comments

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

ДИАГРАММЫ ВЗАИМОДЕЙСТВИЯ (ПОСЛЕДОВАТЕЛЬНОСТИ И КОММУНИКАЦИИ)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 13.8. Примеры отображения экземпляров сущностей, линии жизни и символа уничтожения объекта

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

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

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

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

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

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

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

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

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

— «create» (англ. – создать) – возвращающее сообщение, требующее создания объекта;

— «destroy» (англ. – уничтожить) – синхронное сообщение с требованием уничтожить соответствующий объект;

— «call» (англ. – вызвать) – синхронное сообщение, требующее выполнения операции принимающего объекта;

— «send» (англ. – послать) – асинхронное сообщение, обозначающее посылку сигнала серверу;

— «return» (англ. – возвратить) или «reply» (англ. – ответить)– возвращающее сообщение;

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

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

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

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

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

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

Рис. 13.9. Примеры отображения сообщений и фокуса управления

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

Рис. 13.10. Пример отображения фрагмента

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На следующих рисунках показаны диаграммы последовательности и коммуникации, показывающие процесс загрузки данных из таблицы с сервера БД в оперативную память клиента (кэширование). Диаграммы созданы методом обратного проектирования (реинжиниринга) на основе реального программного кода с помощью Case-средства Borland Together Architect 2006 for Eclipse, поддерживающего стандарт UML версии 1.x. Ввиду поддержки старого стандарта на диаграмме последовательности некоторые программные конструкции отображены не с помощью фрагментов, а с помощью вложенных фокусов управления.

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

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

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

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

— Object – инициирует загрузку данных;

— propertyTable – хранит описание таблицы и ее полей, а также загруженные данные в атрибуте data;

— connectDB – отвечает за установку, поддержку и закрытие соединения с БД;

— statement – выполняет и возвращает результаты запросов к БД.

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

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

— Object инициирует загрузку данных getData();

— создается соединение с БД в виде объекта connectDB посредством вызова конструктора класса ConnectDB. Созданный объект запоминается в переменной connect;

— создается объект statement для выполнения запросов к БД и запоминается в переменной statement;

— посредством вызова метода checkChangeData() проверяется признак изменения данных на сервере. Если данные изменились, то;

o из атрибута data объекта propertyTable удаляются старые данные clear();

o выполняется запрос к БД executeQuere() и запрошенные данные запоминаются в переменной rs;

o в цикле while() записи из переменной rs переносятся в атрибут data с помощью метода add();

— удаляется объект statement – на диаграмме указано стереотипное сообщение «destroy»;

— закрывается соединение с БД closeConnect().

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

— два варианта создания объекта – с помощью конструктора () для объекта connectDB и с помощью стереотипного сообщения «create» для объекта statement;

— два варианта уничтожения объекта – с помощью вызова деструктора closeConnect() для объекта connectDB и с помощью стереотипного сообщения «destroy» для объекта statement;

— два варианта вызова методов, возвращающих значения – вызов конструктора объекта connectDB с занесением результата (созданного объекта) в переменную connect с помощью двух сообщений и выполнением запроса к БД executeQuere() с занесением результата в переменную rs с помощью одного сообщения.

Источник

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

1. Диаграммы взаимодействия (interaction diagrams)

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

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

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

Существует два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams).

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

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии (рис. 12.1).

Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.

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

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

Таблица 12.1. Описание кнопок панели инструментов диаграмм взаимодействия Rational Rose

Кнопка

Выбор элемента моделиSekection ToolВвод текстаText BoxКомментарийNoteСвязь комментария с элементомAbchor Note to ItemОбъектObjectСообщениеObject MessageСамоделегированиеMessage to self

Кооперативные диаграммы (collaboration diagrams)

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

Рис. 12.2. Кооперативная диаграмма

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

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

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

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

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

Таблица 12.2. Описание кнопок панели инструментов кооперативных диаграмм Rational Rose

Кнопка

Выбор элемента моделиSekection ToolВвод текстаText BoxКомментарийNoteСвязь комментария с элементомAbchor Note to ItemОбъектObjectПредставитель классаClass InstanseСвязьObject LinkСамоделегированиеLink to selfСообщениеLink MessageОтветReverse Link NessageПоток данныхData Flowобратный поток данныхReverse Date Flow

Пример

На рис. 12.3 и 12.4 приведены диаграммы последовательности модели подсистемы «Служба занятости», показывающие взаимодействие двух классов модели: Студент и БД студентов. На рис. 12.5 и 12.6 то же взаимодействие показано с помощью кооперативных диаграмм.

Найдем численную оценку для каждой из диаграмм.

Рис. 12.3. Диаграмма 1

Диаграмма 1: Так как на диаграмме последовательности связи отсутствуют, проведем расчет по сокращенной формуле:

Диаграмма 2

Рис. 12.5. Диаграмма 2

Рис. 12.5. Диаграмма 3

Теперь рассчитаем оценку для кооперативных диаграмм.
Диаграмма 3

Рис. 12.6. Диаграмма 4

Диаграмма 4

В результате значения для диаграмм 1 и 3 соответствуют оптимальным, для диаграмм 2 и 4 — ниже оптимальных. Это можно объяснить низкой информативностью диаграмм 2 и 4, так как взаимодействие классов показано на них на слишком высоком уровне.