Отчеты

Печатные и, возможно, экранные отчеты.

Пакетные процессы

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

Нерегламентированные запросы

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

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

Средство, собирающее различные компоненты в одно цельное приложение.

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

У одного из авторов еще живо в памяти воспоминание о том, как он пытался уговорить клиента-консультанта написать всего один модуль (из почти 750) на Рго*С, а не на PL/SQL. Руководитель проекта настаивал на том, что поскольку PL/SQL является корпоративным стандартом, то следует использовать этот язык. В соответствующем разделе отчета консультанта было написано:

Я согласен с вашими разработчиками, что на PL/SQL технически невозможно написать модуль, который удовлетворял бы поставленным требованиям к производительности. Кроме того, затраты на разработку варианта на PL/SQL примерно в десять раз больше, чем варианта на С.

Новый руководитель проекта больше года старался решить проблемы производительности средствами PL/SQL, пробуя вариант за вариантом, после чего наконец санкционировал написание этого модуля на Рго*С. Для создания и тестирования понадобилась неделя работы одного программиста, и проблемы производительности были решены.

У нас есть пословица:

Если инструментальное средство не делает то, что вы хотргге, поменяйте то, что вы хотите.

Если инструментальное средство не делает то, что вам нужно, поменяйте инструментальное средство.

Какие критерии отбора важны?

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

переносимость кода между аппаратными и программными платформами;

возможность поддержки средств клиент/сервер, описанных в главе 11;

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

поддержка генерации кода из CASE-средства;

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

степень современности продукта и вероятность того, что он будет поддерживаться многие годы;

сложность инструментального средства и возможная скорость написания и отладки программ;

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

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

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

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

Инструментальные средства для систем клиент/сервер

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

прямое SQL-соединение через SQL*Net; SQL-соединение через ODBC-драйвер;

направление удаленных вызовов процедур на серверы приложений, выдающие все запросы к базе данных.

На практике в настоящий момент времени щироко распространены только первые два способа. Третий начинает выглядеть как вариант для Web-приложений и для развертывания архитектуры сетевых вычислений Oracle (NCA). Без сомнения, в Oracle есть люди, считающие, что это одно и то же и что каждый Oracle-узел, развертывающий Web-приложения, автоматически принимает NCA.

Некоторые продукты, например Powerbuilder фирмы Powersoft, позволяют выбрать любой из двух вариантов SQL-соединений, поэтому важно знать о различиях между ними. Во-первых, для использования ODBC необходим ODBC-драйвер, хотя необходимые драйверы довольно часто продаются в комплекте с инструментальными средствами. При использовании SQL*Net можно свободно писать SQL-код, включающий Oracle-расщирения стандарта ANSL Если же применяется ODBC-драйвер, он может попытаться разобрать этот SQL-код и отклонить SQL, не соответствующий стандарту ANSI.

Это ограничение приводит к появлению проблем, когда мы пытаемся проектировать экранную форму, позволяющую администратору приложения сопровождать пользователей, поскольку такие команды, как ALTER USER и DROP USER в стандарте ANSI отсутствуют. Это ограничение касается почти всех DCL- и DDL-операций в Oracle?. Документ The Oracle! Server SQL Reference Manual содержит перечень Oracle-расщирений стандартного SQL, a руководство для версии 7.2 - список более чем 60 команд SQL, поддерживаемых Oracle?, но не входящих в стандартный SQL. Для тех, кто не знаком с ограниченной областью применения стандарта (стандартов) на SQL, сообщаем, что этот список включает команду CREATE SYNONYM.

В больщинстве ODBC-драйверов это ограничение ANSI можно обойти, установив опцию, называемую режимом ретрансляции (pass through mode). Этот режим заставляет драйвер передавать SQL прямо на сервер, не интерпретируя его. Это позволяет использовать SQL, не соответствующий стандарту ANSI, но лищает нас одного из главных преимуществ ODBC, которое Заключается в следующем. Если режим ретрансляции не применяется, то приложение можно сделать независимым от базы данных. Это значит, что теоретически оно должно работать с Oracle?, Sybase, SQL Server, Informix и т.д. Если это важно - например, в случае, когда создается продукт, который планируется продавать на более щироком рынке, чем рынок серверов