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

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

Статья по теме:

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

Аспирант кафедры “Информационные системы” Кузнецов А.И., науч. рук. к.т.н, доцент Гордиенко А.П. Орловский государственный технический университет Россия

Despite the fact that researches in the field of graphical user interfaces have reached considerable success, namely: determined architecture and composition methods of such systems, developed a variety of models and dialogue specifications' languages, none of the currently available methods is acknowledged as universally recognized in International standards. This work employs simple graphical editor as an example and shows the advantages of using the model offered in work [7] with the use of CSP language for dialogue logics description.

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

Кроме того, для многих языков формальных спецификаций возможно создание различного рода инструментальных средств, автоматизирующих процесс проектирования и реализации систем. Примером может служить общепризнанная методика проектирования схем реляционных баз данных, закрепленная в стандарте IDEF1 и реализуемая инструментальным средством типа Erwin [2]. Для многих формальных языков спецификаций разработаны эффективные методы их реализации и исполнения, как в случае технологий создания лексических и синтаксических анализаторов компиляторов [3], реализуемые инструментальными средствами типа LEX [4] и YACC [5].

К сожалению, на данный момент не существует общепризнанных и закрепленных в международных стандартах подобных методик для построения систем графического пользовательского интерфейса (ГПИ) [6]. Считается, что в процессе проектирования пользовательского интерфейса важную роль играют неформальные соображения («человеческий фактор») [7], и процесс проектирования ПИ состоит из последовательности версий, на каждом шаге которого производится экспериментальная оценка полученных результатов и определяются направления дальнейшего усовершенствования. Разработка средств быстрого прототипирования ПИ, использующих язык формальных спецификаций, могла бы значительно повысить эффективность данного процесса [6].

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

К наиболее известным моделям интеракторов можно отнести пизанскую [8] и йоркскую [9] модели интеракторов, MVC - модель [10], ADC - интеракторы, разработанные Маркополосом [11] и интеракторы системы FUDGETS [12].

А.П. Гордиенко в работе [7] представил собственную модель интеракторов для построения сложных графических редакторов САПР. Данная модель является развитием моделей ADC и FUDGETS и представлена на рис.1.

Рисунок 1 - Диаграмма кооперации объектов интерактора Гордиенко А.П.

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

Блок управления является совокупностью управляющих структур, представляющих собой выражения поведения. Для определения логики диалога может быть использован язык взаимодействующих последовательных процессов Ч. Хоара (CSP) [13]. Выражения поведения на CSP представляют собой композиции процессов, взаимодействующих посредством совместного участия в событиях (синхронизации). Специальный вид событий - события коммуникации, в результате обработки которых происходит обмен данными между взаимодействующими процессами. Можно рассматривать синхронизацию процессов по событиям коммуникации как межпроцессный обмен данными посредством именованных небуферизованных каналов. Использование небуферизованных взаимодействий в качестве основного их вида позволяет упростить процесс формального исследования свойств процессов, а в случае необходимости буферизованные коммуникации легко моделируются на основе первых. Такой подход позволяет сократить количество базовых конструкций языка, не снижая его описательную мощность.

В описываемом ниже примере показана реализация простого графического редактора, реализующего метафору «эволюционного развития»[14].

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

Внешний вид области построений редактора показан на рис.2.

Рисунок 2 - Внешний вид области построений графического редактора с метафорой «эволюционного развития»

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

Главный интерактор приложения - объект, обеспечивающий работу области построения (канвы) редактора.

Подчиненные ему интеракторы инкапсулируют графические объекты (отрезок, дуга, кривая Безье).

В данном примере эти интеракторы не содержат собственного блока управления, а являются просто объектными представлениями.

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

Простой интерпретатор выражений CSP можно написать на языке Пролог [15].

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

Определим следующие операторы композиции процессов:

:- op(705, xfy, >>>). % последовательное исполнение

:- op(704, xfy, <>). % прерывание

:- op(703, xfy, '[>'). % отключение

:- op(701, xfy, '[[]'). % альтернатива

:- op(700, xfy, ';;'). % префикс

Зададим операторы для определения событий коммуникации:

:- op(699, xfx, ?). % для чтения значения из канала

:- op(699, xfx, '!!'). % для передачи значения по каналу

Рекурсивный предикат next(F, T, E, O) истинен, если выражение поведения F преобразуется в выражение P при наступлении события E и O - список выходных сигналов.

Сначала определим, что завершившийся процесс не может быть преобразован:

next(F, _, _, _,):- is_exit(F), !, fail.

Правила для префикса имеют вид:

next(IC?IV ';;' OC'!!'OV ';;' Q, Q, IC?IV, [OC'!!'OV]).

next(IC?IV ';;' Q, Q, IC?IV, []).

Выбор альтернативы:

next(P '[[]' _, P1, E, O):- next(P, P1, E, O).

next(_ '[[]' Q, Q1, E, O):- next(Q, Q1, E, O).

Последовательная композиция процессов:

next(P >>> Q, Q1, E, O):- is_exit(P), !, next(Q, Q1, E, O).

next(P >>> Q, P1 >>> Q, E, O):- next(P, P1, E, O).

Отключение процесса Q процессом P:

next(P '[>' Q, P1 '[>' Q, E, O):- next(P, P1, E, O).

next(_ '[>' Q, Q1, E, O):- next(Q, Q1, E, O).

Прерывание процесса Q процессом P:

next(P <> Q, P1 <> Q, E, O):- next(P, P1, E, O).

next(P <> Q, Q1 >>> (P<>Q), E, O):- next(Q, Q1, E, O).

Использование в выражениях поведения имен процессов, описываемых своими выражениями поведения возможно благодаря следующему правилу:

next(P, P2, E, O):- rule(P, P1), next(P1, P2, E, O).

Данные правила используют предикат is_exit/1 для определения завершенности процесса:

is_exit(exit).

is_exit(P '[[]' _):- is_exit(P).

is_exit(_ '[[]' Q):- is_exit(Q).

is_exit(P >>> Q):- is_exit(P), is_exit(Q).

is_exit(P '||' Q):- is_exit(P), is_exit(Q).

is_exit(P '[>' _):- is_exit(P).

is_exit(P <> _):- is_exit(P).

is_exit(P):- rule(P, P1), is_exit(P1).

Выражения поведения, определяющие логику диалога интерактора, задаются множеством правил для предиката rule/2, где первый аргумент - имя процесса, второй - описывающее его выражение поведения.

Диалог редактора в момент запуска определяется процессом изменения объекта, который может быть прерван процессом построения отрезка:

rule( canvas, obj_change '[>' create_line ).

Процесс построения отрезка предлагает ввести координату первой точки, передает функциональному ядру команду создания отрезка с концами в этой точке, отслеживает дальнейшее перемещение курсора для создания эффекта «резиновой нити» (процесс do_move) и переходит в первоначальный процесс:

rule( create_line, loc?[P1] ';;' fc_create'!!'[P1] ';;' ( do_move >>> canvas )).

Рекурсивный процесс obj_change начинает работу по событию выделения курсором графической фигуры, передает команду функциональному ядру об активизации объекта (чтобы показать необходимые маркеры и пиктограммы) и далее определяется процессом changing:

rule( obj_change, pick?[shape,ID] ';;' fc_active_shape'!!'[ID] ';;' changing >>> obj_change).

Процесс changing позволяет осуществить выбор между процессами «прогресса»(evolve), «регресса»(degrade), перемещения опорной точки (move) или быть прерванным по событию esc.

rule( changing, (evolve '[[]' degrade '[[]' (move >>> changing)) '[>' obj_change '[>' esc?[] ';;' exit ).

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

rule( evolve, pick?[up_marker,_] ';;' fc_evolve'!!'[] ';;' (do_move >>> exit) ).

rule( degrade, pick?[down_marker,_] ';;' fc_devolve'!!'[] ';;' exit ).

Процесс перемещения контрольной точки подобен процессу эволюции по своей структуре:

rule( move, pick?[point_marker,MID] ';;' fc_active_point'!!'[MID] ';;' ( do_move >>> exit ) ).

Процесс do_move отслеживает перемещение курсора до тех пор пока не будет введен локатор, после чего успешно завершает свою работу:

rule( do_move, do_move_obj '[>' loc?[_] ';;' exit ).

rule( do_move_obj, move?[P] ';;' fc_move'!!'[P] ';;' do_move_obj ).

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

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

Литература

интерактор редактор гордиенко

1. Боуэн Д.П., Хинчи М.Д. Десять заповедей формальных методов //Мир ПК. 1997. №10.

2. Logic Works. ERWin Methods Guide.- 1997.

3. Aho A.V., Sethi R., Ullman J.D. Compilers, Principles, Techniques and Tools.-Massachusetts: Addison-Wesley, 1987.

4. M. E. Lesk and E. Schmidt, “LEX--Lexical Analyzer Generator”, Unix Research System Programmer's Manual, Tenth Edition, Volume 2.

5. S. C. Johnson and R. Sethi, ``Yacc: A parser generator'', Unix Research System Programmer's Manual, Tenth Edition, Volume 2

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

7. Гордиенко А.П. Принципы организации графического пользовательского интерфейса // Известия ОрелГТУ // Материалы конференции ИТНОП, 2004.

8. Paterno' F.: A Theory of User Interaction Objects. Journal of Visual Languages and Computing, Academic Press Ltd, Vol. 5, 227-249 (1994).

9. Duke D.J., Harisson M.D.: Abstract Interaction Objects. In: Hubbold R.J., Juan R. (eds.): Eurographics'93, Computer Graphics Forum, Vol. 12, No. 3, 26-36 (1993).

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

11. Markopoulos P. On The Expression Of Interaction Properties Within An Interactor Model // DSV-IS'95: Design, Specification, Verification of Interactive Systems, Conference Proceedings. Berlin: Springer Verlag, 1995.-P.294-311

12. Carlsson M., Hallgen 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.

13. Communicating Sequential Processes, C.A.R. Hoare. Prentice Hall International Series in Computer Science, 1985.

14. Гордиенко А.П. Разработка новых метафор пользовательского интерфейса для графических редакторов//Известия ОрелГТУ//Материалы конференции ИТНОП, 2004.

15. L. Sterling and E. Shapiro, The Art of Prolog, 2nd edition., MIT Press, 1994.

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