На этом шаге рассмотрим типичные приемы моделирования потока работ в UML.
Ни одна программная система не существует в изоляции. Всегда существует некоторый контекст, в котором она "живет" и который обязательно включает действующие лица, работающие с системой. Особенно когда речь идет о критически важном программном обеспечении масштаба предприятия, всегда можно обнаружить автоматизированные системы, работающие в контексте более высокоуровневых бизнес-процессов. Эти бизнес-процессы следует рассматривать как разновидность потока работ (workflow), поскольку они по своей сути представляют поток работ и объектов, проходящих через весь бизнес. Например, в розничной торговле существуют некоторые автоматизированные системы: сеть кассовых терминалов взаимодействует с системами маркетинга, складскими системами и т.д., равно как и с человеческими системами – продавцами, сотрудниками отделов маркетинга, закупок и поставок. Бизнес-процессы можно моделировать как совместную работу всех этих автоматизированных и человеческих систем, используя диаграммы деятельности.
Чтобы смоделировать поток работ, необходимо:
- установить фокус потока работ. Невозможно показать все важные потоки работ нетривиальной системы в пределах одной диаграммы;
- выбрать бизнес-объекты, имеющие обязанности самого высокого уровня в отношении всего потока работ или его частей. Это могут быть реальные сущности из словаря системы либо какие-то более абстрактные. В любом случае необходимо создать "плавательную дорожку" для каждого важного бизнес-объекта или подразделения;
- идентифицировать предусловия начального состояния рабочего потока и постусловия его конечного состояния. Это весьма существенно для очерчивания границ потока работ;
- начиная со стартового состояния потока работ специфицировать деятельности, разворачивающиеся во времени, и отобразить их на диаграмме;
- сложные действия или их наборы, которые применяются многократно, представить в виде вызовов отдельных диаграмм деятельности;
- изобразить потоки, которые соединяются с этими действиями и узлами деятельности: начать с последовательных потоков, затем рассмотреть ветвление и только в последнюю очередь – разделение и соединение (параллельные потоки);
- если существуют важные значения объектов, вовлеченных в рабочий поток, отобразить их на диаграмме. Показать их изменяющиеся значения и состояния, насколько это необходимо для передачи назначения потоков объектов.
На рис. 1 в качестве примера показана диаграмма деятельности для системы розничной торговли, которая специфицирует поток работ, возникающий при возврате заказчиком продукта, высланного по почте.
Рис.1. Моделирование потока работ
Работа начинается с действия Request Return (Возврат заказа), выполняемого объектом Customer (Заказчик), затем поток проходит через отдел Telesales (Почтовые продажи) – Get return number (Получить номер возврата), обратно к заказчику – Ship item (Отправить товар), затем попадает на Warehouse (Склад) – Receive item (Принять позицию) и Restock item (Пополнить запас) – и, наконец, завершается в отделе Accounting (Бухгалтерия) – Credit account (Кредитовать счет). Как показано на диаграмме, один важный объект – экземпляр Item (Позиция товара) – также путешествует в потоке, изменяя свое состояние от returned (возвращен) до available (доступен).
Потоки работ являются бизнес-процессами в большинстве случаев, но не всегда. Например, вы можете использовать диаграмму деятельности для описания процесса разработки программного обеспечения, такого как процесс управления конфигурацией. Более того, диаграммы деятельности подходят для моделирования непрограммных систем, в частности потока пациентов в системе здравоохранения.
В этом примере нет ветвлений, разделений и соединений. Но все это можно встретить в более сложных потоках работ.
На следующем шаге рассмотрим типичные приемы моделирования операций в UML.
