Пользовательского интерфейса

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

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

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

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

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

Согласно концепции построения графа состояний и переходов интерфейса каждая последующая итерация взаимодействия с пользователем приводит изменению состава данных. Эту особенность и следует реализовать посредством соответствующего функционального содержания. Так, например, рассмотрим два класса объектов «Факультет» и «Специальность». Множество данных первого класса определяет информационное обеспечение второго класса, т.е. при выборе факультета список специальностей ограничивается их принадлежностью к нему. Пользователю должны быть предоставлены возможности оперировать данными в контексте того состояния, в котором находится система в конкретный момент времени. Пусть для визуального представления рассматриваемых классов объектов выбран компонент ListBox. Для решения поставленной задачи необходимо предусмотреть метод связанный с изменением выбранного значения. Например, в рамках RAD-системы Delphi такой метод уже предусмотрен (onChange), т. е. достаточно его просто объявить. Однако такая ситуация не всегда имеет место. Зачастую разработчику недостаточно имеющейся функциональности системы и он вынужден создавать собственные. Такой способ, хотя и является трудоемким, зато обеспечивает большую гибкость по сравнению с традиционным подходом.

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

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

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

1. Функциональное описание, в котором кратко представлены функциональные возможности системы. Прочитав функциональное описание и вводное руководство, пользователь должен определить, та ли это система, которая ему нужна?

2. Документ по инсталляции системы, в котором содержится информация по установке системы. Здесь должна быть представлена информация о дисках, на которых поставляется система, описание файлов и минимальные требования к конфигурации.

3. Вводное руководство, предоставляющее неформальное введение в систему, описывающее её «повседневное» использование. Как начать работу с системой, как использовать общие возможности. Все описания снабжаются примерами и содержат сведения о том, как восстановить систему, после совершения ошибки и как начать работу заново.

4. Справочное руководство, в котором описаны возможности системы и их использование, представлен список сообщений об ошибках и возможные причины их появления.

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

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