Как построить диаграмму вариантов использования (UML)

Диаграмма вариантов использования (Use Case Diagram) — это визуальная модель, которая показывает, кто взаимодействует с системой (акторы) и что они могут в ней делать (варианты использования). Она отвечает на вопрос «Что делает система?», игнорируя технические детали реализации. Это идеальный инструмент для согласования требований между заказчиком, аналитиком и разработчиком на старте проекта.

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

Основные элементы диаграммы

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

1. Актор (Actor)

Актор — это роль, которая взаимодействует с системой. Это не обязательно человек; актором может быть другая информационная система, таймер или внешнее устройство.

• Обозначение: Стикмен (человечек) или прямоугольник с пометкой <<actor>>.
• Примеры: Покупатель, Администратор, Платежный шлюз.

2. Вариант использования (Use Case)

Это конкретная услуга или функция, которую система предоставляет актору для достижения его цели.

• Обозначение: Овал (эллипс) с названием внутри.
• Правило именования: Используйте глагол + существительное (например, Оформить заказ, Зарегистрироваться). Избегайте технических терминов вроде Вызов API.

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

Прямоугольник, который ограничивает область видимости вашей системы.

• Зачем нужна: Помогает отделить функционал вашего приложения от внешних сервисов и действий пользователей, происходящих за пределами ПО.
• Расположение: Акторы находятся за пределами рамки, варианты использования — внутри.

4. Связи (Relationships)

Линии, показывающие взаимодействие между элементами.

Разбор связей: Include vs Extend

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

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

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

• Пример: Кейс Перевод денег и Снятие наличных всегда требуют Проверки баланса.
• Направление стрелки: От базового кейса к включаемому (Базовый --> <<include>> --> Включаемый).

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

Используется для описания альтернативных или опциональных сценариев. Расширяющий кейс выполняется только при выполнении определенного условия.

• Пример: Кейс Оплата заказа может быть расширен кейсом Применить промокод (если у пользователя есть код) или Обработка ошибки платежа (если карта отклонена).
• Направление стрелки: От расширяющего кейса к базовому (Расширяющий --> <<extend>> --> Базовый).

Пошаговый алгоритм составления диаграммы

1. Определите границы системы. Решите, что именно вы проектируете (например, мобильное приложение доставки, а не курьерскую службу в целом).
2. Выявите акторов. Кто будет пользоваться системой? Не путайте должности с ролями. Один человек может иметь несколько ролей (например, сотрудник может быть и Менеджером, и Пользователем портала).
3. Сформулируйте варианты использования. Для каждого актора перечислите цели, которые он хочет достичь с помощью системы.
4. Установите ассоциации. Соедините акторов с соответствующими кейсами.
5. Детализируйте связи. Найдите общие шаги для нескольких кейсов и оформите их через <<include>>. Выделите редкие или условные сценарии через <<extend>>.
6. Проверьте полноту. Убедитесь, что у каждого актора есть хотя бы один вариант использования, и нет «висящих» кейсов без назначения.

Практические примеры

Пример 1: Интернет-магазин

В этом примере мы моделируем базовый функционал e-commerce платформы.

Акторы:

• Гость (неавторизованный пользователь)
• Покупатель (авторизованный пользователь)
• Администратор

Ключевые связи:

• Гость может выполнять Просмотр каталога и Поиск товаров.
• Покупатель наследует права Гостя (Generalization) и дополнительно может Добавить товар в корзину и Оформить заказ.
• Кейс Оформить заказ включает <<include>> Авторизация (если пользователь еще не вошел) и Проверка наличия товара.
• Кейс Оформить заказ расширяется <<extend>> кейсом Применение скидки (опционально).
• Администратор управляет Товарами и Заказами.

Пример 2: Сервис онлайн-записи (Салон красоты)

Акторы:

• Клиент
• Мастер
• Система уведомлений (технический актор)

Сценарии:

1. Клиент выбирает Услугу и Мастера.
2. Кейс Записаться на прием включает <<include>> Проверку свободного времени.
3. Если время свободно, система подтверждает запись.
4. Кейс Подтверждение записи расширяется <<extend>> кейсом Отправка SMS-напоминания (выполняется за 24 часа до визита). Здесь актором выступает Система уведомлений.

Частые ошибки при моделировании

1. Функциональная декомпозиция вместо бизнес-процессов.
   • Ошибка: Создание кейсов «Нажать кнопку», «Открыть форму», «Сохранить в БД».
   • Как надо: Объедините эти шаги в один бизнес-результат: «Сохранить профиль».
2. Игнорирование границ системы.
   • Без четкой границы непонятно, где заканчивается ответственность вашего ПО и начинаются действия пользователя или внешних сервисов.
3. Слишком много деталей.
   • Если на диаграмме более 10–15 вариантов использования, она становится нечитаемой. Разбейте систему на подсистемы (модули) и постройте отдельные диаграммы для каждого модуля.
4. Путаница в направлениях стрелок.
   • Помните: include идет от общего к частному, extend — от частного к общему.

FAQ

Нужна ли диаграмма вариантов использования для маленьких проектов? Да, даже для MVP она помогает отсеять лишние функции и четко определить, что именно нужно сделать в первую очередь. Это экономит время на разработке ненужного функционала.

Чем Use Case отличается от User Story? User Story («Как пользователь, я хочу...») — это текстовое описание требования для бэклога. Use Case Diagram — это визуальная структура, показывающая связи между всеми требованиями системы. Они дополняют друг друга: диаграмма дает общую картину, истории — детали реализации.

Какие инструменты использовать для построения? Подойдут любые редакторы с поддержкой UML: PlantUML (для генерации из кода), Draw.io, Lucidchart, Miro или специализированные IDE вроде Enterprise Architect. Главное — соблюдать стандарт нотации.

Можно ли использовать диаграмму для тестирования? Да. Каждый вариант использования легко трансформируется в тест-кейс. Связи extend подсказывают, какие граничные случаи нужно проверить в первую очередь.