Памятка по BPMN / BPMN-диаграммы
Пишу статью в первую очередь для себя, но думаю, что она также будет полезна для начинающих айтишников. А еще статья будет полезна для тех, кому необходимо освежить знания или быстро вспомнить основные вещи, не открывая полный мануал.
Что это?
BPMN — это нотация (или метод, хотя почти везде пишут «система») моделирования или описания бизнес-процессов. Бизнес-процесс представляет из себя логику или же алгоритм работы системы для поставленной задачи. Соответственно, BPMN-диаграмма — это диаграмма, которая описывает бизнес процесс.
Такие диаграммы довольно просто и интуитивно читаются, особенно, если разработчик бизнес-процесса (тот, кто моделировал диаграмму) формировал его по всем правилам и стандартам, а также пытался не нагружать его лишней информацией.
В отдельных случаях с помощью BPMN прорабатывают сложные процессы. Имеется в виду не диаграмма, а именно процесс, то есть разработчик формирует процесс, описывает все условия, пробрасывает потоки и тд. И есть специальные среды разработки, например, Tibco BPM и Camunda BPM.
Но все же, далее речь пойдет в первую очередь о диаграммах, так как это отличный инструмент для того, чтобы каждый участник команды, от менеджера до тестировщика, смогли понять что именно они делают в рамках конкретной задачи.
Из чего состоит?
Еще раз подчеркну, статья нацелена больше на начинающих и как базовая памятка, но никак не исчерпывающая документация. Многие вещи я опускаю ввиду их избыточности или неактульности (по крайней мере в моей личной работе).
Основные элементы, из которых состоит BPMN-диаграмма: события (синий), действия (зеленый), шлюзы (красный) и потоки (желтый).
Основные элементы
Всего элементов больше (есть также комментарии, «дорожки» и артефакты), но они не так важны и можно обойтись без них, а вот обойтись без основных элементов никак не получится.
События(или триггеры) — используются для того, чтобы отобразить какое-то происшествие, например, пришло сообщение в топик. События могут быть стартовыми, завершающими или промежуточными. Стартовые обозначают начало процесса, завершающие — его окончание, а промежуточные события могут приостанавливать выполнение процесса.
Обычно стартовые события имеют тонкую рамку, промежуточные — двойную рамку, а завершающие жирную рамку:
Основные типы событий
Подтипы событий
В нотации второй версии (BPMN2.0) есть еще и другие события, а если быть точным, то стартовые и промежуточные разделены на подтипы. В моей практике событий базового типа было всегда достаточно, чтобы описать бизнес-процесс. Поэтому на подтипах я останавливаться не буду, они больше нужны для разработки в специальных средах вроде Camunda BPM.
Помимо разделения на 3 основных типа, еще есть разделение на типы по характеру работы события. Самые часто используемые:
Основные типы событий по характеру работы
Пустое
Используется чаще всего в описании «подпроцесса» или, когда проектировщик диаграммы просто поленился))
Иногда я сам так делаю, не судите строго ❤️
Сообщение
Используется в тех случаях, когда, например, инициатором для запуска процесса выступает новое сообщение в топике, либо запрос.
Таймер
Почти все кейсы, которые связаны со временем. Например, запуск процесса осуществляется в 12:00 каждый день.
Ошибка
Событие, которое чаще все используют как завершающее. Зачастую, описывая процесс, затрагиваются и негативные сценарии, именно для таких сценариев используют событие с ошибкой (исключение).
Действия(или задачи) используются для отображения функций, которые будут выполняться программой. Также как и события бывают нескольких типов и разные по характеру. Но в своей практике я пришел к тому, что для описания бизнес-процесса с точки зрения аналитики для айтишной команды — использование всех вариантов действий бессмысленно, так как зачастую не все знают и понимают различие. А еще это вызывает небольшой перегруз, но это мое субъективное мнение. Поэтому среди всех действий, что я постоянно использую только два: обычное и «подпроцесс».
Основные типы действий
Обычное
Обычное действие используется для описания активности, которое нельзя никак разбить (по крайней мере я его так использую).
Подпроцесс
Это действие используется, когда необходимо в описываемый процесс внедрить еще один (который например уже описан) как его часть, либо для дальнейшей декомпозиции действия. Ознакомиться с использованием такого действия можно дальше в главе с примерами — «Лента новостей своими руками».
Шлюзы — это элементы, которые используются для введения в процесс развилок, различных условий или дополнительной логики. Чаще всего используются три типа шлюзов: «исключающее ИЛИ», «И» и «включающее ИЛИ». По сути они работают как и их одноименные операторы. Опять же, типов куда больше, особенно в BPMN2.0, но практически всегда используются эти три (по крайней мере мной и вопросов я лишних от коллег не получаю).
Основные типы шлюзов
«Исключающее ИЛИ»
Такой шлюз требуется для того, чтобы разделить выполнение процесса на один из вариантов. То есть по сути это работает как выбор, и в процессе выполняется либо одна ветка, либо другая. Примеры разделения потоков:
Пример 1
Пример 2
«И»
Шлюз «И» используется для того, чтобы распараллелить процесс на две ветки. Соответственно, в процессе с таким шлюзом будут выполняться одновременно обе ветки. Примеры разделения потоков:
Пример 1
Пример 2
«Включающее ИЛИ»
Данный шлюз по сути сочетает в себе функции двух вышеописанных. При его использовании выполнение процесса может как распараллелиться на все ветви, так и разбиться на определенные, удовлетворяющие условию.
Пример с шлюзом «включающее ИЛИ»
Примеры разделения потоков:
Пример
Очень важно отметить то, как двигается «токен» выполнения процесса по потоку и какие бывают нюансы. Это НЕпоможет на собеседовании (а может и поможет), но позволит четко и осознано понимать работу шлюзов, как делать НАДО, как можно, но НЕ СТОИТ, а как точно НЕЛЬЗЯ.
Как делать НАДО (показано в примерах под каждым шлюзом)
Корректнее использовать открывающие шлюзы и закрывающие одного типа, а также не использовать закрывающий шлюз сразу под раскрытие новых веток. Это необходимо для повышения читаемости и исключения различных ошибок (о них дадее).
Как делать НЕ СТОИТ
Я бы не рекомендовал сочетать разные шлюзы при раскрытии веток и их объединении, так как это может запутать человека, который будет смотреть ваш процесс. Еще такое сочетание разных шлюзов может привести к некорректной работе. В примере ниже действие под номером 4 выполнится дважды, хотя процесс был запущен один раз. Так произойдет из-за того, что в процессе используется шлюз «И», как открывающий, и он распараллеливает потоки, а закрывающий ветки — шлюз «ИЛИ», который не собирает потоки воедино.
Так делать НЕ СТОИТ
Работать этот процесс будет. Возможно, в отдельных случаях такой алгоритм работы может даже пригодится. Поэтому это не ошибка, так делать можно, но я бы не рекомендовал, как минимум в силу снижения читаемости логики выполнения процесса. Если нужно в алгоритме сделать так, чтобы какое-то действие выполнялось дважды, то лучше это действие разбить и внести в каждую ветку. В таком виде процесс будет понятнее и вопросов к нему будет меньше.
Как делать НЕЛЬЗЯ
Здесь также речь про сочетание разных шлюзов. В примере ниже действие под номером 4 не выполнится никогда, да и собственно сам процесс тоже никогда не завершится. Произойдет это из-за того, что в качестве закрывающего шлюза выбран «И», который ожидает токены из обеих веток для продолжения процесса, а их никогда не будет. Сочетание шлюзов в таком формате — грубая ошибка.
Так делать НЕЛЬЗЯ
Потоки — тут все очень просто, это стрелка, которая отображает последовательность действий в процессе.
Дорожки — эти элементы являются необязательными, но я лично в своей практике использую их довольно часто для отображения разделения на микросервисы, а также взаимодействий со смежными системами. Дорожка представляет из себя подписанный прямоугольник, внутри которого укладываются те элементы, которые выполняются внутри или причастны к микросервису/системе. На примере все будет понятнее.
Пример с дорожками
В данном примере с помощью дорожек процесс декомпозируется на отдельные микросервисы системы, в которой он[процесс] выполняестя.
Пример с дорожками
Где и как пользоваться?
Есть довольно много вариантов, где и как можно пользоваться нотацией, это могут быть упомянутые выше Tibco BPM, Camunda BPM или же такие инструменты как ARIS, draw.io и тд. Останавливаться более подробно я здесь не буду, так как по большой части все зависит от компании, в которой вы работаете. Либо вам предоставляют специальное ПО для проектирования бизнес-процессов, либо нет. Я предпочитаю в своей практике draw.io, так как он универсален и пользоваться им можно практически везде. Причем это может быть как плагин встроенный во всеми любимый (или нет) Confluence, так и плагин встроенный в вашу любимую IDE. Кстати, при использовании IDE перед нами открывается могучий «docs-as-code».
При использовании плагина draw.io в Confluence работа выглядит также, как и при работе непосредственно на самом ресурсе. Небольшой пример работы в draw.io вы можете посмотреть в моей статье по диаграмме последовательности.
Для установки плагина в IDE, в моем случае это WebStorm от JetBrains можете следовать руководству в картинках ниже:
Руководство
Зайдите в настройки в меню Plugins, далее найдите во вкладке MarketPlace плагин «Diagrams.net Integration» и установите его:
Установка плагина
После установки плагина вам станет доступно создание файла в формате понятном для draw.io:
Лента новостей своими руками
Попробуем вместе спроектировать бизнес-процесс приближенный к рабочим задачам. Предположим, что перед нами стоит цель спроектировать алгоритм по взаимодействию браузера с бэкендом приложения. Необходимо описать процесс с предоставлением пользователю ленты новостей на основе записей друзей и рекомендаций.
Обращаю внимание, что все новые элементы выделены зеленым цветом для наглядности.
У нас получился простой процесс из стартого, завершающего событий и четырех действий:
Поиск друзей и интересов;
Отбор новых записей друзей и рекомендаций;
Отсечение лишних записей;
Сортировка записей по релевантности.
Теперь предлагаю улучшить наш процесс, можем это сделать за счет добавления типов «Сообщение», которые отображают, полученный запрос и отправленный ответ. Также добавляем еще одно действие для наглядности, что мы формируем ответ и возвращаем его. Результат улучшения:
Добавим обработку запроса:
Помимо нового действия с обработкой запроса, в который может быть включена валидация тела запроса, проверка корректности данных и тд, добавилась новая ветка, которая раскрывается с помощью исключающего шлюза. В новой ветке у нас добавилось действие с фиксацией ошибки и новое событие с ошибкой.
Предлагаю теперь немного еще улучшить:
В новой версии процесса мы декомпозировали действия на отдельные ветки и добавили дополнительные условия.
И последнее улучшение, предположим, что архитектура нашего бэкенда состоит из микросервисов. В таком случае будет удобнее раскидать все события и действия в свои «дорожки». Каждая дорожка будет представлять из себя блок с определенным микросервисом:
Теперь стало понятнее где и что у нас происходит в разбивке на отдельные сервисы, но пришел владелец продукта и попросил добавить новый кусок логики — добавление в ленту рекламных записей и описал определенную логику работы процесса. Чтобы аккуратно внедрить этот кусок в наш процесс, мы можем его выделить в виде отдельного подпроцесса. А сам алгоритм описать уже в отдельной диаграмме:
Заключение
BPMN это мощный инструмент, который лично я, как системный аналитик, использую в своей работе практически каждый день. Если сам не проектирую бизнес-процесс, то как минимум изучаю документацию смежников. Очень рекомендую каждому аналитику, а также всем причастным к разработке освоить это дело.
Надеюсь, что в виде шуточной практики мне удалось донести смысл и принцип создания бизнес-процессов, если нет, то жду ваши вопросы в комментариях.
Кстати, у меня есть Telegram-канал Айтишник обыкновенный, где я делюсь опытом и знаниями IT-индустрии. Лучшая поддержка — подписка на мой канал ❤️
А еще рекомендую глянуть мою статью по диаграммам последовательности. Я уверен, что каждый найдет для себя в ней что-то новое.
P.S. Возможно, про какие-то особенности я забыл написать или даже не знал. Поделись в комментариях, если пользуешься чем-то еще, чего я не осветил в этой статье. Если будет что-то дельное, я обязательно добавлю это, а также укажу тебя как соавтора.
Всем добра!
