Неизвестная связь между вариантами использования в диаграмме «usecase»

Question

В проекте есть вариант использования "синхронизация" для синхронизации файлов. Естественно, иногда для варианта использования «синхронизация» требуется «загрузка файлов», что является другим вариантом использования. Таким образом, существует связь между «синхронизацией» и «загрузкой файлов»; но «загрузка файлов» не extend «синхронизирует», потому что это часть синхронизации, и иногда синхронизация не завершается без этого. Хотя "синхронизация" не include "загрузка файлов", потому что существуют ситуации, когда синхронизация не требует загрузки.

Как я могу описать этот ситуатин в диаграмме прецедентов?

Answer 1

Если загружаемая часть всегда является частью sync (то есть она может быть вызвана только из sync , но не из какого-либо другого UC или как независимый UC ) затем загружаемая часть является частью sync и поэтому не должна быть разложена как отдельный UC . Тот факт, что это не происходит всегда, ничего не меняет здесь (это просто альтернативный поток).

Если загружаемая часть является отдельным UC (то есть может выполняться независимо или - все еще не рекомендуется делать это отдельным UC - может вызываться из другого UC), но она запускается только во время некоторых запусков синхронизация , тогда это тип отношений расширение (стрелка указывает от часть загрузки до синхронизация )

Если загружаемая часть - это отдельный UC (как выше), но он запускается каждый раз, когда запускается sync (т.е. это часть каждого потока sync ) тогда это включает тип отношений (стрелка указывает от синхронизация до загрузка части ).

Насколько я понимаю, это либо не отдельный UC, либо extension . Дело в том, что:

потому что это часть синхронизации, а иногда синхронизация не завершается без этого.

предполагает, что это просто не отдельный UC (так что просто отбросьте его с вашей диаграммы).

Тем не менее, если это может быть отдельный UC, то в этой части:

Хотя «синхронизация» не включает «загрузку файлов», поскольку существуют ситуации, когда синхронизация не требует загрузки.

вы правы - это не может быть , включая , оставляя вас только с опцией extends (что верно). Тот факт, что он является - как вы сказали - частью sync (то есть он запускается sync и предоставляет результаты) именно то, что нужно для того, чтобы он был продлить .

Answer 2

Используйте для таких ситуаций include.

Распространенным заблуждением является то, что включенные варианты использования должны всегда выполняться, а дополнительные варианты использования необязательны .

На самом деле основное отличие между include и extension заключается скорее в зависимости, чем в частоте выполнения.

Из спецификации UML 2.5:

Включить - это DirectedRelationhip между двумя вариантами использования, указывающее что поведение включенного UseCase (дополнение) вставлено в поведение включающего UseCase (включаяCase).
[...]
Включение UseCase может зависеть от изменений, произведенных выполнением включенный UseCase. Включенный UseCase должен быть доступен для поведение включающего UseCase будет полностью описано.
[...]
Отношение «Включить» предназначено для использования при наличии общих частей поведение двух или более вариантов использования. Эта общая часть затем извлекается в отдельный UseCase, который будет включен во все базовые UseCase, имеющие эта часть общего. Поскольку основное использование отношения Включить для повторного использования общих частей обычно оставляют в базовом UseCase не завершена сама по себе, но зависит от включаемых частей осмысленный. Это отражается в направлении отношений, указывая, что базовый UseCase зависит от дополнения, но не от недостатков наоборот.

Но будьте осторожны с включениями и расширениями. Прежде чем вы это узнаете, вы будете описывать каждую функцию системы как вариант использования, который побеждает ее назначение.