УПРАВЛЕНИЕ ВИЗУАЛЬНЫМ ПРЕДСТАВЛЕНИЕМ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА ГРАФИЧЕСКОГО РЕДАКТОРА САПР VISUAL UI REPRESENTATION MANAGEMENT

УДК 004.514
А.П. ГОРДИЕНКО, О.В. АМЕЛИНА
A.P. GORDIENKO, O.V. AMELINA
УПРАВЛЕНИЕ ВИЗУАЛЬНЫМ ПРЕДСТАВЛЕНИЕМ
ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА ГРАФИЧЕСКОГО
РЕДАКТОРА САПР
VISUAL UI REPRESENTATION MANAGEMENT
OF CAD GRAPHICS EDITOR
В данной статье предложены принципы управления визуальным представлением графического
интерфейса пользователя (ГПИ) САПР. Данные принципы являются основой для реализации ГПИ в
декларативном стиле, средствами чистого функционального программирования, в виде системы формальных
определений. Это позволяет получить программу, с которой можно выполнять формальные преобразования,
улучшающие ее качество. Предложенный метод позволяет доказывать корректность реализации и
соответствие заданной спецификации.
Ключевые слова: графический интерфейс пользователя; САПР; визуальное представление
пользовательского интерфейса; контекст диалога; ограничения целостности; чисто функциональное
программирование.
In this article proposed the principles of visual representation of the graphical user interface (GUI) of CAD.
These principles are the basis for the realization of GUIs in a declarative style, by means of pure functional
programming, in the form of formal definitions. This allows to get a program with which become possible to perform
formal transformations that improve its quality. The proposed method allows to prove the correctness of the
implementation and compliance with specifications.
Keywords: graphical user interface; CAD; visual representation of the user interface; the context of dialogue;
integrity constraints; purely functional programming.
Введение
Одним из критериев эффективного проектирования с помощью САПР считается
удабство ее использования, что обусловлено качеством разработки графического
пользовательского интерфейса (ГПИ).
Диалог в ГПИ обеспечивает система управления интерфейсом пользователя (СУИП),
которая координирует выполнение множества взаимодействующих параллельных процессов,
ответственных за различные прикладные функции диалога. Каждый отдельный процесс
должен быть очевидным образом представлен на экране дисплея. Совокупность таких
представлений от всех активных в данный момент процессов, которую обычно называют
контекстом диалога, должна быть понятна пользователю. Пользователь должен легко
обнаруживать предоставляемые ему для работы инструменты и знать, как их применять.
ГПИ должен на каждое действие оператора реагировать
изменением своего
визуального представления. Это изменение зависит не только от прикладной модели,
хранящейся в базе данных, но и от состояния диалога и, таким образом, имеет множество
параметров. Опыт показывает, что если все эти параметры не привести в систему, то
построение ГПИ может существенно затянуться во времени из-за поиска многочисленных
ошибок в поведении ГПИ.
В достаточно сложных САПР управление визуальным представлением требует
использования специальных методов спецификации и разработки специальных моделей в
СУИП.
В этой статье мы предлагаем принципы управления визуальным представлением
ГПИ, на основе которых становится возможной реализация ГПИ в декларативном стиле,
средствам чистого функционального программирования.
Компоненты визуального представления пользовательского интерфейса
Изображение, представленное пользователю графического редактора, включает
компоненты, отображающие проектируемую модель, и компоненты, отображающие текущее
состояние пользовательского интерфейса.
Проектируемая модель хранится в базе данных, входящей в состав функционального
ядра (ФЯ). База данных строится в соответствии с концептуальной схемой, сущностями
которой являются отрезки, дуги, окружности, размеры и т.д. С базой данных связан модуль
поддержки ограничений целостности. В нем содержится информация о геометрических
соотношениях между графическими сущностями, например таких, как принадлежность
точки прямой, параллельность прямых, концентричность дуг и окружностей и т.д. В базе
данных содержатся и правила вычисления зависимых данных, позволяющие на основе
анализа ограничений и размеров построить план вычерчивания чертежа.
Помимо базы данных в функциональное ядро входит набор прикладных процедур,
составляющих прикладной интерфейс. Эти процедуры заносят данные в базу, изменяют их и
удаляют из базы данных.
Объекты пользовательского интерфейса визуализируют события, которые могут
произойти в ГПИ. Возможные события определяются модулем логики диалога.
В модуле логики диалога определены возможные процессы диалога на языке
взаимодействующих последовательных процессов [1]. Процесс – это математическая
абстракция взаимодействия системы и ее окружения. Будем употреблять термин «процесс»
для обозначения поведения объектов диалога, так как оно может быть описано в терминах
ограниченного набора событий, выбранного в качестве его алфавита. События – это
объекты, служащие для синхронизации процессов. Если событие отражает синхронизацию
процесса с окружением, то есть с пользователем, то в момент его совершения происходит
ввод данных от пользователя к функциональному ядру или вывод на экран данных,
хранящихся в функциональном ядре. Если синхронизируются два процесса, то событие
включает в себя передачу данных между процессами.
Язык описания процессов диалога, его синтаксис и реализация на чисто
функциональном языке Haskell предложена в [2].
Каждое возможное событие имеет свое визуальное представление. В терминах
стандарта GKS [3] – это логическое устройство ввода. Представление события содержит
графические объекты следующих классов:
1) Приглашение на взаимодействие (Prompt). На экран выводится изображение,
показывающее пользователю, что логическое устройство ввода готово к работе.
2) Графический курсор (Echo). Это изображение, по которому пользователь
отслеживает на экране текущее положение графического устройства ввода.
3) Подтверждение (Acknowledgement). В нем представлена оценка действий
пользователя, информация об изменившемся состоянии ФЯ, сообщение об ошибке.
4) Предположение о возможных геометрических соотношениях строящегося объекта
с уже существующими объектами (параллельность, перпендикулярность, принадлежность
прямой, то есть возможные ограничения целостности).
Представление всех возможных событий объектами перечисленных классов будем
называть контекстом диалога.
Формирование контекста диалога
Исходными данными для формирования контекста диалога является множество
входных событий, представленных в меню текущего процесса диалога. Каждое такое
событие описывается его идентификатором и списком параметров. События могут
различаться по видам, которые, как правило, соответствуют классам логических устройств
ввода, определенных еще в стандарте GKS, основные из них:
1) устройство ввода позиции (locator), которое получает позиции на экране;
2) устройство указывания (pick), которое получает идентификаторы указанных
объектов;
3) устройство выбора (choice), которое срабатывает по нажатию кнопки на экране
или по выбору пункта меню;
4) устройство ввода строки (string), которое срабатывает при вводе строки с
клавиатуры.
Информацию, которая формируется при срабатывании логического устройства ввода,
называют входным знаком. Это описание входного события.
Возвращаясь к описанию меню текущего процесса диалога, отметим, что параметры
входящих в него событий – это списки ранее введенных входных знаков.
Формирование подсказок
В СУИП должна быть определена функция, которая для каждой пары идентификатор события, список параметров – строит список графических объектов, которые,
отображаясь на экране, будут служить подсказкой пользователю и приглашением выполнить
определенные действия (вызвать входное событие). Некоторые из этих графических
объектов могут быть помечены идентификаторами для возможности указывания на них
(возможности ввода события pick).
Формирование эха
В СУИП также должна быть определена функция, назначающая событию его эхо,
которое реализуется функцией типа
Position → Token → IO EchoRes ,
где Position - положение курсора в координатах экрана,
Token - знак, который был бы сформирован, если бы данное устройство сработало,
IO EchoRes - процедура ввода-вывода, которая выводит эхо на экран и возвращает
результат этого действия типа EchoRes.
Эта функция имеет доступ к состоянию ФЯ и, таким образом, при её применении
можно запрашивать базу данных. При построении функции, которая будет определять эхо
для всего меню, нужно учесть очевидное требование, что активность одного эха может
блокировать остальные эхо. Таким образом, из списка функций нужно выбирать только
некоторые виды эхо, а остальные не показывать. Выбор этот может зависеть от следующих
факторов:
а) от области действия события – то есть событие может возникать только в
определенной области экрана; например, нажатие визуальной кнопки может происходить
только в прямоугольнике, в котором она расположена, а ввод позиции возможен в области,
где изображен редактируемый чертеж;
б) от приоритета события; например, если пользователь навел курсор на какой-либо
объект, то эхо должно быть от устройства указания (если таковое есть в меню), а если курсор
расположен в свободной части окна, то эхо должно быть от устройства ввода позиции.
Руководствуясь этими соображениями, можно построить алгоритм формирования
функции эхо. Исходные данные для него – меню текущего процесса, то есть список событий.
Из этого списка нужно исключить те события, которые в данный момент невозможны.
Событие назовем невозможным в данный момент, если его наступление требует каких-либо
предварительных действий со стороны пользователя. Например, событие, вызываемое
отпусканием кнопки мыши, будет невозможным, если эта кнопка еще не нажата. Далее
полученный список событий нужно отсортировать в соответствии с приоритетом событий.
Например, сначала должно идти событие выбора, потом указывания, потом ввода позиции и
т.д. Результирующая функция вывода эха будет работать с этим отсортированным списком.
Она будет по очереди брать каждое событие и выполнять соответствующую ему функцию
эха. Эта функция в зависимости от ее параметров – текущего события и возможного знака –
решает, нужно ли ей выводить эхо. Если нужно – выводит его и выдает результат – эхо
введено, иначе просто выдает результат – эхо не введено. В первом случае функция перебора
должна завершиться, а во втором – перейти к следующему событию из списка.
Формирование предположения о геометрических соотношениях
Как уже отмечалось, при построении элементов чертежа нужно учитывать
геометрические соотношения. Они будут заноситься в базу данных как ограничения
целостности. Информация о геометрических соотношениях имеет смысл только для
устройств ввода позиции. Для каждого окна может быть активно не более одного устройства
такого вида. Таким образом, события ввода позиции должны иметь атрибуты, указывающие
виды предположений о геометрических соотношениях, которые для них могут
генерироваться.
Заключение
Изложенные выше принципы построения модуля управления визуальным
представлением ГПИ являются основой для реализации такого модуля средствами чистого
функционального программирования. Опыт его реализации на языке Haskell [4] показал
следующее:
1) ГПИ может быть реализован в декларативном стиле, как система формальных
определений;
2) с полученной программой можно выполнить формальные преобразования,
улучшающие ее качество;
3) предложенный метод позволяет доказывать корректность реализации и
соответствие заданной спецификации.
СПИСОК ЛИТЕРАТУРЫ
1. Хоар Ч. Взаимодействующие последовательные процессы.- М: Мир, 1989.
2. Гордиенко А.П. Процессы диалога – основа иерархии интеракторов // Известия
ОрёлГТУ. Серия «Информационные системы и технологии».- 2005.- N 2(8).- С. 50 -61.
3. ISO 7942-1985E.- Information Processing System.- Computer Graphics.- Functional
Specification of the Graphical Kernel System (GKS).
4. Haskell 2010. Language Report. Simon Marlow (editor).
Гордиенко Александр Петрович
Госуниверситет УНПК, г. Орел
к.т.н., доцент кафедры «Информационные системы»
Тел.: +7(4862) 47-37-88
E-mail: algord@rambler.ru
Амелина Ольга Викторовна
Госуниверситет УНПК, г. Орел
к.э.н., доцент кафедры «Информационные системы»
Тел.: +7(4862) 75-01-06
E-mail: shu-shu-oa@yandex.ru