А. М. Кондратьев.
CASE-СРЕДСТВА И OБЪЕКТНЫЕ БАЗЫ ДАННЫХ
При разработке сложного программного обеспечения в последнее время все большее распространение получает UML [1] (стандарт OMG [2]) — язык визуального объектно-ориентированного моделирования. Но когда дело доходит до разработки базы данных, то широко распространенной практикой является создание моста из CASE-средства, реализующего UML, в другое CASE-средство, ориентированное на базы данных, например ERwin и проектирование базы данных именно в нем (т.е. не с помощью UML).
Поскольку UML предлагает объектно-ориентированный подход, то и базы данных естественно разрабатывать тоже объектно-ориентированными. Но в этой области пока не существует широко используемых разработок, чаще принимаются реляционные СУБД. Однако и они не всегда удовлетворяют разработчиков своими выразительными средствами. Поэтому в рамках CASE-средства Real [3] было разработано технологическое решение, позволяющее создавать в расширенной модели классов UML схему базы данных и автоматически генерировать по ней, во-первых, саму базу данных (в любой реляционной СУБД, поддерживающей ODBC), во-вторых, ее объектно-ориентированный образ в виде классов С++ и COM [4]. Именно реляционные базы данных были выбраны потому, что они являются наиболее зрелыми из всех существующих ныне коммерческих СУБД. С другой стороны, объектно-ориентированное представление базы данных необходимо для единообразия абстракций, используемых при проектировании программного обеспечения и баз данных, и для более тесной интеграции самой базы данных и приложения, которое с ней работает. При разработке этого технологического решения мы широко пользовались рекомендациями ODMG [5].
Отметим, что сам программный продукт Real использует базу данных (репозиторий) для хранения информации о проекте, причем эта база данных создана (спроектирована и сгенерирована автоматически) с помощью представляемого здесь метода. Репозиторий Real также рассматривается в данной работе — его можно считать жизненным примером проекта, успешно реализованного с помощью нашего технологического решения. Мы также проводим сравнение нашего репозитория и репозитория Rational Rose [6].
1. Базы данных в Rational Rose
База данных проекта. CASE-средство Rational Rose фирмы Rational Software Corp. предлагает разработчику с помощью UML проводить анализ и проектирование программного обеспечения. В графическом редакторе разработчик строит различные модели обеспечения с помощью диаграмм случаев использования, диаграмм классов, диаграмм сценариев и т.д. Данные этих диаграмм сохраняются в специальной базе данных. Когда Rational Rose запущен и пользователь работает над проектом, эта база данных находится целиком в оперативной памяти. При выходе из проекта информация сохраняется в текстовом файле, при повторном обращении к данным проекта содержимое этого файла снова загружается в оперативную память.
Авторы Rational Rose отмечают, что хранение модели в текстовом файле предпочтительнее, потому что разработчик не привязан ни к определенной СУБД, ни к операционной системе. Существуют версии Rational Rose как для Windows, так и для Unix, и авторам, вероятно, хотелось обеспечить их совместимость. В Real применен другой подход к хранению данных проекта: они размещаются в полноценной базе данных — репозитории.
Rational Rose для Windows как сервер Автоматизации [4] предоставляет набор COM-объектов для доступа к содержимому базы данных проекта. Причем работу с этими объектами можно осуществлять как из встроенного в Rational Rose языка скриптов (типа Visual Basic), так и из других приложений, способных быть клиентами Автоматизации. Система объектов предоставляет удобный способ перемещаться по данным о проекте и получать необходимую информацию в терминах элементов модели проекта. Например, можно взять набор всех классов модели, у каждого класса взять набор ассоциаций, в которых он участвует, у ассоциации посмотреть и установить различные атрибуты. В Real тоже есть возможность доступа к данным репозитория через программный интерфейс с помощью механизма Автоматизации.
Главное преимущество организации репозитория в Rational Rose — быстродействие. Работа с данными в оперативной памяти происходит существенно быстрее, чем обращения к базе данных на диске. Однако при этом подходе нельзя реализовать такие возможности, как полноценный многопользовательский доступ, обеспечение целостности данных, использование языка запросов (SQL) в скриптах.
В Real все эти возможности присутствуют благодаря использованию СУБД для хранения репозитория.
Многопользовательский доступ. В Rational Rose модель проекта находится в памяти одного экземпляра приложения и недоступна с других рабочих мест. Авторы Rational Rose предлагают способ обойти это ограничение: надо создать общий файл с данными проекта, который аккумулирует изменения всех разработчиков. Каждому разработчику назначается своя часть проекта, которую он развивает. Он копирует себе этот общий файл и, работая с копией, может вносить изменения только в свою часть проекта. Затем его изменения заносятся в общий файл. При этом настройка многопользовательского доступа в Rational Rose требует дополнительных усилий. Поддержка многопользовательского доступа к репозиторию Real обеспечивается естественным образом — качественная реляционная СУБД (например, Oracle), отвечающая за хранение репозитория, позволяет блокировать записи при их чтении и модификации, чем и разграничивает доступ к репозиторию из разных процессов.
Целостность данных. При возникновении исключительной ситуации и аварийном завершении Rational Rose все изменения, выполненные в оперативной памяти, будут потеряны. В Real же все данные проекта постоянно хранятся в СУБД, поэтому потеряны не будут. Кроме того, при внесении изменений в репозиторий Real используется механизм транзакций, что позволяет гарантировать не только сохранность, но и непротиворечивость данных модели.
Язык запросов. В скриптах для репозитория Real наряду с объектно-ориентированным стилем доступа поддерживается и выборка объектов с помощью SQL-предложения. В Rational Rose такой возможности нет.
Генерация баз данных. В Rational Rose есть простейшие возможности автоматизированной разработки реляционных баз данных. В модели классов у каждого класса можно указать, является ли он временным (transient) или постоянным (persistent). Экземпляры временных классов существуют только во время работы программы, а экземпляры постоянных классов сохраняются в базе данных и после окончания работы программы. По модели классов Rational Rose позволяет сгенерировать описания классов, заголовки их методов и для постоянных классов программу создания реляционной базы данных на языке SQL DDL. Более сложные понятия реляционной модели, такие как представления (view) и индексы, в Rational Rose не поддерживаются. А в Real эти понятия есть.
Рассмотрим, каким образом Rational Rose преобразует понятия модели классов UML в элементы реляционной базы данных. Каждому классу сопоставляется таблица в базе данных, в полях которой хранятся атрибуты и связи экземпляров данного класса. Если у класса есть предок, то в таблице этого класса есть поле, указывающее на строку таблицы предка. Унаследованные атрибуты и связи хранятся в таблице предка. Для каждого класса, имеющего предков, описывается представление, которое позволяет собрать все атрибуты и связи объекта из нескольких таблиц. Та же идея реализации наследования используется и в базах данных Real. И в Rational Rose, и в Real поддерживаются только ассоциации один к одному и один ко многим, как и в реляционной модели данных.
В Rational Rose отсутствует связь генерируемого кода на языке C++ с базой данных: генерируются только заголовки методов классов, а всю работу с базой данных, отображение данных из таблиц в объекты языка программирования разработчик должен написать самостоятельно, пользуясь встроенным языком скриптов и информацией из базы данных проекта. Никаких стандартных скриптов для генерации кода доступа к базе из программ на языке C++ с Rational Rose не поставляется. Конечно, заготовки кода, генерируемого в Rational Rose, достаточно универсальны и подходят для любого компилятора и СУБД, однако программистам придется изрядно потрудиться, чтобы реализовать доступ к базе данных, созданной в Rational Rose.
В Real эта задача решена. По модели классов проекта, не написав ни одной строчки кода, разработчик получает реляционную базу данных и библиотеку классов программного интерфейса для работы с этой базой. Программист может работать с экземплярами классов в терминах языка программирования, а программный интерфейс отражает эти действия в базе данных. Тем самым автоматически создается механизм доступа к базе данных из проектируемой в Real программы.
2. ODMG и Real
Международная группа ODMG (Object Data Management Group) объединяет ведущих разработчиков объектно-ориентированных баз данных (ООБД). Результатом деятельности этой группы является стандарт объектно-ориентированных баз данных. Последняя версия стандарта ODMG (версия 2.0) вышла в мае 1997 г. [5]. Цели этого стандарта — описать основные требования к объектно-ориентированным базам данных и интегрировать их с объектно-ориентированными языками программирования.
Мы не ставили перед собой задачу, чтобы репозиторий Real и базы данных, проектируемые с помощью Real, удовлетворяли стандарту ODMG. Однако при проектировании репозитория мы широко использовали рекомендации этого стандарта. Объектную модель (object model), язык описания объектов (object definition language, ODL), объектный язык запросов (object query language, OQL), связь объектов базы данных с объектами языка программирования (binding), язык манипулирования объектами (object manipulation language, OML) — все это определяет ODMG.
Для языков программирования C++, SmallTalk и Java определены синтаксические расширения для работы с объектно-ориентированными базами данных. Поскольку программный интерфейс баз данных Real реализован на языке C++, то мы остановимся лишь на связи стандарта ODMG и языка C++. Рассмотрим подробнее также каждую компоненту стандарта и укажем, как она соотносится с базами данных в Real.
Объектная модель. Единицей хранения в объектной базе данных стандарта ODMG является объект. Как в объектно-ориентированных языках программирования объекты ODMG имеют атрибуты и методы. Объекты связаны друг с другом отношениями, как и в реляционной базе данных. Однако в отличие от последних в ODMG отношения описаны явно и не являются частным случаем атрибутов. Каждый объект в базе данных имеет уникальный идентификатор, который используется для реализации связей между объектами. При изменении данных объекта значение идентификатора остается неизменным, благодаря этому в базе данных не нарушаются связи. Каждый объект является экземпляром некоторого типа. Совокупность всех объектов одного типа называется экстентом (extent). Тип объекта может иметь супертип, что означает наследование атрибутов, методов и отношений супертипа. До сих пор объектная модель, используемая в Real, не отличается от объектной модели ODMG.
Рис. 1. Пример моделирования отношения многие ко многим.
Отношение означает, что, имея один объект, можно получить связанный с ним отношением другой объект (другие объекты). Отношения бывают только бинарные: один к одному, один ко многим и многие ко многим. Если отношение один к одному, то по нему можно получить один объект, связанный с данным. Если отношение один ко многим, то мы получаем целый набор объектов. Программный интерфейс базы данных Real предоставляет такие возможности работы с отношениями. Однако в Real, в отличие от стандарта ODMG, не поддерживаются отношения многие ко многим. Мы предлагаем моделировать их с помощью введения дополнительного класса в схему базы данных (рис. 1).
Введение явным образом вспомогательного класса понижает уровень абстракции модели и может ухудшить ее восприятие, поэтому в Real планируется добавить возможность автоматической генерации такого вспомогательного класса. Однако иногда нужно явно обозначить вспомогательный класс, чтобы его атрибутами выразить дополнительные свойства ассоциации.
В объектной модели ODMG есть возможность работы с наборами объектов — множествами, мультимножествами1, списками, массивами. Они поддерживают операции вставки, удаления и перебора объектов. В базах данных Real есть возможность работы только с множествами и списками.
В описании объектной модели ODMG специфицируются операции работы с транзакциями (начать, закончить, откатить, откатить вложенную транзакцию до предыдущего уровня) и с самой базой данных (открыть, закрыть, найти объект по уникальному идентификатору). В программном интерфейсе баз данных Real есть такие же операции.
Язык описания объектов (ODL) предназначен для формального описания интерфейсов объектов объектно-ориентированных баз данных. Он является модификацией языка IDL (Interface Definition Language), созданного международной группой OMG [2]. Язык описания объектов служит для следующих целей:
Рис. 2. Пример использования языка описания объектов.
Определения схемы базы данных;
обеспечения универсальности описания схемы объектно-ориентированных баз данных (к базе данных, схема которой представлена на языке описания объектов, можно обращаться из программ на разных языках программирования: C++, SmallTalk, Java; ODL используется как «общий знаменатель» при описании схемы объектно-ориентированных баз данных);
Генерации типов из схемы объектно-ориентированных баз данных на конкретном языке программирования, из которого планируется доступ к ней.
Описание типа состоит из имени, списка предков, описания атрибутов, методов и отношений. При описании роли объекта в отношении указывается не только тип, но и роль противоположного объекта, чтобы можно было отличать разные отношения между одной парой объектов. Схема использования языка описания объектов показана на рис. 2.
При разработке репозитория Real сначала предполагалось использовать язык описания объектов. Но с развитием Real и усложнением структуры репозитория выяснилось, что текстовое описание громоздко и неудобно. Графическое представление значительно нагляднее, и мы стали использовать расширенную модель классов UML для описания схемы данных. Поэтому в Real исходными данными для задания схемы базы данных является не текстовое описание интерфейсов, а диаграмма классов UML, создаваемая в редакторе классов.
Объектный язык запросов (OQL) — декларативный язык обращения к базе данных, похожий на язык SQL для реляционных баз данных. Авторы стандарта ODMG утверждают, что выражения на объектном языке запросов на 90% совместимы с синтаксисом оператора select из SQL’92.
Отличия OQL от SQL заключаются в том, что входными данными запросов являются объекты, а не таблицы. В запросе можно указать, какие атрибуты из каких экстентов мы хотим выбрать, какие условия мы налагаем на множество объектов. Для записи запроса используется конструкция select-from-where, как и в SQL. В результате запроса на OQL можно получить как подмножество некоторого экстента объектов базы данных, так и сконструировать из атрибутов объектов другие типы данных, например структуру, массив или объект.
Результатом запроса обычно является набор объектов стандарта ODMG — множество. Затем это множество можно преобразовать в список, массив, мультимножество. Набор можно перебрать и получить его отдельные элементы — объекты базы данных целиком или совокупность значений из базы данных в виде любого типа языка программирования.
Программный интерфейс баз данных Real предоставляет менее богатые возможности запросов к базе данных, чем объектный язык запросов. Если в запросе на OQL можно из атрибутов объектов сконструировать значения разных типов данных, то в Real можно лишь наложить фильтр на набор всех объектов определенного типа с помощью SQL-предложения.
Связь объектных баз данных с программами на языке C++. Авторы стандарта ODMG отмечают особую важность связи базы данных с языками программирования и предлагают расширения существующих языков для простого и естественного доступа к объектно-ориентированным базам данных. Для использования базы данных стандарта ODMG в приложениях на языке C++ надо решить следующие вопросы:
отобразить язык описания объектов в язык C++;
встроить возможности объектного языка запросов в язык C++;
определить способы работы с объектами базы данных в языке C++, т.е. определить язык манипулирования объектами (OML).
Язык описания объектов достаточно естественно отображается в C++. Атрибуты, методы и наследование ODL переходят в соответствующие понятия языка C++. Отношения описываются не просто как атрибуты классов. Если бы отношения были представлены просто как ссылка из класса А на класс Б и ссылка из класса Б на класс А, то не было бы ясно, что обе ссылки относятся к одному отношению. Связанность ссылок нужна для обеспечения целостности отношения при создании, модификации и удалении последнего. Если мы хотим, например, связать два объекта, то достаточно лишь в первом объекте присвоить ссылку на второй. Обратная ссылка должна быть проставлена автоматически. Для обеспечения этой возможности надо знать, что обе ссылки относятся к одному отношению. Поэтому введено расширение языка C++, в котором есть дополнительное ключевое слово inverse. При описании отношения указывается ссылка на объект с другой стороны отношения, а после ключевого слова inverse — имя класса и имя ссылки с противоположной стороны отношения.
В Real и атрибуты, и операции, и отношения классов схемы базы данных реализованы методами классов языка C++. Для каждого атрибута есть два метода: Get (прочитать) и Set (установить) значение. Для отношений тоже есть методы Get (получить объект или набор объектов, связанных с данным) и Set (связать данный объект с другим). Так как отношения реализованы методами, то нет необходимости особо их описывать с помощью конструкции inverse, чтобы база данных смогла обеспечить целостность отношения. В самом методе Set изменяется и прямая, и обратная ссылки.
Основной принцип языка манипулирования объектами (OML) — сделать работу с постоянными объектами (объектами базы данных) максимально похожей на работу с временными объектами (обыкновенными объектами языка C++). Для создания постоянных объектов в языке C++ авторы стандарта ODMG предлагают перегрузить и использовать оператор new, удаление объектов из базы данных происходит с помощью метода delete_object. Работа с постоянными объектами производится с помощью специальных ссылок: оператором «->» можно вызвать методы объекта, изменить его атрибуты. Эти же ссылки используются для связи объектов в отношениях. В Real не вводятся специальные ссылки для работы с объектами баз данных, для этого используются обыкновенные указатели языка C++. Объекты базы данных создаются, как и временные, и заносятся в базу вызывом метода Update. Удаление объекта из базы данных происходит вызывом метода Delete.
Для выполнения OQL-запросов из программы на языке C++ в языке манипулирования объектами введена специальная функция oql. Ее параметр — строка символов с выражением на объектном языке запросов; возвращаемым значением может быть как некоторое скалярное значение, так и массив, структура, объект базы данных, набор объектов в зависимости от результата запроса. В программном интерфейсе базы данных Real можно лишь в конструкторе коллекции объектов указать условие на SQL и тем самым выбрать с помощью запроса только некоторое множество объектов одного типа.
3. Базы данных в Real
Проектирование баз данных. Объектную базу данных в Real мы предлагаем реализовывать как реляционную базу данных в совокупности с программным интерфейсом, с помощью которого к ней обращаются программы. Реляционная база данных отвечает за хранение данных, а программный интерфейс занимается представлением этих данных в объектно-ориентированном стиле.
Объектно-ориентированный стиль доступа — возможность обращения к базе данных в терминах ее объектной схемы. Единицей хранения служит объект, его можно добавить в базы данных или удалить, у каждого объекта прочитать и изменить значение атрибутов, получить объект(ы), связанный(ые) с данным. У базы данных можно запросить набор объектов некоторого класса, чтобы его поэлементно перебрать.
Схема базы данных представляет собой расширение модели классов UML. Ее соответствие схеме реляционной базы данных примерно следующее: класс соответствует таблице, а ассоциация между классами соответствует связи между таблицами (по некоторому ключу). Отличия возможностей схемы баз данных в Real от возможностей схем обычных реляционных баз данных следующие:
eсть наследование между классами;
у ассоциаций есть специальные атрибуты — агрегирование и ссылка по имени, которые предоставляют дополнительные возможности работы с ассоциациями;
классы имеют не только атрибуты и отношения, но и методы.
Атрибуты ассоциаций имеют следующий смысл. Агрегирование означает, что объект одного класса включает в себя объект(ы) другого класса. В модели классов один класс может быть агрегируем несколькими разными классами. Это означает лишь то, что экземпляр такого класса может быть включен в экземпляр любого из клаcсов-агрегатов, но только в один. Все объекты базы данных имеют владельца (агрегат). Владелец не скрывает включенные в него объекты от других объектов базы данных. Включаемые объекты могут быть связаны не только друг с другом и с владельцем, но и с любыми другими объектами. В программном интерфейсе есть следующая поддержка агрегирования: у каждого объекта имеется связь с владельцем (отношение Owner) и метод Delete, который удаляет не только сам объект, но и все включенные в него объекты.
Ссылка по имени введена для того, чтобы можно было определять связи с объектами, которые будут созданы позже. Можно определить, что объект А связан с объектом, имя которого Б. Если объекта Б в базе нет, то ссылка остается пустой. Но когда такой объект Б появится, все ссылки по имени на него автоматически обновятся и будут указывать на вновь созданный объект.
Использование баз данных. На рис. 3 показано взаимодействие базы данных, созданной в Real, и приложения, ее использующего, на примере репозитория. База данных может физически располагаться в любой реляционной базе данных, которая имеет ODBC-драйвер. Мы, например, использовали СУБД MS Access и Oracle для хранения репозитория. Обращение к базе данных через ODBC происходит из программного интерфейса. Он состоит из двух частей:
Программный интерфейс C++ — библиотека C++ классов.
Программный интерфейс COM — библиотека COM классов.
Рассмотрим подробнее элементы, изображенные на рис. 3. Для чего нужен интерфейс COM? Пользовательские программы обращаются к интерфейсу C++ через интерфейс COM по нескольким причинам:
исходный текст интерфейса C++ предназначен для компиляции в среде MS Visual C++, поэтому он может быть использован из тех программ, которые тоже написаны на Visual C++, а это неудобно: не все пользователи захотят (или смогут) приобрести этот компилятор специально для доступа к репозиторию;
Рис. 3. Схема доступа к репозиторию.
язык C++ является не самым простым и удобным средством для написания небольших пользовательских скриптов для работы с репозиторием; Visual Basic в этом случае более предпочтителен, а из него доступ к репозиторию возможен только через интерфейс COM;
мы не привязываем пользователя ни к встроенному в Real языку VBScript, ни к Visual C++; интерфейс COM является языково-независимым и позволяет разработчику писать приложения, работающие с репозиторием на его любимом языке; необходимым требованием к языку программирования являются возможности работы с Автоматизацией.
Интерфейс COM является лишь переходником между пользовательскими программами и интерфейсом C++. Именно последний делает всю работу по обеспечению объектного стиля доступа к репозиторию. Программный интерфейс C++ предоставляет доступ к объекту как к единому целому несмотря на то, что его данные могут быть расположены по нескольким таблицам. В Real реализована работа с наборами объектов, механизм связей между объектами. В то же время в качестве реляционной базы данных репозиторий должен обеспечивать выполнение SQL-запросов, поэтому программный интерфейс позволяет выбирать объекты, определенные SQL-предложением. Иногда бывает удобнее с помощью SQL выбрать набор объектов с заданными свойствами, чем перебирать все объекты данного класса и проверять, удовлетворяет ли каждый объект этому условию. Программный интерфейс C++ используется средствами Real напрямую (а не через COM) из соображений эффективности и удобства, так как Real создан на Visual C++.
На реляционную СУБД возлагается не только обеспечение физического доступа к данным, но и поддержание транзакций, выполнение SQL-запросов и обеспечение многопользовательского доступа. Последнее означает возможность работы с одним репозиторием с нескольких рабочих мест, при этом редактируемые элементы репозитория на время их модификации будут блокированы средствами СУБД, что обеспечивает целостность данных репозитория.
Целевая платформа. Программные интерфейсы COM и C++ для доступа к базе данных Real разработаны для использования в операционной системе Windows (Win32), однако ограничение на применяемую операционную систему не распространяется на реляционную базу данных. Программные интерфейсы обращаются к базе данных через ODBC, и это позволяет использовать не только локальные, но и удаленные базы данных, которые могут располагаться на сервере баз данных, работающем под управлением другой операционной системы.
На рис. 4 показаны возможности работы с базой данных с помощью ODBC. В верхней части рисунка изображены элементы, расположенные на той же рабочей станции, что и клиентская часть базы данных Real. Под клиентской частью понимаются программные интерфейсы C++ и COM. В нижней части изображен удаленный сервер баз данных. Во-первых, база данных может располагаться на той же рабочей станции, что и клиентская часть базы данных Real (на рисунке это показано как обращение к локальной базе данных, например к БД Access), во-вторых, база данных может быть расположена на удаленном сервере (на рисунке этот путь показан как обращение к удаленной базе данных, например к БД Oracle). В обоих случаях заботу о доступе к базе данных берет на себя ODBC-драйвер базы данных, а программный интерфейс не знает о том, локальную или удаленную базу данных он использует.
Рис. 4. Пример обращения к реляционной базе данных через ODBC.
Генерация баз данных. В рамках Real предоставляется возможность создавать реляционные базы данных с элементами объектно-ориентированного подхода, аналогичные репозиторию. Шаги этого процесса изображены на рис. 5.
Схема базы данных создается в виде набора диаграмм классов. Редактор классов Real сохраняет эту модель в репозитории, по содержимому которого генератор создает исходные тексты программного интерфейса COM, программного интерфейса C++ и готовую реляционную базу данных. После компиляции исходных текстов мы получаем готовые программные интерфейсы COM и C++ (они реализованы в виде динамически подключаемых библиотек). Три элемента в нижней части рис. 5 представляют автоматически сгенерированную базу данных Real.
Рис. 5. Пример создания базы данных в Real.
Генерация реляционной базы данных и программного интерфейса может использоваться в рамках Real следующим образом. Если проектируемая система должна использовать в своей работе базу данных, то разработчик при описании структурной модели системы указывает классы, экземпляры которых должны быть сохранены в базе данных. На диаграмме классов у каждого класса можно указать, является ли он временным или постоянным. Совокупность постоянных классов используется в качестве схемы базы данных.
Обеспечивая взаимодействие проектирумой системы с базой данных, Real выгодно отличается от многих других CASE-средств, которые позволяют автоматизировать разработку и программного обеспечения, и баз данных, однако не обеспечивают никакой связи между ними.