Модуль 2.1. BPMN 2.0 на практике
Темы: пулы/потоки, события, шлюзы, паттерны. Артефакты: модель процесса As-Is/To-Be («заказ-оплата-доставка»). Практика: смоделировать процесс заказа.
BPMN 2.0 — это «общий язык» бизнеса и ИТ, который позволяет одинаково понимать сценарии с участием людей, систем и внешних контрагентов. Для системного аналитика BPMN — связка между SRS, AC/BDD, DMN (правила) и API/событиями. Ниже — практический гайд «как сотруднику», с паттернами, ошибками и чек-листами качества.
Быстрый ориентир по нотации (что, где и зачем)
Коллаборация (Collaboration) — главный вид диаграммы для интеграций: пулы (Pools) — участники, потоки сообщений (Message Flows) — взаимодействие между пулами.
Процесс (Process) — внутри пула: ленты (Lanes) для ролей/подразделений; задачи (Tasks), события (Events), шлюзы (Gateways), подпроцессы (Sub-process).
Хореография/Конверсация — реже в ИТ-проектах; используем Collaboration в 90% случаев.
Токены — как «бежит» выполнение
- Стартовое событие порождает токен.
- Шлюз AND дублирует токен; Join AND ждёт все входящие токены.
- XOR пропускает 1 ветку; OR — одну или несколько (динамический join).
- Без End Event токен «зависает» — процесс не завершён.
Пулы, ленты и потоки: что помещать и как именовать
- Пул = организация/внешняя система: Покупатель, Витрина/Checkout, Платежный провайдер (PSP), Склад, Перевозчик.
- Ленты = роли/подсистемы внутри пула: Оператор саппорта, Сервис Payments, Сервис Orders.
- Последовательные потоки (Sequence Flow) — только внутри пула.
- Потоки сообщений (Message Flow) — между пулами (HTTP-запросы, вебхуки, e-mail).
- Именование задач: Глагол + Объект («Проверить корзину», «Создать платёж»), событий — Событие + Объект («Событие: таймаут PSP»).
События: стартовые/промежуточные/конечные и пограничные
Что должно быть в «инвентаре» SA
- Start: простое, по сообщению (Message), по таймеру (Timer), по условию (Conditional).
- Intermediate: ожидание сообщения (catch), отправка сообщения (throw), Timer, Signal, Link (связка частей диаграммы).
- Boundary Events (пограничные) — на границе задачи/подпроцесса: Error, Timer, Message, Escalation, Compensation; прерывающие (сплошная кайма) и непрерывающие (штриховая).
- End: обычное, Error End (выброс ошибки), Terminate End (убивает все активные токены), Escalation End.
Практика «заказ-оплата-доставка»
- На задаче «Авторизовать платёж» — пограничный Timer 25 сек (прерывающий): при срабатывании — ветка «Принять как асинхронный» → 202 Accepted, публикация события payment.pending.
- На подпроцессе «Доставка» — непрерывающий Message Boundary для входящих вебхуков трекинга: процесс продолжается, но фиксируем статус.
Шлюзы (Gateways) и как ими не стрелять себе в ногу
- Exclusive (XOR) — одна ветка. Всегда задавайте Default Flow.
- Parallel (AND) — параллелит/синхронизирует; Join AND ждёт все токены → возможен дедлок, если одна ветка условно не порождает токен.
- Inclusive (OR) — динамический выбор нескольких веток; Join OR ждёт только те, что стартовали.
- Event-based — выбор по входящему событию (сообщение/таймер/сигнал), а не по условию данных. Нельзя смешивать с задачами — только события.
- Complex — редко; заменяйте явной логикой/подпроцессом.
Анти-паттерн: ставить XOR там, где фактически нужна реакция на событие (например, «или пришёл вебхук, или истек таймер») — используйте Event-based Gateway.
Подпроцессы, multi-instance и транзакции
- Collapsed Sub-process — «сверните» детали, если они не нужны на верхнем уровне.
- Event Sub-process — локальный «перехватчик» событий (ошибка/эскалация/сообщение/таймер) в контексте процесса.
- Multi-instance (маркеры внизу задачи): например, «Собрать посылки по позициям заказа» (по списку OrderItems).
- Транзакционный подпроцесс + компенсации — для саг: «Создать этикетку» ↔ «Отменить этикетку», «Зарезервировать товар» ↔ «Снять резерв».
Данные: объекты, хранилища и документы
- Data Object — вход/выход задачи («Заказ», «Платёж», «Трекинг»).
- Data Store — постоянное хранилище (БД, DWH, файловое).
- В BPMN не моделируем структуру данных — только факт использования. Схему атрибутов держим в ER/словаре данных.
Библиотека паттернов (e-commerce сквозняк)
Чекаут и платёж (с асинхронным PSP)
- Start → «Проверить корзину» → «Создать заказ» → «Инициировать платёж (REST)».
- Event-based Gateway: либо Message Catch «payment.captured», либо Timer «25 сек».
- Если Message — «Подтвердить заказ», End.
-
Если Timer — «Вернуть 202 Accepted», «Поставить задачу на ретраи», End.
Пограничные события: на «Инициировать платёж» повесьте Error Boundary (decline) → «Отменить заказ/резерв».
Доставка и трекинг
- «Сформировать отгрузку» → Parallel Gateway: «Печать этикетки» && «Упаковка».
- Message Boundary на подпроцессе доставки для приема вебхуков tracking.updated.
- Timer Boundary «Просрочка SLA» → «Эскалация/компенсация клиенту» (Escalation Event).
Возврат (RMA) с инспекцией и рефандом
- Start (Message: запрос RMA) → «Создать RMA» → «Отправить ярлык/назначить забор» → Event Sub-process (Message: посылка получена) → «Инспекция» → XOR: «Approved» → «Инициировать рефанд»; «Rejected» → «Отправить уведомление/закрыть».
Качество модели: чек-лист (DoD BPMN)
- Название процесса = глагол + объект (напр., «Оформить заказ»).
- Есть Start и хотя бы один End, нет «висящих» токенов.
- Межсистемные вызовы — Message Flow (не Sequence).
- Ошибки/таймауты — через Boundary/Event-based (а не XOR «как-будто»).
- У каждого XOR — Default Flow.
- Пулов не > 7, элементов на уровне — не > ~12.
- На каждой диаграмме — легенда/версия/владелец/ссылка на SRS/AC/контракты.
- Все задачи наблюдаемы: где лог/метрика/трейс.
- Есть линк на DMN (если есть правила) и на OpenAPI/Events (если есть интеграции).
Типовые ошибки и риски
|
Ошибка |
К чему приводит |
Как чинить |
|---|---|---|
|
Sequence между пулами |
Потеря семантики интеграции |
Заменить на Message Flow |
|
Нет End |
Висящие инстансы/ресурсы |
Добавить End, проверить ветки |
|
XOR вместо Event-based |
«Счастливый» путь, нет таймаута |
Event-based + Timer/Message |
|
AND-join без гарантий токенов |
Дедлок |
Убедиться, что все ветки стартуют; иначе OR-join |
|
Нет обработки ошибок/откатов |
«Подвисшие» заказы/резервы |
Boundary Error/Compensation, Event Sub-process |
|
Логика в названиях |
Неоднозначность |
Чёткие глаголы, DMN/AC для условий |
|
Пул «Пользователь» с задачами |
Путаница |
Для внешнего клиента используйте Message Start/End |
|
Гигантский «ковёр» |
Нечитаемо |
Декомпозируйте на подпроцессы/диаграммы уровня |
Связи BPMN с другими артефактами
- SRS: § «Сценарии/Состояния» — ссылка на BPMN; в требованиях — отсылки к узлам/событиям.
- AC/BDD: каждое ответвление alt → AC/feature-файл.
- DMN: гейтвеи решения → таблицы DMN (скидки, SLA, лимиты).
- OpenAPI/Events: Message Flows ↔ эндпоинты/события (ссылки на OpenAPI/AsyncAPI).
- RTM: строка «REQ-… ↔ BPMN node(s) ↔ AC ↔ TestCase».
Артефакты модуля: шаблоны As-Is / To-Be
As-Is (минимум полей в заголовке)
Process: Возврат товара (As-Is) | Версия 1.0 | Владелец: SA Границы: с момента обращения клиента до завершения возврата денег SLAs: T1 — первичный ответ ≤ 1ч; T2 — рефанд ≤ 5 раб.дней Известные боли: нет трекинга, ручные сверки, задержки PSP Ссылки: SRS §7, регламент №…
To-Be
Process: Возврат товара (To-Be) | Версия 1.2 Изменения: добавлен Event Sub-process «Получен трек»; таймеры SLA; компенсации; webhooks Зависимости: PSP v1.4 (Async), Carrier API v2, Rules DMN v3
Практика: смоделировать процесс заказа (90–120 мин)
Задание: сделать Collaboration-диаграмму «Заказ-Оплата-Доставка» (To-Be) с пулами: Витрина/Checkout, Payments, Warehouse, Carrier, Customer (как внешний пул с сообщениями), Support.
Обязательные элементы:
- Event-based Gateway на ожидании платёжного результата (Message vs Timer).
- Boundary Timer на задаче «Доставить» — SLA нарушено → «Эскалация» (Escalation).
- Split shipment — Multi-instance Sub-process по OrderItems.
- Message Flows для PSP/Carrier вебхуков; дедупликация и акк как отдельная задача.
- Compensation на «Печать этикетки» (отмена при отказе/откате).
- Минимум 2 End Events: «Заказ завершён» и «Заказ отменён/истёк».
Критерии зачёта:
- Межсистемные вызовы оформлены Message Flow, альтернативы смоделированы событиями.
- Есть таймеры/ошибки/эскалации; нет висящих токенов.
- Линки на OpenAPI/Events и на DMN (SLA/скидки).
- Читаемость: ≤ 12 элементов на уровне, остальное — в подпроцессы.
Вопрос–Ответ
В: Когда использовать Event-based Gateway вместо XOR?
О: Когда выбор зависит не от данных, а от внешнего события/времени (вебхук, таймер). Пример: «или придёт payment.captured, или наступит таймаут 25 сек».
В: Как показать ретраи/идемпотентность?
О: Отдельная задача «Поставить повтор», рядом — Boundary Timer и цикл; в подписи указать политику backoff. Идемпотентность отражайте в AC/контрактах, на диаграмме — комментарий «повтор безопасен».
В: Пользователь — это пул или лента?
О: Внешний актор — отдельный пул без внутренних задач (только Message Start/End). Внутренние роли — ленты.
В: Чем компенсаторное событие отличается от отмены задачи?
О: Компенсация — откатывает завершённое действие (после End компенсации процесс продолжается); отмена — прерывает текущее.
В: Можно ли показывать SQL/внутренности сервисов?
О: Нет. BPMN — про процесс и взаимодействия. Данные/SQL — в ER/контрактах. В BPMN — только факт использования Data Objects/Stores.
В: Как показать SLA доставки?
О: Таймеры (Timer Boundary) + DMN (правила расчёта обещанной даты) + Event Sub-process «Нарушен SLA» (эскалация/компенсация).
Теория — короткая памятка
- Collaboration = пулы + message flows; процесс = задачи/шлюзы/события внутри пула.
- Обработку ошибок делаем событиями (Boundary/Error/Escalation), а не XOR.
- Event Sub-process — лучший способ локально ловить таймеры/сообщения/ошибки.
- AND-join ждёт все токены — проверяйте, что они действительно появляются.
- Default Flow у XOR — маст-хэв.
- Подробности скрывайте в подпроцессы; на верхнем уровне — не более ~12 элементов.
- Всегда указывайте версию/легенду/владельца и ставьте ссылки на SRS/AC/контракты/DMN.
Что сдаём по модулю (артефакты)
- As-Is возврата/доставки (1 диаграмма Collaboration).
- To-Be «Заказ-Оплата-Доставка» (1–2 диаграммы с подпроцессами).
- Список ошибок/таймеров/эскалаций (таблица с условиями и владельцами).
- Связи: таблица «узел BPMN → AC/BDD → OpenAPI/Events → DMN».
