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

Question

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

Например, у меня есть модуль с именем X. Этот модуль X на самом деле состоит из трех субмодулей с именами x1, x2 и x3. Пользователь может выбрать любой из этих подмодулей из доступных опций. Это означает, что этот модуль не выходит без этих 3 подмодулей. Я сомневаюсь, что при рисовании диаграммы вариантов использования, как я могу представить эти подмодули? Я должен использовать «включить» или «расширить» для этого суб-модулей из основного модуля?

Другое сомнение в том, что когда я рисую диаграмму вариантов использования x1. Как я могу представить основную работу под названием «Просмотр местоположения» и дополнительную работу под названием «Изменить представление карты»

Пожалуйста, объясните ответ.

Answer 1

Первый

Примеры использования просто описывают «что пользователь может делать с вашей системой».

Это простое определение иногда смущает многих людей:

Когда мы спрашиваем, что пользователь может делать с вашей Системой, они говорят меню опций в раннем прототипе GUI.

В вашей проблеме, я думаю, вы также говорите о "GUI".Насколько я понимаю, у вас есть прототип графического интерфейса, в котором пользователь выбирает опцию «X Module», затем вы показываете действия подопций пользователя «X1, X1, X3» ...

Варианты использования "не заинтересованы в" вашемДетали GUI.Он пытается уловить реальную «мотивацию» ...

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

Что пользователь хотел сделать с помощьюATM?Предположим, что он хотел оплатить свои счета через банкомат ...

Простой вариант использования Digram Для этого:

Но как он будет оплачивать свои счета?Это фиксируется описаниями вариантов использования [не диаграммой, текстом варианта использования] ... И предположим, что наш клиент говорит, что пользователь может оплачивать такие счета: его / ее счет за мобильный телефон, его / ее счет за электроэнергию, может быть его / ееналог.И вы поймете, что каждая из этих выплат имеет разные характеристики.

И вы начинаете писать описание варианта использования в форме [Система делает это, актер делает это]

Вариант использования: Оплата счета.................

Основной сценарий:

1. Система отображения операций банкомата
2. Пользователь выбрал PayBill Options

3. Система показывает те операции по оплате счетов

   A) Оплата счета за мобильный телефон

   B) Оплата счета за электроэнергию

   C) ...

4. Пользователь Выберите параметры

5. Если пользователь выберет оплату счета за сотовый телефон, то

   5.a) Система запросит номер мобильного телефона.

   ........ .......

   5.n) Система запрашивает, хочет ли пользователь получать

   5.n + 1)Пользователь хочет квитанцию ​​

   5.n + 2) Система выдает квитанцию ​​.....

   .....

6. Если пользовательВыберите Оплатить счет за электричество, затем ..... ...

7. Если пользователь выбирает параметры X, то .... ....

КакGEНеральное правило: не загрязняйте диаграмму вариантов использования множеством «расширяет» или «включает», «обобщает»

В результате: мы не можем знать, «изменить вид карты» или «view location "- это реальный вариант использования [который мы должны показать на диаграмме] или просто шаг в сценарии использования.Это зависит от вашего контекста ...

В качестве практического совета вы можете применить тесты Крейга Лармана 3, чтобы выяснить, являются ли они реальными вариантами использования:

• Тест босса: подумайтепохож на начальника".И скажите актеру [думайте, что актер как ваш сотрудник] «измените представление».Удовлетворяет ли это вас как "Босс".Или это бессмысленно.Например, «PayBill» для прохождения босс-теста банкомата, но «выбрать варианты оплаты» - нет.
• Размер теста: реальный вариант использования, имеет некоторый размер [сценарный], ни одного шага
• AВариант использования завершен: в результате варианта использования пользователь должен получить реальную выгоду.

Наконец,

Варианты использования - это в основном тексты: [Scenarious] Not Diagrams,Диаграммы просто дают обзор функциональных требований.Но просто обзор, а не детали