Лабораторная работа Бумажное прототипирование пользовательских интерфейсов 6
 Скачать 144.13 Kb.
|
Лабораторная работа № 3. Моделирование вариантов использования, пользовательских историйПорядок выполнения работыПровести анализ предметной области в соответствии с выбран- ным заданием. Составить пять сценариев использования программного обеспечения пользователем согласно формату описания Кобейна. Оформить отчет. Осуществить защиту работы. Краткие теоретические сведенияСценарии использования. Сценарий – один из способов описания структуры задачи. Это повествовательный рассказ о совершаемых действиях, это история, эпизод, происходящий в данных временных рамках и в данном контексте. Различные формы сценариев широко применяются при разработке программного обеспечения. Сценарии задач и взаимодействий обычно богаты характеристиками и обладают высокой реалистичностью. Сценарии при разработке пользовательского интерфейса описывают взаимодействие между пользователем (или типом пользователей) и системой. Обыкновенные сценарии обладают некоторыми серьезными ограничениями при попытке использовать их для проектирования пользовательского интерфейса. В них делается упор на реалистичность и детали, при этом на серьезные проблемы и общую организацию обращается недостаточно внимания. Сценарии включают в себя правдоподобные описания комбинаций отдельных действий и задач, поэтому часто бывает тяжело выделить и понять основную суть взаимодействия. Модели use case. Элемент use case – это ситуация, вариант использования, то есть некоторый случай применения системы. По сути, use case – это: обеспечение функциональности; сугубо внешняя точка зрения (принцип «черного ящика»); повествовательное описание; описание взаимодействия между пользователем (в какой-то роли) и системой; завершенное и понятное пользователю применение системы. Каждый элемент use case описывает в повествовательной форме завершенное, хорошо определенное взаимодействие, имеющее ясную цель с точки зрения пользователя. При объектно-ориентированном подходе элементы use case могут описывать взаимодействие с другими системами и оборудованием, а не только с живыми пользователями. Тем не менее когда целью является разработка пользовательского интерфейса, можно совершенно спокойно ограничиться рассмотрением только тех элементов use case, которые относятся к взаимоотношениям человека и системы. Сущностные элементы use case. Сущностный элемент use case – это структурированное повествование, выраженное на языке данной прикладной области и пользователей системы и содержащее упрощенное, обобщенное, абстрактное, не зависящее от технологии и реализации описание одной завершенной, наполненной смыслом и хорошо определенной с точки зрения пользователей задачи или взаимодействия. Предполагается, что пользователь играет определенную роль по отношению к системе, а в описании воплощаются цели и замыслы лежащего в его основе взаимодействия. Сущностные элементы use case строятся на основе целей и задач пользователя, а не на основе каких-то конкретных механизмов или этапов, ведущих к достижению этих целей. Некоторым кажется значимым включение целей пользователей в модели use case, но это не должно быть связано с упрощениями, присущими сущностному моделированию. При применении подхода, ориентированного на удобство использования, в сущностных элементах use case, являющихся структурированным описанием, можно выделить три части: изложение общих устремлений пользователя, выраженное в элементе use case, плюс состоящее из двух частей описание, включающее в себя модель пользовательских устремлений и модель обязательств системы. Сущностные элементы use case именуются, причем при помощи этих имен стараются выразить пользовательские намерения в условиях данного варианта использования. В соответствии с соглашением, предложенным Якобсоном, элемент use case изображается в виде эллипса с именем элемента. Описание вариантов использования. В контексте процесса управления требованиями варианты использования трактуются следующим образом (согласно Коберну): вариант использования фиксирует соглашение между участниками проекта относительно поведения системы; вариант использования описывает поведение системы при различных условиях, когда система отвечает на запрос одного из участников, называемого основным действующим лицом; основное действующее лицо инициирует взаимодействие с системой, чтобы добиться некоторой цели. Система отвечает, соблюдая инте- ресы всех участников. Варианты использования – это вид документации, применяемый, когда требуется сконцентрировать усилия на обсуждении принципиальных требований к разрабатываемой системе, а не на подробном их описании. Стиль их написания зависит от масштаба, количества участников и критичности проекта. В общем случае рекомендуется придерживаться следующих правил: названия вариантов использования должны быть деловыми (нетехническими) терминами, имеющими значение для заказчика; каждый вариант использования должен представлять собой завершенную транзакцию между пользователем и системой, представляющую для первого некоторую ценность; хорошо написанный вариант использования легко читается и состоит из предложений, написанных в единой грамматической форме. На обучение чтению варианта использования не должно уходить больше нескольких минут. Формат описания варианта использования (по Коберну). Имя – цель в виде краткой активной глагольной фразы. Контекст использования– более длинное описание цели. 3 Область действия. Уровень точности. Основное действующее лицо. Другие участники и их интересы. Предусловие (определяет, выполнение какого условия гарантирует система перед тем, как разрешить запуск варианта использования). Минимальные гарантии (наименьшие обещания системы участникам, в частности, когда цель основного действующего лица не может быть достигнута). Гарантии успеха (или постусловие– postcondition – устанавливает, что интересы участников удовлетворяются при успешном завершении варианта использования в конце основного сценария). Триггер(событие, которое запускает вариант использования). Основной сценарий или поток(простой для понимания типичный сценарий, в котором достигается цель основного действующего лица и удовлетворяются интересы всех участников). Каждый шаг основного сценария описывает: взаимодействие двух действующих лиц («Клиент вводит адрес»); шаг подтверждения для защиты интереса участника («Система подтверждает PIN-код»); внутреннее изменение для удовлетворения интереса участника («Система выводит сумму из баланса»). Расширения (запускаются при возникновении определенного условия, содержат последовательность шагов, описывающих, что происходит при этом условии, и заканчивается достижением цели или отказом от неё). Список изменений в технологии и данных. Вспомогательная информация. Контрольные вопросыКаким образом производится моделирование задач? Что такое сценарий использования? Что такое элемент use case? Что такое сущностные элементы use case? Чем отличаются сценарии использования от модели use case? Каким образом можно описать варианты использования? Приведите пример описания варианта использования по Коберну. |