#include #uml #extend #use-case #use-case-diagram
#включить #uml #расширить #вариант использования #схема вариантов использования
Вопрос:
Почему во многих случаях вам нужно разделять или разбивать один вариант использования на два или более вариантов использования?
Комментарии:
1. может быть, чтобы сделать его более понятным, но это очень широкий вопрос, такой же, как зачем разделять функцию на две или более 😉
2. Предполагается, что этот вопрос содержит 5 баллов. могу ли я объяснить это с помощью включения и расширения отношений? (объяснение их назначения, добавление примера для каждого) Кроме того, является ли отношение обобщения потенциальным ответом на вопрос?
3. может быть, но как вы можете надеяться на ответ, не давая никакого контекста?
4. контекст? вы имеете в виду тематическое исследование или сценарий?
5. тедди пытается ответить на это: почему мне нужно заменить
f(123)наf(12) h('a')
Ответ №1:
Единственная причина разделить вариант использования на несколько вариантов использования — разделить значительную часть функциональности между несколькими вариантами использования путем выделения этой части функциональности в отдельный вариант использования.
Пример: «поиск информации о продукте» может быть отдельным вариантом использования, включенным в варианты использования «купить продукт» и «нанять продукт».
Помимо «включить» есть также примеры того же принципа с использованием «расширить» или «обобщить».
Поступая таким образом, вы предотвращаете копирование общего поведения в нескольких вариантах использования с возможностью увеличения несоответствий.
В предыдущем примере: мы хотим убедиться, что клиенты не получают другой способ поиска информации о продукте при покупке по сравнению с наймом продуктов. При включенном варианте использования люди, которые читают варианты использования, сразу же узнают об этом факте.
Ответ №2:
Прежде всего: вы этого не делаете. Начиная это делать, вы выполняете функциональный анализ. Суть синтеза вариантов использования заключается в том, чтобы найти цель (цели) (или добавленную стоимость), которые разные участники имеют при взаимодействии с рассматриваемой системой. Довольно бесполезно разделять цель на подцели на этом уровне. Либо у вас есть какая-то дополнительная ценность, либо у вас ее нет. Итак, если кто-то установил вариант использования и пытается его разбить, то вариант использования либо неправильный (нет варианта использования), либо бесполезный, поскольку вариант использования уже показывает добавленную стоимость.
Мое личное мнение о включении и расширении: они в основном злые и неправильная концепция, введенная технар (каковыми являются большинство дизайнеров UML) без бизнес-опыта. Их использование означает, что вы уже начинаете функциональный анализ. Но UC синтезируются из требований. То есть вы перетаскиваете свою сеть через этот суп требований и выуживаете те, которые подходят друг другу, чтобы создать историю, которая имеет смысл и которая обеспечивает дополнительную ценность: вариант использования.
И как всегда: прочитайте Биттнера / Спенса о вариантах использования.