Формирование модели интерактора как универсального логического устройства ввода

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

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

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

Формирование модели интерактора как универсального логического устройства ввода

Гордиенко А.П., к.т.н., доцент



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

Abstract

Analysis of the standard logical input devices for graphical user interfaces (GUI) shows, that they can be unified into more abstract objects called interactors. According to the object - oriented approach interactor is implemented as abstract class, which can be specialized by the regulation functions. Collection of such functions is a framework for declarative description of the GUI.



Введение

Под влиянием объектно-ориентированного подхода графический пользовательский интерфейс (ГПИ) теперь чаще всего строят как совокупность типовых объектов - интеракторов. В общем виде интеракторы можно определить как компоненты интерактивной графической системы, выполняющие ввод и вывод информации и представляющие собой единое целое. Приведем и другие определения интеракторов. В [1] читаем: «Интерактор - это компонента интерактивной системы, способная реагировать на внешние стимулы; она способна вводить и выводить данные и передавать их вверх и вниз по уровням абстракции». Таким образом, интерактор - это концептуализация программной компоненты, осуществляющей обмен информацией между пользователем и функциональным ядром.

В [2] понятии интерактора уточняется: интерактор имеет локальное состояние, способен участвовать в событиях окружения и, вследствие этого, менять свое состояние. В этом отношении интеракторы похожи на процессы с состояниями, описанными [3], но их отличительная черта - доступность пользователю для взаимодействия.

К настоящему времени уже разработан ряд моделей интеракторов, анализ которых дан нами в [4]. Рассматривая эти модели, можно заметить, что существуют два основных взгляда на интерактор: как на формальную основу ГПИ и как на обобщенное графическое устройство ввода - вывода. Во втором случае появляется возможность проследить этапы формирования структуры и поведения интерактора, начиная со стандартных логических устройств ввода (ЛУВ), определенных в стандарте GKS [5]. Этому и посвящена настоящая статья.



Классы и режимы работы ЛУВ

Наиболее распространёнными классами ЛУВ, определенными в международных стандартах [5,6], являются LOCATOR, STROKE, PICK, VALUATOR, CHOICE, STRING. Они выполняют следующие функции:

· LOCATOR (ввод позиции) - выдает координаты точки, соответствующие позиции, в которую оператор установил устройство ввода;

· STROKE (ввод последовательности позиций) - выдает последовательность точек, соответствующую последовательности позиций, в которые оператор устанавливал устройство ввода;

· PICK (указание объекта) - выдает имя структуры и идентификатор указания в соответствии с тем, какую часть изображения выбрал оператор;

· VALUATOR (ввод числа) - выдает вещественное число, соответствующее положению движка на полосе прокрутки или какой-либо иной шкале;

· CHOICE (выбор альтернативы) - выдает неотрицательное целое число, соответствующее выбору из некоторого числа возможностей;

· STRING (ввод строки) - выдает массив символов (строку), введённый с пригодного для этой цели устройства, чаще всего с клавиатуры.

В графическом редакторе основную роль играют первые три класса устройств, так как остальные можно получить, использовав стандартные визуальные компоненты Windows, такие как меню, кнопки, полосы прокрутки и строки для редактирования. Поэтому мы остановимся только на трех классах LOCATOR, STROKE и PICK.

Стандарт GKS определяет ЛУВ как совокупность шести процессов: измерение, триггер, подсказка, эхо, подтверждение и управление. Процесс измерение отслеживает текущее состояние физического устройства ввода (для мыши это координаты X,Y), изменяемое действиями оператора. Процесс триггер некоторые изменения состояния физического устройства ввода интерпретирует как сигнал о необходимости передачи измеренного значения в направлении функционального ядра (прикладной программы). Процесс подсказки выводит на экран изображение, показывающее пользователю, что ЛУВ готово к работе. Процесс эхо отображает на экране текущее значение измеряемой величины, например, в форме курсора. Процесс подтверждение служит для информирования оператора о срабатывании триггера. Процесс управления управляет работой всех перечисленных выше процессов. Структура взаимодействия этих процессов показании на рисунке 1.

Рисунок 1 - Структура взаимодействия процессов ЛУВ

Каждое ЛУВ может работать в трех режимах:

· Запрос - когда ввод данных осуществляется по запросу со стороны приложения. Выдав запрос, приложение останавливает свою работу и ждет ввода со стороны требуемого ЛУВ. Остальные ЛУВ приостанавливают свою работу.

· Опрос - когда происходит опрос текущего состояния ЛУВ без передачи приложением управления к ЛУВ.

· Событие - когда сразу несколько ЛУВ могут быть активными. Их срабатывания асинхронно заносятся в очередь, из которой модуль логики диалога читает события.



Представление ЛУВ совокупностью взаимодействующих процессов

В работе [7] ЛУВ строятся как совокупность определенных на языке CSP [8] параллельных процессов: M - измерение, T - триггер, E - эхо, LID - процесс, управляющий всем ЛУВ-ом в целом. В этой модели оператор представлен процессом OP, который задает новое измеряемое значение и запускает триггер. Процесс OP реализует недетерминированный выбор между процессами P и Q:

OP = P П Q,

это значит, что процесс OP ведет себя как процесс P или как процесс Q. Оператор

П_x:S P(x),

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



Рассмотрим работу ЛУВ в различных режимах. Схема взаимодействия процессов в режиме «запрос» показана на рисунке 2. В этом режиме оператор может установить новое измеряемое значение или заставить сработать триггер. В первом случае процесс продолжит работу, а во втором - станет неактивным. Процесс «оператор» - это недетерминированный выбор вида:

OP =(П_v:V m!v ->OP) П (trigger ->STOP_бOP),

где бOP - алфавит процесса OP.

Процесс «измерение» - M описывается выражением:

M(v) = (m?v -> e!v' -> M(v'))

| (trigger -> si!v -> STOP_бM).

Он имеет состояние v и может получить его новое значение v' по каналу m, затем передать его по каналу e для изменения положения курсора и далее считать v' новым состоянием. В случае срабатывания триггера в физическом устройстве ввода, процесс M участвует в событии trigger, передает свое состояние по каналу si и становится неактивным.

Процесс «триггер» - T после участия в событии trigger становится неактивным:

T = trigger -> STOP_бT.

Процесс «эхо» - E имеет состояние - текущее положение курсора и при получении по каналу e нового положения - меняет свое состояние и перемещает положение курсора:

E(v) = (e?v' -> E(v')).

Процесс «управление» - LID получает от прикладной программы событие read, являющееся запросом на чтение данных, затем, когда сработает триггер, получает по каналу si измеренное значение v, после передает его по каналу o и становится неактивным:

LID = read -> si?v -> o!v -> STOP_бLID.

Работа ЛУВ в режиме «опрос» отличается тем, что для выдачи выходного события ему не нужно ждать срабатывания триггера. Схема взаимодействия процессов теперь имеет вид, показанный на рисунке 3. Процесс «оператор» - это недетерминированный выбор вида:

OP = (П_v:V m!v -> OP),

он генерирует последовательность измеренных значений и не использует триггер.

Процесс «измерение» в этом режиме работает циклически:



M(v) = (m?v -> e!v' -> M(v'))

| (sample -> si!v -> M(v)),

по внешнему событию sample передавая по каналу si состояние v (измеренное значение). В этом режиме процесс «триггер» не используется, а процесс «эхо» используется без изменений. Процесс «управление» - LID также работает циклически: получает от прикладной программы событие sample - сигнал опроса, затем получает по каналу si измеренное значение v и после передает его по каналу o:

LID = sample -> si?v -> o!v -> LID.

Отметим, что просто переименовав в процессе M событие si в o, можно совсем отказаться от процесса LID.

Если ЛУВ работает в режиме «Событие», то к нему добавляется еще процесс S - память, представляющий собой очередь сгенерированных событий. Схема взаимодействия процессов теперь примет вид, показанный на рисунке 4.

Процесс «память» - S управляет очередью событий, исходящих из ЛУВ, работающих в режиме «событие». Он описывается двумя уравнениями:

(1) S(s:q) = (await_event -> o!s -> S(q))

| (trigger -> so?s' -> S(s:q ++ [s'])

(2) S([]) = (await_event ->

((time_out -> o!NONE -> S([]))

| (trigger -> so?v -> o!v -> S([])))

| (trigger -> so?v -> S([v]))



Процесс S имеет состояние - список событий. Уравнение (1) соответствует случаю, когда очередь не пуста, то есть список имеет голову s и хвост q. Если наступит событие await_event - запрос на чтение знака из ЛУВ, то по каналу o будет передан стоящий первым в очереди знак s, и далее процесс S будет иметь состояние q - хвост очереди. Уравнение (2) соответствует случаю, когда очередь пуста. Тогда при наступлении события await_event, если придет событие time_out, то по каналу o будет передан сигнал NONE - нет ввода, а если успеет прийти событие trigger, то по каналу si поступит введенное значение v, которое будет передано по каналу o. В обоих случаях процесс S продолжит свою работу с пустой очередью. Если триггер сработает до наступления события await_event, то полученный по каналу so знак будет занесен в очередь.

Процесс «оператор» циклически и недетерминировано генерирует события, передающие измененные значения измеряемой величины по каналу m и срабатывания триггера:

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

OP =(П_v:V m!v ->OP) П (trigger -> OP).

Процесс «измерение» такой же, как и в режиме «опрос», только выдача значения по каналу «si» запускается по триггеру:

M(v) = (m?v' -> e!v' -> M(v'))

| (trigger -> si!v -> M(v)).

Процесс «триггер» циклически участвует в событии «trigger»:

T = (trigger -> T).

Процесс «эхо» не меняется:

E(v) = (e?v' -> E(v')).

Процесс «управление» такой же, как и в режиме «опрос», только запускается он по событию «trigger»:

LID = trigger -> si?v -> o!v -> LID.

Рассмотренные нами схемы ЛУВ подходят для построения ГПИ как с внутренним, так и с внешним управлением. В [9] отмечалось, что управление пользовательским интерфейсом может быть двух типов: с инициативой от программы и с инициативой от пользователя. В первом случае программа, выполняя свои вычисления, периодически обращается через ЛУВ к пользователю для получения необходимых данных. Пользователь оказывается в подчиненном положении по отношению к программе. В этом случае ЛУВ работает в режиме «запрос».

Во втором случае инициатива исходит от пользователя, ему дана возможность работы сразу с несколькими ЛУВ, работающими параллельно в режиме «событие». Теперь программа подчинена пользователю, который своими действиями может управлять логикой ее выполнения. Конечно, второй подход предпочтительнее и большинство современных программ так и работают. Следовательно, для построения ГПИ с внешним управлением потребуются ЛУВ, работающие в режимах «опрос» и «событие». Но даже если в какой-то момент программе понадобится ввести данные с какого-либо конкретного ЛУВ, то она сможет это сделать, оставив активным только одно ЛУВ, работающее в режиме «событие».

Теперь рассмотрим отличия в схемах ЛУВ для режимов «опрос» и «событие». Во-первых, в режиме «событие» прикладная программа читает введенное значение из очереди, а в режиме «опрос» - непосредственно из процесса измерения M. Во-вторых, в режиме «событие» сигнал от ЛУВ выдается по триггеру, а в режиме «опрос» - триггер не используется.

Для унификации этих двух режимов сформулируем назначение каждого из них. Режим «событие» используется, когда ЛУВ способно обеспечить необходимое для работы эхо. В противном случае используется режим «опрос», и для каждого измеренного значения прикладная программа сама выводит эхо. Следовательно, если предположить, что очередь на выходе ЛУВ, работающего в режиме «событие», освобождается быстрее, чем заполняется, то и в режиме «опрос» выходные сигналы можно направлять в очередь. Тогда событие sample будет использоваться только процессом «измерение». Новая схема ЛУВ, работающего как в режиме «событие», так и в режиме «опрос», показана на рисунке 5.



Поведение процесса измерения будет определяться выражением:

M(v) = (m?v' -> e!v' -> M(v'))

| (trigger -> M'(v))

| (sample -> M'(v)),

где процесс M'(v) определяется выражением:

M'(v) = si!v -> M(v).

Построение иерархий ЛУВ

Для построения более сложных ЛУВ на основе более простых, рассмотренных нами выше, авторы анализируемой нами работы [7] предложили организовывать ЛУВ в иерархии. Так, для построения устройства класса «STROKE» предлагалось использовать два простых устройства. У них процесс измерения устройства верхнего уровня получает входные значения с выхода устройства нижнего уровня, как показано на рисунке 6. Теперь оператор может изменять значения, измеряемые устройством нижнего уровня, и запускать триггеры обоих устройств.

По такой схеме можно построить ЛУВ класса STROKE, как показано на рисунке 7. Его нижний уровень составляет описанное ранее ЛУВ класса LOCATOR, а верхний - устройство ввода последовательности позиций STROKE. Рассмотрим процессы этого ЛУВ. Оператор циклически делает выбор: либо изменяет измеряемое значение, либо запускает триггер устройства ввода позиции, либо запускает триггер устройства ввода последовательности позиций:

OP = om!m -> OP

| loctrigger -> OP

| stroketrigger -> OP

Рассмотрим процессы ЛУВ нижнего уровня. Его процесс «измерение» определяется следующим выражением:

MLOC(v) = om?v' -> el!v' -> MLOC(v')

| loctrigger -> ml!v -> MLOC(v).

Это процесс с состоянием v, отражающим текущее измеренное значение. Он получает от оператора новое значение по каналу om, измеряет его, передает его процессу «эхо» по каналу el и продолжает работу с новым состоянием. Если сработает триггер нижнего уровня loctrigger, то процесс MLOC передаст по каналу ml текущее измеренное значение и продолжит работу с этим состоянием.

Процесс «триггер» принимает от оператора сигнал о срабатывании триггера нижнего уровня:

TLOC = (loctrigger -> TLOC).

Процесс «эхо» получает от процесса MLOC измеренное значение по каналу el и выводит для него на экран эхо:

ELOC(v) = el?v' -> ELOC(v').

Процесс «управление» - LOCATOR, получив сигнал о срабатывании триггера loctrigger, принимает измеренное значение по каналу ml и передает его по каналу lm:

LOCATOR = loctrigger -> ml?v -> lm!v -> LOCATOR.



Рассмотрим теперь процессы ЛУВ верхнего уровня, относящиеся собственно к устройству класса STROKE. Его процесс «измерение» имеет состояние - список уже введенных позиций и определяется следующим выражением:

MSTROKE(s) = lm?v' -> let s' = s++[v']

in (es!s' -> MSTROKE(s')

| stroketrigger -> ms!s -> MSTROKE([]).

Этот процесс, получив по каналу lm введенное устройством нижнего уровня значение, записывает его в конец списка - своего состояния, затем по каналу es передает для отображения эха и продолжает работу с новым состоянием. Если сработал триггер верхнего уровня stroketrigger, то введенная последовательность позиций передается по каналу ms, и далее процесс продолжает свою работу, имея состояние - пустую последовательность. Остальные процессы устройства класса STROKE определяются аналогично процессам устройства класса LOCATOR:

Процесс «триггер»:

TSTROKE = (stroketrigger -> TSTROKE).

Процесс «эхо»:

ESTROKE(v) = el?v' -> ESTROKE (v').

Процесс «управление»:

STROKE = stroketrigger -> ml?v -> lm!v -> STROKE.

В качестве недостатка такой схемы отметим, что нет необходимости процессам STROKE и MSTROKE синхронизироваться по событию stroketrigger (и соответственно процессам LOCATOR и MLOC по событию loctrigger). Они уже синхронизируются по событию ms (соответственно ml). Но все-таки основными недостатками рассмотренных нами схем построения ЛУВ являются следующие:

1. В них не учитываются процессы «подсказка» и «подтверждение», обеспечивающие удобство работы пользователя.

2. Они не обеспечивают работу устройства класса PICK.

3. Они недостаточно универсальны.

Для построения схемы ЛУВ, свободной от перечисленных выше недостатков, нужно решить две задачи:

1. Обеспечить возможность хранения внутри ЛУВ его визуальных представлений.

2. Объединить в одной схеме ЛУВ возможности трех классов устройств: LOCATOR, STROKE и PICK.

Рассмотрим возможные пути решения этих задач.

Структура сегментов

Для решения первой задачи нужно ввести в состав ЛУВ память сегментов, хранящую структурированные последовательности графических примитивов, атрибутов и геометрических соотношений. Прототипом их являются структуры графического стандарта PHIGS [6]. Включение в состав ЛУВ структуры сегментов обусловлено тем, что в процессе работы интерактивной графической системы одну и ту же графическую информацию приходится выводить многократно. Поэтому её лучше один раз представить в удобном для вывода виде, а затем по необходимости передавать её устройству вывода. Более того, формат структуры сегментов должен быть удобен для поиска указываемых пользователем объектов, когда ЛУВ принадлежит классу PICK.

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

Segment::= SegmentID (Primitive | Attribute | PickId | Segment)

Primitive::= Marker | Line | Arc | Circle | Curve | Filled area

Attribute::= Color | Line type | Line width | Pattern

PickId:: string.

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

Координата_X (XID: Integer; X: Float)

Координата_Y (YID: Integer; Y: Float)

Точка (PID: Integer; IX: Integer; IY: Integer)

Отрезок (LID: Integer; IP1: Integer; IP2: Integer)

Маркер (XID: Integer; Mtype: Integer; MP: Integer)

Отношение Координата_X содержит значения координат X, используемых при изображении прикладной модели. В нем XID - идентификатор координаты и одновременно ключ отношения, X - собственно координата. Отношение Координата_Y строится аналогично. Отношение Точка имеет ключ - идентификатор PID и два внешних ключа IX и IY, указывающих на соответствующие координаты из отношений Координата_X и Координата_Y. Отрезок имеет ключ - идентификатор LID и индексы точек начала и конца. Отношение Маркер строится аналогично. В нем Mtype - тип маркера, а MP - его позиция. Так же можно определить отношения и для остальных графических примитивов.

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

Сегмент верхнего уровня (корневой) обязательно должен содержать следующие сегменты: prompt, echo, acknowledge, echo area, которые хранят графические представления подсказки, курсора, подтверждения и области действия курсора соответственно.



Унификация структуры ЛУВ

Для решения второй задачи определим набор возможностей ЛУВ, необходимых для реализации названных классов устройств. Для устройства класса LOCATOR все возможности уже заложены в прототипе ЛУВ, рассмотренном выше. Для устройства класса STROKE необходимо предусмотреть возможность стыковки ЛУВ и организации иерархий. Для реализации устройства класса PICK необходимо в ЛУВ ввести функцию поиска графических объектов в структуре сегментов. Помимо этого, устройство класса PICK должно генерировать предположения о геометрических соотношениях между вводимыми графическими объектами и объектами, находящимися в структуре сегментов. Эти предположения в виде эха должны отображаться на экране, а при срабатывании триггера передаваться в сторону функционального ядра. Для реализации названных возможностей в одном унифицированном ЛУВ нами была разработана структура процессов ЛУВ, показанная на рисунке 8. Будем называть такие ЛУВ интеракторами нижнего уровня.

Блок управления получает команды со стороны функционального ядра, определяющие режим работы интерактора. Команда «старт» запускает работу интерактора: сигналом по каналу prompt выводится на экран его внешнее представление и активизируется процесс «измерение - триггер». Команда «приостановить» делает изображение интерактора менее ярким и приостанавливает процесс «измерение - триггер». Командой «продолжить» можно выйти из этого режима. По команде «стоп» интерактор завершает свою работу.



Рисунок 8 - Структура унифицированного ЛУВ

Через канал вывода fc-output со стороны функционального ядра поступает поток данных, определяющих конкретное внешнее представление ЛУВ. Это результат выполнения запроса к функциональному ядру. Внутри ЛУВ определена функция форматирования этих данных format, которая формирует структуру сегментов. Графическое представление интерактора определяется содержимым структуры сегментов. В ней хранится совокупность графических примитивов и заданных на них геометрических соотношений.

Определим на языке CSP [8] процесс SS, обслуживающий структуру сегментов, которая является его состоянием и связана с параметром seg. У него есть три входных канала и два выходных. Поведение процесса SS определяется оператором выбора, который для каждого входного события ставит в соответствие процесс его обработки:

SS(seg) = fc_output?d -> (let seg = format d

in display!seg -> SS(seg))

| echo?(x,y) -> (let m = match(x,y,seg)

in display!(cursor(x,y,seg) ++ show(m)) ->

pick!m -> SS(upd(x,y,seg)))

| command?c -> (let seg' = modify(c,seg)

in display!(seg') -> SS(seg'))

Если в процесс SS по каналу fc_output поступят графические примитивы и геометрические соотношения со стороны функционального ядра (они связываются с параметром d), то они сначала визуализируются - передаются по каналу display, а потом заносятся в память сегментов функцией insert.

Если по каналу echo поступят новые измеренные координаты (x,y), то

1) для них функция match построит список возможных геометрических соотношений m,

2) на экран выводится через канал display их графическое представление вместе с новым положением курсора,

3) список m по каналу pick передается процессу измерения M,

4) процесс SS продолжает работу со структурой сегментов, в которой модифицировано положение текущей точки.

Процесс «измерение - триггер» имеет параметры (состояние): значение, измеренное устройством ввода, и список предположений о геометрических соотношениях, полученных от структуры сегментов. Он получает входное событие от устройства ввода (например, мыши), разделяет его на две составляющие: измеренное значение, если была изменена позиция устройства, и триггер - если была нажата кнопка. В первом случае измеренное значение по каналу echo передается в память сегментов, там для него подбираются возможные геометрические соотношения и принимаются по каналу pick. Во втором случае измеренное значение и список предполагаемых геометрических соотношений передается по каналу inptoken процессу генерации знака. Это буфер, через который со стороны функционального ядра можно последовательно читать отдельные предположения. Процесс измерение - триггер определяется следующим выражением:

MT(v) = inp?v' -> (if trigger(v')

then inptoken!v -> MT(v)

else echo!v' -> MT(v))

| sample -> inptoken!v -> MT(v)

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

1) его визуальное представление: изображение прикладной модели, подсказку, подтверждение, эхо;

2) определение триггера;

3) множество классов предположений о геометрических соотношениях, предположения о которых может сгенерировать интерактор;

4) визуальное представление этих предположений;

5) множество знаков, которые интерактор может выдать.

Для определения экземпляра интерактора необходимо:

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

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

3) Задать множество классов геометрических соотношений, предположения о которых интерактор может генерировать.

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

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

Поддержка в ЛУВ геометрических соотношений

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

Множество всех графических объектов, содержащихся в структуре сегментов, можно разделить на два подмножества:

· изменяемые, которые при изменении позиции устройства ввода изменяют своё положение или форму;

· неизменяемые, которые не зависят от позиции устройства ввода.

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

Рассмотрим возможные виды геометрических соотношений. Прежде всего, они зависят от классов связываемых ими графических объектов.

1. Соотношения между двумя точками.

· Совпадение координат X

· Совпадение координат Y

· Совпадение точек

· Симметрия двух точек относительно заданной точки или оси

2. Соотношения между точкой и отрезком.

· Принадлежность точки прямой, на которой лежит отрезок

· Принадлежность точки отрезку

3. Соотношения на одном отрезке.

· Фиксация угла наклона к оси OX

· Фиксация длины

4. Соотношения между двумя отрезками.

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



Выводы

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



Литература

[1] Faconti G.P. Towards the Concept of Interactor/ AMODEUS project report. Esprit Basic Research 7040. Amodeus Project Document, system modelling/WP8. 1993. ftp://ftp.mrc-apu.cam.ac.uk/pub/amodeus/sysmod/sm_wp08.ps.Z.

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

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

[4] Гордиенко А.П. Модели интеракторов // Вестник МЭИ.- 2004.- N 5.- С. 58-64.

[5] ISO 7942-1985E.- Information Processing System.- Computer Graphics.- Functional Specification of the Graphical Kernel System (GKS).

[6] ISO dp9592/1-198n(E).- Information Processing System.- Programmer's Hierarchical Interactive Graphics System (PHIGS).

[7] Duce D.A., van Liere R. and ten Hagen P.J.W. An Approch to Hierarchical Input Devices // Computer Graphics Forum.- 1990.-N.9.-P.15-26.

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

[9] Takala T. Communication Mediator - A Structure for UIMS // User Interface Managment Systems. Ed. G. E. Pfaff. Springer-Verlag, 1985.- P.59 - 66.

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

...