Примеры использования анализа пригодности
Рассмотрим использование анализа пригодности на примере книжного Internet-магазина, рассмотренного в [19]. Для этого:
- Сформулируем следующие требования заказчика (владельца книжного магазина)
книжный магазин должен принимать заказы через Internet;
книжный магазин должен поддерживать до миллиона счетов клиентов;
книжный магазин должен обеспечивать защиту счетов с помощью пароля;
книжный магазин должен предоставлять средства поиска в главном каталоге;
должны быть реализованы различные методы поиска, в том числе по автору, по названию, по ISBN и по ключевым словам;
книжный магазин должен обеспечить безопасность при осуществлении платежей по кредитной карточке;
книжный магазин должен предоставить безопасные средства платежа по перечислению;
книжный магазин должен поддерживать специальный вид счетов, для которых заранее дано разрешение оплаты по перечислению;
книжный магазин должен поддерживать электронный обмен данными с системой товаров;
книжный магазин должен поддерживать электронный обмен данными с системой управления запасами;
книжный магазин должен поддерживать рецензирование книг и позволять посетителям оставлять свои комментарии;
книжный магазин должен следить за рейтингом книг на основе отзывов посетителей.
- Приведем полную диаграмму вариантов использования.
Рис. 6.20. Диаграмма вариантов использования для книжного Internet-магазина
- Рассмотрим анализ пригодности для некоторых из вариантов использования.
Для этого, для выбранных вариантов использования, сформулируем главные и альтернативные последовательности событий, построим диаграммы последовательности и диаграммы пригодности.
- В заключении приведем концептуальную модель предметной области и статическую (объектную) модель книжного Internet-магазина.
Напомним, что концептуальная модель представляет собой диаграмму сущностей, выявленных путем анализа таких источников, как высокоуровневое описание задачи и низкоуровневые требования. Элемент модели представляется в виде прямоугольника с двумя разделами, состоящими из названия сущности и его обязанности. Из отношений между сущностями будем использовать отношения ассоциации, агрегации и обобщения.
30. Концептуальная модель пользовательского интерфейса и руководящие принципы проектирования интерфейса на примере Вашей курсовой работы. (229,239)
Заказчики представляют концепцию – часто подсознательную и неполную того, как их приложение должно работать. Эту концепцию называют моделью приложения, или концепцией работы. Разные люди обычно имеют различные представления о программном продукте, что приводит к совершенно разным приложениям. Поэтому разработчик требований помогает заказчику четко сформулировать его концепцию работы приложения. Для этого применяются подходящие технологии, такие, например, как CRC-карточки, с помощью которых определяются основные (базовые) концепции предметной области, которые наделяются соответствующими обязанностями и связями. Получаемая таким образом модель представляет собой концептуальную модель предметной области.
Требования часто естественно выразить через взаимодействие приложения с внешним пользователем. Концепция вариантов использования является очень полезным способом выражения требований заказчика в форме таких взаимодействий. Набор вариантов использования этапа анализа требований, назовем моделью вариантов использования. Таким образом, для разработки концептуальной модели пользовательского интерфейса следует применять две модели: концептуальную модель предметной области и модель вариантов использования.
Разработка концептуальной модели интерфейса, ориентированной на конкретные задачи, до начала стадии проектирования пользовательского интерфейса, позволяет создать приложение, которое является простым, последовательным, единообразным по внутреннему содержанию, более понятным для изучения и использования.
Концептуальная модель пользовательского интерфейса – это модель, которую проектировщик хочет довести до понимания пользователя, с целью согласования взглядов на разработку. Используя концептуальную модель пользовательского интерфейса, и документацию к ней, пользователь рассматривает модель функционирования системы через призму своего взаимодействия с ней. Концептуальная модель пользовательского интерфейса - это ещё не пользовательский интерфейс. Модель достаточно абстрактно ( в терминах функциональных С-требований пользователя и возможных основных и альтернативных потоков событий) описывает, что именно пользователь может делать с системой и какие концепты (сущности) ему необходимо при этом знать и использовать.
Основная идея заключается в том, что тщательная разработка подробной концептуальной модели, на основе которой потом проектируется пользовательский интерфейс, должна представить приложение простым и понятным. При этом необходимо, во-первых, сделать концептуальную модель пользовательского интерфейса максимально простой с использованием минимального количества концептов, для обеспечения необходимой функциональности. Во-вторых, надо максимально ориентировать данную модель на конкретные задачи, то есть исключить или ограничить работу пользователя с концептами, не фигурирующими в данной области задач.
Важным компонентом концептуальной модели интерфейса является анализ объектов и действий – список всех видимых пользователю объектов приложения и действий, которые пользователь может совершать над каждым объектом. В реализации системы будут обязательно присутствовать объекты, так называемой, технической инфраструктуры системы, но предполагается, что они пока невидимы для пользователя. Речь идет об объектах имплементации (объектах проектирования), которые обеспечивают непосредственную реализацию событий, сопровождающих взаимодействие пользователя с системой через интерфейс.
Объекты концептуальной модели интерфейса могут образовывать структурную (is a), иерархию наследования, в которой дочерние объекты будут перенимать свойства и действия родительских объектов. В зависимости от приложения, объекты могут также образовывать иерархию включения ( has a), в которой некоторые объекты включают в себя другие ( слабая, либо сильная формы агрегации). Использование двух этих типов иерархии в концептуальной модели значительно облегчит проектирование и разработку связного и понятного пользовательского интерфейса.
Подобный анализ объектов и действий помогает управлять реализацией системы, поскольку он указывает наиболее удобный вид иерархии объектов, а также методы работы, которые предусматривает каждый вид. Анализ объектов и действий над ними, также облегчает структуру команд приложения, так как позволяет проектировщику увидеть, какие действия применимы к разным объектам, а какие могут быть спроектированы как обобщенные. В свою очередь, это делает структуру команд более легкой для изучения пользователем, так как вместо того, чтобы осваивать большое количество объектно-ориентированных команд, достаточно изучить несколько обобщенных, применяемых к разным объектам.
К примеру, если бы наше приложение было программой, помогающей клиенту управлять банковским счетом, концептуальная модель пользовательского интерфейса включала бы такие объекты, как проверка, счет, сумма денег и такие действия, как разместить, отозвать, аннулировать, запросить баланс. Концептуальная модель пользовательского интерфейса должна исключать все объекты, не входящие в данную область задач (например, буферы, диалоговые окна, база данных и т.п.), а также такие действия, как: нажатие клавиш, резервное копирование, очистка буфера обмена и т. д. Такое ограничение по количеству выделяемых концептов и действий является естественным для объектного подхода, так как каждый дополнительный концепт, добавленный в область задач, может создать проблемы с его освоением и появлением дополнительных взаимодействий.
Далее, после разработки концептуальной модели пользовательского интерфейса, необходимо написать сценарии работы пользователя с приложением. Сценарий моделирует основной поток поведения для каждого варианта использования модели вариантов использования. При написании сценариев используется терминология из области задачи, то есть сценарий должен ссылаться только на объекты и действия области задачи, а не на какие-либо свойства пользовательского интерфейса. В процессе разработки пользовательского интерфейса абстрактные концепты пользовательского интерфейса переводятся в конкретные представления и действия пользователя.
Разработка концептуальной модели пользовательского интерфейса, как первая стадия проектирования интерфейса, имеет ряд преимуществ. Во - первых, разделение области задачи, или другими словами, организация требований по сущностям концептуальной модели предметной области, с наделением этих сущностей обязанностями, позволяет определить действия, одинаковые для нескольких объектов. Впоследствии это дает возможность использовать один и тот же пользовательский интерфейс для работы с разными объектами. Это, в свою очередь, делает пользовательский интерфейс более простым и последовательным, а значит, и более удобным в изучении и использовании. Во – вторых, такие явления как существование обобщенных действий, типовая структурная иерархия и иерархия включения объектов, в значительной степени облегчают проектирование пользовательского интерфейса.
Таким образом, разработка концептуальной модели пользовательского интерфейса представляет собой методику первоначального представления объектной модели (по крайней мере, для объектов, необходимых пользователю). Далее применяются: методика выделения классов анализа и методика анализа пригодности (диаграммы устойчивости).
Руководящие принципы проектирования интерфейса
Первый принцип – контроль на стороне пользователя
Основной смысл этого принципа заключается в том, что пользователь инициирует действия, и если в результате этого контроль переходит к программе, то пользователь получает необходимую обратную связь (в виде курсора в форме песочных часов, либо индикатора ожидания или аналогичным способом).
Рис. 7.6 демонстрирует типичный поток управления в человеко – машинном взаимодействии. Событие, инициированное пользователем (выбор пункта меню, щелчок мышью, перемещение указателя мыши по экрану и т.д.), может привести к открытию окна GUI-интерфейса или вызову программы – как правило, программы на языках типа 4GL или SQL в рамках приложения информационной системы. Программа временно перехватывает контроль у пользователя.
Рис. 7.6. Поток управления GUI – программы
Процесс выполнения программы имеет возможность вернуть управление назад тому же или другому окну. В другом случае он может вызвать другой модуль на языках типа 4GL или SQL или вызвать внешнюю процедуру. В некоторых случаях программа может кое-что делать для пользователя. Это возможно, к примеру, если программе требуется выполнить вычисления, которые обычно связаны с явным пользовательским событием, или если программа перемещает указатель на другое поле экрана, а для события перемещения с исходного поля предусмотрен обработчик события выхода, связанный с ним.
Второй принцип – согласованность
Согласованность, несомненно, является вторым основным принципом разработки качественного интерфейса. Фактически согласованность означает соблюдение стандартов и следование некоторым общепринятым правилам работы с GUI-интерфейсом. Согласованность может рассматриваться, по меньшей мере, в двух аспектах.
- Соответствие стандартам поставщика GUI-интерфейса.
- Соответствие стандартам в области именования, программирования и другим, разработанным внутри организации стандартам, которые связаны с GUI-интерфейсом.
Оба аспекта одинаково важны, и второй (на который оказывают влияние разработчики) не должен противоречить первому. Если приложение разрабатывается для Windows, то следует обеспечить «впечатление и ощущение», свойственные работе в системе Windows. Для системы Macintosh замена знаменитого «яблочного» меню вложенным меню (типа «кенгуру»), вообще не удачная идея.
Разработчик GUI-интерфейса не должен слишком увлекаться творчеством и предлагать необычные новшества. Это может плохо сказаться на уверенности и умении пользователей. Пользователям следует представлять знакомую среду, поведение которой предсказуемо.
Не следует также недооценивать соответствие внутренним стандартам в области именования, программирования, аббревиатур и т.п. Сюда относятся именование и программирование меню, командных кнопок, полей экранов, а также стандартов по расположению объектов на экране и последовательному использованию элементов GUI-интерфейса в рамках всех приложений, разрабатываемых собственными силами.
Третий принцип – индивидуализация и настройка
Индивидуализация и настройка – два взаимосвязанных принципа разработки GUI-интерфейса.
Индивидуализация GUI- интерфейса – это просто его настройка под персональные нужды, в то время как настройка – так, как мы понимаем ее здесь – административная задача приспособления ПО к требованиям различных групп пользователей.
Примером индивидуализации является изменение пользователем порядка и размеров колонки в программе просмотра строк (так называемые сетки - grid) с последующим сохранением этих изменений как его личных предпочтений. При обращении к этой же программе в будущем данные предпочтения учитываются.
Примером настройки является различие в функционировании программы по отношению к опытным пользователям и пользователям-новичкам. Например, пользователю-новичку программа может предложить явную помощь и дополнительные предупреждающие сообщения, указывающие на потенциальную опасность некоторых событий, инициированных пользователем.
Во многих случаях различия между индивидуализацией и настройкой весьма размыты и малозаметны. Изменение пунктов меню, создание новых меню и т.п. попадают в обе категории. Если они предназначены для индивидуального использования – это индивидуализация. Если они осуществляются системным администратором в интересах всего коллектива пользователей – это настройка.
Четвертый принцип – терпимость к ошибкам
Хорошо спроектированный интерфейс должен позволять пользователям экспериментировать и совершать ошибки, проявляя терпимость к ошибкам. Подобная терпимость стимулирует исследовательскую активность пользователя, поскольку позволяет ему выполнять ошибочные последовательности действий с возможностью в любой момент совершить при необходимости «откат» в начало. Терпимость к ошибкам подразумевает многоуровневую систему отмены операций.
Об этом принципе легко говорить, однако, он трудно поддается реализации. Реализация терпимости к ошибкам в интерфейсе отличается особой сложностью для многопользовательских приложений баз данных. Пользователь, который снял (и потратил) деньги с банковского счета, не имеет возможности отменить эту операцию! Единственное, что он в состоянии сделать – исправить ошибку (если, конечно, это было ошибкой ), положив деньги назад на счет, осуществив для этого другую операцию. Должен или не должен терпимый к ошибкам интерфейс предупреждать пользователя о последствиях снятия денег со счета – вопрос спорный (и относится он к принципу индивидуализации интерфейса).
Пятый принцип – обратная связь
Принцип обратной связи дополняет первый принцип – контроль должен находиться на стороне пользователя. Контролировать ситуацию – значит знать, что происходит, когда контроль временно передается программе. Разработчик должен встроить в систему визуальные или аудио подсказки для каждого события, инициируемого пользователем.
В большинстве случаев указатель в форме песочных часов или индикатор ожидания представляет достаточный уровень обратной связи, чтобы понять, что программа что-то делает. Для тех компонент приложения, которые иногда могут стать источником проблем с производительностью, может потребоваться более ясная обратная связь (например, в виде отображения поясняющего сообщения). В любом случае, разработчик никогда не должен предполагать, что приложение выполняется настолько быстро, что обратная связь не потребуется. Любые отклонения в рабочей нагрузке приложения докажут, что разработчик, к сожалению, ошибался.
Шестой принцип – эстетичность и удобство
Эстетичность интерфейса влияет на зрительное восприятие системы. Удобство касается легкости, простоты, эффективности, надежности и продуктивности в использовании интерфейса. Безусловно, оба принципа касаются удовлетворенности пользователя. Именно в этом вопросе разработчик GUI- интерфейса нуждается в помощи художника-графика и эксперта по социальной психологии.
Существует много разнообразных «золотых правил», касающихся создания эстетичного и удобного интерфейса. При этом, следует учитывать такие вопросы, как фиксация и движение человеческого глаза, использование цветов, чувство уравновешенности и симметрии, выравнивание и отступ между элементами, чувство пропорции, группирование связанных элементов и т.д.