DM часто называют интерактивной технологией с отсутствием режимов. Это конечно не так, но верно, что пользователь получает доступ к множеству функциональностей работая в нормальном контексте, команды и режимы ввода, присущие командно-ориентированным редакторам в этой технологии по возможности не используются. Обычной синтаксической композицией взаимодействия в DM является "выбор объекта" за которым следует "активация функции". Переход в режим "объект выбран" отражается изменением яркости объекта, после активации функции возможен переход в новый режим (например ожидания ввода параметра) отображаемый изменением формы курсора.
Требования к конструированию DM интерфейсов:
поддержка разных классов интерактивной технологии;
возможность создания новых типов технологий;
использования подходящего, простого в изучении языка программирования для описания частей системы, которую трудно специфицировать графически;
предоставление разной интерактивной технологии одновременно;
обеспечение семантической обратной связи, проверки семантики и использования в семантике установок по умолчанию;
гибкость компоненты представления;
выражение синтаксиса в терминах индивидуальных объектов.
0.4.5 Пример реализации UIDS/UIMS
В заключении приведем в качестве примера описание системы UIMS XFaceMaker2 фирмы Non Standard Logics, созданной на базе OSF/Motif и X Window System.
Проектирование интерфейса. Пользователь создает интерфейс в интерактивном режиме, используя предопределенные элементы - заготовки (Widgets).
Спецификация ресурсов. Реализует простую установку параметров (ресурсов) для заготовок. Многообразие ресурсов заготовок и их взаимодействия делает задачу установки параметров чрезвычайно сложной. XFM2 везде, где это возможно, предоставляет предопределенную установку соответствующего выбора, в частности в зонах диалога.
Спецификация поведения интерфейса. Описывается на С-подобном командном языке (Face). Динамика поведения интерфейса трактуется XFM2 как целостная часть вместе с геометрическим представлением.
Простая и естественная связь между интерфейсом и прикладной задачей. Реализована двумя способами: вызовом функции прикладной задачи из описания или с помощью разделяемых переменных (активных значений). Разделяемые переменные могут быть любого типа. Таким образом возможна связь с прикладной задачей через указатель на заготовку в интерфейсе.
Непосредственное и полное тестирование интерфейса и его поведения (так называемый режим попытки (try mode). В этом режиме интерпретируется описание связанное с какими либо событиями, но без вызова функций прикладной задачи.
Эффективность конечного приложения. Результат проектирования реализуется двумя способами: либо интерпретацией описания, аналогично режиму TRY, либо компиляцией интерфейса вместе со всеми описаниями в С код.
0.4.6 Выводы
Ситуация в области разработки систем построения и управления интерфейсом пользователя в наши дни напоминает ситуацию с графикой до выработки международных стандартов: нет единой терминологии, есть разные подходы к построению моделей (лингвистический, графический), которые часто пересекаются.
Анализ разработок в области UIMS позволяет представить соотношение между различными компонентами в виде слойной структуры, напоминающей структуру OSI [104]. При реализации конкретной прикладной задачи необходимый уровень UIMS и набор компонент может определяться из соображений требуемой эффективности и доступных ресурсов.
Рис. 0.4.27: Рекомендованная модель UIMS
Открытые проблемы в разработки UIMS можно определить как:
эргономика взаимодействия;
управление диалогом;
отделение интерфейса пользователя;
сопровождение, мобильность и эффективность.
Do'stlaringiz bilan baham: |