Диаграмма последовательности для чего
Основы UML. Диаграммы последовательности
Диаграммы последовательности ( sequence diagram ) являются видом диаграмм взаимодействия языка UML, которые описывают отношения объектов в различных условиях. Условия взаимодействия задаются сценарием, полученным на этапе разработки диаграмм вариантов использования [1]. Существуют различные взгляды на применение этого вида диаграмм:
Рассмотрим этот вид диаграмм на примере главной последовательности сценария добавления ученика в систему:
Пример: диаграмма последовательности сценария добавления ученика в систему тестирования
По приведенной диаграмме можно проследить следующие правила построения:
Кроме того, на ней показаны три основных вида стрелок (сообщений):
При построении диаграммы последовательности обязанности распределяются между объектами (и классами), например мы решили, что база данных будет выступать в роли модели и уведомлять своих подписчиков об изменениях, однако эту же роль мог выполнить объект экрана добавления студента. Внести изменения в диаграмму значительно проще, чем в исходный код. Буч строит этот вид диаграмм сразу после описания вариантов использования, при этом он решает сразу две задачи — выделяет объекты и распределяет между ними ответственность, однако в процессе ICONIX к диаграммам последовательности переходят после построения диаграмм пригодности, т.е. уже выделены объекты, необходимые для реализации прецедента. Процесс построения при этом сводится к четырем шагам:
В нашем случае на диаграмме был оставлен контроллер, т.е. введен новый управляющий объект отображения уведомления о том, что студент был добавлен в базу. Мы, конечно, могли бы добавить этот функционал в виджет главного меню (наиболее простое решение), введение дополнительного объекта не только является более гибким решением, но и позволит снять с меню лишние обязанности, т.е. сделать код более чистым с точки зрения принципа единой обязанности — SRP [6].
Видно, что приведенная диаграмма очень хорошо отражает взаимодействие объектов, однако прецеденты могут содержать предусловия (требования, которые должны быть выполнены для начала выполнения действий прецедента) — они могут быть показаны при помощи механизма использования взаимодействий. Этот механизм позволяет указать что повторно используется какое-либо взаимодействие, определенное в другом месте, изображается с помощью метки ref. Так, можно показать, что до выполнения прецедента учитель должен войти в систему (выполнить прецедент login) и открыть окно главного меню:
Механизм использования взаимодействий диаграмм последовательности (метка ref)
Фреймы взаимодействия могут использоваться для изображения параллельных секций, при этом часть сообщений рисуются внутри фрейма par, так например, мы могли бы показать, что база данных уведомляет параллельно всех трех подписчиков и все они параллельно и независимо друг от друга начинают работать:
Пример использования фрейма взаимодействия par
Существуют также фреймы для изображения условных конструкций (alt, opt), циклов (loop) и критических секций (critical). Ветвление при этом использовать не рекомендуется, т.к. для изображения деталей алгоритмов в языке UML есть диаграммы деятельности, а Фаулер в таких случаях даже считает также обоснованным использование псевдокода.
Фаулер рекомендует строить диаграммы последовательностей не только при проектировании, но и на этапе рефакторинга если требуется заменить централизованную обработку децентрализованной (более гибкой), т.к. этот вид диаграмм является лучшим способом распределения обязанностей. Также, они часто используются при объяснении каких-либо деталей проекта другим участникам, т.к. этот вид диаграмм быстро строится с нужной степенью детализации на маркерной доске. На следующем примере показан фрейм взаимодействия loop:
Пример использования фрейма loop
На приведенной диаграмме показано взаимодействие процессов — главный процесс (go) после запуска создает дочерний (loop), затем в цикле посылает ему свой идентификатор (self())и некоторое сообщение (Msg). Дочерний процесс отправляет назад сообщение, но уже со своим идентификатором. Внутри части фрейма loop подписывается условие выхода из цикла — в данном случае пересылка сообщений продолжается до тех пор, пока Msg не станет равно «stop». После цикла главный процесс отправляет дочернему сообщение stop, которое является сигналом завершения процесса.
Последний пример показывает, что диаграммы последовательностей удобно использовать не только при проектировании архитектуры приложений, но и для описания взаимодействия процессов/потоков. Визуальное представление в таких случаях гораздо проще воспринимается, чем текстовое описание.
Таким образом, диаграммы вариантов использования могут очень широко применяться при разработке программного обеспечения:
Теория и практика UML. Диаграмма последовательности
В ходе проектирования ИС аналитик поэтапно спускается от общей концепции, через понимание ее логической структуры к наиболее детальным моделям, описывающим физическую реализацию.
С помощь диаграммы прецедентов (вариантов использования) выявляются основные пользователи системы и задачи, которые данная система должна решать. С помощью диаграммы деятельности мы описываем последовательность действий для каждого прецедента, необходимая для достижения поставленной цели.
Далее проектируется логическая структура системы с помощью диаграммы классов. На данном этапе выделяются классы, формирующие структуру БД Системы, а также классы реализующие некий набор операций, способствующий достижению целей в рамках выбранного прецедента. Для описания сложного поведения некоторых объектов (экземпляров класса) составляется диаграмма состояний.
Таким образом, аналитиками фиксируются такие поведенческие аспекты как алгоритм действий в рамках одного или нескольких прецедентов, необходимый для достижения определённого результата, а также изменение состояния объектов в ходе выполнения приведенных действий.
Зачастую на этапе спецификации требований необходимо показать не только алгоритм действий или изменение состояния объекта, но и обмен сообщениями между отдельными объектами Системы. Данную задачу решает диаграмма взаимодействия.
Диаграмма взаимодействия предназначена для моделирования отношений между объектами (ролями, классами, компонентами) Системы в рамках одного прецедента.
Данный вид диаграмм отражает следующие аспекты проектируемой Системы:
В отличие от диаграммы деятельности, которая показывает только последовательность (алгоритм) работы Системы, диаграммы взаимодействия акцентируют внимание разработчиков на сообщениях, инициирующих вызов определенных операций объекта (класса) или являющихся результатом выполнения операции.
Диаграмма последовательности является одной из разновидности диаграмм взаимодействия и предназначена для моделирования взаимодействия объектов Системы во времени, а также обмена сообщениями между ними.
Одним из основных принципов ООП является способ информационного обмена между элементами Системы, выражающийся в отправке и получении сообщений друг от друга. Таким образом, основные понятия диаграммы последовательности связаны с понятием Объект и Сообщение.
На диаграмме последовательности объекты в основном представляю экземпляры класса или сущности, обладающие поведением. В качестве объектов могут выступать пользователи, инициирующие взаимодействие, классы, обладающие поведением в Системе или программные компоненты, а иногда и Системы в целом.
Объекты располагаются с лева на права таким образом, чтобы крайним с лева был тот объект, который инициирует взаимодействие.
Неотъемлемой частью объекта на диаграмме последовательности является линия жизни объекта. Линия жизни показывает время, в течение которого объект существует в Системе. Периоды активности объекта в момент взаимодействия показываются с помощью фокуса управления. Временная шкала на диаграмме направлена сверху вниз.
На диаграммах последовательности допустимо использование стандартных стереотипов класса:
Также одним из основных понятий, связанных с диаграммой последовательности, является Сообщение.
На диаграмме деятельности выделяются сообщения, инициирующие ту или иную деятельность или являющиеся ее следствием. На диаграмме состояний частично показан обмен сообщениями в рамках сообщений инициирующих изменение состояния объекта.
Диаграмма последовательности объединяет диаграмму деятельности, диаграмму состояний и диаграмму классов.
Таким образом, на диаграмме последовательности мы можем увидеть следующие аспекты:
Итак, прием сообщения инициирует выполнение определенных действий, направленных на решение отдельной задачи тем объектом, которому это сообщение отправлено. Сообщение в большинстве случаев (за исключением диаграмм, описывающих концептуальный уровень Системы) это вызов методов отдельных объектов, поэтому для корректного исполнения метода в сообщении необходимо передать какие-то данные и определить, что мы хотим видеть в ответ. При именовании сообщения на уровне проектирования реализации системы в качестве имени сообщения следует использовать имя метода.
В UML различают следующие виды сообщений:
Для сообщений также доступен ряд предопределенных стереотипов. Наиболее часто используемые стереотипы это create и destroy.
Сообщение со стереотипом create, вызывает в классе метод, которые создает экземпляр класса. На диаграмме последовательности не обязательно показывать с самого начала все объекты, участвующие во взаимодействии. При использовании сообщения со стереотипом create, создаваемый объект отображается на уровне конца сообщения.
Для уничтожения экземпляра класса используется сообщение со стереотипом destroy, при этом в конце линии жизни объекта отображаются две перекрещенные линии.
При отображении работы с сообщениями иногда возникает необходимость указать некоторые временные ограничения. Например, длительность передачи сообщения или ожидание ответа от объекта не должно превышать определенный временной интервал. Можно указать следующие временные параметры:
Форма заказа передает данные Менеджеру заказа, при этом передача данных не должна длиться больше 30 сек. – данное ограничение может понадобиться при выявлении требований к быстродействию Системы. Далее получение данных с формы инициирует запуск метода для создания экземпляра класса Заказ. Между получением данных от Формы заказа и инициализацией создания объекта должно пройти не более 30 сек., в противном случае пользователю может быть предоставлено сообщение об ошибке или недоступности сервера. Длительность передачи сообщения о создании объекта может быть зафиксирована в переменной d.
Данное значение может понадобиться при установке временного ограничения на получение ответного сообщения клиентом. В момент передачи сообщения фиксируется временное значение и заносится в переменную t. Таким образом, можно установить ограничение на стороне приемника, указав переменную t в качестве минимального значения и t+ в качестве максимального значения.
До появления UML 2.0 диаграмма последовательности рассматривалась только в рамках моделирования последовательности обмена сообщениями. Расширение сценария отображались с помощью ветвления линий сообщений, что не давало полной картины взаимодействия объектов. Таким образом, для целей моделирования расширения сценария, параллельности процессов или цикличности использовались диаграммы деятельности. Для решения данных задач в UML 2.0 было введено понятие фрейма взаимодействия и операторов взаимодействия.
Отдельные фрагменты диаграммы взаимодействия можно выделить с помощью фрейма. Фрейм должен содержать метку оператора взаимодействия. UML содержит следующие операнды:
При использовании фрагмента условного операнда фрейм должен содержать условие для ограничения взаимодействия. При использовании условного или параллельного операнда фрейм делится на регионы взаимодействия с помощью разделителя операторов взаимодействия.
К условным операндам относятся alt и opt. Операнд alt используется при моделировании расширения сценария, т.е. при наличии альтернативного потока взаимодействия. Оператор opt используется, если сообщение должно быть передано, только при истинности какого-то условия. Данный фрейм используется без разделения на регионы.
Параллельность потоков взаимодействия можно изобразить с помощью операнда par. Внутри фрейма моделируются потоки взаимодействия в отдельных регионах.
Цикличность потока взаимодействия может быть представлена на диаграмме последовательности с помощью операнда loop. При использовании оператора цикла можно указать минимальное и максимальное число итераций. Также фрейм должен содержать условие, при наступлении которого взаимодействие повторяется.
Диаграммы последовательности предназначены для моделирования взаимодействия между несколькими объектами. Зачастую диаграммы последовательности создаются для моделирования взаимодействия в рамках одного прецедента.
На концептуальном уровне можно использовать диаграммы последовательности для моделирования взаимодействия между Бизнес-актерами, но зачастую подобные диаграммы обрастают лишними подробностями и плохо читаются. На данном уровне лучше подойдут диаграммы деятельности, исключение составляют случае, когда необходимо смоделировать обмен сообщениями между двумя независимыми Системами.
Также диаграммы последовательности подойдут для моделирования взаимодействия пользователя и Системы в целом.
На уровне детальной спецификации требований диаграммы последовательности используются для моделирования взаимодействия компонентов Системы и пользовательских классов в рамках выбранного прецедента.
На уровне реализации с помощью диаграммы последовательности моделируется взаимодействие между отдельными компонентами Системы. На данном уровне детализации лучше подойдет диаграмма коммуникации.
Статья подготовлена с использованием материалов:
Диаграмма последовательности UML
Диаграмма последовательности UML
Для чего используется метод проектирования
Изобразить участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются.
План действий
В разделе «Описание» изучите основной набор символов диаграммы последовательности, необходимый для того, чтобы уметь читать диаграммы.
После ознакомления с другими разделами («Пример», «Применение») вы можете попробовать свои силы в самостоятельном составлении диаграмм последовательности.
Замечания (описание)
Здесь представлен основной набор символов диаграммы последовательности, необходимый для того, чтобы суметь прочитать диаграмму. После ознакомления с другими разделами («Пример», «Применение») вы сможете составлять диаграммы последовательности самостоятельно!
| Термин | Изображение | Описание |
|---|---|---|
| Найденное сообщение |  | У первого сообщения нет участника, пославшего его, поскольку оно приходит из неизвестного источника. Оно называется найденным сообщением (found message). |
| Сообщение |  | Команда, отправляемая другому участнику. Может содержать только передаваемые данные. |
| Линия жизни |  | Каждая линия жизни имеет полосу активности, которая показывает интервал активности участника при взаимодействии. Она соответству ет времени нахождения в стеке одного из методов участника. В языке UML полосы активности не обязательны, но я считаю их исключительно удобными при пояснении поведения. |
| Участник |  | В большинстве случаев можно считать участников диаграммы взаимодействия объектами, как это и было в действительности в UML 1. Но в UML 2 их роль значительно сложнее. Поэтому здесь употребляется термин участники (participants), который формально не входит в спецификацию UML. |
| Самовызов |  | Участник отправляет сообщение (команду) самому себе. |
| Возврат |  | Передача управления обратно участнику, который до этого инициировал сообщение. |
| Активация |  | На изображении это — белый вертикальный прямоугольник. Момент, когда участник начинает действовать в ответ на принятое сообщение. |
| Создание |  | В случае создания участника надо нарисовать стрелку сообщения, на правленную к прямоугольнику участника. Если применяется конст руктор, то имя сообщения не обязательно, но можно маркировать его словом «new» в любом случае. Если участник выполняет что- нибудь непосредственно после создания, например команду запроса, то надо начать активацию сразу после прямоугольника участника. |
| Самоудаление |  | Удаление участника обозначается большим крестом (X). X в конце линии жизни показывает, что участник удаля ет сам себя. |
| Удаление из другого объекта |  | Удаление участника обозначается большим крестом (X). Стрелка сооб щения, идущая в X, означает, что один участник явным образом уда ляет другого. |
| Фреймы взаимодействия |  |
Как применять технику креативности
Диаграммы последовательности следует применять тогда, когда требуется посмотреть на поведение нескольких объектов в рамках одного прецедента. Диаграммы последовательности хороши для представления взаимодействия объектов, но не очень подходят для точного определения поведения.
Если вы хотите посмотреть на поведение одного объекта в нескольких прецедентах, то примените диаграмму состояния. Если же надо изучить поведение нескольких объектов в нескольких прецедентах или потоках, не забудьте о диаграмме деятельности.
Если требуется быстро исследовать несколько вариантов взаимодействия, лучше использовать CRC-карточки, поскольку это позволяет избежать непрерывного рисования и стирания. Часто бывает удобно поработать с CRC-карточками для просмотра вариантов взаимодействия, а затем с помощью диаграмм взаимодействий фиксировать те взаимодействия, которые будут применяться позже.
Другим полезным видом диаграмм взаимодействий являются коммуникационные диаграммы, которые показывают соединения, и временные диаграммы, показывающие временные интервалы.
CRC-карточки
Одним из наиболее полезных приемов, соответствующих хорошему стилю ООП, является исследование взаимодействия объектов, поскольку его цель состоит в том, чтобы исследовать работу программы, а не данные. CRC-диаграммы (Class-Responsibility-Collaboration, класс-обязанность-кооперация), придуманные Уордом Каннингемом (Ward Cunningham) в конце 80-х годов, выдержали проверку временем и стали высокоэффективным инструментом решения этой задачи (рис. 4.6). И хотя они не входят в состав UML, все же являются очень популярными среди высококвалифицированных разработчиков в области объектных технологий.
Для использования CRC-карточек вы и ваши коллеги должны собраться за столом. Возьмите различные сценарии и проиграйте их с помощью карточек, поднимая их над столом, в то время когда они активны, и передавая их по кругу в предположении, что они посылают сообщение. Эту технологию почти невозможно описать в книге, но легко продемонстрировать; лучший способ научиться этому состоит в том, чтобы попросить кого-нибудь, кто имеет такой опыт, показать вам это
Важным моментом в CRC-методике является определение ответственностей. Ответственность (responsibility) – это краткое описание того, что объект должен делать: операция, которую выполняет объект, некоторый объем знаний, который объект поддерживает, или какие-либо важные решения, принимаемые объектом. Идея состоит в том, чтобы вы могли взять любой класс и сформулировать его разумно ограниченные обязанности. Такой образ действия поможет вам яснее представить себе архитектуру классов.
Вторая буква «С» (в CRC) означает взаимодействие (collaboration): другие классы, с которыми должен работать рассматриваемый класс. Это дает вам некоторое представление о связях между классами, но все еще на высоком уровне.
Одно из главных преимуществ CRC-карточек состоит в том, что они способствуют живому обсуждению проектов в среде разработчиков. Если в процессе работы над шаблоном поведения вы хотите посмотреть, как классы его реализуют, то вычерчивание диаграмм взаимодействия, описанных в этой главе, может занять слишком много времени. Обычно требуется просмотреть варианты, а рисование и стирание вариантов на диаграммах может быть очень утомительным. С помощью CRC-карточек разработчики моделируют взаимодействие, поднимая карточки и передавая их по кругу. Это позволяет быстро просчитать варианты.
В процессе работы вы создаете представление об ответственностях и записываете их на карточки. Размышления об ответственностях важны, поскольку рассеивают представление о классах как о бессловесных хранителях данных и помогают членам команды лучше понять поведение каждого класса на высшем уровне. Ответственность может соответствовать операции, атрибуту или, что более точно, неограниченной группе атрибутов и операций.
Опыт показывает, что распространенной ошибкой разработчиков является создание ими длинных списков низкоуровневых ответственностей. Это приводит к непониманию сути. Ответственности должны свободно помещаться на одной карточке. Спросите себя, следует ли разделить класс или лучше отрегулировать ответственности, переместив их на более высокий уровень операторов.
Многие разработчики подчеркивают важность ролевой игры, когда каждый член команды играет роль одного или нескольких классов.
Как научиться
Здесь мы попытались предоставить как можно более простой способ изучения диаграммы последовательности языка UML.
Как и многие другие языки он использует для описания набор знаков. Смысл этих знаков вы найдете в таблице в разделе «Замечания (описание)». Каждый знак имеет свое наименование (термин) и написание. Также каждый термин снабжен кратким пояснением, чтобы быстро уяснить его основную суть.
Далее мы бы рекомендовали перейти в раздел «Пример», чтобы попробовать свои силы в чтении разных диаграмм. Затем стоит изучить раздел «Применение», так как, хотя и количество типов диаграмм в UML невелико, максимум преимуществ от их использования вы сможете получить только если будете применять нужные диаграммы по назначению.
Пример использования
Для того чтобы начать обсуждение метода «Диаграмма последовательности» UML (ЮМЛ), рассмотрим простой сценарий.
Предположим, что у нас есть заказ, и мы собираемся вызвать команду для определения его стоимости. При этом объекту заказа (Order) необ ходимо просмотреть все позиции заказа (Line Items) и определить их цены, основанные на правилах построения цены продукции в строке заказа (Order Line). Проделав это для всех позиций заказа, объект за каза должен вычислить общую скидку, которая определяется индиви дуально для каждого клиента.
На рис. 4.1 приведена диаграмма, представляющая реализацию дан ного сценария. Диаграммы последовательности показывают взаимо действие, представляя каждого участника вместе с его линией жизни (lifeline), которая идет вертикально вниз и упорядочивает сообщения на странице; сообщения также следует читать сверху вниз.
Одно из преимуществ диаграммы последовательности заключается в том, что почти не придется объяснять ее нотацию. Можно видеть, что экземпляр заказа посылает строке заказа сообщения getQuantity и getProduct. Можно также видеть, как заказ применяет метод к самому себе и как этот метод посылает сообщение getDiscountInfo экземпляру клиента.
Однако диаграмма не все показывает так хорошо. Последовательность сообщений getQuantity, getProduct, getPricingDetails и calculateBasePrice должна быть реализована для каждой строки заказа, тогда как метод calculateDiscounts вызывается лишь однажды.
На приведенной диаграмме именовали участников, используя стиль anOrder. В большинстве случаев это вполне приемлемо. Вот более полный синтаксис: имя : Класс, где и имя, и класс не обязательны, но если класс используется, то двоеточие должно присутствовать.
Каждая линия жизни имеет полосу активности, которая показывает интервал активности участника при взаимодействии. Она соответствует времени нахождения в стеке одного из методов участника. В языке UML полосы активности не обязательны.
У первого сообщения нет участника, пославшего его, поскольку оно приходит из неизвестного источника. Оно называется найденным со общением (found message).
Создание и удаление участников
В диаграммах последовательности для создания и удаления участников применяются некоторые дополнительные обозначения (рис. 4.3).
Удаление участника обозначается большим крестом (X). Стрелка сообщения, идущая в X, означает, что один участник явным образом удаляет другого; X в конце линии жизни показывает, что участник удаляет сам себя.
Диаграмма последовательности: циклы, условия и тому подобное
Общая проблема диаграмм последовательности заключается в том, как отображать циклы и условные конструкции. Прежде всего надо усвоить, что диаграммы последовательности для этого не предназначены. Подобные управляющие структуры лучше показывать с помощью диаграммы деятельности или собственно кода. Диаграммы последовательности применяются для визуализации процесса взаимодействия объектов, а не как средство моделирования алгоритма управления.
В основном фреймы состоят из некоторой области диаграммы последовательности, разделенной на несколько фрагментов. Каждый фрейм имеет оператор, а каждый фрагмент может иметь защиту. (В табл. 4.1 перечислены общепринятые операторы для фреймов взаимодействия.)
Для отображения цикла применяется оператор loop с единственным фрагментом, а тело итерации помещается в защиту. Для условной логики можно использовать оператор alt и помещать условие в каждый фрагмент. Будет выполнен только тот фрагмент, защита которого имеет истинное значение. Для единственной области существует оператор opt.
Подписывайтесь на новости сайта, форму подписки вы можете найти в правой колонке сайта.
Если вы хотите научиться работать на фрилансе профессионально, приглашаем на курс «Как зарабатывать на фрилансе».