Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Цель лабораторной работы состоит в освоении технологии разработки диаграмм потоков данных (ДПД) информационных систем с использованием модуля Dataflow Diagrammer программы Oracle Designer.
Задание заключается в разработке диаграмм потоков данных для заданных бизнес-функций системы, включая назначение связей компонентов ДПД с компонентами модели данных предметной области.
Рекомендуется выполнять лабораторную работу в следующем порядке:
Для разработки ДПД в составе системы Oracle Developer Suite имеется «диаграммер потоков данных» (Dataflow Diagrammer), который позволяет создавать и поддерживать бизнес-функции, хранилища (накопители) данных, потоки данных и внешние объекты, сведения о которых сохраняются в репозитории. Диаграммы потоков данных схематично представляют потоки данных, проходящих через предприятие. Они позволяют представлять зависимости по данным, системные компоненты и контекст проекта.
Каждая диаграмма потоков данных представляет единственную бизнес-функцию для прикладной системы. Содержание функции зависит от разработчика проекта; функция может относиться к различным уровням иерархии: от миссии всей организации до небольшого набора достаточно простых действий для отдельной части бизнеса организации.
Dataflow Diagrammer обеспечивает:
ДПД в нотации Oracle Designer включает в себя следующие компоненты: внешние объекты (external), бизнес-функции (function), потоки данных (flow), хранилища (накопители) данных (datastore), рисунок 1.
Рисунок 1 – схематичная обобщенная модель ДПД
Внешними являются объекты, которые находятся за пределами иерархии бизнес-функций в контейнере; они рассматриваются как источники или получатели потоков данных относительно иерархической совокупности бизнес-функций. Внешним объектом может быть человек, подразделение, другой контейнер бизнес-функций.
Фреймовая функция (frame function) - термин, использованный для определения (указания) функции, для которой составлена диаграмма потоков данных. Функции внутри границ фреймовой функции (внутри фрейма) называются локальными (local function), а функции, которые изображаются вне функции фрейма, - глобальными (global function). Локальные функции - дочерние функции фреймовой функции.
Любая функция на ДПД, которая не является дочерней функцией текущей функции фрейма, может быть глобальной.
Бизнес-функция, у которой нет родительской функции, называется корневой функцией (root function).
Общие функции (common function) используются, когда одна и та же функция используется больше чем в одном месте в функциональной иерархии бизнес-функций. Каждая общая функция основывается на главной функции и наследует её свойства. На диаграммах потоков данных метка главной функции выведена на экран в верхнем правом углу общей функции.
Хранилище данных – место (устройство) для временного или постоянного хранения набора атрибутов от одного или более элементов модели, использующихся указанными функциями или процессами. Хранилище данных может также содержать элементы данных, которые могут быть впоследствии преобразованы в атрибуты.
Поток данных - именованный поток данных между функциями и хранилищами данных, или между внешними объектами и другими функциями. По крайней мере, один конец потока данных должен быть соединен с бизнес-функцией.
Разрешенные потоки (resolved flow) представляют потоки данных между функциями на более низком уровне в функциональной иерархии, чем текущая функция фрейма. Разрешенные потоки не могут быть созданы на ДПД; они могут быть включены только от контейнера (диаграммы бизнес-функций).
Разрешенные потоки на схеме представляются штриховой линией. Имя разрешенного потока выводится на экран выше линии; составляется из имен потоков данных, которые этот поток содержит. Если в разрешенном потоке содержится более одного потока данных, то имя разрешенного потока - первое имя потока данных, сопровождаемое запятой и замещающим знаком (...).
Глобальные потоки представляют поток информации между глобальными функциями и другими элементами, которые находятся вне фрейма бизнес-функции на ДПД, например, другие глобальные функции, хранилища данных или внешние объекты.
Для разработки диаграммы потоков данных следует:
Рисунок 2 – выбор действия в гланом меню
Выбрать контейнер (проект) для диаграммы потоков данных (рисунок 3).
Рисунок 3 - выбор контейнера (проекта) для ДПД
Выбрать или создать (кнопка Create Function) новую функцию бизнес-процесса, для которой необходимо разаботать ДПД (рисунок 4). Создание новой функции можно использовать, например, для разработки ДПД системы в целом, подсистем и т.д.; в этом случае надо нажать кнопку Create Function и ввести имя «новой функции», например: DFD for AS.
Рисунок 4 - выбор функции бизнес-процесса или создание новой функции
Рисунок 5 - Форма для ввода данных о новой функции
Будет создана «фреймовая функция» - форма для ДПД (рисунок 6).
Рисунок 6 – символ фрейма бизнес-функции
Создать внешние объекты с помощью панели инструментов следующим образом:
Рисунок 7– символ внешнего объекта на панели инструментов
Рисунок 8 – ввод идентифицирующих данных для внешнего объекта
Рисунок 9 – символ внешнего объекта на ДПД
Щелчком правой кнопки по символу объекта вызвать контекстное меню, выбрать пункт «Свойства» (Properties) и ввести данные о свойствах объекта в форму (рисунок 10).
Рисунок 10 – форма для редактирования свойств внешнего объекта
Добавление функции (процесса обработки данных) на ДПД:
Рисунок 11 – символ «Функция» на панели инструментов
Рисунок 12 – ввод имени и краткого определения функции
Рисунок 13 – форма для редактирования свойств функции
Редактирование свойств функции может включать в себя назначение следующих значений параметров функции:
Рисунок 13.а – форма для назначения полномочий функции по работе с сущностями
Рисунок 13.б – форма для назначения полномочий функции по работе с атрибутами
Для создания потока на ДПД:
Рисунок 14 – символ потока на панели инструментов
Рисунок 15 – форма для ввода имени потока
Ограничения при создании потоков:
Линии потоков, как правило, представляются ломаными линиями; при необходимости можно придать линиям потоков наиболее удобную для «чтения» диаграммы форму (без наложения потоков, с минимальным количеством пересечений).
Рисунок 16 – форма для редактирования свойств потока
Для добавления накопителя (хранилища) на ДПД:
Рисунок 17 - форма для ввода идентифицирующих данных накопителя данных
Рисунок 18 - символ накопителя данных после ввода идентификатора
Рисунок 19 - Форма для ввода свойств накопителя данных
В результате выполнения указанных действий получатся ДПД для функций, определённых в рамках ранее созданных диаграмм (рисунок 20.а – фрагмент ДПД для бизнес-функции «Realization»), или для «новых функций», например, ДПД для АЭИС (рисунок 20.б).
Рисунок 20.а - фрагмент ДПД для бизнес-функции «Realization»
Рисунок 20.б - ДПД для «новой функции» проекта (ДПД АЭИС)
На ДПД для накопителей данных и информационных потоков можно указать связь с моделью данных, т.е. определить содержание накопителей данных и информационных потоков (состав атрибутов данных, которые должны храниться в выбранном накопителе или передаваться в составе информационного потока). Предварительно должна быть разработана модель данных средствами модуля Entity Relationship Diagrammer.
Связь накопителей данных с моделью данных устанавливается с помощью Dataflow Diagrammer следующим образом:
В поле «Datastore» имена атрибутов начинаются с префикса, который имеет следующую структуру:
DSTATT; имя сущности (имя проекта); имя атрибута в составе сущности,
где DSTATT означает «DataSTore ATTributes».
Для потоков данных назначение атрибутов выполняется аналогично.
Рисунок 21 – закладка «Contents» для накопителя данных
Рисунок 22 – формирование списка атрибутов накопителя данных
В процессе проектирования ИС должны быть рассмотрены вопросы об использовании данных каждой бизнес-функцией, например, может ли создавать или изменять конкретные данные рассматриваемая бизнес-функция. Это может быть сделано при обсуждении проекта ИС с пользователями, например, показывая им прототип системы. В результате этой работы могут быть определены сущности (объекты) и атрибуты, которые должны быть добавлены к модели «сущность-связь».
Такая работа может выполняться неоднократно: вначале должны быть определены объекты, которые используются каждой бизнес-функцией, затем следует явно определить следующие возможности бизнес-функции:
Можно указать все атрибуты каждого объекта, которые используются бизнес-функцией, и определить, может ли функция:
Эти варианты использования данных должны быть представлены в форме «CRUD-матрицы (С – create, создать; R – retrieve, получить, U - update, обновить, D – delete, удалить). Дополнительно может быть указана информация о том, сколько экземпляров сущности (объекта) может использовать бизнес-функция.
Получающиеся матрицы могут быть просмотрены с помощью матричного диаграммера. Матрицы покажут, что какие-либо объекты или атрибуты не используются бизнес-функциями; например, потому что не все требуемые функции определены в функциональной иерархии, или атрибут не требуется в информационной модели.
Если функция не использует сущности, возможно, что не все требуемые сущности определены в информационной модели, или функция включает ручные процедуры, которые не читают или не записывают данные.
Преобразователь проектирования приложений (Application Design Transformer) использует данные о полномочиях бизнес-функций по работе с сущностями для того, чтобы определить, как программные модули должны использовать таблицы базы данных в прикладной системе.
Для назначения полномочий бизнес-функций по использованию сущностей следует:
Предварительно должна быть разработана информационная модель (модель данных предметной области).
Чтобы указать, каким образом будут использоваться сущности и атрибуты бизнес-функциями, можно использовать такие инструменты как Матричный Diagrammer, Diagrammer потоков данных, Diagrammer функциональной иерархии или навигатор объектов репозитария.
Чтобы указать использование бизнес-функциями атрибутов сущностей может использоваться утилита Function/Attribute Matrix диаграммера потоков данных.
Матричный Diagrammer и Навигатор Объектов репозитария могут вывести на экран все сущности (объекты), которые используются бизнес-функцией, или все функции, которые используют данную сущность.
Запустить Матричный Diagrammer; в диалоговом окне выбрать пару («Бизнес-функции»; «Сущности»); названия бизнес-функций впоследствии будут выводиться в строках, а названия сущностей – в столбцах (рисунок 23).
Для каждого элемента выбранной пары следует указать состав обозначения, которое будет выводиться при разработке матричной диаграммы; например, Label для бизнес-функций и Name – для сущностей (рисунки 24 - 25); при этом следует выбрать имя проекта, для которого будет разрабатываться матричная диаграмма (поле Select from). Обозначение может быть составным, например, включать краткое определение (Short Definition), тип функции (Function Type) и др. С помощью кнопок ↑, ↓ можно изменить порядок следования составных частей в обозначении бизнес-функции или сущности. При выборе обозначения для бизнес-функции использовать вкладку «Row – Business Functions», для сущностей - вкладку «Column - Entities».
Затем следует выбрать обозначения для полномочий бизнес-функций, которые будут выводиться в ячейках матричной диаграммы (рисунок 26).
Рисунок 23 - Выбор пары («Бизнес-функции»; «Сущности»)
Рисунок 24 - Выбор обозначения для бизнес-функции, которое будет выводиться в строках матричной диаграммы
Рисунок 25 - Выбор обозначения для сущностей, которое будет выводиться в столбцах матричной диаграммы
Рисунок 26 - Выбор обозначений для полномочий бизнес-функций, которые будут выводиться в ячейках матричной диаграммы
Назначение полномочий для бизнес-функций по работе с сущностями выполняется в диалоговой форме (рисунок 27):
Рисунок 27 - Назначение полномочий для бизнес-функций по работе с сущностями
Запустить Матричный Diagrammer; в диалоговом окне выбрать пару («Бизнес-функции»; «Атрибуты»); названия бизнес-функций впоследствии будут выводиться в строках, а названия атрибутов – в столбцах (рисунок 28).
Рисунок 28 - Выбор пары («Бизнес-функции»; «Атрибуты»)
Состав обозначения для бизнес-функций, которое будет выводиться при разработке матричной диаграммы, выполняется так же как рассмотрено выше. Для атрибутов рекомендуется указать имя сущности (Entity) и имя атрибута (Name), рисунок 29.
Рисунок 29 – выбор обозначения атрибута
Для выбора полномочий бизнес-функции по работе с атрибутами какой-либо сущности следует:
Рисунок 30 – выбор бизнес-функции и атрибута
Рисунок 31 – результат назначения полномочий
Инструментальное средство Repository Reports («Отчеты репозитория») позволяет формировать около 100 предварительно определенных отчетов, что даёт возможность контролировать содержание репозитория. Продвинутые пользователи могут также определять свои собственные отчеты репозитория.
Окно навигатора отчетов содержит список отчетов, из которого можно выбрать один для формирования. Когда выбран отчет, его параметры выводятся на дисплей в «палитре параметров» (в форме, подготовленной для заполнения).
Список отчетов в навигаторе может быть упорядочен одним из трёх способов (Group View, Hierarchy View, Report Name View):
Для выбора варианта отображения списка отчетов следует использовать команду главного меню View.
Рисунок 32 - Форма для выбора отчётов, формируемых по данным репозитория (вид Group View)
Каждый отчет репозитория включает данные только из текущей рабочей области.
Если рабочая область имеет внешние ссылки (т.е. объекты рабочей области ссылаются на объекты, находящиеся вне её), то внешние ссылки не включаются в отчет. Другие инструментальные средства позволяют проверять внешние ссылки, например, навигатор объектов репозитория.
Рисунок 33 - Форма для выбора отчётов, формируемых по данным репозитория (вид Hierarchy View)
В навигаторе отчетов указаны следующие группы:
Для формирования отчетов:
Аналогично сформировать отчет о полномочиях функций и модулей по работе с сущностями (рисунки 38 – 39).
Рисунок 34 – выбор функции для формирования отчетов
Рисунок 35 - Варианты отчетов группы «Entity/Relationship Modelling»
Рисунок 36 – выбор варианта отчета «Сущности и их атрибуты»
Рисунок 37 – отчет «Сущности и их атрибуты» (стр.1)
Рисунок 37 – отчет «Сущности и их атрибуты» (стр.2), продолжение
Рисунок 37 – отчет «Сущности и их атрибуты» (стр.3), окончание
Рисунок 38 - Варианты отчетов группы «Impact Analysis»
Рисунок 39 – отчет «Полномочия функций и модулей по работе с сущностями»
В некоторых случаях при работе в локальной сети могут возникнуть проблемы с формированием отчетов в виде файлов (например, из-за невозможности указания имени каталога для сохранения: нельзя использовать пробелы или символы «кириллицы» в имени). Тогда можно воспользоваться функцией формирования отчета для просмотра: в окне установки параметров (рисунок 40) установить в полях Destination Type и Mode указанные на риснуке 40 значения, выбрать имя проекта (контейнера), установить значения других параметров, если требуется.
Рисунок 40 – назначение параметров отчета для просмотра
После запуска процесса формирования отчета (одним из указанных выше способов: File/Run Report, кнопкой с пиктограммой , или с помощью контекстного меню) будет сформирован отчет в формате html и с помощью интернет-эксплорера выведен на экран. С помощью команд Файл/Сохранить как (File/Save as) следует сохранить файл с отчетом в нужном каталоге.
Отчёт о работе должен содержать следующие разделы:
В первом разделе должны быть представлены следующие данные: название и назначение бизнес-функций; фрагмент диаграммы бизнес-функций, содержащий выбранные функции, с входными и выходными информационными потоками.
Во втором разделе привести диаграммы потоков данных для выбранных бизнес-функций и экранные формы, в которых указаны свойства компонентов диаграммы.
В третьем разделе должно быть приведено описание содержания накопителей данных и информационных потоков, а также экранные формы, в которых представлены связи хранилищ данных и информационных потоков с сущностями и атрибутами модели данных предметной области.
В четвертом разделе должны быть приведены экранные формы, в которых представлены связи бизнес-функций с сущностями и атрибутами модели данных предметной области; для бизнес-функций должны быть указаны полномочия по работе с данными.
Пятый раздел должен содержать краткое описание и примеры сформированных отчетов об объектах репозитория.
В заключении сформулировать результаты работы.