Освоение подхода, ориентированного на сценарии использования: полное руководство по требованиям и проектированию

Введение

В программной инженерии преодоление разрыва между потребностями заинтересованных сторон и технической реализацией часто является самым сложным этапом разработки. Подходориентированного на сценарии использования предлагает структурированную итеративную методику для решения этой проблемы. Фокусируясь натом, как пользователи взаимодействуют с системойдля достижения конкретных целей, этот подход гарантирует, что требования являются четкими, проверяемыми и напрямую прослеживаемы к артефактам проектирования.

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

---

Обзор методологии

Подход, ориентированный на сценарии использования, следует естественной иерархической прогрессии сверху вниз. Каждый этап уточняет предыдущий, добавляя точность и снижая неопределенность.

Почему важен этот порядок?

1. Диаграмма сценариев использования: Предоставляет полный перечень возможностей и границ системы. Она быстро просматривается и идеально подходит для согласования заинтересованными сторонами того,что делает система.
2. Описание сценария использования: Устраняет неопределенность путем фиксации предварительных условий, последующих условий, актеров и приоритетов. Он «замораживает» контракт поведения.
3. Последовательность событий: Превращает контракт в конкретные, проверяемые шаги. Это служит исходным материалом как для тестовых случаев, так и для технического проектирования.
4. Деятельность/Диаграмма последовательности:Выступает в роли моста к коду. Оно идентифицирует участвующие объекты, их обязанности, обмен сообщениями и точные правила ветвления.

---

Этап 1: Диаграмма вариантов использования (Требования)

Диаграмма вариантов использования фиксируеткто взаимодействует с системой (актёры) ичто они могут делать (варианты использования), а также связи между ними.

Ключевые понятия

• Основной актёр:Запускает вариант использования (размещается слева).
• Второстепенный актёр:Поддерживает систему или получает уведомления (размещается справа).
• Граница системы:Прямоугольник, определяющий границы системы.
• <<include>>:Представляет обязательное общее поведение. Если Вариант использования A включает Вариант использования B, то Bдолжен произойти, чтобы A завершился.
• <<extend>>:Представляет опциональное поведение. Вариант использования B расширяет Вариант использования A только при определённых условиях.

Пример: Система управления онлайн-заказами

@startuml
skinparam linetype ortho
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam vpDiagramType UseCaseDiagram
skinparam actor {
  BackgroundColor #E8F5E9
}
skinparam usecase {
  BackgroundColor #BBDEFB
  BorderColor #1976D2
  ArrowColor #1976D2
}

left to right direction
actor "Customern(Primary)" as cust
actor "Warehousen(Secondary)" as wh

rectangle "Order Management System" {
  usecase "Place Order" as UC1
  usecase "Cancel Order" as UC2
  usecase "Track Order" as UC3
  usecase "Login" as UC4
  usecase "Print Invoice" as UC5
}

cust -[#black]- UC1
cust -[#black]- UC2
cust -[#black]- UC3
UC1 -[#crimson]- wh
UC2 -[#crimson]- wh
UC1 ...> UC4 : <<include>>
UC2 ...> UC4 : <<include>>
UC3 ...> UC4 : <<include>>
UC1 <... UC5 : <<extend>>
@enduml

Анализ диаграммы:

• ДиаграммаКлиент запускает оформление, отмену и отслеживание заказов.
• СкладСклад участвует в оформлении и отмене заказов (вероятно, для обновления остатков).
• Вход включен в действия «Оформить заказ», «Отменить заказ» и «Отследить заказ», что означает обязательную аутентификацию для этих действий.
• Печать счета расширяет действие «Оформить заказ», что означает, что это необязательный шаг, который может произойти после оформления заказа.

---

Этап 2: Описание случая использования (спецификация)

Диаграмма называет случаи использования, но не содержит подробностей. Таблица «Описание случая использования»Описание случая использования table определяет точный контракт для каждого случая использования.

Пример: UC-01 Оформление заказа

Поле	Значение
Идентификатор случая использования	UC-01
Название	Оформить заказ
Основной исполнитель	Клиент
Вторичный исполнитель	Склад
Предусловия	Клиент авторизован; корзина содержит хотя бы один товар; товары есть в наличии
Постусловия (успех)	Заказ сохраняется со статусом подтвержден; оплата проведена; выдан номер для отслеживания
Постусловия (Сбой)	Заказ не создан; корзина не изменена; пользователь проинформирован о причине
Основной поток	→ См. Этап 3
Альтернативные / Исключительные потоки	Недостаточно товара; оплата отклонена
Приоритет	Высокий

Цель: Этот этап определяет, что должно быть истинным до запуска сценария использования (предусловия) и что должно выполняться после (постусловия), устанавливая четкие критерии успеха/неудачи.

---

Этап 3: Последовательность событий (Сценарии)

Это поведенческое ядро подхода. Сценарий использования «Оформить заказ» раскрывается в сценарий сценариясценарий сценария—последовательность пронумерованных шагов, записанная до создания любых детальных диаграмм проектирования.

Основной сценарий успеха (Базовый поток)

1. Клиент входит в систему.
2. Клиент отправляет корзину с выбранными товарами.
3. Система проверяет содержимое корзины и наличие товара на складе.
4. Система списывает общую сумму через платежный шлюз.
5. Система сохраняет заказ со статусом подтвержден.
6. Система возвращает подтверждение заказа с идентификатором заказа.
7. Система уведомляет склад о необходимости отбора, упаковки и отправки товара.

Альтернативные сценарии

• 3a. Недостаточный запас: Система сообщает о недоступных товарах и возвращает пользователя в корзину.
• 4a. Отказ в оплате: Система информирует клиента и не создает заказ.

Основное соглашение: Каждый сценарий напрямую соответствует шагу в описании. Эти потоки становятся основой для диаграмм деятельности и последовательности на следующем этапе.

---

Этап 4: Детальное проектирование (диаграммы последовательности и деятельности)

На этом этапе вы выбираете нотацию в зависимости от того, какой аспект системы вы хотите подчеркнуть.

• Диаграмма последовательности: Подчеркиваетлинии жизни, порядок сообщений и ответственность между объектами. Идеально подходит для выявления классов и методов.
• Диаграмма деятельности: Подчеркиваетпоток управления и решения через дорожки/стороны. Идеально подходит для документирования процессов и ролевой ответственности.

4А. Диаграмма последовательности (Перспектива взаимодействия)

@startuml
title Диаграмма последовательности размещения заказа
skinparam linetype ortho
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam sequenceParticipant underline
skinparam vpDiagramType InteractionDiagram
skinparam {
  FontSize 14
  ArrowColor #4A4A4A
  ArrowFontColor #4A4A4A
  BackgroundColor #FFFFFF
  BorderColor #DEDEDE
  FontColor #333333
  Participant {
    BorderColor #0077B6
    BackgroundColor #F0F8FF
    FontColor #005691
  }
  Actor {
    BorderColor #6A057F
    BackgroundColor #F5EEF8
    FontColor #510363
  }
  Sequence {
    ArrowThickness 2
    LifeLineBorderColor #444444
    LifeLineBackgroundColor #F7F7F7
    BoxBorderColor #AAAAAA
    BoxBackgroundColor #FFFFFF
    BoxFontColor #333333
  }
}

actor "Клиент" as USR
participant "Сервис заказов" as OS
participant "Платежный шлюз" as PG
database "База данных заказов" as DB

activate USR
USR -> OS : submitOrder(items)
activate OS
alt Проверка и оплата
  OS -> OS : validateCart(items)
  OS -> PG : charge(total)
  activate PG
  PG --> OS : paymentOk
  deactivate PG
  OS -> DB : saveOrder(status=confirmed)
  activate DB
  DB --> OS : orderId
  deactivate DB
  OS --> USR : orderConfirmation(orderId)
else Недостаточный запас
  OS -> DB : checkStock(items)
  activate DB
  DB --> OS : stockUnavailable
  deactivate DB
  OS --> USR : error("Нет в наличии")
else Ошибка оплаты
  PG --> OS : paymentFailed
  OS --> USR : error("Отказ в оплате")
end
deactivate OS
@enduml

Ключевые понятия:

• Синхронные вызовы: Сплошные стрелки (->).
• Ответы: Пунктирные стрелки (-->).
• Полосы активации: Показывают срок жизни обработки объекта.
• alt Объединённый фрагмент: Объединяет три сценария (Успех, Недостаточный запас, Ошибка оплаты), напрямую отражая поток событий из Этапа 3.

4B. Диаграмма деятельности (Перспектива процесса)

@startuml
<style>
  element { MaximumWidth 150 }
  start   { Backgroundcolor #00695C }
  stop    { Backgroundcolor #C2185B }
  activity{ Backgroundcolor #81D4FA; MaximumWidth 150 }
  diamond { Backgroundcolor #FFB74D; MaximumWidth 80 }
  arrow   { LineColor #424242; Fontcolor #000000 }
  swimlane{ Fontcolor #000000; FontSize 14 }
</style>
title Диаграмма деятельности размещения заказа

|#F0F8FF|Клиент|
start
:Вход;
:Просмотр каталога;
:Добавление товаров в корзину;

if (Готов к оформлению?) then (да)
  :Перейти к оформлению;
else (нет)
  :Вернуться к просмотру;
  stop
endif

|#E8F5E9|Система|
:Проверка корзины;
:Обработка оплаты;

if (Оплата одобрена?) then (да)
  :Создание заказа (статус=подтверждён);
else (нет)
  :Уведомление об ошибке оплаты;
endif

|#F5EEF8|Склад|
if (Оплата одобрена?) then (да)
  :Подбор и упаковка товаров;
  :Отправка заказа;
  :Отправка трек-номера;
  stop
else (нет)
  stop
endif
@enduml

Ключевые понятия:

• Поплавки (Swimlanes): Назначает каждое действие ответственной стороне (Клиент, Система, Склад).
• Узлы решений: if/then/else/endif структуры кодируют ветвящиеся сценарии.
• Маркеры начала/конца: Ограничивают начало и конец процесса.

---

Ключевые выводы по PlantUML

Чтобы эффективно моделировать этот подход с помощью PlantUML, запомните следующие основы синтаксиса:

1. Диаграммы вариантов использования:
   • Используйте usecase для функций.
   • Используйте ...> для <<include>> отношения.
   • Используйте <... для <<extend>> отношения.
   • Используйте rectangle "Название системы" {} для определения границы системы.
2. Диаграммы последовательности:
   • Определите участников с помощью actor, participant, или database.
   • Используйте -> для синхронных вызовов и --> для ответов.
   • Используйте activate и deactivate для отображения жизненного цикла объектов.
   • Используйте alt, иначе, и конец для объединённых фрагментов, представляющих альтернативные потоки.
3. Диаграммы деятельности:
   • Используйте |#color|LaneName| для определения дорожек.
   • Используйте :action; для действий.
   • Используйте if/else/endif для узлов принятия решений.
   • Используйте start и stop для обозначения границ процесса.

---

Заключение

Подход ориентированный на сценарии использования — это не просто техника документирования; это фреймворк для постепенной детализации. Начиная с общей картины (диаграммы сценариев использования) и углубляясь в конкретное поведение (поток событий) и технические взаимодействия (диаграммы последовательности/диаграммы деятельности) команды могут гарантировать, что каждая строка кода прослеживается до подтверждённой потребности пользователя.

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