В этой статье несколько оторвемся от вопросов проектирования конкретных структур в базах данных («Мир ПК», ‡‚3/07, с. 72, ‡‚5/07, с. 64) и попытаемся воспарить на более абстрактный уровень модели предметной области, чтобы оттуда взглянуть на остро стоящие по сей день вопросы внесения изменений в процессе разработки.

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 2. Датацентричная стратегия

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

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

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

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

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

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

 

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

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

Таблица 2. Все использованные в примере скрипты
Для генерации слоя доступа к данным используется немного модифицированный стандартный шаблон для C#.NET (файл csharp.xol), который входит в состав PowerDesigner. Этот шаблон должен располагаться в подкаталоге Resource FilesObject 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).

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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