1. Альтернативные подходы

Хотя, как уже говорилось выше, в настоящее время интерес к данной проблематике растет, большинство исследований пока сосредоточены на поисках адекватного формального аппарата для описания преобразования и синхронизации различных моделей [27,37,55,63,78,93]. Теория в данном случае пока отстает от практики потребности пользователей (в данном случае - программистов) заставили большинство производителей средств разработки, содержащих те или иные генераторы кода, добавить в свои продукты соответствующую поддержку. Поэтому в дапном обзоре мы будем рассматривать, в первую очередь, существующие промышленные решения.

В настоящий момент наиболее распространенными видами генераторов кода являются компиляторы, мастера (wizards) и генераторы, встроенные в различные CASE-пакеты.

В большинстве компиляторов есть возможность состыковывать сгенерированный код с модулями (библиотеками процедур, классов и т.д.), написанными непосредственно на целевом языке (языке, в который осуществляется трансляция). Для использования таких модулей требуется описать их сигнатуру в терминах исходного языка (языка, подающегося на вход транслятору). Кроме того, в ряде компиляторов (например, Microsoft Visual C++[15], Turbo Pascal [21] и др.) предусмотрена возможность использования «ассемблерных вставок» - добавление фрагментов кода на целевом языке непосредственно в код на исходном языке.

В отличие от компиляторов, исходная модель для которых - набор файлов, определяется до их запуска, мастера строят эту модель в диалоге с пользователем. После генерации построенная модель обычно либо забывается (как, например, в генераторах экранных форм, встроенных но многие средства разработки - например, ERwin [6] и Microsoft Acccss [24]), либо сохраняется в сгенерированном коде в форме специфических комментариев и при следующем запуске мастера восстанавливается из них - так работают, например, мастера создания классов (Class Wizards) в Microsoft Visual Studio [15]. Собственно генерация осуществляется этими мастерами только один раз, при создании класса. При этом создается единая модель, хранящаяся в файлах с исходными текстами класса и представляются собой программный код, размеченный специальными комментариями. Нся дальнейшая работа над классом с помощью мастера является модификацией этой модели.

Существует, однако, ряд мастеров, в которых исходная модель сохраняется, а генерация основываегся на применении шаблона объектно-ориентированного проектирования «Generation Gap» [4]. Использование этого шаблона предполагает д.ш каждого создаваемого модуля генерацию двух классов - предка, содержащего всю функциональность, и наследника, ничего не добавляющего к функциональности предка. При последующей перегенерации перегенерируется только класс-предок. Все «ручные» изменения вносятся в код наследника. Такой подход реализован, например, в системах ibuild [101]. Гопе [49}, Orbix [96J.

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

UML не предоставляют четких рекомендаций по связыванию функционалистики системы, которую предлагается описывать на диаграммах случаев использования, с се реализацией, осуществляемой классами и их членами. Соответственно, многочисленные CASE-пакеты, основанные на лом языке, не содержат автоматизированных средств для поддержки соответствия между высокоуровневыми и реализационными моделями. Поэтому данный обзор ограничивается рассмотрением связи реализационных диаграмм с исходным кодом. Эту связь будет рассмотрена на примере двух популярных объектно-ориентированных CASE-пакетов — Rational Rose и Together, использующих для этой цели различные подходы.

Механизм поддержки циклической разработки Rational Rose [87] наиболее полно реализован в расширении для Си-[86]. Ко модели классов осуществляется генерация скелета кода, т.е. кода без реализации методов. В случае изменения скелета в коде требуются построить на его основе новую модель в Rational Rose с помощью специальной утилиты реверс-инжиниринга. После этого с помощью специальной утилиты сравнения можно сравнить построенную модель с исходной и ьнссти соответствующие изменения в исходную модель. При перетеиерации методы, у которых есть тела, оставляются без изменений.

В Together [100] модель классов, по которой осуществляется генерация, синтаксически эквивалентна модели классов целевого языка (в данном случае - Java). Этим данный пакет отличается от предыдущего, в котором модель классов является универсальной и может содержать элементы, отсутствующие в языках программирования (например, дискриминаторы наследования). При этом Together хранит информацию о модели классов непосредственно в виде исходных текстов на языке java, сохраняя в своем внутреннем формате только ту информацию, которая не влияет на семантику кода, а отвечает за его визуализацию. Таким образом, файлы с исходными текстами, с точки зрения Together являются элементом модели проекта, поэтому генерации как таковой не происходит.

Огсутствие возможности синхронизировать высокоуровневые диаграммы с кодом не позволяет говорить о поддержке итеративного модельно­ориентированного подхода в рассмотренных CASE-пакетах, а только об итеративном визуальном моделировании.

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

Наиболее полное, на наш взгляд, из этих решений, представлено в пакете ERwin, поэтому именно оно и будет рассмотрено ниже.

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

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

Надо отмстить, *гто собственно задаче сохранения содержимого базы данных при ее и шенении, правда, без связи с ее разработкой с помощью CASE-пакетов, посвящено достаточно большое количество работ [84,89,95]. Общепринятыми являются следующие определения [88]:

Модификацией схе,чы данных называется внесение изменений в схему БД, содержащей данные.

Эволюцией схемы данных называется внесение изменений в схему заполненной базы данных без потери данных.

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

Большинство публикаций посвящено именно последнему вопросу [29,30,46,73,74], поскольку весьма распространенной является ситуация, когда с одной базой данных работает несколько приложений, и изменения, вносимые в схему в интересах одного из этих приложений, не должны отразиться на работоспособности всех остальных. Однако предлагаемые решения обычно содержат требования по поддержке средствами СУБД различных видов темпоральных данных и специальных конструкций языков запросов.

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

В настоящее время исследования в области именно эволюции схемы сместились от реляционных к объектным и XML-базам данных, при этом наиболее распространенным подходом ямляется выделение инвариантов, которые должны сохраняться при любых модификациях схемы [16,73,83]. При изменении схемы разработчиком, если это изменение нарушает инварианты, система автоматически дополняет его последовательностью «компенсационных» изменений, которые вновь приводят схему в состояние, удовлетворяющее инвариантам, а если это невозможно - изменение отклоняется. 11о сути, инварианты определяют «костяк» схемы данных - т.е. то ее подмножество, которое наиболее значимо и не подлежит изменениям.

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

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

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