Диаграммы вариантов использования: Практическое руководство

А диаграмма вариантов использования — это диаграмма поведения UML, которая показывает, как внешние пользователи или системы взаимодействуют с системой. Она фокусируется на том, что делает система с точки зрения актора, а не на внутренних деталях реализации.

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

1. Что показывает диаграмма вариантов использования

Диаграмма вариантов использования обычно содержит:

• Граница системы — определяет, что находится внутри моделируемой системы.

• Акторы — внешние пользователи, организации, устройства или системы, взаимодействующие с ней.

• Варианты использования — цели или услуги, которые предоставляет система.

• Связи — связи связи между акторами и вариантами использования.

• Связи между вариантами использования — например, <<include>> и <<extend>>.

• Обобщение — наследование между актерами или вариантами использования.

Диаграмма вариантов использования обычно не показывает:

• Шаги алгоритма

• Таблицы базы данных

• Классы программы

• Внутренние рабочие процессы

• Детальные макеты пользовательского интерфейса

• Последовательности сообщений во времени

Эти детали лучше отображаются с помощью диаграмм активности, классов, последовательностей или состояний.

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

Граница системы

Граница системы — это прямоугольник, окружающий варианты использования, принадлежащие системе.

Например, в системе онлайн-покупок:

+--------------------------------------+
|        Система онлайн-покупок         |
|                                      |
|  (Просмотр продуктов)                |
|  (Помещение заказа)                  |
|  (Оплата)                            |
+--------------------------------------+

Актеры остаются за пределами границы, потому что они внешние по отношению к системе.

Граница помогает уточнить область системы. Если функция находится за границей, она не реализуется системой, которая моделируется.

Акторы

Аактор — это все, что внешнее, взаимодействующее с системой для достижения цели.

Акторы могут включать:

• Человеческие пользователи

• Внешние приложения

• Аппаратные устройства

• Другие организации

• Время или запланированные события, когда моделируются как внешние триггеры

Примеры:

• Клиент

• Библиотекарь

• Платежный шлюз

• Администратор

• Сервис электронной почты

Актор представляет собойроль, не обязательно конкретное лицо. Например, «Клиент» обычно лучше, чем «Алекс».

Актеры могут быть:

• Основные актеры — инициируют взаимодействия для достижения цели.

• Вспомогательные актеры — предоставляют услуги системе.

Например, клиент может инициировать «Создать заказ», в то время как шлюз оплаты поддерживает «Обработать оплату».

Сценарии использования

Сценарий использованияuse case представляет собой значимую цель или услугу, предоставляемую системой.

Хорошие названия сценариев использования обычно следуют этой форме:

Глагол + объект

Примеры:

• Зарегистрировать учетную запись

• Поиск в каталоге

• Подать заявку

• Создать отчет

• Отменить бронирование

• Обработать оплату

Кейс использования должен описывать наблюдаемый результат, а не внутренний шаг реализации.

Предпочтительно:

Оформить заказ

вместо:

Проверить объект заказа

Второй описывает внутреннюю операцию, а не цель пользователя.

Связи

Связь — это коммуникационная связь между актором и случаем использования.

Она указывает, что актор участвует в случае использования или инициирует его.

Клиент ---- (Оформить заказ)

Связи обычно не указывают последовательность, поток управления или направление. Если важен порядок взаимодействий, используйте диаграмму последовательности или диаграмму деятельности.

3. Связи между случаями использования

<<включить>>

Используйте <<включить>> когда один случай использования всегда используетдругой случай использования.

Например, оформление заказа всегда может требовать аутентификации:

(Оформить заказ) ..> (Аутентифицировать клиента) : <<включить>>

Базовый случай использования зависит от включенного случая использования.

Использовать включить когда:

• Поведение обязательно.

• Поведение повторно используется несколькими случаями использования.

• Извлечение поведения улучшает ясность.

Пример:

(Снять наличные) ..> (Аутентификация карты) : <<включить>>
(Проверить баланс) ..> (Аутентификация карты) : <<включить>>

Оба случая использования всегда требуют аутентификации карты.

<<расширить>>

Использовать <<расширить>> когда дополнительное поведение является необязательным или условно вставляется в базовый случай использования.

(Применить скидку) ..> (Сделать заказ) : <<расширить>>

Поведение скидки происходит только при соблюдении условий допуска.

Использовать расширить когда:

• Поведение необязательно.

• Оно происходит только при определённом условии.

• Базовый вариант использования завершён без него.

Примеры:

• «Добавить подарочную упаковку» расширяет «Сделать заказ».

• «Запросить возврат средств» расширяет «Отменить подписку».

• «Отправить промо-рассылку» расширяет «Завершить регистрацию».

Стрелка указывает от расширяющего варианта использования к базовому варианту использования.

Обобщение

Обобщение представляет собой отношение «является» между акторами или вариантами использования.

Например:

Премиум-пользователь --|> Пользователь

Премиум-пользователь — это разновидность пользователя и наследует взаимодействия пользователя.

Обобщение акторов может быть полезным, когда несколько акторов имеют общее поведение:

Администратор --|> Сотрудник
Библиотекарь --|> Сотрудник

Используйте обобщение умеренно. Если отношение является просто «использует» или «участвует в», то обычно более уместно использовать ассоциацию.

4. Основные и вспомогательные акторы

Рассмотрим сценарий онлайн-оплаты:

• ТакойПокупательявляется основным актором, потому что инициирует покупку.

• Тот Платежный шлюз является вспомогательным участником, потому что обрабатывает платеж по запросу системы.

Простая модель может выглядеть следующим образом:

Клиент ---- (Сделать заказ)
(Сделать заказ) ---- Платежный шлюз

Различие полезно, потому что оно уточняет, кто извлекает выгоду из использования, и какие внешние системы вовлечены.

5. Как определить случаи использования

Практический способ выявления случаев использования — задать следующие вопросы:

1. Кто использует систему?

2. Какую цель каждый участник хочет достичь?

3. Какие услуги предоставляет система?

4. Какие события запускают поведение системы?

5. С какими внешними системами должна взаимодействовать система?

6. Какое поведение всегда необходимо?

7. Какое поведение является необязательным или условным?

Для каждого участника перечислите их цели:

Цель должна иметь значение для исполнителя. Избегайте превращения каждой небольшой операции системы в вариант использования.

6. Рекомендации по наименованию

Используйте четкие, ориентированные на цель имена.

Хорошие примеры:

• Создать учетную запись

• Обновить профиль

• Подать заявку

• Отслеживать отправку

• Утвердить запрос

• Создать счет-фактуру

Избегайте неясных названий:

• Обработка системы

• Обрабатывать данные

• Функция пользователя

• Запустить операцию

Избегайте избыточных технических деталей:

• Выполнить SQL-запрос

• Вызвать REST-конечную точку

• Создать экземпляр PaymentService

Это могут быть допустимые шаги реализации, но обычно они не полезны в качестве высокого уровня использования.

7. Пример: система управления библиотекой

Предположим, что система библиотеки поддерживает:

• Члены, ищущие книги

• Члены, берущие книги в аренду

• Члены, возвращающие книги

• Библиотекари, управляющие каталогом

• Уведомления о просрочке

• Обработка оплаты штрафов

Возможные участники:

• Член клуба

• Библиотекарь

• Сервис уведомлений

• Сервис оплаты

Возможные варианты использования:

• Поиск в каталоге

• Взять книгу

• Сдать книгу

• Рассчитать штраф

• Заплатить штраф

• Управление каталогом

• Отправить уведомление о просрочке

Связи:

• Взять книгу включает проверку членства.

• Взять книгу включает проверку доступности книги.

• Сдать книгу включает расчет штрафа.

• Оплата штрафа взаимодействует с сервисом оплаты.

• Создание уведомления о просрочке взаимодействует с сервисом уведомлений.

8. Пример PlantUML

Следующий код PlantUML создает диаграмму вариантов использования для библиотечной системы:

@startuml
направление слева направо

title Система управления библиотекой - Диаграмма вариантов использования

актер Член
актер Библиотекарь
актер "Сервис уведомлений" как Уведомление
актер "Сервис оплаты" как Оплата

прямоугольник "Система управления библиотекой" {

  вариант использования "Поиск каталога" как UC_Search
  вариант использования "Заказать книгу" как UC_Borrow
  вариант использования "Сдать книгу" как UC_Return
  вариант использования "Проверить членство" как UC_CheckMember
  вариант использования "Проверить наличие книги" как UC_CheckAvailability
  вариант использования "Рассчитать штраф" как UC_CalculateFine
  вариант использования "Оплатить штраф" как UC_PayFine
  вариант использования "Управление каталогом" как UC_ManageCatalog
  вариант использования "Отправить уведомление о просрочке" как UC_Notify
}

Член --> UC_Search
Член --> UC_Borrow
Член --> UC_Return
Член --> UC_PayFine

Библиотекарь --> UC_ManageCatalog
Библиотекарь --> UC_Borrow
Библиотекарь --> UC_Return

Оплата --> UC_PayFine
Уведомление --> UC_Notify

UC_Borrow ..> UC_CheckMember : <<включает>>
UC_Borrow ..> UC_CheckAvailability : <<включает>>
UC_Return ..> UC_CalculateFine : <<включает>>

UC_Notify ..> UC_Return : <<расширяет>>

@enduml

9. Объяснение примера

Актеры

актер Член
актер Библиотекарь
актер "Сервис уведомлений" как Уведомление
актер "Сервис оплаты" как Оплата

Диаграмма моделирует двух человеко-актеров и два внешних сервиса.

Псевдонимы, такие как как уведомление делает длинные имена проще для последующего использования.

Граница системы

rectangle "Система управления библиотекой" {
    ...
}

Прямоугольник определяет границы системы. Сценарии использования внутри прямоугольника предоставляются библиотечной системой.

Ассоциации участников

Член --> UC_Поиск
Член --> UC_Займы

Эти ассоциации показывают, что член может искать в каталоге и брать книги.

Направление стрелки обычно не имеет семантического значения на простой диаграмме вариантов использования. Оно в основном используется для улучшения читаемости диаграммы.

Связи включения

UC_Borrow ..> UC_CheckMember : <<include>>
UC_Borrow ..> UC_CheckAvailability : <<include>>

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

Связь расширения

UC_Notify ..> UC_Return : <<extend>>

Это означает, что поведение уведомления о просрочке — это дополнительное поведение, связанное с возвратом книги.

Однако в реальной модели требований более естественным решением может быть связь «Отправить уведомление о просрочке» с запланированным процессом или актором, таким как «Планировщик библиотеки». Лучшее отношение зависит от реальных бизнес-правил.

10. Более подробное описание варианта использования

Диаграмма дает обзор, но каждый важный вариант использования, как правило, должен иметь текстовое описание.

Вариант использования: взять книгу

Диаграмма вариантов использования не должна пытаться содержать всю эту детализацию. Диаграмма предоставляет карту; спецификация определяет поведение.

11. Справочник по синтаксису PlantUML

Объявление актеров

актер Клиент
актер "Платежный шлюз" как Шлюз

Объявление вариантов использования

usecase "Сделать заказ" как PlaceOrder
usecase "Обработать оплату" как ProcessPayment

Создание границы системы

rectangle "Онлайн-магазин" {
    usecase "Просмотреть товары" как Browse
    usecase "Сделать заказ" как Order
}

Связывание акторов и случаев использования

Клиент --> Browse
Клиент --> Order

Включить

Order ..> ProcessPayment : <<включить>>

Расширить

ApplyCoupon ..> Order : <<расширить>>

Обобщение актора

PremiumCustomer --|> Customer

Группировка пакетов

Пакеты могут визуально группировать связанные случаи использования:

rectangle "Банковская система" {
  package "Управление счетами" {
    usecase "Открыть счет" as OpenAccount
    usecase "Закрыть счет" as CloseAccount
  }

  package "Платежи" {
    usecase "Перевод средств" as TransferFunds
    usecase "Оплатить счет" as PayBill
  }
}

Примечания

note right of PlaceOrder
  Клиент должен быть аутентифицирован
  перед размещением заказа.
end note

12. Улучшение компоновки диаграммы

PlantUML автоматически располагает диаграммы, но несколько техник улучшают читаемость.

Управление направлением

направление слева направо

Это часто полезно, когда актеры должны располагаться по бокам, а случаи использования — в центре.

Другие распространенные направления включают:

направление сверху вниз

Использовать псевдонимы

Вместо повторения длинных имен:

usecase "Проверка идентичности клиента" как VerifyIdentity

Затем ссылка:

RegisterAccount ..> VerifyIdentity : <<include>>

Группировать связанные случаи использования

Используйте пакеты или вложенные прямоугольники для разделения функциональных областей:

package "Управление заказами" {
    usecase "Создать заказ" as CreateOrder
    usecase "Отменить заказ" as CancelOrder
}

Избегайте чрезмерных пересечений

Схема становится трудно читаемой, когда слишком много линий пересекаются. Вы можете улучшить её, выполнив следующее:

• Размещение связанных участников рядом с их вариантами использования

• Группировка вариантов использования в пакеты

• Разделение одной большой схемы на несколько меньших схем

• Использование псевдонимов для ясных ссылок

• Избегание ненужных связей

13. Распространённые ошибки

Моделирование внутренних функций как вариантов использования

Обычно это слишком технически:

Проверить подключение к базе данных
Сериализовать запрос
Вызвать API оплаты

Предпочтение внешним, значимым целям:

Произвести оплату
Подать заявку
Создать отчёт

Рассматривание каждого участника как человека

Внешние системы и устройства также могут быть участниками:

• Платежный шлюз

• Поставщик удостоверений

• Система складского учета

• Сканер штрих-кода

• Сервис уведомлений

Использование включить для необязательного поведения

Если поведение необязательно, используйтерасширить вместовключить.

Неправильно:

Сделать заказ ..> Применить купон : <<включить>>

Если применение купона является необязательным, используйте:

Применить купон ..> Сделать заказ : <<расширить>>

Использование расширить для обязательного поведения

Если поведение всегда происходит, его обычно следует моделировать с помощьювключить.

Сделать заказ ..> Аутентификация клиента : <<включить>>

Прямое соединение вариантов использования без смысла

Линия между двумя вариантами использования должна представлять действительную связь UML. Избегайте произвольных соединений, которые лишь подразумевают, что варианты использования как-то связаны.

Создание одного гигантского диаграммы

Диаграмма вариантов использования должна четко передавать информацию на высоком уровне. Если она содержит десятки акторов и вариантов использования, создайте несколько диаграмм, организованных по подсистемам или бизнес-областям.

Показ последовательности

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

14. Когда использовать другие диаграммы UML

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

15. Рекомендуемый процесс моделирования

1. Определите границы системы.

2. Определите всех внешних участников.

3. Определите цели каждого участника.

4. Преобразуйте эти цели в случаи использования.

5. Соедините участников с случаями использования, в которых они участвуют.

6. Определите обязательное повторно используемое поведение и моделируйте его с помощью <<include>>.

7. Определите необязательное или условное поведение и моделируйте его с помощью <<extend>>.

8. Добавляйте обобщение только там, где существует подлинное отношение «является».

9. Обсудите диаграмму с заинтересованными сторонами.

10. Добавьте текстовые спецификации для важных вариантов использования.

11. Разделите диаграмму, если она станет перегруженной.

16. Компактный шаблон PlantUML

Вы можете использовать это как отправную точку:

@startuml
направление слева направо

title Диаграмма вариантов использования системы

актер Пользователь
актер "Внешняя система" как ВнешняяСистема

прямоугольник "Название системы" {
  вариант использования "Основная цель пользователя" как ОсновнаяЦель
  вариант использования "Необходимое общее поведение" как НеобходимоеПоведение
  вариант использования "Дополнительное поведение" как ДополнительноееПоведение
}

Пользователь --> ОсновнаяЦель
ВнешняяСистема --> ОсновнаяЦель

ОсновнаяЦель ..> НеобходимоеПоведение : <<включает>>
ДополнительноееПоведение ..> ОсновнаяЦель : <<расширяет>>

@enduml

Центральный принцип заключается в моделировании целей, видимых извне, а не внутренних деталей реализации. Хорошая диаграмма вариантов использования сразу делает понятными границы системы, акторы, возможности и важные зависимости.

Ссылка

Эта статья также доступна на Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Việt Nam, 简体中文 and 繁體中文