Введение

Одним из уже сложившихся направлений деятельности фирмы ORACLE стала разработка методологических основ и производство инструментальных средств для автоматизации процессов разработки сложных прикладных систем, ориентированных на интенсивное использование баз данных.
Основу CASE-технологии и инструментальной среды фирмы ORACLE [1-5] составляют:

• методология структурного нисходящего проектирования, при которой разработка прикладной системы представляется в виде последовательности четко определенных этапов (рис.1);
• поддержка всех этапов жизненного цикла прикладной системы, начиная с самых общих описаний предметной области до получения и сопровождения готового программного продукта;
• ориентация на реализацию приложений в архитектуре "клиент-сервер" с использованием всех особенностей современных серверов баз данных, включая декларативные ограничения целостности, хранимые процедуры, триггеры баз данных, и с поддержкой в клиентской части всех современных стандартов и требований к графическому интерфейсу конечного пользователя;.
• наличие централизованной базы данных, репозитария, для хранения спецификаций проекта прикладной системы на всех этапах ее разработки. Такой репозитарий представляет собой базу данных специальной структуры, работающую под управлением СУБД ORACLE;
• возможность одновременной работы с репозитарием многих пользователей. Такой многопользовательский режим почти автоматически обеспечивается стандартными средствами СУБД ORACLE. Централизованное хранение проекта системы и управление одновременным доступом к нему всех участников разработки поддерживают согласованность действий разработчиков и не допускают ситуацию, когда каждый проектировщик или программист работает со своей версией проекта и модифицирует ее независимо от других;
• автоматизация последовательного перехода от одного этапа разработки к следующему. Для этого предусмотрены специальные утилиты, с помощью которых можно по спецификациям концептуального уровня (модели предметной области) автоматически получать первоначальный вариант спецификации уровня проектирования (описание структуры базы данных и состава программных модулей), а по последним после всех необходимых уточнений и дополнений автоматически генерировать готовые к выполнению программы;
• автоматизация различных стандартных действий по проектированию и реализации приложения: предусматривается генерация многочисленных отчетов по содержимому репозитария, обеспечивающих полное документирование текущей версии системы на всех этапах ее разработки; с помощью специальных процедур предоставляется возможность проверки спецификаций на полноту и непротиворечивость и т.д.

Первая версия CASE-инструментария фирмы ORACLE, ORACLE*CASE 5.0 появилась в 1989 году для сервера ORACLE/6 с ориентацией на символьный режим для конечного пользователя. Существенные изменения потребовались в следующей версии, ORACLE*CASE 5.1 (1993г.), в связи с реализацией нового сервера ORACLE/7 и перехода к графическому интерфейсу конечного пользователя. В настоящее время завершена работа по выпуску в промышленную эксплуатацию новой CASE-среды под названием DESIGNER/2000, работающей в среде MS WINDOWS. Этот продукт вместе со средствами разработки DEVELOPER/2000 реализуют новый подход фирмы ORACLE к общей среде создания и сопровождения прикладных систем (рис. 2).

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

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

Анализ деловой деятельности Концептуальное моделирование Проектирование системы Генерация приложений	Информация	Процессы

Рис.3.

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

• средства доступа к репозитарию
• средства управления репозитарием
• средства анализа деловой деятельности
• средства концептуального моделирования
• средства проектирования системы
• генераторы приложений

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

Рис.4.

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

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

Рис. 5

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

Моделирование, анализ и реорганизация деловой деятельности

Средства анализа деловой деятельности - новый компонент, не имеющий аналогов в предыдущих версиях CASE - продуктов фирмы ORACLE. Он предназначен для описания и анализа деятельности организации или компании, визуального представления основных технологических процессов, способов коммуникации и т.п. Включение этого компонента в общую интегрированную среду DESIGNER 2000 связано с быстро развивающимся в последние годы новым направлением менеджмента, известным под названием анализ и реорганизация деловой деятельности (Business Process Reengineering)[6].
В рамках этого направления решаются задачи анализа деятельности предприятия или фирмы, перепроектирования и реорганизации основных технологических процессов с целью повышения эффективности, сокращения затрат, увеличения прибыли и др. Основой для этого служат модели деловой деятельности или модели процессов, отражающие различные аспекты работы производственного или коммерческого предприятия, включая организационные структуры, распределение работ, загрузку и занятость персонала и т. д.
При этом особые требования предъявляются к наглядности, выразительности таких моделей, их простоте для восприятия управленческим персоналом, не обязательно обладающим технической подготовкой и навыками работы с формальным аппаратом.
Входящие в состав DESIGNER 2000 средства моделирования процессов полностью отвечают этим требованиям. Использование средств мультимедиа, включая визуализацию, звуковое сопровождение, видеоизображение, анимацию, позволяет дополнительно повысить выразительность моделей процессов и обеспечивает возможность исследовать их динамические характеристики.
Общая модель деловой деятельности представляется в виде совокупности диаграмм, каждая из которых описывает отдельный процесс в виде его разбиения на взаимосвязанные друг с другом шаги или подпроцессы (рис.6).

базовый процесс; шаг процесса; поток данных; хранилище данных; организационная единица;

Рис.6.

Диаграмма строится из стандартных элементов, основными из которых являются:
Базовый процесс - процесс, определяющий общий контекст для всех подпроцессов данной диаграммы, т.е. тот главный процесс, который описывается данной диаграммой.
Шаг процесса - определенная часть деятельности в рамках базового процесса; впоследствии любой шаг может служить основой для нового базового процесса и новой диаграммы.
Хранилища - предназначены для представления некоторого информационного фонда или материального склада.
Потоки - описывают передачу информации или материальных объектов между двумя шагами процессов или между процессом и хранилищем.
Организационные единицы - представляют структуру предприятия или фирмы; допускается иерархическая структура организационных подразделений без ограничения на уровень вложенности.
События - могут быть входные и выходные; служат для связи различных диаграмм процессов.
По мере уточнения модели классифицируются шаги процессов (ввод данных, принятие решений, выдача отчета), типизируются потоки (поток данных, материальный поток, временный поток), хранилища (хранилище данных, материальный склад) и др. элементы. Для каждого типа можно использовать свое графическое представление, окраску (рис.7).

Рис. 7

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

Рис. 8

Кроме того для каждого типа объектов или для отдельного индивидуального объекта можно задать целый спектр разнообразных количественных параметров, включая, например, временные затраты и ресурсы, необходимые для выполнения того или иного шага процесса или для реализации некоторого потока. После этого с помощью специальной процедуры анимации можно "оживить" диаграмму, увидеть поведение модели в динамике с учетом введенных временных задержек и затрат ресурсов, заданных для отдельных составляющих. Такое "имитационное" моделирование наглядно показывает, как распределяется процесс по времени, а также дает представление о динамической зависимости между различными подпроцессами. В случае параллельных шагов процессов специальный механизм "анализ критических участков" выявляет "узкие" места в технологических цепочках и определяет возможные способы усовершенствования деятельности.
Вся информация, вводимая в модель, может быть экспортирована в стандартные пакеты электронных таблиц, такие как Microsoft Excel и Lotus-1-2-3. Это оказывается полезным для более глубокого сложного анализа временных и стоимостных затрат, для представления результатов в виде специальных графиков и диаграмм.

Концептуальное описание предметной области

Важнейшим этапом разработки прикладной системы является построение концептуальных моделей, как можно более полно описывающих особенности предметной области, характер решаемых задач, информационные потребности и ресурсы, технологические ограничения и т.д. В результате должны быть построены модели двух типов - информационная, отражающая существующие информационные структуры и взаимосвязи между ними, и функциональная, описывающая технологию и способы обработки информации, используемые в данной области.
В качестве стандартного средства информационного моделирования в современных CASE- методологиях используется в том или ином виде аппарат моделей "сущность-связь" или ER- моделей (Entity Relationship Model). Этот формализм позволяет представлять информационные потребности в виде, наглядном и удобном для восприятия, что делает их хорошим средством коммуникации между проектировщиками и пользователями в процессе уточнения постановки задач.
Теоретической основой этого подхода является известная модель "сущность-связь", введенная Ченом в 1976 году [7] и получившая широкое развитие и распространение в качестве средств концептуального проектирования баз данных. В основе модели Чена лежит представление о том, что предметная область состоит из отдельных объектов, находящихся друг с другом в определенных связях. Объекты описываются различными параметрами или атрибутами; однотипные объекты описываются одним и тем же набором параметров и объединяются в множества или классы; такие классы называются сущностями. Конкретные объекты, составляющие класс , называются экземплярами соответствующей сущности. Между сущностями специфицируются взаимосвязи различного вида: один к одному, один ко многим и др.
В CASE-методологии фирмы ORACLE используется некоторый специальный вид модели Чена, близкий к бинарной ER-модели. В этом случае взаимосвязи могут быть определены только между двумя сущностями. Кроме того, для взаимосвязей нельзя задавать атрибутов.
Для наглядного представления общей структуры предметной области все такие спецификации изображаются в графическом виде - в виде ER-диаграммы. На этой диаграмме объекты изображаются прямоугольниками, а связи - линиями, соединяющими соответствующие прямоугольники. Задание типа связи ("один к одному", "многие к одному" и т.д.) означает введение некоторого семантического ограничения. На диаграмме для каждого типа взаимосвязи используется свое графическое изображение: если любой экземпляр сущности A может быть связан с несколькими экземплярами сущности B, то со стороны прямоугольника-сущности A линия, выражающая взаимосвязь, дополняется специальным символом (рис. 9). Кроме того, для связи можно указать, является ли она обязательной для входящих в нее сущностей. Если любой экземпляр сущности A обязательно должен быть связан с каким-либо экземпляром сущности B, то прилегающая к прямоугольнику "A" половина линии - сплошная, в противном случае она - пунктирная.

Рис.9.

Например, на рис.9 для сущностей "СЛУЖАЩИЙ" и "ОТДЕЛ", определена взаимосвязь, описывающая распределение людей по отделам . В данном случае диаграмма моделирует следующие семантические ограничения:

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

Рис.10.

Кроме самой диаграммы для каждой сущности необходимо специфицировать описывающие его параметры, различные характеристики каждого параметра (тип, возможные значения, уникальность и др.). Вся эта информация и составляет информационную модель концептуального уровня.
Функциональные аспекты предметной области описываются с помощью диаграмм иерархии функций и потоков данных. Эти диаграммы отражают деятельность существующих организационных структур, технологические особенности процессов переработки информации и строятся по методологии проектирования "сверху вниз". Начиная с самой общей функции, описывающей деятельность всей организации в целом, аналитик последовательно разбивает это описание на более детальные функции, в совокупности составляющие исходную; в дальнейшем этот процесс продолжается применительно к новым, полученным на предыдущем уровне функциям. Такая декомпозиция функций завершается, когда функции, полученные на самом нижнем уровне иерархии, не поддаются дальнейшему разложению, т.е. являются элементарными. Для них специфицируется, с какими объектами они работают, какие типы действий при этом производятся (создание, удаление, модификация) как на уровне объектов, так и на уровне отдельных их параметров. Кроме этого, могут быть описаны события, вызывающие выполнение той или иной функции.
Дополнительно к иерархии функций для описания функционирования организационных структур и принятой технологии обработки информации используется еще один вид диаграмм - диаграммы потоков данных. Эти диаграммы служат для представления движения данных в процессе работы организационных структур и являются широко распространенным средством моделирования, знакомым многим системным аналитикам, проектировщикам, а иногда и пользователям. Для каждой неэлементарной функции строится диаграмма, на которой изображаются информационные взаимосвязи между составляющими эту функцию "под-функциями", указываются источники и приемники данных, места промежуточного временного накопления информации.
Входящие в состав DESIGNER/2000 средства концептуального моделирования представляют собой совокупность графических редакторов, обеспечивающих поддержку информационных и функциональных моделей концептуального уровня. В состав этих средств входят (рис. 4):

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

Рис. 11

Рис. 12

Рис. 13

Кроме собственно изображения диаграммы каждый из редакторов позволяет вводить дополнительную уточняющую информацию об отдельных элементах диаграммы. Например, для любой сущности, представленной на ER-диаграмме прямоугольником с названием, можно вызвать специальное окно для задания всевозможных характеристик этой сущности, включая атрибуты, первичные ключи, уникальные идентификаторы, ограничения или правила проверки для значений атрибутов, частотные характеристики и т.д. Аналогично, для любой взаимосвязи можно специфицировать, является ли она идентифицирующей (входит в состав какого-либо уникального идентификатора), переносимой ( можно динамически переопределять для любого экземпляра сущности типа "деталь", какому экземпляру "мастера" он подчиняется) и т.д.
Существенно, что в отличие от предыдущих версий ER-редакторов, здесь можно изображать непосредственно на диаграмме многие из таких дополнительных характеристик. Так, часто удобно бывает видеть на ER-диаграмме не только название сущности, но и определяющие ее атрибуты с указанием, какие из них являются ключевыми, какие - обязательными и т.д. (рис.11).
Дополнительно повышает наглядность и выразительность концептуальных моделей широкие возможности использования цвета и различных шрифтов для обозначения названий отдельных элементов.
Для одного и того же приложения предусматривается возможность построения нескольких ER- диаграмм и нескольких иерархий функций: это может быть полезно для сложных задач с огромным количеством объектов и связей. В этом случае естественно декомпозировать общую задачу и для каждой части рисовать свою ER-диаграмму.
Кроме средств ввода данных и построения графических изображений каждый редактор предоставляет возможность выполнять различные семантические проверки построенных диаграмм на полноту и корректность, а также генерировать разнообразные отчеты для документирования концептуального уровня разработки. Развитые средства вывода позволяют получить на бумаге любую диаграмму с помощью плотера или любого PostScript-принтера.

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

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

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

• редактор схем баз данных
• редактор диаграмм взаимосвязей между модулями
• редактор схем использования данных в модуле (или схем модуля)

Рис. 14

По внешнему виду диаграмма схемы БД похожа на ER-диаграмму. В простейших случаях, например, когда в ER-диаграмме не используются конструкции подтипов, соответствующая полученная по умолчанию диаграмма базы данных может почти совпадать с ER-диаграммой. Однако, даже и в этом случае в результате дальнейшего проектирования первоначальный вариант структуры БД может дополняться представлениями и другими дополнительными деталями, что приводит к изменению диаграммы.
Диаграмма взаимосвязей между модулями дает наглядное представление о структуре приложения с точки зрения взаимодействия между различными программными модулями. По внешнему виду диаграмма близка к иерархии функций, но семантически они различаются. Иерархия функций моделирует декомпозицию функций, начиная с более общих и кончая элементарными; иерархическое подчинение функций некоторой заданной означает, что они нужны для выполнения этой последней. В случае диаграммы взаимосвязей между модулями иерархическое подчинение означает вызов одних программных модулей из других в процессе работы приложения. Диаграмма взаимосвязей между модулями служит источником для генерации первоначального варианта главного меню прикладной системы.
Схема модуля представляет собой диаграмму, описывающую структуру отдельного программного модуля с точки зрения использования им данных.
Как и на диаграмме базы данных, в виде прямоугольников здесь изображаются таблицы, используемые в модуле, а с помощью соединительных линий - связи между таблицами. Такая связь может определяться при наличии в одной из базовых таблиц соответствующего внешнего ключа и на данной диаграмме эта связь означает, что в результирующем модуле, экранной форме или отчете, между двумя таблицами должно поддерживаться соотношение "мастер-деталь" (если таблицы имеют вертикальное относительное расположение) или одна из таблиц играет роль просмотровой или "lookup"-таблицей (таблицы в этом случае должны располагаться на одной горизонтали). Дополнительно, с помощью внешних линий можно задавать относительное расположение информационных блоков на экране.
На рис. 15 приводится пример использования диаграммы структуры модуля.

Рис. 15

На диаграмме определяется модуль типа экранной формы, в которой в одном окне должны высвечиваться данные из таблицы "ОТДЕЛЫ" и данные из таблицы "СОТРУДНИКИ", синхронизированные друг с другом (при переходе на новую строку в первом блоке соответственно меняются данные во втором блоке и т.п.). Кроме того, для таблицы "СОТРУДНИКИ" определена дополнительная просмотровая таблица для выбора и задания для каждого сотрудника его начальника. Результирующая сгенерированная экранная форма приведена на рис. 16.

Рис. 16

Кроме трех графических редакторов системного проектирования, в Designer/2000 включено специальное средство для определения программных модулей типа процедуры, написанной на языке PL/SQL (универсальный процедурный язык программирования, включающий в себя операторы языка SQL). Это средство, так называемый навигатор процедурной логики, представляет собой синтаксически-ориентированный редактор, позволяющий создавать программные тексты на языке PL/SQL по технологии "найди-и-выбери". Это означает, что вместо непосредственного набора текста операторов создание программы сводится к выбору нужной конструкции или объекта из "каталога". Особенность этого средства - его объектно- ориентированный интерфейс, существенно упрощающий процесс работы: "каталог" возможных конструкций языка PL/SQL и объектов базы данных представлен в виде иерархии типов с набором удобных средств просмотра и поиска необходимых элементов.

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

Входящие в состав DESIGNER/2000 генераторы разбиваются на две группы:

• генератор сервера
• генераторы клиентской части