BPMN: основы нотации
BPMN (business process model and notation) спрашивают у обеих ролей аналитика, но по-разному. Бизнесовому - про процессы, участников и то, где процесс буксует. Системному - про исполняемость: схему на BPMN можно загрузить в движок, и он выполнит ровно то, что нарисовано, включая ошибки.
Стержень: пулы и дорожки задают участников, шлюзы отвечают за логику ветвления, события описывают поводы и сроки. Семантика строгая, и это принципиальное отличие от блок-схемы «как нарисовалось».
// Формулировки: «чем пул отличается от дорожки?», «что делает исключающий шлюз?», «почему процесс завис?»
Пулы, дорожки и граница участника
Пул - это самостоятельный участник со своим собственным процессом: организация, подразделение, внешняя система. Дорожка - роль внутри пула, скажем менеджер и бухгалтер внутри пула «Наша компания».
Правило, которое отличает правильную схему от неправильной: поток работ не пересекает границу пула. Внутри пула действия соединяются сплошными стрелками потока, а между пулами летают только сообщения, и рисуют их пунктиром.
Это не формальность ради формальности. Правило заставляет явно проговорить, что именно передаётся между сторонами и в какой момент - а именно на этих передачах и живут все реальные проблемы процесса: потерянные заявки, забытые уведомления, ожидание ответа, который никто не обещал.
// Если на схеме сплошная стрелка потока уходит из одного пула в другой, схема неверна, как бы красиво она ни выглядела. Это первое, что проверяет любой ревьюер, и первое, на чём срезают на собесе.
Токен и симметрия шлюзов
Чтобы понимать шлюзы, нужен один образ - токен. Представь фишку, которая появляется на старте процесса и ползёт по стрелкам от действия к действию. Где фишка, там сейчас идёт работа. Движок BPMN буквально так и работает, а шлюзы - это правила, что происходит с фишкой на развилке.
Исключающий шлюз пропускает фишку ровно по одному пути - по первому условию, которое оказалось истинным. Отсюда два требования: условия должны покрывать все случаи и не пересекаться, а ветка «иначе» обязана быть явной. Иначе при невыполнении всех условий фишку просто некуда деть, и процесс встанет.
Параллельный шлюз наоборот - кладёт по фишке на каждую исходящую ветку. Три ветки, три фишки. Если потом их не собрать симметричным слиянием, каждая доползёт до конца самостоятельно, и следующий шаг выполнится трижды, а завершающее событие сработает три раза. Уведомление клиенту уйдёт три раза - классика.
// Смертельная комбинация: разошлись по исключающему шлюзу, а собираются через параллельное слияние. Слияние ждёт фишку с каждого входа, а пришла всего одна - вторая не появится никогда. Процесс замирает молча, без ошибки и без записи в лог, и обнаруживается это через неделю по жалобе клиента.
- токен
- условная фишка исполнения, которая движется по схеме. Реальной сущности в системе ей не соответствует, зато с ней вся логика шлюзов становится очевидной
Инклюзивный шлюз и почему его боятся
Инклюзивный шлюз запускает произвольное подмножество веток - все, чьи условия оказались истинными. Может одну, может три, может ни одной. В теории удобно: «согласовать у юриста, если сумма больше миллиона, и у безопасности, если контрагент новый» ложится на него идеально.
На исполнении начинаются трудности. Слиянию нужно понять, каких фишек ждать, а каких не будет никогда, и для этого движку приходится анализировать граф схемы вперёд. На простых линейных схемах это работает, а на схемах с циклами даёт либо зависания, либо преждевременное продолжение - процесс поехал дальше, не дождавшись согласования, которое ещё шло.
// Практическое правило: в исполняемой схеме надёжнее разложить ту же логику на исключающие и параллельные шлюзы, даже если схема станет на пару элементов длиннее. Читаемость почти не пострадает, а предсказуемость вырастет заметно.
Как отвечать: «Процесс завис и не идёт дальше. Где смотреть?»
Первым делом проверю симметрию шлюзов. Классика - ветки разошлись через исключающий шлюз, а собираются через параллельное слияние: оно ждёт фишку с каждого входа, а придёт только одна, вторая не появится никогда. Процесс замирает молча, без ошибки, и по логам этого не видно. Второе место - исключающий шлюз без ветки «иначе»: если ни одно условие не выполнилось, фишку некуда девать. Третье - параллельное ветвление без слияния, там наоборот, следующие шаги выполняются по нескольку раз, и клиент получает три одинаковых письма. Все три ловятся до прода: я прогоняю схему по чек-листу и мысленно веду фишку по каждому возможному пути, включая тот, где все условия ложны.
Кандидат называет конкретные дефекты вместе с механизмом отказа и добавляет способ профилактики. Ответ звучит как описание того, что человек уже разбирал, а не как список из учебника.
На чём валятся
- −− Разветвляют исключающим шлюзом, а сливают параллельным - процесс замирает молча и навсегда.
- −− Ставят параллельное ветвление без слияния и получают многократное выполнение следующих шагов.
- −− Ведут сплошной поток работ через границу пула вместо потока сообщений.
- −− Не делают явную ветку «иначе» на исключающем шлюзе.
- −− Тянут инклюзивный шлюз в исполняемую схему с циклами.
Проверьте себя
Пять вопросов из банка по этой подтеме. Всего их 15, остальные разбираются в тренажёре.
- Сколько стартовых событий допустимо в одном пуле?A)Ровно одно, иначе схема некорректнаB)Несколько, если процесс запускается по-разномуC)Не больше двухD)Стартовое событие вообще не обязательно
показать ответ и разбор
+B)Несколько, если процесс запускается по-разному// разбор: Процесс может стартовать разными способами: по расписанию, по приходу заявки, по сообщению из другой системы. Каждый повод — своё стартовое событие со своим типом. Важно другое: у каждого пути должно быть завершающее событие, иначе на схеме остаются висящие концы.
- Что делает эксклюзивный шлюз (XOR) при разветвлении?A)Запускает все ветки одновременноB)Запускает ветки, условия которых истинныC)Ожидает завершения всех входящих ветокD)Выбирает ровно одну ветку
показать ответ и разбор
+D)Выбирает ровно одну ветку// разбор: XOR пропускает поток строго по одному пути — по первому условию, которое оказалось истинным. Отсюда два правила: условия должны покрывать все случаи и не пересекаться, а ветку «иначе» лучше делать явной. Иначе токен упирается в шлюз и процесс встаёт.
- Параллельный шлюз разветвил процесс на три ветки, слияния нет. Что будет?A)Процесс завершится по самой быстрой веткеB)Схема не пройдёт валидацию в редактореC)Каждая ветка дойдёт до конца самостоятельноD)Ветки выполнятся последовательно
показать ответ и разбор
+C)Каждая ветка дойдёт до конца самостоятельно// разбор: Параллельный шлюз порождает по токену на ветку, и без слияния каждый живёт своей жизнью до завершающего события. Обычно это не то, что задумано: следующий шаг выполнится трижды, а завершающее событие сработает три раза. Симметричное слияние возвращает единственный токен.
- Как в BPMN связать действия в двух разных пулах?A)Потоком сообщенийB)Обычным потоком работC)Ассоциацией с текстовой пометкойD)Общим шлюзом на границе пулов
показать ответ и разбор
+A)Потоком сообщений// разбор: Поток работ не пересекает границу пула — внутри пула свой процесс со своими токенами. Взаимодействие участников идёт только через поток сообщений, пунктирную стрелку. Это не формальность: правило заставляет явно проговорить, что именно передаётся между сторонами и в какой момент.
- Почему инклюзивный шлюз (OR) считают рискованным в исполняемых схемах?A)Его не поддерживают движки процессовB)Он допускает только два исходящих потокаC)Он требует обязательного таймераD)Слияние должно ждать только стартовавшие ветки
показать ответ и разбор
+D)Слияние должно ждать только стартовавшие ветки// разбор: OR запускает произвольное подмножество веток, и слиянию нужно понять, каких токенов ждать, а каких не будет никогда. Движку приходится анализировать граф, и на сложных схемах с циклами это даёт зависания или преждевременные продолжения. Обычно надёжнее разложить логику на XOR и параллельные шлюзы.
дальше
Теорию прочитали. Навык ставится повторением
В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.