Следующий пункт: ``Непосредственное манипулирование'' (DM - Надпункт: UIDS/UIMS Предыдущий пункт: Требования к UIMSкритерии

Классификация требований к UIMS, обобщения

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

1. Интерфейс с пользователем:
   • согласованность;
   • поддержка пользователя разного уровня;
   • обеспечение обработки ошибок и восстановления.
2. Разработчик программного обеспечения:
   • предоставление абстракного языка для конструирования интерфейса пользователя;
   • предоставление согласованных интерфейсов для связанных прикладных задач;
   • обеспечение простоты изменения интерфейса на стадии его проектирования (быстрое создание прототипа);
   • упрощение разработки повторным использованием программных компонент;
   • обеспечение простоты изучения и использования прикладных программ.
3. Конечный пользователь:
   • согласованность интерфейса по прикладным программам;
   • многоуровневая поддержка сопровождения или функций помощи;
   • поддержка процесса обучения;
   • поддержка расширяемости прикладных программ.

Эти цели определяют следующие функциональные характеристики UIDS/UIMS:

• работа с входными устройствами;
• проверка допустимости ввода;
• обработка ошибок пользователя;
• реализация обратной связи;
• поддержка обновления/изменения данных прикладной задачи;
• поддержка задач развития интерфейса;
• синтаксическая поддержка.

Возможные модели управления, по терминологии конференции 1982 года в Сиэтле:

1. Интерфейс пользователя, скрывающий прикладную программу.

   Этот подход соответствует внутреннему управлению (по терминологии конференции 1982г. в Сиэтле). Основа инструментального подхода, при котором интерфейс пользователя сужается до набора модулей ввода-вывода, по мере надобности вызываемых из прикладной прогаммы, Всё управление диалогом сосредотачивается в прикладной программе, которая должна создаваться с учётом этого факта. Создание прототипов затруднено. Разделение фактически отсутствует.

2. Обобщённый пользовательский интерфейс конфигурируемый под прикладную программу.

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

3. Смешанная, приводящая к появлению новой компоненты -- связной области, являющейся ``транслятором'' между двумя Стандартными и тесно связанными компонентами. Это наиболее общая из моделей.

Наиболее часто используется модель (в вышеозначенной классификации -- третья (``смешанная'')), введённая на конференции в Seeheim (1983), в соответcтвии с которой UIMS состоит из трёх компонент:

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

На её основе определяется структура эталонной модели UIDS/UIMS, представленная на рисунке. 1.

Рекомендованная эталонная модель.

Пути реализации:

• механизм обратного вызова (прикладная программа организована как набор процедур вызываемых инструментарием);
• разделяемая память;
• передача сообщений;
• механизм обработки событий.

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

• языковая;
• графическая;
• автогенерация по спецификации прикладной задачи;
• объектно-ориентированный подход.

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

• сети меню;
• диаграммы состояний и переходов;
• контекстно-свободные грамматики;
• языки событий;
• декларативные языки;
• обычные языки программирования;
• объектно-ориентированные языки.

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

Графическая спецификация связана с определением интерфейса с помощью размещения объектов на экране (визуальное программирование, программирование демонстраций, программирование по примерам). Она проста для использования не программистами, но:

• трудна в реализации;
• поддерживает лишь ограниченные интерфейсы.

Здесь также существуют разные формы реализации:

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

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

Возможные реализации:

• создание интерфейса на основе списка процедур прикладной программы (Mike);
• создание интерфейса по типам параметров процедур (Control Panel Interface);
• соэдание интерфейса на основе определения семантики прикладной задачи, описываемой на специальном языке (IDL).

Четвёртый подход связан с принципом, называемом ``Direct Manipulation'' -- DM, рассматриваемым в следующем разделе. Основное свойство этого подхода состоит в том, что пользователь взаимодействует с индивидуальными объектами, а не со всей системой как единым целым.

Следующий пункт: ``Непосредственное манипулирование'' (DM - Надпункт: UIDS/UIMS Предыдущий пункт: Требования к UIMSкритерии