Автоматизация создания пользовательского интерфейса на основе модели приложения баз данных Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 004.4'244

© Е.С. Фереферов, А.Е. Хмельное

АВТОМАТИЗАЦИЯ СОЗДАНИЯ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА НА ОСНОВЕ МОДЕЛИ ПРИЛОЖЕНИЯ БАЗ ДАННЫХ1

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

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

© E.S. Fereferov, A.E. Khmelnov

AUTOMATIZATION OF USER INTERFACE CREATION BASED ON MODELS OF DATABASE APPLICATION

The article is devoted to the problems of automated creation of user interface for work with databases. To solve this problem the authors propose an original model of database applications, models presentation declarative language and instrumental system to create such models of database application.

Keywords: databases, models of information systems, declarative languages, instrumental systems, specifications.

Введение

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

Современные технологии разработки информационных систем, основанные на императивном программировании и использовании развитых библиотек визуальных компонентов (например, Delphi и Visual Component Library [1]), предоставляют достаточно общие инструментальные средства и подходят для решения большинства задач. В их арсенале имеется большое количество компонентов, реализующих как части визуального интерфейса, так и бизнес-логики для обеспечения доступа и модификации БД. Как правило, приложения создаются для работы с базами данных, имеющими определенную структуру, при этом доступ к индивидуальной таблице реализуется при помощи одних и тех же (или сходных по функциям) подпрограмм. При изменении структуры БД, например, добавлении новых таблиц или полей, необходимо соответственно вносить изменения в программный код, заново реализуя функции для доступа к новым элементам БД. Низкий уровень автоматизации реализации однотипных функций для работы с таблицами БД приводит к большими временным и трудовым затратам при создании (модернизации) пользовательского интерфейса для работы с БД.

В настоящее время ведутся активные работы по созданию новых подходов к разработке как пользовательских интерфейсов (например, MBUIDE [2]), так и к разработке АИС в целом (например, MDA [3], порождающее программирование [4]), позволяющие ускорить, сделать дешевле, качествен-

1 Работа выполнена при частичной финансовой поддержке РФФИ проекты 11-07-00426-а, 11-07-92204-Монг-а, междисциплинарного проекта № 131 СО РАН, ОНИТ РАН (проект № 4.1)

100

но повысить процесс создания приложений. Основной тенденцией современных подходов является попытка структурировать метаинформацию (данные о структуре) об АИС в виде модели системы различными средствами (например, надстройки над моделями классов UML или построение онтологий предметной области [5]). Формализация знаний о структуре АИС в модели позволяет выделять схожие структуры данных и присущие им бизнес-процессы в отдельные компоненты, что позволяет генерировать соответствующие им сценарии создания структур в СУБД, алгоритмы обработки бизнес-процессов, экранные формы единожды и распространить их на все подобные компоненты. Как показывает практика, сгенерированный код практически всегда требуется дорабатывать программисту, при этом полученные изменения не отражаются в исходных абстрактных моделях системы.

Для решения задач обработки, представления и анализа пространственных данных информационные системы должны обладать ГИС-функциональностью. Все современные геоинформационные системы предлагают разработчикам API, позволяющие реализовать как пользовательский интерфейс для работы с пространственными данными, так и функции для их обработки. Несмотря на развитость этих API, реализация ГИС-функциональности является сложной и трудоёмкой задачей, требующей от программистов знаний в области геоинформационных технологий. Часто программисту приходится повторять реализацию существующих функций целевой ГИС в своем проекте. Кроме того, при необходимости развития существующего приложения за счет ГИС-функциональности необходимо наличие исходных кодов этих АИС, а их отсутствие вынуждает разрабатывать систему заново.

Технология создания приложений баз данных

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

При создании модели приложения в качестве входных данных используются метаданные о структуре уже созданной БД (схема БД), хранящиеся в СУБД. Предполагается, что для создания схемы БД используются зарекомендовавшее себя ПО от ведущих компаний-разработчиков, позволяющее строить ER-модели данных и генерировать схемы БД (например, интегрированные утилиты СУБД MS SQL Server, Oracle или CASE-средства, такие, как Sybase Power Designer, IBM Rational Rose). Схема данных является уже структурированными знаниями о сущностях и связях между ними, которые необходимо расширить знаниями о бизнес-процессах и способах представления информации пользователю для создания качественного пользовательского интерфейса.

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

Для создания и модификации моделей приложений БД разработана инструментальная система ГеоАРМ [7]. Кроме того, при помощи спецификаций инструментальная система автоматически формирует пользовательский интерфейс для работы с предметной базой данных. Интеграция функций создания спецификаций и их интерпретации в одной системе дает возможность разработчику сразу оценить адекватность создаваемой модели приложения и повысить скорость разработки в целом. Встроенный в ГеоАРМ модуль для работы с пространственными данными обеспечивает пользователям работу с пространственными данными.

Модель приложения баз данных

Предлагаемая модель приложения БД имеет следующий вид:

M=<Schema, Display, Rules, Plugins>, где Schema - структура, описывающая схему БД, расширенную информацией о связях, способах организации данных для пользователя и взаимодействия с пространственными данными; Display -структура, описывающая механизм представления данных пользователю; Rules - структура для опи-

сания бизнес-правил приложения; Plugins - структура для описания взаимодействия с внешними подключаемыми модулями, решающими задачи, не заложенными в базовый функционал. Рассмотрим некоторые структуры модели подробно.

Структура Schema=<Tbls,Refs> описывает множества таблиц Tbls = {^,...,tn },n eN и связей

Refs ={r1,..., rm }, m e N между ними. C = {c1,..., cl} - множество схем таблиц БД, l eN, l < n . tt (Cj) - таблица со схемой cj, i = 1,...,n, j = 1,...,m, где cj = {a ,...,ap } p e N. ah - атрибут таблицы, h = 1,...,p .

Каждый атрибут относится к определенному типу данных: Vah 3Type(ah ) - тип атрибута. Определены восемь типов Type={I,F,S,D,B,X,G,SD}, где I - множество целых чисел, F - множество действительных чисел, S - множество строковых значений, D - множество значений дат и времени, B={true; false} - булевы значения, X - множество бинарных данных, G - множество растровых данных, SD - множество пространственных данных. Тип атрибута таблицы влияет на способ представления и обработки данных из этого поля.

Каждая таблица состоит из конечного множества записей

tr (cj) ^v.^ kq} q eN : Vkg 3C} ^ Type, kg a ) e Typef, f = 1,...,8, g = q, где kg (c;) -

запись со схемой c j, kg (ah) - значение записи kg на атрибуте ah, т.е. значение поля.

Для каждой таблицы могут быть определены ключи. Первичный ключ PK = {fj,...,app }с cj,pp = 1,...,p, если

L Vkg,kgge tt: kg(PK) * kgg(PK),g * gg,g = ъ--q,gg = ъ--q;

2 3PK ' с PK : kg (PK') * kgg (PK),g * gg, g = 1,...,q, gg = 1,...,q

Часто в качестве PK используют так называемые искусственные ключи - автоинкрементные поля, например, kg+1 (PK) = kg (PK) +1. При этом в таблице могут присутствовать естественные ключи (например, «Район», «Улица», «Дом»). Комбинации полей естественных ключей NF = {a1,...,appp }с cj, ppp = 1,...,p будем называть именующими полями. Такие именующие поля необходимы для организации удобного пользовательского интерфейса, например, по ним может быть организована автофильтрация или сортировка. FK = {a1,...,app }с cj - внешний ключ таблицы ti, если

L 3^, (cjj XPK ^..^app }с j

2. Vkge t,(cs)3kgge t.(c;j): kg(FK) = kgg(PKXgg = q

Структура Refs = {r1,...,rm } описывает множество связей между таблицами. Данная структура необходима для автоматического создания пользовательского интерфейса, поскольку метаинформации СУБД о ключах недостаточно для понимания, как должна быть организована работа с таблицами с точки зрения пользователя. Определены связи трех видов: rw e {LR, PR, DR}, w = 1,...,m, где LR -простая связь, PR - связь из первичного ключа, DR - связь типа детали.

rw (t,, t„) e LR, если kg (FK) = kgg (PK) v 0, FK e cj, PK e ^, kg e t (c. X kgg e t. (cjj);

rw (t., tn) e PR, если kg (PK) = kgg (PK), PK e c;, PK e ^, kg e tl (ciX kgg e t. (cjj);

rw (t,., t. ) e DR, если kg (PK) = ^(FK) л... л kgg (FK), FK e ^, PK e c]},

kge tr(c,), kgge t. (cj), {kJ,..., kgg}e t.;

При наличии связей LR или PR можно построить представления. Представление v(c') e V - это множество записей из таблицы t, (c .) e Tbls, где c' с cj, либо v(c') = (t, (cj), V', LR', PR'), где V' с V, Vv e V' 3rw(t,, v) e LR' v 3rw(t,, v) e PR' л c' с cj u c[ u... u c;'.

Т1

Ю1,РК А1 A2,FK

1 ааа 3

2 bbb

3 ссс 2

12

ID2,PK B1

1 dd

2 ее

3 ff

ТЗ

EH

1 ii

2 jj

3 gg

^^^^1(А2)-»Т2(1Р2) Т1(А2)=ТЗ(1РЗ)^^

VI

ID1,PK A1 ■ A2,FK ИB1 ci

1 aaa 3 ff ii

2 bbb jj

3 ccc 2 Иee gg

Рис. 1. Пример представления

В отличие от View популярных СУБД, которые являются сохраненными SQL-запросами, представления в предлагаемой модели являются наборами данных (рис. 1), которые построены на одной базовой таблице и содержат информацию о декодировании связей для получения данных из связанных таблиц. Такие представления позволяют автоматически организовать работу со связанными таблицами как с одним набором данных.

Структура Display = (C,U, E, C ^ Ej отвечает за то, какими элементами пользовательского интерфейса будут представлены данные из полей таблиц и представлений. U=(grd,frm) - режимы работы (табличный, форма). E={Btn,Edt,Cbx,Dtp,Chkt,Img,fn(Cbx),Grd,GB,TS} - множество элементов управления пользовательского интерфейса. Отображение полей в элементы пользовательского интерфейса зависит от типа поля:

k(ah) ^ Edt, если Type(ah) = I v F v S, k e tt, h = 1,...,p, ah e C;

k(ah) ^ Dtp, если Type(ah) = D,k e tt, h = 1,...,p, ah e C; k(ah) ^ Chkt, если Type(ah) = B,k e tt,h = 1,...,p,ah e C ; k(ah) ^ Cbx, если Type(ah) = I v F v S , k(ah) e v(c') = (ti (c j ),V', LR', PR'), h = 1,...,p, ah e C;

k(ah) ^Img, если Type(ah) = G,k e tt,h = 1,...,p,ah e C ;

k(ah) ^ fn(Cbx), если Type(ah) = I v F v S , k(ah) e v(c') = (tt (c j), V' , LR' , PR'), ah e NF ^ Cj,h = 1,...,p , где fn(Cbx) - Cbx с функциональностью автофильтрации.

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

Структура Rules={RO,CHK,MO} отвечает за режимы и правила работы с данными. Например, если RO(ti), то работа с таблицей tt будет в режиме «только для чтения», поля таблицы будут неактивны

для редактирования. Режим CHK (k (ah ), Rg), Rg = {0,1} отвечает за проверку вводимых данных, при этом существует два режима (Rg) проверки: строгое соответствие (1) и предупреждение (0). Меха-

низм MO(ti, tu ) позволяет автоматически создавать пространственные объекты для записей из tt на цифровой топооснове по метрике из таблицы деталей tu .

Структура Plugins = (Tbls, D, Dltj отвечает за вызов внешних приложений для обработки данных. Данная структура обеспечивает для tt e Tbls передачу данных во внешнее приложение dllz e Dll, вызов которого осуществляется из пользовательского интерфейса dx e Display.

Спецификации приложений баз данных

Для представления и хранения моделей приложений баз данных применяются декларативные спецификации, которые строятся на специально разработанном языке ЯПБД [6]. Конструкции языка позволяют в декларативном виде описывать все элементы модели приложения БД, а также некоторые общие настройки системы (например, способ подключения к БД, взаимодействие с другими БД и цифровыми картами). Язык представления баз данных принадлежит к классу LL(1) [8] грамматик. Предложения ЯПБД имеют следующую структуру:

<Стартовое слово> <Список обязательных выражений> [список необязательных выражений]

Начало предложений определяется по принадлежности первого слова к множеству стартовых слов. Каждое предложение состоит из обязательных и необязательных выражений. Все выражения разделены пробелами. Каждое выражение содержит зарезервированное (служебное) слово, описывающее имя какого-либо атрибута системы, и может включать значение этого атрибута через знак «=». Например,

READONLY или SCHEMA=<Значение атрибута> .

В некоторых случаях за служебным словом может идти список выражений в скобках «(...)» через запятую «,»:

FIELDS (<список выражений>,...,<список выражений>)

Определены следующие предложения:

• способы подключения к БД,

• общие настройки работы приложения,

• описание таблицы (для каждой таблицы, с которой необходимо работать),

• описание представления (для каждого представления, с которым необходимо работать),

• описание дерева таблиц и представлений,

• описание механизма интеграции с картой,

• описание расширений (Plugins).

Разработанный язык обеспечивает возможность настройки большого перечня параметров приложения. Предложения, описывающие таблицы и представления (рис. 2), сочетают в себе информацию о всех уровнях модели приложения M=<Schema,View,Rules,Plugins>. С одной стороны, конструкции языка позволяют достаточно детально описать структуру БД (уровень Schema), с другой, позволяют представить эту информацию с точки зрения работы приложения, то, как информация из таблиц БД будет представлена пользователю (уровень Display). Кроме того, конструкции ЯПБД позволяют поддерживать модульное программирование, т.е. при разработке спецификации приложения БД можно ссылаться на готовые спецификации других приложений. Такая возможность позволяет создавать

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

Рис. 2. Пример представления на ЯПБД

Инструментальная система создания приложений баз данных. Для создания и модернизации спецификаций приложений БД авторами была разработана инструментальная система ГеоАРМ [7]. Данная инструментальная система позволяет интерактивно управлять структурами моделей приложений баз данных, настраивать взаимодействие с БД, внешними подсистемами, цифровыми картами и сохранять спецификации в файлы на ЯПБД. Кроме того, при помощи спецификаций инструментальная система автоматически формирует пользовательский интерфейс, становясь предметной АИС.

Инструментальная система состоит из следующих подсистем: «Ядро», «Управление спецификациями», «Редактор БД», «Построитель пользовательских запросов», «Карта», модуль «Программный интерфейс» (рис. 3).

Ядро системы отвечает за взаимодействие всех подсистем АИС с СУБД, обеспечивая преобразование команд в терминах спецификации в команды интерфейсов для работы с СУБД.

СУБД

Спецификация

Внешние

системы

ГеоАРМ

ПС управления спецификациями ПС Построитель пользовательских запросов

у > г \ г

Ядро ПС Редактор БД

>

г

Программный интерфейс ПС Карта

Рис. 3. Архитектура инструментальной системы создания приложений БД

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

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

Рис. 4. ПС Редактор БД в режиме «таблица»

В области данных (справа на рис. 4) отображаются элементы управления для работы с таблицами и представлениями. Работа с данными осуществляется в двух режимах: в режиме таблицы (режим U=grd) для просмотра набора записей или в режиме формы (режим U=frm) для работы с конкретной записью. Состав элементов управления и стиль работы с полями таблиц или представлений определяется автоматически на основе информации из спецификации. Например, в режиме таблицы для полей представлений, полученных по ссылкам (к(ак) є v(c') = (їі (с;. ), V' , LR', PR')), автоматически

формируется список значений, причём, если осуществляется работа с несколькими полями таблицы-источника, то может быть определена последовательность их выбора. В режиме «форма» (рис. 5) поля, полученные по одной ссылке, автоматически объединяются в группу типа GB, если не определены иные группировки полей. Для полей Туре(ак ) = D поддерживается ввод данных непосредственно в Edt и через «Календарь». Рядом с полями Туре(ак ) = G автоматически создаются кнопки для вызова стандартных диалогов открытия и сохранения графических файлов. При наличии связей типа Г№ (їі, їіі) є DR в нижней части формы отображаются записи из таблицы-деталей. За оптимальную, с

точки зрения удобства работы пользователя, расстановку в области задач элементов управления отвечает менеджер компоновки [9].

Рис. 5. ПС Редактор БД в режиме «форма»

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

Рис. 6. Построитель пользовательских запросов

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

Программный интерфейс предназначен для взаимодействия с надстройками, позволяющими решать специфические, не заложенные в архитектуру «ГеоАРМ» задачи. Надстройки реализуются в виде динамически подключаемых библиотек и позволяют расширять возможности системы.

Подсистема «Карта» обеспечивает возможность работы с цифровой топоосновой. Данный модуль реализован при помощи пакета GIS ToolKit из ГИС Панорама [10]. В системе реализован механизм «Адресный план» - поиск на карте объектов по их почтовым адресам.

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

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

Заключение

Предложенная модель приложения баз данных позволила разделить информацию о структуре БД и пользовательском интерфейсе на отдельные структуры, что обеспечило возможность создания универсальных алгоритмов обработки данных из таблиц БД и автоматического создания пользовательского интерфейса. Представление моделей приложений БД в виде декларативных спецификаций удобно своей компактностью по сравнению с программами на императивных языках, предметной ориентированностью и выразительностью, а также широкой возможностью интерпретации и обработки различными трансформационными процедурами. Разработанная инструментальная система ГеоАРМ позволяет визуально создавать (модернизировать) спецификации приложений БД. Кроме того, ГеоАРМ может интерпретировать спецификации, становясь предметной АИС, обеспечивающей работу с БД и пространственными данными. В целом разработанная технология позволяет быстро создавать информационные системы для работы с БД и ГИС.

Литература

1. Архангельский А.Я. Приемы программирования в Delphi на основе VCL. - М.: Бином-Пресс,

2009. - 944 с.

2. Griffiths T. et al., A Model-Based User Interface Development Environment for Object Databases / Interacting with Computers. - Vol. 14, No. 1, Dec. 2001. - P. 31-68.

3. Рамбо Дж. UML 2.0. Объектно-ориентированное моделирование и разработка. - СПб. : Питер, 2007. - 544 с.

4. Чарнецки К., Айзенекер У. Порождающее программирование. Методы, инструменты, применение. - СПб.: Питер, 2005. - 736 с.

5. Грибова В. В., Клещев А.С. Управление проектированием и реализацией пользовательского интерфейса на основе онтологии // Пробл. управл. - 2006. - № 2. - С. 58-62.

6. Фереферов Е.С., Хмельнов А.Е. Язык представления баз данных // Инфокоммуникационные и вычислительные технологии и системы: материалы III Междунар. конф. - Улан-Удэ: Изд-во БГУ,

2010. - С. 269-272.

7. Фереферов Е.С., Бычков И.В., Ружников Г.М., Хмельнов А.Е. Инструментальное средство автоматизации создания приложений баз данных на основе декларативных спецификаций // Вестн. Бурят. гос. ун-та. - 2011. - № 9. - С. 118-122.

8. Aho A.V., Lam M.S., Sethi R., Ulman J.D. Compilers. Principles, techniques and tools: Second Edition // Addison-Wesley Publishing Company, Inc. 2008.

9. Фереферов Е.С., Хмельнов А.Е. Реализация менеджера размещения визуальных компонентов в Delphi // Вычислительные и информационные технологии в науке, технике и образовании: материалы Междунар. конф. - Алматы; Новосибирск, 2008. - Т. 13. - С. 283-287.

10. ГИС Панорама. URL: http://www.gisinfo.ru

Фереферов Евгений Сергеевич, научный сотрудник ИДСТУ СО РАН, 664033, г. Иркутск, ул. Лермонтова, 134, тел. (395-2) 453071, e-mail: [email protected]

Хмельнов Алексей Евгеньевич, кандидат технических наук, заведующий лабораторией ИДСТУ СО РАН, тел. (395-2) 453071, e-mail: [email protected]

Fereferov Evgeny Sergeevich, researcher, Institute for System Dynamics and Control Theory SB RAS, 664033, Irkutsk, Lermontov str., 134, e-mail: [email protected]

Khmelnov Alexey Evgenievich, candidate of technical sciences, head of laboratory, Institute for System Dynamics and Control Theory SB RAS, e-mail: [email protected]