Участники процесса и потоки
Участники процесса помогают увидеть распределение ответственности. Если все действия находятся в одной дорожке “Система”, модель скрывает реальные роли. Пользователь инициирует действия, сотрудник может проверять или утверждать, внешняя система может возвращать результат, а сама ИС выполняет автоматизированные проверки и сохраняет данные.
Зоны ответственности показывают, где действие переходит от одного участника к другому. Например, пользователь создаёт обращение, оператор классифицирует его, группа поддержки выполняет работу, руководитель согласует исключение, система отправляет уведомление. Если ответственность не указана, процесс выглядит линейным, но в реальности его невозможно выполнить.
Поток управления показывает порядок выполнения действий: что происходит сначала, что потом, где есть условие, где ветви объединяются, где процесс завершается. Он отвечает на вопрос “как движется работа”. Поток управления особенно важен для условий и альтернатив: если заявка согласована, она переходит дальше; если отклонена, возвращается на доработку или закрывается.
Поток данных показывает, какие информационные объекты появляются, меняются или передаются между шагами. Это могут быть заявка, заказ, платёж, документ, уведомление, отчёт, запись журнала, решение согласования. Потоки данных показывают не просто порядок действий, а предметную информацию, которая делает процесс осмысленным.
Сравнение потоков:
| Вид потока | Что означает | Пример |
|---|---|---|
| Поток управления | после какого действия выполняется следующее | после проверки заявка отправляется на согласование |
| Поток данных | какой объект передаётся или создаётся | заявка передаётся сотруднику на проверку |
| Поток объекта | какой предметный объект участвует в шаге | платёж получает статус “подтверждён” |
| Сообщение внешней системе | обмен с участником за границей ИС | платёжный сервис возвращает результат оплаты |
Например, в процессе оформления заказа управление переходит от клиента к системе, затем к платёжному сервису, затем снова к системе и службе доставки. Данные также движутся: корзина превращается в заказ, заказ получает статус, платёж подтверждается или отклоняется, уведомление отправляется клиенту.
Хорошая процессная модель не должна уходить в технические детали вроде SQL-запросов или внутренних методов. На этом уровне важны смысловые действия, ответственность участников, условия перехода и информационные объекты, которые имеют значение для предметной области.
Данные на процессной модели особенно важны для дальнейшей предметной модели. Если в процессе постоянно возникают “заявка”, “подтверждение”, “отчёт”, “статус”, “уведомление”, это не просто подписи. Они могут стать кандидатами в концептуальные классы, атрибуты, состояния или события.
При проверке процессной модели полезно искать три типа ошибок: действие есть, но непонятно, кто его выполняет; условие есть, но неясно, на каких данных оно проверяется; объект появляется в середине процесса, но нигде не создаётся. Такие ошибки обычно показывают, что сценарий ещё недостаточно разобран.
При использовании дорожек ответственности важно не создавать дорожку для каждого мелкого технического элемента. Дорожка нужна там, где меняется исполнитель или зона ответственности: пользователь, сотрудник, проектируемая система, внешняя система. Внутренние классы и методы появятся позже, в технических материалах.