
- •Лабораторная работа. Разработка диаграмм потоков данных и матричных диаграмм средствами программы Oracle Designer
- •1.1. Цель работы и задание на лабораторную работу
- •1.2. Порядок выполнения работы
- •1.3. Возможности диаграммера потоков данных
- •1.4. Состав дпд в нотации Oracle Designer
- •1.5. Технология разработки дпд
- •1.5.1. Связь хранилищ данных и информационных потоков с моделью данных
- •1.6. Разработка матричных диаграмм
- •1.6.1. Назначение матричных диаграмм
- •1.6.2. Разработка матричных диаграмм «Бизнес-функции – Сущности»
- •1.6.3. Разработка матричных диаграмм «Бизнес-функции – Атрибуты»
- •1.7. Формирование отчетов по объектам репозитория
- •1.8. Содержание отчета
- •1.9. Контрольные вопросы
1.5.1. Связь хранилищ данных и информационных потоков с моделью данных
На ДПД для накопителей данных и информационных потоков можно указать связь с моделью данных, т.е. определить содержание накопителей данных и информационных потоков (состав атрибутов данных, которые должны храниться в выбранном накопителе или передаваться в составе информационного потока). Предварительно должна быть разработана модель данных средствами модуля Entity Relationship Diagrammer.
Связь накопителей данных с моделью данных устанавливается с помощью Dataflow Diagrammer следующим образом:
вызвать контекстное меню щелчком правой клавиши мыши по символу накопителя данных,
выбрать команду properties (свойства),
на открывшейся форме выбрать закладку Contents (Содержание), рисунок 19; в поле сущностей модели данных (Entity) будут выведены имена сущностей, которые входят в состав модели данных выбранного проекта; при выборе курсором имени сущности в поле атрибутов (Attributes) будут выведены имена её атрибутов (рисунок 21),
выбрать атрибуты, которые должны содержаться в составе данных выбранного накопителя, и нажать кнопку ↓; выбранные атрибуты переместятся в поле «Datastore» (рисунок 22),
повторить п. 4 для всех необходимых сущностей и атрибутов и нажать кнопку «Применить» (в левом верхнем углу символа накопителя будет выведена красная точка).
В поле «Datastore» имена атрибутов начинаются с префикса, который имеет следующую структуру:
DSTATT; имя сущности (имя проекта); имя атрибута в составе сущности,
где DSTATT означает «DataSTore ATTributes».
Для потоков данных назначение атрибутов выполняется аналогично.
Рисунок 21 – закладка «Contents» для накопителя данных
Рисунок 22 – формирование списка атрибутов накопителя данных
1.6. Разработка матричных диаграмм
1.6.1. Назначение матричных диаграмм
В процессе проектирования ИС должны быть рассмотрены вопросы об использовании данных каждой бизнес-функцией, например, может ли создавать или изменять конкретные данные рассматриваемая бизнес-функция. Это может быть сделано при обсуждении проекта ИС с пользователями, например, показывая им прототип системы. В результате этой работы могут быть определены сущности (объекты) и атрибуты, которые должны быть добавлены к модели «сущность-связь».
Такая работа может выполняться неоднократно: вначале должны быть определены объекты, которые используются каждой бизнес-функцией, затем следует явно определить следующие возможности бизнес-функции:
создать экземпляр сущности (объекта),
получить или читать экземпляр сущности (объекта),
обновить или удалить экземпляр объекта,
заархивировать и удалить экземпляр объекта.
Можно указать все атрибуты каждого объекта, которые используются бизнес-функцией, и определить, может ли функция:
вставить возможное значение атрибута,
прочитать значение атрибута,
обновить значение атрибута,
установить значение атрибута NULL.
Эти варианты использования данных должны быть представлены в форме «CRUD-матрицы (С – create, создать; R – retrieve, получить, U - update, обновить, D – delete, удалить). Дополнительно может быть указана информация о том, сколько экземпляров сущности (объекта) может использовать бизнес-функция.
Получающиеся матрицы могут быть просмотрены с помощью матричного диаграммера. Матрицы покажут, что какие-либо объекты или атрибуты не используются бизнес-функциями; например, потому что не все требуемые функции определены в функциональной иерархии, или атрибут не требуется в информационной модели.
Если функция не использует сущности, возможно, что не все требуемые сущности определены в информационной модели, или функция включает ручные процедуры, которые не читают или не записывают данные.
Преобразователь проектирования приложений (Application Design Transformer) использует данные о полномочиях бизнес-функций по работе с сущностями для того, чтобы определить, как программные модули должны использовать таблицы базы данных в прикладной системе.
Для назначения полномочий бизнес-функций по использованию сущностей следует:
идентифицировать элементарные бизнес-функции в функциональной иерархии проекта,
составить описание использования данных элементарными бизнес-функциями,
установить способ, которым элементарные бизнес-функции в функциональной иерархии используют атрибуты сущностей в информационной модели.
Предварительно должна быть разработана информационная модель (модель данных предметной области).
Чтобы указать, каким образом будут использоваться сущности и атрибуты бизнес-функциями, можно использовать такие инструменты как Матричный Diagrammer, Diagrammer потоков данных, Diagrammer функциональной иерархии или навигатор объектов репозитария.
Чтобы указать использование бизнес-функциями атрибутов сущностей может использоваться утилита Function/Attribute Matrix диаграммера потоков данных.
Матричный Diagrammer и Навигатор Объектов репозитария могут вывести на экран все сущности (объекты), которые используются бизнес-функцией, или все функции, которые используют данную сущность.