Обзор инструментария Oracle D e signer

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

Отдельным подразделом производится обосновывается выбор в качестве средства реализации инструментальной среды СУБД ORACLE.

Пример содержания второго раздела представлен ниже.

Характеритиска инструментария Oracle Designer.

Набор инструментальных средств Oracle Designer предлагает интегрированное решение для разработки прикладных систем корпоративного уровня для Web и клиент/серверных приложений. Oracle Designer участвует в каждой фазе жизненного цикла разработки программного обеспечения ­ от моделирования бизнес-процессов до внедрения. Применение единого репозитория, делает возможным использование любых его компонент для быстрой разработки масштабируемых, кросс-платформных распределенных приложений.

Задачей Oracle Designer является сбор данных о потребностях пользователей и автоматизация построения гибких графических приложений. Oracle Designer используется не только для создания приложений, но и для ведения учета изменений, которые неизбежно происходят при эксплуатации системы.

Графические модели определений проекта, интегрированные с многопользовательским репозиторием существенно облегчают работу с Oracle Designer. Инструментальные средства построены на базе общепринятых методик, охватывающих весь жизненный цикл разработки и позволяющих пользователям привычным для их организации способом. Это обеспечивает гибкость и открытость подхода к разработке программного обеспечения за счет использования только тех частей продукта, которые требуются в данной задаче. В рамках процесса разработки обеспечивается поддержка методов RAD, JAD, информационного проектирования, водопадного метода (waterfall), итеративного метода, а также индивидуального подхода, выбранного компанией.

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

Общая архитектура и основные компоненты DESIGNER.

В соответствии с общей архитектурой CASE-системы DESIGNER, выделяются следующие основные этапы процесса разработки системы: моделирование и анализ деловой деятельности, разработка концептуальных моделей предметной области, проектирование прикладной системы и реализация.

Первый этап связан с моделированием и анализом процессов, описывающих деятельность организации, технологические особенности работы. Целью является построение моделей существующих процессов, выявление их недостатков и возможных источников усовершенствования. Этот этап не является обязательным в случае, когда существующая технология и организационные структуры четко определены, хорошо понятны и не требуют дополнительного изучения и реорганизации. В состав DESIGNER/2000 входят удобные средства поддержки этого этапа, позволяющие строить наглядные представления процессов и взаимосвязей между ними и анализировать их с использованием средств мультимедиа.

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

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

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

В соответствии с общей архитектурой инструментальные средства, входящие в состав DESIGNER, разбиваются на следующие компоненты:

- средства доступа к репозитарию

- средства управления репозитарием

- средства анализа деловой деятельности

- средства концептуального моделирования

- средства проектирования системы

- генераторы приложений

Репозиторий - централизованная база данных проекта.

Все модели и спецификации, относящиеся к проекту прикладной системы и возникающие на различных этапах ее жизненного цикла, хранятся в централизованной базе данных ­ репозитория. Работа над проектом во многом сводится к работе с этой базой данных ­ вводу и коррекции различных описаний, проверке их согласованности и полноты, преобразованию одних моделей в другие и т. д. Вся информация в репозитории, относящаяся к одной и той же прикладной системе, называется приложением. В общем случае репозиторий может содержать несколько приложений.

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

Проектирование прикладной системы.

На этапе проектирования формируются все спецификации, описывающие структуру и основные компоненты будущей системы. Как и на предыдущем уровне эти спецификации разделяются на информационные и функциональные - на описание базы данных и описание состава программных модулей системы.

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

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

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

- утилита автоматической генерации спецификаций базы данных по ER- модели;

- процедура генерации спецификаций модулей по иерархии функций и потокам данных.

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

При генерации схемы базы данных по ER-модели каждой сущности ставится в соответствие таблица, атрибутам – столбцы таблиц, а для каждой связи создаются дополнительные столбцы и определяются ограничения целостности типа внешних ключей (foreign key constraint). Подтипы сущностей в ER-модели реализуются в схеме базы данных в виде одной общей таблицы или в виде совокупности нескольких – по одной на каждый подтип.

По иерархии функций и диаграммам потоков данных могут быть автоматически сгенерированы спецификации программных модулей прикладной системы, описывающие общие характеристики модулей, с какими таблицами работает каждый из них, возможные действия с этими таблицами и т. д. При этом анализируется диаграмма иерархии функций и для каждой элементарной функции (нижней в иерархии) создается спецификация модуля. Тип модуля устанавливается по определенным правилам в соответствии с указанным для функции способом работы с сущностями. Например, если известно, что функция использует сущности только для чтения информации, то считается, что ей должен соответствовать модуль типа отчет. Предусмотрена также возможность «объединять» некоторые однотипные функции, т. е. создавать один модуль сразу для нескольких различных элементарных функций. Основой для такого «объединения» служит также характер использования функциями сущностей ­ если две функции работают с одними и теми же сущностями и одинаково их используют, то это может считаться основанием для создания для них одного общего модуля. Разработчику предоставляется возможность регулировать уровень «объединения» функций путем выбора одного из имеющегося набора критериев.

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

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

В DESIGNER для этой цели предусмотрены:

- редактор схем баз данных

- редактор диаграмм взаимосвязей между модулями

- редактор схем использования данных в модуле (или схем модуля).