Памятка по BPMN и BPMN-диаграммам

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

Ещё раз подчеркну, статья задумывалась как базовая памятка и помощь для начинающих, а никак не исчерпывающая документация. Многое я опускаю ввиду избыточности или неактульности, по крайней мере в моей работе.

Статья является дублем с Хабра.

BPMN — это нотация (или метод, хотя почти везде пишут «система») моделирования или описания бизнес-процессов. Бизнес-процесс представляет из себя логику (алгоритм) работы системы для достижения поставленной задачи. Соответственно, BPMN-диаграмма — это диаграмма, которая описывает бизнес-процесс. Такие диаграммы довольно просто и интуитивно читаются, особенно если разработчик бизнес-процесса (тот, кто моделировал диаграмму) проектировал его по всем правилам и стандартам, а также старался не нагружать его лишней информацией.

В отдельных случаях с помощью BPMN прорабатывают сложные процессы: разработчик проектирует процесс, описывает все условия, пробрасывает потоки и т. д. Для этого есть специальные среды разработки, например, Tibco BPM и Camunda BPM.

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

Основные элементы, из которых состоит BPMN-диаграмма: события (синий), действия (зелёный), шлюзы (красный) и потоки (желтый).

На самом деле элементов больше — есть также комментарии, «дорожки» и артефакты, — но они не так важны и можно обойтись без них. А вот обойтись без основных элементов никак не получится.

События (триггеры) используются для того, чтобы отобразить какое-то происшествие, например, приход сообщения в топик. События могут быть стартовыми, завершающими или промежуточными. Стартовые обозначают начало процесса, завершающие — его окончание, а промежуточные события могут приостанавливать выполнение процесса.

Обычно стартовые события имеют тонкую рамку, промежуточные — двойную, а завершающиежирную рамку:

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

Помимо разделения на три основных типа, ещё есть разделение на типы по характеру работы события. Самые востребованные:

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

Шлюзы — это элементы, которые используются для введения в процесс развилок, различных условий или дополнительной логики. Чаще всего используются три типа шлюзов: «исключающее ИЛИ», «И» и «включающее ИЛИ». По сути, они работают как и их одноимённые операторы. Опять же, типов куда больше, особенно в BPMN2.0, но практически всегда используются эти три (по крайней мере мной, и лишних вопросов от коллег не получаю).

«Исключающее ИЛИ». Такой шлюз требуется для разделения выполнения процесса на один из вариантов. То есть это работает как выбор, и в процессе выполняется либо одна ветка, либо другая. Примеры:

«И». Шлюз используется для распараллеливания процесса на две ветки, которые исполняются одновременно. Примеры:

«Включающее ИЛИ». Этот шлюз сочетает в себе функции двух вышеописанных: выполнение процесса может как распараллелиться на все ветви, так и разбиться на определённые, удовлетворяющие условию.

Примеры разделения потоков:

Очень важно отметить, как двигается «токен» выполнения процесса по потоку и какие бывают нюансы. Это НЕ поможет на собеседовании (а может, и поможет), но позволит чётко и осознанно понимать работу шлюзов, как делать НАДО, как можно, но НЕ СТОИТ, а как точно НЕЛЬЗЯ.

Как делать НАДО (показано в примерах под каждым шлюзом). Корректнее использовать открывающие шлюзы и закрывающие одного типа, а также не использовать закрывающий шлюз сразу под раскрытие новых веток. Это необходимо для повышения читаемости и исключения различных ошибок (о них далее).

Как делать НЕ СТОИТ. Я бы не рекомендовал сочетать разные шлюзы при раскрытии веток и их объединении, так как это может запутать человека, который будет смотреть ваш процесс. Ещё такое сочетание разных шлюзов может привести к некорректной работе. В примере ниже действие под номером 4 выполнится дважды, хотя процесс был запущен один раз. Так произойдёт из-за того, что в процессе используется шлюз «И» как открывающий, он распараллеливает потоки, а закрывающий — шлюз «ИЛИ», который не собирает потоки воедино.

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

Как делать НЕЛЬЗЯ. Здесь также речь про сочетание разных шлюзов. В примере ниже действие под номером 4 не выполнится никогда, да и сам процесс тоже никогда не завершится. Произойдёт это из-за того, что в качестве закрывающего шлюза выбран «И», который ожидает токены из обеих веток для продолжения процесса, а их никогда не будет. Сочетание шлюзов в таком формате — грубая ошибка.

Потоки — тут всё очень просто: это стрелка, которая отображает последовательность действий в процессе.

Дорожки — эти элементы являются необязательными, но я лично в своей практике использую их довольно часто для отображения разделения на микросервисы, а также взаимодействий со смежными системами. Дорожка представляет из себя подписанный прямоугольник, внутри которого укладываются те элементы, которые выполняются внутри или причастны к микросервису или системе. В этом примере с помощью дорожек процесс декомпозируется на отдельные микросервисы системы, в которой он (процесс) выполняется.

Есть довольно много вариантов, где и как можно пользоваться нотацией. Это могут быть упомянутые выше Tibco BPM, Camunda BPM, или же такие инструменты как ARIS, draw.io и т. д. Писать об этом подробно не буду, так как по большей части всё зависит от компании, в которой вы работаете. Либо вам предоставляют специальное ПО для проектирования бизнес-процессов, либо нет. Я предпочитаю в своей практике draw.io, так как он универсален и пользоваться им можно практически везде. Причём это может быть плагин, встроенный во всеми любимый (или нет) Confluence или в вашу любимую IDE. Кстати, при использовании IDE перед нами открывается могучий «docs-as-code».

При использовании плагина draw.io в Confluence работа выглядит так же, как и при использовании конструктора на сайте. Небольшой пример работы вы можете посмотреть в моей статье про диаграмму последовательности.

Для установки плагина в IDE — в моём случае это WebStorm от JetBrains — можете следовать этому руководству. Зайдите в настройках в меню Plugins, далее найдите во вкладке MarketPlace плагин «Diagrams.net Integration» и установите его:

После этого вам станет доступно создание файла в формате, понятном для draw.io:

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

У нас получился простой процесс из стартового, завершающего событий и четырёх действий:

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

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

Предлагаю теперь немного ещё улучшить:

В новой версии процесса мы декомпозировали действия на отдельные ветки и добавили дополнительные условия.

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

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

BPMN это мощный инструмент, который лично я, как системный аналитик, использую в своей работе практически каждый день. Если сам не проектирую бизнес-процесс, то, как минимум, изучаю документацию смежников. Очень рекомендую каждому аналитику, а также всем причастным к разработке освоить это дело.

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

Кстати, у меня есть Telegram-канал «Айтишник обыкновенный», где я делюсь опытом и знаниями из IT-индустрии. Лучшая поддержка — подписка на мой канал ❤

А ещё рекомендую глянуть мою статью по диаграммам последовательности. Я уверен, что каждый найдёт для себя в ней что-то новое.

P.S. Возможно, про какие-то особенности я забыл написать или даже не знал. Поделитесь в комментариях, если пользуетесь чем-то ещё, что я не осветил в статье. Если будет что-то дельное, я обязательно добавлю, а также укажу вас как соавтора.

Всем добра!