Процессы диалога – основа иерархии интеракторов

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

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

Процессы диалога - основа иерархии интеракторов

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

Аннотация

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

Современные среды программирования, такие как Borland Delphi или Microsoft Visual Studio, для программирования графического пользовательского интерфейса (ГПИ) предлагают уже ставшие привычными средства: набор визуальных компонент, событийную модель управления и возможности императивного языка, такого как Паскаль или Си. Однако такое сочетание больших возможностей не гарантирует защиту от ошибок. Несколько параллельно работающих обработчиков событий, совместно изменяя общее состояние диалога, могут повести себя непредсказуемым образом. Во избежание этого нужно обеспечить синхронизацию процессов и разделение ресурсов. Достичь этого можно, если описать диалог на формальном языке параллельных процессов, например на CSP [1], а затем транслировать это описание в структуры обработчиков событий и конструкции языка программирования.

Использование языка процессов имеет ещё одно преимущество: описание ГПИ приобретает законченную форму в виде иерархии интеракторов [2]. Сформулируем точнее понятие интерактора. Интерактор - это компонента пользовательского интерфейса, имеющая состояние и визуальное представление и способная реагировать на сообщения от устройств ввода и других интеракторов, изменяя при этом своё состояние и визуальное представление. В иерархии интеракторов можно выделить три уровня: на нижнем уровне располагаются примитивные интеракторы, выполняющие функции логических устройств ввода, описанных в [3]; на среднем - агрегирующие интеракторы, обеспечивающие совместную работу примитивных интеракторов; на верхнем - процессы диалога, определяющие логику диалога без уточнения интерактивных методов взаимодействия с пользователем. Связь уровней иерархии в общем виде можно определить так: каждому вхождению в выражение имени события соответствует примитивный интерактор. Меню процесса определяет необходимый ему набор примитивных интеракторов, работающих под управлением агрегирующего интерактора.

Принципы построения графического пользовательского интерфейса в виде иерархии интеракторов описаны нами ранее [4]. В данной статье предлагается язык описания процессов диалога и его реализация на чисто функциональном языке Haskell [5].

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

d ProcDef e Event

p Proc exp Exp

op Op x Var

np ProcName v Value

ne EventName

где, ProcDef - определения процессов; Proc - выражения, определяющие процесс; Op- операции композиции процессов; ProcName - множество возможных имён процессов, EventName - множество возможных имён событий; Event - множество событий; Exp - выражения функционального языка; Var - переменные; Value - значения. Тогда структура объектов языка в форме контекстно-свободных грамматик определяется следующим образом:

d ::= np (x1, … xk) = p

p ::= Exit | ep | e1p1 [] e2p2 … [] enpn | p Op p1

| case exp of v1p1 ; v2p2 … ; vmpm

e ::= ne | ne ! exp | ne ? x

op ::= [ e0, e1,… ek ] | | [> | >> .

Определение процесса d ставит в соответствие его имени np со списком формальных параметров (x1, … xk) выражение p, определяющее процесс. Процесс может быть: префиксом, вида ep; альтернативой - e1p1 [] e2p2 … [] enpn или композицией процессов, полеченной операциями: [e0, e1,… ek] - параллельное выполнение с синхронизацией по событиям e0, e1,… ek; - прерывание; [>- отключение; >> - последовательное выполнение. Смысл операций подробно будет рассмотрен ниже. Процесс, зависящий от окружения локальных переменных, определяется в виде: case exp of v1p1 ; v2p2 … ; vmpm. Он ведёт себя в зависимости от вычисленного значения выражения exp. Определения процессов могут быть рекурсивными. Один из процессов ps выбирается в качестве стартового.

Обозначение события может быть одновременно и обозначением канала, по которому передаются данные. Процесс, который сначала передает по каналу c значение v, а затем ведет себя как процесс P, определяется так:

(c!v p)

Процесс, который готов получить значение переменной x по каналу c, а затем вести себя как процесс P(x), определяется в виде:

(c?x p(x))

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

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

Var(p) = {x0,x1,…xn} если p'(x0,x1,…xn) = p

Var(p) = Var(p') {x} если p' = e?x p

Переменная x, значение которой было получено в событии e?x, доступна процессам, следующим за этим событием. Таким образом, при выполнении процесса p = e?x e'?x' q, в процессе q можно использовать переменные x и x'. По завершении процесса, когда выполнение передаётся процессу Exit, или процесс отключается другим процессом - связи локальных переменных теряются. Локальные переменные могут использоваться для накопления вводимых пользователем данных для дальнейшей передачи их функциональному ядру и для управления логикой диалога данными, вводимыми пользователем.

Для определения смысла операций языка используем структурную операционную семантику [6], которая определяет способ вывода смысла выражений из их синтаксиса. Мы будем иметь в виду систему взаимодействующих процессов, включающую в себя ГПИ и пользователя. Система выполняет обработку события, когда обе стороны вовлечены в процессы. Процесс p выполняет действие, когда он и его окружение вместе видят одно и то же событие e в одно и то же время. Это совместное действие называется синхронизацией. Множество событий, которые процесс p может увидеть, называется алфавитом процесса p и обозначается б(p).

Структурно-операционная семантика выражений поведения определяется на основе деревьев синхронизации. Дерево синхронизации имеет узлы - выражения поведения, а направленные дуги - синхронизации событий, преобразующие выражения поведения до события в выражение поведения после события. Дуги дерева синхронизации записывают в виде P e Q, что означает, что процесс P по событию e преобразуется в процесс Q. В структурно операционной семантике смысл операторов языка процессов определяется правилами вывода вида:



где P - посылки, Q - заключение, C - условие применимости правила. Например, правило для оператора префикса имеет вид:

что означает, что процесс eP после участия в событии e ведет себя как P. Правила для оператора выбора имеют вид:

Первое из них утверждает, что если процесс P может синхронизироваться по событию e и далее вести себя как процесс P', то процесс P [] Q тоже может синхронизироваться по событию e и далее вести себя как P'. Второе правило описывает случай, когда процесс Q может синхронизироваться по событию e и далее вести себя как Q'.

Смысл оператора последовательной композиции можно определить следующими двумя правилами:

Первое правило утверждает, что если процесс P по событию e преобразуется в процесс P', то последовательная композиция процессов P >> Q по этому событию преобразуется в P' >> Q. Второе правило утверждает, что если в последовательной композиции первый процесс завершил работу, то композиция ведет себя как второй процесс.

Оператор параллельной композиции вида P[e0, e1,… ek]Q позволяет построить систему из двух процессов P и Q, работающих независимо друг от друга, если происходят события, не входящие в множество {e0, e1,… ek}. Но когда такое событие произойдет, параллельные события должны синхронизироваться. В этом случае если один процесс готов обработать это событие, а другой нет, то первый должен заблокироваться до тех пор, пока второй не достигнет точки синхронизации. Синхронизацию процессов можно определить следующим правилом:

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

В последних работах по применению языка CSP для описания графического диалога [7, 8] используется ряд дополнительных операторов композиции процессов. Эти операторы, дополняя описанные выше, образуют основу языка LOTOS, являющегося стандартом ISO для описания взаимодействующих процессов Рассмотрим семантику дополнительных операторов. Оператор отключения в выражении P [> Q позволяет описывать поведение процесса P, который может быть отключён процессом Q. Его можно описать следующими правилами:



Первое правило показывает, что процесс P может синхронизироваться со своими событиями без помех со стороны процесса Q. Второе правило утверждает, что если первый процесс успешно завершит свою работу, то вся композиция успешно завершает работу. Третье правило соответствует процедуре отключения первого процесса: если возникло событие e, в котором может принять участие процесс Q и далее ввести себя как Q', то процесс P выключается из работы, а вся композиция ведет себя как Q'. Оператор отключения соответствует оператору обработки исключительных ситуаций в обычных языках. В ГПИ оператор отключения используется, например, при переходе от одной команды к другой, когда пользователь делает выбор в меню.

Оператор прерывания в выражении P ? Q позволяет описать композицию из двух процессов, в которой первый процесс P, нормально развиваясь, в любой момент времени может быть прерван вторым процессом Q. Прерывание происходит тогда, когда в окружении появляется возможность наступления события, в котором может участвовать процесс Q. За этим событием второй процесс начинает определять поведение композиции в целом, а первый станет активным только по завершении второго. Семантику оператора прерывания можно определить следующими тремя правилами:

Первое правило: если по событию e первый процесс P трансформируется в P', то по этому событию вся композиция P ? Q трансформируется в P' ? Q. Это правило описывает нормальную работу первого процесса. Второе правило: если первый процесс успешно завершает работу, то и вся композиция успешно завершает работу. Третье правило: если по событию e прерывающий процесс Q преобразуется в Q', то по этому событию композиция P ? Q трансформируется в последовательное выполнение процессов Q' и исходной композиции P ? Q.

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

Для сокращения числа скобок в выражениях поведения примем следующий приоритет операций: , [], ||, [>, ?, >> . Операторы с одинаковым приоритетом считаются ассоциативными вправо. Как будет показано позже, набор перечисленных операторов достаточен для описания многопотоковых диалогов произвольной сложности.

Рассмотрим структуру событий. События - это объекты, служащие для синхронизации процессов. Если событие отражает синхронизацию процесса с окружением, то есть с пользователем, то в момент его совершения происходит ввод данных от пользователя к функциональному ядру или вывод на экран данных, хранящихся в функциональном ядре. Если синхронизируются два процесса, то событие одновременно включает в себя передачу данных между процессами. Таким образом, событие может одновременно обозначать канал, по которому передаются данные. В этом случае событие записывается парой <c,v>, где c - название канала, v - значение, передаваемое по каналу (сообщение). Множество всех сообщение, которыми может обмениваться процесс P по каналу c, определяется следующим выражением:

с (P) = {v <c,v> (P)}

Если v с(P), то процесс, который сначала передает по каналу c значение v, а затем ведет себя как процесс P, определяется так:

(c!v P)

Процесс, который готов получить значение переменной x по каналу c, а затем вести себя как процесс P(x), определяется в виде:

(c?x P(x))

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

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

data SP input output,

где input и output - типы вводимых (потребляемых) и выводимых (производимых) элементов. Обработчики потоков строятся на основе трех базовых обработчиков потоков, которые могут: поместить значение в выходной поток, взять значение из входного потока и закончить работу. Их типы определяются следующим образом:

putSP :: output SP input output SP input output

getSP :: (input SP input output) SP input output

nullSP :: SP input output

Представим процессы диалога в виде обработчиков потоков следующих типов:

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

Exit - процесс, который завершил свои действия, и должен быть исключен из текущего выражения поведения.

Pro (e -> Pro e v) - процесс, способный обработать событие и выдать процесс - продолжение.

Get (v -> Pro e v) - процесс, читающий данные из входного потока. Он содержит функцию, преобразующую их в процесс - продолжение.

Put v (Pro e v) - процесс, выдающий в выходной поток значение и далее действующий как процесс, заданный вторым аргументом.

На Хаскеле этот тип можно определить следующим образом:

data Pro e v = Bleep | Exit | Pro (e -> Pro e v)

| Get (v -> Pro e v) | Put v (Pro e v)

instance (Eq a) => Eq (Pro a b) where

Bleep == Bleep = True

Exit == Exit = True

_ == _ = False

type Event = [Char]

type Value = [Char]

type PC = Pro Event Value

Определим семантическую функцию T, отображающую выражения проведения в соответствующие функции Хаскеля. Для оператора префикса они должны учитывать три случая:

1. Когда событие не связано с передачей данных.

T[ eP ] = prefix e T[P],

где функция prefix имеет следующее определение:

prefix :: Event -> PC -> PC

prefix e p = Pro ( \ x -> (if x==e then p else Bleep))

Она, получив событие и процесс, формирует процесс вида Pro, который будет сравнивать переданное ему событие с заданным префиксом e и в случае совпадения возвращать процесс - продолжение p, а в противном случае - Bleep.

2. Когда событие включает в себя чтение данных из канала.

T[ e?xP ] = prefixGet e (\x -> T[P]),

где функция prefixGet имеет следующее определение:

prefixGet :: Event -> (Value -> PC) -> PC

prefixGet ev clo = Pro ( \ e -> (if e==ev then (Get clo) else Bleep)) .

Она требует два аргумента событие и функцию, передающую полученное из канала значение в процесс - продолжение. Она возвращает процесс, который сравнивает событие e с префиксом, и, в случае совпадения, ведёт себя как процесс, который прочтет из канала значение, свяжет его с переменной v, а потом вернет процесс T[P], в окружении которого будет это связывание; в случае несовпадения будет возвращен Bleep.

3. Когда событие связано с передачей данных в канал.

T[ e!vP ] = prefixPut e v T[P],

где функция prefixPut имеет следующее определение:

prefixPut :: Event -> Value -> PC -> PC

prefixPut e v p = Pro(\x ->(if x==e then (Put v p) else Bleep))

Она требует два аргумента событие e, выводимое значение v, и процесс - продолжение p. Она возвращает процесс, который сравнивает событие e с префиксом и в случае совпадения выдает в канал значение v и далее ведёт себя как процесс p; в случае не совпадения будет возвращен Bleep.

Определение семантической функции оператора выбора имеет те же три варианта.

T[ eP [] Q] = choice e T[P] T[Q]

T[ e?xP [] Q] = choiceGet (\x -> T[P]) T[Q]

T[ e!vP [] Q] = choicePut e v T[P] T[Q]

где функции choice, choiceGet и choicePut определены следующим образом:

choice :: Event -> PC -> PC -> PC

choice ev p (Pro alt) =

Pro (\x -> if x == ev then p else alt x)

choiceGet :: Event -> (Value -> PC) -> PC -> PC

choiceGet ev clo (Pro alt) =

Pro (\x -> if x == ev then Get clo else alt x)

choicePut :: Event -> Value -> PC -> PC -> PC

choicePut ev v p (Pro alt) =

(Pro (\x -> if x == ev then p else alt x)) .

Они работают аналогично функциям prefix, prefixGet и prefixPut, но имеют дополнительный параметр - альтернативный процесс (Pro alt) , который будет применяться к событию, если оно не совпадет с ev.

Операции композиции процессов из двух процессов строят один. Причём процессы - операнды могут быть заключены в конструкторы Get и Put, которые нужно вынести за пределы композиции так, чтобы композицию строить из процессов (Pro …). Это можно сделать функцией

advance:: PC -> (PC -> PC) -> PC,

которая, получив процесс p и функцию f, преобразующую его в новый процесс, строит преобразованный процесс (применение f к p), в котором конструкторы передачи по каналу пропущены вперёд:

advance (Get clo) f = Get (\x -> f (clo x))

advance (Put v p) f = Put v $ f p .

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

T[ P [ e0, e1,… ek ] Q] = parallel T[P] [e0, e1,… ek] T[Q],

Где parallel - функция, которая строит процесс, являющийся параллельной композицией процессов P и Q, синхронизирующихся по событиям e0, e1,… ek. Она определяется следующим образом:

1) parallel :: PC -> [Event] -> PC ->PC

2) parallel p a q =

3) let

4) sync :: (PC,PC) -> (PC,PC)

5) sync (p@(Pro _), q@(Pro _)) = (p, q)

6) sync (Get clo, Put v p) = (clo v, p)

7) sync (Put v p, Get clo) = (p, clo v)

8) sync (_, _) = (Stop,Stop)

9) trys :: Event -> (PC,PC) -> (PC,PC)

10) trys e pq@(p,q) =

11) let

12) p' = next e p

13) q' = next e q

14) in if (p'==Bleep) || (q'==Bleep) then pq else (p',q')

15) goon p q = Pro (\x ->

16) let

17) (p',q') = sync $ foldr trys (p,q) a

18) tryp = case p' of

19) Bleep -> Bleep

20) (Pro pc) -> let

21) pn = pc x

22) in case pn of

23) Bleep -> tryq

24) Skip -> q'

25) (Pro _) -> goon pn q'

26) otherwise -> advance pn (\p-> goon p q')

27) tryq = case q' of

28) Bleep -> Bleep

29) (Pro qc) -> let

30) qn = qc x

31) in case qn of

32) Bleep -> Bleep

33) Skip -> p'

34) (Pro _) -> goon p' qn

35) otherwise -> advance qn (goon p')

36) in tryp)

37) in goon p q

Функция parallel получает два процесса p и q, которые должны выполняться параллельно, и список событий a, по которым они должны синхронизироваться. Функция parallel работает в соответствии со следующим алгоритмом. Она, функцией goon, строит процесс - параллельную композицию процессов p и q, которая, получив событие x, сначала пытается синхронизировать свои процессы по событиям из a (строка 17), и получает новую пару процессов (p',q'). Для этого, для каждого события e из a выполняется функция trys, которая пытается синхронизировать процессы p и q по событию e. Если они оба могут участвовать в событии e, став соответственно p” и q”, то со следующим событием используется новая пара процессов (p”,q”); иначе -исходная пара (p,q) (строки 10-14). Последняя полученная пара принимается за (p',q').

После этого, обращением к функции tryp, делается попытка синхронизировать событие x с процессом p'(строка 36). В случае удачи возвращается новая параллельная композиция: процесс, который следует за x в процессе p'и q'(строка 25). В противном случае обращением к функции tryq, делается попытка синхронизировать событие x с процессом q'. В случае удачи возвращается параллельная композиция процесса p'и процесса, который следует за x в процессе q'(строка 34). В противном случае результат будет Bleep (строка 17).

Семантическая функция для оператора отключения процессов имеет следующий вид:

T[ P [> Q] = disable T[P] T[Q]

Функция disable строит композицию процессов p и q, в которой процесс q может отключить процесс p. Её реализация на Хаскеле имеет следующий вид:

1) disable :: PC -> PC -> PC

2) disable Bleep _ = Bleep

3) disable Exit _ = Exit

4) disable p@(Pro _) q = Pro (\x -> let qx = (next x q)

5) in if qx /= Bleep then qx

6) else (disable (next x p) q))

7) disable p q =

8) let

9) f p' = disable p' q

10) in advance p f

Если процесс p имеет вид Bleep или Exit, то и композиция становится Bleep или Exit соответственно (строки 2-3). Если композиция получила событие x, а в процессе q за x следует некоторый процесс qx, отличный от Bleep, то композиция ведёт себя как процесс qx, и, таким образом, процесс p в дальнейшем не участвует (строка 5).

Иначе - композиция ведёт себя как процесс, следующий в p за x, который может отключить процесс q (строка 6).

Семантическая функция для оператора прерывания имеет следующий вид:

T[ P Q] = interrupt T[P] T[Q]

Функция interrupt строит композицию процессов p и q, в которой процесс q может прервать развитие процесса p, а выполнив свои действия, дать возможность продолжиться процессу p, оставив за собой право снова прервать его. Её реализация на Хаскеле имеет следующий вид:

1) interrupt :: PC -> PC -> PC

2) interrupt Bleep _ = Bleep

3) interrupt Exit _ = Exit

4) interrupt p@(Pro _) q = Pro (\x -> let qx = (next x q)

5) in if qx /= Bleep then (seqw qx $ interrupt p q)

6) else (interrupt (next x p) q))

7) interrupt p q =

8) let

9) f p' = interrupt p' q

10) in advance p f

Если процесс p имеет вид Bleep или Exit - то и композиция становится Bleep или Exit соответственно (строки 2-3). Если композиция получила событие x, а в процессе q за x следует некоторый процесс qx, отличный от Bleep, то композиция ведёт себя как процесс qx, по окончании которого композиция продолжит свою работу(строка 5). Иначе - композиция ведёт себя как процесс, следующий в p за x, который может быть прерван процессом q (строка 6). Семантическая функция для оператора последовательной композиции имеет следующий вид:

T[ P >> Q] = seqw T[P] T[Q]

где функция seqw определена следующим образом:

1) seqw:: PC -> PC -> PC

2) seqw Bleep p = Bleep

3) seqw Exit p = p

4) seqw (Pro p) q = Pro (\x -> seqw (p x) q)

5) seqw p q =

6) let

7) f p' = seqw p' q

8) in advance p f

Если процесс p - Bleep, то и композиция становится Bleep (строка 2). Если процесс p - Exit (завершил свою работу), то композиция ведёт себя как процесс q (строка 3). Иначе, если композиция получила событие x, то композиция ведёт себя как процесс, который следует в p за x, по завершении которого будет выполняться процесс q (строка 4).

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

Функция menu, для текущего процесса строит множество событий, в которых он может участвовать. Это множество определяет контекст диалога. Функция menu тип:

menu:: [Event] -> PC -> [Event].

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

menu [] _ = []

menu _ Bleep = []

menu _ Exit = []

menu (x:xs) (Pro p) = if (p x) == Bleep

then m

else x : m

where m = menu xs pp

Функция next получает два параметра: событие и текущий процесс и возвращает процесс который следует за заданным событием в текущем. Она определяется следующим образом:

next :: Event -> PC -> PC.

next e (Pro p) = p e

next e p = p

Эта функция, в случае если процесс можно выполнить, то есть он имеет вид (Pro p), применяет p к событию e и возвращает процесс, следующий за заданным событием. Если процесс невыполним (имеет вид Bleep или Exit), то возвращает полученный процесс без изменения.

Теперь можно определить алгоритм управления логикой диалога:

1) Для текущего процесса p вычисляем его меню:
m = menu б(p) p.

2) Для каждого события меню из таблицы определения событий выбираем соответствующие параметры его примитивного интерактора.

3) Объединяем примитивные интеракторы в один агрегирующий, запускаем его на выполнение и получаем от него знак.

4) Полученный знак интерпретируем как событие e и используем его при вызове функции next(e,p) для получения нового текущего процесса.

5) Переходим к пункту 1.

В заключение отметим, что предлагаемый метод построения процессов диалога позволяет разработать инструментарий для проектирования поведения пользовательского интерфейса. Они должен содержать транслятор выражений поведения в функции Хаскеля, которые можно известными методами [10] транслировать в выражения - исчисления и представлять в виде графа. Блок управления пользовательским интерфейсом будет содержать такой граф, который будет интерпретироваться машиной редукции графов [10].

Литература

интерактор пользовательский интерфейс

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

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

3. Гордиенко А.П. Формирование модели интерактора как универсального логического устройства ввода // Вестник ОрелГТУ.- 2005.- N 4.- С. 57- 69.

4. Гордиенко А.П. Построение графического пользовательского интерфейса в виде иерархии интеракторов // Вестник компьютерных и информационных технологий.- 2005.- N 6.- С. 44 -48.

5. Bird R. Introduction to functional programming using Haskell.- Prentice Hall Press, 1998.

6. Plotkin. . G. D. A structural approach to operational semantics // Technical Report DAIMI FN­19, Computer Science Department, Aarhus University, 1981.

7. Markopoulos P. On the Expression of Interaction Properties within an Interactor Model // DSV-IS'95: Design, Specification, Verification of Interactive Systems, Conference Proceedings, Springer Verlag, pp.294-311.

8. Stirewalt R.E.K. Automatic Generation of Interactive Systems from Declarative Models. PhD thesis, Georgia Institute of Technology, 1997.

9. Carlsson M., Hallgren T. FUDGETS - A Graphical User Interface in a Lazy Functional Language // FPCA'93 Proceedings. - 1993. - p. 321-330.

10. Peyton Jones.S.L. The Implementation of Functional programming languages.- New York: Prentice Hall, 1987.

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

...