Из чего состоит Use Case diagram?

Use Case Diagram: Структура и компоненты

Use Case diagram — это один из базовых диаграмм UML, который визуализирует взаимодействие акторов (участников) с системой через сценарии использования (use cases). Это мощный инструмент для сбора и документирования требований.

Основные компоненты

1. Actor (Актор)

Актор — это внешний объект или роль, которая взаимодействует с системой. Не путать с конкретным человеком — актор представляет роль или внешнюю систему.

Примеры акторов:

• Customer (клиент сайта)
• Admin (администратор системы)
• Payment System (внешняя платёжная система)
• Email Service (почтовый сервис)
• Third-party API (внешний API)

Визуально: стик-фигура человека или объект (для систем).

Варианты:

• Primary Actor — инициирует use case (например, Customer)
• Secondary Actor — участвует в процессе (например, Payment System)

2. System Boundary (Граница системы)

Система показывается как прямоугольник, внутри которого находятся use cases. Граница отделяет то, что находится внутри системы от того, что находится снаружи.

Значение:

• Ясно показывает область ответственности системы
• Акторы находятся снаружи границы
• Use cases находятся внутри границы

3. Use Case (Сценарий использования)

Use case — это процесс или функция, которую система предоставляет актору. Представляет связную последовательность взаимодействия, которая даёт актору измеримый результат.

Примеры use cases:

• Register User (регистрация пользователя)
• Place Order (создание заказа)
• Process Payment (обработка платежа)
• Generate Report (создание отчёта)
• Send Notification (отправка уведомления)

Визуально: овал/эллипс с именем внутри.

Характеристики хорошего use case:

• Имеет чёткое начало и конец
• Добавляет ценность для актора или системы
• Охватывает один основной процесс (не слишком большой, не слишком маленький)
• Не описывает как, а что** система делает

4. Association (Связь актор-use case)

Связь — это линия, которая соединяет актора с use case, указывая, что актор участвует в этом сценарии.

Типы:

• Простая линия — актор просто участвует
• Стрелка к актору — система инициирует, актор получает результат

Отношения между Use Cases

1. Include (Включение)

Пунктирная стрелка с labels "<<include>>" показывает, что один use case обязательно включает другой.

Пример:

Place Order <<includes>> Validate Payment

Смысл: Когда выполняется "Place Order", ВСЕГДА будет выполнен "Validate Payment".

Использование:

• Избежать дублирования
• Выделить общую логику
• Разбить сложный use case на подчасти

2. Extend (Расширение)

Пунктирная стрелка с label "<<extend>>" показывает, что один use case может расширить другой в определённых условиях.

Пример:

Place Order <<extends>> Apply Discount (условие: есть промо-код)

Смысл: "Apply Discount" выполняется ТОЛЬКО если выполнены определённые условия.

Использование:

• Моделировать опциональное поведение
• Обработка исключений
• Альтернативные потоки

3. Generalization (Обобщение)

Стрелка без пунктира показывает, что один use case — это специализация другого.

Пример:

Pay by Card --> Pay (родитель)
Pay by PayPal --> Pay (родитель)

Смысл: Разные способы оплаты — это варианты базового use case "Pay".

Пример: Система заказа пищи (Food Delivery)

Actor: Customer
Actor: Admin
Actor: Payment Gateway

System Boundary: Food Delivery App

Use Cases:
- Browse Restaurant <<accessed by>> Customer
- Add to Cart <<accessed by>> Customer
- Place Order <<accessed by>> Customer
  - Place Order <<includes>> Validate Cart
  - Place Order <<includes>> Select Delivery Address
  - Place Order <<extends>> Apply Coupon (условие: есть код)
  - Place Order <<includes>> Process Payment
- Track Order <<accessed by>> Customer
- Cancel Order <<accessed by>> Customer
  - Cancel Order <<extends>> Refund (условие: платёж уже прошёл)
- View Statistics <<accessed by>> Admin
- Process Payment <<accessed by>> Payment Gateway

Таблица компонентов

Правила создания Use Case Diagram

1. Выделяй акторов на основе ролей, а не конкретных людей
2. Один use case = один основной процесс, не задачи
3. Избегай деталей реализации — диаграмма о "что", не "как"
4. Используй clear naming — глаголы в infinitive (Place, Register, View)
5. Include для переиспользуемой логики, extend для опциональных путей
6. Не переусложняй — слишком много use cases = нечитаемая диаграмма

Когда использовать Use Case Diagram

• На ранних этапах анализа для понимания scope проекта
• Для коммуникации с бизнесом — наглядно показывает функциональность
• Для определения требований — каждый use case = требование
• Для планирования спринтов — use cases могут быть основой для user stories

Выводы

Use Case Diagram — это незаменимый инструмент для System Analyst. Хорошая диаграмма помогает выявить пропущенные требования, коммуницировать с заинтересованными лицами и планировать разработку. Ключ к успеху — простота и фокус на пользовательских сценариях, а не на деталях реализации.