Анализ устойчивости при проектировании интерфейса

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

 

Эффективный вариант использования должен обладать следующими свойствами:

- текст для обычного (основного) потока событий «хорошего» варианта использования в основном занимает от одного до трех абзацев, а тексты для альтернативных потоков должны в среднем состоять из одного – двух предложений каждый. Идея состоит в том, чтобы каждый вариант использования воплощал одно (или более) требований в своем тексте;

- он должен быть написан в настоящем времени;

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

- с помощью него должно быть легко понятно, как основной поток событий связан с альтернативными.

Итак, каким образом необходимо моделировать подробные требования для нашей системы, памятуя о том, что требование – это требуемое поведение системы. Для демонстрации этого положения возьмем пример в [1] высокоуровневой диаграммы вариантов использования для приложения, связанного с организацией по торговле товарами. Допустим, что первоначальный вариант модели вариантов использования является наиболее адекватным на текущий момент (рис.7.1).

 

Рассмотрим реализацию описания и размещения заказа, как часть основного потока поведения варианта использования « Размещение заказа ». Для этих целей конкретизируем логику основного потока поведения, представленного на рис.7.2, для того, чтобы спроектировать сущностный прототип пользовательского интерфейса рассматриваемого варианта использования, показанный на рис.7.3. Пока мы не будем заниматься реализацией варианта использования «Поиск товара», и другими техническими вопросами.

 

Рис. 7.1. Высокоуровневая диаграмма вариантов использования для организации по торговле товарами

 

 

1. Элемент Use Case начинается, когда покупатель решает разместить заказ.

2. Система показывает страницу «Корзина покупателя» для размещения заказа.

3. Покупатель ищет товары при помощи элемента Use Case «Поиск товара».

4. Покупатель добавляет товары в заказ.

[Альтернативный поток: Покупатель удаляет товар из заказа]

5. Покупатель указывает номер товара, который желает заказать.

6. Покупатель решает обновить страницу.

7. Система подсчитывает промежуточную сумму, умножая цену товара на количество заказанного товара.

8. Система снова показывает «Корзину покупателя».

9. Покупатель повторяет шаги со 3-го по 8-й для составления заказа.

10. Покупатель прекращает добавлять товары к своему заказу.

11. Покупатель предоставляет информацию о доставке и оплате, включая имя, телефон и почтовый адрес.

12. Покупатель решает посчитать сумму заказа.

[Альтернативный поток: Покупатель продолжает заказывать].

13. Система подсчитывает промежуточную сумму всего заказа, складывая промежуточные суммы частей заказа.

14. Система подсчитывает налоги, применимые к заказу согласно бизнес-правилу «Подсчитать налоги с заказа».

15. Система подсчитывает скидки, применимые к заказу согласно бизнес-правилу «Подсчитать скидки с заказа».

16. Система подсчитывает оплату доставки и обработки заказа согласно бизнес-правилу « Подсчитать оплату доставки и обработки».

17. Система подсчитывает общую сумму заказа, добавляя применимые налоги к промежуточной сумме заказа и вычитая скидки.

18. Система подсчитывает страницу «Итог».

19. Покупатель проверяет правильность заказа.

20. Покупатель указывает способ оплаты.

[Альтернативный поток: Покупатель продолжает заказывать]

21. Система подтверждает оплату.

[Альтернативный поток: Оплата не подтверждена]

22. Система отправляет заказ на выполнение (см. элемент Use Case «Выполнение заказа»).

23. Система показывает страницу «Подтверждение заказа».

24. Система создает и отправляет подтверждение заказа по электронной почте покупателю.

 

Рис.7.2. Основной поток поведения для размещения заказа

 

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

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

Следующим артефактом, используемым для проектирования пользовательского интерфейса, является, так называемая диаграмма потоков пользовательского интерфейса.

Размещение заказа

Номер Имя Номер Дата

покупателя покупателя заказа _________

Доставить на имя Доставить по адресу Примечание по доставке ____

(Имя покупателя) (Адрес покупателя)

Счет прислать на имя __________ Счет прислать по адресу_________

Наименование товара_____ Описание товара______Цена за единицу______

Заказанное количество _______ Промежуточная сумма товара _______

⇐ Предыдущая19202122232425262728Следующая ⇒

Поделиться: