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

И что, это проблема BPMN? Не думаю. Скорее наоборот – достоинство BPMN в том, что и в такой ситуации на его основе удается обеспечить обратную связь с бизнесом.

Сложен не BPMN – сложен бизнес. Чудес не бывает.

RUP, разумеется, я привёл в качестве примера вовсе не для ругательства

Несколько расстроен тем фактом, что всё-таки остаётся разрыв между описанием «бизнеса» и отображением его выполнения с использованием информационной системы в нотации BPMN. Видимо, ожидания были завышены и пока не изжиты

Кстати, в RUP «мосты» между моделями также остаются, да и двустороннюю трассировку тоже никто не отменял

Еще одно замечание вдогонку. Цитирую: «вероятность ошибки при написании текста программы существенно меньше, чем при составлении схемы в нотации BPMN».

Утверждение не вполне корректно, так как тут сравнивается программирование ОДНОГО ПОТОКА с составлением МНОГОПОТОЧНОЙ диаграммы в BPMN. Если сравнивать яблоки с яблоками, т.е. многопоточное программирование там и там, то BPMN будет смотреться намного выигрышнее. Ну просто представьте себе мысленно как будет выглядеть программный код для рассматриваемой задачи – как насчет вероятности ошибки в такой программе?

Да, все правильно.

Но не забываем, что BPMN методологически нейтрален, то есть оставляет широкое поле для выработки собственного стиля моделирования. Я лично придерживаюсь мнения, что не стоит на одной диаграмме смешивать сообщения в «строгом» смысле (как механизм коммуникаций внутри BPMS) и в «аморфном» (как описание неформальных коммуникаций с внешними сущностями через телефон, обычную и электронную почту и т.д.). Но на этот счет могут быть и другие мнения, могут быть другие стили. Важно только, чтобы был какой-то стиль, которого придерживалась бы команда.

Что касается RUP – для начала, это ведь слово не ругательное, в сходстве с ним нет ничего зазорного. Но полностью ставить знак равенства я бы не стал. Все-таки в случае BPMN после перехода к исполняемой модели мосты не сжигаются – она сохраняет достаточную степень преемственности с аналитической, чтобы бизнес-аналитик продолжал воспринимать ее как свою. Пусть он не может самостоятельно разработать исполняемую модель – главное, чтобы он мог продолжать ее понимать и вносить в нее изменения в своей сфере компетенции.

Спасибо за участие и за отзыв. Я его продублировал в «Отзывах».

По сути полностью согласен. У меня давно оформился вывод: если бизнес в принципе и можно запрограммировать (а BPMS – это технология программирование бизнеса), то только как многопоточную систему. Поэтому документооборот, простенькие встроенные в корпоративные системы workflow-движки и реализации BPMN без сообщений и сигналов – это не про бизнес, а про канцелярию.

И похоже, авторы BPMN тоже это понимают – развитие стандарта идет в направлении более полной поддержки механизмов межпроцессного взаимодействия.

И да – мозги надо перестраивать. Но по мне это кайф! А главный кайф – в получаемых результатах, в диаграммах не «as is» и не «to be», а «AS REALLY IS».

Прежде всего, я хочу поблагодарить Анатолия Белайчука за тот существенный объем знаний, который он сумел передать нам всего за два занятия.

Вот мое резюме:

1. Анатолий Белайчук – талантливый преподаватель (без ложной скромности).

2. BPMN – это не так просто как может показаться на первый взгляд. Она требует к себе уважительного отношения. Нужно понимать много нюансов, чтобы некая совокупность квадратиков, кружочков и линий смогла принять очертания исполняемого процесса, причем исполняемого ТАК КАК БЫ НАМ ХОТЕЛОСЬ.

3. BPMN содержит массу возможностей для «просто рисования», которое позволяет получить достаточно понятный бизнес-процесс, но который при этом не будет исполнимым. Лично меня это в некоторой степени смущает и сбивает с толку, потому что я изначально был нацелен на построение только исполнимых шаблонов БП.

4. Один и тот же процесс, оформленный «для объяснения людям» и «для исполнения» может выглядеть по-разному. И иногда процесс «для исполнения» может оказаться уже менее понятным для менеджеров и бизнес-аналитиков, поскольку содержит технические и технологические включения, связанные с функционированием движка BPMS и с используемой моделью данных.

5. Так же как в программировании, для BPMN существует «плохой стиль» и «хороший стиль». И для BPMN «хороший стиль», возможно, даже еще более важен, чем для программиста при написании программы. Имея опыт работы программистом, я могу утверждать, что вероятность ошибки при написании текста программы существенно меньше, чем при составлении схемы в нотации BPMN. И причина тут кроется в том, что BPMN оперирует большим количеством задач, исполняемых ОДНОВРЕМЕННО. При написании программного кода, конечно же, тоже приходится сталкиваться с асинхронной обработкой, распараллеливанием, использованием потоков… Но не в таких объемах. Приходится перестраивать мозг на новый стиль мышления, в котором параллельная обработка используется не от случая к случаю, а, может статься, даже более активно, чем последовательная. Нужно хорошо понимать взаимодействие потоков параллельных вычислений – явное, неявное, через обмен сигналами, сообщениями, через генерацию событий и через «модель поведения» шаблона BPMN, по разным ветвям которого разошлось множество «токенов». Я вижу, что в нотации BPMN заложен огромный потенциал для описания параллельных вычислений – такой, которого нет ни в каких других известных мне инструментариях. Им нужно научиться правильно пользоваться. Этот потенциал может иметь значение далеко за пределами одних только «бизнес-процессов» (ну, это уже очень личное мнение).

В комментариях к процессу я специально отметил, что диаграмма выполнена в «исполняемом», а не «аналитическом» стиле: сообщения (message) зарезервированы под межпроцессное взаимодействие, а взаимодействие с внешними сущностями моделируется человеческими или автоматическими задачами. Поэтому процесс запускается вручную, почта отправляется скриптовой задачей, а ожидание сообщения о выпуске билда моделируется человеческой задачей «получить билд».

Относительно предложения добавить исключение к подпроцессу «Тестирование РСС». Вопрос: это исключение будет относиться к циклу или к одному из потоков в цикле? Причем какой бы вариант ответа на этот вопрос ты не дал, есть ли уверенность, что другие читатели диаграммы, включая такого специфического «читателя», как движок BPMS, ответят на него так же?

Поэтому лучше не надо. Причем в буквальном смысле не надо, т.е. не требуется. Прелесть представленной схемы в том, что в ней каждый поток подпроцесса «Тестирование РСС» всегда так или иначе завершается – либо тем, что тестирование успешно вышло, либо одним из двух сигналов. Все потоки завершаются, цикл по объектам в процессе «Управление тестированием» тоже завершается без приключений, процесс анализирует были ли ошибки и идет по одному или другому маршруту.

По-моему, все стройно и логично. А вот если прикрепить обработчик события к циклу по объектам, тогда путаница действительно возникнет.