В диаграмме деятельности UML действие должно начаться только после получения документа, но связь с предыдущим шагом показана как поток управления. Какую семантическую ошибку допустил аналитик?
Аналитик перепутал поток управления с потоком объектов. Поток управления передаёт управляющий токен и задаёт порядок запуска действий, но не означает передачу документа; для моделирования получения документа нужен поток объектов через объектный узел или входной пин действия.
В UML activity diagram разделение потоков позволяет одновременно показывать порядок выполнения и движение данных. Такой подход решает проблему смешения двух разных зависимостей: «шаг может начаться после другого шага» и «шаг получает конкретный объект как вход».
Без этого разделения диаграмма может выглядеть логично, но скрывать отсутствие данных, необходимых для выполнения действия. Поэтому поток управления и поток объектов имеют разные токены и разные смысловые обязанности.
Если документ обозначен только потоком управления, модель утверждает лишь, что действие может начаться после завершения предыдущего шага. Она не утверждает, что документ был создан, передан или доступен следующему действию.
Это приводит к рискам: разработчики могут не понять источник данных, тестировщики — не проверить передачу документа, а при изменении процесса станет неясно, какой именно объект используется. В исполняемой или детализированной модели действие может быть активировано при наличии управляющего токена, даже если нужный документ не представлен как вход.
Поток управления передаёт управляющий токен. Он задаёт условие продолжения процесса: например, действие «Проверить заявку» выполняется после завершения действия «Получить заявку».
Поток объектов передаёт объектный токен — экземпляр или значение, например заявку, документ или платёжное поручение. Его следует связывать с объектным узлом либо входным пином действия, чтобы явно показать, какой объект поступает на обработку.
Если важны и порядок, и данные, модель может содержать оба аспекта: поток управления показывает разрешение на запуск, а поток объектов — передачу документа. При этом объектный поток не следует использовать как универсальную замену управления: наличие данных само по себе не всегда означает, что действие уже разрешено бизнес-логикой.
При выборе между двумя вариантами нужно учитывать назначение диаграммы. Для обзорной схемы процесса иногда достаточно потока управления, если передача данных не является частью проверяемого сценария; для анализа интеграций, входов и выходов действий это упрощение уже опасно.
В процессе обработки страхового заявления после шага «Загрузить заявление» был проведён поток управления к действию «Проверить заявление». Позже выяснилось, что проверка использует не само заявление, а его нормализованную версию, сформированную отдельным шагом.
Рассматривались два варианта. Можно было оставить только поток управления: это проще для обзорной диаграммы, но источник проверяемого документа оставался бы неявным. Можно было заменить связь только на поток объектов: передача данных стала бы ясной, однако порядок запуска и отдельное условие допуска к проверке могли бы потеряться.
Выбрали оба потока: поток управления от завершения загрузки и поток объекта «Нормализованное заявление» на входной пин проверки. В результате стало явно видно, что проверка начинается после разрешения процесса и получает конкретный подготовленный документ; это также позволило сформулировать отдельные тесты на наличие и корректность входного объекта.
Нет. Поток объектов показывает передачу данных, но не обязан выражать все условия управления процессом. Действие может дополнительно зависеть от решения шлюза, разрешения роли, завершения другого действия или наступления события. Если эти ограничения важны, их нужно моделировать средствами управления, а не рассчитывать только на наличие объекта.
Нет. Подпись или текстовая пометка может помочь читателю, но не создаёт формальной семантики передачи объекта. Для этого нужен объектный узел, входной или выходной пин и соответствующий поток объектов; иначе связь остаётся пояснением, а не частью модели данных.
Нет, степень детализации выбирают по цели модели. Следует явно показывать объекты, если их источник, преобразование, обязательность или передача между участниками влияют на требования, интеграции или приёмочные проверки. Второстепенные внутренние значения можно не выносить на диаграмму, если их отсутствие не меняет понимание процесса.