Как составить диаграмму последовательностей в uml

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

Постановка задачи: описание бизнес-процесса

Предположим, пользователь – посетитель сайта хочет купить курс по бизнес-анализу и оплатить его онлайн банковской картой. При этом он может получить скидку, применив промокод. Промокод действует только на определенный курс и ограничен по времени. Данные о промокоде хранятся в СУБД Учебного Центра (УЦ): сам промокод, курс, на который он распространяется, размер скидки, срок действия (дата валидности) и состояние (новый, выдан, использован, истек). Сам процесс оплаты, т.е. непосредственного списания денег с банковской карты выполняется на стороне банковского платежного шлюза. Выполняемую при этом последовательность шагов можно упрощенно представить следующим образом:

1. пользователь выбирает курс по бизнес-анализу и нажимает кнопку «Купить»;
2. открывается страница оплаты курса на сайте учебного центра с формой договора покупки курса и чек-боксом о наличии промокода;
3. пользователь вводит свои данные в форму договора покупки курса;
4. пользователь отмечает наличие промокода в чек-боксе;
5. открывается поле ввода промокода и кнопка проверки его валидности;
6. пользователь вводит промкод;
7. пользователь проверяет его валидность, кликнув на кнопку «Проверить»;
8. выполняется проверка валидности промокода с учетом данных по нему, которые имеются в СУБД УЦ.
9. Если промокод валиден (т.е. привязан к выбранному курсу и дата действия его еще не истекла) и находится в состоянии «выдан», цена курса меняется с учетом скидки по промокоду. Иначе цена курса остается прежней и пользователю показывается сообщение о невозможности применить этот код по одной из следующих причин: уже использован, не применим к выбранному курсу или закончился срок его действия.
10. соглашаясь с ценой (пересчитанной или прежней), пользователь нажимает кнопку «Оплатить». При этом в сторону платежного шлюза посылается запрос со всеми параметрами заказа, где сумма списания равна итоговой цене, рассчитанной с учетом скидки по промокоду, если ее удалось применить.
11. открывается веб-страница платежного шлюза с формой ввода данных банковской карты пользователя и суммой списания;
12. пользователь вводит реквизиты своей банковской карты и нажимает кнопку «Оплатить». При этом на сервер банка в систему «Антифрод» отправляются детали заказа и данные карты, чтобы проверить заказ на мошенничество.
13. в платёжный шлюз возвращаются результаты проверки заказа на мошенничество. Если заказ признан мошенническим, оплата отклоняется и платеж считается неуспешным. Иначе платёжный шлюз списывает деньги со счёта клиента.
14. Платёжный шлюз возвращает сайту УЦ статус платежа (успешный или неуспешный).
15. На странице оплату сайта УЦ отображается статус платежа.
16. При успешном платеже в СУБД УЦ меняется состояние промокода на «Использован».

Хотя при проектировании систем не рекомендуется включать в описание бизнес-процессов детали интерфейса, для простоты и наглядности рассматриваемого примера, мы нарушим это правило. Теперь рассмотрим, как данное текстовое описание последовательности шагов показать в виде UML-диаграммы последовательности. Кстати, проверить свои знания UML вы можете прямо на нашем сайте, выполнив бесплатный интерактивный тест. А посмотреть, как строить другие виды UML-диаграмм (классов, состояний и вариантов и использования), можно в этой статье.

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

Итак, в UML-диаграмме описанной последовательности будут участвовать объекты:

• Пользователь;
• страница оплаты сайта учебного центра (Сайт УЦ);
• СУБД УЦ;
• Платежный шлюз;
• Антифрод-система.

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

Из-за ответных сообщений их общее количество больше, чем в текстовой последовательности шагов, описанной ранее. Для простоты рассматриваемого примера здесь не показан опциональный сценарий применения защищенной технологии 3D-secure.

Таким образом, UML-диаграмма последовательности позволяет достаточно наглядно показать взаимодействие между разными объектами, детализируя какими сигналами прямыми и ответными они обмениваются. Чаще всего это требуется для иллюстрации интерактивного взаимодействия между разными сервисами или объектами одной системы, например, когда при регистрации клиентского обращения запускается задача ответственному сотруднику на его обработку. Более детально разобраться с sequence-диаграммой и другими моделями UML вам поможет специализированный курс «UML для бизнес-аналитика».

В рамках плотного 8-часового курса вы познакомитесь с основными возможностями и примерами практического использования UML, чтобы научиться понимать смысл диаграмм и уметь самостоятельно разрабатывать их. За 1 день изучения этого метода моделирования процессов и проектирования систем начинающий аналитик перестанет бояться UML и сможет применять на практике. После обучения вы будете способны дополнять текстовые схемы представления требований User Story и Use Case схемами UML вариантов использования и детализировать их далее в диаграммы деятельности, последовательности и состояний, чтобы наглядно объяснить разработчикам, что именно должна делать программная система.

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

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

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

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

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

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

Объекты

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

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

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

Контроллеры (Control) обрабатывают запросы и управляют потоком данных в системе. Они представляют собой узлы, через которые проходят данные и управляющие выполнением операций в системе. Например, контроллер может обрабатывать запросы, которые поступают от акторов и возвращать результаты.

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

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

Линии жизни

Линия жизни (lifeline) — это вертикальная линия на диаграмме последовательности UML, которая представляет объект или участника взаимодействия и связывает его с сообщениями во времени. Линия жизни начинается с появления объекта на диаграмме и продолжается до его удаления или окончания взаимодействия.

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

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

Сообщения

Мгновенные и не мгновенные сообщения

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

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

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

Синхронные и асинхронные сообщения

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

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

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

Активации

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

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

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

Фреймы

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

Фрейм Alt

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

Блок альтернативы представляет собой условный блок, содержащий один или несколько сообщений. Каждый блок альтернативы имеет свое условие, которое должно быть истинным для того, чтобы блок выполнился. Если условие блока не истинно, то блок пропускается.

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

Фрейм Opt

Фрейм opt (от «optional», на русском «необязательный») — позволяет указать, что определенные сообщения являются необязательными. Таким образом, если условие выполняется, то сообщение отправляется, а если нет, то сообщение не отправляется.

Фрейм opt используется, когда выполнение какой-то части последовательности необязательно и может быть пропущено, если не выполняется определенное условие. Например, процесс покупки товара онлайн,он может использоваться для отображения условия наличия купона на скидку. Если купон есть, то будет отправлено сообщение для применения скидки, а если нет, то этот шаг может быть пропущен.

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

Фрейм Loop

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

Ключевое слово «loop» указывает на начало цикла, а «end loop» — на его конец. Условие, которое указывается в квадратных скобках, определяет, когда цикл должен завершиться.

Фрейм «loop» отображается в виде прямоугольника, внутри которого располагается последовательность действий, которые должны быть выполнены в рамках цикла. В верхней части прямоугольника указывается условие завершения цикла.

Фрейм Par

Фрейм par (parallel) используется на диаграммах для отображения параллельных процессов, которые происходят одновременно и независимо друг от друга. Он позволяет разделять диаграмму на несколько потоков выполнения, которые могут выполняться параллельно.

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

Фрейм Neg

Фрейм neg (или Negative Frame) на диаграмме используется для представления альтернативной сценарной ветки, которая не должна происходить в системе. То есть он используется для описания ошибок или невозможных сценариев.

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

Фрейм Ref

На диаграмме фрейм Ref (Reference) используется для ссылки на другую диаграмму или фрагмент кода, который описывает детали процесса внутри данного фрейма. Он позволяет вынести подробную информацию на отдельную диаграмму, упрощая основную диаграмму и делая её более читабельной.

Фрейм SD

На диаграмме последовательности фрейм SD (Sequence Diagram) позволяет очертить всю диаграмму и указать ее имя. Обычно используется если на диаграмму ссылается другая диаграмма.

Комментарии

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

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

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

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

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

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

Перед началом построения диаграммы важно подготовить сценарии использования. Как составить качественные сценарии использования (Use Case) я уже рассказывал в прошлой статье. Далее следует определить объекты или агенты, которые будут участвовать в процессе. Затем необходимо написать подробное описание того, что происходит в конкретном сценарии использования. На основе этого описания можно выявить взаимодействия, которые будут происходить в системе.

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

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

Распространенные ошибки в диаграммах последовательностей

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

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

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

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

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

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

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

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

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

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

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

В этом учебном пособии по последовательной диаграмме вы узнаете об этом;

• Что такое диаграмма последовательности
• Обозначения диаграмм последовательности
• Диаграмма последовательностей Лучшие практики
• Как нарисовать схему последовательности
• Распространенные ошибки в диаграммах последовательностей
• Шаблоны и примеры схем последовательностей
• Презентация SlideShare с диаграммой последовательности
• Отзыв о Руководстве по диаграммам последовательностей

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

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

Проще говоря, диаграмма последовательности показывает различные части работы системы в “последовательности”, чтобы что-то сделать.

Обозначения диаграмм последовательности

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

Краткий обзор различных частей диаграммы последовательности

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

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

Линия жизни с элементом-субъектом представляет системные данные. Например, в приложении “Обслуживание клиентов” организация-заказчик будет управлять всеми данными, относящимися к клиенту.

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

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

Бары активации

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

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

Стрелки сообщений

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

Стрелка сообщения содержит описание, известное как подпись сообщения. Формат подписи этого сообщения приведен ниже. Все части, кроме имени_сообщения, являются необязательными.

Атрибут = имя_сообщения (аргументы): return_type

• Синхронное сообщение

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

• Aсинхронное сообщение

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

• Вернуться сообщение

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

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

• Сообщение о создании участника

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

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

• Сообщение об уничтожении участника

Аналогичным образом, участники, которые больше не нужны, могут быть удалены из схемы последовательности. Это делается путем добавления буквы “Х” в конце спасательной линии указанного участника.

• Рефлексивное сообщение

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

Комментарий

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

Примечание: Просмотрите “Лучшие методы работы с диаграммой последовательностей”, чтобы узнать о фрагментах последовательностей.

Диаграмма последовательностей Лучшие практики

• Управление сложными взаимодействиями с фрагментами последовательности

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

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

Альтернативы

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

Альтернативный фрагмент представляет собой большой прямоугольник или кадр, который задается упоминанием ‘alt’ в окошке с названием кадра (так называемый оператор фрагмента).

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

Варианты

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

Как и альтернативный фрагмент, фрагмент опции также представлен прямоугольной рамкой, в которой в окошке с названием помещается ‘opt’.

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

(Найдите пример диаграммы последовательности с фрагментом опции в разделе Шаблоны и примеры последовательностей).

Loops

Loop фрагмент используется для представления повторяющейся последовательности. Поместите слова “петля” в поле с названием и состояние защиты в верхнем левом углу рамы.

В дополнение к Булеву тесту, защитный кожух в фрагменте петли может иметь два других специальных условия, с которыми он тестируется. Это минимальные (записанные как minint = [число] и максимальные (записанные как maxint = [число])).

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

(Пример фрагмента цикла приведен ниже в шаблонах последовательных диаграмм и разделе с примерами)

Справочный фрагмент

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

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

Для получения дополнительных фрагментов последовательностей обратитесь к Основам диаграмм последовательностей: Часть 1, Часть 2 и Часть 3.

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

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

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

Как нарисовать схему последовательности

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

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

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

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

• Библиотекарь
• Система управления онлайн-библиотекой
• База данных учетных данных пользователей
• Система электронной почты

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

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

• Библиотекарь просит систему создать новую онлайновую библиотечную учетную запись
• Затем библиотекарь выбирает тип учетной записи пользователя библиотеки
• Библиотекарь вводит данные пользователя
• Детали пользователя проверяются с помощью базы данных Credentials Database
• Создана учетная запись пользователя новой библиотеки
• После этого по электронной почте пользователю отправляется краткая информация о новой учетной записи

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

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

Распространенные ошибки в диаграммах последовательностей

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

• Слишком много деталей. Это загромождает диаграмму и затрудняет чтение.

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

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

• Тщательно не учитывая происхождение стрелок сообщений.

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

Примеры и шаблоны схем последовательностей

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

Система онлайн-экзаменов – Схема последовательности

Схема последовательности Пример системы управления школой

Пример фрагмента комбинации опций

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

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

Учебное пособие по диаграммам последовательности – презентация SlideShare

Обратная связь по учебному пособию “Схема последовательности”

Данное учебное пособие по последовательным схемам охватывает все, что необходимо знать на последовательных схемах и их построении. Если у Вас есть какие-либо предложения или вопросы касательно учебного пособия “Схема последовательности”, Вы можете оставить свой комментарий.

Больше руководств по диаграммам

• Учебное пособие по моделированию бизнес-процессов (Руководство BPM, объясняющее особенности)
• Окончательное руководство по блок-схемам ( Полное руководство по блок-схемам с примерами)
• Используйте учебное пособие по тематической диаграмме (Руководство с примерами)

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

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

Реализация отдельного варианта использования требует участия и взаимодействия определенных экземпляров актеров и классов. Наиболее подходящий инструмент для описания такого взаимодействия – это диаграммы последовательности и коммуникации, которые, по сути, отображают одну и ту же информацию. В связи с этим большинство 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-диаграммы ПО, автоматизирующего процесс покупки товара в магазине отделочных материалов с отдельным складом.

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

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

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