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

Уточняем описание функций системы с помощью диаграммы Sequence

Уточняем описание функций системы с помощью диаграммы Sequence (продолжение «Белки»)

В данной статье рассмотрим, как можно детализировать (уточнить) описание автоматизируемой функции с помощью UML Sequence Diagram — диаграммы последовательности.

В данном примере я использую среду Enterprise Architect от австралийской компании Sparx Systems [1].
Полную спецификацию UML см. здесь [2].

Для начала поясню, что мы будем детализировать.
В 1-ой части статьи «От моделирования процессов к проектированию автоматизированной системы» мы моделировали процессы «сказочной» предметной области — строчки про белку из «Сказки о царе Салтане» А.С.Пушкина. И начали мы с диаграммы Activity. Потом во 2-ой части мы разработали функциональную модель с помощью диаграммы Use-case, на Рисунке 1 представлен фрагмент.

Рисунок 1. Связь требования и функции

Теперь мы хотим уточнить информацию о выполнении данной автоматизируемой функции:

Основными элементами диаграммы Sequence являются взаимодействующие объекты с различными стереотипами и связи между ними — взаимодействующие объекты обмениваются между собой некоторой информацией (Рисунок 2).

Рисунок 2. Основные элементы Sequence диаграммы

Объекты расположены в горизонтальной последовательности, между ними передаются сообщения. Ось времени ориентирована сверху вниз.
Элемент Actor может использоваться для представления пользователя, инициирующего поток событий.
Каждый объект имеет пунктирную линию, называемую «линией жизни», где этот элемент существует и потенциально принимает участие во взаимодействиях. Фокус управления обозначается прямоугольником на линии жизни объекта.
Сообщения, которыми обмениваются объекты, могут быть нескольких типов, сообщения также могут быть настроены для отражения операций и свойств исходного и целевого элементов.
Стереотипные элементы, такие как границы (Boundary), элементы управления (Control) и сущности (Entity), могут использоваться для моделирования пользовательского интерфейса (GUI), контроллеров и элементов базы данных, соответственно.
Повторяющийся поток обмена сообщениями может быть обозначен как фрагмент с типом «loop».

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

Диаграмма, построенная с учетом этих допущений, приведена на Рисунке 4.

Рисунок 4. Уточнение описания функции «Добавить в ведомость информацию о новом орехе»

О применении других видов диаграмм UML можно почитать здесь:

Источник

Основы 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, которое является сигналом завершения процесса.

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

Таким образом, диаграммы вариантов использования могут очень широко применяться при разработке программного обеспечения:

Источник

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

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

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

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

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

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

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

Объекты

Объект изображается в виде вертикального штрихового пунктира («генеральная линия»). Генеральная линия указывает на существование объекта в определенное время. Символ объекта рисуется в начале генеральной линии. Имя объекта и его класс выделяются подчеркиванием и разделяются двоеточием:

В диаграмме последовательности объекты можно использовать следующим образом:

Субъекты

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

Сообщения

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

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

Сценарии

Сценарий содержит текстуальное описание потока событий.

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

Распределение управляющего потока в диаграмме последовательности

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

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

Поведение варианта использования Печать ежедневного отчета сосредоточено в объекте Генератор отчетов.

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

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

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

Поведение варианта использования Отправка письма децентрализованное.

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

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

Потоку событий с централизованным управлением соответствует «вилообразная» диаграмма последовательности. Потоку событий с децентрализованным управлением соответствует прямолинейная диаграмма последовательности.

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

Децентрализованная структура подходит для следующих случаев:

Централизованная структура подходит для следующих случаев:

© Copyright IBM Corp. 1987, 2006. Все права защищены..

Источник

Теория и практика 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. При использовании оператора цикла можно указать минимальное и максимальное число итераций. Также фрейм должен содержать условие, при наступлении которого взаимодействие повторяется.

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

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

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

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

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

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

Источник