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