Теоретическая часть

При построении интерфейса важно придерживаться определенных принципов, способствующих обеспечению его унификации и дружественности:

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

– уменьшение загрузки памяти пользователя. Элементы, редко или вовсе не используемые пользователем должны располагаться «на заднем плане» или быть скрыты от пользователя, уступая место наиболее актуальным, часто используемым. Элементам управления.

– последовательность пользовательского интерфейса. Все элементы управления в своей совокупности должны «читаться»: у пользователя не должно возникать сомнения, в каком порядке ему следует использовать те или иные элементы.

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

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

Решение этих задач носит вполне формализованный характер и базируется на определении объектов и субъектов разрабатываемой системы в контексте доступных элементов управления.

На начальном этапе разработки прототипа интерфейса должен быть составлен перечень объектов и данных [4], которые должны быть задействованы в данном проекте. Для каждого объекта указывается его обобщенный тип (например, данные или устройство), позволяющий заранее выделить необходимые классы объектов. При этом каждый объект разрабатываемого прототипа будет представлять собой экземпляр одного из выделенных классов.

Все объекты можно разделить на две основные группы – активные и пассивные. Первые предназначены для выполнения какой-то конкретной операции или операций, т.е. являются объектами, на которые может быть направлено действие. Например, для активного объекта «Список студентов» могут быть определены три операции (действия) – заполнить, найти, проверить. Все эти действия предполагают участие объекта «Список студентов» в качестве операнда – «заполнить список студентов», «найти в списке студентов», «проверить список студентов».

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

При этом следует иметь в виду, что одни объекты могут представлять подмножество для других. Например, объект «Студент» является подмножеством объекта «Список студентов». Эти взаимосвязи должны быть учтены при описании их свойств и допустимых действий, в частности, такие объекты должны, по меньшей мере, относиться к одному и тому же типу. Например, объекты «Студент» и «Список студентов» должны относиться к единому типу – данные, – в противном случае механизм их сопоставления не будет однозначным.

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

Последний этап создания проекта прототипа пользовательского интерфейса предполагает агрегирование данных, полученных на двух предшествующих этапах, в форме матрицы прямого манипулирования объектами. Эта матрица представляет собой двумерную таблицу, строки и столбцы которой описывают исходные и конечные объекты взаимодействия экземпляров классов, выявленных на предыдущих этапах. Для того, чтобы описать все возможные варианты взаимодействия, необходимо и в столбцах, и в строках таблицы указать все выявленные на первом этапе проектирования объекты и данные, независимо от того, к какому виду они относятся (активные или пассивные). На пересечении строк и столбцов таблицы должны быть заданы связывающие их действия. Например, в ячейке, заданной пересечением строки «Студент» и столбца «Список студентов», должно помещаться значение «Добавить студента в список», что соответствует результатам, полученным на предшествующих этапах проектирования прототипа пользовательского интерфейса.

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

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

Так, например, объект «Категория студента» может быть визуализирован с помощью трех альтернативных интерфейсных элементов:

– раскрывающийся список – ListBox, позволяющий выбрать соответствующее значение;

– компонент CheckBox, с единственным значением, например «Бюджетник»: если он выбран, то значение данного объекта – бюджетник, в противном случае – контрактник;

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