Схемы процессов и взаимодействий: BPMN и UML

Зачем схемы

Текст хорош для деталей, но плохо показывает картину целиком. Схема за минуту показывает, кто что делает, в каком порядке и где развилки. А ещё помогает найти пропущенное: на схеме сразу видно, что у ромба «Оплата прошла?» нарисован только путь «да».

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

BPMN: схема процесса

BPMN — стандарт схем бизнес-процессов. Основные элементы:

событие — круг: начало (тонкий), конец (жирный), промежуточное;
задача — прямоугольник со скруглёнными углами: «Приготовить напиток»;
шлюз — ромб: развилка. «Оплата прошла?» → да / нет;
поток — стрелка, порядок шагов;
дорожки — горизонтальные полосы для участников: гость, приложение, бариста.

Процесс предзаказа текстом выглядел бы так:

Дорожка	Шаги
Гость	Оформить заказ → Оплатить
Приложение	Проверить оплату → ромб «Оплата прошла?» → да: передать заказ бариста; нет: показать ошибку
Бариста	Приготовить → Отметить «Готово»
Гость	Получить уведомление → Забрать заказ → конец

На схеме это одна картинка, где сразу видно, кто за что отвечает и где процесс может пойти по другому пути. Подробно о схемах процессов — в уроке «Бизнес-процессы» курса для 1С-аналитиков.

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

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

Текст

Гость → Приложение:        нажимает «Списать баллы»
Приложение → Сервер:       запрос на расчёт списания
Сервер → Лояльность:       сколько баллов у гостя?
Лояльность → Сервер:       120 баллов
Сервер → Приложение:       можно списать 120, к оплате 130 ₽
Гость → Приложение:        оплачивает картой
Приложение → Сервер:       оплата прошла, создать заказ
Сервер → Лояльность:       списать 120 баллов
Лояльность → Сервер:       списано

Такая диаграмма — основа для описания интеграций и API, о них урок 6.

UML: диаграмма состояний

Диаграмма состояний показывает, через какие статусы проходит объект и какие переходы разрешены. Заказ «Зерна»:

Текст

Создан → Оплачен → Готовится → Готов → Выдан
Создан → Отменён        (гость не оплатил за 10 минут)
Оплачен → Отменён       (гость отменил до начала приготовления, деньги возвращаются)

Важно и то, чего нет: из «Готовится» и «Готов» отменить нельзя. Если этого не зафиксировать, разработчики могут разрешить отмену уже приготовленного кофе.

Схемы рисуют в онлайн-редакторах диаграмм или текстом в специальных форматах, которые потом превращаются в картинку. Главное — не инструмент, а чтобы схему понимали все.

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

Пример

Текст

Ожидает → Начислены        (заказ выдан гостю)
Ожидает → Отменены         (заказ отменён до выдачи)
Начислены → Списаны обратно (заказ отменён после выдачи — возврат)

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

Схема помогла найти дыру в первой версии требований из урока 2, где баллы начислялись сразу после оплаты. Решение начислять их только после выдачи защищает от схемы «оплатил — получил баллы — отменил». Такие уточнения — обычная работа аналитика: требования меняют, согласуют с заказчиком и обновляют в документации.

Зачем схемы

BPMN: схема процесса

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

UML: диаграмма состояний

Мини-тест: проверьте себя