Диаграммы последовательности · Конспекты по бизнес-анализу

Что это#

Диаграмма последовательности (sequence diagram) — часть UML, унифицированного языка моделирования. В Руководстве BABOK® она моделирует взаимодействия между объектами системы в хронологическом порядке. Объект — конкретный экземпляр класса: «эта бронь», а не «брони вообще». В бизнес-анализе участниками часто бывают роли, экраны или целые системы.

Элементов в нотации немного:

Линия жизни (lifeline): участник. Его рисуют прямоугольником вверху, от которого вниз идёт пунктирная линия. Время течёт сверху вниз.
Блок активации: узкий прямоугольник на линии жизни, который показывает, когда участник занят обработкой сообщения.
Сообщение: стрелка от одной линии жизни к другой. Синхронный вызов (закрашенный наконечник) означает, что отправитель ждёт ответа. Асинхронный вызов (открытый наконечник) означает, что отправитель продолжает работу. Пунктирная стрелка в обратную сторону — ответ.

В UML есть и фрагменты для альтернатив, необязательных шагов и циклов (с метками alt, opt и loop). Используйте их экономно: одна диаграмма должна рассказывать одну историю.

В курсе Белина по UML для IT-бизнес-аналитиков сравниваются нотации описания потоков работ. Диаграммы последовательности — стандартный UML, они приучают мыслить объектами и явно показывают, кто что делает. Правило «один сценарий — одна диаграмма» к тому же сохраняет логику простой. Минус в том, что многим аналитикам и пользователям такой стиль кажется неестественным, и нужно решить не только, кто выполняет каждое действие, но и кто его инициирует.

Когда применять#

Чтобы описать, как процессы, компоненты или системы взаимодействуют и в каком порядке (задача BABOK 7.1 «Спецификация и моделирование требований»).
Чтобы проверить логику варианта использования. Один вариант использования можно изобразить одной или несколькими диаграммами последовательности и рассмотреть подробнее.
Для интеграций с внешними системами, где важны порядок сообщений, ожидание и ответы.
Когда дефект или спор касается того, кто кого вызывает и когда.

Выберите другую технику, когда:

аудитория — представители бизнеса. Диаграммы последовательности обычно моделируют системные потоки и могут оказаться для них слишком техническими; используйте модель процесса с дорожками (swimlane) или диаграмму деятельности;
в сценарии много ветвлений. Диаграмма деятельности справляется с ветвлением лучше;
нужен жизненный цикл одного объекта — используйте моделирование состояний;
диаграмма никому не нужна. Руководство BABOK отмечает, что такие диаграммы трудоёмки, поэтому приберегите их для новых, рискованных или спорных потоков.

Как это делать#

Выберите один сценарий — обычно один поток варианта использования или одну пользовательскую историю. Запишите его триггер и ожидаемый результат.
Перечислите участников слева направо в порядке их первого появления: первым — действующее лицо, которое запускает сценарий, внешние системы — справа.
Нарисуйте линии жизни.
Добавьте сообщения сверху вниз. Подпишите каждое глаголом и ключевыми данными («отправить статус: готов, ID заказа»). Отметьте, синхронное оно или асинхронное.
Добавьте ответы везде, где отправитель ждёт данных или подтверждения.
Добавьте блоки активации, чтобы показать, кто когда работает.
Добавьте альтернативные пути во фрагментах alt или opt, только если они меняют порядок сообщений; иначе нарисуйте отдельную диаграмму.
Пройдите диаграмму с разработчиками и тестировщиками. По каждому сообщению спросите: есть ли у отправителя данные, которые он отправляет? Что будет, если ответ не придёт?
Свяжите диаграмму с вариантом использования, спецификацией интерфейса и тест-кейсами.

Пример#

«Мастерская», вымышленная сеть веломастерских, моделирует сценарий «Механик отмечает ремонт завершённым, и клиент получает уведомление». Участники слева направо: механик, приложение мастерской, сервис ремонтов, провайдер рассылок (внешний), клиент.

№	От кого	Кому	Сообщение	Тип
1	Механик	Приложение мастерской	Отметить заказ выполненным (ID заказа)	синхр.
2	Приложение мастерской	Сервис ремонтов	Установить статус «Готов» (ID заказа)	синхр.
3	Сервис ремонтов	Сервис ремонтов	Найти предпочтительный способ связи с клиентом	себе
4	Сервис ремонтов	Приложение мастерской	Статус обновлён	ответ
5	Сервис ремонтов	Провайдер рассылок	Отправить сообщение «велосипед готов» (адрес, текст)	асинхр.
6	Провайдер рассылок	Клиент	Доставить сообщение	асинхр.
7	Провайдер рассылок	Сервис ремонтов	Отчёт о доставке (доставлено или нет)	асинхр.

Рис. 1. Сценарий «Механик отмечает ремонт завершённым, и клиент получает уведомление» по таблице выше. Закрашенные наконечники — синхронные вызовы, открытые — асинхронные сообщения, пунктирная стрелка — ответ. Нотация: UML-диаграмма последовательности

Показать текстом

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

Фрагмент alt после сообщения 7: если доставка не удалась, сервис ремонтов добавляет заказ в список обзвона стойки приёма.

При разборе диаграммы всплыл вопрос, который раньше никто не задавал: должен ли механик увидеть статус «Готов» до отправки сообщения или после? Диаграмма фиксирует ответ: сразу, потому что отправка асинхронная и не должна задерживать механика.

Частые ошибки#

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

Шаблон#

Шаблон

Сценарий: <вариант использования или история, название потока>
Триггер: <событие>
Результат: <что истинно в конце>
Участники (слева направо): <Действующее лицо>, <Экран>, <Сервис>, <Внешняя система>

| № | От кого | Кому | Сообщение (глагол + ключевые данные) | синхр. / асинхр. / ответ / себе |
|---|---|---|---|---|
| 1 |  |  |  |  |

Альтернативы (alt / opt): <условие> -> <сообщения>
Открытые вопросы: <список>
Трассировка к: <шаг варианта использования, спецификация интерфейса, тест-кейс>

Чек-лист#

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

Источники и что почитать#

IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Рус. изд.: Руководство к своду знаний по бизнес-анализу (Руководство BABOK®), версия 3.0. Техника 10.42 «Диаграммы последовательности».
Watermark Learning. BABOK v3 Study Tables. 2016 (учебное пособие к Руководству BABOK). Техника 10.42.
А. Белин. Бизнес-анализ. Этап начала проекта (тренинг «UML для IT бизнес-аналитиков»), слайды. Luxoft, 2005 (сравнение нотаций описания потоков работ).