DESIGNER/2000 - новое поколение CASE-продуктов фирмы ORACLE

О.Ю. Горчинская

НПВП "Форс", тел.: 973-60-47

Одним из уже сложившихся направлений деятельности фирмы 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, выделяются следующие основные этапы процесса разработки системы: моделирование и анализ деловой деятельности, разработка концептуальных моделей предметной области, проектирование прикладной системы и реализация.

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

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

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

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

Оставшаяся часть статьи посвящена более подробному рассмотрению каждого из этих компонентов.

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

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

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

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

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

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

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

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

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

Диаграмма строится из стандартных элементов, основными из которых являются:

Базовый процесс - процесс, определяющий общий контекст для всех подпроцессов данной диаграммы, т.е. тот главный процесс, который описывается данной диаграммой.

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

Хранилища - предназначены для представления некоторого информационного фонда или материального склада.

Потоки - описывают передачу информации или материальных объектов между двумя шагами процессов или между процессом и хранилищем.

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

События - могут быть входные и выходные; служат для связи различных диаграмм процессов.

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

С любым отдельным шагом процесса или с потоком можно связать специальное изображение в виде иконки, звуковое сопровождение, повышая выразительность и наглядность всей диаграммы в целом. Для более детального рассмотрения отдельный шаг процесса можно также связать с заранее заготовленным видеоклипом, показывающим, как осуществляется соответствующий технологический этап в реальной жизни (рис. 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 для сущностей "СЛУЖАЩИЙ" и "ОТДЕЛ", определена взаимосвязь, описывающая распределение людей по отделам. В данном случае диаграмма моделирует следующие семантические ограничения:

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

На рис. 10 приводится более сложный пример, иллюстрирующий дополнительные возможности ER-диаграмм: моделирование подтипов и исключающих взаимосвязей. В данном примере каждый сотрудник может принимать участие в некотором (не более чем одном) проекте или заниматься преподаванием одного учебного курса. При этом существует дополнительное правило: никто не может одновременно участвовать в проекте и преподавать. Такие исключающие друг друга взаимосвязи изображаются на диаграмме линиями, объединенными дугой (рис. 10). Кроме того, при изображении сущности "ПРОЕКТ" учитывается, что любой проект может быть одним из двух видов - исследованием или разработкой (каждый из этих подтипов описывается своим набором атрибутов).

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

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

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

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

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

Каждый из этих редакторов (диаграммеров) обеспечивает удобные средства работы с диаграммами определенного типа, отвечающие всем требованиям современного графического интерфейса (рис. 11 - 13).

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

Существенно, что в отличие от предыдущих версий ER-редакторов, здесь можно изображать непосредственно на диаграмме многие из таких дополнительных характеристик. Так, часто удобно бывает видеть на ER-диаграмме не только название сущности, но и определяющие ее атрибуты с указанием, какие из них являются ключевыми, какие - обязательными и т.д. (рис. 11).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На диаграмме схемы базы данных в виде прямоугольников изображаются таблицы и представления (view), а соединяющие их линии соответствуют взаимосвязям между таблицами, задаваемые внешними ключами (рис. 14). По внешнему виду диаграмма схемы БД похожа на ER-диаграмму. В простейших случаях, например, когда в ER-диаграмме не используются конструкции подтипов, соответствующая полученная по умолчанию диаграмма базы данных может почти совпадать с ER-диаграммой. Однако, даже и в этом случае в результате дальнейшего проектирования первоначальный вариант структуры БД может дополняться представлениями и другими дополнительными деталями, что приводит к изменению диаграммы.

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

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

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

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

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

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

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

Генераторы клиентской части обеспечивают автоматическое формирование текстов программных модулей по их спецификациям, записанным в репозитарии. Все модули приложения классифицируются по типам, основными из которых являются экранные формы, отчеты, процедуры. Для каждого типа имеется свой генератор, результатом работы которого является программа, написанная на языке, соответствующем этому типу: генератор форм создает приложения для ORACLE/Forms, генератор отчетов позволяет получать процедуры на PL/SQL либо приложения для ORACLE/Report.

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

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

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

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

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

При необходимости сгенерированный текст программы можно дополнительно доработать и дополнить, пользуясь непосредственно соответствующими инструментальными средствами разработки "нижнего уровня", входящими в состав DEVELOPER/2000. В этом случае появляется некоторая опасность несоответствия конечной версии программы спецификациям проекта, что особенно неудобно при возможных изменениях проекта, например схемы базы данных. Такое изменение требует перегенерации модулей с учетом новых таблиц и взаимосвязей, а с другой стороны выполнение повторной генерации "уничтожит" старую версию программы со всеми введенными "вручную" дополнительными фрагментами. Для такой ситуации в DESIGNER/2000 предусмотрен специальный режим работы генераторов - регенерация. При регенерации происходит не замена старого программного текста на новый, а его "редактирование", когда по возможности вносятся лишь необходимые изменения и не корректируются отдельные фрагменты. При этом можно управлять уровнем изменений и запретить модифицировать определенные фрагменты программы (например, все, относящееся к описанию расположения полей или триггеры заданного типа и т.п.). Из дополнительных средств, входящих в состав генераторов, особый интерес представляют утилиты, позволяющие использовать DESIGNER/2000 не только для новых разработок, начинающихся с этапа постановки задачи, но и для готовых прикладных систем, которые были спроектированы и реализованы без использования CASE-средств. Для такой ситуации предусмотрена возможность реинжениринга системы - автоматического создания по работающей версии приложения его описания в репозитарии, т.е. спецификаций структуры базы данных, программных модулей типа экранных форм и отчетов, ER-модели. Полученные описания могут быть использованы для анализа возможностей и выявления недостатков существующей версии приложения, а впоследствии модифицированы в соответствии с новыми требованиями и условиями функционирования системы. На основе отредактированных спецификаций производится генерация новой версии системы.

ЛИТЕРАТУРА

1. Barker, R. (1990). CASE*Method Entity Relationship Modelling. Wokingham, England, Addison-Wesley.
2. Barker, R. and Longman, C. (1993). CASE*Method Function and Process Modelling. Wokingham, England, Addison-Wesley.
3. Barker, R. et al. (1990). CASE*Method Tasks and Deliverables Modelling. Wokingham, England, Addison-Wesley.
4. Barker, R. and Clegg, D. (1994). CASE*Method Fast-Track A RAD Approach. Wokingham, England, Addison-Wesley.
5. Hickman, L. and Longman, C. Foreword by Barker, R.(1994). CASE*Method Business Interviewing. Wokingham, England, Addison-Wesley.
6. Hammer, M. and Champy, J. (1993). Reengineering the Corporation: A Manifesto for Business Revolution. Harper Collins, New York.
7. Yhen, P.P. (1976). The Entity-Relationship Model: Toward a Unified View of Data. ACM Transactions on Database Systems N1