Представление процесса

Итак, у нас была сформирована модель прецедентов, затем на её основе мы создали представление пользователя, включая модель предметной области и модель последовательностей взаимодействия. Я также указал, что в представление пользователя нужно включить макеты пользовательского интерфейса, формы которого использованы на диаграммах последовательности или диаграммах взаимодействия.

Сегодня мы рассмотрим представление бизнес-процессов.

Собственно, модель бизнес-процесса представляется либо в виде диаграммы деятельности (активностей) UML, либо в виде диаграммы BPMN, либо в иной нотации, учитывающей потребности и возможности заинтересованных лиц. Заинтересованными лицами могут быть руководители организации-заказчика, её аналитики, технологи и иные лица, которые часто сами пользователями не являются, но которым важен верхнеуровневый взгляд на деятельность, которую полностью или частично автоматизирует разрабатываемая система.

Нужно сразу предупредить, что диаграмма последовательности UML не должна применяться для представления бизнес-процесса. Она содержит слишком много деталей, за которыми скрывается схема самого процесса. Если процесс сложный, диаграмма последовательностей становится похожей на паутину, и отследить на ней циклы, условия, параллельное выполнение ветвей процесса совершенно невозможно.

Основой модели процесса являются прецеденты. По сути, они становятся узлами активностей на диаграмме бизнес-процесса. По этой причине мне больше нравится использовать диаграмму деятельности UML, чем BPMN. К тому же UML позволяет показать явно многопоточность, циклы и обмен сообщениями или событиями.

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

Активности (прецеденты), выполняемые конкретным актором, размещаются на его дорожке. 

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

Если в процессе (с точки зрения бизнеса, а не реализации системы!) есть вероятность возникновения сбоя (исключения), нужно не забыть внести обработку исключительной ситуации в модель процесса. Особенно это касается работы бизнес-сервисов.

Если модель предметной области предполагает наличие бизнес-событий, сигналов или сообщений, в том числе из внешних источников, они должны быть отражены в модели бизнес-процессов.

И, в общем, это всё.

На что нужно обратить внимание. Это, конечно, ошибки описания алгоритма.

Во-первых, проверяйте достижимость окончания процесса из любой активности с учётом всех условий. Очень часто в сложных процессах появляются ветви, ведущие в никуда.

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

В-третьих, нужно быть аккуратными с акторами. Если одну и ту же операцию могут сделать два или более пользователя (роли), создайте в иерархии акторов абстрактного пользователя, от которого должны наследоваться реальные акторы, выполняющие операцию. Именно для этого абстрактного пользователя создайте дорожку, и разместите на ней активность. Если при этом у вас возникает ситуация множественного наследования - когда один и тот же актор оказывается наследником нескольких других акторов - то вам нужно проверить ролевую модель.

Если оказывается, что в процессе присутствует субъект или объект, отсутствующий в модели предметной области, нужно скорректировать модели предметной области и, возможно, прецедентов.