Использование XML-технологий в разработке СУБД-приложений Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 519.683.8

ИСПОЛЬЗОВАНИЕ ХМЬ-ТЕХНОЛОГИЙ В РАЗРАБОТКЕ СУБД-ПРИЛОЖЕНИЙ

© 2004 г. А.П. Малышевский, А.Н. Литвиненко, Е.В. Пэк

Наша конечная цель-расширяемое программирование.

Н. Вирт

In given article is considered row of the problems, in accordance with painless and techno-

logical program maintenance and is offered new approach of the development supported

DBMS-application, founded on joint use XML-technology and classical programming.

Введение

Процесс сопровождения программной системы занимает примерно 80 % от жизненного цикла программы, а разработка приложения - 20 % [1]. Однако основной программный инструментарий «заточен» под быструю разработку приложений, а не под удобное и технологичное сопровождение уже работающей программы.

Центральным моментом сопровождения приложения является внесение в него очередного содержательного изменения. Эго, говоря языком баз данных, транзакция: перевод приложения из одного работоспособного состояния в другое, но с новым содержательным свойством (или отсутствием уже существовавшего свойства). Этот процесс занимает 90 % забот разработчика и администратора приложения. Оказывается, что при выполнении такого рода транзакций появляются проблемы, связанные с безболезненностью и технологичностью (удобством) внесения изменений. Здесь и далее безболезненность (метод внесения изменений в программу называется безболезненным, если его применение не нарушает работоспособность ранее отлаженных версий) употребляется в рамках терминологии М.М. Горбунова-Посадова [2].

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

Факторы инструментальных сред разработки, затрудняющие процесс внесения изменений

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

1. Рассредоточенность фрагментов текста программы, реализующих многие содержательные функции. Действие (или функция) называется рассредоточенным, если его программная реализация представляет собой несколько фрагментов, находящихся в разных местах программы (в отличие от сосредоточенных действий, реализуемых одним таким фрагментом) [3, 4]. Таким образом, внесение изменений в единую, с нашей точки зрения, функциональность увеличивает вероятность ошибки минимум в столько раз, сколько рассредоточенных фрагментов текста реализуют данную функциональность. А это в свою очередь не отвечает требованиям безболезненности.

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

3. Невозможность многомерного структурирования с точки зрения нашей собственной логической модели программы и, как следствие, многомерный анализ программы. В объектно-ориентированном программировании, самом популярном на сегодняшний день, структуризация идет по методам объектов (классов) и по самим объектам.

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

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

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

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

Не всегда имеется двунаправленная связь между конструктором и текстом программной системы. Некоторые элементы, к примеру, экранной формы, не имеют текстового эквивалента.

Закрытость некоторых свойств экранных форм от программной реализации уменьшает гибкость работы с ее программными эквивалентами.

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

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

Предлагаемый подход с использованием ХМЬ-технологий

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

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

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

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

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

Основная цель достигается также за счет того, что программа становится более регулярной. Эго означает, что принимаемые соглашения материализуются в виде некоторых программных модулей, причем таким образом, что их нарушить просто невозможно. Реализация соглашений в виде программных модулей включается в обшую технологическую цепочку разработки приложения. Идея реализации регулярных правил, предлагаемая нами, заимствована из мира HTML-программирования и связана с понятием «стиля». Применение понятия «стиля» к классу СУБД-приложений дает отделение содержательной части программы, ее внутренней структуры, которая может быть достаточно сложной, от того, как эта информация будет преподноситься.

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

Удобным инструментом для реализации такого подхода на практике и тем альтернативным средством разработки, которым предлагается дополнять классическое программирование, оказались XML-технологии.

Язык XML, представляющий собой вид атрибутированного дерева рекомендуется использовать для описания собственных объектов, их структуры и поведения, язык XSLT - для отображения собственных объектов в объекты конкретной инструментальной среды и языка программирования. При этом в XSLT материализуются регулярные правила. Для проверки корректности XML-моделей возможно использовать язык XSD.

Одна итерация применения XML-технологий делится на два этапа: разработка XML-модели объекта программы и разработка XSLT-транс-формации, которая преобразует XML-модель объекта в программный код на конкретном языке программирования (рис. 1).

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

Рис. 1

Языки XML, XSLT имеют древовидную структуру, результат их применения - тоже [5]. Это позволяет в программных системах строить многоуровневую модель XML и выходить на более высокие уровни абстракции (рис. 2).

Рис. 2

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

1. Вертикальное: от менее абстрактных моделей объектов к более абстрактным и высокоуровневым (рис. 3).

Рис. 3

Например, можно построить ХМЬ-модель для экранной формы общего вида и с помощью регулярных правил переводить ее в модель конкретной инструментальной среды разработки. Далее возникает потребность в построении ХМЬ-модели специализированных экранных форм, к примеру, «условий доя отчетов» (рис. 3). Они представляют собой группы элементов управления доя работы и реакцию на их использование.

Хорошим примером «условий для отчета» может служить «выбор периода отчета» (рис. 4), представляющего собой пять элементов управления. В ХМЬ-модели это единый, сосредоточенный в одном месте по тексту элемент, тогда как в общей ХМЬ-модели - 5 элементов: два текстовых поля, два поля доя ввода информации и кнопка, а в модели среды разработки количество сосредоточенных фрагментов, описывающих «выбор периода отчета», еще больше.

Период с: II • . по:

Рис. 4

Переход между моделями разных уровней осуществляется на базе регулярных правил, материализованных в ХБЬТ.

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

2. Горизонтальное направление: движение от разрозненных моделей схожих объектов к одной, единой доя всех этих объектов (рис. 5).

Рис. 5

Например, рассмотрим такие объекты СУБД-приложений, как таблица, Remote View и справочник. Таблица - основной объект реляционных баз данных. Remote View - удаленное параметризованное представление таблицы или нескольких таблиц. Справочник - экранная форма с данными из конкретной таблицы. Оказывается, что доя всех этих объектов можно построить единую XML-модель, которая будет содержать гораздо меньше параметров и информации, чем при описании каждого объекта отдельно.

3. Консолидирующее направление: реализация механизма точек присоединения как одного из подходов применения хорошо известной технологии «plug-in-play» [6,7].

Заключение

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

однородных объектах системы, а это, в свою очередь, достигается за счет введения более высокоуровневых и более декларативных объектов.

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

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

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

Существует и ряд недостатков при использовании подхода:

1. Увеличивается первоначальное время на проектирование и разработку приложения.

2. Повышаются требования к уровню знаний программиста. Помимо знания инструментальной среды, необходимо владение XML-технологиями.

3. Возрастает громоздкость системы.

4. В полной мере реализовать данный подход можно только в интерпретируемых языках программирования.

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

Литература

1. Зелкотц М., Шоу А., Гэннон Дж. Принципы разработки программного обеспечения: Пер. с англ. М., 1982.

2. Горбунов-ПосадовММ. II Открытые системы. 1996. № 4. С. 65 - 70.

3. ФуксманАЛ. Технологические аспекты создания программных систем. М., 1979.

4. Горбунов-ПосадовММ.. Расширяемые программы. М., 1999.

5. ВаликовА.Н. Технология XSLT. СПб., 2002.

6. Салтыкова Н.Н. Разработка метода проектирования модифицируемых СУБД-приложений: Дис. ... канд. техн. наук. Ростов н/Д, 2002.

7. Салтыкова H.H., Литвиненко А.Н. // Изв. вузов. Сев.-Кавк. регион. Технические науки. 2002. №3. С. 5-11.

Ростовский государственный университет 22 декабря 2004 г.