Диаграмма прецедентов (Use Case Diagram) фиксирует внешнее функциональное поведение системы: кто с ней взаимодействует и какие цели достигает с её помощью. В терминах UML use case, вариант использования и прецедент — синонимы; в русскоязычной практике чаще говорят «прецедент». Диаграмма отвечает на вопрос что система делает для окружения, но не как реализовано внутри — для потока шагов и обмена сообщениями служат 03.02.02 Диаграмма деятельности (Activity Diagram) и 03.02.03 Диаграмма последовательности (Sequence Diagram). Обычно её строят после согласования контекста (03.01.02 Моделирование контекста системы (Context Diagram)): контекст фиксирует акторов и потоки данных, UC-диаграмма раскладывает тех же акторов в набор функций системы.

Три вопроса, на которые закрывает диаграмма:

  • Кто взаимодействует с системой? (акторы)
  • Какие функции система предоставляет вовне? (прецеденты)
  • Как связаны эти функции между собой и с акторами? (структура связей, не реализация)

1. Суть темы

Главная цель — выявить и согласовать набор функциональных возможностей, которые система должна предоставить окружению, и связать их с ролями пользователей и внешними системами. Диаграмма задаёт каркас функциональности; детальные сценарии (main/alternate/exception) живут в текстовой спецификации (02.03.03 Спецификация требований (SRS, Use Case, User Story), 10.01.02 Шаблон Use Case). Выбор формата UC vs User Story — в 04.03 Use Case vs User Story — выбор подхода.

Прецедент в SRS по ISO/IEC/IEEE 29148 — это контейнер для одного или нескольких функциональных требований (FR): эллипс задаёт границу сценария, а FR формулируются в спецификации. Стандарт в первую очередь описывает stakeholder requirements и структуру спецификаций; жёсткая схема «один эллипс = один UC-ID = пачка FR» на практике часто дробится backlog'ом и итерациями. Связь UC→FR ведут в матрице трассировки, а не на диаграмме (02.03.04 Трассировка требований (концепция), 10.01.15 Шаблон матрицы трассировки). Классификация БТ/ФТ/НФТ — в 02.03.01 Классификация требований (БТ, ФТ, НФТ); нефункциональные требования на UC-диаграмме не моделируются — их фиксируют отдельно (08.02 Нефункциональные требования (НФТ) — классификация и стандарты).

Когда применять:

Когда UC-диаграмма не нужна (или достаточна упрощённая карта):

Критерий: диаграмма оправдана, когда нужен общий язык о границах и функциях системы; для end-to-end потока — процессная модель, для API-only сервиса — контракт.

2. Ключевые понятия

Полная нотация UML 2.5.1 для поведенческих диаграмм — в 06.01.02 Поведенческие диаграммы (State, Activity, Use Case). Ниже — прикладной минимум для системного аналитика; формальная семантика include, extend и generalization — по OMG UML 2.5.1, подробнее в 06.01.02 Поведенческие диаграммы (State, Activity, Use Case).

Элементы диаграммы

ЭлементНазначение для SA
Актор (Actor)Роль внешней сущности при взаимодействии с системой: человек, подразделение, внешняя ИС, устройство, таймер
Прецедент (Use Case)Функция, которую система выполняет для актора и которая даёт наблюдаемый результат, значимый для достижения цели
Граница системы (System Boundary)Прямоугольник subject: всё внутри — ответственность проектируемой системы; акторы — снаружи
АссоциацияУчастие актора в прецеденте; направление стрелки (если есть) показывает, кто инициирует взаимодействие
IncludeОбязательное включение поведения: стрелка от базового прецедента к включаемому, стереотип <<include>>
ExtendУсловное расширение: стрелка от расширяющего к базовому, стереотип <<extend>>
GeneralizationНаследование ролей или вариантов реализации: стрелка с треугольником от потомка к предку

Акторы: виды и идентификация

  • Основной (primary) — инициирует прецедент ради своей цели (Покупатель → «Оформить заказ»).
  • Второстепенный (secondary) — участвует в прецеденте, но не инициирует его самостоятельно (платёжный шлюз внутри «Провести платёж»). Участие фиксируют в спецификации сценария; отдельная ассоциация с include-прецедентом на диаграмме обычно не нужна. Связь с интеграционными требованиями — 03.01.04 Интерфейсы и интеграционные взаимодействия.
  • Системный — внешняя ИС, обмен через API; на диаграмме — фигурка или прямоугольник с ключевым словом actor.
  • Время (Time) — инициирует прецеденты по расписанию («Ежедневная выгрузка отчёта»).
  • Гость (Guest) — неаутентифицированный пользователь с ограниченным набором прецедентов (просмотр каталога без входа).

Акторов выявляют через карту стейкхолдеров (02.01.03 Анализ заинтересованных сторон (Stakeholder Map)), интервью (02.02.01 Интервьюирование и анкетирование) и контекстную диаграмму (03.01.02 Моделирование контекста системы (Context Diagram)). На контексте нет прецедентов — только акторы и потоки; UC-диаграмма использует тот же список акторов и добавляет функции. Один человек может соответствовать нескольким акторам в разных ролях.

Актор на диаграмме ≠ роль в RBAC. UC фиксирует функции взаимодействия с системой; кто имеет право вызывать функцию — отдельный артефакт (10.01.11 Шаблон ролевой модели). «Администратор» и «Менеджер склада» на диаграмме — роли участников сценариев, а не матрица разрешений.

Ассоциация на ревью: если актор инициирует прецедент — направляйте стрелку от актора к прецеденту. Для второстепенного актора, которому система «отдаёт» запрос в рамках include, — достаточно описания в спецификации; если внешняя система сама инициирует отдельный прецедент (webhook, push статуса) — ассоциация уместна.

Прецеденты: именование и уровни детализации

Имя — «Глагол + объект»: «Оформить заказ», не «Оформление заказа». Имя отражает цель актора, а не шаг реализации («Сохранить в БД» — внутри сценария, не на диаграмме).

«Войти в систему» как самостоятельный прецедент сомнителен: чаще это предусловие других прецедентов. Исключение — когда вход сам по себе бизнес-цель (доступ в закрытый раздел). На диаграмме ниже аутентификация показана через обобщение, а не отдельный эллипс «Войти».

Уровни по Коберну (Cockburn):

УровеньМетафораЧто на диаграммеКуда детализировать
CloudОблакоЦель верхнего уровня («Управлять заказами»)Product map, эпики
KiteВоздушный змейОдин эллипс = один прецедент релиза/MVPUC-диаграмма, краткая спецификация
SeaМореНе отдельные эллипсыШаги main/alternate/exception в 10.01.02 Шаблон Use Case

Один эллипс на диаграмме = прецедент уровня Kite: достаточно крупный для согласования с заказчиком, достаточно конкретный для оценки итерации.

Абстрактный прецедент ({abstract} / пометка в инструменте): не инициируется актором напрямую; служит родителем для конкретных вариантов («Аутентифицироваться» → «…по паролю», «…по отпечатку»). На диаграмме связь — generalization, не include.

Отношения между прецедентами

Include — общая обязательная логика, без которой базовый прецедент неполон. Пример: «Оформить заказ» <<include>> «Провести платёж». Включаемый прецедент не получает отдельных ассоциаций от акторов базового сценария — инициатор остаётся у базового прецедента.

Extend — опциональное поведение при выполнении условия в точке расширения (extension point) базового сценария. Пример: «Применить промокод» <<extend>> «Оформить заказ» при условии «пользователь ввёл код». Extend не инициируется актором напрямую.

Точки расширения фиксируют в спецификации прецедента (имя точки + условие), не обязательно подписывают на диаграмме — см. 10.01.02 Шаблон Use Case.

Extend vs альтернативы и исключения. Формальная семантика UML: extend вставляет фрагмент в базовый поток в заданной точке; исключение (exception flow по Коберну) прерывает основной сценарий и описывается в тексте, а не связью <<extend>>. На практике extend используют для опциональных веток (промокод, страховка), а альтернативы и ошибки — в сценарии. Для SA это аргумент не перегружать диаграмму, а выносить сложные ветки в спецификацию.

Generalization — иерархия ролей («Старший менеджер» → «Менеджер») или вариантов одной цели (способы аутентификации).

Несколько subject на одной диаграмме

Если система декомпозирована на подсистемы (03.01.03 Декомпозиция системы на подсистемы и модули), каждый subject — отдельный прямоугольник с собственными прецедентами. Не смешивайте прецеденты разных bounded context без явной подписи границ.

3. Как применяется в работе аналитика

Процесс построения

  1. Границы системы — имя subject и scope (02.01.04 Определение границ решения (Scope Modelling)).
  2. Список акторов — из контекста и стейкхолдеров; отметьте primary/secondary.
  3. Цели акторов — глагольные фразы-кандидаты в прецеденты уровня Kite.
  4. Фильтрация — уберите CRUD-мелочь и внутренние шаги; оставьте наблюдаемый результат для актора.
  5. Связи — ассоциации, затем include/extend/generalization только там, где убирают дублирование.
  6. Проверка — все акторы контекста отражены? прецеденты покрывают MVP? нет «висячих» эллипсов? Проведите walkthrough с заказчиком или стейкхолдерами (09.02 Проведение эффективных встреч и воркшопов); при формальном ревью артефакта — 08.04 Рецензирование и инспекции (техники Фейгана) или 08.03 Тестирование требований (статическое тестирование).
  7. Спецификация — краткое описание каждому прецеденту; развёрнутый сценарий для ключевых (10.01.02 Шаблон Use Case). Нумерация UC-01, UC-02 упрощает трассировку в матрице.

Инструменты: 07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io).

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

Диаграмма иллюстрирует include, extend и generalization. «Аутентифицироваться» — абстрактный родитель; «Войти в систему» намеренно не вынесен отдельным эллипсом (см. подраздел «Прецеденты: именование и уровни детализации»). «Провести платёж» включается в «Оформить заказ»; платёжный шлюз участвует внутри сценария оплаты — его нет на диаграмме как инициатора «Провести платёж». Служба доставки инициирует «Обновить статус доставки» (push webhook) — для этого прецедента ассоциация уместна.

usecaseDiagram
    actor "Покупатель" as buyer
    actor "Гость" as guest
    actor "Администратор" as admin
    actor "Менеджер склада" as wh
    actor "Служба доставки" as del

    rectangle "Интернет-магазин" {
        (Оформить заказ) as UC_Order
        (Просмотреть каталог) as UC_Catalog
        (Отследить доставку) as UC_Track
        (Вернуть товар) as UC_Return
        (Провести платёж) as UC_Pay
        (Применить промокод) as UC_Promo
        (Управлять каталогом) as UC_AdmCat
        (Управлять заказами) as UC_AdmOrd
        (Обновить статус доставки) as UC_Status
        (Аутентифицироваться) as UC_Auth
        (Аутентифицироваться по паролю) as UC_Pwd
        (Аутентифицироваться по отпечатку) as UC_Bio
    }

    guest --> UC_Catalog
    buyer --> UC_Order
    buyer --> UC_Track
    buyer --> UC_Return
    buyer --> UC_Pwd
    buyer --> UC_Bio
    admin --> UC_AdmCat
    admin --> UC_AdmOrd
    admin --> UC_Pwd
    wh --> UC_AdmOrd
    wh --> UC_Status
    del --> UC_Status

    UC_Order ..> UC_Pay : <<include>>
    UC_Promo ..> UC_Order : <<extend>>
    UC_Pwd --|> UC_Auth
    UC_Bio --|> UC_Auth

Связь с другими артефактами

Каскад и Agile

В RUP/водопаде (05.01 Waterfall и V-model) UC-диаграмма — центр функциональной спецификации с текстовыми сценариями. В Agile (05.02 Scrum и Kanban (аналитик в Agile)) тот же эллипс часто соответствует эпику или теме на product map; детализация — в backlog. Критерии выбора глубины — 04.03 Use Case vs User Story — выбор подхода.

Черновик с помощью LLM

LLM может ускорить первичный черновик диаграммы из текста требований, но связи include/extend, границы subject и второстепенные акторы требуют обязательной верификации аналитиком. Промпты, ограничения и кейсы — в 11.01 Введение в искусственный интеллект и LLM, 11.03 Промпт-инжиниринг для аналитика, 11.07 Практические кейсы применения LLM в анализе.

4. Типовые ошибки и ограничения

Типичные ошибки:

  • CRUD вместо целей: «Создать заказ», «Изменить заказ»… — лучше «Управлять заказами» с деталями в сценарии.
  • Внутренние модули на UC-диаграмме — для этого sequence/component, не прецеденты.
  • Пропуск второстепенных акторов (платёж, доставка) — выпадают интеграционные требования; но и лишние ассоциации акторов с каждым include-прецедентом создают ложное впечатление, что внешняя система инициирует подфункцию.
  • Неверное направление extend (от базового к расширению) или include как сплошная ассоциация между эллипсами.
  • НФТ, UI-макеты и API-контракты на одной диаграмме с функциями — разные артефакты.
  • Подмена процессной модели: несколько ролей в одном потоке с таймерами и эскалациями — задача BPMN/DFD, не UC.

Ограничения подхода (см. также Kevlin Henney):

  • семантика <<extend>> и generalization прецедентов часто понимается по-разному в команде;
  • перегруженная диаграмма хуже простого списка ассоциаций актор–прецедент;
  • диаграмма не заменяет сценарии, критерии приёмки и тесты.

Практика SA: держите диаграмму на уровне Kite; include — для повторяющейся обязательной логики; extend — для 2–3 явных опциональных веток; остальное — в текст. Если диаграмма перестаёт быть понятной заказчику — упростите или замените таблицей акторов и прецедентов с приоритетом (02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано)).

Связи с другими разделами базы

Источники и дополнительные материалы

Нормативные документы

Классические книги

  • Алистер Коберн. Writing Effective Use Cases. — Addison-Wesley, 2000. (Рус.: «Современные методы описания функциональных требований к системам». — Лори, 2002.)
  • Крэг Ларман. Applying UML and Patterns. 3rd ed. — Addison-Wesley, 2005. (Рус.: «Применение UML 2.0 и шаблонов проектирования». — Вильямс, 2013.)
  • Гради Буч, Джеймс Рамбо, Айвар Якобсон. The Unified Modeling Language User Guide. 2nd ed. — Addison-Wesley, 2005.

Своды знаний

  • IIBA. BABOK Guide v3 — разделы 7.4 «Specify and Model Requirements», 10.47 «Use Cases and Scenarios».
  • SEBoK v2.9 — System Definition, Functional Architecture.

Статьи и веб-ресурсы