Почему нам нужно разделить или разбить один вариант использования на два или более вариантов использования?

Question

Почему во многих случаях вам нужно разделить или разбить один вариант использования на два или более вариантов использования?

Answer 1

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

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

Помимо 'include', есть также примеры того же принципа с использованием 'extended' или 'generalize'.

Тем самым вы предотвращаете копирование общего поведения в нескольких случаях с вероятностью нарастания несоответствий.

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

Answer 2

Прежде всего: нет.Начать делать это означает, что вы делаете функциональный анализ.Смысл в синтезе прецедентов состоит в том, чтобы найти цель (цели) (ака. Добавленную стоимость), которую различные участники имеют при взаимодействии с рассматриваемой системой.На этом уровне совершенно бесполезно разделять цель на подцели.Либо у вас есть добавленная стоимость, либо у вас ее нет.Таким образом, если кто-то определил вариант использования и попытается разбить его, он будет либо неправильным (без варианта использования), либо бесполезным, поскольку в этом примере уже показана добавленная стоимость.

Мое личное мнение о включении и расширении: они в основном злые и неправильная концепция, представленная техническими специалистами (каковыми являются большинство разработчиков UML), не имеющими бизнес-опыта.Использование их означает, что вы уже начинаете функциональный анализ.Но UC синтезируются из требований.То есть вы протаскиваете свою сеть через эти супы требований и выискиваете те, которые сочетаются друг с другом, чтобы создать историю, которая имеет смысл - и которая приносит добавленную стоимость: пример использования.

И, как всегда, читайте Bittner / Spenceо случаях использования.