Рекомендации по разделению процесса с участием нескольких действующих лиц на варианты использования

Question

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

1. Поставщик создает прайс-лист,
2. Покупатель выбирает несколько предметов для покупки и отправляет заказ на покупку,
3. Поставщик получает заказ на поставку и отправляет товар.
4. Поставщик отправляет счет
5. Покупатель получает счет и производит оплату

Конечно, каждый из этих шагов сам по себе может быть сложным. Как бы вы разбили это на варианты использования в вашем документе требований?

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

В качестве альтернативы, использование варианта использования каждого из вышеперечисленных шагов может скрыть некоторые важные взаимодействия и потоки, которые должны быть зафиксированы. Имеет ли смысл иметь вариант использования, который начинается с «Получен заказ на покупку» и заканчивается «Отправить счет», а затем другой, который начинается с «Получить счет» и заканчивается «Делает платеж»?

Любой совет?

Answer 1

Обычно я подхожу к таким задачам, просто начав создавать UML Use Case и высокоуровневые диаграммы Activity для процесса. Не беспокойтесь о специфике, просто сделайте свой лучший снимок.

Когда у вас будет черновик, вы почти сразу увидите, как его можно улучшить. Затем вы можете продолжить его рефакторинг - уменьшите вариант использования, структурируйте большие Деятельности и так далее. В качестве альтернативы вы можете объединить несколько вариантов использования вместе, если они слишком малы.

Не зная деталей вашего проекта, я бы просто пошел дальше и сделал каждый шаг отдельным вариантом использования - все они кажутся автономными и могут быть описаны без каких-либо перекрестных ссылок. Если при этом вы найдете какие-либо зависимости, вы всегда можете переосмыслить подход.

Также рассмотрите возможность использования блоков «extension» и «include» для общих элементов, таких как ведение журнала, безопасность и т. Д.

Answer 2

Да, здесь есть много возможностей. В приведенном выше примере Покупатель может сделать несколько частичных платежей для оплаты счета еще сложнее.

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

Я работаю над исходным кодом QuickBooks, и количество путей прохождения транзакции через систему устрашает. Наши парни из QA практически не могут протестировать каждую комбинацию.