Для чего нужна диаграмма взаимодействия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

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, так как взаимодействие классов показано на них на слишком высоком уровне.

Упражнения

Упражнение 1. Создание диаграмм взаимодействия

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

Добавление на диаграмму действующего лица, объектов и сообщений:

Соотнесение сообщений с операциями

Создание примечаний

Для того чтобы поместить на диаграмму примечание:

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

Для того чтобы поместить на диаграмму текстовую область:

Создание кооперативной диаграммы

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

Так, диаграмма классов VOPC (classes only) после построения диаграмм взаимодействия в упражнении будет похожа на диаграмму приведенную на рис. 12.12.

Рис 12.12

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

Источник

Что находится между идеей и кодом? Обзор 14 диаграмм UML

Тебе пришла крутая идея продукта, но ты не хочешь увязнуть в коде и потерять целостную картинку из-за мелких деталей? Ты вот-вот присядешь за то, что крякнул корпоративный сервер и тебе нужно набить что-то крутое и айтишное?

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

UML — это сокращение от Unified Modeling Language, и, как мы знаем, он является стандартизированным языком моделирования, состоящим из интегрированного набора диаграмм, разработанных, чтобы помочь разработчикам систем и программного обеспечения в определении, визуализации, конструировании и документировании артефактов программных систем, а также, к примеру, для бизнес-моделирования.

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

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

Происхождение UML

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

UML не возник на пустом месте, ему предшествовали несколько значимых событий, личностей и методологий. Например:

К 1995 году создатель OOSE, Ивар Якобсон, также присоединился к Rational, и его идеи (в частности, концепция «прецедентов») были включены в новый унифицированный метод, который теперь называется Unified Modeling Language.

В противовес всем известной “Банде Четырех”, Команда Румбо, Буча и Якобсона известна как «Три Амигоса».

На UML также повлияли другие объектно-ориентированные нотации:

Почему UML?

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

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

Компании также ищут методы для управления сложностью систем по мере увеличения их масштаба.

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

Кроме того, разработка под Web хоть и упрощает некоторые вещи, в целом, она усугубляет эти архитектурные проблемы.

Унифицированный язык моделирования (UML) был разработан для удовлетворения этих потребностей.

Основные цели дизайна UML:

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

Диаграмма классов

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

Три наиболее важных типа отношений в диаграммах классов (на самом деле их больше), это:

Ассоциация, которая представляет отношения между экземплярами типов, к примеру, человек работает на компанию, у компании есть несколько офисов.

Наследование, которое имеет непосредственное соответствие наследованию в Объектно-Ориентированном дизайне.

Агрегация, которая представляет из себя форму композиции объектов в объектно-ориентированном дизайне.

Диаграмма компонентов

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

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

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

Диаграмма развертывания

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

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

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

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

Диаграмма объектов

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

Тем не менее, диаграмма объекта представляет собой экземпляр в конкретный момент, который имеет конкретный характер.Использование диаграмм объектов довольно ограничено, а именно — чтобы показать примеры структуры данных.

Диаграмма пакетов

Диаграмма пакетов — это структурная схема UML, которая показывает пакеты и зависимости между ними.

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

Диаграмма составной структуры

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

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

Диаграмма профилей

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

Диаграмма прецедентов

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

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

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

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

Диаграмма состояний

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

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

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

Диаграмма Коммуникации

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

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

Диаграмма обзора взаимодействий фокусируется на обзоре потока управления взаимодействиями. Это вариант Диаграммы деятельности, где узлами являются взаимодействия или события взаимодействия. Диаграмма обзора взаимодействий описывает взаимодействия, в которых сообщения и линии жизни скрыты. Мы можем связать «реальные» диаграммы и добиться высокой степени навигации между диаграммами внутри диаграммы обзора взаимодействия.

Временная диаграмма

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

Зачем в UML столько диаграмм?

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

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

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

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

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

Источник