Диаграммы вариантов использования UML как код с помощью PlantUML и VPasCode

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

PlantUML поддерживает диаграммы вариантов использования. Редактор VPasCode от Visual Paradigm предоставляет редактор и предпросмотр PlantUML, а также функции генерации и редактирования диаграмм с поддержкой искусственного интеллекта.

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

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

• Граница системы:Прямоугольник, обозначающий моделируемую систему.

• Актер:Роль вне системы, которая с ней взаимодействует. Актерами могут быть люди, организации, устройства или внешние системы.

• Вариант использования:Возможность или цель, предоставляемая системой, обычно изображаемая в виде овала и называемая глагольной фразой, например «Оформить заказ».

• Связь:Линия, показывающая, что актер участвует в варианте использования.

• Отношения вариантов использования:Включение, расширение и обобщение.

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

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

2. Отношения вкратце

• Связь «актер — вариант использования»:Обычная линия, указывающая на взаимодействие.

• <<включить>>:Вариант использования, включающий, всегда использует включенное поведение. Пунктирная стрелка указывает от варианта использования, включающего, к варианту использования, включаемому. Например, оформление заказа всегда может включать авторизацию платежа.

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

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

Полезное различие: include означает обязательное поведение; extend означает условное добавленное поведение.

3. Основы PlantUML

Диаграмма PlantUML начинается с @startuml и заканчивается @enduml. Объявляйте акторов с помощью actor, сценарии использования с помощью usecase, а границы системы — с помощью rectangle. Псевдонимы упрощают ссылку на элементы в отношениях.

@startuml
left to right direction

actor Customer

rectangle "Online Store" {
  usecase "Browse products" as Browse
  usecase "Place order" as Place
}

Customer --> Browse
Customer --> Place
@enduml

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

4. Пример: базовый интернет-магазин

@startuml
left to right direction

actor Customer
actor Administrator as Admin

rectangle "Online Store" {
  usecase "Browse products" as Browse
  usecase "Place order" as Place
  usecase "Track shipment" as Track
  usecase "Manage catalog" as Manage
}

Customer --> Browse
Customer --> Place
Customer --> Track
Admin --> Manage
@enduml

Клиенты просматривают товары, оформляют заказы и отслеживают отгрузки. Администратор управляет каталогом. На диаграмме намеренно опущены внутренние этапы обработки заказа.

5. Пример: include и extend

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

@startuml
left to right direction

actor Customer

rectangle "Online Store" {
  usecase "Place order" as Place
  usecase "Authorize payment" as Payment
  usecase "Apply promotion" as Promotion
}

Customer --> Place

Place ..> Payment : <<include>>
Promotion ..> Place : <<extend>>
@enduml

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

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

6. Пример: обобщение акторов и внешние системы

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

@startuml
left to right direction

actor "User" as User
actor "Registered customer" as Customer
actor "Payment gateway" as Gateway

Customer --|> User

rectangle "Online Store" {
  usecase "Browse products" as Browse
  usecase "Place order" as Place
  usecase "Process payment" as Pay
}

User --> Browse
Customer --> Place
Place ..> Pay : <<include>>
Gateway --> Pay
@enduml

«Зарегистрированный клиент» является специализацией «Пользователь» и наследует общее взаимодействие с пользователем. Шлюз оплаты находится за пределами границ Интернет-магазина, но участвует в сценарии использования оплаты.

7. Пример: обобщение сценариев использования

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

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

актор Клиент

прямоугольник "Платежная система" {
  сценарий "Оплатить" как Payment
  сценарий "Оплатить картой" как Card
  сценарий "Оплатить банковским переводом" как Transfer
}

Клиент --> Card
Клиент --> Transfer

Card --|> Payment
Transfer --|> Payment
@enduml

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

8. Работа в VPasCode

Практический рабочий процесс:

1. Определите границы.Определите границы системы, роли акторов и цели, которые каждая роль стремится достичь.

2. Создайте черновик.Напишите PlantUML напрямую или попросите ИИ-ассистента создать диаграмму сценариев использования.

3. Проверьте код и просмотрите результат.Убедитесь, что акторы находятся за пределами системы, сценарии использования — внутри неё, а стрелки указывают в правильном направлении.

4. Уточните модель.Замените неясные названия, удалите детали реализации и добавляйте отношения только тогда, когда они отражают реальные требования.

5. Запросите целевые правки от ИИ.Например: «Добавьте актор внешнего шлюза оплаты и покажите необходимую платежную взаимодействие с помощью отношения «включать». Остальное оставьте без изменений.»

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

7. Сохраните исходный код. Сохраняйте .puml текст вместе с проектной документацией или в системе контроля версий. Экспортируйте изображение при необходимости для документов или презентаций.

Пример запроса для помощи ИИ

Создайте диаграмму вариантов использования UML в PlantUML для интернет-магазина. Включите границу системы, акторов «Клиент» и «Администратор», а также цели: «Просмотр товаров», «Оформление заказа», «Отслеживание отправки» и «Управление каталогом». Покажите авторизацию платежа как обязательное поведение, включаемое в «Оформление заказа». Покажите применение промоакции как условное расширение «Оформления заказа». Верните только корректный исходный код PlantUML.

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

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

• Моделирование внутренних компонентов как акторов: Акторы должны быть внешними ролями или системами, взаимодействующими с рассматриваемым объектом.

• Названия вариантов использования как задачи реализации: Предпочитайте «Отслеживание отправки» вместо «Вызов API отслеживания».

• Использование <<include>> для условного поведения: Включение (include) представляет поведение, которое требуется базовому варианту использования.

• Перепутанные стрелки связей: Включение указывает на включаемый вариант использования; расширение указывает на базовый вариант использования.

• Перегрузка одной диаграммы деталями: Используйте диаграмму высокого уровня для определения границ, а затем отдельные диаграммы или текст для детальных сценариев.

• Предположение, что успешная рендеризация означает корректность модели: PlantUML может отрендерить диаграмму, которая всё равно неверно отражает требования.

10. Контрольный список для проверки

Перед публикацией диаграммы убедитесь в следующем:

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

• Каждый актор является внешним и представляет роль.

• Названия вариантов использования описывают значимые цели.

• Связи акторов отражают реальные взаимодействия.

• Связи включения обязательны; связи расширения условны или иначе обоснованы.

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

• Диаграмма остаётся читаемой в предполагаемом размере.

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

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