Урок 04.02: Use Case диаграммы (Диаграммы прецедентов / вариантов использования)
Цель урока
Освоить Use Case диаграммы — основной инструмент системного аналитика для описания функциональных требований на ранних этапах проекта. Детально разобрать элементы: актёры, прецеденты, границы системы и все типы связей. Научиться читать и строить диаграммы, используя нотацию UML и код PlantUML.
Ключевые понятия
- Use Case (Вариант использования / Прецедент) — описание последовательности действий, которые система выполняет в ответ на запрос актёра для достижения конкретного, измеримого результата
- Actor (Актёр) — внешняя по отношению к системе сущность (человек, система, устройство, время), взаимодействующая с системой
- System Boundary (Граница системы / Subject) — прямоугольник, обозначающий разрабатываемую систему; всё внутри — зона ответственности проекта, всё снаружи — внешняя среда
- Association (Ассоциация) — связь между актёром и прецедентом, показывает, что актёр участвует в данном варианте использования
- <> (Включение) — отношение, при котором один прецедент обязательно включает поведение другого; базовый прецедент неполон без включённого
- <> (Расширение) — отношение, при котором один прецедент опционально расширяет поведение другого в определённых точках (Extension Points)
- Extension Point (Точка расширения) — место в базовом прецеденте, в которое может быть вставлено расширяющее поведение
- Generalization (Обобщение) — отношение «является частным случаем» между актёрами или между прецедентами
1. Назначение и место Use Case диаграммы
Use Case Diagram (диаграмма прецедентов / вариантов использования) — это самая высокоуровневая диаграмма UML. Она не показывает детали реализации, алгоритмы или протоколы. Её задача — ответить на три вопроса:
- КТО находится за пределами системы и взаимодействует с ней? (Актёры)
- ЧТО система делает для каждого из них? (Прецеденты)
- ГДЕ проходит граница между системой и внешним миром? (System Boundary)
Аналогия: Use Case диаграмма — это меню ресторана с указанием, для кого какое блюдо. В меню написано «Стейк» (прецедент), и указано, что его может заказать «Посетитель» (актёр). В меню нет рецепта (детали реализации) и нет списка продуктов на кухне (внутренние компоненты). Это — сознательное упрощение, чтобы гость понимал, что ему доступно.
1.1. Когда Use Case диаграмма absolutely необходима
| Ситуация | Почему Use Case — правильный выбор |
|---|---|
| Старт проекта — согласование объёма (Scope) | Граница системы — первое, что нужно зафиксировать. Use Case показывает заказчику: «Вот что мы делаем, а вот что — нет». |
| В проекте несколько групп пользователей | Актёры на диаграмме наглядно показывают, какие роли взаимодействуют с системой |
| Заказчик — не ИТ-специалист | Use Case — самая простая для понимания диаграмма UML (овалы + человечки) |
| Нужно быстро оценить объём работ | Количество прецедентов — грубая, но быстрая оценка размера проекта |
| Составление User Story Map | Use Case служит «эпиком» (контейнером) для User Stories |
1.2. Когда Use Case НЕ нужна
| Ситуация | Лучший инструмент |
|---|---|
| Описание детального сценария (шаги + данные) | Sequence Diagram / Activity Diagram |
| Описание бизнес-правил | Decision Table / DMN |
| Проектирование модели данных | Class Diagram / ERD |
| Описание API-протокола | Sequence Diagram + OpenAPI |
| UI/UX-дизайн | Wireframes / Mockups |
2. Actors (Актёры)
Актёр — это роль, а не конкретный человек или система. Один человек может играть несколько ролей, и одна роль может быть реализована несколькими людьми.
2.1. Классификация актёров
| Тип актёра | Примеры | Обозначение |
|---|---|---|
| Primary Actor (Основной) | Инициирует взаимодействие для достижения цели | Пациент (запись к врачу), Клиент (оформление заказа) |
| Secondary / Supporting Actor (Вторичный) | Оказывает сервис системе (система запрашивает у него данные) | Платёжный шлюз, МИС, SMS-провайдер |
| Offstage Actor (Закулисный) | Заинтересован в результате, но напрямую не взаимодействует | Регулятор (налоговая), Руководство компании |
Пример: В системе «Личный кабинет пациента»:
- Пациент — Primary (сам инициирует запись)
- МИС — Secondary (система запрашивает у МИС расписание врачей)
- Росздравнадзор — Offstage (ему нужны отчёты, но он не заходит в кабинет)
2.2. Нотация актёра
UML 2.5 допускает два варианта изображения:
1) Стикмен (человечек) 2) Прямоугольник со стереотипом
┌───┐ ┌──────────────────┐
│ ╱ │ │ «actor» │
│ ○ │ │ Пациент │
│ ╱ │ └──────────────────┘
─┴─┴─┴─
Правило выбора: Стикмен — для людей (наглядно). Прямоугольник — для внешних систем и устройств (чтобы не путать с людьми). На одной диаграмме можно смешивать оба стиля.
2.3. Актёр «Время» (Timer Actor)
Специфический, но важный случай: актёр, который не является ни человеком, ни системой. Если процесс запускается по расписанию — актёром выступает «Время».
Пример:
- «Отправить напоминание о записи» — запускается каждый день в 8:00. Актёр — «Время».
- «Архивировать завершённые заказы» — каждый месяц 1-го числа. Актёр — «Время».
Важно: Наличие актёра «Время» — сигнал, что в системе есть фоновые задачи (scheduled jobs), которые нужно реализовать (cron, Quartz, Scheduled Executor).
2.4. Как выявить актёров: практические техники
| Техника | Вопросы |
|---|---|
| Организационная структура | Какие отделы/должности будут работать с системой? |
| Business Process Model | Какие роли участвуют в процессах, которые автоматизирует система? |
| Интервью с заказчиком | «Кто будет заходить в систему? Кто будет вводить данные? Кто будет принимать решения?» |
| Поиск внешних систем | С какими системами нужно обмениваться данными? (CRM, ERP, платёжные системы) |
| Метод «Естественные роли» | Какие роли существуют в предметной области независимо от системы? (Врач — он и в Африке врач, даже без нашей системы) |
2.5. Generalization (Обобщение) актёров
Актёры могут наследовать друг друга. Если актёр B является частным случаем актёра A, то B наследует все прецеденты A и добавляет свои.
Нотация: Стрелка с пустым треугольником от B к A.
┌──────────────┐
│ Сотрудник │
└──────┬───────┘
△
╱ ╲
╱ ╲
╱ ╲
┌──────┴──┐ ┌─┴────────┐
│ Врач │ │ Администратор│
└─────────┘ └──────────┘
Интерпретация:
- Врач «является» Сотрудником. Он может всё, что может Сотрудник (например, «Просмотреть расписание»), плюс свои специфические прецеденты («Назначить лечение»).
- Администратор также «является» Сотрудником, со своими прецедентами.
Когда использовать: Когда у нескольких актёров есть общие прецеденты, и вы хотите избежать дублирования линий на диаграмме.
Когда НЕ использовать: Если у актёров нет общих прецедентов — обобщение не нужно.
3. Use Cases (Прецеденты / Варианты использования)
Прецедент — это цель актёра, а не последовательность шагов. Он описывает, что система делает, а не как.
3.1. Правила именования прецедентов
Формат: Глагол в инфинитиве + дополнение (что? / кого?)
| ✅ Правильно | Описание |
|---|---|
| «Записаться к врачу» | Глагол «записаться» + объект «врач» |
| «Оплатить заказ» | Глагол «оплатить» + объект «заказ» |
| «Просмотреть историю назначений» | Глагол + объект (с уточнением) |
| ❌ Неправильно | Почему |
|---|---|
| «Запись к врачу» | Нет глагола — не ясно, это действие или статический экран |
| «Форма регистрации» | Это UI-элемент, а не цель пользователя |
| «Обработка платежа» | Пассивный залог; цель — «Оплатить заказ» |
| «Валидация email» | Техническая подфункция, а не бизнес-цель |
3.2. Уровни прецедентов (Cockburn Scale)
Алистер Коуберн в книге «Writing Effective Use Cases» предложил шкалу из трёх уровней:
| Уровень | Масштаб | Описание | Пример | Кому понятен |
|---|---|---|---|---|
| Summary (Краткий) | Стратегический | Бизнес-цель компании, занимает недели/месяцы | «Лечить пациентов», «Вести бухгалтерию» | Топ-менеджмент |
| User Goal (Пользовательский) | Сеанс работы за ПК | Конкретная цель за один присест (15–60 мин) | «Записаться к врачу», «Оформить заказ» | Заказчик, пользователь |
| Subfunction (Подфункция) | Технический шаг | Детальный шаг, часть User Goal | «Проверить доступность слота», «Ввести CVC-код» | Разработчик, тестировщик |
Золотое правило: 90% прецедентов аналитик пишет на уровне User Goal. Если прецедент занял больше страницы текста — возможно, он Summary и его стоит разбить. Если прецедент описывает один клик — это Subfunction, и он должен быть частью более крупного прецедента.
3.3. Атомарность прецедента
Прецедент должен быть атомарным с точки зрения актёра: после его завершения актёр достигает измеримого результата.
Проверка атомарности:
- Актёр может сказать: «Я достиг цели»? → Да, это User Goal.
- Нужно ли выполнить ещё что-то, чтобы получить результат? → Возможно, прецедент слишком мелкий.
- Можно ли прервать выполнение на середине без потери данных? → Если нет — прецедент проектно неполный.
4. System Boundary (Граница системы / Subject)
System Boundary — это прямоугольник с названием системы в верхней части. Внутри — прецеденты (то, что система делает сама). Снаружи — актёры и внешние системы.
┌────────────────────────────────────────────┐
│ Task Manager │
│ │
│ ┌───────────────────────┐ │
│ │ Создать задачу │ │
│ └───────────────────────┘ │
│ ┌───────────────────────┐ │
│ │ Назначить исполнителя │ │
│ └───────────────────────┘ │
└────────────────────────────────────────────┘
4.1. Зачем нужна граница
- Scope Management: Прямоугольник визуально показывает, что входит в проект, а что нет. Заказчик видит: «А, отправка SMS — это не ваша система, понятно».
- Разграничение ответственности: Всё внутри прямоугольника разрабатывает команда проекта. Всё снаружи — либо «as is» (существующие системы), либо другие проекты.
- Коммуникация: Споры «А чья это задача?» решаются одним взглядом на границу.
4.2. Ошибки при определении границы
| Ошибка | Как проявляется | Как исправить |
|---|---|---|
| Слишком широкая | Внутри границы — «Управление клиникой» (вся клиника) | Сузить до конкретной системы: «Личный кабинет пациента» |
| Слишком узкая | Внутри — только «Форма записи» (UI-компонент) | Расширить до сервиса: «Сервис записи к врачу» |
| Смешение систем | Внутри одной границы и CRM, и платёжный шлюз, и мобильное приложение | Разделить на несколько System Boundary (по одной на каждую разрабатываемую систему) |
5. Relationships (Типы связей)
5.1. Association (Ассоциация)
Нотация: Сплошная линия между актёром и прецедентом.
Пациент ─────────────── Записаться к врачу
Смысл: Актёр взаимодействует с данным прецедентом. Направление (стрелка) необязательна, но если есть — указывает, кто инициирует взаимодействие.
Тонкость: В UML 2.5 ассоциация — двунаправленная. Актёр инициирует прецедент, но система может «возвращать» результат актёру. Стрелка ставится, когда важно подчеркнуть направление потока.
5.2. <> (Включение)
Нотация: Пунктирная стрелка со стереотипом <<include>>. Направление: ОТ базового прецедента К включённому.
┌──────────────────┐ <<include>> ┌──────────────────┐
│ Оформить заказ │ ───────────────────────────│ Авторизоваться │
└──────────────────┘ └──────────────────┘
Стрелка от «Оформить заказ» к «Авторизоваться».
Правило: Если при выполнении прецедента A всегда (в 100% случаев, в каждом потоке) выполняется прецедент B — это <<include>>.
Примеры:
| Базовый прецедент | <> | Почему это include? |
|---|---|---|
| «Создать задачу» | «Авторизоваться» | Нельзя создать задачу без аутентификации. Всегда. |
| «Оплатить заказ» | «Проверить баланс» | Перед оплатой всегда проверяется баланс. |
| «Записаться к врачу» | «Выбрать специализацию» | Запись всегда начинается с выбора специализации. |
Типичная ошибка: Использовать <<include>> для опциональных шагов. Если шаг выполняется не всегда — это <<extend>>.
5.3. <> (Расширение) и Extension Points
Нотация: Пунктирная стрелка со стереотипом <<extend>>. Направление: ОТ расширяющего прецедента К базовому.
┌──────────────────┐ ┌────────────────────┐
│ Отменить запись │ ◄── <<extend>> ──────────────│ Отправить уведомление│
└──────────────────┘ └────────────────────┘
Стрелка от «Отправить уведомление» к «Отменить запись». «Отправить уведомление» расширяет «Отменить запись».
Правило: Если прецедент B выполняется только при определённом условии (не всегда), расширяя поведение прецедента A — это <<extend>>.
Extension Points (Точки расширения)
Точка расширения — место в базовом прецеденте, в которое может быть вставлено расширение. В UML она обозначается в виде секции внутри овала прецедента.
┌──────────────────────────────────┐
│ Оформить заказ │
│ extension points │
│ ep1: после подтверждения │
│ ep2: при выборе подарочной │
│ упаковки │
└──────────────────────────────────┘
▲
│ <<extend>> (при условии, что это подарок)
│
┌──────────────────────────────────┐
│ Добавить подарочную упаковку │
└──────────────────────────────────┘
Расшифровка:
- Базовый прецедент «Оформить заказ» имеет две точки расширения.
- В точке
ep1(после подтверждения) может быть вставлен прецедент «Отправить email с чеком». - В точке
ep2(при выборе подарочной упаковки) может быть вставлен прецедент «Добавить подарочную упаковку». - Расширение срабатывает только если выполняется условие (guard condition).
Пример с условием:
Условие: {пациент выбрал опцию «Уведомить по email»}
Base: Отменить запись
Extend: Отправить уведомление об отмене
Point: после подтверждения отмены
<> vs <>: исчерпывающее сравнение
| Признак | <> | <> |
|---|---|---|
| Обязательность | Всегда выполняется | Выполняется только при условии |
| Hаправление стрелки | От базового к включённому | От расширяющего к базовому |
| Самостоятельность | Включённый прецедент может существовать отдельно | Расширение не имеет смысла без базового прецедента |
| Решение | Аналитик решает, что шаг обязателен | Аналитик решает, что шаг опционален |
| Аналогия в коде | Вызов функции login() внутри createTask() |
if (user.wantsNotification) { sendNotification() } |
| Тестирование | Тест базового прецедента обязан включать шаги включённого | Тест базового прецедента может не включать расширение |
5.4. Generalization (Обобщение) прецедентов
Прецедент может быть обобщением для нескольких более конкретных прецедентов.
Нотация: Стрелка с пустым треугольником от конкретного к общему.
┌──────────────────────┐
│ Оплатить │
└──────────────────────┘
△
╱ ╲
╱ ╲
╱ ╲
┌────────┴──┐ ┌─┴────────────┐
│ Оплатить │ │ Оплатить │
│ банковской │ │ через СБП │
│ картой │ │ │
└────────────┘ └──────────────┘
Интерпретация: «Оплатить банковской картой» — это частный случай «Оплатить». «Оплатить через СБП» — другой частный случай. Оба наследуют общее поведение прецедента «Оплатить» (выбор суммы, проверка лимита), но добавляют свою специфику (реквизиты карты vs номер телефона).
Когда использовать: Когда у вас есть прецеденты с одинаковой структурой, но разными способами реализации. Обобщение позволяет не дублировать описание.
Когда НЕ использовать: Если прецеденты различаются не только деталями, но и общей логикой.
6. Полный пример: Use Case диаграмма для интернет-магазина
Постановка
Разрабатывается интернет-магазин. Выявлены следующие требования:
Актёры:
- Посетитель (неавторизованный пользователь)
- Клиент (авторизованный пользователь)
- Администратор магазина
- Платёжный шлюз (внешняя система)
- Служба доставки (внешняя система, API)
Прецеденты:
| Актёр | Прецедент | Описание |
|---|---|---|
| Посетитель | Просмотреть каталог | Просмотр товаров без регистрации |
| Посетитель | Зарегистрироваться | Создать учётную запись |
| Клиент | Авторизоваться | Войти в систему |
| Клиент | Оформить заказ | Создать заказ с товарами |
| Клиент | Оплатить заказ | Провести оплату через платёжный шлюз |
| Клиент | Просмотреть историю заказов | Список своих прошлых заказов |
| Клиент | Отменить заказ | Отменить заказ до отгрузки |
| Администратор | Управлять товарами | CRUD товаров и категорий |
| Администратор | Управлять заказами | Просмотр и изменение статусов заказов |
| Администратор | Формировать отчёты | Отчёты по продажам, остаткам |
| Система (по таймеру) | Отправить подтверждение заказа | Email после успешного оформления |
| Система (по таймеру) | Проверить статус доставки | Запрос к API службы доставки |
Связи:
<<include>>: «Оформить заказ» → «Авторизоваться» (чтобы оформить заказ, нужно войти)<<include>>: «Оплатить заказ» → «Проверить остаток на складе» (система проверяет наличие перед оплатой)<<extend>>: «Отменить заказ» ← «Отправить уведомление об отмене» (только если клиент выбрал опцию уведомления)<<extend>>: «Оформить заказ» ← «Добавить подарочную упаковку» (опционально, при условии{товар помечен как "можно упаковать"})- Generalization: «Клиент» → «Посетитель» (Клиент — частный случай Посетителя, может всё, что Посетитель, и больше)
- Generalization: «Оплатить банковской картой» → «Оплатить заказ»
PlantUML-код этой диаграммы (рабочий, компилируемый)
@startuml
' Настройка внешнего вида
skinparam backgroundColor #FEFEFE
skinparam useCase {
BackgroundColor #E8F5E9
BorderColor #2E7D32
FontColor #1B5E20
}
skinparam actor {
BackgroundColor #E3F2FD
BorderColor #1565C0
FontColor #0D47A1
}
skinparam boundary {
BorderColor #424242
FontColor #212121
}
' Объявление актёров (все перед диаграммой, чтобы управлять порядком)
actor "Посетитель" as guest
actor "Клиент" as customer
actor "Администратор" as admin
actor "Платёжный шлюз" as payment_gateway
actor "Служба доставки" as delivery
actor "Время" as time
' Граница системы
rectangle "Интернет-магазин" {
' Прецеденты для Посетителя
usecase "Просмотреть каталог" as UC1
usecase "Зарегистрироваться" as UC2
' Прецеденты для Клиента
usecase "Авторизоваться" as UC3
usecase "Оформить заказ" as UC4
usecase "Оплатить заказ" as UC5
usecase "Просмотреть историю заказов" as UC6
usecase "Отменить заказ" as UC7
' Прецеденты для Администратора
usecase "Управлять товарами" as UC8
usecase "Управлять заказами" as UC9
usecase "Формировать отчёты" as UC10
' Прецеденты по времени / системе
usecase "Отправить подтверждение\nзаказа" as UC11
usecase "Проверить статус\nдоставки" as UC12
' Sub-use cases (детали)
usecase "Проверить остаток\nна складе" as UC13
usecase "Отправить уведомление\nоб отмене" as UC14
usecase "Добавить подарочную\nупаковку" as UC15
usecase "Оплатить банковской\nкартой" as UC16
usecase "Оплатить через СБП" as UC17
}
' === СВЯЗИ: Ассоциации (Актёр → Use Case) ===
guest --> UC1
guest --> UC2
customer --> UC3
customer --> UC4
customer --> UC5
customer --> UC6
customer --> UC7
admin --> UC8
admin --> UC9
admin --> UC10
time --> UC11
time --> UC12
payment_gateway --> UC5 ' Платёжный шлюз участвует в оплате
delivery ---> UC12 ' Служба доставки участвует в проверке статуса
' === СВЯЗИ: <<include>> (Обязательное включение) ===
UC4 ..> UC3 : <<include>>
UC5 ..> UC13 : <<include>>
' === СВЯЗИ: <<extend>> (Опциональное расширение с точками) ===
UC7 <. UC14 : <<extend>>
UC4 <. UC15 : <<extend>>
' === СВЯЗИ: Generalization (Обобщение) ===
' Актёр Клиент является частным случаем Посетителя
customer --|> guest
' Прецедент Оплатить банковской картой — частный случай Оплатить заказ
UC16 --|> UC5
UC17 --|> UC5
@enduml
Комментарий к диаграмме
| Элемент | Смысл |
|---|---|
| Customer → Guest (обобщение актёров) | Клиент — это Посетитель, который авторизовался. Клиент может всё, что Посетитель (просмотр каталога), плюс свои прецеденты (оформление заказа). |
| <> UC4 → UC3 | «Оформить заказ» всегда включает «Авторизоваться». Невозможно оформить заказ без входа в систему. |
| <> UC5 → UC13 | «Оплатить заказ» всегда включает «Проверить остаток на складе». Перед оплатой система проверяет, есть ли товар в наличии. |
| <> UC7 ← UC14 | «Отправить уведомление об отмене» — опциональное расширение «Отменить заказ». Срабатывает, только если клиент выбрал опцию уведомления. |
| <> UC4 ← UC15 | «Добавить подарочную упаковку» — расширение «Оформить заказ». Доступно только для товаров, помеченных как «можно упаковать». |
| UC16, UC17 → UC5 (обобщение прецедентов) | Конкретные способы оплаты наследуют общий прецедент «Оплатить заказ». |
| Актёр «Время» → UC11, UC12 | Прецеденты запускаются по расписанию (cron), а не инициируются человеком. |
7. Use Case диаграмма в PlantUML: полный синтаксис
7.1. Справочник команд PlantUML для Use Case
| Конструкция | Синтаксис PlantUML | Результат |
|---|---|---|
| Актёр (стикмен) | actor "Имя" |
🧑 Человечек |
| Актёр (прямоугольник) | actor "Имя" as alias |
Можно ссылаться по alias |
| Прецедент | usecase "Имя" as U1 |
Овал |
| Граница системы | rectangle "Имя" { ... } |
Прямоугольник |
| Ассоциация | Actor --> U1 |
Стрелка от актёра к прецеденту |
| <> | U1 ..> U2 : <<include>> |
Пунктирная стрелка с текстом |
| <> | U2 <. U1 : <<extend>> |
Пунктирная стрелка (обратное направление!) |
| Generalization (актёры) | `Actor2 -- | > Actor1` |
| Generalization (прецеденты) | `UC2 -- | > UC1` |
| Многострочный текст | "Строка1\nСтрока2" |
Используйте \n |
7.2. Skinparam (настройка внешнего вида)
PlantUML позволяет настраивать цвета, шрифты и отступы:
@startuml
skinparam backgroundColor #FEFEFE
skinparam useCase {
BackgroundColor #E8F5E9
BorderColor #2E7D32
FontColor #1B5E20
FontSize 12
}
skinparam actor {
BackgroundColor #E3F2FD
BorderColor #1565C0
FontColor #0D47A1
}
skinparam boundary {
BorderColor #424242
FontColor #212121
BackgroundColor #FAFAFA
}
skinparam arrow {
Color #555555
FontColor #555555
}
' ... диаграмма ...
@enduml
7.3. Управление порядком (слева направо)
По умолчанию PlantUML располагает актёров слева. Чтобы управлять порядком, объявите их в нужной последовательности перед rectangle:
@startuml
' Порядок слева направо: Посетитель, Клиент, Администратор
actor "Посетитель" as guest
actor "Клиент" as customer
actor "Администратор" as admin
rectangle "Система" {
usecase "Прецедент 1" as U1
usecase "Прецедент 2" as U2
}
guest --> U1
customer --> U2
admin --> U1
admin --> U2
@enduml
7.4. Компиляция PlantUML
| Способ | Команда / Инструкция |
|---|---|
| VS Code + PlantUML плагин | Установить плагин, открыть .puml файл, Alt+D |
| PlantUML Web Server | Перейти на plantuml.com, вставить код, нажать Submit |
| Консоль (Java) | java -jar plantuml.jar diagram.puml |
| CI/CD интеграция | Плагины для Jenkins, GitLab CI, GitHub Actions |
| Confluence | Плагин «PlantUML for Confluence» |
8. Как читать и валидировать Use Case диаграмму
8.1. Чек-лист проверки диаграммы
| № | Вопрос | Если нет — проблема |
|---|---|---|
| 1 | Каждая линия ассоциации соединяет актёра с прецедентом? | «Висящие» прецеденты — кто их выполняет? |
| 2 | Все ли актёры находятся снаружи границы системы? | Внутри не может быть актёров. |
| 3 | Есть ли хотя бы один прецедент у каждого актёра? | Зачем этот актёр, если он ничего не делает? |
| 4 | Названия прецедентов — глаголы в инфинитиве? | «Запись к врачу» — неправильно. |
| 5 | Стрелки <<include>> направлены от базового к включённому? |
Если наоборот — ошибка. |
| 6 | Стрелки <<extend>> направлены от расширяющего к базовому? |
Если наоборот — ошибка. |
| 7 | Нет ли циклов в <<include>>? (A → B, B → A) |
Бесконечное включение — критическая ошибка. |
| 8 | Нет ли прецедента, который одновременно и <<include>>, и <<extend>> для одного и того же? |
Неоднозначность. |
8.2. Типичные ошибки (и как их избежать)
Ошибка 1: Прецедент как последовательность шагов
❌ «Пациент вводит логин → система проверяет → если верно → открывается кабинет» ✅ «Авторизоваться»
Use Case — это цель, а не алгоритм. Алгоритм — в текстовом сценарии или Sequence Diagram.
Ошибка 2: Перепутанные <> и <>
❌ «Cancel Order» ..> «Send Email» : <<extend>> — неверное направление и неверный тип
✅ «Send Email» ..> «Cancel Order» : <<extend>> — верно: «Send Email» расширяет «Cancel Order»
Запомните: include — стрелка ВПЕРЕД (от главного к подчинённому), extend — стрелка НАЗАД (от расширения к базовому).
Ошибка 3: Слишком много прецедентов (>30)
Если на одной диаграмме больше 30 овалов — она нечитаема. Решения:
- Разделить на подсистемы (несколько System Boundary на одной диаграмме или несколько диаграмм)
- Группировать прецеденты в пакеты (UML Package)
Ошибка 4: Premature Generalization (преждевременное обобщение)
Не вводите обобщение, если у актёров или прецедентов нет общего поведения. Обобщение ради обобщения усложняет диаграмму.
9. Use Case как контракт: от диаграммы к тестам
Use Case диаграмма — первый шаг. Второй шаг — текстовое описание каждого прецедента. Третий — тест-кейсы.
Связь Use Case → Тест-кейс
| Use Case | Сценарий (текстовый поток) | Тест-кейс |
|---|---|---|
| Оформить заказ | Main flow: Клиент выбирает товары → заполняет адрес → подтверждает → система создаёт заказ → 201 Created | TC-01: Успешное оформление |
| Alternative flow: Клиент вводит невалидный адрес → система показывает ошибку | TC-02: Адрес не найден | |
| Alternative flow: Товара нет в наличии → система уведомляет клиента | TC-03: Товар закончился | |
| Exception flow: Ошибка платёжного шлюза → система сохраняет заказ в статусе «Ожидание оплаты» | TC-04: Платёжный шлюз недоступен |
Каждый альтернативный и исключительный поток — отдельный тест-кейс.
10. Use Case и Agile: User Stories из Use Case
В Agile-командах Use Case диаграмма используется как источник для User Stories.
Матрица трансформации
| Use Case | User Story | Epic? |
|---|---|---|
| «Оформить заказ» | US-01: Как клиент, я могу добавить товар в корзину | Нет (Story) |
| «Оформить заказ» | US-02: Как клиент, я могу указать адрес доставки | Нет (Story) |
| «Оформить заказ» | US-03: Как клиент, я могу выбрать способ оплаты | Нет (Story) |
| «Оформить заказ» | EPIC-01: Оформление заказа | Да (Epic = Use Case) |
Правило: Один Use Case (User Goal) ≈ один Epic. Один Epic = 3–10 User Stories.
Практическое задание
Задание 1. Построение Use Case диаграммы
Кейс: Система для бронирования переговорных комнат в офисе.
Требования:
- Любой сотрудник может посмотреть список свободных переговорок на дату/время
- Сотрудник может забронировать переговорку на определённое время
- Сотрудник может отменить своё бронирование
- Администратор может управлять переговорками (добавить/удалить/изменить комнату)
- Администратор может отменить любое бронирование
- Система отправляет напоминание о бронировании за 15 минут до начала (background job)
- Система интегрируется с корпоративным календарём (Exchange/Google) для синхронизации бронирований
- Руководитель может просмотреть статистику использования переговорок за период
Задание:
- Определите актёров (минимум 4, включая внешние системы и «Время»)
- Определите прецеденты (минимум 7)
- Определите связи: минимум 1
<<include>>, 1<<extend>> - Определите обобщение, если уместно
Формат сдачи: PlantUML-код (компилируемый) + текстовое описание (2–3 предложения, почему выбраны такие связи).
Задание 2. Анализ Extension Point
Дан прецедент «Забронировать переговорку» с extension points:
ep1:после выбора времениep2:при выборе повторяющейся встречи
Предложите два расширяющих прецедента (по одному на каждую точку) и опишите условие, при котором каждое расширение срабатывает.
Задание 3. Исправление диаграммы
Дана диаграмма с тремя ошибками. Найдите и исправьте их.
actor "Пользователь" as user
rectangle "Система" {
usecase "Войти в систему" as UC1
usecase "Создать документ" as UC2
usecase "Отправить документ" as UC3
}
user --> UC1
user --> UC2
UC2 ..> UC3 : <<extend>> ' Ошибка?
UC3 ..> UC1 : <<include>> ' Ошибка?
' Нет актёра для UC3
Какие три ошибки? Как их исправить?
Задание 4. Валидация (письменно)
Ответьте на вопросы:
- Почему на Use Case диаграмме не должно быть стрелок между прецедентами без стереотипа (
<<include>>или<<extend>>)? - В чём разница между «актёром Время» и «прецедентом, запускаемым по таймеру»?
- Может ли один прецедент быть включён (
<<include>>) сразу в несколько базовых прецедентов? Если да — приведите пример. - Почему обобщение прецедентов используется реже, чем обобщение актёров?
Дополнительные материалы
- Стандарт: OMG UML 2.5.1 Specification, раздел 16.2 «Use Cases» (формальное определение)
- Книга: Alistair Cockburn — «Writing Effective Use Cases» (исчерпывающее руководство по текстовому описанию прецедентов)
- Книга: Kurt Bittner, Ian Spence — «Use Case Modeling» (практическое руководство с примерами)
- PlantUML: plantuml.com/use-case-diagram (официальная документация с примерами)
- Шпаргалка: PlantUML Use Case — cheatsheet с синтаксисом всех элементов
- Статья: «Use Case 2.0: The Definitive Guide» — Ivar Jacobson International (эволюция Use Case для Agile)
- Инструмент: PlantUML Web Server (plantuml.com) — онлайн-песочница для компиляции диаграмм