Диаграмма использования
Диаграмма использования собирает на одном листе ответы на три вопроса: что входит в рассматриваемую систему, кто с ней взаимодействует и какие цели эти участники достигают. Она особенно полезна в начале проектирования, когда важно проверить полноту функциональных требований и не смешать систему с окружающей средой.
Сначала определяют стейкхолдеров, пользовательские цели и границу системы. Затем отбирают цели, для которых можно назвать актора, результат и условия успеха. Диаграмма фиксирует этот результат анализа компактно; подробности остаются в спецификации и сценариях варианта использования.
Основные элементы
Заголовок раздела «Основные элементы»Актор находится вне границы системы. Это роль, а не конкретный человек: один преподаватель может быть актором «Преподаватель» в сценарии открытия интервалов и актором «Пользователь» в сценарии просмотра расписания. Внешний сервис единого входа тоже может быть актором, если система обменивается с ним данными.
Человечек — обычное, но не единственное обозначение актора. Его можно показать прямоугольником классификатора с ключевым словом «actor»; это особенно удобно на больших диаграммах или при единообразном стиле модели.
Вариант использования обозначают овалом. Его имя обычно выражает цель в форме действия с результатом: «Записаться на консультацию», «Сформировать отчёт», «Подтвердить оплату». Названия «Открыть форму» и «Выбрать дату» описывают шаги интерфейса, а не самостоятельную цель.
Граница системы показывает, какие варианты использования относятся к проектируемой ИС. Акторы располагаются снаружи, варианты использования — внутри. В UML её представляет классификатор-субъект: его можно показать прямоугольником с именем в левом верхнем углу, внутри которого расположены овалы вариантов использования.
Обычно достаточно имени субъекта, например «Сервис записи на консультации». Стереотипы «subsystem» и «service» из стандартного профиля применимы к компоненту; «system» допустим как стереотип только в профиле, где он определён.
На примере сервиса записи на консультации диаграмма может включать такие элементы:
| Элемент | Пример |
|---|---|
| Граница системы | Сервис записи на консультации |
| Акторы | Студент, Преподаватель, сервис единого входа |
| Варианты использования студента | Записаться на консультацию, отменить запись, просмотреть свои записи |
| Варианты использования преподавателя | Открыть интервал, закрыть интервал, просмотреть записи |
Такой набор уже позволяет обсудить границы: например, сервис единого входа подтверждает личность, но управление учётными записями не входит в сервис записи на консультации.
Связи между элементами
Заголовок раздела «Связи между элементами»Ассоциация соединяет актора с вариантом использования и показывает участие этой роли во взаимодействии. Она отвечает на вопрос, кто может инициировать или поддерживать достижение цели.
Обобщение используют, когда один актор или вариант использования является частным случаем другого и получает его связи. Например, «Администратор службы поддержки» может быть специализацией «Оператора». Эта связь не заменяет описание прав доступа: их фиксируют в требованиях и правилах системы.
Общий актор или вариант использования может быть абстрактным: он нужен для объединения специализаций, но не используется и не реализуется напрямую. Абстрактность полезна, только если общая роль или цель действительно упрощает модель.
Связь «include» выделяет обязательное общее поведение. Базовый вариант использования включает другой вариант каждый раз, когда выполняется. Например, «Оформить заказ» может включать «Проверить доступность товаров». Стрелка направлена к включаемому варианту использования.
Связь «extend» показывает дополнительное поведение, которое добавляется при условии. Например, «Применить промокод» может расширять «Оформить заказ», если покупатель ввёл промокод. Стрелка направлена от расширяющего варианта к базовому.
Связь «extend» может ссылаться на точку расширения базового варианта использования; если она указана, то принадлежит базовому варианту. «include» и «extend» стоит вводить только тогда, когда связь помогает понять состав поведения. Если цель одна, а различаются лишь несколько шагов, условие или порядок действий, понятнее раскрыть это в спецификации и сценарии. Пакеты помогают группировать варианты использования на большой диаграмме, а примечания — зафиксировать краткое ограничение или источник требования.
Чего диаграмма не раскрывает
Заголовок раздела «Чего диаграмма не раскрывает»Диаграмма использования не показывает последовательность сообщений, ветвления, экранные формы, структуру базы данных или устройство компонентов. Не стоит превращать в варианты использования технические операции вроде «вызвать API» и «сохранить запись в таблицу». Эти решения появляются в других представлениях модели.
Также диаграмма не заменяет текстовую спецификацию. За овалом «Записаться на консультацию» остаются предусловия, бизнес-правила, успешный и альтернативные сценарии, постусловия и обработка ошибок.
Проверка диаграммы
Заголовок раздела «Проверка диаграммы»- у каждого варианта использования есть понятный полезный результат;
- акторы названы ролями, а не именами конкретных людей;
- граница системы соответствует согласованному объёму проекта;
- варианты использования не дублируют шаги одного сценария;
«include»означает обязательное общее поведение, а«extend»— условное дополнение;- важные условия и исключения раскрыты в спецификациях, а не спрятаны в названиях овалов.
В модели
Заголовок раздела «В модели»Основанием для диаграммы служат стейкхолдеры, пользователи, акторы и граница системы и пользовательские цели и возможности системы. Каждый выбранный вариант следует раскрыть в спецификации варианта использования, а его потоки — в сценариях. Когда нужно показать выполнение этих потоков, используют диаграмму деятельности.
Контекст системы C4 использует ту же согласованную границу, но показывает окружение системы, а не цели акторов и отношения «include» или «extend».