При моделировании входа в систему аналитик зафиксировал обязательную проверку личности для каждого успешного входа. Какую семантическую ошибку содержит модель?
@startuml
(Проверка личности) ..> (Вход в систему) : <<extend>>
@enduml
Ошибка в том, что обязательное поведение показано как необязательное расширение. Для проверки личности, выполняемой при каждом успешном входе, нужно использовать связь «include», направленную от базового сценария к включаемому:
Связи include и extend появились в моделировании вариантов использования, чтобы отделить общие обязательные шаги от условного или дополнительного поведения. Это помогает описывать цели пользователя, не смешивая основной сценарий с его необязательными вариациями.
Такой подход решает проблему нечётких моделей, в которых повторяющиеся действия копируются в несколько сценариев либо условные ветви ошибочно объявляются обязательными.
Связь extend означает, что один вариант использования при определённых условиях добавляет поведение к другому. Базовый сценарий должен оставаться осмысленным без этого расширения.
В примере проверка личности обязательна для каждого успешного входа. Если оставить extend, читатель модели может решить, что вход иногда выполняется без проверки. Это влияет на требования к безопасности, тестовые сценарии, оценку объёма работ и согласование ответственности между системами.
Связь include означает: выполнение базового варианта использования всегда включает выполнение другого варианта использования. Поэтому направление связи имеет значение: стрелка идёт от «Входа в систему» к «Проверке личности».
Связь extend применяется, когда дополнительное поведение запускается только при условии, например при входе с нового устройства или при подозрительной активности. Тогда базовый вход может быть завершён без расширения, а расширяющий сценарий подключается в определённой точке расширения.
Важно не использовать include просто для отображения последовательности каждого шага. Вариант использования должен описывать значимую цель или самостоятельное поведение, а не превращаться в подробную блок-схему интерфейса.
Если проверка личности нужна только для части пользователей, нельзя автоматически заменять extend на include. Сначала нужно уточнить бизнес-правило: обязательность определяется каждой попыткой входа, ролью пользователя, уровнем риска или другим условием.
В корпоративном портале вход состоял из ввода пароля и обязательной проверки через единый сервис идентификации. Аналитик сначала связал «Проверку личности» с «Входом» через extend, поскольку воспринимал проверку как дополнительный этап.
Рассматривались два варианта. Можно было оставить extend, указав условие запуска, но это создавало риск неверной трактовки требования безопасности. Можно было описать проверку только текстом основного сценария, однако тогда она хуже переиспользовалась бы в сценариях восстановления доступа и смены устройства.
Выбрали include для обязательной проверки в сценарии входа. Для дополнительного многофакторного шага, включаемого только при повышенном риске, отдельно применили extend. В результате модель явно разделила обязательную идентификацию и условный контроль риска, а тестировщики получили корректные обязательные и вариативные сценарии.
Ответ: Да, если он действительно имеет самостоятельный смысл для пользователя или бизнеса. Например, «Проверка личности» может использоваться не только при входе, но и при подтверждении особо рискованной операции. Однако сам факт повторного использования ещё не делает любой технический шаг отдельным вариантом использования.
Ответ: В этом случае условное поведение можно моделировать как extend базового входа: расширяющий сценарий добавляется при выполнении условия «устройство новое». В текстовых требованиях всё равно нужно явно зафиксировать условие, иначе диаграмма не объясняет, когда расширение срабатывает.
Ответ: Переиспользование — лишь практическое следствие, а не главный критерий. Выбор определяется обязательностью поведения и условием его запуска: include выражает обязательное включение, а extend — дополнительное поведение при заданном условии. Неверный выбор меняет смысл модели и может привести к неполному набору требований и тестов.