Концептуальная модель пользовательского интерфейса и руководящие принципы проектирования интерфейса на примере Вашей курсовой работы. (229,239)

Заказчики представляют концепцию – часто подсознательную и неполную того, как их приложение должно работать. Эту концепцию называют моделью приложения, или концепцией работы. Разные люди обычно имеют различные представления о программном продукте, что приводит к совершенно разным приложениям. Поэтому разработчик требований помогает заказчику четко сформулировать его концепцию работы приложения. Для этого применяются подходящие технологии, такие, например, как CRC-карточки, с помощью которых определяются основные (базовые) концепции предметной области, которые наделяются соответствующими обязанностями и связями. Получаемая таким образом модель представляет собой концептуальную модель предметной области.

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

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

Концептуальная модель пользовательского интерфейса – это модель, которую проектировщик хочет довести до понимания пользователя, с целью согласования взглядов на разработку. Используя концептуальную модель пользовательского интерфейса, и документацию к ней, пользователь рассматривает модель функционирования системы через призму своего взаимодействия с ней. Концептуальная модель пользовательского интерфейса - это ещё не пользовательский интерфейс. Модель достаточно абстрактно (в терминах функциональных С-требований пользователя и возможных основных и альтернативных потоков событий) описывает, что именно пользователь может делать с системой и какие концепты (сущности) ему необходимо при этом знать и использовать.

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

Важным компонентом концептуальной модели интерфейса является анализ объектов и действий – список всех видимых пользователю объектов приложения и действий, которые пользователь может совершать над каждым объектом. В реализации системы будут обязательно присутствовать объекты, так называемой, технической инфраструктуры системы, но предполагается, что они пока невидимы для пользователя. Речь идет об объектах имплементации (объектах проектирования), которые обеспечивают непосредственную реализацию событий, сопровождающих взаимодействие пользователя с системой через интерфейс.

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

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

К примеру, если бы наше приложение было программой, помогающей клиенту управлять банковским счетом, концептуальная модель пользовательского интерфейса включала бы такие объекты, как п роверка, счет, сумма денег и такие действия, как разместить, отозвать, аннулировать, запросить баланс. Концептуальная модель пользовательского интерфейса должна исключать все объекты, не входящие в данную область задач (например, буферы, диалоговые окна, база данных и т.п.), а также такие действия, как: нажатие клавиш, резервное копирование, очистка буфера обмена и т. д. Такое ограничение по количеству выделяемых концептов и действий является естественным для объектного подхода, так как каждый дополнительный концепт, добавленный в область задач, может создать проблемы с его освоением и появлением дополнительных взаимодействий.

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

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

Таким образом, разработка концептуальной модели пользовательского интерфейса представляет собой методику первоначального представления объектной модели (по крайней мере, для объектов, необходимых пользователю). Далее применяются: методика выделения классов анализа и методика анализа пригодности (диаграммы устойчивости).