книги / Построение моделей бизнес-процессов
..pdf
Рис. 41. Маркеры задачи
Маркер многоэкземплярности указывает на то, что действие выполняется над несколькими экземплярами, и только после обработки всех экземпляров задача считается выполненной. Экземпляры могут обрабатываться параллельно (маркер на рис. 41), тогда они запускаются единовременно и последовательно. Во втором случае линии маркера повернуты на 90 градусов (≡). Порядок обработки задается атрибутами задачи. Если количество экземпляров заранее неизвестно, тогда оно определяется по ходу процесса и может быть разным для разных экземпляров процесса (например, число клиентов, которым нужно послать e-mail). Маркер многоэкземплярности может использоваться совместно с маркером компенсации, а маркер компенсации– совместнос маркеромцикла.
Компенсация связана с отменой шагов, которые уже были успешно выполнены, но их результаты и, возможно, побочные эффекты больше не нужны и должны быть отменены (измененные данные должны быть возвращены к исходным значениям). Когда действие находится в активном состоянии, его нельзя компенсировать, но оно может быть отменено. Отмена, в свою очередь, может привести к компенсации успешно выполненных операций в составе подпроцесса.
Компенсация выполняется при помощи обработчика ком-
пенсации, который делает шаги, необходимые для отмены результатов действия (рис. 42).
Здесь компенсация моделируется с помощью специального действия по компенсации, которое находится вне стандартного потока операций и связано с граничным событием компенсируемого действия через ассоциацию. Как видно, начальной точкой обработчика ком-
пенсации является обрабатывающее триггер событие Компенсация.
61
Такое событие либо присоединено к границе действия (см. рис. 42), либо является стартовым событием данного
обработчика (например, событийного
подпроцесса компенсации). Заметим, что событие компенсации произойдет столько раз, сколько раз было выполнено действие (обработчик граничной компенсациивызывается одинраздля каж-
дого экземпляра многоэкземплярного подпроцесса); компенсация из подпроцесса не передается в вышестоящий процесс.
В подпроцессе обработчик компенсации имеет доступ к данным этого подпроцесса в момент его завершения, т.е. делает моментальный снимокнабораданных подпроцесса.
Компенсация запускается генерирующим событием компенсации, которое может быть либо промежуточным, либо конечным событием. Сигнал генерирующего события улавливается парным ему промежуточным граничным событием компенсации или стартовым подпроцесса компенсации. При этом определяется действие, которое необходимо компенсировать. Если действие не указано в контексте, по умолчанию используется текущее действие. Типичный сценарий компенсации имеет место, когда встроенный обработчик ошибок подпроцесса не может исправить ошибку и в результате запускает компенсацию для этого подпроцесса.
5.2.7. Шлюзы (Gateways)
Бизнес-процесс может исполняться по разным сценариям в зависимости от складывающихся по ходу процесса условий. Чтобы отразить в модели все возможные сценарии поведения, в нотации предусмотрены элементы логических операторов, называемые шлюзами или развилками. Они играют роль своеобразных маршрутизаторов потоков операций, так как используются для контроля схождений и расхождений множественных потоков операций в рамках одного процесса.
62
Для описания поведения выполняемого процесса в нотации BPMN оперируют понятием «токен», которое является чисто теоретическим и в инструментах моделирования не используется. Токен можно представить как виртуальный пузырек, который ведет за собой поток, и его маршрут есть маршрут потока. Стартовое событие формирует токен, который в итоге должен завершиться (пузырек лопнуть) в конечным событии. При протекании нескольких параллельных потоков одного экземпляра процесса каждый поток имеет свой токен, который указывает на место, до которого дошел поток в процессе.
Поведение элементов процесса, включая шлюзы, определяется через их взаимодействие с токеном. Когда токены подходят к шлюзу, то при его активизации они могут объединиться у входа в шлюз и/или разделиться при выходе из шлюза. Как и действия, шлюзы могут поглощать токены или формировать дополнительные токены, эффективно контролируя при этом исполнительную семантику процесса. Основные отличия шлюза от действия заключаются в том, что посредством шлюза нельзя отобразить выполнение какого-либо действия, и поэтому он не влияет на стоимость или время выполнения процесса.
Шлюзы позволяют отразить в модели все типы поведения потоков операций бизнес-процесса: ветвление по условиям и событиям, слияние, синхронизацию, соединение. Все шлюзы имеют вид ромба, с которым может соединяться любое количество входящих и исходящих потоков операций, причем присоединяться они могут к любой точке его границы, а не только к углам.
Первым рассмотрим шлюз эксклюзивный/exclusive, реализующий логику исключающего ИЛИ (XOR) и управляемый данными. Нотациядаетдва равнозначных варианта его изображения (рис. 43).
Рис. 43. Шлюз Исключающее ИЛИ
63
На исходящей стороне он используется для разделения потока операций на несколько альтернативных маршрутов. Для одного экземпляра процесса может быть выбран лишь один из предложенных маршрутов. Выбор осуществляется оценкой условий ветвей по порядку, и первое выполненное условие определяет ветвь, по которой пойдет исходящий поток (остальные условия игнорируются). Если все условия оцениваются как ложные и не указан поток по умолчанию, шлюз генерирует исключение. Каждый токен, поступающий с любым входящим потоком, активирует шлюз и направляется точно в одну из исходящих ветвей (поступление токена означает завершение соответствующего входящего потока). Со стороны входа объединяющий эксклюзивный шлюз применяется для объединения нескольких альтернативных маршрутов в один. Каждый раз, как только завершается один из входящих потоков (токен достигает шлюза), активируется шлюз и исходящий поток операций. Токен каждого из входящих потоков перемещается на исходящий поток операцийбезсинхронизации (неодновременно).
Пример использования эксклюзивного шлюза приведен на рис. 44.
Рис. 44. Применение эксклюзивного шлюза
В этом примере действия, следующие после 1-й задачи, зависят от результата ее решения и выбора плана. Вместо двух разделяющих шлюзов можно было бы показать один с тремя исходящими ветвями, но тогда усложнилось бы понимание диаграммы. Эта диаграмма демонстрирует хороший стиль моделирования:
64
процесс изображен слева направо, шлюзы применены парами, подписаны события и разделяющие шлюзы, а на их исходящих ветвях приведены условия.
Второй пример (рис. 45), на котором представлена диаграмма процесса обработки запроса клиента, также соответствует хорошему стилю.
Рис. 45. Процесс обработки заказа клиента
Здесь процесс показан в пуле с дорожками, отражающими исполнителей процесса.
В обоих примерах токены (пузырьки) проходят шлюзы без изменений. Разделяющие шлюзы реализуют по два альтернативных маршрута, а в объединяющие шлюзы токены входят в данный момент только с одной из двух входящих ветвей.
Еще один пример – модель процесса «Обработка платежа» с распределением функций по исполнителям (ролям), приведен на рис. 46. Использование эксклюзивных шлюзов позволило отразить все возможные сценарии исполнения процесса. Как видно, при величине платежа больше 500 тыс. руб. требуется предварительное одобрение супервизора, иначе сразу после ввода платежа автоматически выполняется проверка на подозрительность (сервисная задача). Если платеж «чистый», то либо обра-
65
ботка на этом заканчивается, либо при межбанковском платеже сервис передает его на межбанк.
Рис. 46. Диаграмма процесса «Обработка платежа»
Подозрительный платеж проверяется службой финансового мониторинга. Таким образом, обработка небольших (до 500 тыс.) «чистых» платежей» выполняется без участия человека, в иных случаях возможен отказ супервизором или финансовой службой.
Одновременно с построением графической модели процесса Camunda Modeller создает его XML-описание. Так, XML-описание рассмотренного процесса «Обработка платежа» приведено в приложении 1. В строке 4-й мы видим название процесса. Особо обратим внимание на строку 6-ю описания, где процесс определяется как исполнимый. Действительно, модель удовлетворяет соответствующим требованиям, а именно: представлены все сценарии процесса, указаны типы задач, приведены все необходимые надписи на шлюзах, ветвях и событиях, отсутствуют неконтролируемые потоки. Такая модель непосредственно воспринимается платформой BPMS (системой управления бизнес-процессами).
Поясним последующие строки XML-описания. В строках с 7 по 28 описываются дорожки: ID, имя дорожки и элементы, размещенные на ней. Далее, до 106-й строки приведено описание всех элементов процесса и связанных с ними потоков операций. Снача-
66
ла между строками начального и конечного событий представлены все шлюзы с входящими и исходящими потоками (ID, надписи и пр.). Затем дается описание задач: имя, входящий и исходящий потоки, атрибуты). Завершается описание фиксацией геометрии модели: по каждому элементу приведены точки привязки в относительных координатах и его размеры.
Параллельный шлюз /parallel gateway
реализует оператор И (and). Он используется для синхронизации потоков (при их объединении) и создания параллель-
ных маршрутов (разветвление потока). Рис. 47. Параллельный Графическое изображение шлюза пока- шлюз
зано на рис. 47.
С помощью этого шлюза параллельные маршруты создаются без необходимости проверки каких-либо условий. При разделении на параллельные потоки все они активируются одновременно и каждый исходящий поток операций получает токен. При объединении параллельных ветвей шлюз ожидает завершения всех входящих потоков операций (слияния всех входящих токенов, по одному от каждого входящего потока, – синхронизация) и затем активирует исходящий поток (на нем создается один токен).
Рис. 48 демонстрирует применение эксклюзивных и параллельных шлюзов. Приведенный процесс включает обработку заказа, выбор продукта в зависимости от величины заказа (эксклюзивный шлюз) и соответствующее ему действие, далее параллельно выполняемые задачи «Организации отправки заказа» и «Пакетирование товара» (параллельные шлюзы). Правый параллельный шлюз ждет выполнения обоих параллельных действий и только после их завершения активирует исходящий поток, который в свою очередь активирует задачу «Отправка заказа». То что заказ выполнен, фиксирует конечное событие.
Другой пример использования двух рассмотренных шлюзов приведен на рис. 49. Здесь показан процесс приготовления желаемой пищи. Процесс стартует при появлении чувства голода.
67
Выбор блюд предусматривает два варианта: салат и паста или салат и бифштекс. Так как салат фигурирует в обоих случаях и обязательно включение в меню одного из двух вторых блюд, то для описания такого поведения применен параллельный шлюз.
Рис. 48. Процесс выполнения заказа
Рис. 49. Процесс приготовления еды
Эксклюзивный шлюз показывает альтернативность вторых блюд. При выборе пасты приготовление пищи займет 15 мин, а при выборе бифштекса – 10 мин. Только когда приготовлены и салат, и второе блюдо, активируется правый параллельный шлюз и выполняется последнее действие процесса. Достижение конечного события означает, что голод утолен.
Следующий пример с двумя видами шлюзов показан на рис. 50. Типичный процесс согласования отпуска представлен с распределением функций по ролям, выделенным дорожками. В исполнении процесса участвуют нуждающийся в отпуске сотрудник, его начальник и специалист по персоналу.
68
Рис. 50. Диаграмма процесса «Согласование отпуска»
69
69
Сотрудник передает заявление на отпуск своему руководителю, который проверяет возможность отпуска и может отказать в отпуске или подписать заявление и вернуть сотруднику. Подписанное заявление HR-специалист проверяет на наличие у сотрудника отпускных дней и, если они есть, оформляет отпуск, после чего руководитель делает отметку в графике загрузки, а сотрудник заменяет в e-mail свой адрес адресом заместителя.
Если отпускных дней недостаточно, сотрудник может принять решение об отказе от отпуска либо написать заявление о дополнительных днях за свой счет. Это заявление он передает на подпись руководителю.
Очевидно, что рассмотренные в примерах диаграммы соответствуют хорошему стилю и не требуют дополнительных текстовых пояснений по взаимодействию потоков с задачами.
Однако на практике можно встретить отклонения от хорошего стиля. Например, на некоторых диаграммах разделения и объединения потоков показываются без использование шлюзов. Так, задача может иметь несколько входящих или несколько исходящих потоков. В таких случаях говорят о неконтролируемых потоках. На рис. 51 слева показан случай с двумя исходящии потоками, и поэтому поток из задачи 1 является неконтролируемым. Справа приведен эквивалентный вариант разделения потока с использование параллельного шлюза. Этасхемачитаетсяоднозначноипотомупредпочтительнее.
Рис. 51. Эквивалентные разделения потока (развилки)
Случай неконтролируемого потока на входе задачи приведен на рис. 52 слева. Здесь задача 2 имеет два входящих потока, характер взаимодействия которых с задачей не очевиден. Эквивалентная
70