Что такое диаграмма вариантов использования?
A Диаграмма вариантов использованияЭто поведенческий чертеж, используемый для визуализации взаимосвязей между пользователями системы (называемыми актерами) и конкретными действиями или целями, которые они хотят достичь (называемыми вариантами использования). В отличие от отображения пошаговых логических циклов, диаграмма вариантов использования предоставляет общий обзор функциональной области системы, что делает её отличным инструментом для определения требований к проекту, границ системы и рабочих процессов заинтересованных сторон.
С помощью VPasCode, вы можете мгновенно создавать четкие, профессиональные диаграммы вариантов использования, не борясь с выравниванием визуальной области холста. Это руководство пропускает неясные, устаревшие обозначения и фокусируется исключительно на практических элементах синтаксиса, необходимых для повседневной документации программного обеспечения.
Основное руководство по синтаксису: элементы и конструкции
Построение диаграммы вариантов использования в PlantUML основано на нескольких простых структурных элементах, заключенных внутри стандартных тегов @startuml и @enduml тегов.
1. Объявление актеров
Актер представляет собой внешнюю сущность, взаимодействующую с вашим приложением (например, человек-пользователь, фоновая служба или внешний API аппаратного обеспечения). Вы объявляете актера, используя ключевое слово actor за которым следует внутренний сокращенный идентификатор:
actor customer
actor admin as "Системный администратор"
Совет профессионала: Используйте ключевое слово as для назначения чистой, легко читаемой строки отображения сложным идентификаторам актеров.
2. Определение вариантов использования
Вариант использования представляет собой функциональную цель или бизнес-процесс. Вы можете определить вариант использования двумя способами: обернув текст в круглые скобки (Ваш вариант использования), или явно используя использование случаяключевое слово для сложного форматирования:
(Вход в панель управления)
использование случая checkout как "Обработка оплаты кредитной картой"
3. Картирование базовых взаимодействий
Чтобы соединить ваших актеров с соответствующими случаями использования, используйте базовые направленные или ненаправленные линии взаимодействия. Вы также можете добавить текстовые метки, чтобы добавить критически важный контекст к взаимодействию:
customer --> (Вход в панель управления)
admin --> checkout : "Утверждает возвраты средств"
4. Расширенные отношения: Включение и Расширение
При моделировании сложного поведения системы вам часто нужно показать зависимости между различными случаями использования с помощью стандартной стереотипизации UML:
- Включить (обязательная зависимость):Указывает, что базовый случай использования зависит от другого вспомогательного случая использования для успешного завершения своей работы. Используйте пунктирную линию соединения (
..>) с добавленной текстовой меткой:Plantuml Edit Plantuml in VPasCode(Обработка заказа) ..> (Проверка баланса) : <<включить>>
- Расширить (необязательное/условное поведение):Указывает, что необязательный рабочий процесс может отклоняться от базового случая использования при определенных условиях. Обратите внимание, что стрелка направлена от *расширения* к *базовому* случаю использования:
Plantuml Edit Plantuml in VPasCode
(Применение промо-кода) ..> (Обработка заказа) : <<расширить>>
5. Установление границ системы
Чтобы четко различать, что происходит внутри вашей программной системы, а что — снаружи, используйте “прямоугольникключевое слово для обертывания ваших внутренних случаев использования. Критически важно, чтобы актеры оставались за пределами этого блока-оболочки, чтобы отразить их статус внешних участников:
актер customer
прямоугольник "Платформа электронной коммерции" {
(Просмотр каталога)
(Добавить в корзину)
}
customer --> (Просмотр каталога)
customer --> (Добавить в корзину)
Рекомендации по созданию чистых компоновок
- Держите текст кратким:Случаи использования всегда должны начинаться с ясного, действительного глагола (например, «Создать отчет», «Обновить профиль») вместо длинного предложения.
- Используйте направляющие ориентиры: Если ваши актеры и случаи использования скапливаются в беспорядочной стопке, используйте стрелки пространственного направления, такие как
-right->или-down->чтобы мягко направить движок компоновки на создание чистой, легко читаемой структуры. - Выделяйте границы системы: Всегда используйте прямоугольник границы при документировании приложений, взаимодействующих с несколькими сторонними микросервисами. Это сразу делает понятным, кто владеет каким процессом.
Примеры диаграмм случаев использования PlantUML в реальных условиях
Скопируйте и вставьте следующие практические чертежи непосредственно в панель живого редактора VPasCode, чтобы увидеть, как они динамически отображаются.
Пример 1: Основная аутентификация пользователей и управление учетными записями
Этот чертеж моделирует стандартную экосистему приложения, содержащую основного пользователя, административного оператора и рамку, содержащую основные механизмы безопасности.
@startuml
' Установить ориентацию компоновки слева направо
слева направо направление
актер "Конечный пользователь" как user
актер "Администратор безопасности" как admin
прямоугольник "Служба предоставления удостоверений" {
(Войти)
(Сбросить пароль)
(Обновить данные профиля)
(Просмотреть журналы безопасности)
(Деактивировать учетные записи)
}
user --> (Войти)
user --> (Сбросить пароль)
user --> (Обновить данные профиля)
(Просмотреть журналы безопасности) <-- admin
(Деактивировать учетные записи) <-- admin
@enduml
Разбор синтаксиса: Направление направление слева направо заставляет движок макета размещать актеров на внешних краях и расширять случаи использования горизонтально, а не вертикально. Обратите внимание, как размещение объявления актеров чисто за пределами прямоугольникаобертки сохраняет их организованность, при этом изменяя направление скобки стрелки для пользователя-администратора (<-- админ) прикрепляет их чисто к правой стороне матрицы диаграммы.
Пример 2: Расширенная система оформления заказа в электронной коммерции с внешними зависимостями
Этот макет реальной системы отображает сложный процесс оформления заказа, который зависит от внешних банковских API, структурных включений и необязательных флагов расширения.
@startuml
направление слева направо
актер "Покупатель" как покупатель
актер "Сотрудник склада" как сотрудник
актер "Шлюз Stripe" как stripe
прямоугольник "Система выполнения заказов в интернет-магазине" {
(Оформить заказ)
(Применить купон)
(Создать счет)
(Выбрать и упаковать товары)
(Обновить статус доставки)
}
' Внешние взаимодействия с границами системы
customer --> (Оформить заказ)
(Оформить заказ) --> stripe : "Авторизовать средства"
' Структуры включения и расширения
(Оформить заказ) ..> (Создать счет) : <<включить>>
(Применить купон) ..> (Оформить заказ) : <<расширить>>
' Пути выполнения
(Выбрать и упаковать товары) <-- сотрудник
(Обновить статус доставки) <-- сотрудник
(Создать счет) --> сотрудник : "Отправить копию по электронной почте"
@enduml
Разбор синтаксиса: Этот шаблон показывает, как один случай использования (Оформить заказ) требует вызова (Создать счет) с использованием <<включить>> тега по пунктирной линии. В то же время применение купонного кода правильно моделируется как необязательный путь через <<расширить>> указывающий назад к основному выполнению. Все внешние актеры остаются четко изолированными за пределами оболочки системы.