1. Цель работы.

2. Описание предметной области.

3. Диаграммы Enterprise Architect с пояснениями.

4. Сгенерированный каркасный код программных компонентов.

5.Вывод.

4.5 Контрольные вопросы.

1. Поясните сущность диаграмм компонентов.

2. Поясните сущность диаграмм развертывания.

3. Поясните сущность модельно-ориентированной архитектуры.

4. Как вы считаете, всегда ли более актуальными являются именно платформо – зависимые модели?

Лабораторная работа №5

«ФУНКЦИОНАЛЬНОЕ ПРОЕКТИРОВАНИЕ

ИНФОРМАЦИОННЫХ СИСТЕМ»

5.1 Цель работ

Ознакомиться с начальным этапом функционального проектирования программного обеспечения. Освоить технологии разработки программных продуктов с применением CASE-средств Sybase Inc.: PowerDesigner ProcessAnalyst и PowerDesigner DataArchitect.

Задание: в соответствии с выбранной предметной областью построить функциональную, концептуальную и физическую модели.

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

Диаграммы потоков данных (DFD)

Диаграммы потоков данных (DFD) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных.

В DFD используются следующие основные символы:

Таблица .2 Основные символы диаграммы потоков данных

Элемент	Описание	Обозначение
Внешняя сущность	Внешний по отношению к системе объект, обменивающийся с нею потоками данных
Хранилище данных	Определяет данные, которые будут сохраняться между процессами на определенных участках. Накопитель представляет собой абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми.
Поток данных (Data Flow)	Определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабедискетами, переносимыми с одного компьютера на другой и т.д.
Процесс (Process)	Преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Процессы можно детализировать, применяя метод декомпозиции и строя иерархию процессов. Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с активным недвусмысленным глаголом в неопределенной форме.

В бизнес-правилах (Business Rules) описываются ограничения на данные и те проверки, которые необходимо будет сделать при реализации алгоритма. Например, сумма договора всегда должна быть больше нуля или дата окончания договора всегда позже даты начала договора.

Модель сложной ИС может быть представлена в общем виде на так называемой контекстной диаграмме в виде одной системы как единое целое либо может быть декомпозирована на ряд подсистем.

Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.

Пример диаграмм DFD автоматизации отдела социальной защиты населения (ОСЗН) городской администрации.

Рис. 23. Диаграмма верхнего уровня функциональной модели ОСЗН

Рис. 24. Декомпозиция корневого процесса «Оказать помощь»

PowerDesigner DataArchitect позволяет импортировать функциональную модель и на ее основе строить концептуальную, при этом полностью переносятся бизнес-правила, элементы данных и домены. Хранилище со своими элементами данных становится объектом или сущностью (Entity) с атрибутами, если это необходимо. Можно также добавить любые новые параметры модели: сущности, атрибуты, домены или бизнес-правила. В каждой сущности необходимо определить следующее:

• какие атрибуты однозначно определяют экземпляр объекта (свойство Identifier). В физической модели эти атрибуты станут первичными ключами (Primary key);

• какие атрибуты должны быть обязательно заданы (свойство Mandatory). Отношение (Relationship) между сущностями означает, что в физической модели первичный ключ первой таблицы будет автоматически перенесен во вторую указанную таблицу как внешний ключ (Foreign key).

Таблица .3 Основные связи физической модели

Тип связи	Описание	Обозначение
один к одному(1:1)	когда один экземпляр первого объекта может соответствовать только одному экземпляру второго объекта
один ко многим (1:n)	когда один экземпляр первого объекта может соответствовать более чем одному экземпляру второго объекта
многие к одному (n:1)	когда более чем один экземпляр первого объекта может соответствовать только одному экземпляру второго объекта
многие ко многим (n:m)	когда более чем один экземпляр первого объекта может соответствовать более чем одному экземпляру второго объекта
рефлексивное отношение (Reflexive)	когда существуют отношения (связи) внутри объекта между его экземплярами

Для отношений можно задать следующие свойства.

• Доминирующее отношение (Dominant) в отношениях один к одному показывает, что при генерации физической модели данных (Physical Data Model – РDM) необходимо сформировать только одну ссылку в указанном направлении и объект, указанный как доминирующий, будет являться таблицей-родителем (the parent table). Если не указать это свойство, то в РDM будет сформировано две ссылки, то есть в каждой таблице будет ссылка на другую таблицу.

• Обязательное отношение (Mandatory) показывает, что каждый экземпляр первого объекта требует существования соответствующего экземпляра во втором объекте. Это свойство на диаграмме изображается вертикальной чертой (рис. 25).

• Необязательное отношение (Optional) показывает, что экземпляр первого объекта не требует существования соответствующего экземпляра во втором объекте. Это свойство на диаграмме изображается маленьким кружком (см. рис. 25).

• Зависимое отношение (Dependent) показывает, что каждый экземпляр первого объекта идентифицируется с помощью соответствующего экземпляра во втором объекте. Оно означает, что в физической модели первичный ключ первой таблицы будет автоматически перенесен во вторую указанную таблицу как первичный ключ. Это свойство на диаграмме изображается треугольником (см. рис.25).

Рис. 25. Обозначение кардинальности связей

в PowerDesigner DataArchitect

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

При необходимости в модель можно вносить изменения.