От редакции. В продолжение темы статьи: система разработки на основе моделей GenieLamp. Кросс-платформенное решение для Windows/Linux и различных СУБД.

Статья опубликована в журнале "Мир ПК" №6-2007

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

Введение

Известный эксперт Мартин Фаулер в своей книге «Архитектура корпоративных программных приложений» называет три типовых подхода к проектированию, среди которых выделяет образец под названием «модель предметной области» (Domain model, далее по тексту МПО). Конечно, решений существует больше, просто уважаемый автор и признанный эксперт является, как он сам пишет, «стойким сторонником объектной парадигмы» с большим опытом реальных проектов, соответственно другие подходы, в том числе комбинированные, вряд ли могут его заинтересовать.

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

В архитектуре МПО у нас есть множество классов, описывающих сущности предметной области, и база данных (БД), в которой хранится состояние объектов. В подавляющем большинстве случаев БД будет реляционной на основе одной из промышленных СУБД, таких как MS SQL Server, Oracle и т.д. Реляционная и объектная модели являются ортогональными (описывающими одни и те же структуры под разным углом зрения). Это означает, что необходимо, как минимум, следующее:

• реализовать отображение (mapping) реляционных структур на объекты, и наоборот;
• поддерживать обе модели в синхронном состоянии.

Несомненно, во многих случаях программисту удобнее работать с объектами, чем с табличными наборами данных (Data Set). Однако, как пишет сам Фаулер, примерно треть затрат при разработке и последующем сопровождении уходит на отображение и поддержание моделей в синхронном состоянии. Делать это придется всякий раз при внесении изменений в МПО, поэтому такие затраты автор справедливо относит к постоянным. Хотя на рынке достаточно большой выбор готовых средств объектно-реляционной проекции (ОРП, или ORM — Object Relational Mapping), большинство из них выполняют только свою основную задачу отображения, никак не влияя на процесс внесения изменений.

Давайте сделаем небольшое отступление на тему архитектур и разработки «от модели».

Зацикливание

Зачем вообще нужно управлять внесением изменений? На первый взгляд все просто: поставили задачу, спроектировали предметную область, реализовали систему, запустили в работу...

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

Классическая схема типа «водопад» подразумевает последовательное прохождение стадий: от анализа до приемочных испытаний. Упор делается на глубокий анализ предметной области, создание моделей, тщательную проработку архитектур. Соответственно эта стадия является наиболее ответственной и длительной. Весьма вероятно, что в это время у заказчика возникнет желание изменить или уточнить свои требования. Тогда процесс возвращается на исходную точку и повторяется. Так как требования в условиях динамичного окружения бизнеса могут меняться часто, то «водопад» просто зацикливается на первой стадии.

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

В один прекрасный день наступает «момент истины», когда по требуемым усилиям дальнейшая факторизация становится сравнима с полной переделкой системы. Вот таким образом agile-методологии типа экстремального программирования тоже приводят к зацикливанию, но на стадии реализации.

Модель-ориентированная архитектура

В последнее время много внимания в публикациях отводится теме архитектуры и разработке на основе моделей MDA (Model Driven Architecture) и MDD или MDSD (Model Driven Software Development). В отечественной практике устоявшихся терминов еще не возникло, поэтому я буду называть их МОА (модель–ориентированная архитектура) и МУР (модель–управляемая разработка). Не вдаваясь в подробности этих направлений, выделим только ключевые моменты.

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

Классический и относительно простой пример из этой серии, который используется уже давно, — моделирование баз данных. На основе одной концептуальной модели данных вы можете поддерживать несколько связанных с ней физических моделей для различных СУБД.

С появлением UML (Unified Modeling Language — унифицированный язык моделирования) и поддерживающих его инструментов появилась возможность работать по аналогичной схеме в терминах объектов. При этом сам UML имеет самый низкий уровень абстракции, это сырье для ваших моделей, а собственно МОА начинается, когда вы создаете свои стереотипы, параметры и настройки и определяете правила генерации кода и данных для нижестоящего уровня.

По-видимому, наиболее мощной и высокоуровневой практической реализацией идей MDA на сегодня является инструментарий ARIS Toolset, предназначенный для моделирования информационных систем управления предприятием.

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

Основные стратегии применения МОА для приложений баз данных

Прежде чем рассматривать стратегии, договоримся об используемых терминах. Названия направлений носят весьма условный характер (терминология еще не сформировалась) и определяются акцентом, отправной точкой моделирования, выбранной в соответствии с исходными условиями. Термины «физическая модель данных» (ФМД) и «объектно-ориентированные модели» (ООМ) используются в понятии инструмента моделирования Sybase PowerDesigner (15-дневную версию вы можете загрузить с сайта производителя). ФМД подразумевает описание структур и запросов к данным с учетом специфики конкретных СУБД, а ООМ — совокупность диаграмм, использующих нотацию UML.

Объектно-центричная стратегия. Ядром разработки являются ООМ, в минимальном случае — диаграмма классов. Все структурные изменения вносятся на уровне ООМ, и из нее же генерируется ФМД. В рамках этой стратегии с наименьшими затратами обеспечивается независимость от типа СУБД.

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

Датацентричная стратегия. Ядром разработки  является ФМД, как правило восстановленная (reverse engineering) из существующей БД. Все структурные изменения вносятся на уровне ФМД, и ООМ (диаграмма классов) также восстанавливается по ФМД или синхронизируется с ней.

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

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

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

Краткое описание цикла внесения изменений

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

В качестве первого шага можно перейти с какой-либо устаревшей или немасштабируемой СУБД. Например, часто мигрируют с MS Access на полноценную клиент-серверную СУБД.

На схеме этот этап не отображен, однако с помощью PowerDesigner вы можете достаточно просто получить физическую модель данных из старой БД и трансформировать ее в ФМД, соответствующую целевой СУБД. Если таковых будет несколько, нужно условно выбрать «главную» (на рис. 2 она показана как ФМД БД1). Если перехода в рамках проекта не предусмотрено, то «главная» ФМД получается восстановлением из существующей БД, минуя этап трансформации. Как правило, этот этап разовый либо очень редкий.

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

Итак, отправной точкой будет внесение изменений в главную ФМД. После нормализации средствами PowerDesigner из главной ФМД генерируется объектная модель (ООМ, диаграмма классов). Зачем она нужна? На ее основе мы создаем следующее:

• Слой доступа к данным — DAL (Data Access Layer), который представляет собой множество постоянных объектов (persistent objects) для используемого вами средства объектно-реляционной проекции ОРП. В примере использовались средства NHibernate и XPO.
• Произвольное количество ФМД для других целевых СУБД.
• Схемы отображения (mappings) для каждого ОРП и СУБД.

После восстановления из ФМД объектную модель также следует нормализовать и проверить с помощью соответствующих VBA-скриптов (табл. 2).

Для генерации слоя доступа к данным используется немного модифицированный стандартный шаблон для C#.NET (файл csharp.xol), который входит в состав PowerDesigner. Этот шаблон должен располагаться в подкаталоге \Resource Files\Object Languages относительно каталога установки PowerDesigner.

В общем виде порядок внесения изменений таков.

1. Изменяем главную ФМД.
2. Проверяем ФМД. В среде PowerDesigner выбираем нужную ФМД и проверяем ее целостность (клавиша F4 или команда меню Tools - Check model... ). Если PowerDesigner не обнаружил ошибок, то переходим к следующему шагу.
3. Нормализуем ФМД. Запускаем скрипт 1-Normalize reversed PDM.vbs и по завершении его работы проверяем наличие ошибок в журнале (log). Если ошибок не обнаружено, то можем создать новую БД или модифицировать имеющуюся прямо из PowerDesigner либо сгенерировать соответствующий SQL-скрипт для запуска из консоли. Выбираем ФМД и нужный пункт в меню Database.
4. Создаем ООМ. В меню Tools - Generate Object-Oriented model выбираем Updating existing model (Обновить существующую модель; в первый раз вам нужно будет ее создать) и отключаем опцию Preserve modifications.
5. Нормализуем ООМ. Выбираем созданную ООМ и последовательно запускаем скрипты 2-Normalize reversed OOM.vbs и 3-Check OOM.vbs. Если ошибок не обнаружено, переходим к следующему шагу.
6. Генерируем DAL. Из активной ООМ выбираем в меню Language - Generate C# code, устанавливаем необходимые опции и запускаем генерацию. После окончания необходимо будет включить новые файлы в проект в среде Visual Studio и перекомпилировать сборку.
7. Генерируем схему отображения (mapping). Запускаем скрипт 4-Generate NHibernate mapping.vbs, который создаст схему отображения (XML mapping schema) для NHibernate между БД и DAL, созданным на предыдущем этапе. Аналогичную схему можно получить и для XPO.

В данном цикле для простоты мы опускаем этап генерации ФМД из ООМ для других целевых БД и соответствующих схем отображения для них. На рисунках они показаны как «Схема отображения для БД2».

Упрощаем

В приведенных схемах предполагается использование инструментария Sybase PowerDesigner и Microsoft VisualStudio .NET. На самом деле эти ограничения непринципиальны, вы можете использовать любой другой, более подходящий для проекта инструментарий.

Чем в нашем случае удобен PowerDesigner? Он умеет корректно преобразовывать ФМД в ООП и обратно, а также генерировать каталог БД и код классов доступа к данным выбранного языка программирования.

На самом деле ООМ может быть вообще удалена из датацентричной схемы (рис. 3).

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

Поддержка пользовательских атрибутов. Встроенный макроязык для манипуляций объектами среды моделирования. Например, таковым является Microsoft Visio из семейства продуктов Office. Это очень гибкий инструмент рисования диаграмм, но средства генерации в нем развиты плохо, и надо быть готовым к написанию большого количества кода на VBA. Неплохой идеей было бы найти подходящий бесплатный CASE-инструмент для моделирования БД и адаптировать его к генерации слоя доступа к объектам. Наконец, некоторые ОРП, например LLBLGen Pro или Vanatec OpenAccess, содержат средства моделирования, которые генерируют каталог БД и схему отображения.

Но и это не все. В принципе можно обойтись инструментом без встроенного языка: в этом случае он должен поддерживать COM-интерфейсы для доступа к объектам приложения. Тогда вы сможете написать скрипты или программу для генерации в любой среде, поддерживающей COM, включая Windows script hosting.

[ Файлы скриптов (zip)