В BPMN аналитик проводит поток управления из одного пула в другой. Какую семантическую ошибку это создаёт?
Это семантическая ошибка: Sequence Flow нельзя проводить между разными пулами. Между пулами моделируют обмен сообщениями через Message Flow, потому что каждый пул представляет отдельного участника или независимого процесса.
BPMN появился как средство, позволяющее единообразно описывать бизнес-процессы для бизнеса, аналитиков и технических специалистов. Одной из исходных проблем была путаница между внутренним выполнением процесса и взаимодействием независимых участников.
Разделение Sequence Flow и Message Flow отражает это различие: первый показывает порядок действий внутри процесса, второй — факт передачи информации между участниками.
Пул в BPMN задаёт границу ответственности и управления процессом. Если провести через эту границу поток управления, модель создаёт впечатление, будто один участник напрямую управляет внутренними шагами другого.
Это приводит к неверным выводам о связанности систем, ответственности за действия и моменте продолжения процесса. На практике ошибка может породить неправильные требования к интеграции: вместо отправки запроса и ожидания ответа команда начнёт проектировать прямое управление чужим процессом.
Sequence Flow соединяет события, задачи и шлюзы внутри одного пула. Он описывает внутреннюю последовательность: после завершения одного элемента управление переходит к следующему.
Для взаимодействия разных пулов используется Message Flow. Он показывает передачу сообщения между участниками, но не определяет внутренний порядок действий получателя. Получатель может обработать сообщение сразу, поставить его в очередь, отклонить или завершить обработку ошибкой — это моделируется внутри его собственного пула.
Если один пул отправляет запрос другому, в первом пуле обычно показывают отправку сообщения, а во втором — получение сообщения через соответствующее событие или задачу. Последующее выполнение во втором пуле связывается с получением сообщения внутренним Sequence Flow, а не линией управления из первого пула.
Внутри одного пула можно использовать дорожки (Lanes) для распределения ответственности между ролями или подразделениями. Однако дорожки не создают независимых участников: поток управления между ними остаётся допустимым. Это важное отличие дорожки от пула.
Компромисс заключается в уровне детализации. Если показать только сообщение между пулами, модель хорошо отражает границы ответственности, но не раскрывает внутреннюю обработку. Если детализировать оба процесса, схема становится информативнее, но сложнее для чтения и сопровождения.
В процессе интернет-магазина аналитик поместил «Проверить платёж» в пул магазина, а «Подтвердить платёж» — в пул платёжного провайдера. Между задачами он провёл Sequence Flow, из-за чего схема выглядела так, будто магазин передаёт управление конкретной внутренней операции провайдера.
Рассматривались два варианта. Первый — объединить участников в один пул: это упростило бы схему, но скрыло бы внешнюю границу и создало ложное впечатление единого процесса. Второй — оставить отдельные пулы, заменить линию на Message Flow, а внутри каждого пула показать собственную обработку.
Выбрали второй вариант. Магазин отправляет запрос и ожидает сообщение о результате, а провайдер самостоятельно выполняет проверку и возвращает ответ. В результате требования к интеграции стали точнее: были явно определены сообщение запроса, сообщение результата, возможная задержка и ответственность каждого участника.
1. Можно ли провести Message Flow между двумя дорожками одного пула?
Нет, это нарушает смысл нотации. Дорожки разделяют ответственность внутри одного участника, поэтому взаимодействие между ними описывается Sequence Flow. Message Flow предназначен для обмена между отдельными пулами, то есть между участниками или независимыми процессами.
2. Означает ли Message Flow, что получатель обязан немедленно продолжить работу?
Нет. Message Flow фиксирует факт или возможность передачи сообщения, но не задаёт синхронность, время обработки и обязательность успешного результата. Очередь, задержка, повторная обработка, отказ или отсутствие получателя должны быть отражены дополнительными элементами процесса или требованиями к взаимодействию.
3. Что делать, если внутренний процесс внешнего участника неизвестен?
Пул внешнего участника можно оставить свёрнутым, показав только доступные точки обмена сообщениями. Это сохраняет корректную границу ответственности и не выдумывает неизвестную внутреннюю логику.
Если позже появятся подтверждённые сведения о процессе внешней стороны, её пул можно детализировать отдельно. Важно не заменять отсутствие информации проведённым потоком управления: такая детализация будет не уточнением, а недоказанным предположением.