Бизнес-варианты использования и системные варианты использования

Главные идеи#

Два вида вариантов использования#

Это разделение не входит в базовый UML (его вводят через расширения UML), но широко распространено на практике, и Белин делает его явным:

• Бизнес-вариант использования (business use case) описывает взаимодействие с бизнесом в целом, а не с ИТ-системой. Это последовательность действий, которая даёт ценный результат конкретному действующему лицу бизнеса. Пример Белина из страхования: подача заявления о страховом случае.
• Системный вариант использования (system use case) описывает взаимодействие с ИТ-системой, которая поддерживает часть бизнес-процесса. В том же примере: зарегистрировать заявление, проверить случай, назначить ответственного. У каждого такого варианта обычно одно основное действующее лицо, он выполняется за один сеанс, а в конце пользователь чувствует, что достиг чего-то значимого для бизнеса.

Обычные варианты использования, которые пишет большинство команд, в этом смысле — системные.

Кто изображается на диаграмме бизнес-вариантов использования#

• Действующие лица бизнеса (business actors) — люди или организации вне бизнеса, например клиенты и поставщики.
• Работники (workers) — люди внутри бизнеса. Расширенная нотация делит их на работников, взаимодействующих с внешними действующими лицами (case workers), и внутренних работников (internal workers), которые имеют дело только с коллегами.
• Ассоциации, которые связывают действующих лиц с вариантами использования, где те участвуют.

От бизнес-вариантов к системным: шаги BOOM#

На тренинге Белина представлен BOOM (Business Object Oriented Modeling) — подход из пяти шагов, который встраивает эту работу в проект:

1. Начало (Initiation): моделирование бизнес-вариантов использования, определение границ, ранние архитектурные решения. Соответствует фазе Envisioning в MSF и Inception в RUP. Подробнее: (а) диаграммы бизнес-вариантов использования и диаграммы деятельности для их содержания; (б) системные варианты использования: действующих лиц находят с помощью карты ролей, а сами варианты группируют в пакеты; (в) первая диаграмма классов для ключевых бизнес-классов; (г) фиксация базовой версии предварительного документа бизнес-требований (BRD).
2. Исследование (Discovery): полный анализ поведения системы, ключевые архитектурные решения, пик работы над требованиями. Сюда входят описания вариантов использования, диаграммы состояний для ключевых бизнес-объектов, диаграммы классов с атрибутами и операциями, тестовые сценарии, план реализации и вторая базовая версия.
3. Построение (Construction): проектирование, кодирование, интеграция и тестирование. В каскадных проектах анализ к этому моменту уже завершён; в гибких шаги этапа «Исследование» повторяются в каждой итерации.
4. Итоговая верификация и валидация (Final Verification and Validation): финальное тестирование перед вводом в эксплуатацию; аналитик проверяет, что каждое требование протестировано.
5. Завершение (Closeout): поддержка развёртывания и участие в анализе результатов после внедрения.

Выбор нотации для описания потока работ#

Чтобы описать содержание бизнес-варианта использования, нужна нотация потоков работ (workflow). Белин сравнивает пять нотаций; вкратце:

Вывод Белина: для ИТ-бизнес-аналитика самая полезная из пяти — диаграмма деятельности, потому что её могут читать и аналитики, и конечные пользователи.

Основные элементы диаграммы деятельности: начальный узел, действия, потоки управления, решения со сторожевыми условиями в квадратных скобках, слияния, события (они задерживают поток, пока что-то не произойдёт), разветвления и соединения (fork и join) для параллельной работы и конечный узел. Разделы (partitions), или дорожки, показывают, кто выполняет каждое действие: по одной дорожке на каждое действующее лицо, работника или, если нужно, систему.