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

А.С.Дружинин

При создании любого приложения разработчику приходится постоянно решать две проблемы:

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

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

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

Во многом это происходит потому, что "переменной" частью преобразования является сторона клиента, а структура данных в СУБД не меняется. На самом деле обе эти структуры данных в смысле подверженности преобразованиям должны быть совершенно равноправны. Если в СУБД кроме самих данных хранить и описания их структур, и правила преобразования одних структур данных в другие, это позволяет существенно расширить гибкость системы. Ровно таким путем пошли создатели XML-XSL:

• XML описывает структуры данных (документы)
• XSL задает правила преобразования XML-документов в HTML-представление.

Последнее, кстати, является частным случаем, и, естественно, на практике будет существенно расширено в плане преобразования одних структур данных в другие. XSL фактически состоит из двух крупных компонент:

1. Селекторов, задающих способ отбора элементов XML-документа (метод Next)
2. Собственно правил преобразования "значений" этих элементов в новый документ (метод Get)

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

Такой объект мы назовем виртуальным документом. У него есть набор свойств, описанных выше, и один-единственный метод - Create. (методы Next и Get естественно отнести с свойствам этого объекта). Такой подход к созданию приложений давно и с успехом применяется в СП.АРМ. Базируется он на уникальных возможностях СУБД Cache и языка CacheObjectScript. Потребовалось разработать систему описания свойств виртуального документа и базовый набор методов для интерпретации этих свойств, что и было сделано в среде qWORD-PRO. Как только этот набор свойств и методов устоялся, в дальнейшем практически не требовалось написания программного кода. Основное внимание разработчика сосредотачивается на отображении требуемых пользователю документов на одну-единственную, весьма общую структуру данных - виртуальный документ, и применении стандартного цикла для порождения новых экземпляров документов.

В качестве базовой структуры данных была взята запись:

Record[Key].Attr[i]

Attr[i]- имена атрибутов этой записи.

Сама запись может иметь рекурсивную структуру: Record1[Key1].Record2[Key2]...

Схематическое DTD в XML-тегах см.ниже

Фактически, был использовано два XML-тега, Запись(Record) и Атрибут(Attr) с разными DTD: в теле Атрибута не может быть Записи, в теле записи могут быть как Записи, так и Атрибуты. Если выражаться в терминах деревьев, использовалось дерево специального вида, причем способ отображения логического дерева на физическое таков, что всегда однозначно можно определить, к чему относится данный индекс - к ключу записи, или же к атрибуту (самим атрибутам никто не мешает иметь деревянную структуру). В терминах реляционных баз данных использовалась совокупность иерархических реляционных таблиц. Функциональная часть технологии (методы) также по смыслу аналогична XML-XSL: один набор методов позволяет отбирать необходимые экземпляры документов, второй создает новые экземпляры на основе интерпретации описаний. Поскольку в результате получаются данные с допустимой структурой, к ним сразу же может применяться стандартный набор методов.

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

1. "Навигационный" - позволяет просмотреть и отобрать совокупность документов, необходимых для дальнейшей работы. Снабжен стандартным набором функций - задание фильтров, работа с совокупностями экземпляров документов, переход к другому документу(документам), связанным с данным, выполнение запроса (т.е. создание новой совокупности экземпляров документов в соответствии с описанием)
2. "Просмотр-редактирование" экземпляра документа.

Унификация экранов по функциям и элементам управления упрощает освоение приложения пользователями - достаточно научиться работать всего с двумя типами экранов.

Такой подход позволяет очень быстро создавать скелет приложения, не дожидаясь, когда будет создана полная постановка задачи (а всем разработчикам известно, что этого не происходит никогда) - ведь мы в любой момент можем сменить набор используемых документов, модифицировать их структуру. Чрезвычайно удобно оказалось создание на основе технологии виртуального документа всевозможных конверторов, аналитических запросов, справок, отчетов, описываемых ровно также, как и реальные документы, хранящиеся в базе данных. Печатные формы описываются точно таким же образом, с окончательным преобразованием в HTML-код и отображением либо IE4(5), либо в Microsoft Word-2000.

Рассмотрим вопросы практического применения этой технологии. В своей практике мы сталкивались со следующими вариантами:

1. Создание приложения с "нуля"
2. Модификация приложения, изначально разработанного в технологии виртуального документа
3. Модификация приложения, состоящих из разнородных баз данных, в основном с целью получения сводных аналитических данных.

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

Третий вариант реализовывался по примерно такой схеме:

1. Определялись виды документов, которые были нужны пользователям, и которые не могли быть получены в существующей системе.
2. Описывались виртуальные документы, с помощью которых можно было отображать существующие БД в требуемом виде.
3. В новой БД создавались экземпляры этих документов, и дальнейшая работа во многом могла быть сведена с именно этими данными.
4. По мере необходимости, часть задач и данных переводилась в новую технологию без нарушения промышленной эксплуатации имеющейся АСУ.

Заключение.

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