Use Case диаграмма: элементы, правила построения и пример UML
Use Case диаграмма — это способ показать на одной картинке, кто и зачем использует систему. Актёры стоят снаружи, варианты использования — внутри границы системы, а линии между ними показывают, кто инициирует какое поведение. Диаграмма не рассказывает, как система устроена внутри: она фиксирует рамки и ключевые результаты применения. В этой статье разбираем элементы UML use case diagram, правила построения, отношения include и extend, даём use case пример для интернет-магазина и банка, сравниваем с sequence и activity и показываем инструменты вроде PlantUML, draw.io и Mermaid.
О чём эта статья
Диаграмма вариантов использования (Use Case Diagram) — один из видов диаграмм UML, который показывает взаимодействие внешних действующих лиц с системой через её варианты использования. Это диаграмма обзора: она отвечает на вопросы «кто пользуется системой» и «какие значимые результаты она им даёт», но не описывает порядок шагов и внутреннюю логику. Порядок шагов раскрывается отдельно — в текстовой спецификации, которую часто называют сценарием использования.
| Термин | Оригинал | Определение |
|---|---|---|
| Актёр | Actor | Роль человека, внешняя система или устройство вне границы системы |
| Вариант использования | Use Case | Значимый результат, который система даёт актору |
| Границы системы | System Boundary | Прямоугольник, отделяющий систему от внешних акторов |
| Ассоциация | Association | Линия между актором и вариантом использования |
| Включение | Include | Обязательный подчинённый вариант использования |
| Расширение | Extend | Необязательное поведение при выполнении условия |
| Обобщение | Generalization | Наследование между акторами или вариантами использования |
| Субъект | Subject | Система, поведение которой описывает диаграмма |
Для кого эта статья. Она будет полезна системным и бизнес-аналитикам, архитекторам, продакт-менеджерам, разработчикам и QA-инженерам. Отдельно — студентам и готовящимся к собеседованию, которым нужно уверенно объяснить разницу между видами UML-диаграмм и построить корректную use case diagram.
Что вы узнаете:
- зачем нужна диаграмма вариантов использования и что она не показывает;
- полный набор элементов: актёр, вариант использования, границы, ассоциации;
- чем отличаются include, extend и обобщение и когда их применять;
- пять базовых правил построения корректной диаграммы;
- примеры для интернет-магазина и банка с готовой нотацией;
- чем use case отличается от sequence и activity диаграмм;
- какие инструменты использовать: PlantUML, draw.io, Mermaid и другие;
- шаблон для заполнения и разбор типичных ошибок.
Зачем нужна диаграмма вариантов использования
Диаграмма вариантов использования решает три задачи. Во-первых, она фиксирует рамки системы: всё, что внутри прямоугольника, предстоит описать и реализовать, всё, что снаружи, — это окружение и интеграции. Во-вторых, она даёт обзор функциональности на высоком уровне: одна картинка заменяет несколько страниц списка требований и позволяет заказчику быстро увидеть, что система умеет. В-третьих, она служит основой для декомпозиции: каждый вариант использования становится кандидатом в отдельную спецификацию и набор пользовательских историй.
Важно понимать, что диаграмма — не текст. Она показывает связи и охват, но не описывает шаги, предусловия и исключения. Поэтому зрелый аналитик использует диаграмму как карту, а сценарии — как путеводитель. О том, как из одной картинки вырастает полноценная спецификация, читайте в статье Use Case пример: как писать сценарии использования.
Диаграмма полезна ещё и как инструмент согласования. Спор «нужна ли системе авторизация через внешнего провайдера» решается на ней за минуту: достаточно посмотреть, есть ли соответствующий актёр и связанный с ним вариант использования. Это дешевле, чем обсуждать абзацы текста.
Элементы use case диаграммы
Актёр (Actor). Обозначается фигуркой человечка и представляет роль, а не конкретного сотрудника. Один и тот же человек может быть разными актёрами в разных сценариях: он же «покупатель», он же «модератор отзывов». Актёрами бывают и внешние системы: платёжный шлюз, антифрод-сервис, служба доставки, а также устройства и время как источник событий. Актёров всегда размещают снаружи границы системы.
Вариант использования (Use Case). Обозначается эллипсом с коротким названием, которое описывает значимый результат. Формулировать нужно глагольной фразой с точки зрения актора: «Оформить заказ», «Перевести средства», «Восстановить доступ». Не «Форма заказа», не «Модуль оплаты» и не «Нажать кнопку». Название должно читаться как цель, которую актор хочет достичь за один присест.
Границы системы (System Boundary). Прямоугольник с названием системы в верхней части. Внутри — все варианты использования, снаружи — все актёры. Эта рамка дисциплинирует: она отвечает на вопрос «что именно мы разрабатываем». Всё, что оказалось снаружи, — либо интеграция, либо ручной процесс, который система не автоматизирует.
Ассоциации. Сплошная линия между актором и вариантом использования означает участие: актор инициирует или получает результат. Если направление важно, добавить стрелку не запрещено, но в UML ассоциация по умолчанию коммуникационная и однонаправленность часто опускают.
Комментарии и примечания. Заметки-«стикеры» позволяют добавить бизнес-правило или источник требования, не перегружая название варианта использования.
Отношения: ассоциация, include, extend, обобщение
Главный источник ошибок — отношения между вариантами использования. Разберём каждое.
Include (включение). Пунктирная стрелка со стереотипом <<include>> означает, что один вариант использования обязательно вызывает другой как часть своего поведения. Классический пример: «Оформить заказ» включает «Авторизоваться» и «Оплатить заказ». Включение применяют, когда поведение повторяется в нескольких сценариях и его не нужно дублировать. Базовый сценарий без включённого работать не может.
Extend (расширение). Пунктирная стрелка со стереотипом <<extend>> означает необязательное поведение, которое выполняется только при определённом условии. Пример: «Оплатить заказ» расширяется вариантом «Применить промокод». Расширение не запускается само по себе; базовая функциональность работает и без него. Стрелку ведут от расширяющего варианта к базовому и сопровождают условием в примечании.
Generalization (обобщение). Стрелка с полым треугольником означает наследование: дочерний элемент (специализация) наследует связи родительского актёра или поведение базового варианта использования, а остриё треугольника всегда указывает на родителя. Пример: «Зарегистрированный покупатель» — специализация «Покупателя»; «Оплатить картой» — специализация «Оплатить заказ». Стрелку ведут от наследника к родителю.
| Отношение | Нотация | Обязательность | Когда применять |
|---|---|---|---|
| Ассоциация | Сплошная линия | Всегда | Связь актора с вариантом использования |
| Include | Стрелка <<include>> от базового к включаемому |
Обязательное | Повторяющееся поведение в нескольких сценариях |
| Extend | Стрелка <<extend>> от расширения |
Необязательное | Поведение по условию, не ломающее основной поток |
| Generalization | Стрелка с полым треугольником к родителю | Наследование | Общие черты актёров или вариантов использования |
Правила построения
- Сначала актёры, потом варианты использования. Найдите роли и внешние системы, затем для каждой роли — её цели. Актёр без варианта использования и вариант без актёра — сигнал ошибки.
- Одна диаграмма — одна граница системы. Не смешивайте на одном листе несколько систем: непонятно, что именно проектируется. Для обзорной диаграммы это правило особенно важно.
- Названия — цели актора, а не операции CRUD. «Управлять товарами» на верхнем уровне лучше, чем четыре овала «создать/прочитать/обновить/удалить».
- Не превращайте диаграмму в блок-схему. Если появились ромбы условий, стрелки «далее» и порядок шагов, вы строите activity diagram, а не use case.
- Не детализируйте интерфейс. Никаких экранов, кнопок и полей ввода. Диаграмма отвечает на вопрос «что», а не «как».
- Сохраняйте читаемость. Размещайте главного актора слева, второстепенных — справа, связанные варианты использования — рядом. Добивайтесь, чтобы диаграмма помещалась на один экран.
- Держите уровень абстракции единым. Не смешивайте крупные цели и мелкие операции на одном листе.
Пример: интернет-магазин
Ниже — вариант диаграммы для интернет-магазина. Главный актор — покупатель, второстепенные — администратор и платёжная система. Внутри границы живут варианты использования, между некоторыми из них — включения и расширение.
Что здесь важно: покупатель связан с двумя независимыми целями — посмотреть каталог и оформить заказ. Оформление заказа включает авторизацию и оплату, а оплата расширяется промокодом, который не обязателен. Платёжная система — актёр, а не внутренний модуль, потому что магазин её не разрабатывает. Текстовая спецификация для этого сценария с шагами и расширениями приведена в статье User Story vs Use Case.
Пример: банк
Второй пример — интернет-банк. Здесь появляется внешняя антифрод-система и важное включение «Проверить операцию». Клиент инициирует перевод, а система обязана проверить операцию и сформировать квитанцию — это части основного поведения, а не отдельные цели.
@startuml
left to right direction
actor Клиент as client
actor "Антифрод-система" as fraud
rectangle "Интернет-банк" {
usecase "Перевести средства" as UC1
usecase "Аутентифицироваться" as UC2
usecase "Проверить операцию" as UC3
usecase "Сформировать квитанцию" as UC4
}
client --> UC1
UC1 ..> UC2 : <<include>>
UC1 ..> UC3 : <<include>>
UC1 ..> UC4 : <<include>>
UC3 --> fraud
@endumlНаправленные ассоциации (client --> UC1, UC3 --> fraud) в примере показаны для наглядности: в UML ассоциация по умолчанию коммуникационная, направление у неё необязательно — можно ограничиться простыми сплошными линиями.
На этой диаграмме видно, что цель клиента одна — перевести средства, а внутренние обязательные шаги вынесены во включаемые варианты использования. Такой приём позволяет переиспользовать «Аутентифицироваться» в других сценариях, например в «Оплатить услугу».
Чем отличается от sequence и activity
Диаграмму вариантов использования часто путают с другими диаграммами UML, потому что все они описывают поведение. Разница — в фокусе.
| Критерий | Use Case | Sequence | Activity |
|---|---|---|---|
| Отвечает на вопрос | Кто и зачем использует систему | Как объекты обмениваются сообщениями | Какой порядок действий и решений |
| Фокус | Цели акторов и рамки | Взаимодействие во времени | Поток управления с условиями |
| Элементы | Актёры, эллипсы, границы | Линии жизни, сообщения | Действия, ромбы, потоки |
| Уровень | Обзор функциональности | Детализация сценария | Логика процесса или алгоритма |
| Когда применять | Рамки и состав функций | Проектирование взаимодействия | Описание бизнес-процесса или алгоритма |
Практическое правило: use case показывает, что система делает для актора; sequence — как объекты системы общаются между собой, реализуя это поведение; activity — в каком порядке выполняются шаги и где возникают развилки. Эти три вида дополняют друг друга, а не заменяют.
Инструменты: PlantUML, draw.io, Mermaid
PlantUML — текстовый инструмент, который компилирует описание в картинку. Идеален для хранения диаграмм в репозитории и ревью через diff. Поддерживает актёров, варианты использования, include, extend и стереотипы.
draw.io (diagrams.net) — бесплатный графический редактор с готовой палитрой UML. Удобен для быстрых набросков и презентаций, поддерживает экспорт в SVG и PNG, хранит файлы локально или в облаке.
Mermaid — формат диаграмм как код, встроенный в GitHub, GitLab и многие wiki. Нативной нотации use case у него нет, поэтому диаграмму собирают через flowchart с эллипсами и пунктирными стрелками, как в примере выше. Для «диаграмм как код» это самый доступный вариант.
StarUML, Visual Paradigm, Enterprise Architect — тяжёлые CASE-средства для крупных проектов. Они поддерживают полный UML 2.5, генерацию документов и трассируемость, но избыточны для небольших задач.
| Инструмент | Формат | Плюсы | Ограничения |
|---|---|---|---|
| PlantUML | Код | Версионирование, diff, полный UML | Нужна сборка или сервер |
| draw.io | Графика | Быстро, бесплатно, экспорт | Ручная синхронизация с текстом |
| Mermaid | Код | Встроен в wiki и репозитории | Нет нативной нотации use case |
| Visual Paradigm | Графика + код | Полный UML 2.5, трассируемость | Платная лицензия, вес |
Шаблон
Чтобы не забыть элементы, заполняйте диаграмму по чеклисту. Ниже — таблица для самопроверки.
| Поле | Что указать | Пример |
|---|---|---|
| Система | Название в границе | Интернет-магазин |
| Primary Actor | Главный актор слева | Покупатель |
| Secondary Actors | Внешние системы и роли | Платёжная система, Администратор |
| Use Cases | Цели акторов глагольной фразой | Оформить заказ, Оплатить заказ |
| Include | Обязательные подчинённые | Авторизоваться |
| Extend | Необязательные ветки | Применить промокод |
| Generalization | Наследование | Зарегистрированный покупатель |
| Условия | Примечания к extend | Сумма заказа больше нуля |
| Вне границ | Что не автоматизируем | Доставка курьером |
Алгоритм работы: выпишите актёров, для каждого соберите цели уровня Primary Task, поместите цели внутрь границы, свяжите ассоциациями, вынесите повторяющееся поведение в include, условное — в extend, проверьте единый уровень абстракции и читаемость. После этого переходите к текстовым спецификациям — например, по гайду Собеседование системного аналитика, где разбираются вопросы по требованиям.
Частые ошибки
| Ошибка | Причина | Решение |
|---|---|---|
| Вариант использования назван существительным | Автор думает о модуле, а не о цели | Называйте глагольной фразой: «Оформить заказ» |
| Актёр нарисован внутри границы системы | Смешение роли и внутреннего компонента | Всегда размещайте актёров снаружи прямоугольника |
| На диаграмме нет границ системы | Забыли про Subject | Добавьте прямоугольник с названием системы |
| Include и extend перепутаны | Непонимание обязательности | Include обязателен, extend — по условию |
| Стрелка extend направлена не в ту сторону | Ошибка в нотации | Ведите стрелку от расширяющего варианта к базовому |
| Диаграмма превращена в блок-схему | Хотят показать порядок шагов | Порядок описывайте в activity или sequence |
| Слишком много мелких вариантов использования | Включили CRUD-операции | Оставляйте цели уровня Primary Task |
| Группировка CRUD в один вариант | Подмена цели набором действий | Формулируйте цель, а не список операций |
| На одной диаграмме несколько систем | Нет чётких рамок | Одна диаграмма — одна граница системы |
| Нечитаемая «паутина» из стрелок | Нет компоновки | Главный актор слева, связанные варианты рядом |
| Актор без единой связи | Забыли цель или добавили лишнюю роль | Уберите актёра или найдите его вариант использования |
| Диаграмма оторвана от текста | Нет спецификаций | Для каждого варианта напишите сценарий |
| Уровни абстракции смешаны | Крупные цели рядом с операциями | Разделите обзорную и детальную диаграммы |
| Названия на русском и английском вперемешку | Нет единого глоссария | Зафиксируйте язык и термины проекта |
Ресурсы
- Стандарт OMG UML 2.5 — официальное определение актора, варианта использования и отношений include, extend, generalization.
- Алистер Коберн, «Writing Effective Use Cases» — уровни целей, шаблон спецификации и связь с диаграммой.
- Айвар Якобсон, «Object-Oriented Software Engineering: A Use Case Driven Approach» — первоисточник метода вариантов использования.
- Мартин Фаулер, «UML Distilled» — краткое и точное описание нотации UML, включая use case диаграммы.
- Крейг Ларман, «Applying UML and Patterns» — применение диаграмм в итеративном процессе.
- Документация PlantUML и Mermaid — синтаксис построения диаграмм как кода.
Что дальше
- User Story vs Use Case: в чём отличие — сравнение форматов требований и связка эпик → use case → story.
- Use Case пример: как писать сценарии использования по Коберну — шаблоны и полные спецификации.
- Архитектурные концепции, которые должен знать разработчик — базовые понятия проектирования систем.
- Справочник аналитика: требования к ПО — виды требований и техники работы с ними.
- Руководство по системному дизайну — от требований к архитектуре и интеграциям.