7 вещей, которые надо добавить к BPMN-схеме, чтобы получить процессное приложение

Умение рисовать схемы в BPMN недостаточно для формирования ТЗ и разработки IT-приложения, которое эту схему автоматизирует.  Расскажу о том, что нужно добавить, чтобы автоматизировать процесс BPMN в BPMS-системе на примере Camunda BPM.

1. Процесс

Будем считать, что к нам поступила нормальная схема от аналитиков, которые действительно умеют их составлять. Мы, как автоматизаторы, не ставим под сомнение логику и правильность схем.
Мы должны проверить, что в схеме использованы символы, которые поддерживает наша BPMS. В случае с Camunda BPM смотрим ссылку и ищем, есть ли в нашей модели неопределённые таски, множественные события или параллельные множественные.
Неопределённые таски определяем, множественные события стараемся привести к виду других событий.

В Camunda  предпочитаю покрасить схему так, чтобы было понятно что именно нам предстоит сделать — зеленый делаем средствами BPM, красный — пишем код на Java, фиолетовый — пишем на HTML,JS. Серое — не делаем ничего или используем что-то, что делали раньше.

На этом этапе настраиваем все названия сообщений, таймеры, скрипты в событиях.

2. Модель данных и контекст

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

Пример кусочка модели данных

Над активностями показываем схематично сущность, с которой выполняется работа

Может потребоваться решить вопрос ГДЕ именно, в какой БД и таблицах хранить эти данные.

В Camunda этот вопрос решён из коробки, классы хранятся в Key-value хранилище в SQL-базе, используется ORM MyBatis и работа напрямую с табличками и прочими делами не предполагается.

Так же на этом шаге может захотется натыкать действий вида «Записать в базу», «Считать из базы». Пожалуйста, не делайте этого, потому что схема вырастит минимум в три раза и потеряет свои визуальные приемущества (и перестанет быть схемой от аналитика). Решайте технологические вопросы не трогая схему.

Например в Camunda на каждом из элементов есть листнеры. При попадании процесса на элемент можно вызвать любой джава код.

3. Формы

На этом этапе нам нужно взять и определить как будут выглядеть пользовательские формы (фиолетовые штуки) с диаграммы. Для макетирования я использую Axure.

Пример формы в Axure

Как бы не хотелось наводить красоту, но процессные приложения с точки зрения форм и своей сути довольно простые — нужно доставить какие-то данные до пользователя, собрать с него какие-то другие данные. Так же на этом этапе определяю права на данные в разных задачах (визуализацией формы). В Camunda BPM формы создаются на HTML, Javascript и Angujar. Специальные API предоставляю доступ до контекста процесса, так что остается всё это дело красиво разложить.

4. Шлюзы и бизнес-правила

На этом этапе мы пишем правила для шлюзов и прочие бизнес-правила, если они есть. При написании условий используем данные, которые определили на втором этапе. В Camunda BPM бизнес-правила задаются в DMN нотации.

Пример DMN-таблицы бизнес-правила

А правила на шлюзах пишутся на скриптах, например с помощью Groovy или JavaScript

5. Исполнители

Чтобы пользователи могли выполнять задачи они их должны найти. Поэтому во все пользовательские задачи нужно прописать исполнителей. В Camunda BPM это делается в моделлере.

Бывают более сложные случаи определения исполнителей, например по количеству задач в работе, по нормативам и т.д. Для этого нужно писать код.

6. Код, интеграции

В бизнес-процессах код и интеграции работают ради данных — например, надо сходить в API платежной системы и узнать, пришёл ли платёж. Или получит массив гос.контрактов и найти самый дорогой. Как правило этот код очень высокоуровневный, и если нет у вас не локальных заморочек с точки зрения того как работать с внешними\внутренними системами, то такой код, хотя бы в виде макета, должен уметь писать аналитик.

7. Тестирование

Для проверки работоспособности вашего приложения нужно собрать несколько бизнес-тест кейсов, которые покроют happy path как минимум, а лучше все ветки процесса. Под бизнес-тест кейсом я понимаю нормальные, боевые случаи прохождения процессов. Если у вас процесс «Заказ еды в офис», то кейс это «Заказ в 18:00 пятница, 3 больших пиццы «4сыра», оплата картой, адрес доставки — Зеленоград, к1220″.

Схемы не достаточно

BPMN-схема это только 30% от хорошего приложения, и работы по её превращению в приложение надо сделать достаточно. Зато BPMN это отличная «карта» для начала разработки, которая позволяет не забыть и не потерять важные элементы приложения.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Комментарии

Вам так же понравится

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: