UML: Sequence Diagram

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

По традиции:

Голубой цвет — то, что не продиктовано UML, а взято как полезный совет/правило из иных теорий и практик.
Курсив — примеры.

Диаграмма последовательности (Sequence Diagram) относится к поведенческим, но не только: в UML есть целая подкатегория поведенческих диаграмм, называющаяся диаграммами взаимодействия (interaction diagram) (тут можно глянуть на то, что там по чем в UML в целом). Капитан снова шепчет, что в таких диаграммах акцент делается на взаимодействии между участниками какого-либо процесса, и Sequence Diagram не исключение — она показывает взаимодействие (или, по-модному опять-таки, обмен сообщениями) между объектами. В какой-то степени это аналог Activity Diagram, но с фокусом на взаимодействии между участниками, а не на детализации шагов процесса. Как следствие, наиболее полезна она тогда, когда рассматриваемый процесс имеет много участников и их общения между собой, и именно это вы хотите отобразить: в какой последовательности, кто и с кем взаимодействует в процессе.

Элементы и связи (в этот раз мы рассмотрим их вперемешку, чтобы планомерно подать фишки диаграммы):

Lifeline (”линия жизни”) — участник взаимодействия. Это фактически аналог Partition (области) в Activity Diagram. Изображается в виде прямоугольника (объект, изображающий участника), из которого вниз идет сама "линия жизни" (пунктирная линия), показывающая отрезок времени, в течение которого участник “живет”/активен в рамках описываемого процесса.

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

Название объекта : Название класса

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

Участника также можно показать с помощью Актера (Actor), если мы хотим акцентировать внимание на том, что этот участник — внешний по отношению к системе, процесс для которой мы моделируем. В применении к IT-системам это актер в том же понимании, что и на диаграмме вариантов использования. Для простоты на картинке у нас неайтишный пример, т. е. мы не ПО и взаимодействие в рамках него рассматриваем, однако если представить, что цель нашего моделирования — описать, как функционирует “система” под названием “Пиццерия”, то человечек, обращающийся туда за покушать — внешний по отношению к “системе” актер:

Ключевая связь на диаграмме — Message (Сообщение). Это некое взаимодействие между участниками, причем подходить к этому нужно философски: это не обязательно сообщение в буквальном смысле; нажать на кнопку на странице — это взаимодействие человека с системой, а потому на диаграмме будет также показываться с помощью сообщения. Порядок обмена сообщениями в рамках процесса показываем сверху вниз. Подписываются сообщения сутью взаимодействия или передаваемой информацией/данными/объектами.

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

Для начала — что за “трубы” у нас на “линиях жизни” в точках, где они обмениваются сообщениями? Это так называемые Execution (Execution Specification, Activation, Спецификация исполнения). Мы знаем, что UML любит завернуть названия так, чтобы было физически больно ими оперировать, поэтому многие называют это неформально линиями активации. Такая “труба” показывает некий временной период, в течение которого участник чем-то занят в рамках рассматриваемого процесса. Некоторые инструменты моделирования сами, кстати, рисуют эти штуки, когда вы добавляете на диаграмму сообщения. Их можно подписывать — так вы покажете, чем именно занят участник, но как правило подписи опускают и, по правде говоря, на корректность этих труб не особо-то и обращают внимания. Но если читать диаграмму правильно, то в примере выше актер с точки донесения заказа до точки подтверждения заказа занят — логично, что он занимается оформлением заказа. Потом он простаивает (ничего не делает в рамках рассматриваемого процесса) до момента, пока доставщик не привезет пиццу.

Вернемся теперь к Сообщениям — какими они могут быть?

1) Сообщения могут быть синхронными и асинхронными.

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

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

2) Сообщение можно явно показать как ответ на некий запрос. Сообщения-ответы изображаются пунктирной линией.

3) В сообщении можно указать, что оно приводит к созданию некоего объекта (например, объекта данных, если мы говорим про информационные системы). В таком случае стрелка сообщения идет не к пунктирной "линии жизни", а входит в прямоугольник с названием создаваемого объекта (и этот объект, как следствие, также становится участником диаграммы в виде Lifeline). Подобное на диаграмме активностей (для преподавателей университетов — на диаграмме деятельности) мы показывали с помощью Object или Pins. Для бОльшей читаемости можно сопроводить такое сообщение стереотипом «create».

4) В сообщении также можно указать, что оно приводит к уничтожению объекта. В таком случае мы на самом объекте (Lifeline) добавляем крестик, дабы показать, что он уничтожается после получения сообщения. Само сообщение, при этом, никак специфично не оформляется, но для бОльшей читаемости можно добавить стереотип «destroy».

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

Добавим все это на диаграмму:

Что еще есть интересного:

Combined Fragment (знатоки, как это будет по-русски, дабы не триггерить строгих ученых мужей?) — это элемент, позволяющий показать более сложные течения процесса, нежели простой последовательный обмен сообщениями. Изображается в виде прямоугольного региона, который обрамляет “сложную” область сообщений, а в секции вверху этого региона ключевое слово описывает тип фрагмента.

Наиболее полезные фрагменты:

alt — позволяет показать альтернативы (ветвления) процесса. Такой фрагмент разбит на несколько секций, каждая из которых показывает один из альтернативных вариантов и его условие (в квадратных скобках).

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

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

Типовые ошибки:

Перегруз читателя

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

Sequence Diagram VS Activity Diagram

Фактически это продолжение предыдущей ошибки, но стоит остановиться на этом отдельно. На первый взгляд Sequence Diagram — это то же самое, что Activity Diagram, но для процессов с несколькими участниками. Она также показывает динамику процесса, но важно понимать, что фокус больше (именно больше, т. к. показать рассматриваемые вещи можно на обеих диаграммах) на том, как коммуницируют между собой участники процесса, а не на шагах этого процесса. Т. е. в Activity Diagram в глаза читателям бросятся, в первую очередь, шаги, ветвления, циклы и прочие моменты, связанные с алгоритмом. В Sequence Diagram же — участники и то, в какой последовательности и как они между собой взаимодействуют. Ряд гуру бизнес-анализа считают, что Sequence Diagram более сложна и запутанна, чем Activity Diagram, и принципиально не любят ее из-за этого (мол, бизнес-стейкхолдеры легче воспринимают Activity Diagram). Тем не менее, пусть она будет в арсенале, и когда нужен акцент именно на коммуникациях, диаграмма может нагляднее отразить желаемое. Главное, определите, что вы показываете: сценарий юз кейса, например (для серьёзных дядек — “варианта использования”) — на мой взгляд, не лучшая область применения диаграммы. Дело вкуса, конечно, но в большинстве случаев акцент в обсуждении сценариев юз кейса — на наборе шагов, исключениях и альтернативах, а не взаимодействии участников. Если вы где-то возле системного аналитика, в требованиях вы можете оперировать компонентами системы, и тогда, этот аспект может стать важным, но в большинстве случаев у ВИ участника два: актер и система. И получается, что показывать последовательные шаги одного актера вы будете через Self messages, а исключения и альтернативы — через перегружающие рисунок Combined Fragments. Так себе упрощение коммуникации.

Игнорирование сообщений-ответов

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

Путаница между синхронными и асинхронными сообщениями

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