UIDS/UIMS

Введение в UIMS

Родоначальником систем интерактивного взаимодействия человека с машиной является Ульям Ньюман (1968, Reaction Handler. A System for Interactive Graphical Programming). А впервые название UIMS появилось в статье Д.Казика Tiger в 1982г.[5].
Основные концепции UIMS были выработаны на ряде семинаров:

1983 Workshop on "User Interface Management Systems", Seeheim, FRG;

1986 ACM SIGGRAPH Workshoop on "Software Tools for User Interface Management Systems", Seattle, USA;

1987 Glasgow University Workshop on "User Interface Management Systems";

1990 ESPRIT/Eurographics International Workshop on "User Interface Management Systems and Environments", Lisbon.

Традиционный графический подход к интерфейсу с пользователем связан с работами Сазерленда, Ньюмена и др.[2,3], в котором взаимодействие базируется на использовании графического дисплея с регенерацией и светового пера. Дальнейшее развитие графического диалога связано с прогрессом в области систем интерактивной машинной графики, который привел к регламентации в виде международных стандартов.
GKS - первый международный графический стандарт. В нем впервые зафиксированы концепции "рабочих станций" и логических устройств ввода (клавиатура, выбор, локатор, валюатор, указатель, ввод последовательности координат). К сожалению задуман во время превосходства парадигмы векторного рисования. Отсюда слабость поддержки диалога: отсутствие возможности ввода новых устройств или видоизменения изображения устройства на экране даже из прикладной программы (пользователя графического пакета), что приводит к необходимости использования в основном символьного ввода при организации диалога. Реализация диалога в GKS прерогатива прикладной программы, возможности раздельного проектирования не предполагается.
Второе направление графики - растровая графика оказала чрезвычайно большое влияние на все последующее развитие интерактивных систем. Все основные черты интерфейса с пользователем на современных рабочих станциях суть производные от работ Xerox PARC: управление окнами

использование графических символов ("икон") для представления объектов
стиль взаимодействия, называемый непосредственным манипулированием
популярность "мыши" как устройства позиционирования на экране
объектно-ориентированный стиль программирования.

С тех пор система классификации инструментария для создания и управления пользовательским интерфейсом рассматривается на трех уровнях:

системы управления окнами (WMS - Window Manager System);
специализированный инструментарий;
- обычный (MacIntosh, SunView . . .)
- объектно-ориентированный (Smalltalk-80, Andrew, InterView)
системы управления пользовательским интерфейсом.

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

Системы управления окнами (WMS)

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

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

Интерфейс со стороны оператора и прикладной программы содержит команды заведения/уничтожения окон, изменения их размеров и положения, поднятие наверх, сжатия окна до пиктограммы и восстановления. Содержит графическую библиотеку вывода (только основные примитивы) и обработчик событий. Тем самым есть некие механизмы для реализации пользовательского интерфейса.
Возможны реализации WMS двух типов: базовая система (Kernel System), работающая на одной машине, и сетевая (Network oriented), реализуемая на основе модели клиент-сервер.

Инструментарий создания пользовательского интерфейса

По Майерсу [4] "Инструментарий создания пользовательского интерфейса есть библиотека технологических интерактивных средств, дающих возможность использовать физические устройства ввода (мышь, клавиатура, планшет . . .) для ввода значений (таких как команда, число, положение или имя) при наличии обратной связи, отображаемой на экране". Программист использует этот инструментарий для организации взаимодействия с человеком. Инструментарий содержит набор функций, реализующий компоненты интерфейса нижнего уровня такие как: меню, кнопки, зоны диалога, подокна, зоны прокрутки. Инструментарий включает также графическую библиотеку вывода (только основные примитивы) и обработчик событий. Тем самым есть некие механизмы и инструменты разработки, но пока нет общей стратегии.
Возможные модели управления, по терминологии конференции 1982 года в Сиэтле:

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

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

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

Дальнейшее развитие инструментария привело к появлению понятия Widget (заготовка) - объекта более сложного, чем перечисленный выше набор простых средств ввода в прикладную программу, хотя и включающих в себя эти средства. Такой инструментарий не стандартизован, различные фирмы (Apple, Sun, etc.) предлагают существенно разный набор средств, как по номенклатуре, так и по функциональным возможностям. В качестве примера рассмотрим набор простых, составных и дополнительных заготовок, предоставляемых программным продуктом OSF/Motif.

Основные:
Область рисования	графическое пространство
Разделитель	линии разделяющие области
Метка	статический текст
Шкала	слайдер для получения числа
Зона прокрутки	управление прокруткой
Три типа Кнопок	управляющие кнопки с различным статусом
Каскадные Кнопки	кнопки для каскадных меню
Необязательные поля	отображение перечислимых значений переменной
Текст	ввод и редактирование текста
Команды	клавиатура с описанием
Составные:
Доска объявлений	панель с произвольным размещением объектов
Экранная форма	форма размещения объектов с выравниванием
Список	список строк
Вертикальное подокно	столбец с изменяемой высотой
Строка/Столбец	объект с ограничениями по строкам и столбцам
Зона меню	область меню для выпадающего меню
Кадр	контейнер для поддержки 3D обрамления
Дополнительные:
Прокрутка текста	область прокрутки текста
Прокрутка списка	область прокрутки списка
Окно прокрутки	обобщенная область прокрутки
Радио поле	набор радио кнопок
Поле выбора	выбор из списка строк
Поле выбора файла	специализированная область селектирования файлов
Основное окно	прикладное окно верхнего уровня
Поле диалога	транзитное поле диалога
Диалог в экранной форме	транзитное поле диалога для экранных форм
Меню	"выпадающее" или "выпрыгивающее" меню
Сообщение/предупреждение	зона диалога для печати сообщений

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

Системы управления интерфейсом пользователя

В научной литературе пока нет согласованного взгляда на термин UIMS - точное его значение само является объектом исследования.
Классическое определение было выработано на семинаре в Глазго в 1987г.
"UIMS - это элемент программного обеспечения, который управляет всеми коммуникациями между пользователем и прикладной программой: прикладная программа не должна связываться с конечным пользователем напрямую."
Одна из версий принадлежит Майерсу: "Система проектирования интерфейса пользователя есть интегрированный набор средств, помогающих программисту в создании и управлении различными интерфейсами пользователя. Эти системы обычно называют системами управления пользовательским интерфейсом (UIMS - User Interface Management Systems), но предпочтительнее называть их системами проектирования (UIDS - User Interface Development Systems), поскольку UIMS ассоциируется только с частью системы, работающей во время исполнения программы (но не с частью, используемой во время разработки), или с системами, включающими явные компоненты управления диалогом. UIDS обеспечивает как разработку, так и реализацию интерфейса и, таким образом, покрывает более широкий класс программ".
Основной концепцией UIDS является идея строгого разделения интерфейса и прикладной программы. В идеале она должна поддерживать все стили диалога и упрощать построение сложных интерфейсов. UIDS должен обеспечивать язык определения интерфейса для представления требуемого диалога и генератор, которой автоматически создает необходимый код из исходного определения в этом языке. Эти функции во многом похожи на функции компилятора или интерпретатора для обычных языков программирования.
UIMS следует разрабатывать в условиях междисциплинарной кооперации экспертов с тем, чтобы создавать, подгонять (приспосабливать), управлять и экспериментировать с (такие эксперименты активно проводятся в m\$oft) взаимодействием между пользователем и прикладной программой опосредованным интерфейсами различных стилей, разными устройствами и методиками (техниками). Основной целью UIMS является освобождение программиста не только от низкоуровневого программирования и заботы о непосредственном управлении устройствами ввода/вывода, но и от проблем интерфейса, носящих не программный, а например, эстетический и т.п., характер, которые являются вотчиной художников, дизайнеров интерфейсов, предметом психологии, эргономики и т.п. Система обычно включает как составную часть набор инструментов для обеспечения поддержки создания, отладки, тестирования и апробирования интерактивных человеко-компьютерных систем. UIMS должна включать обстоятельное множество инструментов дизайнера интерфейса. UIMS призвана снижать затраты на создание программного обеспечения. Поскольку в UIMS акцент делается на описании, а не на кодировании, то UIMS можно описывать как язык четвёртого поколения.
Важно чётко различать прикладного программиста и дизайнера пользовательского интерфейса. Они могут быть одним и тем же лицом, но это совсем не обязательно. Разделение частей пользовательского интерфейса и собственно приложения и является целью UIMS. Это разделение делает возможным распределение функций прикладного программиста и дизайнера пользовательского интерфейса между разными людьми. Также должно быть возможно использовать различные интерфейсы с одним и тем же приложением.
Разработчик прикладного программного обеспечения использует UIMS, чтобы определить диалог между пользователем и приложением, который не зависит от приложения. На приложение налагается внешнее управление. Система управляет выводом приложения - его представлением на устройстве вывода, и поддерживает используемые методы взаимодействия.
Разработчику программного обеспечения должна быть предоставлена возможность создания интерфейсов, совместимых между разными прикладными программами. Полезным свойством является гибкость системы в смысле возможности поддержки пользователей разного уровня подготовки: от полных "чайников" до опытных - такая гибкость делает прикладную часть программного продукта независимой от уровня пользователя и операционной среды. Должно быть возможно легко подгонять и расширять как интерфейс, так и само приложение. В идеале UIMS должна быть достаточно гибкой, чтобы было возможно использовать интерфейс в других приложениях, в других разработках.
С точки зрения конечного пользователя UIMS должна позволять создавать приложения легко, а сами приложения должны получаться эффективными и простыми в использовании. Постоянство интерфейса при переходе от одного приложения к другому должно уменьшать время необходимого обучения. Система должна быть самодокументированной, предоставлять информационную поддержку различных уровней. Конечный пользователь должен иметь возможность подогнать интерфейс под свои потребности (эстетические, профессиональные, etc.) с тем, чтобы сделать его более лёгким в использовании. Должно быть возможно развивать приложение без разрушения (т.е. оставаясь в рамках существующего интерфейса.
Для создания пользовательского интерфейса должны предоставляться отдельные ресурсы, поскольку в описываемой идеологии эта фаза отделена от разработки самого приложения.

Требования к UIMS, критерии оценки

Множество требований, предъявляемых к UIMS, и критериев их оценки строится, исходя из основной эталонной модели UIMS (см. рис.1). Эта модель представляет систему в виде двух компонент: инструментария, используемого на стадии разработки диалога и части, относящейся ко времени исполнения (run-time portion). UIMS обычно предоставляет способ управлять последовательностью действий конечного пользователя. Структура диалога задается вне прикладной программы. Это даёт возможность разработчику (дизайнеру) диалога экспериментировать с диалоговой последовательностью без необходимости каждый раз заново компилировать всю прикладную программу.
В составе UIMS должен присутствовать инструментарий WYSIWIG для облегчения конструирования макетов экранов, структур меню и диалоговых последовательностей. Должно быть возможно использовать наработки (например, библиотеки интерфейсов, диалоговых структур), в последующих разработках. UIMS должна использовать для представления информации пользователю существующие графические библиотеки и администраторы оконных систем. Будучи задано определение диалога, оно преобразуется ("компилируется") в некий формат (описание диалога), которое может представлять собой как файл данных, так и код (исполнимый: машинный, либо на языке виртуальной машины). Впоследствии этот файл, будучи неким образом скомпонованный с прикладным кодом, должен будет породить работающую конечную систему.

Стадия разработки пользовательского интерфейса
Именно здесь принимается решения, как будет выглядеть конечный продукт. Это не строгое определение, но указание направления разработок. Приложение не должно накладывать жёстких ограничений ни на внешний вид интерфейса, ни на его идеологию; должно быть возможным реализовать в интерфейсе продукта любые идеи. Возможно ли экспериментирование с интерфейсом на ранних этапах?
Автоматический дизайн. Подразумевается возможность автоматического создания дизайна пользовательского интерфейса исходя из его описания. Первый черновой вариант такого дизайна должен быть приемлем в качестве исходного варианта (ввода, входных данных) других компонент (компонент следующих уровней доводки) UIMS. Путь от описания (спецификации) через прототип к конечному варианту должен быть хорошо определён и автоматизирован. Возможно использование автоматического инструмента дизайна для изготовления различных вариантов и форм интерфейса из одного и того же описания - управление вариациями может осуществляться либо через непосредственное манипулирование, либо через системы меню, либо на командной основе (через командную строку). Выбор варианта из полученного множества - за дизайнером.
Явная семантика. Семантика приложения может быть выражена в поведении (в терминах поведения) объектов и действий пользовательского интерфейса. Например, красный цвет ассоциируется с риском, а зелёный - с безопасностью. Такие ассоциативные связи могут быть выгодно использованы в интерфейсе. UIMS должна предоставлять возможность определять и по мере необходимости позже изменять подобные зависимости (отношения).

Критерии разработки
Это подмножество критериев охватывает те из них, которые могут быть полезными для разработки пользовательского интерфейса.
Требования. Желательно наличие инструментов, которые могли бы помочь дизайнеру интерфейса вникнуть в суть поставленной задачи, той которую призван решать (или помогать решать) конечный продукт. Эти инструменты могли бы помочь выработать модели данных и поведения пользователя при работе с ними. Содействие может оказываться при сборе информации (накапливании знаний) и управлении данными. Эти инструменты должны предоставлять средства для быстрого создания прототипа. Знания полученные на этапе выяснения требований должны использоваться для создания формального описания интерфейса. Это описание (спецификация) должно отражать требования. Повторное использование прототипа в конечной системе позволит сохранить (сэкономить) время и силы. Если требования изменятся, то частично изменится и спецификация, и поэтому возникает необходимость в средствах, которые позволили бы проследить путь от требований к спецификации, т.е. выяснить, как выходная спецификация зависит от каких- либо входных требований. Эти средства также можно использовать для проверки спецификации на предмет соответствия выдвигаемым требованиям.
Техника взаимодействия. UIMS должна поддерживать широкий диапазон приложений и пользователей. UIMS должна также поддерживать широкий диапазон стилей взаимодействия: как низкоуровневые, типа командной строки, так и высокого уровня, как, например, графическое манипулирование с лексической или семантической обратной связью, непосредственное манипулирование графическими объектами.
Далее мы будем использовать термин "графический ввод" для обозначения простого распознавания символов; "стандартное меню" - для меню, которое видно на экране всегда.

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

Взаимоотношение пользовательского интерфейса и прикладного кода
UIMS должна отделять прикладную часть программы от части пользовательского интерфейса: каждый раздел должен писаться отдельно. Управление системой может осуществляться как из интерфейсной части (посредством UIMS), так и из прикладной части.
Две модели. UIMS обычно состоит из двух основных модулей: препроцессора разработки и реализации пользовательского интерфейса и рабочей (run-time) среды, в которой и работает интерфейс пользователя.
Разделение пользовательского интерфейса прикладной части. UIMS должна отделять прикладную часть программы от интерфейсной. Должно быть возможно работать над этими частями раздельно.
Осуществляет ли управление UIMS или приложение? Управление системой может осуществлять либо UIMS - посредством управляющих действий со стороны интерфейсной части, либо прикладная часть. Приложение может запрашивать у пользователя ввод, либо же инициатива во взаимодействии принадлежит пользователю. Если управление принадлежит UIMS, то обычно она вызывает прикладные модули по мере необходимости в ответ на действия конечного пользователя. Такое управление можно назвать "внешним". Если управление всегда осуществляется из прикладной части, то такое управление можно назвать "внутренним". Третий вид управления - пользователь полностью управляет системой. Настоящая UIMS предоставляет средства для осуществления внешнего управления, в то время как инструментарий предоставляет средства только для создания системы с внутренним управлением.
UIMS должна допускать возможность ввода множеством разных способов. Пользователь может использовать только одно устройство ввода, а UIMS сама должна решать - которое именно (мышь или клавиатура). Пользователь может взаимодействовать со множеством устройств ввода, UIMS должна учитывать возможность такой ситуации и правильно её обрабатывать. Используемый метод зависит от того, как UIMS логически представляет ввод, а не от того, как он реализован.

Реализация
Инструменты. Этот раздел охватывает инструменты для разработки интерфейса. Эти инструменты дают возможность интерактивного построения пользовательского интерфейса. Возможен и, вероятно, более предпочтителен вариант, в котором дизайнеру вообще не надо писать программный код самому - необходимый для компоновки в окончательную систему код будет порождён автоматически. В этом случае дизайнер может изменять интерфейс, не меняя никакого кода, и приложение можно сразу же собирать с этим новым интерфейсом.
Правка на ходу (в приостановленном состоянии). Редактор интерфейса должен позволять приостанавливать работу интерфейса конечного пользователя, подправлять его параметры и спецификации, и запускать его работу дальше - с того момента, на котором его работа была ранее прервана.
Повторно используемые компоненты. UIMS может предоставлять инструменты для повышения повторной используемости программных компонент - цели весьма желательной. Она может запоминать определения и доставать (из своего хранилища) компоненты, которые можно использовать повторно. Должна иметься возможность задания семантики программных модулей, с тем чтобы дизайнер мог найти модуль с соответствующими функциями. Компоненты, допускающие многократное использование, повышают продуктивность (производительность) работы дизайнера; предоставляют возможность стандартизации и гарантию того, что все составные части интерфейса полностью проверены.
Препроцессор. Желательно, чтобы UIMS предоставляла возможность оттранслировать спецификацию диалога в программу на стандартном языке высокого уровня.
Сложность программирования. Использование таких возможностей, как интерактивный дизайн диалога и пробная работа, избавляют разработчика диалогов от необходимости формального программирования. Единственно необходимым остаётся только программирование прикладной части системы. Ясен пень, если прикладная часть создаётся отдельно и другим человеком, то дизайнеру интерфейса вообще не надо писать никаких программ. Эффективно интерфейс можно было бы создать полностью средствами UIMS.
Система может быть формально описана в терминах языка типа BNF или же конечных автоматов. Последняя модель, вероятно, более проста для понимания человека, не искушённого в программировании.
Автоматическое создание заглушек. UIMS должна автоматически создавать программные "заглушки" для отсутствующих процедур обработки событий. Система при обращении к такой несуществующей процедуре может, например, просто выводить на экран сообщение, что вызвана конкретная процедура.
Макроопределения. Макросы суть сокращённые записи кусков программного кода. Макроопределения раскрываются в полную свою форму препроцессором или непосредственно при исполнении программы. Макрос определяется в процедуре и хранится в библиотеке. Библиотеки макроопределений позволяют использовать их как строительные блоки для других приложений. Макросы могут использоваться в рекурсивной форме.
Уровень детализации описания. Как много деталей должен задавать в описании дизайнер? Можно ли заставить UIMS сконструировать интерфейс, предоставив ей только список операций и ничего более? Уровень детализации должен быть регулируемым, чтобы можно было, задав изначально общее описание и получив продукт в некоем виде, далее его довести до желаемого состояния, используя более высокий уровень детализации. Система должна допускать любой уровень детализации и предоставлять дизайнеру полную свободу выбора уровня, на котором он будет вести работу. На всех уровнях детализации должны быть заданы разумные умолчания, которые можно по мере необходимости изменять.

Выражения и типы
Этот раздел охватывает многообразие переменных и выражений доступных разработчику.
Типы, определяемые пользователем. Прикладной программист или дизайнер диалога должны иметь возможность пользоваться средствами языка программирования, на котором пишется система (например, "C"), для создания различных структур данных, например, записей событий.
Проверка допустимости значений. Проверка типа и допустимости значений облегчает обработку данных вводимых пользователем. Эту проверку может осуществлять либо UIMS, либо программный код дизайнера интерфейса. При обнаружении ошибки должно выводится сообщение о таковой или подсказка о необходимых свойствах ожидаемых данных.
Выражения. Выражения могут быть как арифметическими, так и частью диалога. Вычисляются ли значения выражений во время работы UIMS или конечной системы? Производятся ли вычисления прикладной частью или внешними программами, написанными на другом языке? Следует учитывать возможность использования графических объектов в качестве именованных переменных в вычислимых выражениях.
Умолчания. Если значение параметра пользователем не задано, система должна быть способна использовать значение по умолчанию, определённое разработчиком интерфейса.

Взаимодействие с устройствами
Этот раздел охватывает взаимодействие аппаратного и программного обеспечения системы на низком уровне. Затрагиваются вопросы программной эмуляции аппаратуры и использования мультимедиа.
Переносимость. Раз UIMS перенесена на некоторую аппаратную платформу, то и пользовательский интерфейс, и конечное приложение должны на ней работать.
Низкоуровневое управление. Иногда возникает необходимость управлять устройствами на низком уровне из контекста языков высокого уровня. В ОС UNIX разработчик должен был бы переделывать устройства в ядре, но это очень непросто сделать в UIMS. Возможно использование низкоуровневого управления, чтобы получить отклик, который соответствует используемой технике взаимодействия. UIMS должна быть достаточно мощной, чтобы было возможно описать полный спектр интерактивных методик, но качество взаимодействия будет зависеть от того, насколько низкого уровня управление графическими устройствами ввода-вывода может быть использовано в диалоговой системе. Поддержка UIMS такой деятельности может оказаться весьма полезной. Но необходимость в задании управления на таком уровне должна отсутствовать - дизайнер не должен об этом думать, если он того не хочет.
Конкурирующие потоки ввода-вывода. UIMS сама должна управлять конкурирующими потоками ввода-вывода различных устройств, с тем чтобы избавить от этой сложной задачи и дизайнера интерфейса, и прикладного программиста. Большинство языков программирования последовательны по природе, поэтому именно UIMS должна управлять вводом одновременно с разных устройств. Оказывается ли взаимодействие с пользователем блокированным во время производства системой вычислений? Пользователь всегда должен иметь возможность прервать вычисления и снова начать взаимодействовать с системой.
Редактирование ввода. Каждый диалоговый элемент (диалоговая единица, элементарный диалог), связанный с низкоуровневым вводом, должен предоставлять возможность отменить последний ввод. В диалоге на более высоком уровне должно быть возможно "удалить последний параметр", не вызывая этим никаких ошибок.
Мультимедиа. UIMS должна предоставлять возможность использовать широкий спектр устройств ввода-вывода, включая средства мультимедиа и виртуальной реальности. Должно быть также возможно добавлять в систему новые средства ввода-вывода. Интерсено в этой связи было бы задать такой вопрос: "Насколько сложно добавить в систему ввод голосом?".
Диалоговая последовательность. Допускает ли UIMS неограниченную свободу движения по диалогу? Диалог может быть "плоским" - так что большинство команд доступны во входной точке диалога. Как только выбор сделан, этот путь должен быть завершён прежде, чем пользователь вернётся ко входной точке. Диалог может быть:

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

Многооконные системы. UIMS может и не работать в среде многооконной системы, но вместо этого она может полностью управлять устройством вывода. Если UIMS не работает в многооконной среде, то сможет ли она обеспечить одновременную работу множества приложений? Даёт ли UIMS возможность использования в приложении многих окон? И если даёт, то допускает ли она одновременный ввод и вывод во всех окнах? UIMS ведь может и предоставлять только возможность ввода в одном окне и вывода - в другом. Если UIMS предоставляет приложению множество окон, то может ли приложение каким-либо образом получить информацию, в какое именно окно был произведён вывод.
X Window. Система X Window (или просто X), разработанная в MIT, заслужила неимоверно широкую популярность, особенно в сообществе UNIX. В X базовая оконная система предоставляет высокопроизводительную графику в иерархически организованное множество окон изменяемых размеров. Вместо конкретного пользовательского интерфейса X предоставляет набор примитивов, поддерживающих несколько стилей и придерживающихся некоторых идеологий. В отличие от большинства оконных систем базовая система в X определяется протоколом клиент-сервер: асинхронная потоковая (stream-based) межпроцессная связь замещает традиционный интерфейс, построенный на подпрограммных и системных ("ядерных") вызовах, предоставляя возможности использования распределённой графики.
Использование X Windows в UIMS резко повышает её аппаратную и программную переносимость.
Графика. Эта область связана с графическими возможностями UIMS. UIMS может оказаться способной использовать только свой собственный графический пакет, либо же она может быть достаточной гибкой, что её можно настроить на работу с любыми графическими стандартами. Это может быть очень важно, если приложение уже использует какой-либо графический стандарт, такой, например, как GKS, или требуется усовершенствовать систему и добавить в неё работу с PHIGS или PHIGS+. Важно знать, какую схему использует UIMS для задания точки на экране: система координат задаёт расстояния в пикселях или в физических единицах, и т.п. Перевод существующего приложения на новый стандарт или подстройка его под другой графический пакет может отнять много времени.
Многопользовательский диалог. Это метод предоставления возможности многим пользователям одновременно работать в распределённой вычислительной среде.

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

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

Стадия тестирования
Обратная трассировка. Было бы весьма полезен инструмент, который позволял бы проследить процесс создания продукта в обратном направлении, получить из конечного продукта его формальное описание в терминах входного языка. Это некая разновидность декомпиляции.
Производительность. Производительность системы - важный фактор, которым пренебрегать нельзя. Система может быть лёгкой в использовании, но оказаться слишком медленной, что сведёт всё удобство на нет.
Протоколирование ввода и воспроизведение "записи". Должна предоставляться возможность вести и записывать протокол взаимодействия пользователя с системой, с учётом всех происходящих в системе событий, проверкой корректности и регистрацией ошибок ввода, пауз, запросов помощи и т.п. Этот протокол должно быть возможно использовать для ввода в UIMS вместо реального ввода с устройств, с тем чтобы можно было воспроизвести сеанс работы, проанализировать его и полученные в его ходе данные, выявить в системе ошибки, слабые места и т.п. Всё это должно помочь дизайнеру улучшить интерфейс.
Автоматическая оценка качества и управлением им. UIMS должна предоставлять средства для проверки и оценки на всех стадиях разработки. Желательно наличие инструментов автоматической оценки качества интерфейса по различным критериям, таким как планировка экрана, последовательность, стилистичность, модель пользователя и использования устройств ввода. Эти инструменты могут предупредить о потенциальных проблемах. Если компания имеет свой стиль, предписывает при разработке интерфейсов руководствоваться какими-либо принципами, то такие инструменты могут проверить разработку на соответствие этим требованиям.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Четвёртый подход связан с принципом, называемом "Direct Manipulation" - DM, рассматриваемым в следующем разделе. Основное свойство этого подхода состоит в том, что пользователь взаимодействует с индивидуальными объектами, а не со всей системой как единым целым.
"Непосредственное манипулирование" (DM - Direct Manipulation)
Во многих отношениях технология непосредственного манипулирования рассматривается как новая генерация методов программирования в области проектирования интерфейса с пользователем, имеющих такое же значение как разработка языка четвёртого поколения для разработки баз данных. Начало этому подходу положили исследования, проводимые в центре Palo Alto корпорацией Xerox (Xerox PARC).
Что же такое непосредственность? Можно выделить четыре аспекта этого понятия:
Семантическая непосредственность. Определяется через "расстояние" между пользовательскими намерениями и операциями предоставляемыми системой. Пользователю важно, что:

в любое время он может передать свои намерения системе и
он может их выразить простым и кратким способом.

Для достижения этих целей необходимо, чтобы система предоставляла соответствующую функциональность, наряду с концептуальными объектами и операциями на уровне абстракции, удовлетворяющей пользователя. Эта проблема хорошо известна из области языков программирования высокого уровня - конструкции языка должны соответствовать проблемной области. Другими словами, семантическая непосредственность заключается в предоставлении пользователю возможности определять собственные классы графических объектов (что есть хорошо), соответствующих его прикладной задаче, а не заставлять его использовать (стандартные) базовые графические примитивы системы (что было бы плохо).
Операционная непосредственность. На уровне диалога можно рассматривать временной аспект непосредственности.
Диалоговая последовательность не обладает нужной непосредственностью, если пользователь хочет воспользоваться последовательностью действий, не предоставляемых системой. Например, выбор пиктограммы с помощью мыши и получение возможности тут же передвинуть её по экрану является реализацией непосредственности в операционном смысле, поскольку действие не подразделяется на дополнительные команды ввода (не надо нажимать клавишу "двигать").
Но не просто определить последовательность действий в намерениях пользователя. Большинство DM систем пытаются сделать все видимые объекты доступными способами инициируемыми пользователем и поддержать развитие последовательности действий непосредственной обратной связью на каждом шаге.
Формальная непосредственность. Этот аспект относится к естественности восприятия (немедленной, непосредственной понимаемости) системного вывода, простоте и эффективности обработки элементов ввода и устройств (клавиатура, кнопки, работа с мышью и т.п). Увеличению степени формальной непосредственности может способствовать использование представления в виде пиктограмм при выборе объектов и функций вместо символических имён команд, хорошо структурированный экран и понятное обозначение функциональных клавиш. Ещё одним важным требованием является использование принципа "Что вы видите - то и получите" (WYSIWYG - What You See Is What You Get), в соответствии с которым на экране формируется именно то изображение, которое будет получено при конечной выдаче.
Компоненты DM интерфейса. На верхнем уровне DM систем обычно находится одна из метафор графического представления (типа метафоры письменного стола, конкретный объект). Через этот верхний уровень пользователю доступны прикладные программы, работающие на окнах. В окнах, подокнах и компонентах экрана доступны различные средства выбора объектов, функций инициирования и управления. Типичными компонентами используемыми для манипуляций с объектами и управляющими функциями являются:

Обработчики (Handlers): средства управления непосредственно связанные с объектами, определяемыми прикладной программой. Обычно проявляются после выбора объекта и могут быть "захвачены" с помощью мыши для выполнения самых разнообразных манипуляций типа перемещения, изменения размеров, вращения и т.п.
Управления (Controls): элементарные средства инициации функций или ввода параметров. Например, Motif предоставляет следующие типы управления: >
кнопки различного вида (простые, радио, контрольные); >
зоны (boxes) вывода, ввода, форматного ввода; >
валюаторы (шкалы, . . .).
Меню: рассматриваемые как совокупность элементарных управлений с типовой организацией (в Open Look меню есть просто набор кнопок). Наиболее часто используемые типы меню: "выпадающие" (pull-down), "выпрыгивающие" (pop-up) и каскадные.
Зоны диалога (Dialog boxes): для выдачи сообщений или ввода подтверждения.

Другие компоненты DM интерфейса связаны с представлением информации, например, икон, которые могут быть, а могут и не быть связаны с определённым поведением. Чаще всего их поведение подобно кнопкам или представляет специфическое поведение объектов "письменного стола".

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

Требования к конструированию DM интерфейсов:

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

Пример реализации UIDS/UIMS

В заключении приведём в качестве примера описание системы UIMS XFaceMaker3 фирмы Non Standard Logics, созданной на базе OSF/Motif и X Window System.

Проектирование интерфейса. Пользователь создает интерфейс в интерактивном режиме, используя предопределённые элементы - заготовки (Widgets).
Спецификация ресурсов. Реализует простую установку параметров(ресурсов) для заготовок. Многообразие ресурсов заготовок и их взаимодействия делает задачу установки параметров чрезвычайно сложной. XFM3 везде, где это возможно, предоставляет предопределенную установку соответствующего выбора, в частности в зонах диалога.
Спецификация поведения интерфейса. Описывается на С-подобном командном языке (Face). Динамика поведения интерфейса трактуется XFM3 как целостная часть вместе с геометрическим представлением.
Простая и естественная связь между интерфейсом и прикладной задачей. Реализована двумя способами: вызовом функции прикладной задачи из описания
- или с помощью разделяемых переменных (активных значений);
- разделяемые переменные могут быть любого типа.
Таким образом возможна связь с прикладной задачей через указатель на заготовку в интерфейсе.
Непосредственное и полное тестирование интерфейса и его поведения (так называемый режим попытки (try mode). В этом режиме интерпретируется описание связанное с какими-либо событиями, но без вызова функций прикладной задачи.
Эффективность конечного приложения. Результат проектирования реализуется двумя способами: либо интерпретацией описания, аналогично режиму TRY, либо компиляцией интерфейса вместе со всеми описаниями в С код.

Выведение

Ситуация в области разработки систем построения и управления интерфейсом пользователя в наши дни напоминает ситуацию с графикой до выработки международных стандартов: нет единой терминологии, есть разные подходы к построению моделей (лингвистический, графический), которые часто пересекаются.
Анализ разработок в области UIMS позволяет представить соотношение между различными компонентами в виде слойной структуры, напоминающей структуру OSI (рис. 2). При реализации конкретной прикладной задачи необходимый уровень UIMS и набор компонент может определяться из соображений требуемой эффективности и доступных ресурсов.

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

Имеется несколько открытых проблем в разработке UIMS, которые можно определить как:

эргономика взаимодействия;
управление диалогом;
отделение интерфейса пользователя;
сопровождение, мобильность и эффективность.

Пока не существует единственной стратегии конструирования UIMS. Нужны эксперименты и опыт. Сфера быстро развивающаяся, сулящая многочисленные выгоды.
Появившиеся стандарты (пока де-факто), по крайней мере на нижних уровнях систем (X-Window и, в какой-то степени OSF/Motif), и активность разработчиков многих фирм дают надежду, что ситуация в ближайшее время может измениться к лучшему.
Перспективы в области разработки человеко-машинных интерфейсов в настоящее время связаны, главным образом, с такими направлениями развития новых информационных технологий, как:

системы мультимедиа;
экспертные системы;
системы виртуальной реальности;
вездесущие системы (ubiquitous);
. . .

Наиболее интересными и фантастическими являются вездесущие системы.
Исследованиями и разработками таких систем занимаются в ведущих центрах по изучению человеко-машинного интерфейса, в частности, в Xerox PARC. Фундаментальные концепции вездесущих систем были рассмотрены на конференции Еврографика'90 в приглашённом докладе У.Ньюмана (Rank Xerox EuroPARC).
Под термином "вездесущие системы" в настоящее время понимаются такие системы, которые включают в себя огромное количество миниатюрных, но достаточно мощных вычислительных устройств, повсюду окружающих человека: прикреплённых к документам, встроенных в окружающую мебель и т.п. Интегрируя такие системы с цифровым звуком и видео, можно получить очень мощные средства, например, для персональной автобиографической памяти.
Последние достижения в области вездесущих систем оказывают большое влияние на проектирование и разработку интерактивных систем. В таких системах большое количество информации проходит без человеческого вмешательства: основной результат проектирования может обеспечить пользователю адекватную концептуальную модель поведения системы, а не поддержку традиционного взаимодействия с использованием экрана.

[Назад] [Содержание] [Вперед]