← вся теориятеория к собесу · BPMN и процессы

BPMN: элементы и шлюзы

Схема BPMN - не картинка для презентации, а программа. Движок берёт фишку и двигает её по стрелкам ровно так, как нарисовано, включая то, что автор нарисовал по невнимательности. Поставил две стрелки из задачи, имея в виду «или-или», - движок понял «и то и другое» и отправил клиенту два письма.

Стержень: в BPMN (business process model and notation) пулы и дорожки задают участников, задачи и подпроцессы - работу, шлюзы - логику. У каждого элемента строгая семантика, и движок исполняет именно её.

// Формулировки: «чем пул отличается от дорожки?», «два потока из задачи без шлюза», «почему процесс завис?»

Токен: фишка, которая ходит по схеме

Представь настольную игру. Стартовое событие кладёт на схему фишку, она идёт по стрелкам от элемента к элементу, задерживается на задачах и исчезает на завершающем событии. Эта фишка называется токеном, и через неё объясняется вообще всё поведение процесса.

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

// Отсюда способ проверять свою схему без движка: веди пальцем токен по каждому возможному пути и вслух говори, сколько их сейчас на доске. Большинство дефектов ловится именно так, за пять минут и до прода.

токен: воображаемая фишка, отмечающая, где сейчас находится экземпляр процесса; их может быть несколько одновременно

Пулы, дорожки и граница участника

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

Правило, которое нарушают чаще всего: поток работ не пересекает границу пула. Между пулами ходят только сообщения. Это не бюрократия нотации - ограничение заставляет вслух проговорить, что именно передаётся наружу, в какой момент и что будет, если ответ не придёт.

// Задачи внутри тоже разные, и разница влияет на требования. Пользовательскую выполняет человек - значит нужны очередь, назначение, срок реакции, замена на время отпуска. Сервисную выполняет система - значит нужны таймаут, число повторов и поведение при ошибке вызова.

Шлюзы: развилка и сборка

Исключающий шлюз, он же XOR - от «исключающее или», крестик в ромбе - пропускает токен ровно по одному пути, по первому истинному условию. Параллельный, он же AND, плюсик в ромбе, запускает все ветки сразу, порождая по токену на каждую. Первый выбирает, второй размножает.

Отсюда два обязательных требования к условиям исключающего шлюза: они покрывают все случаи и не пересекаются. Классическая дыра - «сумма меньше 100 000» на одной ветке и «сумма больше 100 000» на другой. Заявка ровно на сто тысяч не проходит ни туда, ни сюда: токен упирается в шлюз, и экземпляр встаёт. Поэтому явную ветку «иначе» рисуют всегда.

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

Уровни и две разные схемы

Схема на три листа не читается никем, включая автора через месяц. Верхний уровень укладывают в десяток шагов, детали прячут в подпроцессы, которые раскрываются по щелчку. Тогда у руководителя свой уровень, у исполнителя свой, а схема одна.

И полезно честно разделять два жанра. Схема для обсуждения с бизнесом допускает упрощения: тут неважно, прерывающий таймер или нет, важно, что срок есть. Схема под исполнение движком обязана быть полной и однозначной, там каждая недорисованная ветка станет зависшим экземпляром.

// Путаница жанров стоит дорого в обе стороны. Исполняемую схему бизнес не читает и согласовывает не глядя. Обсуждаемую отдают разработке как готовую, и дефекты вылезают уже на проде.

Как отвечать: «Экземпляры процесса зависают и не идут дальше. Где смотреть?»

Первым делом проверю симметрию шлюзов. Классика - ветки разошлись через исключающий шлюз, а собираются через параллельный: сборка ждёт токен со второй ветки, которого не будет никогда, и процесс замирает без всякой ошибки. Второе место - исключающий шлюз, где ни одно условие не сработало, а явной ветки «иначе» нет. Такое обычно живёт на границах диапазонов: меньше ста тысяч и больше ста тысяч, а ровно сто тысяч не подходит ни под одно. Третье - параллельное ветвление без сборки, там наоборот, следующие шаги выполняются по нескольку раз, и клиент получает три одинаковых письма. Все три дефекта ловятся до прода: веду токен по каждому возможному пути и считаю, сколько их на схеме в каждый момент.

Кандидат называет три типовых дефекта с механизмом отказа, приводит конкретный провал на границе диапазона и добавляет способ профилактики.

На чём валятся

−− Разветвляют исключающим шлюзом, а сливают параллельным - процесс замирает навсегда.
−− Рисуют две стрелки из задачи, подразумевая выбор, и получают двойное исполнение.
−− Оставляют дыру на границе диапазона и не делают явную ветку «иначе».
−− Ведут поток работ через границу пула вместо сообщения.
−− Растягивают схему на несколько листов вместо подпроцессов.
−− Отдают в разработку схему, нарисованную для обсуждения с бизнесом.

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 13, остальные разбираются в тренажёре.

#ana_bpm_elements1 / 5
На схеме после задачи сразу идут два исходящих потока без шлюза. Как это читается движком?
A)Выполнится только первый по порядку
B)Выполнится тот, чьё условие истинно
C)Схема будет отклонена как некорректная
D)Оба потока пойдут параллельно
показать ответ и разбор
+D)Оба потока пойдут параллельно
// разбор: Несколько исходящих потоков без шлюза означают безусловное ветвление: токен размножается, и выполняются обе ветки. Авторы часто рисуют так, подразумевая выбор, и получают двойное исполнение следующих шагов. Если нужен выбор — ставят эксклюзивный шлюз с явными условиями.
#ana_bpm_elements2 / 5
Чем шлюз слияния отличается от шлюза ветвления?
A)Формой обозначения на схеме
B)Числом входящих и исходящих потоков
C)Возможностью задавать условия перехода
D)Типом задач, которые к нему примыкают
показать ответ и разбор
+B)Числом входящих и исходящих потоков
// разбор: Тип шлюза один, роль определяется расположением: у ветвления один вход и несколько выходов, у слияния наоборот. Хороший тон — не смешивать роли в одном элементе: шлюз, который одновременно и сливает, и разветвляет, читается плохо и часто скрывает ошибку в логике.
#ana_bpm_elements3 / 5
Параллельный шлюз слился с эксклюзивным: ветки разошлись по XOR, а собираются через AND. Что произойдёт?
A)Процесс завершится нормально
B)Выполнятся обе ветки вместо одной
C)Процесс зависнет в ожидании ветки
D)Токен вернётся на предыдущий шаг
показать ответ и разбор
+C)Процесс зависнет в ожидании ветки
// разбор: XOR отправил токен по одной ветке, а параллельное слияние ждёт токенов со всех входов. Второй не придёт никогда, и процесс замирает молча — без ошибки, просто навсегда. Правило простое: тип слияния должен соответствовать типу ветвления.
#ana_bpm_elements4 / 5
Схема процесса разрослась на три листа и стала нечитаемой. Что сделать в первую очередь?
A)Уменьшить шрифт и уплотнить схему
B)Разбить на верхний уровень и подпроцессы
C)Убрать с неё все исключительные ветки
D)Разделить на схемы по отделам компании
показать ответ и разбор
+B)Разбить на верхний уровень и подпроцессы
// разбор: Читаемая схема верхнего уровня укладывается в десяток шагов, а детали живут в раскрываемых подпроцессах. Так у каждого адресата свой уровень: руководителю нужен обзор, исполнителю — подробности своего куска. Удаление исключений ради красоты убирает как раз самое ценное.
#ana_bpm_elements5 / 5
Чем схема для обсуждения с бизнесом отличается от схемы под исполнение движком?
A)Используемым инструментом рисования
B)Числом дорожек на диаграмме
C)Цветовым оформлением элементов
D)Строгостью семантики и полнотой ветвлений
показать ответ и разбор
+D)Строгостью семантики и полнотой ветвлений
// разбор: Для разговора с людьми допустимы упрощения: главный поток, крупные шаги, часть исключений опущена. Исполняемая схема обязана быть полной и однозначной — движок выполнит ровно то, что нарисовано, включая необработанные ветки, где процесс встанет. Это два разных артефакта, и смешивать их вредно.

дальше

Теорию прочитали. Навык ставится повторением

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

Открыть тренажёр Вся тема: BPMN и процессы