Связывание функциональной модели и модели данных
После завершения разработки модели данных логического уровня ее необходимо связать с функциональной моделью проектируемой системы. Такое связывание моделей гарантирует завершенность анализа и полную информационную поддержку для всех функциональных модулей системы.
Для связывания модели данных и функциональной модели необходимо осуществить экспорт данных из ERwin в BPwin[20].
В ERwin необходимо открыть модель данных и, выполнив команду File/Export/BPwin, выбрать в появившемся диалоговом окне нужный каталог, указать имя создаваемого файла экспорта (*.eax) и нажать ОК.
Затем в BPwin нужно открыть функциональную модель, выполнить команду File/Import/ERwin, а в диалоговом окне выбрать нужное имя файла (*.eax) и нажать «Открыть» (рис. 5.12). В появившемся диалоговом окне необходимо щелкнуть по кнопке Accept, чтобы занести данные в функциональную модель.
Рис. 5.12. Окно для импорта файла из Erwin
После внесения данных в функциональную модель можно связать сущности и атрибуты со стрелками функциональной модели. Для этого правой клавишей мыши следует щелкнуть по стрелке в функциональной модели, а в контекстном меню выбрать вкладку Arrow Data и затем щелкнуть по кнопке выбора в иерархическом списке атрибутов. В результате сущность автоматически связывается со стрелкой. Каждая стрелка в функциональной модели может быть связана с несколькими атрибутами различных сущностей.
|
|
|
Для документирования воздействия работ (функциональных блоков) на данные необходимо щелкнуть правой клавишей мыши по работе и в контекстном меню выбрать пункт Data Usage Editor. В этом диалоговом окне в виде иерархического списка показываются все функциональные блоки модели, стрелки, которые касаются работ, сущности и атрибуты, которые были связаны со стрелками.
Если в процессе связывания стрелок с объектами модели данных не будет хватать сущностей или атрибутов, то их можно добавить непосредственно в BPwin, а затем экспортировать в ERwin.
Для того, чтобы отредактировать сущности в BPwin, необходимо выполнить команду Dictionary / Entity. В появившемся диалоговом окне Entity создается новая сущность.
Редактирование атрибутов созданных сущностей выполняется в диалоговом окне Attribute Dictionary, которое вызывается командой Dictionary / Entity / Attribute.
Новые сущности и атрибуты могут быть использованы для связывания со стрелками сразу же после их создания, то есть до их экспорта в ERwin.
После создания сущностей или атрибутов необходимо сохранить данные и выйти из словаря.
Экспорт данных из BPwin осуществляется выбором команды File/Export/ERwin 4.1 (BPX) и указанием файла, в который будет выгружена информация о модели. В ERwin необходимо выбрать команду File/Import/ERwin и в диалоге указать файл BPX, в который была выгружена информация о моделях.
|
|
|
После щелчка по кнопке Import происходит импорт BPX-файла. Импортированные новые сущности не имеют первичных ключей и не связаны с другими сущностями. Форматирование первичных ключей и связывание сущностей производится средствами ERwin. Физический уровень модели зависит от выбранного СУБД. ERwin поддерживает практически все современные СУБД, выбор конкретного СУБД выполняется командой Database/Choose Database. В диалоговом окне выбирается СУБД, тип данных и правила ссылочной целостности.
Глава 6. Реализация CASE -технологии в инструментальной среде Oracle Designer /2000
Основу CASE-технологии фирмы Oracle составляют следующие компоненты [6].
Реализуется методология структурного проектирования «сверху-вниз», при которой разработка системы представляется в виде последовательности четко определенных этапов модели ЖЦ (рис. 6.1).
Обеспечивается поддержка всех этапов ЖЦ системы, начиная с самых общих описаний предметной области до получения и сопровождения готового программного продукта.
ИС строится по архитектуре «клиент-сервер» с использованием всех особенностей современных серверов БД, включая декларативные ограничения целостности, хранимые процедуры, триггеры баз данных, и с поддержкой в клиентской части всех современных стандартов и требований к графическому интерфейсу конечного пользователя.
|
|
|
Обязательное использование репозитария для хранения спецификаций проекта разрабатываемой системы на всех этапах ее разработки и обеспечения доступа к ним всех участников разработки с учетом их прав доступа. Такой репозитарий представляет собой базу данных специальной структуры, которая работает под управлением СУБД.
Для доступа к репозитарию и управления им имеется навигатор, позволяющий просматривать и модифицировать объекты, хранящиеся в репозитарии, а также осуществлять административные функции: удаление, управление доступом, экспорт/импорт и т.п., и является местом, в котором создается ИС.
Рис. 6.1. Этапы построения ИС по технологии фирмы Oracle
В настоящее время заказчики получают в свое распоряжение не только прикладные программы и базу данных разработанной ИС, но весь репозитарий, что существенно упрощает процесс модификации и сопровождение системы.
Централизованное хранение проекта системы и управление одновременным доступом к нему всех участников разработки поддерживают согласованность действий разработчиков и не допускают ситуацию, когда каждый разработчик или программист работает со своей версией проекта и модифицирует ее независимо от других.
|
|
|
С помощью специальных утилит реализуется автоматизация перехода от одного этапа разработки к следующему. Эти утилиты позволяют по спецификациям концептуального уровня (модели предметной области) автоматически получить первоначальный вариант спецификаций уровня проектирования (описание структуры базы данных и состава программных модулей), а затем на их основе с учетом необходимых уточнений и дополнений автоматически генерировать готовые к выполнению программы (рис. 6.2).
На основе содержимого репозитария предусматривается генерация многочисленных отчетов, обеспечивающих полное документирование текущей версии системы на всех этапах ее разработки. С помощью специальных процедур предоставляется возможность проверки спецификаций на полноту и непротиворечивость.
Рис. 6.2. Среда создания и сопровождения прикладных систем (фирма Oracle)
В соответствии с общей архитектурой CASE-системы Designer/2000 можно выделить следующие этапы процесса разработки системы: моделирование и анализ деловой деятельности, разработка концептуальных моделей предметной области, проектирование прикладной системы и реализация (рис. 6.1).
Первый этап связан с моделированием и анализом процессов, описывающих деятельность организации, технологические особенности работы. Целью является построение моделей существующих процессов, выявление их недостатков и возможных источников усовершенствования. Эти действия выполняются в режиме постоянного диалога с заказчиком с помощью средства построения различных диаграмм, детализированных информационных и функциональных моделей проектируемой системы.
Подход, реализованный в Designer/2000, предполагает первым шагом в разработке системы моделирование бизнес-процесса в среде пакета Process Modeller (рис. 6.2). Полученная иерархическая модель процессов затем используется в качестве основы для разработки концептуальных моделей и проектирования системы (рис. 7.9, 7.10).
Затем применяют диаграммеры, входящие в Systems Modelling : Function Hierarchy Diagrammer – для построения функциональной модели (рис. 7.11), Entity Relationship Diagrammer – для построения логической модели базы данных в виде ER-диаграммы и Data Flow Diagrammer – для графического представления документооборота.
На втором этапе разрабатываются концептуальные модели предметной области, описывающие особенности функционирования системы, ее информационные потребности и т.п. Для выявления особенностей функционирования системы используются диаграммы потоков данных, оценка завершенности и полноты моделей производится с использованием множества матричных диаграмм.
Матричная диаграмма (Matrix Diagrammer) является средством анализа и модификации связей объектов различных типов. Для любого типа объектов репозитария, диаграммер автоматически выделяет подмножество связанных с ним типов и после указания требуемого (парного) типа строит соответствующую диаграмму в виде электронной таблицы. Например, описание модулей и используемых в них таблиц, описание модулей и используемых в них колонок таблиц.
Результатом являются модели двух типов: функциональные, описывающие особенности решаемых задач, и информационные, отображающие структуру и общие закономерности предметной области.
На этапе проектирования на основании концептуальных моделей вырабатываются технические спецификации будущей системы – специфицируется набор программных модулей, определяется структура и состав базы данных. Первоначальный вариант проектных спецификаций может быть получен автоматически с помощью специальных утилит на основании данных концептуальных моделей (рис. 6.3).
Утилита чернового проектирования Database Design Wizard на основе ER-модели выполняет генерацию описаний объектов базы данных (таблиц, внешних ключей, последовательностей и др.), а затем Data Diagrammer строит соответствующие диаграммы, отображающие взаимосвязи таблиц. Утилита представляет информационную модель ИС в виде множества объектов БД (таблиц, ключей, последовательностей и т.д.), определенных разработчиком в процессе проектирования.
Генерация описания прикладных программных модулей выполняется утилитой Application Design Wizard . Для этих целей используется информация, содержащаяся как в функциональной, так и в ER-модели проектируемой системы.
Формирование и просмотр структуры проектируемой системы (построение иерархии из полученных программных модулей) осуществляется с помощью Module Structure Diagrammer. Это средство описывает структуру прикладной системы на уровне взаимодействия следующих типов модулей: меню, экранных форм, отчетов, процедур и функций на языке PL/SQL, а также представляет следующие возможности: создание новых модулей; включение в диаграмму модулей, полученных утилитой Application Design Wizard; изменение описания модуля (тип, язык и т.п.); изменение описания использования данных в модуле; копирование, слияние и расщепление модулей.
Формирование детального описания использования данных каждым конкретным модулем осуществляется Module Data Diagrammer. Например, таблицы представляются отдельными прямоугольниками, со списками всех используемых полей. Связи между таблицами, соответствующие внешним ключам, отображаются в виде линий и используются для описания отношений типа родитель-потомок.
Здесь же разработчик имеет возможность специфицировать предполагаемый режим работы с таблицей. Например, будет ли в данном модуле разрешена модификация данных в таблице или она используется только для просмотра. Средство позволяет также быстро и простоопределить вид представления данных на экране (для диалоговых модулей).
Сложная логика обработки данных (хранимые процедуры, триггеры, функции и т.д.) описываются на языке PL/SQL, построенного на базе языка программирования Ada и языка структурированных запросов SQL. Инструментом для их создания и отладки служит Module Logic Navigator. Генерация модулей выполняется утилитой Server DDL Generator .
И наконец, на этапе реализации создается первая рабочая версия прикладной системы. Для этого необходимо на основе информации, хранящейся в репозитарии, выполнить генерацию объектов базы данных и исполняемых программных модулей, работающих с ней.
Генераторы, входящие в состав Designer/2000, разбиваются на две группы: генератор серверной части Server ( DDL ) Generator и генераторы клиентской части (или генераторы приложений) Forms Generator и Reports Generator.
Server Generator по спецификациям БД автоматически генерирует тексты программ на языке SQL (DDL-скрипты), после исполнения которых на сервере будет создана база данных.
|
Server Generator позволяет строить распределенные системы хранения и обработки данных, закрепляя объекты БД за конкретными узлами распределенной базы.
После того, как объекты базы данных будут созданы на сервере, разработчик может сгенерировать исполняемые модули на клиентской части для ведения диалога с оператором (экранные формы) и подготовки отчетов. Эта работа выполняется с помощью средств генерации экранных форм (Forms Generator) и отчетов (Reports Generator).
Эти средства могут быть вызваны непосредственно из Module Structure Diagrammer , Module Data Diagrammer , Preferences Navigator и применены для построения экранных форм и отчетов соответственно.
Наличие средств предварительной настройки позволяет изменять правила формирования экрана по умолчанию, что позволяет на этой стадии сгенерировать экранные формы максимально соответствующими требованиями заказчика. При необходимости сгенерированные тексты могут быть доработаны с помощью пакета Oracle Developer /2000.
Все действия по генерации экранных форм и отчетов выполняются автоматически на основе описаний структур таблиц данных и описаний программных модулей, хранящихся в репозитарии.
Таким образом, в идеальном случае концепция CASE-технологии выглядит следующим образом.
Системные аналитики совместно с представителями заказчика определяют желаемые возможности будущей системы и требования к ней, общаясь на понятном обеим сторонам формальном языке с использованием наглядных визуальных диаграмм. Затем построенные таким образом диаграммы, объединившие в одно целое все требования к системе, уточняются на техническом уровне проектировщиками, к ним добавляются детали реализации, после чего они автоматически транслируются в готовые исходные тексты программ.
Программисты их немного правят, настраивая различные нюансы поведения системы, и получают готовый продукт, в котором ошибок гораздо меньше, чем в приложениях, созданных традиционным ручным кодированием.
Дата добавления: 2019-07-17; просмотров: 104; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!