Руководство по диаграммам вариантов использования PlantUML

Введение

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

PlantUML делает использование сценариев моделирования практичным через текстовый основанный на тексте синтаксис который может быть сохранён, просмотрен, версионирован, и перегенерирован вместе с проектной документацией или источник код. С несколькими командами, вы можете определить актёров, использовать сценарии, границы системы, ассоциациям, <<включить>> связям, <<расширить>> связям, обобщению, примечаниям, и разметке предпочтениям.

Это руководство объясняет ключевые аспекты PlantUML использовать случай обозначение показано в справочном листе и демонстрирует как применить его его его в реалистичный примеры. Оно также вводит широкий более широкий инструментарий рабочий процесс с использованием визуального парадигмы UML, с поддержкой ИИ моделирование, и VPasCode. Вместе, эти инструменты поддерживают полный процесс: превращение требований в первоначальный начальный этап модель, валидация UML связей, уточнение финальной диаграммы, и поддержание финальной финальной модели в виде читаемой диаграммы источник.

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

PlantUML позволяет создавать диаграммы вариантов использования с помощью простой текстовой нотации.

1. Базовая структура PlantUML

Каждая диаграмма PlantUML начинается с @startuml и заканчивается @enduml.

@startuml

' Содержимое диаграммы идёт здесь

@enduml

Комментарии начинаются с апострофа:

' Это комментарий

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

/'
Это многострочный комментарий
'/

2. Определение акторов

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

Базовый актор

actor User

Это создаёт актора в виде палочного человечка с именем Пользователь.

Актор с псевдонимом

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

actor "Платёжный шлюз" как payment
actor "Системный администратор" как admin

Затем вы можете ссылаться на псевдонимы:

payment --> ProcessPayment
admin --> ManageUsers

Актор с другим визуальным стилем

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

skinparam actorStyle awesome

actor Customer

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

skinparam actorStyle hollow

actor Customer

Точный внешний вид зависит от движка рендеринга PlantUML и параметров скина.

3. Определение сценариев использования

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

Базовый сценарий использования

usecase "Вход в систему"

PlantUML отображает это как эллипс с подписью Войти.

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

usecase "Обработка оплаты кредитной картой" как ProcessPayment

Видимая подпись Обработка оплаты кредитной картой, в то время как ProcessPayment используется в отношениях.

actor Customer
Customer --> ProcessPayment

Имена сценариев использования в несколько строк

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

usecase "ОбработкаnОплатыnКредитной картой" as ProcessPayment

Это полезно, когда диаграмма содержит длинные подписи.

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

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

rectangle "Система онлайн-покупок" {
    usecase "Просмотр товаров" as Browse
    usecase "Оформление заказа" as Checkout
}

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

Вы также можете использовать именованный псевдоним для границы:

rectangle "Система онлайн-покупок" as OnlineStore {
    usecase "Просмотр товаров" as Browse
    usecase "Оформление заказа" as Checkout
}

Граница системы полезна при различении поведения системы с внешними акторами и сервисами.

5. Соединение акторов и сценариев использования

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

Ненаправленная связь

Клиент -- Просмотр

Это создаёт сплошную линию без стрелки.

Направленная связь

Клиент --> Просмотр

Это создаёт сплошную линию со стрелкой, указывающей на сценарий использования.

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

Связь с подписью

Клиент --> Оформление заказа : начинается

Подпись описывает взаимодействие.

Клиент --> ПросмотрЗаказов : просматривает историю заказов

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

Клиент ---> ОформлениеЗаказа : начинает

6. Это <<включить>> связь

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

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

PlaceOrder ..> ValidatePayment : <<include>>

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

Базовый сценарий использования ..> Включаемый сценарий использования : <<include>>

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

Пример

usecase "Оформление заказа" как Checkout
usecase "Проверка данных клиента" как ValidateCustomer
usecase "Расчёт общей суммы заказа" как CalculateTotal
usecase "Оплата" как MakePayment

Checkout ..> ValidateCustomer : <<include>>
Checkout ..> CalculateTotal : <<include>>
Checkout ..> MakePayment : <<include>>

Это означает:

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

2. Оформление заказа всегда рассчитывает общую сумму заказа.

3. Оформление заказа всегда выполняет оплату.

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

7. «<<extend>>» связь

Связь «extend» связь представляет собой необязательное, условное или исключительное поведение, добавляемое к базовому сценарию использования.

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

ApplyDiscount ..> Checkout : <<extend>>

Направление следующее:

Дополнительный расширяющий сценарий ..> Базовый сценарий : <<extend>>

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

Правильный пример

usecase "Оформление заказа" как Checkout
usecase "Применить купон скидки" как ApplyDiscount

ApplyDiscount ..> Checkout : <<extend>>

Это означает, чтоПрименить купон скидкиопционально расширяетОформление заказа процесс.

Сравнение включений и расширений

Пример:

Оформление заказа ..> Проверка оплаты : <<include>>
Применение скидки ..> Оформление заказа : <<extend>>

Избегайте обращения этих связей, так как направление изменяет их смысл.

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

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

usecase "Поиск товаров" как SearchProducts
usecase "Просмотр товаров" как BrowseProducts

SearchProducts -|> BrowseProducts

Пустой треугольник указывает на более общий вариант использования.

Это означает, что Поиск товаров является специализированным вариантом Просмотр товаров.

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

9. Обобщение акторов

Акторы также могут иметь отношения обобщения.

actor Customer
actor "Premium Customer" as PremiumCustomer

PremiumCustomer -|> Customer

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

Например:

PremiumCustomer --> ApplyDiscount

10. Примечания и аннотации

Заметки добавляют пояснения или ограничения к диаграмме.

Заметка, привязанная к сценарию использования

note right of Checkout
  Клиент должен предоставить
  действительные платежные данные.
end note

Другие позиции включают:

note left of Checkout
  Процесс, ориентированный на клиента
end note

note top of Checkout
  Основной бизнес-процесс
end note

note bottom of Checkout
  Включает обработку платежей
end note

Синтаксис короткой заметки

note справа от Login : Требуется аутентификация пользователя

Отдельная заметка с псевдонимом

note "Оплата должна быть авторизованаnперед подтверждением заказа" как PaymentNote

Соедините заметку с элементом пунктирной линией:

PaymentNote .. MakePayment

Заметки для ограничений

Заметки полезны для документирования условий:

заметка справа от ApplyDiscount
  Опциональное поведение:
  используется только при
  предоставлении действительного
  купона.
конец заметки

11. Направление макета

По умолчанию PlantUML автоматически выбирает макет. Вы можете влиять на направление.

Макет слева направо

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

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

Вертикальная компоновка сверху вниз

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

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

Невидимые ссылки компоновки

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

Клиент -[скрыто]-> Оформление заказа

Это полезно для улучшения макета диаграммы.

12. Стилизация диаграммы

Удалить тени

skinparam shadowing false

Использовать прямоугольные пакеты и границы

skinparam packageStyle rectangle

Установить цвета

skinparam usecase {
    BackgroundColor #FDFDFD
    BorderColor #333333
}

skinparam actor {
    BorderColor #333333
}

Установить цвета стрелок

skinparam ArrowColor #555555

Установить размер шрифта по умолчанию

skinparam defaultFontSize 14

Полный раздел стилей может выглядеть так:

skinparam shadowing false
skinparam packageStyle rectangle
skinparam actorStyle awesome
skinparam defaultFontSize 14

skinparam usecase {
    BackgroundColor #F9FBFF
    BorderColor #234
}

skinparam ArrowColor #555555

13. Пакеты и группировка

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

package "Функции клиента" {
    usecase "Регистрация аккаунта" as Register
    usecase "Вход в систему" as Login
    usecase "Просмотр товаров" as Browse
}

package "Функции администратора" {
    usecase "Управление товарами" as ManageProducts
    usecase "Генерация отчета о продажах" as SalesReport
}

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

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

rectangle "Управление заказами" {
    usecase "Оформление заказа" as PlaceOrder
    usecase "Отслеживание заказа" as TrackOrder
    usecase "Отмена заказа" as CancelOrder
}

14. Внешние системы

Внешние приложения или сервисы могут быть представлены как актеры.

actor "Платёжный шлюз" как PaymentGateway
actor "Служба электронной почты" как EmailService
actor "Внешняя CRM" как CRM

Подключите их к системным сценариям использования:

PaymentGateway --> MakePayment
EmailService --> SendConfirmation
CRM --> SynchronizeCustomer

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

15. Полный пример

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

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

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

skinparam shadowing false
skinparam packageStyle rectangle
skinparam actorStyle awesome

skinparam usecase {
    BackgroundColor #F9FBFF
    BorderColor #333333
}

skinparam ArrowColor #555555

' Актеры
actor Клиент как customer
actor "Премиум-клиент" как premium
actor Администратор как admin
actor "Платежный шлюз" как payment
actor "Служба электронной почты" как email

' Обобщение актеров
premium -|> customer

' Граница системы
rectangle "Система онлайн-покупок" {

    ' Варианты использования клиента
    usecase "Регистрация аккаунта" как Register
    usecase "Вход в систему" как Login
    usecase "Просмотр товаров" как Browse
    usecase "Поиск товаров" как Search
    usecase "Просмотр деталей товара" как ViewProduct
    usecase "Добавить товар в корзину" как AddToCart
    usecase "Просмотр корзины" как ViewCart
    usecase "Оформление заказа" как Checkout
    usecase "Разместить заказ" как PlaceOrder
    usecase "Отследить заказ" как TrackOrder
    usecase "Отменить заказ" как CancelOrder

    ' Совместное включенное поведение
    usecase "Проверка данных клиента" как ValidateCustomer
    usecase "Расчет общей суммы заказа" как CalculateTotal
    usecase "Осуществить оплату" как MakePayment
    usecase "Отправить подтверждение заказа" как SendConfirmation

    ' Опциональное поведение
    usecase "Применить купон со скидкой" как ApplyDiscount
    usecase "Запросить возврат" как RequestRefund

    ' Варианты использования администратора
    usecase "Управление товарами" как ManageProducts
    usecase "Сформировать отчет о продажах" как SalesReport
}

' Связи актеров
customer --> Register
customer --> Login
customer --> Browse
customer --> Search
customer --> ViewProduct
customer --> AddToCart
customer --> ViewCart
customer --> Checkout
customer --> TrackOrder
customer --> CancelOrder

premium --> ApplyDiscount
premium --> RequestRefund

admin --> ManageProducts
admin --> SalesReport

payment --> MakePayment
email --> SendConfirmation

' Отношения включения
Checkout ..> ValidateCustomer : <<include>>
Checkout ..> CalculateTotal : <<include>>
Checkout ..> PlaceOrder : <<include>>

PlaceOrder ..> MakePayment : <<include>>
PlaceOrder ..> SendConfirmation : <<include>>

' Отношения расширения
ApplyDiscount ..> Checkout : <<extend>>
RequestRefund ..> CancelOrder : <<extend>>

' Обобщение вариантов использования
Search -|> Browse

' Примечания
note right of Checkout
    Основной процесс покупки клиента
end note

note right of ApplyDiscount
    Опциональное поведение:
    используется только при наличии
    действительного купона
end note

note bottom of MakePayment
    Оплата обрабатывается
    внешним платежным шлюзом
end note

@enduml

16. Чтение полного примера

Диаграмма передает следующую информацию:

• Клиент может просматривать товары, добавлять товары в корзину и оформлять заказ.

• Премиум-клиент является специализированной формой Клиент.

• Оформление заказа всегда включает проверку клиента, расчёт общей суммы и оформление заказа.

• Оформить заказ всегда включает оплату и подтверждение.

• Применить купон со скидкой является необязательным и расширяет процесс оформления заказа.

• Запросить возврат средств является необязательным расширением отмены.

• Платёжный шлюз обрабатывает платежи.

• Служба электронной почты отправляет подтверждения заказов.

• Администратор управляет товарами и формирует отчёты.

17. Типичные ошибки

Отмена включить

Неверно:

ValidateCustomer ..> Checkout : <<включить>>

Верно:

Checkout ..> ValidateCustomer : <<включить>>

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

Обратноерасширение

Неверно:

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

Верно:

ApplyDiscount ..> Checkout : <<extend>>

Дополнительный расширяющий сценарий указывает на базовый сценарий.

Используя include для дополнительного поведения

Если поведение происходит только при определённых условиях, используйте <<extend>>:

ApplyDiscount ..> Checkout : <<extend>>

Если это происходит всегда, используйте <<include>>:

Checkout ..> ValidateCustomer : <<include>>

Размещение внешних акторов внутри границ системы

Внешние пользователи и сервисы обычно должны находиться за пределами прямоугольника:

actor Customer

rectangle "Система покупок" {
    usecase "Оформление заказа" as Checkout
}

Customer --> Checkout

Создание чрезмерно детализированных сценариев использования

Сценарий использования должен описывать значимую цель пользователя, например:

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

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

18. Минимальный практический шаблон

Для более простой диаграммы используйте этот шаблон:

@startuml

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

actor Пользователь

rectangle "Моя система" {
    usecase "Основная цель пользователя" как ОсновнаяЦель
    usecase "Требуемое общее поведение" как ОбщееПоведение
    usecase "Опциональное поведение" как ОпциональноеПоведение
}

Пользователь --> ОсновнаяЦель

ОсновнаяЦель ..> ОбщееПоведение : <<include>>
ОпциональноеПоведение ..> ОсновнаяЦель : <<extend>>

note справа от ОсновнаяЦель
    Основная функция системы
end note

@enduml

Этот шаблон содержит основную нотацию:

• Актер

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

• Варианты использования

• Связь

• Включать

• Расширять

• Примечание

• Направление макета

Инструментарий: Visual Paradigm UML, ИИ и VPasCode

PlantUML идеально подходит для создания диаграмм в текстовом виде, однако инструменты визуального моделирования могут упростить процесс проверки, доработки и обмена диаграммами. Visual Paradigm предоставляет возможности моделирования UML наряду с моделированием с поддержкой ИИ и текстовым рабочим пространством VPasCode. Его платформа поддерживает стандартные диаграммы UML, включая диаграммы вариантов использования, классов, последовательностей, деятельности, компонентов, развертывания, состояний, пакетов и объектов.

Моделирование UML в Visual Paradigm

Visual Paradigm можно использовать, когда вы хотите построить диаграмму вариантов использования визуально, а не писать весь синтаксис вручную. Типичный рабочий процесс выглядит следующим образом:

1. Создайте проект UML.

2. Добавьте диаграмму вариантов использования.

3. Разместите актеров и варианты использования на холсте.

4. Нарисуйте границу системы.

5. Свяжите акторов с вариантами использования.

6. Добавить включение, расширение, а также отношения обобщения.

7. Добавьте примечания и ограничения.

8. Расположите и экспортируйте готовую диаграмму.

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

Вручную созданная диаграмма вариантов использования может содержать:

• Акторы, такие как Клиент, Администратор, и Шлюз оплаты

• Граница системы, например Система онлайн-покупок

• Варианты использования, например Оформление заказа, Разместить заказ, и Отследить заказ

• <<include>> отношения для обязательного переиспользуемого поведения

• <<extend>> отношения для опционального поведения

• Отношения обобщения для специализированных актеров или вариантов использования

Визуальная модель должна сохранять те же семантические правила, что и в PlantUML:

Checkout ..> ValidatePayment : <<include>>
ApplyDiscount ..> Checkout : <<extend>>
PremiumCustomer -|> Customer

Важное различие заключается в том, что смена инструментов не меняет смысл UML. Независимо от того, создана ли диаграмма вручную, сгенерирована искусственным интеллектом или написана на PlantUML, направление связей должно оставаться корректным.

Моделирование с помощью ИИ

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

Например, вы можете предоставить следующее требование:

Создайте диаграмму вариантов использования для системы онлайн-покупок.

Актеры:
- Клиент
- Премиум-клиент
- Администратор
- Платежный шлюз
- Служба электронной почты

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

Оформление заказа должно включать проверку клиента, расчет общей суммы, оплату
и подтверждение заказа.

Применение скидочного купона является опциональным и расширяет оформление заказа.
Премиум-клиент является специализированным типом Клиента.

Инструмент с поддержкой ИИ может использовать это описание для предложения:

• Определения актеров

• Названия вариантов использования

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

• Связи

• Включаемые варианты использования

• Расширяемые варианты использования

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

• Заметки, описывающие бизнес-правила

ИИ наиболее полезен на первом этапе моделирования. Он может быстро создать черновик на основе требований, выявить кандидатов в роли и предложить повторно используемое поведение. Полученная модель всё равно должна быть проверена разработчиком, аналитиком или экспертом предметной области.

Рекомендуемый чек-лист для проверки с помощью ИИ

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

• Каждая роль находится за пределами границ системы.

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

• Обязательное повторно используемое поведение использует<<include>>.

• Опциональное или условное поведение использует<<extend>>.

• Стрелкавключения направлена от базового сценария к включённому сценарию.

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

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

• Дублирующиеся или чрезмерно детализированные сценарии использования были удалены.

• Названия последовательно выражаются в виде глагольных фраз.

• Диаграмма чётко передаёт границы системы.

VPasCode: моделирование с помощью текста

VPasCode предоставляет рабочее пространство для преобразования текста в диаграммы в рамках экосистемы Visual Paradigm. Официальная платформа описывает его как бесплатный онлайн-редактор для преобразования текста в диаграммы, а также представляет его как способ преобразования кода в диаграммы.

Это делает VPasCode полезным для пользователей, которые предпочитают точность и повторяемость подхода «диаграмма как код», при этом работая в визуальной среде моделирования.

Диаграмму сценариев использования PlantUML можно записать следующим образом:

@startuml
заголовок Система онлайн-покупок

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

актор Покупатель как customer
актор "Премиум-покупатель" как premium
актор Администратор как admin
актор "Платёжный шлюз" как payment
актор "Служба электронной почты" как email

premium -|> customer

прямоугольник "Система онлайн-покупок" {
    сценарий "Регистрация аккаунта" как Register
    сценарий "Вход в систему" как Login
    сценарий "Просмотр товаров" как Browse
    сценарий "Оформление заказа" как Checkout
    сценарий "Размещение заказа" как PlaceOrder
    сценарий "Отслеживание заказа" как TrackOrder
    сценарий "Отмена заказа" как CancelOrder

    сценарий "Проверка данных клиента" как ValidateCustomer
    сценарий "Расчёт общей суммы заказа" как CalculateTotal
    сценарий "Оплата" как MakePayment
    сценарий "Отправка подтверждения заказа" как SendConfirmation

    сценарий "Применение купона со скидкой" как ApplyDiscount
    сценарий "Запрос возврата средств" как RequestRefund

    сценарий "Управление товарами" как ManageProducts
}

customer --> Register
customer --> Login
customer --> Browse
customer --> Checkout
customer --> TrackOrder
customer --> CancelOrder

premium --> ApplyDiscount
premium --> RequestRefund

admin --> ManageProducts
payment --> MakePayment
email --> SendConfirmation

Checkout ..> ValidateCustomer : <<включить>>
Checkout ..> CalculateTotal : <<включить>>
Checkout ..> PlaceOrder : <<включить>>

PlaceOrder ..> MakePayment : <<включить>>
PlaceOrder ..> SendConfirmation : <<включить>>

ApplyDiscount ..> Checkout : <<расширение>>
RequestRefund ..> CancelOrder : <<расширение>>

@enduml

Одну и ту же модель можно уточнить несколькими способами:

• Изменить направление макета с помощью направления слева направо.

• Добавьте примечания для объяснения бизнес-правил.

• Сгруппируйте сценарии использования в пакеты.

• Добавьте стилизацию с помощью skinparam.

• Переименуйте псевдонимы, не изменяя видимые метки.

• Храните исходный код диаграммы под контролем версий.

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

Визуальное моделирование против диаграмм как кода

Практичный комбинированный рабочий процесс

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

1. Фиксируйте требования на естественном языке.
   Опишите пользователей, цели, границы системы и бизнес-правила.

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

3. Проверьте черновик в Visual Paradigm UML.
   Проверьте, точно ли модель отражает предметную область и легко ли понять диаграмму.

4. Экспортируйте или переписайте модель в PlantUML.
   Используйте псевдонимы, согласованные имена и явный синтаксис отношений.

5. Храните исходный код в VPasCode или системе контроля версий.
   Сохраните файл.puml вместе с проектной документацией или исходным кодом.

6. Проверьте семантику UML.
   Особое внимание уделитевключениям, расширениями направлению обобщения.

7. Опубликуйте итоговую диаграмму.
   Экспортируйте её в виде изображения или документа для требований, архитектуры, обзоров проектирования и проектной документации.

Запрос для генерации диаграммы вариантов использования PlantUML

Следующий запрос можно использовать с ИИ-ассистентом для моделирования:

Сгенерируйте диаграмму вариантов использования PlantUML для системы онлайн-покупок.

Используйте макет слева направо и поместите все варианты использования системы внутрь
прямоугольника с названием «Система онлайн-покупок».

Актеры:
- Клиент
- Премиум-клиент
- Администратор
- Платёжный шлюз
- Служба электронной почты

Варианты использования клиента:
- Регистрация аккаунта
- Вход в систему
- Просмотр товаров
- Добавление товара в корзину
- Оформление заказа
- Отслеживание заказа
- Отмена заказа

Оформление заказа должно включать:
- Проверка данных клиента
- Расчёт общей суммы заказа
- Размещение заказа

Размещение заказа должно включать:
- Осуществление платежа
- Отправка подтверждения заказа

Дополнительное поведение:
- Применение купона на скидку расширяет Оформление заказа
- Запрос возврата расширяет Отмену заказа

Премиум-клиент является специализацией Клиента.

Используйте стандартный синтаксис PlantUML и включите:
- Псевдонимы актеров
- Псевдонимы вариантов использования
- Границу системы
- Связи актеров
- Отношения <<include>>
- Отношения <<extend>>
- Обобщение актеров
- Как минимум одну поясняющую заметку

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

Ключевой вывод

Visual Paradigm UML отлично подходит для интерактивного моделирования и проверки, искусственный интеллект может ускорить переход от требований к первому черновику, а VPasCode с PlantUML обеспечивает повторяемый текстовый рабочий процесс. В совокупности они поддерживают полный жизненный цикл моделирования: описание требований, генерацию черновика, проверку UML, доработку исходных данных и публикацию поддерживаемой диаграммы.

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