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

Размещено на http://www.allbest.ru/

Орловский государственный технический университет

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

Гордиенко А.П.

Приступая к проектированию графического пользовательского интерфейса (ГПИ), разработчик сразу сталкивается с большим спектром задач: от разработки принципов визуального взаимодействия человека с компьютером, до реализации алгоритмов. Если считать пользовательский интерфейс виртуальным миром, с которым пользователь может взаимодействовать интуитивно понятными ему способами, то этот компьютерный мир должен быть похожим на реальный мир, и, как мы уже писали в работе [1], должен строиться на принципах онтологии - науки, изучающей существование вещей в мире. Таким образом, первая задача, возникающая при проектировании ГПИ - разработка принципов структурирования и поведения визуального компьютерного мира. Вторая задача - разработка методов реализации ГПИ. В этом направлении уже есть ряд важных решений, включающих в себя метамодель Arch [2], архитектуры MVC [3] и PAС [4]. Обзор этих решений дан в статье [5]. Он позволил, учитывая собственный опыт построения интерактивных графических систем, разработать структуру ГПИ в виде иерархии интеракторов. Есть несколько определений интеракторов. В работе [6] читаем: «Интерактор - это компонента интерактивной системы, способная реагировать на внешние стимулы; она способна вводить и выводить данные и передавать их вверх и вниз по уровням абстракции». Таким образом, интерактор - это концептуализация программной компоненты, осуществляющей обмен информацией между пользователем и функциональным ядром. В работе [7] понятие интерактора уточняется: интерактор имеет локальное состояние, способен участвовать в событиях окружения и вследствие этого менять свое состояние. В этом отношении интеракторы похожи на процессы с состояниями, описанные в работе [8]. Но отличительной чертой интерактора является то, что он доступен пользователю для взаимодействия. Использование интеракторов позволяет объединить два взгляда на разработку интерактивной системы: со стороны пользователя и со стороны функционального ядра. С точки зрения функционального ядра, интерактор - это элемент ГПИ, ответственный за ввод-вывод. С точки зрения пользователя, интерактор - это посредник между ним и функциональными возможностями системы. Он отражает взаимодействие между двумя сторонами и, таким образом, является формальной основой для исследования свойств диалога. Для этого необходимы абстрактные модели интеракторов, инкапсулирующие внутреннюю структуру и наиболее полно отражающие его внешнее поведение. Нами разработана структура ГПИ, показанная на рисунке 1 в виде диаграммы компонентов. В качестве системы обозначений был использован унифицированный язык моделирования UML [9].

Структура ГПИ

Модель мира, с которой взаимодействует пользователь, хранится в объектно-ориентированной базе данных, которая в терминах метамодели Arch является функциональным ядром. Концептуальная схема базы данных отражает классы объектов, с которыми может работать пользователь. Для графического редактора основу этих объектов составляют геометрические примитивы: линии, дуги, кривые, контуры, поверхности и так далее. Классы организованы в иерархическую структуру отношением обобщения. Классы могут агрегироваться на основе ассоциации «часть-целое». Например, контур - это агрегация линий. В базе данных хранится и информация о геометрических соотношениях между объектами. Они реализуются на основе ограничений целостности. Если, например, между отрезками прямых задано соотношение параллельности, то при изменении одного из отрезков другой отрезок должен измениться так, чтобы данное соотношение не нарушалось. База данных - активная: она содержит набор триггеров и правил вывода, реагирующих на заносимые данные. Если будет обнаружена ошибка - нарушение какого-либо закона визуального мира, то она выдаст соответствующее сообщение. На основе правил вывода можно делать и предположения о возможных геометрических соотношениях заносимого в базу данных объекта с уже существующими. Тогда система будет предлагать пользователю возможные варианты таких соотношений, которые по желанию пользователя будут заноситься в базу данных в виде ограничений целостности.

Функциональное ядро обеспечивает два интерфейса: один для чтения прикладных данных, а второй - для модификации. Интерфейсы в языке UML обозначаются маленькими поименованными кружками. Сплошная линия, связывающая компонент с интерфейсом указывает, что первый обеспечивает второй. Адаптер функционального ядра является связующим звеном между функциональным ядром и пользовательским интерфейсом. Он через интерфейсы к функциональному ядру осуществляет доступ к базе прикладных данных. Возможность доступа к интерфейсу обозначается пунктирной стрелкой. Адаптер функционального ядра может быть интерпретатором запросов к базе данных, а в более простом случае - интерфейсом к модулю объектов, реализованных на языках C++ или Object Pascal.

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

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

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

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

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

Рисунок 1 - Структура ГПИ

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

Блок управления получает поток внутренних событий от подчиненных интеракторов и формирует контекст диалога: информацию о текущем состоянии объектного представления. Помимо этого он из последовательности событий выделяет (абстрагирует) прикладные команды и передает их адаптеру функционального ядра. Блок управления является отдельной задачей, выполняющейся параллельно с другими интеракторами и функциональным ядром. Синхронизация между ними осуществляется через общие события. Логика диалога определяется выражениями поведения, написанными на языке CSP [10] с использованием операторов, описанных в [5]. Каждой фазе диалога соответствует некоторое выражение поведения B, определяющее множество переходов B B', которые выводятся из него на основе аксиом и правил вывода, описанных в [5]. Для этого выражения можно определить функцию menu, задающую множество событий, в которых может участвовать модуль управления диалогом:

Menu (B) = { e B'. B B'}.

Множество menu(B) определяет контекст диалога в состоянии B - то есть множество интеракторов, активных в данной фазе диалога, и параметры их настройки. Если в текущее меню входит событие функционального ядра, определяющее запрос к базе данных, то оно выполняется в первую очередь. Если таких событий нет, то модуль управления диалогом будет ждать событие от интеракторов. В любом случае, при наступлении события происходит изменение текущего выражения поведения. Для этого должна быть реализована функция next:

Next (B, e) = B', если B B'.

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

1. Разработать формальную модель интеракторов и методов их стыковки.

2. Разработать язык для описания поведения совокупности интеракторов.

3. Разработать методы проектирования пользовательского интерфейса на основе интеракторов.

Структура интерактора

Если сопоставить две наиболее перспективные на наш взгляд модели интеракторов ADC [11] и FUDGETS [12], то, не смотря на различие подходов к их реализации, можно заметить между ними много общего, и это общее положить в основу разработки нового интерактора. Блок управления интерактора ADC соответствует обработчику потоков интерактора FUDGETS. Обе эти компоненты определяют поведение интерактора. Также соответствуют друг другу блок абстракции и изображения и визуальная компонента: они выполняют функции визуализации и предварительной обработки внешних событий. Обе модели интеракторов, как ADC так и FUDGETS, предполагают иерархическую организацию пользовательского интерфейса. На самом нижнем уровне располагаются конкретные визуальные интеракторы, выполняющие стандартные функции ввода-вывода. Они образуют набор интерактивных методов, которые можно собрать в общий инструментарий - toolkit. Выше по уровню иерархии располагаются более абстрактные прикладные интеракторы: их основная функция - управление подчиненными интеракторами; их поведение в большей степени зависит от прикладной области, а не от метода взаимодействия с пользователем; они являются контейнерами, содержащими подчиненные интеракторы и определяющими геометрические соотношения между ними. Таким образом все множество интеракторов можно разделить на две категории: интерактивный графическоий пользовательский интерфейс

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

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

управление логикой диалога, объединение подчиненных интеракторов, поддержка геометрических соотношений между своими компонентами.

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

На основе изложенных выше положений нами разработана структура интерактора, которая изображена на рисунке 2 в виде диаграммы кооперации языка UML. Интерактор состоит из двух основных частей: блока управления и блока объектного представления. Между ними установлена связь «один к одному». Блок управления определяет логику диалога и является совокупностью управляющих структур, представляющих собой выражения поведения. Объектное представление - это совокупность объектов, определяющих визуальное представление интерактора. Объектное представление может быть примитивным и сложным, что на схеме показано в виде классификации с родовидовыми связями. Сложные объекты являются агрегациями более простых объектов. На схеме агрегация показана в виде ромбика у класса - агрегата. Агрегация, как связь часть-целое, вместе с обобщением от сложного объекта к абстрактному, формирует рекурсивную структуру - иерархию интеракторов.

Рассмотрим теперь операции, выполняемые интерактором. Внешнее событие от устройства ввода в виде сообщения 1:input передается объектному представлению корневого интерактора. Получив это сообщение объект определяет находится ли в зоне его чувствительности курсор устройства ввода. Если находится и данный интерактор содержит подчиненные интеракторы, то им всем рассылаются аналогичные сообщения (2:input). Таким образом происходит рекурсивный спуск в глубину дерева интеракторов. Когда будет найден указанный пользователем примитивный интерактор, то его идентификатор будет передан блоку управления сообщением 3:pick(pid). Если такого интерактора найти не удастся, то корневой интерактор передаст блоку управления сообщение 4:locator(X,Y), указывающее, что была введена позиция.

Блок управления, получив сообщение 4:locator(X,Y) или 3:pick(pid), применяет к нему текущее выражение поведения и формирует новое, выполнив функцию next, определенную в параграфе 2.2. Затем вызовом функции menue вычисляется меню нового процесса. После этого возможны два варианта в работе блока управления.

Если в полученном меню встречается событие - прикладная команда, то эта команда в виде сообщения 5:fc_call(args) передается адаптеру функционального ядра. После этого блок управления может получить семантическую обратную связь в виде сообщения 6:fc_os(args) и обработать его аналогично сообщениям 4:locator(X,Y) и 3:pick(pid).

Рисунок 2 - Диаграмма кооперации объектов интерактора

Если в меню нет событий - сообщений функциональному ядру, то каждому событию из меню ставится в соответствие его визуальное представление с возможными вариантами локального поведения. Для этого объектному представлению передается сообщение 7:context(args), набор аргументов args которого определяет состояния подчиненных интеракторов, их геометрические соотношения и чувствительность к указыванию. В процессе установки этих состояний - контекста объектное представление может передавать запросы адаптеру функционального ядра в виде сообщения 8:query и получать графические данные из сообщения 9:gr_data. При изменении контекста интеракторов происходит и изменение их изображения на экране (сообщения 10:displ).

Заключение

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

Упрощается метод построения ГПИ, основанного на метафоре модели мира.

Появляется возможность разработки формальных спецификаций ГПИ.

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

Литература

1. Гоpдиенко А.П. Онтологическая модель визуального пользовательского интерфейса// Человеческий фактор в правоохранительных системах.- Орел: Высшая школа МВД РФ, 1996. С. 302-303.

2. Bass L., Coutaz J., Unger C. A reference model for interactive system construction.// EWHCI'92. - 1992. - , St. Petersburg, P. 23-30.

3. Krasner G.E., Pope S.T. A Cookbook For Using the Model-View-Controller User Interface Paradigm in The Smalltalk-80 System, Journal of Object Oriented Programming. - 1988, Vol.1, P. 26-49.

4. Coutaz J. PAC, an Object Oriented Model for Dialog Design. //INTERACT'87 Conference Proceedings. Elsevier (North-Holland).- 1987.- P. 431-436.

5. Гордиенко А.П. Модели графического пользовательского интерфейса // Вестник МЭИ.- 2003.- N 2.- С. 83-90.

6. Faconti G.P. Towards the Concept of Interactor/ AMODEUS project report. Esprit Basic Research 7040. Amodeus Project Document, system modelling/WP8. 1993.

7. Duke D.J., Harrison M.D. Abstract Interaction Objects // Computer Graphics Forum. 1993.- Vol. 12.- N 3.- P. 26-36.

8. Sufrin B., He J. Specification analysis and refinement of interactive processes // Formal Methods in Human Computer Interaction, Cambridge University Press, 1990.- P. 153-200.

9. Рамбо Дж., Якобсон А., Буч Г. UML: специальный справочник.- СПб.: Питер, 2002.- 656 С.

10. Хоар Ч. Взаимодействующие последовательные процессы.- М: Мир, 1989.- 264 c.

11. Markopoulos P., Johnson P., Rowson J. Formal architectural abstractions for interactive software // Journal of Human Computer Studies. 1998.- Vol. 49.- N 5.- P. 675-715.

12. Carlsson M., Hallgren T. Fudgets - A Graphical User Interface in a Lazy Functional Language // FPCA '93 - Conference on Functional Programming Languages and Computer Architecture. ACM Press, 1993.- P. 321-330.

Размещено на Allbest.ru