BPMN

Этот документ был подготовлен при помощи ИИ

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

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

Создайте модель

Создайте модель Order Handling типа BPMN 2.0 и откройте её диаграмму.

Путь заказа

1. Создайте начальное событие Order received с триггером «сообщение»: процесс запускает не расписание и не оператор, а пришедший извне заказ.
2. Создайте задачу Check the order и проведите поток управления от события к задаче.
3. Создайте исключающий шлюз In stock? и проведите поток от задачи к нему. Исключающий шлюз выбирает ровно одну ветвь из нескольких.
4. Проведите ветвь out of stock к конечному событию Order rejected и объявите её потоком по умолчанию для шлюза.
5. Проведите ветвь in stock к задаче Reserve stock и задайте ей условие stock available.
6. Продолжите от Reserve stock к задаче Ship the order и к конечному событию Order shipped.

Поток по умолчанию срабатывает, когда не выполнено ни одно условие, поэтому заказ не застрянет на шлюзе. Если условны все ветви, при невыполнении всех условий процесс завершится ошибкой; редактор об этом предупредит.

Завершающих событий в процессе три, по одному на исход: Order rejected, Order shipped и Order cancelled. Общее событие «конец» их не различало бы.

Дорожки

Заказ проверяют продажи, а резервируют и отгружают на складе. Поставьте пул Online retailer и разделите его на дорожки Sales и Warehouse. Перенесите Reserve stock и Ship the order на дорожку склада: узел принадлежит той дорожке, в которой лежит.

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

Если склад не успевает

Что делать, если склад не уложился в срок, тоже описывают на диаграмме. Поставьте на Reserve stock граничное событие с триггером «таймер», проведите от него поток к задаче Cancel the order и дальше к конечному событию Order cancelled.

Граничное событие бывает прерывающим и непрерывающим. Прерывающее останавливает активность: резервирование прекращается, заказ отменяется. Непрерывающее оставляет активность работать и запускает ветвь параллельно — так описывают напоминание или эскалацию.

Данные

Поставьте объект данных Order и проведите ассоциацию данных от него к Check the order — проверка читает заказ. Ассоциация в обратную сторону, от задачи к объекту, означает, что задача его заполняет.

Объект данных описывает то, что живёт внутри одного экземпляра процесса: сам заказ, заявку, черновик письма. Хранилище данных — то, что переживает процесс: каталог товаров, базу клиентов, архив отгрузок.

Смена типа

Тип нарисованного элемента меняется двумя способами: выделите узел и выберите новый тип в разделе Сменить тип его палитры или в поле Type формы свойств. Обычная задача становится пользовательской, сервисной, задачей отправки, получения, ручной, задачей-сценарием или задачей бизнес-правила; исключающий шлюз — включающим, параллельным, событийным или комплексным.

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

Ссылки в форме свойств кликабельны: с потока можно перейти на его источник или цель, с граничного события — на активность, к которой оно прикреплено, с вызова процесса — на вызываемый процесс. Элемент выделяется на диаграмме, где он изображён.

Дерево модели

Диаграмма открывается щелчком по процессу или взаимодействию, которое на ней нарисовано.

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

Проверка

Модель проверяется по ходу редактирования. Уберите у шлюза In stock? поток по умолчанию, оставив обе ветви условными, — появится замечание: «У расходящегося шлюза все исходящие потоки условны, но не задан поток по умолчанию: при ложности всех условий возникнет ошибка выполнения».

Рядом с ним — исправление «Задать поток по умолчанию». Оно показывает, что изменится, и применяется после подтверждения.

Так же находятся узел, недостижимый ни от одного стартового события, поток управления из одного пула в другой, граничное событие, не прикреплённое к активности, и элемент, с которого процесс начинается без стартового события. В каждом замечании указан пункт OMG BPMN 2.0, на котором оно основано.

Обмен с другими инструментами

Модель хранится в том же .bpmn, с которым работают Camunda, bpmn.io и движки процессов. Загрузить модель открывает такой файл, Скачать с форматом BPMN сохраняет модель обратно в него.

Раскладка при обмене не теряется: размеры и положение фигур, изгибы линий возвращаются такими же, какими были, — расставлять диаграмму заново не приходится. Файл, сохранённый без координат, тоже открывается: диаграмму для него редактор построит сам.