Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

Межпроцессное взаимодействие через данные

Внимание, тест!

Вопрос: какие элементы BPMN позволяют моделировать межпроцессное взаимодействие (отметьте все правильные варианты ответа) -

  1. поток управления (sequence flow)
  2. сообщение (message flow)
  3. сигнал (signal event)
  4. триггер по данным (conditional event)
  5. ассоциация (association)

Ответ: кликните, чтобы увидеть правильные варианты ответа

Комментарии к ответам:

Потоки управления могут соединять объекты только внутри одного пула, поэтому вариант А не годится. Сообщения, напротив, соединяют объекты, принадлежащие разным пулам, и/или сами пулы (начинаясь или заканчиваясь на границе пула), так что можно сказать, что вариант B - “самый правильный”. Вариант C тоже правильный, см. мои примеры использования сигналов.

Пример взаимодействия процессов через триггер по данным:

Процесс “Закупка” сверяется с бюджетом и если бюджет на данный период не утвержден, ждет утверждения. Если бюджет утвержден, то закупка делается или нет в зависимости от того, предусмотрена ли она бюджетом. Утверждается бюджет в рамках самостоятельного процесса: когда бюджет утвержден, этот процесс присваивает соответствующему атрибуту значение “истина”, и именно этот атрибут проверяет процесс “Закупка”. В этом примере процессы “Утверждение бюджета” и “Закупка” взаимодействуют через триггер по данным - таким образом, вариант ответа D правильный.

Обратите внимание: событие “Бюджет утвержден” срабатывает только тогда, когда значение заданного для него булева выражения меняется с “ложь” на “истина”. Поэтому следующая схема работать не будет:

Если к моменту закупки бюджет окажется уже утвержден, то триггер не сработает, и процесс “зависнет”.

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

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

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

Рассмотрим последний вариант ответа E:как вы думаете, можно ли использовать для моделирования межпроцессного взаимодействия ассоциации? Мой ответ - не только можно, но и нужно! Правда, ценность представляют не ассоциации как таковые, а объекты данных, которые они соединяют с шагами процесса.

Пример:

На диаграмме изображена типичная картина взаимодействия процессов обработки клиентского заказа, производственного планирования и производства. Ключевой момент: производство работает по собственному ритму, оно не бросается немедленно исполнять клиентский заказ. Клиентские заказы превращаются в заказы на производство, которые некоторое время накапливаются в базе данных, а затем с определенной периодичностью (например, раз в день) запускается процесс планирования производства, который превращает заказы в производственный график. По мере выполнения графика соответствующие экземпляры процесса “от заказа до оплаты” получают сообщение о том, что заказ произведен, и в результате процесс переходит к следующему шагу - доставке заказа.

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

По моим наблюдениям, интерес большинства бизнес-аналитиков ограничивается последовательностью шагов в рамках одного процесса (оркестровке). И если они и используют объекты данных BPMN, то для того, чтобы показать передачу данных между шагами одного процесса. Между тем объекты данных более ценны как средство моделирования межпроцессного взаимодействия.

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

Не имеет смысла углубляться в оркестровку, пока у вас не сведены все концы с концами на уровне потоков данных и сообщений.

В BPMN 2.0 появился новый элемент “хранилище данных” (Data Store), который больше подходит для моделирования межпроцессного взаимодействия:

Но особой нужды я лично в нем не вижу: если вы ограничены рамками BPMN 1.x, то используйте старый добрый объект данных (Data Object), просто указав в подписи к нему, что это, скажем,”БД производственных заказов”:

12.11.10 | Статьи | , , ,    

Комментарии (9)

  1. AS 13.11.10 13:06

    About the diagram for the option E - may be add a version with two start events or one event-based gateway (as in the CPP pattern) in “Production Scheduling” process and compare pros/cons for the both versions.

    Thanks,
    AS

  2. Anatoly Belychook 13.11.10 15:31

    Alexander

    Sorry, don’t get your idea: what two start events are good for in this example?

    A.B.

  3. AS 20.11.10 13:17

    Sorry Analoty for not being explicit enough - I referred to the Collect and Periodically Process – CPP pattern from my book 11.9.7. See - http://www.samarin.biz/misc/BPMN-patterns-CPP.png

    Thanks,
    AS

  4. Anatoly Belychook 20.11.10 20:14

    Alexander

    Thanks for the clarification.

    Yes it’s similar but you follow very “intalish” style of modeling that associates pools with performers. For me (and some well-known BPMN specialists) pools are processes or external instances, see http://mainthing.ru/wp-content/uploads/2010/11/samarin.png

    A.B.

  5. AS 21.11.10 22:17

    In many illustrations from the book, pools are used to make the coordination explicit. So, it is important to show to each participant his/her/its contribution in (or the view at) the coordination. Similar to that each member of a ballet dance has to learn his/her own “partie”.

    Thanks,
    AS

  6. Виталий 22.11.10 18:31

    А как на Ваш взгляд наилучшим образом отобразить исполнителя на диаграмме процесса. Может с помощью Lane?

  7. Anatoly Belychook 23.11.10 00:18

    Конечно, они именно для этого предназначены.

  8. Bruce Silver 25.11.10 03:04

    I agree with your main point about communicating via shared data — in BPMN 2.0 must be dataStore not dataObject — but I think clarification needed when you say it is “often neglected.” It is often neglected in BPMN diagrams; in actuality, it is far and away the most common way processes communicate with each other. BPMN has a rich visual language for sending messages, waiting for messages, interrupting on messages etc, but nothing equivalent for common data read or write operations. So in that sense the notation “favors” messages over data, even though data sharing is more prevalent.

  9. Anatoly Belychook 25.11.10 09:44

    Bruce

    Exactly! If explicit process is the target then we must diagram communications via data. Yet people use data objects mostly to decorate orchestration (in many cases excessively for my taste) but very rare if ever to show communications between processes.

    A.B.

А что вы думаете?

Captcha

Copyright © 2008-2016 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии