В модели вариантов использования несколько сценариев обязаны выполнять один и тот же общий фрагмент. Какой механизм UML выбрать, чтобы вынести этот фрагмент без превращения его в необязательное расширение?
Нужно использовать отношение «include». Базовый вариант использования всегда вызывает включаемый вариант, поэтому общий обязательный фрагмент выполняется как часть основного сценария. Отношение «extend» здесь неверно: оно предназначено для условного или дополнительного поведения.
Диаграммы вариантов использования UML применяются для описания поведения системы с точки зрения внешних участников, без привязки к внутренней реализации. Отношения между вариантами использования появились как средство избежать дублирования сценариев и отдельно показать обязательные и необязательные части поведения.
Без такого разделения одинаковые шаги пришлось бы копировать в несколько описаний. Это повышает риск расхождения сценариев при изменении общего правила.
Допустим, несколько операций должны обязательно выполнять проверку прав доступа. Если описать её как необязательное расширение, из модели может следовать, что некоторые сценарии имеют право пропустить проверку.
Обратная ошибка тоже опасна: если дополнительное поведение оформить через include, модель будет утверждать, что оно выполняется всегда. Это исказит требования и может привести к неверным тестам или лишним обязательным действиям в системе.
Включаемый вариант использования выделяют как самостоятельный фрагмент поведения, а из базового варианта проводят зависимость include к нему. Семантика направлена от базового варианта к включаемому: базовый сценарий использует общий фрагмент в рамках своего выполнения.
Include выбирают, когда поведение обязательно для данного сценария или когда оно является повторно используемой частью его основного потока. Например, сценарии «Оформить заказ» и «Изменить заказ» могут включать обязательный вариант «Проверить права пользователя».
Extend применяют иначе: дополнительный вариант добавляет поведение к базовому только при выполнении условия или в определённой точке расширения. Например, запрос дополнительного подтверждения может расширять оплату только для операции с повышенным риском.
Важно не выносить в отдельный включаемый вариант любой короткий шаг. Если фрагмент используется только один раз или его выделение не улучшает понимание модели, такая декомпозиция создаёт лишнюю сложность. Также отношение include не заменяет описание бизнес-правил: оно показывает связь сценариев, но не раскрывает все условия выполнения.
В интернет-магазине сценарии «Оформить возврат» и «Отменить заказ» должны проверять полномочия сотрудника. Рассматривались два варианта: продублировать проверку в каждом сценарии или вынести её в общий вариант использования.
Дублирование проще для небольшой модели, но при изменении правила требует синхронно исправлять несколько описаний. Вынесение через include уменьшает повторение и делает обязательность проверки явной, однако добавляет отдельный элемент модели, который нужно поддерживать и понятно связывать с основными сценариями.
Выбрали include, потому что проверка является обязательной и используется в нескольких сценариях. В результате изменение правила выполнялось в одном описании, а тестировщики получили единый объект для проверки общего поведения.
1. Может ли включаемый вариант использования выполняться отдельно по инициативе пользователя?
Не обязательно. Include описывает повторно используемый фрагмент поведения, а не самостоятельную пользовательскую цель. Включаемый вариант может быть технически вынесен отдельно для структурирования модели и запускаться только в составе базового сценария.
Самостоятельным вариантом использования его стоит считать только тогда, когда он представляет отдельную цель актёра и имеет собственный осмысленный результат. Простая возможность нарисовать отдельный овал этого не доказывает.
2. Чем отличается обязательность include от безусловного выполнения каждого шага сценария?
Include означает, что базовый вариант использования обращается к включаемому поведению в своей модели. Но внутри включаемого поведения всё ещё могут быть альтернативные потоки, условия и исключения.
Поэтому include не означает, что абсолютно каждый шаг фрагмента выполняется безусловно. Он означает обязательность самого включения в соответствующей точке основного сценария; ветвление должно быть описано внутри сценария.
3. Можно ли заменить include наследованием вариантов использования?
Иногда можно, но это другой механизм. Наследование показывает специализацию общего варианта использования: дочерний сценарий сохраняет базовое поведение и уточняет или изменяет его.
Include предназначен для композиции повторно используемых частей, а не для построения иерархии типов сценариев. Если нужно выразить общий фрагмент, который вызывается несколькими сценариями, include обычно точнее; если нужно показать специализированный вариант общей цели, уместнее рассматривать обобщение.