Диаграмма вариантов использования показывает, какие задачи внешние участники решают с помощью системы. Она помогает согласовать границы продукта и требования до обсуждения экранов, базы данных и программного кода.
Ниже — шесть шагов построения диаграммы и два примера: учебная информационная система и запись к врачу. Для начала достаточно назвать систему, её участников и цели, с которыми они к ней обращаются.
Что показывает диаграмма вариантов использования
В UML участника называют актором. Это роль человека или внешней системы, взаимодействующей с рассматриваемой системой: например, пациент, регистратор или платёжный сервис. Один человек может выступать в нескольких ролях.
Вариант использования описывает цель актора, например «Записаться на приём» или «Посмотреть оценки». Он не равен отдельной кнопке интерфейса. Диаграмма показывает состав целей и связи, а подробный сценарий — условия, действия, результат и исключения — удобно хранить рядом в тексте.
| Элемент | Обозначение | Пример |
|---|---|---|
| Актор | Фигура человека или именованный внешний участник | Пациент, регистратор |
| Вариант использования | Овал с названием цели | Записаться на приём |
| Граница системы | Прямоугольник с названием системы | Сервис записи в клинику |
| Связь участия | Линия между актором и вариантом использования | Пациент — Отменить запись |
Шаг 1. Определите систему и цель диаграммы
Откройте новую доску Boardmix или шаблон диаграммы вариантов использования. Назовите систему и решение, для которого нужна схема. Например: «Уточнить, какие действия доступны пациенту и регистратору в сервисе записи».
Запишите, что находится вне задачи. Если вы описываете запись на приём, расчёт зарплаты врачей не должен случайно попасть на эту же диаграмму. Для него нужна отдельная граница и собственные участники.
Шаг 2. Нарисуйте границу системы
Добавьте прямоугольник и подпишите его «Сервис записи в клинику». Внутри будут варианты использования, снаружи — акторы. Граница отделяет ответственность сервиса от действий людей и других систем.
Внешний сервис остаётся актором даже тогда, когда его API вызывается автоматически. Например, платёжная система участвует в оплате, но её внутренние операции не нужно рисовать внутри сервиса клиники.
Шаг 3. Добавьте акторов
Для каждого участника уточните роль и цель. В примере клиники пациент записывается и отменяет запись, регистратор помогает с записью, врач просматривает расписание. Должность сама по себе не делает человека актором: у него должно быть взаимодействие с системой.
Разместите акторов за границей прямоугольника. Основных пользователей удобно поставить слева, внешние сервисы — справа, но это приём компоновки, а не обязательное правило UML.
Шаг 4. Сформулируйте варианты использования
Добавьте овалы с короткими названиями действий: «Найти свободное время», «Записаться на приём», «Отменить запись», «Посмотреть расписание». Предпочитайте глагол и результат: «Открыть форму № 3» описывает экран, а не задачу пользователя.
Для сложного варианта использования добавьте рядом карточку сценария: участники, предусловия, событие запуска, основной путь, результат и исключения. Предусловие описывает то, что уже должно быть истинно до начала сценария, а не его первый шаг.
Шаг 5. Соедините участников и разберите отношения
Проведите линии между акторами и целями, в которых они участвуют. Не превращайте эти линии в блок-схему: диаграмма вариантов использования не показывает порядок выполнения всех операций.
Для общих и дополнительных действий в UML есть специальные отношения. Добавляйте их только тогда, когда они поясняют требования, а не ради усложнения схемы.
| Отношение | Когда применять | Направление |
|---|---|---|
| «include» | Один сценарий включает повторно используемое поведение другого | Пунктирная стрелка от включающего варианта к включаемому |
| «extend» | Дополнительное поведение возникает при определённом условии | Пунктирная стрелка от расширяющего варианта к базовому |
| Обобщение | Одна роль или вариант специализирует другой | Линия с пустым треугольником в сторону общего элемента |
Например, если идентификация пациента всегда является частью записи, её можно выделить во включаемый сценарий. Не переносите авторизацию в «include» автоматически: она также может быть предусловием. Выбор зависит от того, как устроен именно ваш процесс.
Для проверки значения обозначений используйте спецификацию UML от OMG (на английском). Не путайте «extend» с обычным следующим шагом процесса.
Шаг 6. Согласуйте схему и поделитесь результатом
Пройдите по целям вместе с представителями пользователей и разработчиками. У каждого овала должна быть понятная цель, участник и граница ответственности. Если объяснение требует длинной цепочки решений, вынесите её на отдельную блок-схему или диаграмму активности.
В Boardmix можно дать коллегам ссылку на общую доску для обсуждения. Выберите права просмотра или редактирования под задачу. Для документа требований подготовьте экспорт в доступном формате, например PNG или PDF, и укажите версию схемы.
Пример: учебная информационная система
Акторы — студент, преподаватель и сотрудник учебной части. Студент просматривает расписание и оценки; преподаватель выставляет оценки; сотрудник учебной части ведёт сведения об обучении. Эти роли позволяют обсудить права доступа до реализации интерфейса.
Если «Изменить оценку» требует отдельного разрешения, не скрывайте это за общей функцией «Управлять студентом». Выделите цель и уточните условия в карточке сценария. Такая детализация помогает обнаружить требования к согласованию и журналу изменений.
Например, в карточке «Изменить оценку» можно указать исходное условие — у преподавателя есть разрешение, успешный результат — новое значение сохранено, исключение — оценка уже заблокирована для изменений. Решение о том, кто вправе снять блокировку, относится к требованиям, а не выводится автоматически из линии на диаграмме.
Пример: запись на приём в клинику
Пациент выбирает врача и время, подтверждает или отменяет запись. Регистратор выполняет запись от имени пациента, врач просматривает расписание. Уведомление о записи можно показать отдельным сценарием, если оно важно для границ системы и требований.
Разберите исключение: свободное время исчезло до подтверждения. Диаграмма оставляет цель «Записаться на приём» на месте, а текстовый сценарий объясняет, что система предлагает выбрать другое время. Не нужно рисовать каждый экран как отдельный вариант использования.
Для этого примера можно заполнить карточку «Записаться на приём» так:
| Поле | Содержание сценария |
|---|---|
| Основной актор | Пациент; регистратор может действовать от его имени в пределах своих полномочий. |
| Предусловие | Пациент идентифицирован. Сервис имеет доступ к актуальному расписанию. |
| Событие запуска | Пациент начинает запись на приём. |
| Основной путь | Пациент выбирает врача и время. Сервис повторно проверяет доступность при подтверждении, создаёт запись и показывает её данные. |
| Успешный результат | Создана одна запись на выбранное время; пациент может её просмотреть. |
| Исключение | При подтверждении время уже занято. Запись не создаётся; пациент получает актуальные варианты и выбирает другое время. |
Это учебный сценарий, а не описание конкретной клиники. Два пациента могут выбрать одно время до подтверждения, поэтому повторная проверка относится к требованиям системы. На диаграмме оба по-прежнему участвуют в одном варианте «Записаться на приём»: отдельный овал для каждого сообщения об ошибке не нужен.
С чего начать свою диаграмму
Выберите один пользовательский процесс, перечислите внешние роли и запишите их цели. Затем нанесите границу системы и связи. Хорошая первая версия помогает участникам договориться о требованиях; она не обязана включать все возможности будущего продукта.
