скачать книгу бесплатно
На рис. 2.3. показано довольно часто встречающаяся ситуация – логический цикл вокруг одной операции процесса. Разработчики, как правило, объясняют такой цикл необходимостью повторно выполнять шаг процесса до тех пор, пока не будет получен требуемый результат. Но дело в том, что процесс все равно не пойдет дальше, пока операция не будет выполнена. Поэтому такая конструкция на схеме процесса просто лишена смысла.
Рис. 2.3. Бессмысленный цикл вокруг одной операции процесса.
На рис. 2.4. показана «любимая» многими неопытными разработчиками схем конструкция – последовательное использование нескольких шлюзов исключающего «ИЛИ». Мало того, что в результате увеличивается размер схемы, самое плохое – это крайняя сложность восприятия логики процесса человеком. Как можно сделать по-другому? Просто создать один шлюз исключающего «ИЛИ» и показать все выходящие из него потоки. Для регламента, кстати, в Business Studio можно присвоить таким потокам (переходам) названия, а в их атрибутах указать критерии, на основании которых выбирается соответствующий переход. Тогда можно будет автоматически выгружать эту информацию в регламент.
Рис. 2.4. Сложные шлюзы исключающего «ИЛИ».
На рис. 2.5. показана типичная для неопытного пользователя ситуация, когда поток процесса прерывается, а вместо него используется информационный поток между шагами. Это грубая ошибка. Так делать нельзя.
Рис. 2.5. Отсутствие связи Sequence flow между операциями процесса.
Довольно часто неопытные пользователи BPMN создают конструкцию, показанную на рис. 2.6 – вместо полноценной операции процесса помещают на дорожку шлюз, который «как бы сам принимает решение».
Рис. 2.6. Замена операции шлюзом.
Замечу, что для исполняемой модели в BPMS это вполне допустимая конструкция, так как в BPMS можно определить действия на шлюзе (скрипты) и они будут выполняться автоматически.
Но при создании описательной схемы для человека и выгрузки в регламент такая конструкция, как на рис. 2.6, конечно, недопустима. На схеме необходимо показать полноценную операцию согласования, выполняемую исполнителем.
На рис. 2.7 показаны схожие по смыслу ошибки – когда событие «как бы что-то выполняет». Опять же, для событий в BPMS можно задать действия (скрипты), но для описательной модели процесса такие конструкции категорически недопустимы, так как они явно приводят к искажению смысла процесса.
Рис. 2.7. Замена операции событием.
На рис. 2.8 показана совсем простая, но довольно часто допускаемая ошибка – привязка стрелки не к объекту (шлюзу, операции), а к другой стрелке. На самом деле, при моделировании в нотации BPMN в Business Studio это сделать технически невозможно. Но визуально стрелка может оказаться очень близко к другой стрелке, что может ввести в заблуждение. Очевидно, что так делать категорически нельзя, так как поток работы прерывается.
Вы ознакомились с фрагментом книги.
Для бесплатного чтения открыта только часть текста.
Приобретайте полный текст книги у нашего партнера:
