Выбор СУБД для создания модели

ERwin поддерживает также настольные (desktop) СУБД: Microsoft Access, FoxPro, Clipper, dBASE III,
dBASE IV и Paradox.

Проектирование на физическом уровне выполняется в терминах той базы данных, которую
предполагается использовать в системе. Важно, что ERwin "известны" соответствия между
возможностями СУБД различных производителей, вследствие чего возможно преобразование
физической схемы, спроектированной для одной СУБД, в другую.

Для создания физической структуры БД может быть запрошена генерация DDL-скрипта (data
definition language). При этом используется диалект SQL для выбранного типа и версии сервера. Хотя
сгенерированный код не нуждается в модификации, имеется возможность его сохранить в файл или
распечатать.

С использованием побитовой схемой

С использованием побитовой схемой индексации Sybase IQ практически все данные в БД могут
быть проиндексированы. Поэтому никакой запрос не приведет к просмотру записей таблиц. Sybase
IQ обладает высокой производительностью для заранее запланированных запросов и отлично
справляется с запросами "на лету".



Sybase IQ не требует изменений в приложениях - любая программа, работающая с SQL Server,
будет работать с IQ. Собственно Sybase IQ не выполняет отдельных обновлений данных. Он в
прозрачном для клиента режиме передает их для выполнения SQL Server. Sybase IQ очень
эффективно выполняет пакетные дополнения к базе данных. В отличие от технологий, основанных
на B-деревьях, при добавлении 10 миллионов строк в таблицу, где уже есть десятки миллионов
строк, Sybase IQ просто построит дополнительные страницы индекса и не потребует перестраивать
весь индекс целиком.




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


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

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

Задание расширенных атрибутов PowerBuilder

Функция ERwin по генерации DataWindow позволяет сгенерировать прототипы окон данных
будущего приложения уже на стадии создания информационной модели. Для создания Data Windows
предлагается Wizard, с помощью которого указывается стиль окна и выбранные колонки
таблиц.

Кроме самой диаграммы для

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

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

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

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


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

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

Схема тиражирования

Выборочная подписка. Сервер подписки может не подписываться
вообще, подписаться на некоторые или на все публикации, предлагаемые
сервером публикаций вашего предприятия.
Выборочная подписка на статьи публикаций. Сервер подписки
может подписаться на все или некоторые статьи внутри публикации.
Защита публикаций. Каждая публикация имеет статус защищенной
или незащищенной (по умолчанию принимается отсутствие защиты). Если
публикация помечена как незащищенная, то она видна любому и на нее может
подписаться любой зарегистрированный сервер. В том случае если публикация
помечена как защищенная, она видна только тем серверам подписки, которым
дано такое право, и только они могут на нее подписаться.
Публикация вертикальных элементов таблицы. При
необходимости статья публикации может быть определена как набор столбцов
той или иной таблицы. При этом необходимо учесть, что среди этих столбцов
обязательно должны присутствовать те, что определяют первичный индекс.
Публикация горизонтальных элементов таблицы. Статья также
может включать только некоторые записи таблицы. В этом случае сервер
подписки получает только набор записей. (Кроме того, статья может включать
"прямоугольную вырезку", ограниченную набором столбцов и набором
записей.)
SQL Server 6.0 предоставляет исключительную гибкость в организации
топологии системы тиражирования данных. Базовые структуры тиражирования
включают следующие схемы:
один сервер публикаций, несколько серверов подписки (самая
простая схема). Один сервер определен как сервер публикаций. Эта схема
принимается по умолчанию и лучше всего подходит для создания
информационных систем, централизованного распространения информации,
снижения нагрузки основного сервера при создании различного рода отчетов и
т.п.;
один сервер публикаций с использованием промежуточного
сервера репликаций. Эта схема похожа на предыдущую, только с той
разницей, что заботу по рассылке информации всем подписчикам берет на
себя дополнительный сервер.
Это снижает нагрузку на основной сервер в том
случае, когда происходит интенсивная работа с большой базой данных.
Основной сервер (сервер публикаций) выполняет только обработку транзакций;
множество серверов публикаций, один сервер подписки. При
использовании такой схемы несколько серверов публикаций тиражируют
данные на единственный сервер подписки. Этот сценарий позволяет
консолидировать данные в едином центре. Подобная модель может
использоваться для локальной обработки данных у клиентов в удаленных
подразделениях;
несколько серверов подписки, несколько серверов публикаций.
При использовании такой схемы несколько серверов могут играть двойную
роль (выступать одновременно и как серверы подписки, и как серверы
публикаций). Эта схема подходит для использования в децентрализованных
организациях, системах резервирования, региональных отделениях. Подобная
конфигурация должна быть создана вручную.

SQL Anywhere имеет продуманную

SQL Anywhere имеет продуманную языковую поддержку. При создании каждой базы данных
указывается, в частности, порядок сортировки символов. Эта информация используется при
выполнении сортировки ORDER BY, сравнения символов без учета регистра, использовании
символов для написания идентификаторов объектов базы данных, обработке фразы LIKE и
различных строковых функций.

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

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

С другой стороны, с выходом SQL Anywhere группы разработчиков могут использовать этот
продукт с уверенностью в том, что при необходимости возможен переход на более мощные
аппаратные и программные платформы (RISC-станции и Sybase SQL Server).

Действительно, включение SQL Anywhere в состав линии продуктов Sybase придало новые
качества продукту и сделало его выбор для рабочих групп еще более привлекательным не только
по цене, но и по наиболее важным характеристикам:


собственная репликация данных - SQL Remote;
поддержка системы репликации Sybase Replication Server;
графический инструмент администрирования SQL Central;
поддержка Transact-SQL;
поддержка ODBC 2.1;
повышение производительности и мониторинг производительности;
расширения языка Watcom SQL;
универсальный серверный интерфейс SQL Anywhere Open Server.

SQL Anywhere поддерживает два различных механизма репликации.

База данных SQL Anywhere может участвовать в схеме репликации Sybase Replication Server. Это
мощная, сложная и высокопроизводительная компонента, тиражирующая данные между
разнородными СУБД, описана выше (рис.8). Для интеграции с Replication Server используется
специальный шлюзовой компонент - Open Server Gateway для SQL Anywhere, который
"транслирует" стандартный для продуктов Sybase интерфейс Open Client/Server в интерфейс SQL
Anywhere.

Для отслеживания изменений в базе данных SQL Anywhere предусмотрена компонента Replication
Agent.

Другой механизм репликации (SQL Remote) - это система репликации только между базами
данных SQL Anywhere. Это менее гибкая система, чем Replication Server; например, в ней жестко
требуется, чтобы имена объектов тиражирования были одинаковыми во всех базах данных. Зато
SQL Remote легко администрируется, пригоден для широкого использования в том числе и в
случаях, когда базы данных не имеют прямого соединения друг с другом.

Определение домена

Назначение доменов для сервера аналогично назначению доменов для клиента. Различие заключается
в том, что правила и начальные значения для сервера определяются в генерации схемы базы данных, а
аналогичные атрибуты для клиента - сохраняются в репозитарии средства 4GL.

Другое назначение доменов для сервера - определение пользовательских типов данных.
Пользовательскому типу данных ставится в соответствие тип, "известный" СУБД. При выполнении
синхронизации с базой данных для СУБД, поддерживающих пользовательские типы, выполняется
соответствующие команды. Например, для Sybase выполняется команда:

sp_addtype person_name, "char(64)", "NOT NULL"

Службы сообщений используют адрес

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

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

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

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

Система репликации администрируется централизованно в консолидированной БД средствами
графического инструмента SQL Central.

Публикация может быть использована несколькими подписчиками.

В SQL Remote реализована поддержка систем передачи сообщений MAPI, VIM, SMTP и
файлового обмена.

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


Два пользователя добавляют в таблицу строку с одинаковым первичным
ключом (ПК). В этом случае второй INSERT закончится неудачно. Этой
ситуации можно избежать при правильном проектировании БД. Например,
включить колонку - идентификатор БД, где происходит обновление, в
первичный ключ такой таблицы.
Два пользователя обновляют одну и ту же колонку в таблице (не ПК). Если
в системе требуется обеспечить пользователям такую потенциально опасную
возможность, то SQL Anywhere предоставляет средство обнаружить и
разрешить конфликт с помощью специального типа триггера (RESOLVE
UPDATE).

Варианты выдачи отчета

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

Для подготовки развитых отчетов может быть использован специальный генератор отчетов фирмы
Logic Works - RPTwin, который интегрирован с ERwin. Пример конструирования отчета в RPTwin
приведен на рис.13.

Кроме собственно изображения диаграммы

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

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

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

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

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

схемы БД похожа на

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

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

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

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

На рис. 15 приводится пример использования диаграммы структуры
модуля.

На диаграмме определяется модуль

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

Кроме трех графических редакторов

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

Семейство Powersoft Enterprise Series

PowerBuilder&#153 входит в состав Powersoft Enterprise Series&#153, семейство инструментальных
средств для разработки масштабируемых приложений в среде клиент/сервер, которые могут быть
использованы различными категориями пользователей организации - от разработчиков сложных
корпоративных информационных систем до разработчиков на уровне отделов и конечных
пользователей.

Построенные на унифицированной платформе клиент/сервер и единой объектной технологии
продукты Powersoft Enterprise Series представляют собой среду разработки приложений в
масштабах предприятия(Enterprise Development Architecture).

В Powersoft Enterprise Series входят различные редакции PowerBuilder. PowerBuilder Enterprise
предназначен для создания сложных многоплатформных приложений клиент/сервер коллективами
профессиональных разработчиков. PowerBuilder Team/ODBC обеспечивает возможность
коллективной разработки и работает с серверами баз данных через ODBC. PowerBuilder Desktop
предназначается индивидуальным разработчикам, создающим автономные приложения под Windows
с помощью Watcom SQL и настольных баз данных. Advanced Developer Toolkit включает библиотеку
многократно используемых объектов, а также развитые инструментальные средства, такие как
редактор изображений и построитель инсталяционных дискет, а также поддержку хранимых процедур
баз данных, NetWare и ввод данных с помощью пера.

В Powersoft Enterprise Series также включен InfoMaker&#153 - персональный инструмент разработки в
среде клиент/сервер, который позволяет конечным пользователям создавать запросы, формы, отчеты и
деловую графику. Пользователи могут манипулировать данными, применяя подход, основанный на
формах и не требующий программирования.


Продукты для всех

WATCOM C, C++ PowerBuilder Enterprise
PowerBuilder Team/ODBC PowerBuilder Desktop
InfoMarker

Семейство продуктов Powersoft Enterprise Series предоставляет менеджерам информационных систем
возможность использовать преимущества технологии клиент/сервер в масштабе всего предприятия.
Так как все продукты основаны на общей объектной технологии, пользователи могут создавать
приложения и передавать их в любое время менеджерам для продолжения разработки, поддержки или
сопровождения. Таким образом, разработчики и конечные пользователи получают инструменты,
которые позволяют использовать преимущества технологии клиент/сервер в рамках всей
организации.

Серверные продукты компании Informix

Н.Вьюкова
СУБД INFORMIX, первая версия которой вышла в 1980 г., традиционно использовалась для
создания информационных систем малого или среднего масштаба, работающих в режиме
оперативной обработки транзакций. Однако, начиная с версии 6.0, сервер Informix, получивший
название Informix-Online Dynamic Server (Informix ODS), прибрел такие черты, которые позволили
с успехом применять эту СУБД для реализации крупных проектов.

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

Архитектурные и технологические решения, положенные в основу Informix-ODS, нашли
дальнейшее развитие в последнем серверном продукте компании - Informix-Online EXtended
Parallel Server (Informix-ОXPS), который предназначен для кластерных и массово-параллельных
платформ и предоставляет повышенный уровень производительности и отказоустойчивости.

В докладе дается обзор архитектурных принципов и механизмов, которые определили новое
качество последних моделей серверов Informix. Основные направления развития этих продуктов
связаны с важнейшими требованиями, предъявляемыми к СУБД, которая претендует на роль
информационной основы современного предприятия :


высокая производительность
масштабируемость
смешанная загрузка сервера разными типами задач
непрерывная доступность данных

Синхронизация с базой данных

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

Для этого предусмотрена функция синхронизации с базой данных. После подключения к СУБД
предлагается список несоответствий между существующей структурой данных и моделью. Например,
если в базе данных создана новая таблица, то ERwin предложит провести включение ее в модель.
Если в модель добавлена новая таблица, ERwin предложит создать ее в реальной базе данных.
Аналогично, при добавлении колонок в базе данных или в модели ERwin предлагает провести
соответствующие операции по синхронизации. Процедура выбора синхронизируемых таблиц
показана на рис.7.

Синхронная модель. Двухфазная фиксация

Исторически первым появился метод синхронного внесения изменений в несколько БД,
называемый двухфазной фиксацией (2PC - two-phase commit). Этот механизм реализован сейчас
практически у всех производителей СУБД.

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

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

Система моделей описания требований к ИС

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

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

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

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

Системы сквозного проектирования

А. Закис, Н. Приезжий, DataX/FLORIN










В предшествующих выступлениях и публикации мы неоднократно рассматривали технологию сквозного проектирования информационных систем, основанную на использовании CASE инструментария фирмы Cayenne (VantageTeam), сред разработки приложений фирм Informix (4GL и NewEra) и Four Seasons (SuperNova) и кодогенераторов фирмы DataX/FLORIN (GRINDERY OneStep 4GL, GRINDERY NewEra/Yourdon, GRINDERY SuperNova/Yourdon). В данном выступлении мы хотели бы рассказать о новом продукте нашей фирмы - среде быстрой разработки GRINDERY Grabber.

Технология

Прежде всего, мы хотели бы ответить на вопрос, который нам неоднократно задавали во время UnixExpo, где был представлен этот продукт: почему мы взялись за его разработку в то время, когда на рынке имеется достаточное количество разнообразных CASE средств и билдеров. Ответ прост - этот продукт "создался сам" из тех технических решений, которые мы использовали при работе над собственными проектами или предлагали нашим клиентам для того, чтобы соединить различные средства автоматизации проектирования и программирования в единый технологический процесс, и которые отсутствовали (или были недостаточно развиты) в готовых продуктах .

Что же не устраивало нас в стандартных подходах? Для ответа на этот вопрос рассмотрим две модели использования средств автоматизации: "до и от" и "от и до".

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

Второй подход (реализованный в "тяжелых" CASE средствах, например, в VantageTeam) предполагает, что в CASE поддерживает разработку "от" анализа "до" логических моделей данных и приложения, на основе которых создается база данных и осуществляется автоматическая генерация программного кода. VantageTeam предоставляет пользователю прекрасный инструментарий для проектирования приложения:
диаграммы содержания экранных форм (FCD - Form Contence Diagram), которые позволяют описать структуру и (в значительной степени) функциональность сложных экранных форм (предназначенных для работы с несколькими таблицами);
диаграммы структурных схем (SCD - Structure Charts Diagram), которые позволяют описать алгоритмы программных модулей и методы работы с экранными формами (последняя задача в рамках структурного подхода достаточно элегантно решена с помощью так называемых "предопределенных модулей");
диаграммы последовательности экранных форм (FSD - Form Sequence Diagram), которая задает общую структуру приложения. а также связывает формы и алгоритмы (методы).

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



Наша фирма пошла по пути проектирования стандарта. Результатом этой работы стала технология сквозного проектирования и семейство кодогенераторов GRINDERY.

Однако их область их применения существенно ограничивалась тем, что они были настроены на логическую модель данных, формируемую VantageTeam. Затраты на приобретение и освоение "тяжелого" CASE окупаются только при создании достаточно крупных систем или при "поточном" производстве, а многие возможности, предоставляемые продуктами этого класса, не столь уж необходимы для создания небольшой системы разработчиками, хорошо знающими предметную область ( и, тем более, для воспроизведения существующей системы на другой платформе, что является весьма актуальной задачей для многих систем ). И мы занялись разработкой "легкой" технологии сквозного проектирования "от" существующей базы данных. Ее основные отличия от рассмотренной выше технологии "до и от" состоят в следующем:
при реверсинжениринге создается не физическая, а логическая модель данных, на основе которой осуществляется генерация стандартного интерфейса ;
билдеры используются только в режиме модификации, причем внесенные изменения автоматически фиксируются и воспроизводятся при повторной генерации.

Продукт (GRINDERY Grabber v.1.0) и проект (GRINDERY Grabber v.2.x)

GRINDERY Grabber v1.0 обеспечивает:
восстановление логической модели базы данных на основе информации, хранящейся в системных каталогах;
интерфейс для ввода параметров, описывающих стандарт приложения;
генерацию приложения на любом языке, поддерживаемом семейством кодогенераторов GRINDERY (в настоящее время - Informix- 4GL, NewEra, SuperNova);
фиксацию изменений, внесенных в программный код пользователем и их воспроизведение при повторной генерации;
модификацию структуры базы данных в объеме, необходимом для эффективной работы стандартного приложения.
GRINDERY Grabber v1.0 поддерживает:
групповую работу над проектами и управление версиями проектов, в том числе:



- разграничение прав доступа;

- независимую разработку частей проекта;

- сборку проекта ;

документирование проекта.

GRINDERY Grabber v1. 0 поддерживает разработку приложений для СУБД Informix, Oracle, CA OpenIngres и может работать на основных Unix и всех Windows платформах.

Принципы построения стандартного интерфейса

Для каждой сущности (предметной таблицы базы данных) создается "рабочее место", позволяющее выполнять основные операции (INSERT, UPDATE, DELETE, QBE) с данными, содержащимися в этой таблице.
Рабочее место позволяет работать не только с "главной" таблицей, но и с другими ("вспомогательными" для данного рабочего места) таблицами базы данных. В том случае, когда реляционная модель данных адекватно отражает связи и бизнес-правила предметной области, вспомогательными являются "таблицы-словари" ( Master tables - таблицы, из которых импортирует ключи "главная" таблица), "таблицы-потомки" (Detail tables - таблицы, которые содержат ссылки на "главную") и "таблицы-партнеры" (связанные с "главной" таблицей отношением "многое ко многому"). Вспомогательные таблицы доступны как в режиме просмотра, так и в режиме модификации (если это необходимо для данного рабочего места).
Каждая таблица имеет в интерфейсе два представления:

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



При таком подходе основная информация, необходимая для генерации приложения "считывается" из логической модели данных. Пользователю необходимо задать незначительное количество атрибутов:
имена, под которыми должны отображаться таблицы и их колонки;
состав предметного ключа (кодогенерация рассчитана на то, что в качестве первичного используется искусственный ключ - колонка типа SERIAL);
форму представления колонок в графическом интерфейсе (Entry, Label etc)
состав краткого представления таблиц;
возможность модификации таблицы-словаря;
необходимость и форму представления информации из таблиц-потомков и таблиц-партнеров в детальной форме;
политику поддержки целостности при удалении.

Структура GRINDERY Grabber

GRINDERY Grabber включает:
модуль Reverse Engineering;
модуль DB Designer;
модуль Access;
модуль Tuner (v.2.x);
модуль App Designer;
кодогенераторы GRINDERY;
модуль Target Bridge;
модуль Test Designer (v.2.x).

Модуль Reverse Engineering обеспечивает построение логической модели данных.

Модуль DB Designer предназначен для проектирования (v.2.x) и модификации модели базы данных.

В версии 1.0 поддерживается:
модификация базы данных в минимальном объеме, необходимом для эффективной работы приложения (переход от предметных ключей к искусственным, создание UNIQUE CONSTRAINTS для предметных ключей, создание триггеров, поддерживающих политику Nullify, создание служебных таблиц для SuperNova);
ведение архива пользовательского DDL.

В версии 2.х предполагается:
навигационный интерфейс, обеспечивающий представление всех объектов базы данных, включая триггера и хранимые процедуры;
конструктор логической модели данных;
конструктор триггеров и хранимых процедур, основанный на синтаксической декомпозиции DDL, библиотеке шаблонов и языке подстановок.

Модуль Access обеспечивает:
автоматическую генерацию DDL (в версии 1.0 - по шаблонам, в 2.х - генерация DDL для любой из поддерживаемых СУБД по логической модели данных, триггеров и хранимых процедур);


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

Модуль Tuner обеспечивает:
трассировку SQL запросов;
фиксацию времени исполнения SQL запросов;
проведение исторических тестов (сравнение результатов исполнения SQL запросов с эталоном);
ведение архива тестов и результатов их исполнения;
генерацию стандартного или задаваемого пользователем структурированного отчета по результатам трассировки;
статистическую обработку и графическое представление результатов замеров производительности.

Модуль App Designer предназначен для построения логической модели приложения и содержит:
графический (навигационный) интерфейс ввода информации;
генератор текстовых отчетов .

Кодогенераторы Grindery обеспечивают генерацию исходных кодов приложений на языках Informix- 4GL, NewEra, SuperNova. В состав всех кодогенераторов входят расширенные библиотеки классов (функций). Генератор для SuperNova содержит открытую библиотеку шаблонов.

Модуль Target Bridge обеспечивает:
фиксацию изменений, внесенных пользователем (только для NewEra; для Informix- 4GL и SuperNova эта функция реализована в кодогенераторе);
генерацию make-файла;
оптимизацию процесса трансляции WIF-файлов (утилита 4GLGEN для NewEra).

Модуль Test Designer включает :
конструктор тестов, основанный на открытой библиотеке шаблонов и языке подстановок;
средства контроля полноты тестов, основанные на синтаксическом анализе SQL и логической модели базы данных;
генератор тестов на производительность (имитация многопользовательского режима и "клонирование" SQL запросов,
графический интерфейс представления теста и его воздействия на объекты базы данных.

Сценарии использования GRINDERY Grabber

Наша фирма предлагает следующие сценарии использования GRINDERY Grabber v.1.0
при работе над большими проектами (и фирм занимающихся индустриальной разработкой информационных систем) GRINDERY Grabber v.1.0 может использоваться как дополнение к "тяжелому" CASE (при использовании VantageTeam, в силу совместимости формата хранения модели данных, разработка стандарта приложения не требует создания целевой базы данных).


Такое использование не только позволяет сократить количество дорогих рабочих мест, но и позволяет изменить подход к проектированию базы данных. В CASE достаточно разработать концептуальную модель данных (используя такие составные предметные ключи, ассоциативные объекты, субтипы), а ее приведения к "удобному для СУБД" виду будет сделано автоматически. Кроме того, GRINDERY Grabber позволяет провести быстрое прототипирование приложения, что позволяет провести окончательную верификацию модели данных;
при разработке средних систем и решении задач миграции существующих систем в новую среду разработки GRINDERY Grabber может использоваться не только как средство создания конечного приложения, но и как средство сравнительной оценки разных средств разработки (поскольку приложение может быть создано и протестировано в пределах срока демо лицензии);
при решении проблем сопровождения плохо документированных систем .

Дополнения, предусмотренные в GRINDERY Grabber v.2.x позволят использовать его:
в качестве инструмента проектирования и отладки серверной части приложения;
как инструмент поддерживающий миграцию существующих систем на новую СУБД. При этом поддерживается не только миграция на выбранную СУБД но и ее выбор по результатам сравнительного тестирования;
как инструмент тестирования существующих систем. .







[]
[]
[]

Словарь Данных (Data Dictionary)

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

Словарь Данных PROGRESS также:


позволяет увеличить производительность разработки приложений, за счет
повторного использования центрально-определяемых описаний объектов;
гарантирует, что все Ваши приложения будут иметь предсказуемый
внешний вид и поведение при использовании ранее определенных объектов;
обеспечивает независимость базы данных;
снижает стоимость поддержки - приложения сразу же воспринимают и
отражают все изменения, сделанные в центрально-определяемых описаниях
объектов. Центральное-хранимые (centrally-stored) описания данных

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

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


форматы, которые описывают каким образом поле базы данных будет

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

Все средства PROGRESS ADE, а так же PROGRESS 4GL, автоматически наследуют определения
Словаря Данных при построении новых компонентов программы. Централизованное хранение и
поддержка определений снижают затраты на построение новых форм, отчетов и процедур.
Использование централизованного описания объектов к тому же значительно облегчает
поддержку приложений в дальнейшем, - изменение определения в Data Dictionary будет
унаследовано всеми компонентами приложений, которые ссылаются на это определение.

Проверка корректности ввода данных и триггеры базы данных

Словарь Данных позволяет определить набор правил для проверки вводимых данных и их
целостности, включая процедуры на 4GL. Эти правила носят название триггеров базы данных.
Триггеры написаны на PROGRESS 4GL и связаны с определением конкретной таблицы или поля в
Словаре Данных. PROGRESS автоматически выполняет триггер базы данных всякий раз, когда
программа обращается к соответствующей таблице или полю. Триггеры используются для
принудительной проверки корректности ввода данных, обеспечения безопасности и поддержки их
целостности. В сочетании с другими установками по умолчанию, хранимыми в Словаре Данных,
применение триггеров существенно снижает затраты сил и времени на разработку приложений,
именно по причине их центрального хранения вместе с данными.

Современные CASE-технологии

А. Вендров, Центральный Банк РФ (Москва)

















Многие организации-разработчики программного обеспечения информационных систем (ПО ИС), пытаясь внести усовершенствования в процесс разработки, обращаются к CASE-технологии. Согласно обзору передовых технологий (Survey of Advanced Technology), составленному фирмой Systems Development Inc. в 1996 г. по результатам анкетирования более 1000 американских фирм, CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно). Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся "полочным" ПО (shelfware). В связи с этим необходимо отметить следующее:
CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;
реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;
CASE-средства обеспечивают возможности для получения существенной выгоды только после успешного завершения процесса их внедрения.

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

Ключом к успешному внедрению CASE-средств является готовность организации, которая включает следующие аспекты:

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

В случае отсутствия готовности по данным аспектам внедрение CASE-средств скорее всего закончится неудачей независимо от степени тщательности следования различным рекомендациям по внедрению.

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

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

Технология освоения и внедрения CASE-средств

Современная технология освоения и внедрения CASE-средств базируется в основном на стандартах-рекомендациях IEEE (IEEE Std 1348-1995. IEEE Recommended Practice for the Adoption of CASE Tools и IEEE Std 1209-1992. IEEE Recommended Practice for the Evaluation and Selection of CASE Tools). Процесс внедрения CASE-средств состоит из следующих этапов:
определение потребностей в CASE-средствах;
оценка и выбор CASE-средств;
выполнение пилотного проекта;
практическое внедрение CASE-средств.



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

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

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

Потребности организации в CASE-средствах должны соразмеряться с реальной ситуацией на рынке или собственными возможностями разработки.


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

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

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

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

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

Типичный процесс оценки и/или выбора может использовать набор критериев различных типов.


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

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

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



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


приобрести собственный опыт использования CASE-средства.

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

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

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


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

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

Характеристика современных CASE-средств

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

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

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


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

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:
применяемым методологиям и моделям систем и БД;
степени интегрированности с СУБД;
доступным платформам.

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:
средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF, BPwin);
средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder, Designer/2000, Silverrun, PRO-IV, CASE.Аналитик). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin, S-Designor и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;
средства разработки приложений. К ним относятся средства 4GL (Uniface, JAM, PowerBuilder, Developer/2000, New Era, SQLWindows, Delphi и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;


средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose, Object Team).

Вспомогательные типы включают:
средства планирования и управления проектом (SE Companion, Microsoft Project и др.);
средства конфигурационного управления (PVCS, SCCS и др.);
средства тестирования (Quality Works и др.).

На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:
Vantage Team Builder (Westmount I-CASE);
Designer/2000;
Silverrun;
ERwin+BPwin;
S-Designor;
CASE.Аналитик;
Rational Rose.

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

CASE-средство Silverrun американской фирмы Сomputer Systems Advisers, Inc. (CSA) используется для анализа и проектирования ИС бизнес-класса и ориентировано в большей степени на спиральную модель ЖЦ. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм "сущность-связь").

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

Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных (BPM - Business Process Modeler) позволяет моделировать функционирование обследуемой организации или создаваемой ИС. Модуль концептуального моделирования данных (ERX- Entity-Relationship eXpert) обеспечивает построение моделей данных "сущность-связь", не привязанных к конкретной реализации.


Модуль реляционного моделирования (RDM - Relational Data Modeler) позволяет создавать детализированные модели "сущность-связь", предназначенные для реализации в реляционной базе данных. Менеджер репозитория рабочей группы (WRM - Workgroup Repository Manager) применяется как словарь данных для хранения общей для всех моделей информации, а также обеспечивает интеграцию модулей Silverrun в единую среду проектирования.

Платой за высокую гибкость и разнообразие изобразительных средств построения моделей является такой недостаток Silverrun, как отсутствие жесткого взаимного контроля между компонентами различных моделей (например, возможности автоматического распространения изменений между DFD различных уровней декомпозиции). Следует, однако, отметить, что этот недостаток может иметь существенное значение только в случае использования каскадной модели ЖЦ ПО.

Для автоматической генерации схем баз данных у Silverrun существуют мосты к наиболее распространенным СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase. Для передачи данных в средства разработки приложений имеются мосты к языкам 4GL: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Все мосты позволяют загрузить в Silverrun RDM информацию из каталогов соответствующих СУБД или языков 4GL.

Система Silverrun реализована на трех платформах - MS Windows, Macintosh и OS/2 Presentation Manager - с возможностью обмена проектными данными между ними.

Vantage Team Builder представляет собой интегрированный программный продукт, ориентированный на реализацию каскадной модели ЖЦ ПО и поддержку полного ЖЦ ПО.

Vantage Team Builder обеспечивает выполнение следующих функций:
проектирование диаграмм потоков данных, "сущность-связь", структур данных, структурных схем программ и последовательностей экранных форм;
проектирование диаграмм архитектуры системы - SAD (проектирование состава и связи вычислительных средств, распределения задач системы между вычислительными средствами, моделирование отношений типа "клиент-сервер", анализ использования менеджеров транзакций и особенностей функционирования систем в реальном времени);


генерация кода программ на языке 4GL целевой СУБД с полным обеспечением программной среды и генерация SQL-кода для создания таблиц БД, индексов, ограничений целостности и хранимых процедур;
программирование на языке C со встроенным SQL;
управление версиями и конфигурацией проекта;
многопользовательский доступ к репозиторию проекта;
генерация проектной документации по стандартным и индивидуальным шаблонам;
экспорт и импорт данных проекта в формате CDIF (CASE Data Interchange Format).

Vantage Team Builder поставляется в различных конфигурациях в зависимости от используемых СУБД (ORACLE, Informix, Sybase или Ingres) или средств разработки приложений (Uniface). Конфигурация Vantage Team Builder for Uniface отличается от остальных некоторой степенью ориентации на спиральную модель ЖЦ ПО за счет возможностей быстрого прототипирования, предоставляемых Uniface. Для описания проекта ИС используется достаточно большой набор диаграмм. При построении всех типов диаграмм обеспечивается контроль соответствия моделей синтаксису используемых методов, а также соответствия одноименных элементов и их типов на различных типах диаграмм.

Конфигурация Vantage Team Builder for Uniface обеспечивает совместное использование двух систем в рамках единой технологической среды проектирования, при этом схемы БД (SQL-модели) переносятся в репозиторий Uniface, и, наоборот, прикладные модели, сформированные средствами Uniface, могут быть перенесены в репозиторий Vantage Team Builder. Возможные рассогласования между репозиториями двух систем устраняются с помощью специальной утилиты. Разработка экранных форм в среде Uniface выполняется на базе диаграмм последовательностей форм (FSD) после импорта SQL-модели.

Структура репозитория (хранящегося непосредственно в целевой СУБД) и интерфейсы Vantage Team Builder является открытыми, что в принципе позволяет интегрировать его с любыми другими средствами.

Vantage Team Builder функционирует на всех основных UNIX-платформах (Solaris, SCO UNIX, AIX, HP-UX) и VMS.



CASE-средство Designer/2000 2. 0 фирмы ORACLE является интегрированным CASE-средством, обеспечивающим в совокупности со средствами разработки приложений Developer/2000 поддержку полного ЖЦ ПО для систем, использующих СУБД ORACLE.

Designer/2000 представляет собой семейство методологий и поддерживающих их программных продуктов. Базовая методология Designer/2000 (CASE*Method) - структурная методология проектирования систем, охватывающая полностью все этапы жизненного цикла ИС.

Designer/2000 обеспечивает графический интерфейс при разработке различных моделей (диаграмм) предметной области. В процессе построения моделей информация о них заносится в репозиторий. В состав Designer/2000 входят следующие компоненты:
Repository Administrator - средства управления репозиторием (создание и удаление приложений, управление доступом к данным со стороны различных пользователей, экспорт и импорт данных);
Repository Object Navigator - средство доступа к репозиторию, обеспечивающие многооконный объектно-ориентированный интерфейс доступа ко всем элементам репозитория;
Process Modeller - средство анализа и моделирования деловой деятельности, основывающееся на концепциях реинжиниринга бизнес-процессов (BPR - Business Process Reengineering) и глобальной системы управления качеством (TQM - Total Quality Management);
Systems Modeller - набор средств построения функциональных и информационных моделей проектируемой ИС, включающий средства для построения диаграмм "сущность-связь" (Entity Relationship Diagrammer), диаграмм функциональных иерархий (Function Hierarchy Diagrammer), диаграмм потоков данных (Data Flow Diagrammer) и средство анализа и модификации связей объектов репозитория различных типов (Matrix Diagrammer);
Systems Designer - набор средств проектирования ИС, включающий средство построения структуры реляционной базы данных (Data Diagrammer), а также средства построения диаграмм, отображающих взаимодействие с данными, иерархию, структуру и логику приложений, реализуемую хранимыми процедурами на языке PL/SQL (Module Data Diagrammer, Module Structure Diagrammer и Module Logic Navigator);


Server Generator - генератор описаний объектов БД ORACLE (таблиц, индексов, ключей, последовательностей и т.д.). Помимо продуктов ORACLE, генерация и реинжиниринг БД может выполняться для СУБД Informix, DB/2, Microsoft SQL Server, Sybase, а также для стандарта ANSI SQL DDL и баз данных, доступ к которым реализуется посредством ODBC;
Forms Generator (генератор приложений для ORACLE Forms). Генерируемые приложения включают в себя различные экранные формы, средства контроля данных, проверки ограничений целостности и автоматические подсказки. Дальнейшая работа с приложением выполняется в среде Developer/2000;
Repository Reports - генератор стандартных отчетов, интегрированный с ORACLE Reports и позволяющий русифицировать отчеты, а также изменять структурное представление информации.

Генерация приложений, помимо продуктов ORACLE, выполняется также для Visual Basic.

Designer/2000 можно интегрировать с другими средствами, используя открытый интерфейс приложений API (Application Programming Interface). Кроме того, можно использовать средство ORACLE CASE Exchange для экспорта/импорта объектов репозитория с целью обмена информацией с другими CASE-средствами.

Среда функционирования Designer/2000 - Windows 3.x, Windows 95, Windows NT.

ERwin - средство концептуального моделирования БД, использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжиниринг существующей БД. ERwin выпускается в нескольких различных конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Версия ERwin/OPEN полностью совместима со средствами разработки приложений PowerBuilder и SQLWindows и позволяет экспортировать описание спроектированной БД непосредственно в репозитории данных средств.

Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi, Visual Basic) выполняется генерация форм и прототипов приложений.



Сетевая версия Erwin ModelMart обеспечивает согласованное проектирование БД и приложений в рабочей группе.

BPwin - средство функционального моделирования, реализующее методологию IDEF0.

S-Designor 4.2 представляет собой CASE-средство для проектирования реляционных баз данных. По своим функциональным возможностям и стоимости он близок к CASE-средству Erwin, отличаясь внешне используемой на диаграммах нотацией. S-Designor реализует стандартную методологию моделирования данных и генерирует описание БД для таких СУБД, как ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server и др. Для существующих систем выполняется реинжиниринг БД.

S-Designor совместим с рядом средств разработки приложений (PowerBuilder, Uniface, TeamWindows и др.) и позволяет экспортировать описание БД в репозитории данных средств. Для PowerBuilder выполняется прямая генерация шаблонов приложений.

CASE.Аналитик 1.1 является практически единственным в настоящее время конкурентоспособным отечественным CASE-средством функционального моделирования и реализует построение диаграмм потоков данных в соответствии с методологией, описанной в подразделе 2.3. Его основные функции:
построение и редактирование DFD;
анализ диаграмм и проектных спецификаций на полноту и непротиворечивость;
получение разнообразных отчетов по проекту;
генерация макетов документов в соответствии с требованиями ГОСТ 19.ХХХ и 34.ХХХ.

Среда функционирования: процессор - 386 и выше, основная память - 4 Мб, дисковая память - 5 Мб, MS Windows 3.x или Windows 95.

С помощью отдельного программного продукта (Catherine) выполняется обмен данными с CASE-средством Erwin. При этом из проекта, выполненного в CASE.Аналитике, экспортируется описание структур данных и накопителей данных, которое по определенным правилам формирует описание сущностей и их атрибутов.

Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации.


Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

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

В составе Rational Rose можно выделить 6 основных структурных компонент: репозиторий, графический интерфейс пользователя, средства просмотра проекта (browser), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для С++, обеспечивающий реинжиниринг - восстановление модели проекта по исходным текстам программ.

Rational Rose интегрируется со средством PVCS для организации групповой работы и управления проектом и со средством SoDA - для документирования проектов. Интеграция Rational Rose и SoDA обеспечивается средствами SoDA.

Rational Rose функционирует на различных платформах: IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX).

Сравнительная характеристика CASE-средств

В заключение приведем сравнительную характеристику CASE-средств по некоторым основным критериям, приведенным выше.


Здесь хотелось бы еще раз отметить нецелесообразность сравнения отдельно взятых CASE-средств, поскольку ни одно из них не решает в целом все проблемы создания и сопровождения ПО. Это подтверждается также полным набором критериев оценки и выбора, которые затрагивают все этапы ЖЦ ПО. Сравниваться могут комплексы методологически и технологически согласованных инструментальных средств, поддерживающие полный ЖЦ ПО и обеспеченные необходимой технической и методической поддержкой со стороны фирм-поставщиков. По мнению автора, на сегодняшний день наиболее развитым из всех поставляемых в России комплексов такого рода является комплекс технологий и инструментальных средств создания ИС, поддерживаемый фирмой "Аргуссофт Компани". В его основе лежит методология и технология DATARUN фирмы CSA. В состав комплекса входят следующие инструментальные средства:
CASE-средство Silverrun;
средство разработки приложений JAM;
мост Silverrun-RDM JAM;
комплекс средств тестирования QA;
менеджер транзакций Tuxedo;
комплекс средств планирования и управления проектом SE Companion;
комплекс средств конфигурационного управления PVCS;
объектно-ориентированное CASE-средство Rational Rose;
средство документирования SoDA.

Примерами других подобных комплексов являются:
Vantage Team Builder for Uniface + Uniface (фирмы "DataX/Florin" и "ЛАНИТ");
комплекс средств, поставляемых и используемых фирмой "ФОРС":

- CASE-средства Designer/2000 (основное), ERwin, Bpwin и Oowin (альтернативные);

- средства разработки приложений Developer/2000, ORACLE Power Objects (основные) и Usoft Developer (альтернативное);

- средство настройки и оптимизации ExplainSQL (Platinum);

- cредства администрирования и сопровождения SQLWatch, DBVision, SQL Spy, TSReorg и др. (Platinum);

- средство документирования ORACLE Book.

комплекс средств на основе продуктов фирмы CENTURA:

- CASE-средства ERwin, Bpwin и Oowin (объектно-ориентированный анализ);

- средства разработки приложений SQLWindows и TeamWindows;



- средство тестирования и оптимизации приложений "клиент-сервер" SQLBench (ARC);

- cредства эксплуатации и сопровождения Quest и Crystal Reports.


Все перечисленные комплексы так или иначе решают проблему поддержки полного ЖЦ ПО. Что же касается остальных важных критериев, то здесь можно отметить следующее:

Обеспечение целостности проекта и контроля за его состоянием

Наилучшими показателями по данному критерию обладают комплексы Vantage Team Builder for Uniface + Uniface и комплекс "ФОРС". Это достигается за счет развитых средств контроля проектных спецификаций и высокой степени интегрированности отдельных средств, входящих в комплексы. В остальных вариантах недостаток возможностей самих средств может компенсироваться организационными мерами.

Независимость от платформы и СУБД

Наибольшей степенью независимости обладает комплекс "Аргуссофт Компани", поскольку его средства в принципе не ориентированы ни на какую конкретную платформу. Достаточно высокой степенью независимости обладает также комплекс Vantage Team Builder for Uniface + Uniface, остальные комплексы достаточно жестко ориентированы на конкретные СУБД (ORACLE и SQLBase).

Открытая архитектура

Наибольшей степенью открытости и количеством интерфейсов с продуктами других фирм также обладают комплексы "Аргуссофт Компани" и Vantage Team Builder for Uniface + Uniface.

Качество технической поддержки

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

Простота освоения и использования

Наилучшие показатели по данному критерию у комплекса "Аргуссофт Компани" и комплекса средств на основе продуктов фирмы CENTURA. Остальные комплексы достаточно сложны в освоении и трудоемки в использовании.

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


крупные многоплатформенные проекты, ориентированные на спиральную модель ЖЦ: комплекс средств, поставляемых фирмой "Аргуссофт Компани";
крупные многоплатформенные проекты, ориентированные на каскадную модель ЖЦ: комплекс Vantage Team Builder for Uniface + Uniface;
крупные проекты, ориентированные на использование СУБД ORACLE: комплекс "ФОРС" - средства фирмы ORACLE;
средние и небольшие проекты: комплекс "Аргуссофт Компани" и комплексы, включающие локальные CASE-средства (ERwin, BPwin, S-Designor, CASE.Аналитик) в сочетании со средствами быстрой разработки приложений (PowerBuilder, Delphi, SQLWindows и др.);
проекты, использующие объектно-ориентированный подход: комплекс "Аргуссофт Компани" (при этом в качестве CASE-средства следует использовать Rational Rose, а в качестве средств разработки приложений одно из тех средств, с которыми взаимодействует Rational Rose.

[]
[]
[]

Современные приложения и их требования к СУБД

Если десять-пятнадцать лет назад наиболее важными приложениями СУБД были экономические и
административные базы данных, которые характеризовались достаточно простой моделью
данных, то сегодня ситуация изменилась.

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

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

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

Создание и управление базой данных

Художник баз данных предоставляет доступ к Художнику администрирования данных
(Data Administration Painter) - интерактивному блокноту для записи и графического представления
операторов SQL, которые затем немедленно выполняются СУБД. Художник администрирования
баз данных позволяет создавать, удалять и модифицировать пользователей системы управления
базами данных, а также указывать привилегии и ограничения доступа в соответствии с
возможностями управления доступом выбранной СУБД.

Художник манипулирования данными(Data Manipulation Painter) позволяет предварительно
просматривать существующие данные, заполнять новые таблицы, а также тестировать форматы
изображений, правила проверки и стили редактирования на реальных данных.

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

Создание интерфейсов для АЦ-терминалов

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

Создание приложений

Из модели базы данных генерируется код для ее создания на сервере. Программируются системные
процессы. При этом возможно разнесение процессов по узлам распределенной системы (часть процессов
реализуется как хранимые процедуры на сервере, часть как сервисы монитора транзакций, часть - как
программы клиентской части). Интерфейс приложений (обычно составляющий до 70-80% всей системы)
может быть быстро создан перенесением соответствующей ему подсхемы базы данных в среду языка 4-го
поколения).

Создание приложений в Informix-ViewPoint Pro

Informix-ViewPoint Pro - это также инструмент для построения простейших приложений без какого
бы то ни было программирования. Приложения, создаваемые в ViewPoint Pro, состоят из окон 3-х
типов:

простые окна (screen) - служат для вызова других окон, выполняют
управляющие функции в приложении;
окна с формами (form) - содержат формы для ввода или просмотра
информации из базы данных;
окна с отчетами (report) - содержат отчеты.
Все типы окон могут содержать графические декоративные элементы, а также параметризуемые
командные кнопки из фиксированного набора: Open(открыть окно), Goto (перейти в
другое окно), Close (закрыть окно), Retrieve (выполнить выборку) и т. п.

Создание приложения в среде PowerBuilder

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



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


Шаг
Процедура
Используемые инструменты

1	Создание объекта приложения	Художник приложений(Application Painter)
2	Проектирование графического интерфейса пользователя	Художники окон, меню и объектов пользователя (Window, Menu and User Object Painters)
3	Определение поведения объектов	Художник PowerScript (PowerScript Painter)
4	Определение режимов работы с данными	Художник Окна данных(DataWindow Painter)
5	Генерация отчетов	Художник отчетов (Report Painter)
6	Добавление подсказок в приложение	Функции PowerScript
7	Управление приложением	Художник библиотек (Library Painter)
8	Отладка приложения	Отладчик (Debugger)
9	Поставка завершенного приложения	Художник приложений (Application Painter, Project Painter)

Список литературы

Кодд Е.Ф. Реляционная модель данных для больших совместно используемых банков
данных. СУБД № 1, 1995.
Chen P.P. The Entity-Relationship Model: Toward a Unified View of Data. ACM Transactions on
Database Systems, vol.1., № 1, 1976.
Горин С.В., Тандоев А.Ю. Применение CASE-средства ERwin 2.1 для информационного
моделирования в системах обработки данных. СУБД, N 3, 1995.
Горин С.В., Тандоев А.Ю. Среда разработки приложений PowerBuilder. DBMS/Russian Edition,
№ 1, 1995.

Александр Науменко

AlconsSoft

tel: +7 (095) 362-5138, 918-1380

e-mail:

[]
[]
[]

Справка (Help)

PowerBuilder снабжен подробной контекстно-зависимой оперативной подсказкой (Online Help),
предоставляющей информацию из справочных руководств по PowerBuilder.

это новое название для пятой

Sybase SQL Anywhere - это новое название для пятой версии Watcom SQL. Это название отражает
как интеграцию продукта в архитектуру Sybase System 11 (рис.4), так и появление мощных средств
обеспечения работы удаленных пользователей и обмена данными. С объединением компаний
Sybase и Powersoft в феврале 1995 года фирма Watcom вошла в состав Sybase, Inc.

Основной диалект SQL, поддерживаемый SQL Anywhere, называется Watcom SQL. Среди новых
качеств продукта - совместимость с Transact-SQL (версия SQL в линии продуктов Sybase).

Диалект Watcom SQL содержит все конструкции, характерные для "больших" СУБД
(декларативная ссылочная целостность, процедуры, триггеры) и соответствует стандарту ANSI
SQL92. Сервер ведет журнал транзакций. Имеется одинаковый по функциональности сетевой
сервер и "локальный" вариант, который может запускаться на одном компьютере с приложением-
клиентом. Для приложения все равно, обращается ли оно к локальному или сетевому
варианту.

SQL Anywhere работает на платформах Windows 3.x, Windows NT и Windows 95 (32-разрядный),
OS/2, DOS, Novell NetWare и QNX. В каждой из этих сред SQL Anywhere максимально
интегрирован. Среди поддерживаемых сетевых протоколов - TCP/IP, Named Pipes, IPX/SPX.

Приложения-клиенты могут разрабатываться с использованием ODBC, Embedded SQL и
собственного интерфейса Watcom HLI (рис.11). Имеется собственный DDE-сервер для интеграции,
например, с Excel, Word или Visual Basic.

SQL Enterprise Manager

Как уже говорилось ранее, SQL Server имеет развитый графический административный интерфейс
- SQL Enterprise Manager, - способный обеспечить потребности администратора в
централизованном управлении многими серверами в организации. Административная консоль
использует объекты SQL-DMO для управления всеми аспектами функционирования SQL Server. В
задачи администратора входит администрирование топологии, защиты, событий/предупреждений,
диспетчирование, создание страховочных копий баз данных, конфигурирование и настройка
серверов и тиражирования. SQL Enterprise Manager может также использоваться для создания,
модификации и копирования схем баз данных и таких объектов, как образы и триггеры. Этот
инструмент позволяет охватить всю топологию системы из любого места в сети.

Архитектура SQL-DMF предлагает множество "точек входа" для поддержания конкретных
потребностей администратора. В результате серверы могут управляться посредством доступа к
объектам SQL-DMO или непосредственно. Мы полагаем, что подобная архитектура создает
гибкую среду администрирования, удовлетворяющую требованиям администраторов как мелких,
так и крупных систем, без необходимости принесения в жертву простоты или
мощности.

SQL Executive

Основой SQL-DMF является SQL Executive, исполняемый как сервис операционной системы и
управляющий тиражированием, обработкой событий, предупреждений и диспетчированием
работы компонентов внутри SQL-DMF. SQL Executive работает как "скрытый" оператор или
"интеллектуальный агент", автоматически и постоянно отслеживающий состояние окружения
сервера и любых распределенных служб SQL Server. Разработчики сервера убеждены, что
критические службы, такие как тиражирование, должны быть частью основного продукта, а не
просто "утилитами".


SQL Enterprize ManagerOLE AutomationSQL Server Distributed Manadgement Object (SQL-DMO)SQL ExecutiveSQL Server

Тиражирование Менеджер задач Менеджер событий Менеджер уведомлений

SQL Server 11 - современная реляционная СУБД

Создание Sybase SQL Server 11 основывается на многолетнем опыте работы предыдущих версий во
всем мире и содержит целый ряд новых возможностей.


Масштабируемость, высокая производительность и эффективность SQL Server 11
основывается на проверенной технологии:
SQL Server 11 работает на множестве платформ, от персональных компьютеров до
многопроцессорных суперсерверов;
обеспечена очень высокая производительность на каждой платформе благодаря тесному
взаимодействию с производителями аппаратуры и оптимизации характеристик;
полностью симметричная многопоточная СУБД достигает высокой пропускной
способности и поддерживает большое количество пользователей.
SQL Server обеспечивает надежность и целостность данных:
SQL Server содержит механизмы триггеров и процедур, декларативной ссылочной
целостности, транзакций и т.д.;
СУБД соответствует уровню безопасности C2 NCSA (National Computer Security
Council).
Доступность данных повышает производительность систем:
Sybase SQL Server программно поддерживает зеркальный журнал и зеркальную базу
данных;
высокоскоростные средства загрузки/восстановления минимизируют влияние этих
операций на работу системы.
Открытость и соответствие стандартам:
SQL Server соответствует стандартам ANSI/ISO SQL-89 и entry-level ANSI/ISO SQL-92;
поддерживаются приложения в стандарте ODBC и X/Open XA;
SQL Server может использовать различные сетевые протоколы, что позволяет соединить
клиента и сервер практически на каждой платформе.
Легкость управления и поддержки:
наличие продуманной многопоточной архитектуры означает, что на компьютере
запускается и требует управления только один процесс - СУБД;
для симметричной мультипроцессорной обработки можно конфигурировать количество
процессоров, распределенных для СУБД;
имеется полный набор продуктов для конфигурирования областей памяти,
пользователей, контроля доступа и производительности - от одной базы данных до множества
сетей в масштабах предприятия.\

Остановимся на важных особенностях SQL Server 11.

SQL Server Distributed Management Objects (DMO)

Другим исключительно важным компонентом являются SQL Server Distributed Management Objects
(SQL-DMO). SQL-DMO - OLE Automation интерфейс SQL Server 6.0 открывает объекты, свойства
и методы для всех аспектов деятельности SQL Server по управлению и администрированию SQL
Server. Объектная модель SQL Server включает более 70 индивидуальных объектов и свыше 1500
свойств и методов. Организация объектов значительно упрощает изучение и продуктивное
использование компонентов административного интерфейса SQL Server.

OLE интерфейс поддерживает использование таких средств разработчика, как Visual C++, Visual
Basic и Visual FoxPro для создания специализированных административных сценариев, исполнение
которых организуется средствами диспетчирования SQL Executive. Справа приведены некоторые
из объектов и методов SQL-DMO.

Все функции SQL Server открыты для доступа извне как объекты, свойства и методы. Подобная
модель значительно упрощает работу с административным "слоем" за счет организации функций
управления в терминах объектной модели SQL Server. Основной объект - "SQL Server" - включает
коллекцию объектов "Databases". Объект "Database" включает коллекции объектов "Table",
"View" и "StoredProcedure". Объекты имеют свойства (например, SQLServer.Name =
"SABERTOOTH") и методы (SQLServer.Start или SQLServer.Stop). Свойства и методы
используются для управления SQL Server.

Метод объекта	Действие
SQLServer.Stop	Останавливает SQL Server
SQLServer.Start	Запускает SQL Server
Database.Backup	Выполняет создание страховочной копии
Index.UpdateStatistics	Обновляет информацию оптимизатора по индексам
Database.Table.Add	Добавляет таблицу к базе данных

Среда разработки приложений на PROGRESS

PROGRESS Application Development Environment (далее ADE) - это функционально полный,
интегрированный набор инструментальных средств, позволяющих создавать и применять
высокопроизводительные приложения для широкого диапазона программно-аппаратных
платформ. С помощью ADE Вы можете создавать все необходимые компоненты приложений - от
графических и алфавитно-цифровых интерфейсов до сложных логических и пакетных процессов,
от отчетов до средств интеграции с внешними программными оболочками. Программирование на
PROGRESS предполагает использование современных подходов к разработке приложений, таких
как: структурированный, объектно-событийный и объектно-ориентированные подходы.

Среда разработки приложений PROGRESS ADE состоит из следующих компонентов:


Построителя Интерфейса Пользователя (User Interface Builder)
Словаря Данных (Data Dictionary)
Редактора Процедур (Procedure Editor)
Генератора Отчетов (Report Builder)
Языка программирования четвертого поколения 4GL (Fourth-Generation
Language)
Отладчика Приложений (Application Debugger)
On-Line Справочника(On-Line Help)
Менеджера Переводов (Translation Manager)
Утилиты Results (PROGRESS Results)
Средств Оптимизации Качества (Performance Profilers)
Администратора Базы Данных (Database Administration)
Утилиты ToolKit

Средства генерации отчетов

S-Designor, как и большинство аналогичных средств такого класса позволяет готовить
отчеты по структуре данных модели. Цель подготовки отчетов - документирование разработанной
модели данных. Можно создать любое количество стилей отчетов и после этого генерировать отчеты
согласно выбранному стилю. Пример использования различных стилей - краткий и полный отчеты по
модели. Подготовленный отчет можно напечатать или сохранить в формате, например, текстового
процессора Microsoft Word. Впоследствии, отчет можно отредактировать средствами
Microsoft Word. В отчет может быть включено графическое изображение модели данных,
расположенной как на отдельных страницах, так и смасштабированной так, чтобы вся модель
размещалась на одной странице. Отчет можно произвольным образом настраивать. Например,
включать или исключать различные элементы отчетов, автоматическое формирование оглавления,
переопределять содержимое заголовка и подвала страницы.

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

Средства групповой разработки модели данных

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

Принцип организации коллективной разработки в S-Designor - использование
централизованного словаря метабазы, который хранит модели данных, и обеспечение доступа к нему.
Для организации работы со словарем и управления коллективной разработкой предназначена
отдельная компонента - S-Designor Dictionary. Компонента служит для создания и
администрирования централизованного словаря.

Словарь метабазы - это ряд таблиц, которые создаются на SQL-сервере из среды S-Designor
Dictionary. Технология работы с централизованным словарем метабазы построена на двух
ключевых понятиях: Consolidation (консолидация/слияние модели с моделью в словаре) и Extraction
(операция извлечения модели данных из словаря).

Перед тем, как внести изменения в модель данных необходимо выполнить операцию Extraction. По
этой операции модель данных либо извлекается из словаря и загружается в S-Designor, либо
сохраняется в файл. По операции Consolidation выполняется консолидация метаданных измененной
модели с метаданными в словаре. Так вносятся изменения в модель в словаре.

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

с центральным словарем. После этого

файле.

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

Права доступа делятся на следующие группы:

ADMI -	пользователи данной группы могут выполнять любые действия со словарем и с хранимыми в нем моделями.
Upgrade -	пользователи данной группы могут оперировать со своими моделями и подмоделями с атрибутом Public.
Read-only -	пользователи данной группы могут только читать информацию из словаря.
Lock -	пользователи данной группы в данный момент не имеют никаких полномочий.

Структура проекта следующая: проект (project) - модель (model: концептуальная
и/или физическая) - подмодель (sub-model). Для создания проекта в словаре администратор выполняет
консолидацию модели в режиме Create (Рис.6).

Средства Оптимизации Качества (Performance Profilers)

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

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

Средство Оптимизации Качества Базы Данных

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

Средства проектирования представлений (View)

При разработке информационных систем со сложной структурой данных эффективно использовать
представления (View). Цель создания представлений - структурировать и в итоге упростить
построение сложных запросов к базе данных.

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

Средства разработки Oracle как

Л. Сорокин, Oracle











Средства разработки Oracle

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

В зависимости от масштаба и назначения разработки, инструменты Oracle могут комплектоваться в наборы, наиболее оптимально соответствующие поставленным задачам. Из основных инструментов Oracle необходимо выделить следующие:

Designer/2000 - Средство описания разрабатываемой системы в виде всеохватывающей модели и генерации на ее основе законченных приложений для различных средств разработки.

Developer/2000 - Многоплатформленное и масштабируемое средство визуального создания промышленных приложений, легко настраиваемых в зависимости от мощности сервера и клиентских компьютеров и переносимых на работу в среду Internet/Intranet.

Power Objects - Инструмент для разработки приложений небольшого масштаба, способного работать с разнообразными источниками данных.
Programmer/2000 - Набор предкомпиляторов
для C/C+, заметно упрощающих создание приложений на C/C+ для сервера Oracle7.

Mobile Agents - Позволяет разрабатывать приложения для мобильных пользователей или для удаленных систем, работающих через плохие, неустойчивые каналы связи.

Необходимо отметить, что в отличие от "универсальных" средств разработок, ориентированных на работу с любыми СУБД (Delphi, Visual Basic, PowerBuilder), "родные" инструменты полностью используют все возможности сервера Oracle7. А именно, поддержка последовательностей и синонимов, работа с механизмом обеспечения секретности на сервере, доступ к хранимым на сервере процедурам и переменным, управление оптимизатором выполнения SQL-команд - использование этих возможностей либо невозможно в универсальных средствах разработок, либо требует большого труда при кодировании.

Инструменты сквозного проектирования и разработки приложений

На этапе предварительного обследования деятельности предприятия (той деятельности, которую необходимо автоматизировать) используется компонента Designer/2000 - средство построения диаграмм деловых процессов BPR (Business Process Modeler).
С его помощь возможно не только построить модель всех процессов, протекающих в ходе повседневной деятельности организации (предприятия), но и произвести ряд анализов, способных выявить узкие места. Даже без последующего создания приложения, такая модель позволяет лучше понять как протекает деятельность организации и найти пути по ее улучшению.

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

Процесс создания модели предполагает коллективную работу над проектом. Существуют мощные средства организации такой работы, разделения модели на части для независимой разработки и "сшивания" частей модели в целое.

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

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

Генерация для клиентской части возможно для целого ряда различных средств разработок. Сейчас поддерживаются :
Oracle Developer/2000


Oracle Power Objects
Oracle WebServer
MS Visual Basic 3.0 и 4.0
Классы C/C+

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

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

Важной особенностью является возможность восстановить модель приложения по уже существующему приложению, созданного без применения Designer/2000, с помощью процедуры реинжиниринга. Так же и вручную сделанные изменения в сгенерированной системе можно отразить в модели приложения и при последующей генерации они не будут потеряны.

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

Обеспечение независимости от смены платформ и технологий

Другой иллюстрацией подхода корпорации Oracle к обеспечению создания независимых от платформы приложений является Developer/2000. Это инструментарий визуального проектирования клиентских приложений для технологии Клиент-сервер. Developer/2000 полностью переносим на все используемые ныне платформы, начиная от символьных терминалов и кончая графическими средами вроде Windows или Motif.


Если при разработке не использовались платформенно зависимые особенности (например компоненты OCX/ActivX для Windows), то перенос приложения на другую платформу не требует никакого кодирования!
Рост популярности приложений для Internet/Intranet вызвал необходимость для разработчиков изучения как новых технологий, так и новых сред разработки для Web. Перенос приложения в среду Internet/Intranet означал практически полностью его переписывание на новом средстве разработки. Поэтому многие фирмы-производители инструментальных средств поддержали технологию Netscape Plug-In, которая позволяла определенным способом распространять и вызывать приложения через Web, не сильно их переделывая. Но на самом деле, это только временное решение, т.к. для выполнения приложения необходимо держать на клиентском компьютере полностью Run-Time среду, а само приложение целиком закачивается с Web-сервера.

Применение Developer/2000 позволяет перенести прикладную систему в среду Internet/Intranet более элегантным способом. Существует возможность разместить Run-Time среду Developer/2000 на Web-сервере, а откомпилированное приложение передается ей безо всякой модификации. Специальный кэтридж Web Developer'а формирует на лету Java Applets, которые передаются на клиентский компьютер в любую программу просмотра Web. Пользователь видит перед собой тот же пользовательский интерфейс, как если бы приложение выполнялось на его компьютере, а работать может даже на DOS-компьютере с 640 КБ памяти!

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

Поддержка разработчиков

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


В их числе:

Соответствующая международным стандартам техническая поддержка продуктов Oracle, функционирующая на территории СНГ.
Возможность ознакомления с пробными (trial) версиями продуктов Oracle, прежде чем принять решения об их закупке и затем возможность предварительного ознакомления с новыми версиями продуктов.
Два периодических русскоязычных журнала ("Мир Oracle" и "Oracle Magazine - Русское издание"), посвященных продуктам Oracle, содержащих большое число статей для разработчиков.
Действующие группы пользователей Oracle, периодические семинары.
Большой выбор учебных курсов по продуктам Oracle, как и в представительстве корпорации Oracle в СНГ, так и у его партнеров.

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

Заключение

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

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

[]
[]
[]

Стратегическая система моделей организации.

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

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


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

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

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


уровень описания / группы характеристик - моделей
функции
данные
люди
сеть
время
правила (мотивация)
Укрупненная система моделей организации

Детальная система моделей организации

Система моделей требований к ИУС

Детализация проекта

Функционирующая система

список бизнес-процессов и бизнес-функций организации	списки документов списки объектов	структурная модель организации alt="pict">	перечень структурных подразделений и внешних организаций	список работ во времени alt="pict">	список целей и задач организации критерии и правила выполнения бизнес-процессов alt="pict">
функциональные модели подразделений: диаграммы потоков данных	информационная модель организации (концептуальная модель)	структурные модели подразделений, роли персонала	логическая модель сетей подразделений организации и внешних связей	временная модель выполнения бизнес-процессов и бизнес-функций	критерии выполнения бизнес-функций; бизнес-правила
требования к функциям; диаграмма потоков данных	требования к данным; структуры данных концептуальная модель данных	требования к регламенту и интерфейсу пользователей	требования к сетевой архитектуре системы	требования к временным характеристикам функции	требования к регламенту работы ИС
функции	данные	пользователи	коммуникации	зависимость	правила

Рис. 3. Схема преобразования
моделей

Стратегия IBM

В такой ситуации подход IBM к созданию ООИС заключается в применении технологий, в
наибольшей степени соответствующих специфике решаемой задачи. Так, в системе организации
коллективной разработки программного обеспечения Team Connection используется объектно-
ориентированная СУБД Object Store, специально лицензированная у компании Object Design.
Выбор объектно-ориентированной СУБД определяется при этом необходимостью управлять
сравнительно небольшим объемом данных при их сложной структуре и разнообразии методов
обработки. Иной подход предлагается IBM для построения корпоративных информационных
систем, где приоритетными являются соображения надежности и производительности, а также
совместимости с прежними версиями и промышленными стандартами. Полагая, что при
современном уровне развития информационных технологий такие характеристики может
обеспечить только реляционная СУБД, IBM предлагает для таких систем новую версию DB2,
которая сохраняет всю функциональность реляционной СУБД, но расширяет ее новыми
средствами, выходящими за рамки реляционной алгебры и призванными снять некоторые
ограничения реляционной модели . В значительной мере на такой подход
влияет и необходимость защиты инвестиций, сделанных пользователями в реляционные
технологии, и в известной степени он является компромиссным, однако позволяет снять многие
острые проблемы, стоящие перед современными СУБД.

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

Игорь Ларин, IBM
Требования, предъявляемые современными условиями к инструментальным средствам разработки
приложений.

Моделирование и проектирование бизнес-процессов и структур данных.

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

Средства управления командной разработкой программного обеспечения.

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

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

Для определения и спецификации бизнес-процессов будущего приложения предназначен инструмент IBM
Business Requirements Tool. Этот продукт предназначен для системных аналитиков, проектировщиков

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

Следующий этап разработки - моделирование данных. Инструменты IBM моделирования данных
предоставляет возможность определения и отображения деловой информации в виде концептуальных
моделей, независимых от конкретной реализации базы данных. Концептуальные модели определяются на
основе метода Чена моделирования связей сущностей. Эта модель делает возможным проектирование
конечным пользователем структуры данных будущего приложения. Как только проектирование
завершено, в дело вступает программа-генератор модели данных. Она увязывает концептуальные модели
с логическими структурами, специфическими для конкретной базы данных. Программа генератор модели
данных - имеет графический редактор, позволяющий описывать сущности, связи и атрибуты, и
включающий средства преобразования концептуальных моделей в логические(реляционные) и наоборот,
логические в концептуальные. Далее, продукт DataAtlas берет на себя контроль и стандартизацию
спецификаций реляционных баз данных.


После определения логической и физической структуры данных, а также дизайна будущего приложения
разработчики могут приступать непосредственно к программированию. И здесь IBM предлагает самый
широкий выбор возможных инструментов. Для разработки можно выбрать либо один из языков третьего
поколения, т.е. обычных процедурных языков, либо применить объектно-ориентированный подход с
использованием языков С++, Smalltalk, O-o Cobol, либо программировать на языке четвертого поколения


от IBM 4Gl. При этом, IBM старается избавить разработчика от рутинной работы и позволить ему
сосредоточиться на разработке смысловой части приложения. Для достижения этой цели используется
технология визуального программирования - создание приложений из уже готовых частей. Программа
собирается из произвольного числа модулей, каждый из которых может быть либо создан при разработке,
либо получен от независимого поставщика, либо взят из поставляемых со средствами разработки
библиотек. Разработчик, имея единую концепцию визуального программирования IBM VisualAge, в
праве выбрать любой из предлагаемых языков программирования или же использовать несколько языков
в рамках технологии IBM стандартизации объектов System Object Model. Кроме того, разработчик
свободен также в выборе компьютерной платформы для исполнения, разработанного им приложения. Ему
предоставляется широкий выбор из платформ IBM (OS/2, OS/400, AIX, MVS...) а также платформ третьих
поставщиков.

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

[]
[]
[]

"Строительные блоки" приложений - компоненты

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

Delphi строится на базе компилятора объектно-ориентированного языка Object Pascal,
продолжающего линию диалектов Pascal - Turbo Pascal и Borland Pascal. По мере своего развития,
каждая очередная реализация Pascal компании Borland включала все новые расширения
синтаксиса, отражающие последние достижения в области языков программирования. Если
подходить к оценке качественных "ступеней" развития Pascal, особо следует отметить три из них,
направленные на поддержку концепции повторного использования кода:


модульная архитектура, с возможностью разделения интерфейсной и
описательной частей (Turbo Pascal 4.0);
средства объектной ориентации, со всеми, присущими ей
характеристиками - наследованием, инкапсуляцией и полиморфизмом (Turbo
Pascal 5.5);
поддержка механизмов RTTI (Run-Time Type Information), позволяющих
получать информацию о базовых характеристиках объектных типов (классов) и
их экземпляров (объектов) с помощью языковых средств, непосредственно
встроенных в системную библиотеку и структуру организации описаний классов
(Delphi 1.0 - Object Pascal);

Следствием введения поддержки RTTI стала возможность создания визуального инструмента
разработки приложений, каковым и является Delphi. На определенном уровне иерархии
наследования базовой библиотеки классов Delphi появляется класс TPersistent,
обеспечивающий необходимый уровень абстракции потокового ввода/вывода объектов (экземпляров
классов). Его наследником выступает класс TComponent, определяющий основы поведения
компонент Delphi VCL (Visual Component Library) в режиме design-time (этап
"конструирования" приложения). На оконечных точках ветвей иерархии VCL находятся как таковые
компоненты - готовые к визуальному использованию классы, непосредственно регистрируемые в
рабочей библиотеке компонент и доступные из Палитры Компонент (Components Palette) IDE
Delphi.

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

С другой стороны, механизмы регистрации и дальнейшего наследования уже существующих
стандартов динамического связывания (Windows DLL) и компонентной архитектуры (VBX в
Delphi 1.0 и OCX - в 32- разрядной версии Delphi) позволяют использовать в Delphi доступные
внешние инструменты (например, компиляторы C++) и, созданные с их помощью, программные
блоки.

Самодостаточность Delphi для расширения набора доступных компонент является первым
признаком открытости архитектуры этого инструмента.

Структура и оформление окна

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

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

В окне могут использоваться также визуальные объекты созданных ранее классов.

Атрибуты окна и его органов (цвет, шрифт, надпись и др.) задаются в окне редактирования
атрибутов.

Имеется также генератор многоуровневых меню, в котором определяется меню для текущего
окна.

Структура JAM

Пакет JAM имеет модульную структуру и состоит из следующих компонент:

Ядро системы. Ядро является законченным модулем и
позволяет полностью разрабатывать приложения;
JAM /DBi - модуль интерфейса к СУБД. Для каждой СУБД,
поддерживаемой JAM`ом, существует специализированный модуль. Например,
JAM/DBi-Oracle, JAM/DBi-Informix, JAM/DBi-ODBC и т.д. Модули JAM/DBi
являются дополнительными для ядра и самостоятельно использоваться не
могут;
JAM/RW - модуль генератора отчетов. Модуль JAM/RW является
дополнительным для ядра и самостоятельно использоваться не может;
JAM/CASEi - модуль интерфейса к CASE верхнего уровня (например,
CASE структурного анализа и дизайна). Для каждой CASE, поддерживаемой
JAM`ом, существует специализированный модуль. Например, JAM/CASEi-
TeamWork, JAM/CASEi-Innovator и т.д. Модули JAM/CASEi являются
дополнительными для ядра и самостоятельно использоваться не могут;
JAM/TPi - модули интерфейса к Мониторам Транзакций. Существует
два варианта этих модулей - TPi-Server и TPi-Client. Для каждого МТ,
поддерживаемого JAM`ом, существуют специализированные модули.
Например, JAM/TPi-Server TUXEDO и т.д. Модули JAM/TPi являются
дополнительными для ядра и самостоятельно использоваться не могут.

Суперпредставления

Суперпредставление, так же, как и представление (view), является описанием информационного
среза БД, но несет некоторую дополнительную структурную нагрузку, имеет наглядное внешнее
представление. При помощи ViewPoint Pro администратор строит серию суперпредставлений,
отражающих существенные информационные связи. На их основе прикладные специалисты, не
обладающие навыками программирования, могут при помощи средств разработки ViewPoint Pro
быстро создавать приложения, отвечающие их потребностям.

Генератор суперпредставлений ViewPoint Pro позволяет описывать их структуру не в терминах
операторов SQL SELECT, а в терминах связей между таблицами. Связь задается операцией
соединения столбцов двух таблиц с явным указанием типа: "один к одному", "один к 0 или к
одному", "один ко многим", "один к нулю или многим".

---

---