За короткий промежуток времени был сделан большой скачок в разработке языков на основе XML для реализации бизнес-процессов для Web-сервисов. Такие языки, как WSBPEL (Web Services Business Process Execution Language), служат для формального описания бизнес-процессов . Отличительной особенностью языков такого формата является то, что они были оптимизированы для описания процессов внутри BPM-систем и их взаимодействия с другими.
Оптимизация этих языков для приложений сделала их менее удобными для использования людьми (включая разработку Бизнес-процессов, управление ими, мониторинг). Для описания бизнес-процессов WSBPEL использует блоки и диаграммы. В нем применены принципы формальных математических моделей (например, pi-calculus1).
Все это способствовало формированию основ выполнения Бизнес-процессов для обработки комплексных внутренних и внешних B2B взаимоотношений, а также выгодного использования Web-сервисов. Для WSBPEL характерно то, что сложные бизнес-процессы могут быть организованы в формате потенциально сложных, разрозненных и интуитивно непонятных моделей, которые с легкостью обрабатываются программами и приложениями, однако, сложны для понимания бизнес-аналитиками и менеджерами, задачами которых являются разработка, управление и мониторинг Процессов. Поэтому языки на основе XML для реализации бизнес-процессов для Web-сервисов не ориентированы на создание удобства использования и способности к взаимодействию на уровне людей.
Людям, занимающимся бизнесом, крайне удобно работать с Бизнес-процессами, отображаемыми в виде блок-схем. Множество бизнес-аналитиков проектируют и описывают бизнес-процессы компаний с помощью простых блок-схем, вследствие чего возникла нерешенная техническая проблема, заключающаяся в различии форматов исходных проектов бизнес-процессов и языков исполнения бизнес-процессов (WSBPEL и др.). Для решения этой проблемы потребовалось создание формального механизма соответствия визуализации бизнес-процессов (нотации) необходимому языку исполнения бизнес-процессов (BPM execution language).
Взаимодействие людей (а не операций приложения) в бизнес-процессах могло быть решено благодаря стандарту BPMN (Business Process Model and Notation). Использование BPMN позволяет создавать множество диаграмм для использования людьми, разрабатывающими бизнес-процессы и управляющими ими. Благодаря BPMN, также осуществляется и соотнесение модели бизнес-процесса с языком исполнения (WSBPEL). Таким образом, создание BPMN обеспечило появление механизма стандартной визуализации бизнес-процессов, описанного с помощью языка исполнения оптимизированных бизнес-процессов.
Стали понятными изображенные с помощью графической нотации внутреннние процедуры компаний, а сами компании получили возможность доступа к стандартной работе с этими процедурами. На данный момент существует множество инструментов и методик моделирования бизнес-процессов.
Персонал переходит из одной компании в другую, сами компании объединяются и распадаются, — все это требует от бизнес-аналитика понимания полимасштабных представлений моделей бизнес-процессов, т.е. потенциально разных моделей одного и того же Процесса на разных его стадиях (включая разработку, внедрение, выполнение, мониторинг и проведение анализа). Следовательно, использование стандартизированной графической нотации может облегчить понимание процесса Взаимодействия и транзакций внутри одной компании или между взаимодействующими компаниями.
Результатом этого является гарантированное взаимопонимание между участниками бизнес-процессов, что поможет компаниям быстро подстраиваться под новые внутренние и внешние (B2B) обстоятельства. Для большей читабельности и гибкости в данной нотации продолжены традиции нотаций блок-схем. Семантика исполнения, описанная в ней, полностью формализована. Для создания нотации нового поколения, в которой сочетались бы читабельность, гибкость и способность к расширению, группа OMG использовала опыт использования других нотаций бизнес-процессов, предшествующих BPMN.
Благодаря тому, что при разработке BPMN была использована B2B концепция построения бизнес-процессов, были расширены возможности нотации в отношении публичных и приватных Процессов, Хореографии (Choreography), а также обработки ошибок, транзакции и компенсаций.
7.1. Область применения BPMN
В данной спецификации рассматриваются нотация, варианты моделирования бизнес-процессов, а также формат обмена данными, применение которых поможет пользователям успешно осуществлять использование терминов нотации BPMN (как в моделях, так и на диаграммах) и их замещение при работе с различными инструментами моделирования. Задача данного документа – показать гибкость использования одних и тех же объектов нотации в различных средах моделирования бизнес-процессов.
В спецификации BPMN 2.0 содержится более подробное, нежели содержащееся в спецификации BPMN 1.2, описание возможностей и областей использования нотации, а именно:
- Формализация семантики исполнения всех существующих элементов BPMN,
- Определение механизма изменения как расширений модели бизнес-процесса, так и для расширений графических элементов,
- Детализация состава и корреляции События,
- Расширение определения пользовательских действий,
- Введение элемента Хореография (Choreography)и описание данной модели.
Данная спецификация также разрешает некоторые несоответствия и неточности спецификации BPMN 1.2.
Нотация BPM заключает в себе концепцию моделирования, применяемую для Бизнес-процессов, что, соответственно, исключает рассмотрение других типов моделирования, осуществляемого различными организациями для ведения деловой деятельности. По этой причине в данной спецификации не затронуты следующие аспекты:
- Определение типов организационных структур и их ресурсов,
- Функциональное моделирование структуры организации,
- Создание моделей данных и информационных моделей,
- Моделирование стратегии,
- Создание бизнес-правил.
Поскольку все вышеперечисленные аспекты высокоуровнего моделирования прямо или косвенно относятся к Бизнес-процессам, взаимосвязь нотации BPMN с другими типами высокоуровнего моделирования можно формально определить как BPMN и его взаимосвязь с другими спецификациями.
Несмотря на то, что BPMN описывает поток данных (Сообщений) и связь артефактов с Действиями, её нельзя назвать языком потока данных. Также в спецификацию не включена информация о выполнении операций в режиме симуляции деятельности, мониторинге и разворачивании Бизнес-процесса.
В BPMN 2.0 можно найти соответствия с несколькими языками исполнения бизнес-процессов, таких как WS-BPEL 2.0. Данная спецификация содержит информацию о соответствии ряда параметров BPMN языку WS-BPEL 2.0. Поиск соответствий данной нотации другим стандартам требует дополнительного изучения.
Для определения типов данных, выражений и сервисных операций в данной спецификации также использованы другие стандарты: XML Schema, XPath, и WSDL соответственно.
7.1.1. Использование BPMN
Моделирование бизнес-процессов предназначено для описания взаимодействия между огромным количеством информации и множеством целевых групп. BPMN объединяет возможности различных типов моделирования, что позволяет создавать непрерывные (end-to-end) бизнес-процессы. С помощью элементов BPMN пользователи могут легко отделять одну часть диаграммы от другой. Существует три основных типа компонентов (sub-model) модели бизнес-процесса end-to-end:
1. Процесс (Оркестровка), включающий:
a. Приватные невыполняемые (внутренние) Бизнес-процессы (Private non-executable (internal) Business Processes).
b. Приватные выполняемые (внутренние) Бизнес-процессы (Private executable (internal) Business Processes).
c. Публичные Процессы (Public Processes).
2. Хореография (Choreography).
3. Взаимодействие (Collaborations), которое может содержать Процессы и/или Хореографии.
a. Вид обмена сообщениями.
Приватный (внутренний) Бизнес-процесс (Private (Internal) Business Processes)
Приватные Бизнес-процессы (Private (internal) Business-Process) относятся к внутренним процессам компании. Такие Процессы обычно называют Процессами потока операций или Процессами BPM (см. фигуру 10.4). Другое их название – Оркестровка сервисов (используется в веб-сервисах). Приватные процессы могут быть выполняемыми и невыполняемыми.
Выполняемый Процесс моделируется для исполнения в соответствии с семантикой, описанной в главе 14. Время от времени на определенных этапах выполнения Процесса может недоставать информации, необходимой для того, чтобы Процесс оставался выполняемым. Невыполняемый Процесс моделируется с целью описания поведения Процесса с точки зрения разработчика модели. Таким образом, информация, необходимая для выполнения Процесса (например, условное выражение), обычно не включается в невыполняемый Процесс.
В случае, если используются Зоны ответственности (например, Взаимодействие, см. ниже), то приватный Бизнес-процесс не выходит за рамки Пула, а Поток операций данного Процесса, содержащийся в этом же Пуле, не пересекает его границ. Поток Сообщений, однако, может выходить за рамки Пула для того, чтобы отобразить взаимодействие между отдельно взятыми приватными Бизнес-процессами.
Фигура 7.1 – Пример приватного Бизнес-процесса
Публичный Процесс
Публичный Процесс (Public Process) служит для отображения взаимодействия между приватным Бизнес-процессом и другим Процессом или Участником (см. фигуру 7.2). В его состав входят лишь те Действия, которые обычно используются для отображения сообщения с другими Участниками. Все остальные «внутренние» Действия приватного Бизнес-процесса не входят в публичный Процесс.
Таким образом, посредством публичного Процесса внешний мир может наблюдать за Потоками сообщений и порядком, в котором эти Потоки сообщений должны взаимодействовать с Процессом. Публичный Процесс может моделироваться как отдельно от Взаимодействия, так и с ним, что помогает показать обмен Сообщениями между Действиями публичного Процесса и другими Участниками. Обратите внимание, что в BPMN 1.2 публичный Процесс назван абстрактным.
Фигура 7.2 – Пример публичного Процесса
Взаимодействие
C помощью Взаимодействия (Collaboration)отображаюся взаимоотношения между двумя или более бизнес-сущностями. Обычно в состав Взаимодействия входят две или более Зоны ответственности, представляющие собой Участников Взаимодействия. Обмен Сообщениями между этими Участниками отображается при помощи Потока сообщений, соединяющих два Пула или объекты в них.
Также отображаются и Сообщения, входящие в состав данного Потока сообщений. Взаимодействие может отображаться в виде двух или более сообщающихся между собой публичных Процессов (см. фигуру 7.3). Публичные Процессы и Действия, предназначенные для выполнения Участниками Взаимодействия, могут рассматриваться в качестве точек соприкосновения (touch-points).
Соответствующие внутренние (выполняемые) Процессы содержат, как правило, намного больше Действий и информации, чем публичные Процессы. Также Пул МОЖЕТ представлять собой черный ящик (black box) или, другими словами, быть пустым. Хореография МОЖЕТ отображаться в пространстве между Пулами, поскольку она разделяет пополам соединяющие их Потоки операций. Во Взаимодействии допускается использование любых комбинаций Пулов, Процессов и Хореографий.
Фигура 7.3 – Пример Процесса Взаимодействия
Хореография (Choreography)
Стандартный Процесс существует внутри Зоны ответсвенности, а Xореография осуществляется между Зонами ответсвенности.
Хореография (Choreography) похожа на приватный Бизнес-процесс, т.к. состоит из последовательности Действий, Событий и Шлюзов (см. фигуру 7.4). Отличие Хореографии заключается в том, что под Действиями в ней подразумеваются взаимоотношения, представляющие собой обмен одним или более Сообщениями между двумя или более Участниками. Ещё одним отличием Хореографии от стандартного Процесса является то, что в ней нет центрального контроллера Процесса, ответственной за него сущности или наблюдателя.
Фигура 7.4 – пример Хореографии
Обмен сообщениями (Conversations)
Диаграмма Обмена сообщениями (Conversation) является частным случаем использования диаграммы Взаимодействия и его неформального описания. При этом, однако, Пулы, входящие в Обмен сообщениями, обычно не содержат Процессов, а Хореография (Choreography), как правило, не располагается между Пулами диаграммы Обмена сообщениями. Обмен сообщениями представляет собой логическое отношение типа обмен сообщениями. На деле логическое отношение часто касается бизнес-объектов коммерческих объединений (к примеру, заказ товаров, их перевозка и доставка, выписка счета)
Компоненты Обмен сообщениями связаны друг с другом и отражают определенные бизнес-сценарии. Рассмотрим пример из логистики. Процесс пополнения запасов товаров включает следующие типичные сценарии: создание заказа, назначение перевозчика товара (сюда входят различные заказы на покупку), карантин, оплата, отвод. Таким образом, на диаграмме Обмена сообщениями (например, такой, что отображена на фигуре 7.5) шестиугольниками показан обмен сообщениями между Участниками (Пулами). Это обеспечивает так называемый «вид с высоты птичьего полета» различных Обменов сообщениями, относящихся к одной области.
Фигура 7.5 – Пример диаграммы Обмена сообщениями
Диаграмма Точек зрения
Поскольку при помощи диаграммы BPMN МОЖЕТ изображаться Процесс с несколькими Участниками, то каждый из участников может по-разному понимать диаграмму, т.е. у каждого из них есть собственная точка зрения по поводу того, каким образом они будут участвовать в Процессе. Некоторые из Действий будут для кого-то из Участников внутренними (т.е. будут выполняться под контролем этого Участника), а некоторые – внешними.
Любой Участник по-своему воспринимает то, какими должны быть внутренние и внешние Действия. Во время выполнения Процесса разница между внешними и внутренними Действиями влияет на то, каким образом данный Участник определяет статус какого-то из Действий или выявляет проблему. Однако сама диаграмма всегда означает одно и то же.
На фигуре 7.3 изображен Бизнес-процесс, который может рассматриваться разными Участниками по-разному. С одной стороны, есть Пациент (Patient), с другой стороны – офис Доктора (Doctor’s office). На диаграмме показаны Действия обоих Участников Процесса, однако, когда Процесс выполняется, каждый из Участников контролирует выполнение лишь собственных Действий. Несмотря на то, что для каждого Участника важна его точка зрения на Процесс, на данный момент в BPMN нет никакого графического механизма отображения точек зрения. Разработчику модели или производителю инструмента моделирования предоставляется возможность вводить собственные графически отображаемые реплики о точках зрения на диаграмму.
Понимание поведения диаграммы
На протяжении данного документа обсуждается то, каким образом в Процессе задействован Поток операций. Для облегчения восприятия материала вводится элемент «токен». Токен пересекает Поток операций и проходит сквозь элементы Процесса. Токен является теоритическим понятием и используется для определения поведения выполняемого Процесса.
Поведение элементов Процесса определяется путем описания их взаимодействия с токеном, который пересекает Процесс. Однако для инструментов моделирования и исполнения, работающих с BPMN, использование токенов НЕ является ОБЯЗАТЕЛЬНЫМ условием.
Стартовое событие формирует токен, который в итоге ДОЛЖЕН завершится Конечным событием (Конечное событие МОЖЕТ БЫТЬ скрытым в случае, если оно не отображается на диаграмме). Маршрут токена должен легко отслеживаться на протяжении всей диаграммы Процесса, содержащей Потоки операций, Шлюзы и Действия.
Примечание: токен не пересекает Поток сообщений, поскольку его пересекают Сообщения (ясно из названия).
- Область действия документа
- Соответствие требованиям спецификации
- Нормативные ссылки
- Термины и определения
- Символы
- Дополнительная информация
- Общее представление
- Элементы BPMN
- Типы Диаграмм Бизнес-процессов (BPMN Diagram Types)
- Структура нотации BPMN
- Шлюзы (Gateways)
- Общие элементы (Common Elements)
- Обмен Сообщениями (Conversations)
- Взаимодействие (Collaboration)
- Процесс
- Процесс. Распределение ресурсов
- Процесс. Участие людей
- Процесс. Подпроцесс
- Процесс. Действие Вызов
- Процесс. Представление XML-схемы для Действий
- Процесс.Компоненты и Данные
- Процесс. Семантика исполнения для данных
- Процесс. Событие
- Процесс. Конечное событие
- Процесс. Элементы EventDefinition
- Процесс. Обработка Событий
- Процесс. Представление XML-схемы для пакета События
- Процесс. Шлюзы
- Процесс. Компенсация
- Процесс. Экземпляры Процесса, Немоделируемые Действия и Публичный Процесс
- Главная
- Нотация BPMN 2.0
- Область применения и использование нотации BPMN 2.0
Источник: www.elma-bpm.ru
BPMN Примеры
Рекомендации по созданию диаграмм процессов BPMN 2.0.
- BPMN Примеры
- Бизнес-правила и BPMN
- Зависимые экземпляры
- Принцип четырех глаз
- Ежемесячное выставление счетов
- Требуется дополнительная информация
- Обработка партии заказов
- Переназначение пользовательских задач
- Двухэтапная эскалация
- Избегайте пересечения потоков
- Соглашения об именах
- Симметричное моделирование
- Использовать равные размеры задач
Бесплатный BPMN инструмент
Cawemo — это бесплатный онлайн-инструмент для разработки, обсуждения и обмена диаграммами BPMN с вашей командой.
Обзор
Мы преподавали BPMN тысячам людей, и мы применяем обозначения в нашей ежедневной проектной работе с 2007 года. Ниже вы можете найти множество примеров BPMN общих проблем моделирования. Независимо от вашего конкретного проекта или вашей отрасли, есть много общих вопросов об использовании BPMN. По нашему опыту, большинство приведенных ниже примеров BPMN полезны для любого пользователя BPMN.
Мы присоединились к OMG в 2009 году как влиятельный член. С тех пор мы участвуем в разработке BPMN 2.0.
BPMN Примеры
Бизнес-правила и BPMN
Сценарий моделированияo
Предположим, мы хотим моделировать процесс в BPMN, и процесс вызывает некоторые бизнес-правила. Мы будем использовать пример создания счета. Чтобы создать счет, необходимо рассчитать скидку. Сумма заказа и тип клиента являются соответствующими критериями для расчета скидки.
Это очень простой пример, который покажет нам, где применять BPMN, а где нет.
Решение как диаграмма BPMN 2.0
Объяснение
Во время моделирования мы фокусируемся на потоке процесса. В этом примере процесс имеет два шага. Скидка рассчитывается до создания счета. Результат — очень простой процесс.
Не имеет смысла моделировать расчет самой скидки в модели BPMN (см. Пример ниже). Для дерева решений правил, для каждого дополнительного критерия, мощности будут расти экспоненциально. Это не то, что мы хотим в модели BPMN.
Поэтому имеет смысл разделить процессы и бизнес-правила.
Неправильный способ моделирования
Зависимые экземпляры
Сценарий моделирования
Предположим, мы хотим моделировать процесс с совпадающими экземплярами. Мы используем простой пример. Если выполняется одна кредитная проверка клиента, мы не хотим, чтобы еще одна кредитная проверка для одного и того же клиента была выполнена одновременно.
Причиной может быть то, что общее количество проведенных кредитных проверок влияет на результат проверки.
Предположим, что мы выполняем кредитную проверку для клиента, и мы получаем второй запрос для одного и того же клиента одновременно.
Что общего у всех решений, так это то, что каждый новый экземпляр должен проверять совпадение экземпляров на уровне данных перед началом фактической проверки кредита.
Решение с сигнальным событием
запуск экземпляров одного и того же клиента?
и того же клиента?
Объяснение
Событие сигнала — это самый простой и компактный способ моделирования взаимодействия между различными экземплярами. Проблема сигнала заключается в том, что он функционирует как широковещательный и не адресует какой-либо конкретный экземпляр. Итак, строго говоря, клиент игнорируется, и все ожидающие экземпляры ловят его.
Решение с событием Message
проверить на ожидание
Объяснение
Это решение немного сложнее, так как вам нужно определить получателя (один экземпляр) сообщения. Это вызывает второй запрос данных до конца экземпляра. Однако это правильный способ решить проблему, возникающую в решении сигнального события.
Решение с таймером и циклом
Объяснение
В этом примере нам не нужна связь между экземплярами. Сам экземпляр проверяет периодичность, если он может перейти к проверке кредита. Недостатком является то, что это может вызвать задержки и накладные расходы из-за цикла.
Принцип четырех глаз
Сценарий моделирования
Мы хотим моделировать следующую ситуацию с использованием BPMN 2.0. Для запроса (например, оплаты) необходимы два разрешения двух разных людей. Механизм процесса должен гарантировать, что оба утверждения будут выполнены до утверждения запроса. Ручные шаги, выполняемые двумя утверждающими, также должны быть смоделированы на диаграмме BPMN. Решение об одобрении выполняется с использованием портала с списком задач.
Случаи использования
Варианты использования для этого шаблона многочисленны. Вот некоторые примеры:
- Утверждение оплаты
- Утверждение счета
- Утверждение контракта
- .
Решение как диаграмма BPMN 2.0
Процеесы в двигателе
Объяснение
Мы используем отдельные пулы для Process Engine, для первого утверждающего и для второго утверждающего. Таким образом, мы можем четко определить, кто контролирует какой процесс.
В пуле двигателей используются пользовательские задачи. Эти пользовательские задачи соответствуют задачам, которые показаны в списке задач 1-го и 2-го утвердителей.
Взаимодействие между задачами пользователя в двигателе и между ручным процессом утвердителей моделируется с использованием потоков сообщений. Эти потоки сообщений инкапсулируют шаги документации, которые должен выполнить утвердитель, чтобы выполнить пользовательскую задачу.
Сам список задач не моделируется, чтобы уменьшить сложность.
Вариации
Утверждение в качестве сбитых пулов
Определение приемника с помощью LDAP
Ежемесячное выставление счетов
Сценарий моделирования
В этом примере объясняется очень распространенная борьба со структурированием диаграмм BPMN 2.0. Допустим, есть адвокат, который предлагает юридические консультации своим клиентам. Услуга работает следующим образом: клиенты могут обращаться за юридической консультацией, когда им это нужно. Адвокат предоставляет запрошенный совет и ставит оплачиваемые часы на лист времени клиента. Когда месяц закончился, бухгалтер-юрист определяет оплачиваемые часы на основе расписания и создает счет-фактуру.
Этот пример иллюстрирует очень общий сценарий моделирования. Это не те шаги процессов, которые сложны, это структура диаграммы.
Решение как диаграмма BPMN 2.0
создать и отправить
Объяснение
Наиболее важным аспектом диаграммы является ее структура.
Процесс предоставления юридических консультаций выполняется много раз в месяц. Процесс ежемесячного выставления счетов выполняется только один раз в месяц. Поэтому эти два процесса должны быть смоделированы как отдельные пулы.
Конечно, эти два пула не полностью независимы друг от друга. Зачем? Они работают над одними и теми же данными — листом времени клиента. Наша способность моделировать такое связанное с данным соединение очень ограничена в BPMN. Это связано с тем, что BPMN ориентирован скорее на поток управления, чем на поток данных.
Однако мы можем использовать элемент хранилища данных для моделирования этого соединения на уровне данных.
Неправильный способ моделирования
создать и отправить
Объяснение, почему это неправильно
В этом примере оба процесса смешиваются в один. Это — в лучшем случае — очень неявный способ его моделирования. Это означало бы, что при каждом предоставленном юридическом консультировании счет-фактура отправляется раз в месяц. Этот способ моделирования в большинстве случаев является неправильным.
Дополнительная информация, необходимая после задачи пользователя
Сценарий моделирования
Предположим, мы хотим моделировать следующий сценарий: мы хотим выполнить пользовательскую задачу, которая выполняется пользователем на портале. После завершения пользовательской задачи может потребоваться дополнительная информация. В этом случае процессор процесса отправляет запрос информации другому пользователю (решение 1) или технической службе (решение 2).
Источник: camundarus.ru
Пример формирования схемы процесса с использованием инструмента bpmn
Практически каждому из нас в работе когда-нибудь приходилось описывать какие-либо процессы, включающие в себя взаимодействие нескольких участников со специфическими ролями, находящихся в разных подразделениях или на разных территориях, использующих разнообразные способы коммуникации и передачи данных, документов и других артефактов. Если процесс достаточно простой, его можно описать в текстовом виде, разделяя по пунктам.
Но если процесс сложный, с большим количеством участников, промежуточных задач и подпроцессов, имеющий разные варианты прохождения (ветвления), то для его понимания требуется дополнительная визуализация, т. е. построение схемы. Как правило, под схемой процесса мы подразумеваем блок-схему. При этом схема должна быть интуитивно понятной неподготовленному человеку.
Для этой цели необходимо наличие стандартизованного набора условных обозначений, понятных всем пользователям: аналитикам, менеджерам, техническим специалистам и др. На сегодняшний день существует несколько стандартов спецификаций для моделирования бизнес-процессов. Одним из них является BPMN (Business Process Model and Notation) — модель и нотация(описание) бизнес-процесса. Стандарт BPMN получил широкое распространение благодаря нескольким факторам:
— Наличие небольшого перечня интуитивно понятных условных обозначений, позволяющих описывать широкий спектр сложных процессов.
— Переносимость схемы. BPMN-схема, созданная в одном редакторе, может быть загружена и обработана в любом другой редакторе или системе, поддерживающей BPMN стандарт.
— Так как концепция BPMN предъявляет строгие требования к XML-описанию модели, BPMN может быть интегрирована с разными BPM — системами (Business Process Management System), позволяющими управлять и анализировать созданные модели и даже автоматически создавать исполняемые приложения.
Существует множество редакторов и приложений, в которых можно создавать BPMN-схему или иначе: BPMN-диаграмму. В этой статье я пошагово покажу, как я создала необходимую мне схему через бесплатный on-line ресурс https://storm.bpmn2.ru/. Несмотря на то, что BPMN-схема предназначена для описания бизнес-процессов, например, таких, как оплата бронирования билетов картой, заказ пиццы в интернет-магазине, обработка и отгрузка заказа, я использовала этот инструмент для описания взаимодействия процессов внутри программного обеспечения. Действительно, не имеет значения, являются ли участниками процесса люди с определенными ролями (менеджер, кладовщик и т д) или сервисы.
Итак, мне необходимо описать задачу формирования и отправки уведомлений клиентам о состоянии их депозитов.
Краткое описание процесса: по заданному расписанию происходит запуск сервиса нотификации клиентов из базы данных либо о состоянии всех их депозитов, либо о депозитах с истекающим и/или завершенным сроком.
Начнем создание BPMN — диаграммы.
Сначала определим список участников процесса. В моем случае – это 3 сервиса:
- Job-ы запуска задач по расписанию
- Сервис отправки уведомлений клиентам
- Сервис формирования сообщений
Участники (роли) указываются на диаграмме Пулами и Дорожками. Создаю пул задачи, перетаскивая соответствующий значок из набора инструментов, и делю его на 3 дорожки по числу участников. Подписываю дорожки (для входа в режим подписи – двойной клик на области подписи дорожки).
Определю начальные события, в моем случаи их два. На диаграмме начальное событие отображается окружностью с тонкой границей. Начальные события у меня работают по расписанию, т. е. являются таймером, что можно отобразить на диаграмме. Для этого в контекстном меню объекта — начального события нажимаем на иконку с гаечным ключом и выбираем нужный тип начального события – таймер.
Подписываю эти события (помните? -Дабл-клик на объекте).
Задачи-таймеры запускают Сервис отправки уведомлений, поэтому создаю еще одно начальное событие на 2-ой дорожке. Меняю его тип на «Промежуточное событие-иницииатор», и затем на тип «Промежуточное событие-обработка таймера». Устанавливаю связи между событиями – это совсем просто: выбираю возле объекта значок со стрелками и протягиваю его к связанному объекту. Выравниваю стрелки, как мне нравится. В итоге у меня получилась следующая картинка:
Продолжаю создание диаграммы. Добавляю задачу – «Считать данные администратора сервиса отправки». В обучающих роликах и документации по BPMN рекомендуется называть задачи с использованием глагола в неопределенной форме + существительное, т. е. «Получить отчет…», «Сформировать заказ…» и т. д.
Моя задача «Считать данные администратора…» может закончиться неудачно, этот вариант тоже надо указать на диаграмме, для чего создаю промежуточное прикрепленное событие – круг с двойной границей – и располагаю его на контуре задачи. Меняю тип прикрепленной задачи на «Прикрепленное событие – ошибка» (напомню: выбор нового типа инициируется нажатием на значок гаечного ключа).
Добавляю завершающее событие в случае ошибки – круг с толстой границей. Подписываю его. Также добавляю комментарий к задаче выбором соответствующего значка из контекстного меню.
Следующий шаг – создаю новую задачу и использую еще один элемент – артефакт – значок Базы данных, показывающий, откуда беру данные. Аналогично предыдущему шагу протягиваю стрелки – связи от БД к нужным объектам.
А вот следующим шагом мне надо добавить большой повторяющийся блок действий, т.е. подпроцесс, в котором будут задействованы два участника (2 сервиса). Выбираю на панели инструментов значок подпроцесса, растягиваю его на обе дорожки. Чтобы показать, что процесс повторяющийся, в контекстном меню можно выбрать несколько вариантов:
- параллельное выполнение действия несколько раз
- последовательное выполнение действия несколько раз
- цикличное выполнение действия, пока верно некоторое условие
Выбираю вариант цикличного действия, т.к. мне необходимо повторять обработку данных каждого клиента из считанного списка. Начинаю заполнение диаграммы подпроцесса. Добавляю стартовое событие для подпроцесса. В данном случае выбираю для него тип – «начальное событие по условию» и подписываю это условие: «считанный клиент не является администратором», т.е. если считали данные администратора, подпроцесс обработки данных не запустится, а перейдет к следующей итерации цикла, т.е. к обработке следующей записи из списка.
Далее добавляю ветвление, для этого выбираю соответствующий элемент с панели инструментов – значок ромба, для которого существует несколько типов: ветвление «и», «и/или», «исключающее И». В данном случае выбираю вариант «и», т.к. в моем алгоритме должны обязательно выполниться две задачи. При выборе такого условия, ветки должны сходиться в такой же значок ветвления – шлюз, т.е. значки ветвления «и» всегда идут парным шлюзом, при этом нужно соблюдать условие: сколько ветвей вышло из первого шлюза, столько же должно прийти в закрывающий шлюз.
Заполняю диаграмму подпроцесса уже знакомыми элементами: задачами и объектами ветвления. На следующих шагах мне понадобились обычные операторы ветвления «или, исключающее и». Обратите внимание, что этот оператор не требует парного шлюза.
-добавила артефакты – документы, т.е. данные, которые передаются между задачами.
— в последнем ветвлении указала ветку по умолчанию, т.е. процесс, соответствующий основному сценарию. Выбирается как обычно из контекстного меню нажатием на гаечный ключ.
— в последней задаче выбрала тип – Отправка сообщения, и на задаче появилась соответствующая метка — значок конверта.
Обратите внимание: задачи и объекты расположены на разных дорожках в соответствии с тем, какой процесс исполняет тот или иной этап процесса или подпроцесса.
Добавила штрихи – подписи, сноски-комменатарии, завершающее событие. В завершающем событии после ошибки поменяла тип на «Завершающее событие-останов». И вот, вроде бы, моя диаграмма завершена.
Хотелось бы понять, насколько она корректна с точки зрения концепции BPMN. Для этого на сайте https://storm.bpmn2.ru/, где я создала свою BPMN – диаграмму, есть удобная «фича»: проверка корректности диаграммы. Для этого на верхней панели надо нажать на «галочку»:
Нажимаю и получаю результат – 7,4 балла из 10. Приемлемым считается 8 баллов из 10. Получилось не так уж плохо (самая первая моя попытка была оценена в 0 баллов из 10). Ошибки подсвечиваются разными цветами, определяющими их критичность:
- Красные — серьезные формальные ошибки.
- Желтые — рекомендуется исправить.
- Синие — желательно исправить для улучшения читаемости диаграммы.
Попытаюсь улучшить результат. Первой, конечно, исправляю ошибку, подсвеченную красным: добавляю завершающее событие для подпроцесса. Баллы в результате увеличились, но появилось новое предупреждающее (желтое) сообщение о том, что процесс должен идти слева направо, а не сверху вниз.
Это просто поправить: располагаю завершающее событие подпроцесса справа, а не снизу от задачи. Теперь результат еще ближе к отличному:
Улучшу еще чуть-чуть, исправляю замечание, указанное голубым цветом: «много входящих потоков в задаче». Это уже из области красоты диаграммы, а не функциональности. Добавляю шлюз, и получаю уже 9,4 из 10 баллов.
Важное замечание об отсутствии потока по умолчанию в ветвлении исправлять не буду: мои потоки (ветки) равнозначны, и выбор ветки зависит от переданного параметра.
Пожалуй, оставлю вою диаграмму в таком виде. Остальные непринципиальные замечания исправлять не буду (наличие нескольких стартовых событий и предложение не использовать дорожки).
Скачиваю и сохраняю свою диаграмму в разных форматах, нажав на соответствующий значок из панели в верхнем левом углу:
Можно сохранить схему как картинку в растровом (.jpeg) или векторном (.svg) формате, а также в формате. bpmn
Теперь у меня есть диаграмма, которую я могу использовать, как мне удобно: вставлять в презентацию или другие приложения, пересылать по почте, а при необходимости ее можно будет закачать и отредактировать в любом редакторе, работающем с BPMN.
Источник: newtechaudit.ru