Как мне разработать диаграмму вариантов использования UML

Question

Я пытаюсь разработать диаграмму вариантов использования для следующего сценария.

У меня есть общество, которое распределяет товары среди клиентов на основе их заказов. Этими клиентами могут быть администрации, компании или частные лица. В зависимости от того, кем является клиент, я хочу узнать более или менее их информацию (имя, номер и т. Д. c)

Варианты использования различаются в зависимости от того, является ли клиент:

1. Engli sh
2. Engli sh и пользовались этой услугой более 3 лет
3. Иностранные

Например:

• 1) Заказы клиентов Engli sh принимаются только в том случае, если они заранее вносят небольшую плату.

• 2) клиентов Engli sh, которые воспользовались услугой в течение 3 лет, не нужно платить эту плату, но необходимо получить одобрение другого участника (в данном случае, агента)

• 3) Заказы иностранных клиентов принимаются всегда, несмотря ни на что.

Именно здесь я сталкиваюсь с неприятностями и мне нужна помощь.

Заказы от клиентов ngli sh, имеющих судимость, всегда отклоняются, ЕСЛИ они не являются администрацией.

Каковы наиболее оптимальные варианты действий здесь? Я думал о том, чтобы перейти с English client и Foreign clients, но я не знаю, как включить «Если клиент не является администрацией» в случае использования.

Answer 1

Вариант использования схема не подходит для размещения этой информации. Как правильно указал @Christophe, вариант использования представляет собой цель для пользователя, который собирается взаимодействовать с системой для достижения цели .

Это означает, что там В вашем сценарии есть только один вариант использования: «Заказать товар» . Однако он имеет набор предварительных условий . Вы можете перечислить их как структурированный простой текст. Поскольку за каждым из них стоит некоторая сложность, я рекомендую поместить их в отдельную таблицу решений. Тогда у вас есть хорошее четкое разделение областей диаграммы, и они остаются легко читаемыми.

Sidenote: Может быть второй «распределить заказанные товары», выполненный вторым актером, который является сотрудником, который выполняет / маршрутизация / диспетчеризация.

Answer 2

Действующие лица в сценариях использования UML являются классификаторами. Чтобы решить, каких акторов создавать, необходимо понимать их цели и поведение, а также то, как они различаются во взаимодействии с системой.

Прежде всего, вам необходимо уточнить супер-неоднозначные требования:

• " Engli sh client ": это клиент с Engli sh национальность? Это клиент, который постоянно живет в Великобритании? Это клиент с адресом в Великобритании? Это клиент с номером телефона +44?
• " Иностранный клиент ": такие же вопросы + можете ли вы точно определить разницу между Ensgli sh и Иностранным? Например: что с би-гражданами? что с людьми, имеющими два адреса, один находящийся за границей?
• " Использование этой услуги более трех лет ": что с иностранным клиентом, который пользуется услугой в течение 3 лет, а затем обосновывается в Великобритании?
• Поскольку вы доставляете товар, вам также может понадобиться указать адрес доставки. Что с клиентом Engli sh, заказывающим по иностранному адресу или наоборот?
• " судимость ": судимость может со временем меняться: предоставляется ли она при каждой покупке? или это часть процесса регистрации клиентов? В последнем случае, необходимо ли периодически обновлять эту информацию?

Варианты использования в принципе должны быть ориентированы на достижение цели. Таким образом, вариант использования представляет собой цель для пользователя, который собирается взаимодействовать с системой для достижения цели. Варианты использования не предназначены для описания подробной последовательности вашего процесса (если это клиент, сделайте это и т. Д. c ...), и ни один из участников не предназначен для этой цели.

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

• Новый клиент: новый клиент может захотеть предоставить данные (адрес, идентификация) или доказательства, которые он имеет право купить (судимость - я полагаю, ваша деятельность регулируется, если вы запрашиваете такие подробности)
• Publi c администрация: поведение администрации при покупке в любом случае отличается из-за публичных c закупок и правовых ограничений.
• Частная компания: поведение отличается, поскольку в нем могут участвовать несколько человек,
• Частное лицо

Необходимость уплаты авансового платежа зависит от адреса , национальность, история. Это больше связано с процессом (это часть его), чем независимая цель для актера. Так что я бы не стал показывать это как пример использования и не делал бы других актеров для этой цели.

Причиной отказа в заказе является не то, что не имеет отношения к клиенту (ни у одного клиента нет цели go получить отказ в покупке!). Это относится к вам и вашей системе и является следствием процесса регистрации. Так что для этого не нужно иметь специального актера.