СТАТЬЯ
25.05.01

Предыдущая часть

Пакет Sybase PowerDesigner.
Объектно-реляционное моделирование.

Николай Птицын,
МГТУ им. Н. Э. Баумана, каф. ИУ5

Архитектура PowerDesigner

Как уже было отмечено во вступлении, PowerDesigner относится к классу интегрированных CASЕ-пакетов и может применяться на этапах от концептуального проектирования до генерации программного кода. Основное назначение PowerDesigner состоит в объектно-реляционном моделировании информационной системы. Пользователями пакета могут быть различные участники проекта – системные аналитики, бизнес-аналитики, администраторы БД, разработчики приложения, менеджеры проекта и др.

Пакет PowerDesigner содержит набор тесно интегрированных модулей, обеспечивающих работу с различными моделями:

  1. Объектно-ориентированная модель (OOM, в нотации UML),

  2. включающая диаграммы классов, сценариев и прецедентов;
  3. Концептуальная модель данных (CDM, в нотациях IE или Merise);
  4. Физическая модель данных (PDM в нотациях реляционной БД, CODASYL или IE).
Таким образом, в продукте объединены средства ООМ с традиционной двухуровневой схемой проектирования БД. Все три компоненты встроены в одно приложение и взаимодействуют с пользователем через единый интерфейс (common shell).

Дополнительными компонентами PowerDesigner являются:

Благодаря модульной архитектуре PowerDesigner (рис. 6) могут быть выбраны различные комплектации продукта [5].

рис. 6 Архитектура PowerDesigner



Методология проектирования

В PowerDesigner реализованы концепции итерационного и структурного проектирования информационной системы:

  1. Итерационный подход предполагает разработку программного обеспечения по спиральной модели [1]. Каждой “виток” спирали включает часть или все этапы проекта (анализ, проектирование, разработка, тестирование, внедрение и сопровождение) и соответствует шагу к “улучшению” программного продукта – наращивание функциональных возможностей, исправление ошибок и т.д. На каждом шаге, модификация проекта может проводиться:
    1. на различных уровнях (в программном коде, OOM, CDM, PDM, …);
    2. одновременно в нескольких местах (при параллельной разработке);
При этом для обеспечения целостности всего проекта требуется:
    1. согласовать и протоколировать изменения с помощью репозитория (repository);
    2. обновлять связанные модели путем прямого/обратного инжиниринга (forward/reverse engineering) и разрешать конфликты (функции merge/compare/check models, ).
  1. Сущность структурного подхода [1] заключается в декомпозиции всего приложения на компоненты по функциональным или другим критериям. Каждый компонент в свою очередь разбивается на меньшие, и так далее до выделения бизнес-логики в методах класса. Например, структурирование приложения обеспечивается с помощью иерархического представления ООМ (вложенные диаграммы UML).

рис. 7 Средства итерационного проектирования для PDM



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

рис. 8 Схема возможных преобразований моделей
 
Исходные данные Средство разработки Описание этапа проектирования и результат
1 Требования к структуре приложения и функциональным возможностям; способы применения и пользователи PowerDesigner / модуль ООМ Проектирование концептуальной модели приложения в нотации UML — диаграмм прецедентов (use-CASE), сценариев (sequence или scenario), классов (class) и пр.

Результат: диаграмма ООМ.

2 Данные о предметной области проектируемого приложения PowerDesigner / модуль CDM Проектирование концептуальной модели данных в нотации IE: определение сущностей и установка связей между ними.

Результат: диаграмма CDM.

3 Концептуальная модель данных (CDM) PowerDesigner / модуль PDM Прямой инжиниринг CDM в физическую модель данных (PDM) и доработка последней (адаптация к выбранной СУБД, оптимизация).

Результат: диаграмма PDM.

4 Физическую модель данных (PDM) PowerDesigner / модуль PDM, СУБД Генерация сценариев DDL и передача их на СУБД (через ODBC или текстовый файл с запросами SQL).

Результат: модель данных в конкретной СУБД.

5 ОО и физическая модели данных (ООМ и PDM) PowerDesigner / модуль ООМ Объединение (merge) моделей, преобразование структур данных PDM в классы ООМ, обновление CDM (при необходимости).

Результат: дополненная диаграмма ООМ.

6 Объектно-ориентированная модель ООМ PowerDesigner / модуль ООМ Прямой инжиниринг ООМ в исходные тексты выбранного средства разработки приложения.

Результат: Шаблоны или готовый код на Java, PowerBuilder, C++, VB или другом языке программирования.

7 Исходные тексты из п 6. выбранное средство разработки (Sybase PowerBuilder,
PowerJ, Sun TDK, Microsoft VC++)
Доработка приложения с помощью средств RAD или “обычного” программирования (разработка пользовательского интерфейса, функции ввода/вывода и пр.)

Результат: дополненный программный код и готовое исполняемое приложение (на данном витке итерации)

8 Исходные тексты из п. 7 PowerDesigner / модули ООМ, CDM, PDM Обратный инжиниринг обновленных классов в диаграммы UML модели ООМ и обновление CDM, PDM, структуры БД (при необходимости)

Результат: обновленные модели ООМ, CDM, PDM.

9 Переход на следующий “виток развития” приложения – п. 1.

 
 
 

Модель данных PowerDesigner

В пакете используется двухуровневая модель данных:

  1. Концептуальная модель данных (CDM) представляет собой формализованное представление общей структуры данных информационной системы без привязки к конкретной реализации на базе СУБД. Модель строиться в виде графической схемы, называемой диаграммой “сущность-связь”. Как правило, при работе на концептуальном уровне системных аналитик создает абстрактную схему данных; выделяет сущности из предметной области; устанавливает связи между ними; задает бизнес-правила работы с данными. Для построения концептуальной модели в PowerDesigner используется нотации IE (Information Engineering) и Merise.
  2. Физическая модель данных (PDM) соответствует реализации концептуальной модели на конкретной платформе (СУБД). Работая на физическом уровне, администратор БД или программист задает типы данных; проводит денормализацию; создает индексы и триггера на SQL-диалекте выбранной СУБД. Физическая модель имеет однозначное отображение в DDL-скрипт (набор инструкций на SQL). Графическая интерпретация модели может быть представлена в нотациях Relational (стрелка связи указывает на первичной ключ родительской таблицы), CODASYL (стрелка указывает на внешний ключ дочерней таблицы) и IE (аналогично CDM).
Как уже было отмечено выше, двухуровневая модель данных с возможностью прямого и обратного инжиниринга, а так же слияния моделей (merge) позволяет вести итерационную разработку структуры данных. К примеру, системный аналитик формирует концептуальную модель (CDM), которая преобразуется в физическую (PDM). Последняя дорабатывается программистом, отлаживается на СУБД. Затем проводится обратный инжиниринг для обновления CDM. Системный аналитик продолжает доработку модели на следующей итерации…

Основы проектирования реляционной БД достаточно хорошо описаны в литературе (например, в учебном курсе С. Д. Кузнецева [3]), поэтому в этом обзоре дополним несколько слов о наследовании.

Наследование

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

Нотация IE поддерживает только одинарное наследование (то есть одна базовая сущность-родитель передает атрибуты дочерним сущностям), в то время как IDEF1X допускает так же и множественное наследование (то есть когда дочерняя сущность наследует атрибуты нескольких родителей).

PowerDesigner поддерживает одинарное наследование двух типов:

  1. Обычное наследование, когда одной записи базовой сущности могут соответствовать наборы атрибутов всех дочерних сущностей (рис. 9);
  2. Исключающие наследование (mutually exclusive children), когда только одна дочерняя запись связана с записью базовой сущности (рис. 10).

рис. 9 Обычное наследование (а-CDM, б-PDM)

рис. 10 Исключающие наследование (а-CDM, б-PDM)

Физическая реализация этих двух типов наследования может выглядеть по-разному (несколько таблиц, связанных отношением “один-к-одному” или одна таблица, содержащая атрибуты базовой и дочерней сущностей).

Настройка параметров наследования в PowerDesigner производится на концептуальном уровне (рис. 11).

рис. 11 Диалог настройки наследования
 

Заключение

Завершая обзор, отметим сильные и слабые стороны объектно-реляционной модели.

Рассмотренный подход наследует все преимущества реляционной модели, дополняя их совместимостью с приложениями объектно-ориентированной архитектуры:

Среди недостатков модели можно выделить следующие: Впрочем, перечисленные недостатки часто не актуальны для реальных приложений.

Источники

  1. А. М. Вендров, CASE-технологии. Современные методы и средства проектирования информационных систем
  2. С. Д. Паронджанов, Методология создания корпоративных ИС
  3. С. Д. Кузнецов, Основы современных баз данных
  4. PowerDesigner – объектно-ориентированное проектирование XXI века
  5. Комплектация PowerDesigner 7.5
  6. PowerDesigner 7.0—the Next Generation
  7. Sun JavaBlend
Приобрести продукты Sybase в нашем магазине

За дополнительной информацией обращайтесь в Interface Ltd.


Interface Ltd.
Тel/Fax: +7(095) 105-0049 (многоканальный)
Отправить E-Mail
http://www.interface.ru
Ваши замечания и предложения отправляйте автору
По техническим вопросам обращайтесь к вебмастеру
Документ опубликован: 25.05.01