Урок 05.01: Основы BPMN 2.0
Цель урока
Познакомиться с нотацией BPMN 2.0 — мировым стандартом моделирования бизнес-процессов. После этого урока вы сможете:
- Понимать структуру BPMN-диаграммы: пулы, дорожки, события, задачи, шлюзы
- Чётко различать Pool и Lane — и не совершать грубую ошибку, помещая внешнего клиента в Lane
- Выбирать корректный тип шлюза (XOR / AND / OR / Event-based)
- Создавать базовую BPMN-диаграмму в Camunda Modeler
- Отличать исполняемую модель от неисполняемой
- Понимать XML-структуру BPMN (на уровне, достаточном для общения с разработчиком)
1. Что такое BPMN и зачем она нужна?
BPMN (Business Process Model and Notation) — стандарт OMG для моделирования бизнес-процессов. Главное отличие от UML Activity Diagram: BPMN может быть исполнена в BPM-движке (Camunda, Activiti, Flowable).
1.1. Аналогия для быстрого понимания
Представьте, что вы — шеф-повар, и вам нужно описать рецепт:
| Инструмент | Аналогия |
|---|---|
| Текстовое описание | «Возьмите муку, добавьте яйца, замесите тесто» — понятно человеку, но неточность |
| UML Activity Diagram | Рисунок на салфетке: повар видит последовательность, но может интерпретировать по-своему |
| BPMN | Техническая карта блюда с точными температурами, граммами и таймерами. Повар может отклоняться, но робот-кулинар (BPM-движок) — нет |
1.2. Ключевые понятия BPM
Прежде чем говорить о BPMN, нужно понять несколько фундаментальных понятий:
Процесс (Process) — это совокупность последовательных действий, преобразующая входы в выходы для достижения определённой бизнес-цели.
Характеристики процесса:
- Trigger (Триггер): что запускает процесс (событие, время, действие)
- Result (Результат): что считается успешным завершением
- Actor (Исполнитель): кто выполняет действия (роль, система, организация)
- Data (Данные): какая информация передаётся между шагами
BPM-движок (Business Process Engine) — программное обеспечение, которое «исполняет» BPMN-диаграмму:
- Создаёт экземпляр процесса (instance) по Start Event
- Передаёт управление от задачи к задаче по Sequence Flow
- Вычисляет условия на шлюзах
- Вызывает внешние сервисы (Service Task)
- Ставит задачи пользователям (User Task)
1.3. История BPMN
| Год | Версия | Что изменилось |
|---|---|---|
| 2004 | BPMN 1.0 | Первая версия — только визуальная нотация, не было формата для исполнения |
| 2008 | BPMN 1.1 | Уточнения, добавлены некоторые элементы |
| 2011 | BPMN 2.0 | Революция: добавлена семантика исполнения, XSD-схема, XML-сериализация. Теперь диаграмму можно загрузить в движок |
| 2013 | BPMN 2.0.1 | Стабилизация, стандарт ISO/IEC 19510 |
| 2025+ | BPMN 2.0 | Остаётся актуальным. Активно развиваются DMN (правила) и CMMN (кейсы) |
1.4. BPMN vs UML Activity Diagram
| Аспект | UML Activity Diagram | BPMN |
|---|---|---|
| Стандарт | OMG UML 2.5 | OMG BPMN 2.0 + ISO 19510 |
| Год появления | 1997 (Activity в UML 1.0) | 2004 (BPMN 1.0) |
| Фокус | Визуализация алгоритма / процесса | Исполняемая модель процесса |
| События | 3 (Start, Stop, Flow Final) | ~50+ типов (Message, Timer, Error, Signal, Escalation, Compensation, Link, Terminate…) |
| Шлюзы | Decision, Fork, Join, Merge — все одним ромбом | 5 типов: Exclusive (XOR), Inclusive (OR), Parallel (AND), Event-based, Complex — строго различимы |
| Формат обмена | Нет (только картинка) | XML по XSD-схеме — можно загрузить в движок |
| Исполнение | Не предназначена | Да — Camunda, Activiti, Flowable, ELMA |
| Пулы и сообщения | Нет (только Swimlane) | Pool + Lane + Message Flow между пулами |
| Инструменты | Draw.io, PlantUML | Camunda Modeler, Signavio, Bizagi |
Когда выбирать BPMN вместо UML Activity:
- Процесс будет исполняться в BPM-движке
- Нужно точное моделирование событий (таймеры, сообщения, ошибки)
- В процессе участвуют несколько организаций (нужны пулы и Message Flow)
- Процесс станет частью регламента (юридически значим)
2. Структура BPMN-диаграммы — Pool и Lane
2.1. Pool (Пул)
Pool — это прямоугольник, представляющий одного участника процесса. Обычно это организация (компания, система) или отдельный бизнес-роль.
Визуально:
┌──────────────────────────────────────────────────────────────────┐
│ Pool: Сеть клиник "Здоровье+" │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Lane: Регистратура │ │
│ │ ⬭ ... → ⬭ ... → ⬭ ... │ │
│ └────────────────────────────────────────────────────────────┘ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Lane: Врач │ │
│ │ ⬭ ... → ⬭ ... → ⬭ ... │ │
│ └────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘
Правила Pool:
- Внутри пула — один процесс (Sequence Flow соединяет элементы)
- Если процесса два — их нельзя поместить в один пул
- У пула есть граница — Sequence Flow не может её пересечь
- Если на диаграмме один пул — он может быть без границы (свёрнутый пул)
2.2. Lane (Дорожка)
Lane — это подобласть внутри пула для группировки действий по ролям / отделам.
Правила Lane:
- Lane всегда внутри Pool (Lane не может существовать самостоятельно)
- Sequence Flow свободно пересекает границы Lane — это нормально
- Lane — это «кто делает», а не «кто владеет процессом»
2.3. ⚠️ КРИТИЧЕСКОЕ ПРАВИЛО: Клиент ≠ Lane
Это самая распространённая и самая грубая ошибка начинающих моделировать в BPMN.
ЧАСТАЯ ОШИБКА (НЕПРАВИЛЬНО):
┌──────────────────────────────────────────────────────────────────┐
│ Pool: Медицинская система │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Lane: Пациент ← ОШИБКА! │ │
│ │ ○ → ⬭ Отправить заявку → ⬭ Получить ответ → ◉ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Lane: Система │ │
│ │ ⬭ Проверить слот → ◇ ... │ │
│ └────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘
Почему это ошибка?
| Аспект | Объяснение |
|---|---|
| Владение процессом | Пациент не владеет процессом клиники. Он — внешний участник. Помещая его в Lane, вы утверждаете, что он — часть организации |
| Sequence Flow | Между Пациентом и Системой нарисован Sequence Flow (сплошная линия). Sequence Flow означает «порядок выполнения в рамках одного процесса». Но Пациент — это другой процесс со своей логикой |
| Message Flow | Единственный способ взаимодействия между организациями — Message Flow (пунктирная линия). Sequence Flow не может пересекать границу пула |
| Управление | Процесс клиники не может управлять действиями пациента. Клиника не говорит пациенту «отправь заявку» — пациент делает это сам, по своему усмотрению |
ПРАВИЛЬНО:
┌──────────────────────────────────────────────────────────────────┐
│ Pool: Пациент (внешняя роль) │ ◄── Пул 1
│ ○ → ⬭ Отправить заявку → ⬭ Получить ответ → ◉ │
└──────────────────────────────────────────────────────────────────┘
│
─ ─ ─ ┼ ─ ─ ─ Message Flow
│
┌──────────────────────────────────────────────────────────────────┐
│ Pool: Сеть клиник "Здоровье+" │ ◄── Пул 2
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Lane: Регистратура │ │
│ │ ⬭ Принять заявку → ◇ "Слот свободен?" │ │
│ └────────────────────────────────────────────────────────────┘ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Lane: Врач │ │
│ │ ⬭ Осмотреть расписание │ │
│ └────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘
Что изменилось:
- Пациент — отдельный пул. Он — внешняя роль, не часть клиники
- Message Flow (пунктир) соединяет пулы — только так
- Sequence Flow (сплошной) — только внутри каждого пула
- Клиника имеет свои Lane (Регистратура, Врач) — это её внутренние роли
2.4. Развёрнутый vs Свёрнутый пул
| Тип пула | Визуал | Когда использовать |
|---|---|---|
| Развёрнутый (Expanded) | Показаны все Lane и элементы процесса | Мы моделируем процесс детально |
| Свёрнутый (Collapsed) | Только рамка с названием | Мы не моделируем процесс внутри (чёрный ящик) |
Свёрнутый пул для внешней роли: Часто внешнего участника (например, «Платёжная система») показывают свёрнутым пулом — чтобы не моделировать его внутренний процесс. Это «чёрный ящик»: мы знаем, что он принимает запрос и возвращает ответ, но как — не наша забота.
┌─────────────────────────────────┐
│ Пациент (свёрнутый) │
│ ○ → ⬭ ... → ◉ │
└─────────────────────────────────┘
│ Message Flow
▼
┌──────────────────────────────────────────────────────────────────┐
│ Клиника "Здоровье+" (развёрнутый) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Lane: Регистратура │ Lane: Врач │ │
│ │ ⬭ ... → ⬭ ... │ ⬭ ... → ⬭ ... │ │
│ └────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘
2.5. Как определить: Pool или Lane?
Алгоритм из 2 вопросов:
| Вопрос | Если ДА → | Если НЕТ → |
|---|---|---|
| 1. Этот участник — часть нашей организации? | Внутри нашего Pool (Lane) | Отдельный Pool |
| 2. Участник владеет своим процессом? | Отдельный Pool | Lane / часть другого процесса |
Примеры:
| Участник | Наша организация? | Владеет своим процессом? | Решение |
|---|---|---|---|
| Пациент (клиника) | Нет | Да (он сам решает, когда отправить заявку) | Отдельный Pool |
| Регистратура (клиника) | Да | Нет (она часть процесса клиники) | Lane |
| Платёжный шлюз (интеграция) | Нет | Да (у него свой API) | Свёрнутый Pool |
| Склад (интернет-магазин) | Да | Нет (часть процесса магазина) | Lane |
| Курьерская служба | Нет | Да (у них свой процесс доставки) | Отдельный Pool |
2.6. Почему новички совершают эту ошибку?
- В UML Activity нет понятия пулов — только Swimlane. Аналитик, пришедший из UML, привык, что все роли — это дорожки. Переносит этот подход в BPMN.
- Визуально проще — нарисовать всё в одном прямоугольнике.
- «Пациент тоже делает действия» — да, но эти действия — часть его процесса, а не процесса клиники.
- Непонимание Message Flow — аналитик не знает, как показать взаимодействие между пулами, и рисует Sequence Flow через границу.
Запомните: Если вы нарисовали Sequence Flow, пересекающий границу пула — ваша диаграмма некорректна с точки зрения BPMN-спецификации. Такую диаграмму нельзя загрузить в BPM-движок.
2.7. Сводная таблица Pool vs Lane
| Характеристика | Pool | Lane |
|---|---|---|
| Представляет | Организацию / систему / внешнюю роль | Отдел / роль внутри организации |
| Sequence Flow | Не пересекает границу | Свободно пересекает |
| Message Flow | Между пулами | Нет (пулы общаются) |
| Процесс | Один процесс на пул | Часть процесса пула |
| Исполнение | Один движок на пул (обычно) | Тот же движок |
| Может быть свёрнут | Да («чёрный ящик») | Нет |
3. Flow Objects: основа BPMN-диаграммы
3.1. События (Events) — то, что ПРОИСХОДИТ
События — это круги. Они делятся по положению (Start / Intermediate / End) и по триггеру (Message, Timer, Error, Signal...).
По положению:
| Тип | Нотация | Смысл | Количество |
|---|---|---|---|
| Start Event | ○ (одинарная тонкая линия) | Начало процесса | Один (на диаграмму) |
| Intermediate Event | ◯ (двойная линия) | Событие в ходе процесса | Много |
| End Event | ◉ (одинарная жирная линия) | Завершение процесса | Может быть несколько |
По триггеру (маркеры внутри круга):
| Маркер | Тип | Название | Пример |
|---|---|---|---|
| (пусто) | Ничего | None | Просто «начало» (без триггера) |
| ✉ | Конверт | Message | Получено / отправлено сообщение |
| ⏰ | Часы | Timer | Наступило время, прошёл интервал |
| ❌ | «Молния» | Error | Произошла ошибка |
| 🔗 | Звено цепи | Link | Связь между частями большого процесса |
| 📌 | Флаг | Signal | Широковещательный сигнал |
| 🔄 | Стрелки | Escalation | Требуется вмешательство руководителя |
| ⚖ | Весы | Compensation | Откат / компенсация |
| ◼ | Квадрат | Conditional | Изменилось состояние данных |
| ⬜ | Страница | Multiple | Любое из нескольких событий |
Start Event — подробно:
| Тип Start Event | Маркер | Что запускает процесс | Пример в XML |
|---|---|---|---|
| None | ○ (пустой) | Вручную (через UI Camunda) | Запуск из админки |
| Message | ○✉ | Приход сообщения (API, очередь) | POST /process/start |
| Timer | ○⏰ | По расписанию или через интервал | Каждый день в 9:00 |
| Signal | ○📌 | Широковещательный сигнал | Сигнал из другой системы |
| Error | ○❌ | Ошибка (обычно не используется) | — |
End Event — подробно:
| Тип End Event | Маркер | Что происходит |
|---|---|---|
| None | ◉ (пустой) | Процесс завершён |
| Message | ◉✉ | В конце отправляется сообщение |
| Error | ◉❌ | Процесс завершается ошибкой |
| Terminate | ◉● (жирный круг) | Завершает все потоки процесса (аварийно) |
Terminate vs обычный End: Если в процессе есть параллельные потоки (Parallel Gateway), обычный End завершает только этот поток. Terminate End — завершает весь процесс, обрывая все параллельные ветки.
3.2. Задачи (Tasks) — то, что ДЕЛАЮТ
Задачи — скруглённые прямоугольники с одинарной линией границы.
Типы задач:
| Тип задачи | Маркер | Исполнитель | Пример |
|---|---|---|---|
| Task (абстрактная) | (нет) | Не указан | «Обработать заявку» (на ранних стадиях) |
| User Task | 🧑 (человечек) | Человек (через UI) | «Согласовать заявку», «Заполнить форму» |
| Service Task | ⚙ (шестерёнка) | Система (API) | «Вызвать платёжный шлюз», «Проверить баланс» |
| Send Task | ✉ (конверт) | Отправка сообщения | «Отправить email пациенту» |
| Receive Task | ✉ (конверт) | Ожидание сообщения | «Ожидать ответ от платёжного шлюза» |
| Manual Task | 🖐 (рука) | Человек (без ИТ) | «Подписать документ лично» |
| Business Rule Task | 📋 (таблица) | DMN-движок | «Рассчитать скидку по правилам» |
| Script Task | 📜 (свиток) | BPM-движок (код) | «Сгенерировать ID», «Присвоить номер» |
| Call Activity | + (плюс) | Вызов подпроцесса | «Обработать возврат» (отдельная диаграмма) |
Service Task vs User Task — ключевое различие:
| Характеристика | Service Task | User Task |
|---|---|---|
| Исполняет | Машина (сервис) | Человек |
| Время | Миллисекунды — секунды | Минуты — дни |
| UI | Нет (API) | Форма (Camunda Forms, React) |
| В XML | implementation="delegateExpression" |
camunda:assignee="user" |
| Пример | Вызвать API погоды | Согласовать заявку у руководителя |
3.3. Подпроцессы (Subprocesses)
Подпроцесс — задача, которая раскрывается в отдельную BPMN-диаграмму.
| Тип | Визуал | Смысл |
|---|---|---|
| Embedded Subprocess | Скруглённый прямоугольник с + | Подпроцесс описан в той же диаграмме (разворачивается по клику) |
| Reusable Subprocess | Call Activity | Вызов отдельного процесса (отдельный файл .bpmn) |
Когда нужен подпроцесс:
- Процесс становится слишком большим (более 20 элементов)
- Один и тот же блок вызывается в разных процессах
- Нужно изолировать сложную логику с собственными ошибками
3.4. Шлюзы (Gateways) — точки ВЕТВЛЕНИЯ
Шлюзы — ромбы. В BPMN каждый шлюз имеет строгий тип. Нельзя просто нарисовать ромб — нужно указать маркер.
Exclusive Gateway (XOR) — исключающий шлюз
Маркер: ✕ (крест) внутри ромба (или пустой ромб без маркера — по умолчанию XOR)
Поведение: Выбирается ровно один путь из нескольких. Аналог if-else / switch.
┌── [сумма > 1000] → ⬭ Запросить approval
◇ (XOR) ──┤
└── [сумма ≤ 1000] → ⬭ Провести оплату
Правила:
- Ровно один вход
- 2–N выходов с условиями
- Условия должны покрывать все случаи (иначе — ошибка исполнения)
- Можно задать default flow (путь, если ни одно условие не подошло)
Пример с default:
┌── [возраст >= 65] → ⬭ Скидка 20%
◇ (XOR) ──┼── [возраст >= 18 и возраст < 65] → ⬭ Без скидки
└── [else / default] → ⬭ Проверить документы
Parallel Gateway (AND) — параллельный шлюз
Маркер: ➕ (плюс) внутри ромба
Поведение: Все пути выполняются параллельно. Аналог fork-join.
┌── ⬭ Отправить email
◇ (AND) ──┤
└── ⬭ Создать задачу в CRM
Параллельный входящий (Join): Ждёт все входящие потоки, затем идёт дальше.
⬭ Отправить email ──┐
├── ◇ (AND) → ⬭ Обновить статус
⬭ Создать задачу ───┘
Важно: AND на входе — синхронизация. Пока все ветки не завершатся, процесс не продолжается.
Inclusive Gateway (OR) — включающий шлюз
Маркер: ○ (круг) внутри ромба
Поведение: Выбирается один или более путей. Аналог — несколько независимых if без else.
├── [заказана доставка] → ⬭ Рассчитать стоимость доставки
◇ (OR) ───┼── [нужна страховка] → ⬭ Добавить страховку
└── [есть промокод] → ⬭ Применить скидку
Когда OR, а не XOR:
- Несколько условий могут быть истинны одновременно
- Выполняются все истинные ветки
Event-based Gateway — шлюз по событию
Маркер: ✦ (звезда) внутри ромба
Поведение: Выбор пути определяет событие, а не данные. Процесс останавливается и ждёт, пока одно из событий не произойдёт.
┌── ◯ (Message) Получить ответ
◇ (Event) ─┤
└── ◯ (Timer) Прошло 15 минут
Аналогия: Вы ждёте у ресторана. Или вам вынесут заказ (Message), или вы уйдёте через 15 минут (Timer). Что наступит первым — тот путь и выбирается.
Complex Gateway — сложный шлюз
Маркер: ★ (звезда) внутри ромба
Поведение: Требует ручного описания логики. Используется редко — только когда ни один другой шлюз не подходит.
Сравнительная таблица шлюзов:
| Шлюз | Маркер | Сколько путей? | Аналог в коде |
|---|---|---|---|
| Exclusive (XOR) | ✕ или пусто | Ровно один | if-else if-else, switch |
| Parallel (AND) | ➕ | Все (одновременно) | fork-join, Promise.all() |
| Inclusive (OR) | ○ | Один или более | Несколько независимых if |
| Event-based | ✦ | Ровно один (по событию) | Promise.race() |
| Complex | ★ | По описанию | — |
4. Connecting Objects — как элементы соединяются
4.1. Sequence Flow (сплошная линия)
Вид: → (сплошная линия с залитой стрелкой)
Что обозначает: Порядок выполнения действий внутри одного пула. «После A выполняется B».
Правила:
- Sequence Flow не может пересекать границу пула
- Sequence Flow соединяет: Start → Task, Task → Gateway, Task → Event, Gateway → Task, Task → End
- На Sequence Flow может быть условие в квадратных скобках (для XOR / OR)
Примеры:
○ Start → ⬭ User Task → ◇ XOR → ... → ◉ End
4.2. Message Flow (пунктирная линия)
Вид: - - - ► (пунктирная линия с открытой стрелкой)
Что обозначает: Обмен сообщениями между пулами (организациями / системами).
Правила:
- Message Flow всегда соединяет разные пулы
- Message Flow никогда не соединяет элементы внутри одного пула
- Message Flow соединяет: Pool → Pool, или элемент пула → элемент другого пула
- На Message Flow не бывает условий — это поток данных, а не управления
Пример:
┌─ Pool: Клиент ─────────┐
│ ⬭ Отправить заявку │
└────────┬────────────────┘
│
─ ─ ─┼─ Message Flow ─
│
┌────────▼────────────────┐
│ Pool: Клиника │
│ ○ Start (Message) │
│ ⬭ Принять заявку │
└──────────────────────────┘
Sequence Flow vs Message Flow:
| Аспект | Sequence Flow | Message Flow |
|---|---|---|
| Линия | Сплошная | Пунктирная |
| Стрелка | Залитый треугольник | Открытая стрелка |
| Пересекает пул | ❌ Никогда | ✅ Всегда |
| Условие | ✅ Да (квадратные скобки) | ❌ Нет |
| Смысл | «Порядок выполнения» | «Обмен данными» |
4.3. Association (пунктир с точкой)
Вид: - - - (пунктирная линия с точкой-ромбом на конце)
Что обозначает: Связь задачи с артефактом (Data Object, Data Store, текстовая аннотация).
Пример:
⬭ Заполнить форму
│
├ - - - (Data Object) «Заявка.pdf» — входные данные
└ - - - 📝 «Заполните все поля» — текстовое пояснение
5. ⚠️ КРИТИЧЕСКИЙ ПРИМЕР: «Запись к врачу» — КАК ДЕЛАТЬ НЕЛЬЗЯ И КАК ПРАВИЛЬНО
5.1. НЕПРАВИЛЬНЫЙ вариант (типичная ошибка)
Начинающий аналитик рисует так:
❌ НЕПРАВИЛЬНО:
┌──────────────────────────────────────────────────────────────────┐
│ Pool: Медицинская система │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Lane: Пациент ← ГРУБАЯ ОШИБКА! │ │
│ │ ○ → ⬭ Отправить заявку → ◉ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Lane: Система │ │
│ │ ⬭ Проверить слот → ◇ XOR (слот свободен?) │ │
│ │ ├── [Да] → ⬭ Подтвердить запись → ⬭ Уведомить │ │
│ │ └── [Нет] → ⬭ Предложить альтернативу → ⬭ Уведомить │ │
│ └────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘
Перечень ошибок:
| № | Ошибка | Объяснение |
|---|---|---|
| 1 | Пациент — Lane | Пациент — внешнее лицо, не часть организации. Нельзя помещать его в пул клиники |
| 2 | Sequence Flow между Пациентом и Системой | Sequence Flow не пересекает границы (здесь — даже внутри одного пула, но в разных Lane). Система не может управлять действиями пациента |
| 3 | Пациент завершает процесс | Start в Lane пациента и End в той же Lane. Процесс клиники не может «начинаться» в Lane пациента |
| 4 | Потеря Message Flow | Взаимодействие должно быть через Message Flow, а не через Sequence Flow |
| 5 | Неверное владение процессом | Кто владеет процессом записи? Клиника. Пациент — внешний запросчик, у него свой процесс |
5.2. ПРАВИЛЬНЫЙ вариант
✅ ПРАВИЛЬНО:
┌──────────────────────────────────────────────────────────────────┐
│ Pool: Пациент (внешний участник) │
│ │
│ ○ (None) → ⬭ Отправить заявку → ◯ (Intermediate Message) │
│ ↓ │
│ ⬭ Получить ответ │
│ → ◉ End │
└──────────────────────────────────────────────────────────────────┘
│ ↑
│ Message Flow (отправить заявку) │ Message Flow (получить ответ)
▼ │
┌──────────────────────────────────────────────────────────────────┐
│ Pool: Сеть клиник "Здоровье+" │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Lane: Регистратура │ │
│ │ │ │
│ │ ○ Start (Message) → ⬭ Принять заявку → ⬭ Проверить слот │ │
│ │ │ │ │
│ │ ◇ XOR (слот │ │
│ │ свободен?) │ │
│ │ ┌───┴───┐ │ │
│ │ [Да] ▼ ▼ [Нет] │ │
│ │ ⬭ Подтвердить ⬭ Найти │ │
│ │ запись альтернативу │ │
│ │ │ │ │ │
│ │ └─────┬──────┘ │ │
│ │ ▼ │ │
│ │ ⬭ Отправить результат │ │
│ │ → ◉ End │ │
│ └────────────────────────────────────────────────────────────┘ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Lane: Врач │ │
│ │ (не участвует в этом процессе — только Регистратура) │ │
│ └────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘
Что исправлено:
| Исправление | Как стало |
|---|---|
| Пациент — отдельный пул | Свой Pool со своим Start/End и своим процессом |
| Sequence Flow не пересекает границу | Внутри каждого пула — только Sequence Flow |
| Message Flow между пулами | Пациент отправляет заявку (→ клиника). Клиника отправляет ответ (→ пациент) |
| Start у клиники — Message | Начинается с получения сообщения от пациента |
| End у клиники — None | Клиника завершила обработку (отправив ответ) |
| End у пациента — None | Пациент получил ответ и завершил свой подпроцесс |
5.3. Как НА САМОМ ДЕЛЕ выглядит процесс «Запись к врачу» в реальной BPMN
Реальный процесс включает 3 пула:
┌──────────────────────────────────────────────────────────────────┐
│ Pool: Пациент │
│ ○ → ⬭ Открыть приложение → ⬭ Выбрать время → ⬭ Отправить │
│ заявку → ◯ (Message)│
└──────────────────────────────────────────────────────────────────┘
│
▼ Message Flow
┌──────────────────────────────────────────────────────────────────┐
│ Pool: Медицинская информационная система (МИС) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Lane: Frontend (сайт/приложение) │ │
│ │ ○ (Message) → ⬭ Показать расписание → ⬭ Принять заявку │ │
│ └────────────────────────────────────────────────────────────┘ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Lane: Backend (API) │ │
│ │ ⬭ Проверить слот → ⬭ Создать запись → ⬭ Отправить │ │
│ │ подтверждение │ │
│ └────────────────────────────────────────────────────────────┘ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Lane: SMS-шлюз │ │
│ │ ⬭ Отправить SMS-уведомление │ │
│ └────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘
│
▼ Message Flow
┌──────────────────────────────────────────────────────────────────┐
│ Pool: Платёжный шлюз (внешняя система, свёрнутый пул) │
│ (чёрный ящик — мы не моделируем его процесс) │
└──────────────────────────────────────────────────────────────────┘
6. Data — данные в BPMN
6.1. Data Object (объект данных)
Прямоугольник с загнутым уголком, присоединяется к задаче через Association.
Состояния:
- Data Input: данные, которые входят в задачу
- Data Output: данные, которые выходят из задачи
- Data Store: хранилище данных (БД, файл)
6.2. Data Store (хранилище)
Более широкий прямоугольник с символом базы данных. Используется для показа, что данные хранятся в постоянном хранилище.
6.3. Message (сообщение)
Конверт ✉, прикреплённый к границе пула. Показывает, какие данные передаются в Message Flow.
7. Практика: работа в Camunda Modeler
7.1. Установка и первый запуск
Где скачать: camunda.com/download/modeler
Системные требования:
- Windows, macOS, Linux
- RAM: от 512 МБ
- Java: не требуется (Modeler написан на Electron)
Установка:
- Windows:
.exe— запустить установщик - macOS:
.dmg— перетащить в Applications - Linux:
.AppImage—chmod +x&& запустить
7.2. Интерфейс Camunda Modeler (пошагово)
При первом запуске вы видите:
┌─────────────────────────────────────────────────────────────────────┐
│ Camunda Modeler 5.x — □ × │
├─────────────────────────────────────────────────────────────────────┤
│ File Edit View Help │
├─────────────────────────────────────────────────────────────────────┤
│ [New Diagram] [Open] [Save] [Undo] [Redo] [Export as PNG] │
├──────────────┬──────────────────────────────────────────────────────┤
│ Pallete │ Canvas │
│ (слева) │ (Рабочая область) │
│ │ │
│ ┌────────┐ │ ┌──────────────────────────────────────────┐ │
│ │Select │ │ │ │ │
│ ├────────┤ │ │ Сюда перетаскиваете элементы │ │
│ │События │ │ │ из панели Palette │ │
│ │ Start ○│ │ │ │ │
│ │ End ◉│ │ │ │ │
│ │ Timer ⏰│ │ │ │ │
│ ├────────┤ │ │ │ │
│ │Задачи │ │ │ │ │
│ │ User 🧑 │ │ │ │ │
│ │ Serv ⚙ │ │ │ │ │
│ │ Send ✉ │ │ │ │ │
│ ├────────┤ │ │ │ │
│ │Шлюзы │ │ │ │ │
│ │XOR ◇ │ │ │ │ │
│ │AND ◇ │ │ │ │ │
│ │OR ◇ │ │ │ │ │
│ ├────────┤ │ │ │ │
│ │Пул/Lane│ │ │ │ │
│ │ Pool ▭ │ │ │ │ │
│ │ Lane ▭ │ │ │ │ │
│ ├────────┤ │ │ │ │
│ │Данные │ │ │ │ │
│ │ Data 📄│ │ │ │ │
│ │ Store 🗄│ │ │ │ │
│ └────────┘ │ └──────────────────────────────────────────┘ │
├──────────────┴──────────────────────────────────────────────────────┤
│ Properties Panel (справа или внизу) │
│ При выделении элемента показывает его свойства │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ General │ Details │ Forms │ ... │ │
│ │ Name: Принять заявку │ │
│ │ Type: User Task │ │
│ │ Assignee: ${registrator} │ │
│ └────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────┘
7.3. Пошаговое создание первой диаграммы
Шаг 1: Создать новый файл → File → New → BPMN Diagram (или Ctrl+N)
Шаг 2: Добавить Pool
- Перетащить Pool из Palette на Canvas
- Появится прямоугольник с одним Lane
Шаг 3: Добавить второй Lane
- Навести мышь на правый край пула → появится значок
+ - Нажать → добавится вторая Lane
- Переименовать Lane: кликнуть на названии → ввести «Регистратура», «Врач»
Шаг 4: Добавить Start Event
- Перетащить Start Event (None) из Palette на место внутри Lane
- Кликнуть на Start Event → в Properties Panel изменить тип на Message (если нужно)
Шаг 5: Добавить задачи
- Перетащить User Task → назвать «Принять заявку»
- Перетащить Service Task → назвать «Проверить слот»
Шаг 6: Добавить шлюз
- Перетащить Gateway (Exclusive / XOR)
- Назвать «Слот свободен?»
Шаг 7: Связать элементы
- Кликнуть на Start Event → появится маленькая зелёная стрелка
- Перетащить стрелку на User Task → создастся Sequence Flow
- Повторить для всех элементов
Шаг 8: Добавить условия на шлюз
- Кликнуть на Sequence Flow после шлюза → в Properties Panel → Condition → написать
${slotAvailable} - Второй поток:
${!slotAvailable}или поставить как default (без условия)
Шаг 9: Добавить End Event
- Перетащить End Event → поставить для каждой конечной ветки
Шаг 10: Экспорт
- PNG:
File → Export As → PNG - SVG:
File → Export As → SVG - Исполняемый XML: сохранить
.bpmn(формат по умолчанию)
7.4. Properties Panel — основные вкладки
| Вкладка | Для какого элемента | Что можно настроить |
|---|---|---|
| General | Все | Имя (Name), ID (уникальный идентификатор) |
| Details | Service Task | Implementation, Delegate Expression, Topic |
| Details | User Task | Assignee (назначенный пользователь), Candidate Users/Groups |
| Details | XOR Gateway | Sequence Flow — Condition Expression |
| Details | Message Start | Message Name (связь с Message Flow) |
| Forms | User Task | Форма для заполнения (Camunda Forms) |
| Input/Output | Service Task | Маппинг входных и выходных переменных |
| Multi-instance | Task | Параллельное выполнение для нескольких исполнителей |
| Extended | Любой | Дополнительные свойства (для расширений) |
7.5. Горячие клавиши Camunda Modeler
| Комбинация | Действие |
|---|---|
Ctrl+N |
Создать новую диаграмму |
Ctrl+S |
Сохранить |
Ctrl+Z / Ctrl+Y |
Отмена / повтор |
Ctrl+C / Ctrl+V |
Копировать / вставить |
Delete |
Удалить выделенный элемент |
Space |
Ручной режим: добавить элемент по клику |
Shift + Drag |
Выделить несколько элементов |
Ctrl + A |
Выделить всё |
Ctrl + Shift + E |
Экспорт как PNG |
Ctrl + Shift + X |
Экспорт как XML (открыть в редакторе) |
7.6. Исполняемая vs Неисполняемая модель
Camunda Modeler по умолчанию создаёт ИСПОЛНЯЕМУЮ модель (isExecutable = true в XML).
| Признак | Неисполняемая | Исполняемая |
|---|---|---|
| Sequence Flow с условием | Просто текст [Да] |
conditionExpression в XML |
| Service Task | Просто название | delegateExpression, topic, connector |
| User Task | Просто название | assignee, candidateGroups |
| Формат | PNG / PDF (картинка) | XML (.bpmn) + PNG |
| Можно загрузить в движок? | ❌ | ✅ |
Совет: Начинайте с неисполняемой модели (только названия и условия текстом). После согласования с заказчиком — добавьте технические детали (assignee, implementation) и превратите в исполняемую.
7.7. Симуляция процесса в Camunda Modeler
Camunda Modeler не имеет встроенного симулятора (он есть в Camunda Веб-моделере). Чтобы «проиграть» процесс:
- Экспортируйте
.bpmn - Загрузите в Camunda Platform (Self-Managed или SaaS)
- Запустите экземпляр процесса через Cockpit / REST API
- Проходите по шагам: завершайте User Task через Tasklist
8. BPMN-диаграмма и XML
8.1. Зачем аналитику знать XML?
Аналитик не обязан писать XML. Но понимать его структуру нужно, чтобы:
- Читать diff в Git (разработчик изменил условие — вы видите)
- Понимать, какие детали добавляет разработчик
- Аргументировать: «Этот процесс нельзя исполнить, потому что в XML нет implementation»
8.2. Базовая структура BPMN XML
<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions
xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
xmlns:camunda="http://camunda.org/schema/1.0/bpmn"
targetNamespace="http://bpmn.io/schema/bpmn">
<!-- Корневой элемент — process -->
<bpmn:process id="appointment_process"
name="Запись к врачу"
isExecutable="true">
<!-- Start Event -->
<bpmn:startEvent id="start" name="Заявка получена">
<bpmn:messageEventDefinition />
</bpmn:startEvent>
<!-- Sequence Flow -->
<bpmn:sequenceFlow id="flow1"
sourceRef="start"
targetRef="check_slot" />
<!-- Exclusive Gateway -->
<bpmn:exclusiveGateway id="check_slot"
name="Слот свободен?"
default="alternative" />
<!-- Sequence Flow с условием -->
<bpmn:sequenceFlow id="flow2"
sourceRef="check_slot"
targetRef="confirm">
<bpmn:conditionExpression xsi:type="tFormalExpression">
<![CDATA[${slotAvailable}]]>
</bpmn:conditionExpression>
</bpmn:sequenceFlow>
<!-- User Task -->
<bpmn:userTask id="confirm" name="Подтвердить запись">
<bpmn:extensionElements>
<camunda:assignee>${registrator}</camunda:assignee>
</bpmn:extensionElements>
</bpmn:userTask>
<!-- End Event -->
<bpmn:endEvent id="end" name="Запись подтверждена" />
</bpmn:process>
<!-- Визуальная информация (BPMNDiagram) — координаты элементов -->
<bpmndi:BPMNDiagram id="diagram">
<bpmndi:BPMNPlane id="plane"
bpmnElement="appointment_process">
<!-- координаты каждого элемента -->
<bpmndi:BPMNShape id="start_shape"
bpmnElement="start">
<dc:Bounds x="100" y="150" width="36" height="36" />
</bpmndi:BPMNShape>
</bpmndi:BPMNPlane>
</bpmndi:BPMNDiagram>
</bpmn:definitions>
8.3. Ключевые XML-теги для аналитика
| Тег | Описание |
|---|---|
<bpmn:process> |
Определяет процесс. isExecutable="true" — исполняемый |
<bpmn:startEvent> |
Start Event. Тип задаётся вложенным тегом (messageEventDefinition, timerEventDefinition) |
<bpmn:endEvent> |
End Event |
<bpmn:userTask> |
Задача, выполняемая человеком. camunda:assignee — ответственный |
<bpmn:serviceTask> |
Автоматическая задача. camunda:delegateExpression — класс-обработчик |
<bpmn:sequenceFlow> |
Связь между элементами. conditionExpression — условие (только для XOR/OR) |
<bpmn:exclusiveGateway> |
XOR шлюз. default="flow_id" — поток по умолчанию |
<bpmn:parallelGateway> |
AND шлюз |
<bpmn:messageFlow> |
Сообщение между пулами. sourceRef и targetRef — элементы |
<bpmn:messageEventDefinition> |
Событие типа «сообщение» |
<bpmn:timerEventDefinition> |
Событие типа «таймер» |
9. Типичные ошибки моделирования BPMN
Ошибка 1: Клиент в Lane (см. раздел 5)
Симптом: Пациент, Клиент, Заказчик — внутри пула организации как Lane.
Решение: Отдельный пул + Message Flow.
Ошибка 2: Sequence Flow через границу пула
Симптом: Сплошная стрелка из одного пула в другой.
Решение: Sequence Flow — только внутри пула. Между пулами — Message Flow.
Ошибка 3: Разные типы шлюзов одним ромбом
Симптом: На диаграмме все ромбы без маркеров — невозможно определить XOR это, AND или OR.
Решение: В BPMN каждый ромб должен иметь маркер (X для XOR, + для AND, O для OR, ✦ для Event-based).
Ошибка 4: Start Event не того типа
Симптом: Process начинается с None Start, но триггер — сообщение извне.
Решение: Если процесс стартует от сообщения — ставьте Message Start. Если по времени — Timer Start.
Ошибка 5: Нет End Event
Симптом: Процесс заканчивается задачей или шлюзом — нет End Event.
Решение: У процесса обязательно должен быть хотя бы один End Event. Если есть ветвления — End Event на каждой конечной ветке.
Ошибка 6: Отсутствие default flow у XOR Gateway
Симптом: У XOR Gateway 3 выхода с условиями, но ни одно не сработало → процесс завис.
Решение: Всегда ставьте default flow (путь без условия) — на случай, если ни одно условие не истинно.
Ошибка 7: Слишком много деталей (Over-modelling)
Симптом: Процесс из 50+ элементов, половину можно объединить.
Решение: BPMN — не протокол каждой секунды. Показывайте шаги, существенные для бизнеса. Не делайте «User Task: Нажать кнопку "Отправить"» — это UI-деталь, не бизнес-шаг.
10. Чек-лист: правильно ли я построил BPMN-диаграмму?
| № | Критерий | Проверка |
|---|---|---|
| 1 | Pool vs Lane — все внешние участники в отдельных пулах? | Да / Нет |
| 2 | Sequence Flow — не пересекает границы пулов? | Да / Нет |
| 3 | Message Flow — соединяет пулы? (пунктир) | Да / Нет |
| 4 | Start Event — есть? Тип соответствует триггеру? | Да / Нет |
| 5 | End Event — есть? Сколько нужно? По одному на ветку? | Да / Нет |
| 6 | Шлюзы — имеют маркер (XOR / AND / OR)? | Да / Нет |
| 7 | Default flow — есть у XOR / OR шлюзов? | Да / Нет |
| 8 | Условия — на Sequence Flow после шлюзов? | Да / Нет |
| 9 | Task Type — User Task vs Service Task не перепутаны? | Да / Нет |
| 10 | Диаграмма читаема — не более 20 элементов на одном экране? | Да / Нет |
11. Вопросы для самопроверки
- Какая разница между Pool и Lane в BPMN?
- Почему нельзя помещать Клиента в Lane внутри пула вашей организации? (объясните причину)
- Чем Sequence Flow отличается от Message Flow?
- Какие 3 типа шлюзов вы знаете? В чём их ключевое различие?
- Что такое Start Event с маркером Timer? Приведите пример.
- Чем отличается User Task от Service Task?
- Что такое «исполняемая модель» BPMN?
- Какие вкладки есть в Properties Panel Camunda Modeler?
- Как в Camunda Modeler добавить условие на Sequence Flow после XOR Gateway?
- Что произойдёт, если ни одно условие XOR Gateway не истинно и не задан default flow?
- Что означает
isExecutable="true"в XML BPMN? - Назовите 2 ситуации, когда нужно использовать BPMN, а не UML Activity.
12. Практическое задание
Задание 1. Pool или Lane?
Даны участники процесса. Для каждого решите: Pool или Lane? Кратко обоснуйте (1 предложение).
| Участник | Контекст |
|---|---|
| Сотрудник | Процесс согласования отпуска (компания) |
| HR-отдел | Тот же процесс отпуска |
| Курьерская служба | Процесс доставки заказа (интернет-магазин) |
| Склад | Процесс отгрузки (интернет-магазин) |
| Платёжная система (Stripe) | Процесс оплаты заказа |
| Бухгалтерия | Процесс выплаты зарплаты |
| Покупатель | Процесс возврата товара (интернет-магазин) |
Задание 2. Исправьте ошибки
Дана некорректная BPMN-диаграмма (текстовое описание). Найдите и исправьте все ошибки:
❌ Исходная диаграмма:
┌──────────────────────────────────────────────────────────────────┐
│ Pool: Интернет-магазин │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Lane: Покупатель ← ??? │ │
│ │ ○ (None) → ⬭ Оформить заказ → ◉ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Lane: Система │ │
│ │ ⬭ Проверить заказ → ◇ (без маркера) "Есть на складе?" │ │
│ │ ├── [Да] → ⬭ Отправить подтверждение → ◉ │ │
│ │ └── [Нет] → ⬭ Уведомить об отсутствии → ◉ │ │
│ └────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘
Какие ошибки вы нашли? Перечислите все.
Задание 3. Постройте BPMN-диаграмму (с правильными пулами)
Кейс: Процесс заказа пиццы онлайн.
Описание процесса:
- Клиент открывает сайт пиццерии, выбирает пиццу из меню
- Клиент добавляет пиццу в корзину, указывает адрес доставки
- Клиент оплачивает заказ онлайн (картой)
- Платёжная система (внешняя) обрабатывает платёж — возвращает успех или ошибку
- Если платёж успешен:
- Система пиццерии получает подтверждение
- Повар (сотрудник пиццерии) получает задание приготовить пиццу
- Повар готовит пиццу (Manual Task)
- Курьер получает задание на доставку
- Курьер доставляет пиццу
- Курьер отмечает заказ как выполненный
- Система отправляет Клиенту уведомление «Пицца доставлена»
- Если платёж не прошёл:
- Система уведомляет Клиента об ошибке
- Клиент может попробовать другую карту (цикл) или отменить заказ
Требования к диаграмме:
- 3 пула: Клиент (свёрнутый), Пиццерия (развёрнутый с Lane: Система, Повар, Курьер), Платёжная система (свёрнутый)
- Message Flow между пулами (клиент → пиццерия, пиццерия → платёжная система, платёжная система → пиццерия, пиццерия → клиент)
- Start Event: None (клиент) / Message (пиццерия — получен заказ) / Message (платёжная система — запрос на оплату)
- End Event: как минимум 2 (успех, ошибка)
- Exclusive Gateway (XOR): проверка платежа
- Parallel Gateway (AND): параллельные действия повара и курьера
- User Task: приготовить пиццу (повар)
- Manual Task: доставить пиццу (курьер)
- Service Task: проверить платёж, отправить уведомление
- Loop (цикл): повтор попытки оплаты (опционально — через XOR назад)
Формат: В виде текстового описания (ASCII-схема с указанием пулов) или скриншот из Camunda Modeler.
Задание 4. Анализ: почему это грубая ошибка?
Даны два варианта одной диаграммы. Ответьте письменно (5–7 предложений):
Вариант A (ошибочный): Пациент — Lane внутри пула «Поликлиника».
Вариант B (корректный): Пациент — отдельный пул; Message Flow между Пациентом и Поликлиникой.
Вопросы:
- Почему Вариант A — грубая ошибка моделирования?
- Какие проблемы возникнут при реализации варианта A как исполняемой BPMN?
- В чём практический вред: что потеряет команда разработчиков, если получит вариант A?
13. Дополнительные материалы
- Инструмент: Camunda Modeler — скачать бесплатно: camunda.com/download/modeler
- Официальная документация: Camunda BPMN Reference — docs.camunda.org/manual/latest/reference/bpmn20/
- Книга: Thomas Allweyer — «BPMN 2.0: Introduction to the Standard for Business Process Modeling» (коротко и понятно)
- Книга: Bruce Silver — «BPMN Method and Style» (для продвинутых, про стиль моделирования)
- Видео: Camunda BPMN Tutorial Series на YouTube (официальный плейлист, ~20 видео по 5–15 минут)
- Шпаргалка: «BPMN 2.0 Symbol Reference» от Camunda (одностраничный PDF со всеми элементами)
- Стандарт: OMG BPMN 2.0 Specification (PDF, ~500 страниц — только если нужно сослаться)
- Практика: Бесплатный курс Camunda BPMN на Camunda Academy (academy.camunda.com)
- Статья: «BPMN vs UML Activity Diagram: When to Use Which?» — краткое сравнение на medium.com
Следующий урок: 05.02 — Продвинутые элементы BPMN: события, подпроцессы, границы