Памятка по BPMN / BPMN-диаграммы
Пишу статью в первую очередь для себя, но думаю, что она также будет полезна для начинающих айтишников. А еще статья будет полезна для тех, кому необходимо освежить знания или быстро вспомнить основные вещи, не открывая полный мануал.
Что это?
BPMN – это нотация(или метод, хотя почти везде пишут «система») моделирования или описания бизнес-процессов. Бизнес-процесс представляет из себя логику или же алгоритм работы системы для поставленной задачи. Соответственно, BPMN-диаграмма – это диаграмма, которая описывает бизнес процесс.
Такие диаграммы довольно просто и интуитивно читаются, особенно, если разработчик бизнес-процесса(тот, кто моделировал диаграмму) формировал его по всем правилам и стандартам, а также пытался не нагружать его лишней информацией.
В отдельных случаях с помощью BPMN прорабатывают сложные процессы. Имеется в виду не диаграмма, а именно процесс, то есть разработчик формирует процесс, описывает все условия, пробрасывает потоки и тд. И есть специальные среды разработки, например, Tibco BPM и Camunda BPM.
Но все же, далее речь пойдет в первую очередь о диаграммах, так как это отличный инструмент для того, чтобы каждый участник команды, от менеджера до тестировщика, смогли понять что именно они делают в рамках конкретной задачи.
Из чего состоит?
Еще раз подчеркну, статья нацелена больше на начинающих и как базовая памятка, но никак не исчерпывающая документация. Многие вещи я опускаю ввиду их избыточности или неактульности(по крайней мере в моей личной работе).
Основные элементы, из которых состоит BPMN-диаграмма: события(синий), действия(зеленый), шлюзы(красный) и потоки(желтый).
Всего элементов больше(есть также комментарии, «дорожки» и артефакты), но они не так важны и можно обойтись без них, а вот обойтись без основных элементов никак не получится.
События(или триггеры) – используются для того, чтобы отобразить какое-то происшествие, например, пришло сообщение в топик. События могут быть стартовыми, завершающими или промежуточными. Стартовые обозначают начало процесса, завершающие - его окончание, а промежуточные события могут приостанавливать выполнение процесса.
Обычно стартовые события имеют тонкую рамку, промежуточные – двойную рамку, а завершающие жирную рамку:
Подтипы событий
В нотации второй версии(BPMN2.0) есть еще и другие события, а если быть точным, то стартовые и промежуточные разделены на подтипы. В моей практике событий базового типа было всегда достаточно, чтобы описать бизнес-процесс. Поэтому на подтипах я останавливаться не буду, они больше нужны для разработки в специальных средах вроде Camunda BPM.
Помимо разделения на 3 основных типа, еще есть разделение на типы по характеру работы события. Самые часто используемые:
Пустое
Используется чаще всего в описании “подпроцесса” или, когда проектировщик диаграммы просто поленился))
Иногда я сам так делаю, не судите строго ❤️
Сообщение
Используется в тех случаях, когда, например, инициатором для запуска процесса выступает новое сообщение в топике, либо запрос.
Таймер
Почти все кейсы, которые связаны со временем. Например, запуск процесса осуществляется в 12:00 каждый день.
Ошибка
Событие, которое чаще все используют как завершающее. Зачастую, описывая процесс, затрагиваются и негативные сценарии, именно для таких сценариев используют событие с ошибкой(исключение).
Действия(или задачи) используются для отображения функций, которые будут выполняться программой. Также как и события бывают нескольких типов и разные по характеру. Но в своей практике я пришел к тому, что для описания бизнес-процесса с точки зрения аналитики для айтишной команды – использование всех вариантов действий бессмысленно, так как зачастую не все знают и понимают различие. А еще это вызывает небольшой перегруз, но это мое субъективное мнение. Поэтому среди всех действий, что я постоянно использую только два: обычное и “подпроцесс”.
Обычное
Обычное действие используется для описания активности, которое нельзя никак разбить(по крайней мере я его так использую).
Подпроцесс
Это действие используется, когда необходимо в описываемый процесс внедрить еще один(который например уже описан) как его часть, либо для дальнейшей декомпозиции действия. Ознакомиться с использованием такого действия можно дальше в главе с примерами – «Лента новостей своими руками».
Шлюзы – это элементы, которые используются для введения в процесс развилок, различных условий или дополнительной логики. Чаще всего используются три типа шлюзов: “исключающее ИЛИ”, “И” и “включающее ИЛИ”. По сути они работают как и их одноименные операторы. Опять же, типов куда больше, особенно в BPMN2.0, но практически всегда используются эти три(по крайней мере мной и вопросов я лишних от коллег не получаю).
“Исключающее ИЛИ”
Такой шлюз требуется для того, чтобы разделить выполнение процесса на один из вариантов. То есть по сути это работает как выбор, и в процессе выполняется либо одна ветка, либо другая. Примеры разделения потоков:
“И”
Шлюз “И” используется для того, чтобы распараллелить процесс на две ветки. Соответственно, в процессе с таким шлюзом будут выполняться одновременно обе ветки. Примеры разделения потоков:
“Включающее ИЛИ”
Данный шлюз по сути сочетает в себе функции двух вышеописанных. При его использовании выполнение процесса может как распараллелиться на все ветви, так и разбиться на определенные, удовлетворяющие условию.
Примеры разделения потоков:
Очень важно отметить то, как двигается «токен» выполнения процесса по потоку и какие бывают нюансы. Это НЕпоможет на собеседовании(а может и поможет), но позволит четко и осознано понимать работу шлюзов, как делать НАДО, как можно, но НЕ СТОИТ, а как точно НЕЛЬЗЯ.
Как делать НАДО(показано в примерах под каждым шлюзом)
Корректнее использовать открывающие шлюзы и закрывающие одного типа, а также не использовать закрывающий шлюз сразу под раскрытие новых веток. Это необходимо для повышения читаемости и исключения различных ошибок(о них дадее).
Как делать НЕ СТОИТ
Я бы не рекомендовал сочетать разные шлюзы при раскрытии веток и их объединении, так как это может запутать человека, который будет смотреть ваш процесс. Еще такое сочетание разных шлюзов может привести к некорректной работе. В примере ниже действие под номером 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. Возможно, про какие-то особенности я забыл написать или даже не знал. Поделись в комментариях, если пользуешься чем-то еще, чего я не осветил в этой статье. Если будет что-то дельное, я обязательно добавлю это, а также укажу тебя как соавтора.
Всем добра!