Расчетно-графическая работа по курсу

«Технологии разработки информационных систем»

Задание 1

Технологии создания кода с использованием CASE средств

Теоретические сведения

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

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

Диаграммы UML позволяют разработчикам сосредоточиться на проектировании бизнес-логики информационной системы, строя концептуальные модели (CDM, Conceptual Data Model) и физические модели (PDM, Physical Data Model) на структурах баз данных. Такая трехуровневая методология проектирования позволяет осуществлять весь процесс производства ПО в единой интегрированной среде, где каждый уровень логически связан с другим. Диаграммы классов могут быть связаны с концептуальными моделями данных, концептуальные модели данных — с физическими. Каждый уровень может быть преобразован в другой. 

Рисунок 1.1 - Преобразование ООМ в РМ

Сопоставим каждому классу ООМ реляционное отношение (таблицу) следующего вида:

1. Первичный ключ генерируется базой данной и становится уникальным идентификатором сохраняемого объекта;

2. Каждый атрибут класса ставиться в соотношение колонке таблицы:

• Если атрибут класса - скаляр, то атрибут реляционного отношения представляет собой внешний ключ таблицы, описывающей класс этого атрибута. Простые атрибуты (char, int, double и т.д) могут сохраняться в таблице класса сразу вместо внешнего ключа;

• Если атрибут класса - вектор (массив элементов), то имеем неатомарный атрибут отношения, что в явном виде не поддерживается реляционной моделью. Такая многозначная связь между атрибутом отношения и записями таблицы класса этого атрибута может быть установлена с помощью дополнительной таблицы, соответствующей "массиву элементов данного класса".

3. Наследование в явном виде не поддерживается в реляционной модели, но может быть реализовано следующим способами:

• Атрибуты таблицы, соответствующей базовому классу (в частности, абстрактному), могут переноситься физически в таблицы наследующих классов. Как правило, эти мигрирующие атрибуты отмечаются разработчиком сразу в концептуальной модели. Объекту финального класса будет соответствовать одна запись в таблице наследующего класса. Базовая таблица вообще не включается в окончательную структуру базы данных.

• Между базовой и наследующей таблицами может быть установлена связь 1:1. В этом случае наследуемые атрибуты хранятся в таблице, соответствующей базовому классу, а дополнительные - в таблице наследующего класса. Объекту финального класса соответствует пара записей (или большее число, в зависимости от глубины иерархии) в базовой и наследующей таблицах. Реализация механизма наследования в PowerDesigner описана ниже в разделе Модель данных PowerDesigner.

Рассмотрим пример.

Пусть имеется абстрактный класс Базовый счет (General Account), который наследуется двумя другими: Карточный Счет (Card Account) и Сберегательный Счет (Saving Account). Класс Держатель (Holde ) связан отношением Держатель счета (Account Holder) со структурой Базовый счет (и следовательно с двумя дочерними классами), а так же со структурой Адрес (Address) отношением Адрес Держателя (Holder Address) типа 1:М. На рис. 2 представлена диаграмма классов и связей между ними в нотации UML.

Рисунок 1.2 - Диаграмма классов Держатель и Счета

Здесь в свойствах связи Держатель Счета (Account Holder) и Адрес Держателя (Holder Address) был определен класс Holder как контейнер для классов Account и Address. В результате в атрибутах Holder появились массивы ссылок accounts и addresses. Скелет класса, который выдает кодогенератор на основе модели UML имеет следующие вид (рис. 3).

Рисунок 1.3 - Генерируемый код класса Holder на языке Java

С учетом того, что все классы объектов должны "запоминаться" в базе данных, преобразуем эту ООМ в реляционную модель физического уровня. Как видно на рис. 4 ассоциативные (association/composition, в терминологии RUP - aggregation) и наследственные (generalization) связи ООМ заменяются на реляционные отношения между таблицами, устанавливаемые с помощью внешних ключей (<fk>).

Рисунок 1.4 - Диаграмма "сущность связь" Держатель и Счета

Таким образом, интеграция двух моделей с помощью рассмотренного механизма приводит к возникновению понятия объектно-реляционной модели (ОРМ) .

Отметим, что в таком понимании объектно-реляционная СУБД существенно отличается от объектно-ориентированной СУБД. Первая представляет собой традиционную реляционную СУБД дополненной схемой преобразования классов в таблицы (mapping layer). Это позволяет сохранять данные объектно-ориентрованного приложения в "обычной" базе данных.

Более серьезное разногласие объектно-ориентированного и реляционного подходов заключается в концепции хранения данных и программирования. Так, в ООМ используется процедурный язык программирования, ориентированный на работу со скалярными значениями, в то время как SQL представляет собой декларативный язык запросов и предназначен для работы со множествами. Эта явление принято называть потерей соответствия (impedance mismatch).

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

Рисунок 1.5 - Уровни проектирования объектно-реляционного ПО

На схеме выделены 4 уровня приложения, на которых ведутся его разработка и тестирование:

1. Концептуальный уровень (включает ООМ и концептуальную модель данных (CDM);

2. Физический уровень (привязывается к прикладному средству разработки);

3. Уровень программного кода (исходные тексты на языке программирования);

4. Уровень выполняемого кода (готовое приложение)

Пошаговая инструкция

1. Создаем диаграмму классов

Рисунок 1.6 – Создание диаграммы классов

2. Строим диаграмму классов

Рисунок 1.7 – Построение диаграммы классов

3. Из диаграммы классов генерируем концептуальную модель данных

Рисунок 1.8 – Генерация концептуальной модели данных

4. Из концептуальной модели данных генерируем физическую модель данных

Рисунок 1.9 – Генерация физической модели данных

5. Из физической модели данных генерируем SQL-скрипт

Рисунок 1.10 – Генерация SQL-скрипта

Задание

Для системы, заданной номером варианта выполнит следующие действия:

1. Создать диаграмму классов

2. Из диаграммы классов сгенерировать концептуальную модель данных

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

4. Из физической модели данных сгенерировать SQL-скрипт