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

Что такое диаграмма вариантов использования: определение и место в UML

UML (Unified Modeling Language — унифицированный язык моделирования) разработан Object Management Group совместно с «Тремя амиго»: Гради Бучем, Иваром Якобсоном и Джеймсом Рамбо. Актуальная версия стандарта — UML 2.5.1.

Семейство UML включает 14 типов диаграмм: 7 структурных и 7 поведенческих. Диаграмма вариантов использования входит в поведенческую группу — фиксирует, как система взаимодействует с внешней средой. Она работает на высоком уровне абстракции: не описывает алгоритмы, как блок-схема, и не показывает структуру объектов, как диаграмма классов. Задача — зафиксировать функциональные требования через взаимодействие пользователей с системой.

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

Диаграмма прецедентов решает три задачи при анализе систем.

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

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

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

Кто создаёт: системный аналитик на стадии сбора требований и проектирования. При его отсутствии — менеджер проекта или тимлид. Кто использует результат: разработчик получает функциональные требования, тестировщик использует каждый прецедент как тест-кейс, UX-дизайнер — при проектировании интерфейса. Результат диаграммы вариантов использования — пользовательские истории для гибких методологий (Agile) разработки, тест-кейсы, технические спецификации.

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

Диаграмма вариантов использования строится из четырёх обязательных элементов: актор, вариант использования (прецедент), граница системы и связи между ними. Уберите хотя бы один — диаграмма перестаёт работать как инструмент анализа требований.

Системный аналитик работает с UML-диаграммами на каждом проекте. Если хотите освоить проектирование информационных систем и нотацию UML с нуля — в рамках федерального проекта «Активные меры содействия занятости» открыта программа «Системный аналитик: с нуля до проектирования систем»: онлайн-формат, бесплатно за счёт государства.

Актор (Actor)

Актор — внешняя сущность, взаимодействующая с системой: человек, устройство или другая программная система. Обозначается символом «человечек». Располагается ТОЛЬКО вне границы системы.

Правило именования: единственное число, название роли — не конкретного человека. «Пользователь», «Администратор», «Платёжная система» — правильно. «Иван Петров» — нет.

Два вида: первичный актор инициирует взаимодействие, вторичный поддерживает сценарий (например, платёжный шлюз принимает запросы от системы).

Вариант использования (прецедент)

Вариант использования — набор действий, приводящий к ценному результату для актора. Символ — эллипс с текстом внутри. Размещается ВНУТРИ границы системы.

Правило именования: «глагол + существительное» — «Заказать такси», «Выставить оценку», «Положить товар в корзину». Размытые формулировки «Обработка» или «Данные» — типичная ошибка.

Уровень детализации выбирается под задачу: обзорный уровень (Summary) — одна фраза; уровень цели пользователя (User goal) — с предусловиями и сценариями. Большинство диаграмм работают на уровне цели.

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

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

Жёсткое правило: акторы — ВСЕГДА вне прямоугольника; прецеденты — ВСЕГДА внутри. Прямоугольник фиксирует, что входит в разрабатываемую систему. Типичная ошибка — разместить актора внутри или вынести вариант использования за пределы границы.

Отношение ассоциации

Ассоциация — базовая связь между актором и прецедентом. Нотация: сплошная линия без стрелки. Означает, что актор участвует в данном варианте использования.

Ограничение: ассоциация существует только между актором и UC. Два прецедента между собой ассоциацией не соединяются — для этого предусмотрены специализированные отношения.

Типы связей: <>, <> и обобщение

Между вариантами использования применяются три специализированных типа связей. Ассоциация работает только с акторами. Для <> и <> общая нотация: пунктирная линия со стрелкой и стереотипом в угловых скобках.

*Таблица 1. Сравнение отношений <> и <> в нотации UML.*

Отношение включения <>

Базовый вариант использования ВСЕГДА вызывает включаемый — безусловно, при каждом выполнении. Аналог обязательного вызова функции в программировании.

Направление стрелки: от базового UC к включаемому UC.

Пример: «Перевести средства» <> «Аутентифицировать пользователя». Перевод без авторизации невозможен ни при каких условиях — включение обязательное.

Типичная ошибка: применять <> там, где поведение опционально. Если действие нужно не всегда — это кандидат на <>.

Отношение расширения <>

Расширяющий вариант использования УСЛОВНО добавляет поведение к базовому — только при определённом условии, называемом точкой расширения (Extension Point).

Направление стрелки: от расширяющего UC к базовому. ⚠️ Стрелка направлена «против интуиции»: от дополнения к основному — исключение из общего правила UML.

Пример: «Применить купон» <> «Оформить заказ». Купон вводят не при каждой покупке.

Аналогия: опциональная картошка фри к бургеру. Бургер оформляется самостоятельно, картошка — по желанию.

Отношение обобщения

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

Применяется к двум типам элементов:

• Акторы: «Классный руководитель» → «Преподаватель». Классный руководитель наследует все прецеденты преподавателя и добавляет собственные.
• Варианты использования: «Срочный заказ» → «Сделать заказ». Специализированный случай базового сценария.

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

Акторы: Пассажир, Водитель, Оператор, Платёжная система. Варианты использования: «Залогиниться», «Заказать такси», «Отследить маршрут», «Привязать карту», «Оценить водителя».

Связи: «Заказать такси» <> «Залогиниться» — авторизация обязательна при каждом заказе. «Применить промокод» <> «Заказать такси» — промокод используют не всегда.

Шаблон прецедента «Заказать такси»:

• Предусловие: пассажир авторизован, геолокация включена.
• Триггер: нажать «Вызвать такси».
• Основной сценарий: ввод адреса → поиск водителя → принятие заказа → такси приезжает.
• Альтернативный сценарий: машин нет в радиусе — система предлагает расширить зону поиска.
• Гарантия успеха: заказ зафиксирован, пассажир и водитель уведомлены.

Карл Вигерс в книге «Разработка требований к программному обеспечению» называет именно такой формат оптимальным для большинства проектов. Второй типичный пример — интернет-магазин: «Положить товар в корзину» <> «Авторизоваться».

Как построить диаграмму вариантов использования: 6 шагов

Системный аналитик строит диаграмму от общего к частному.

Шаг 1. Определить акторов — кто взаимодействует с системой: пользователи, администраторы, внешние сервисы. Фиксируйте роль, а не конкретного человека.

Шаг 2. Выявить цели каждого актора — чего он хочет достичь с помощью системы.

Шаг 3. Сформулировать варианты использования по правилу «глагол + существительное», без лишней детализации на этом этапе.

Шаг 4. Установить границу системы — провести прямоугольник: что внутри (разработка), что снаружи (внешняя среда).

Шаг 5. Добавить связи — ассоциации между акторами и UC, <>, <>, обобщение — только там, где они действительно нужны.

Шаг 6. Валидация — согласовать диаграмму вариантов использования с командой и заказчиком. Каждый актор должен быть связан хотя бы с одним прецедентом, каждый UC — достижим хотя бы от одного актора.

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

Три категории инструментов: визуальные редакторы — для новичков; профессиональные платформы с функцией искусственного интеллекта — для больших команд; текстовые форматы (code-as-text) — для интеграции в инженерные процессы разработки и доставки. Выбор зависит от уровня пользователя и наличия выстроенных процессов.

Draw.io — бесплатный онлайн-редактор

Draw.io (app.diagrams.net) — бесплатный визуальный редактор без регистрации.

Пошаговая инструкция для создания use case diagram:

1. Открыть app.diagrams.net.
2. Выбрать категорию «UML» в шаблонах.
3. Добавить символ «человечек» (актор) из боковой панели.
4. Добавить эллипс — вариант использования с подписью.
5. Нарисовать прямоугольник — границу системы.
6. Соединить элементы связями нужного типа.

Экспорт: PNG, SVG, PDF. Интеграции: Google Drive, GitHub, Confluence.

Visual Paradigm и PlantUML — продвинутые решения

Visual Paradigm — профессиональная платформа: диаграмму можно сгенерировать из текстового описания через ИИ-ассистент. Экспортирует в PlantUML, Mermaid, Graphviz.

PlantUML и Mermaid — форматы «код как документация»: диаграмма описывается текстовым кодом, хранится в репозитории, версионируется в Git, встраивается в процессы непрерывной интеграции и доставки (CI/CD). Подходит командам с DevOps-практиками.

Часто задаваемые вопросы

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

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

Диаграмма прецедентов и диаграмма вариантов использования — это одно и то же?

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

В чём разница между <> и <>?

<> — обязательное включение: базовый сценарий ВСЕГДА выполняет включаемый. <> — условное расширение: дополнительный сценарий срабатывает только при определённом условии. Ключевая особенность <>: стрелка идёт от расширяющего UC к базовому — исключение из общего правила направления стрелок в UML.

Кто составляет диаграмму вариантов использования в команде?

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

Как бесплатно создать диаграмму вариантов использования онлайн?

Используйте Draw.io (app.diagrams.net): откройте сайт без регистрации, выберите категорию UML, добавьте символ «человечек» (актор), эллипс (прецедент), прямоугольник границы системы, соедините связями. Поддерживает экспорт в PNG, SVG, PDF, интегрируется с Google Drive.

Чем вариант использования отличается от пользовательской истории?

Пользовательская история — одно предложение: «Как [роль], я хочу [действие], чтобы [ценность]». Вариант использования — структурированная модель: предусловие, триггер, основной и альтернативный сценарии, гарантии успеха. Один вариант использования может охватывать несколько пользовательских историй и значительно детальнее их.

Когда применяют диаграмму вариантов использования в проекте?

На стадии сбора требований и проектирования, до написания кода. В каскадных проектах (Waterfall) создают полную спецификацию — Fully Dressed-шаблон с детализацией каждого поля. В гибких методологиях (Agile) используют краткий формат (Brief) и дорабатывают итерационно.

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

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

Сколько типов диаграмм в UML и какое место занимает use case среди них?

В UML 2.5.1 (стандарт Object Management Group) — 14 типов: 7 структурных и 7 поведенческих. Диаграмма вариантов использования — одна из семи поведенческих. Строится первой при анализе системы — раньше диаграмм последовательности, активности и состояний, поскольку определяет функциональные требования к системе.