Как видно из примера, приведенного в материале "Компания Progress предложила свою методологию разработки приложений" (см. стр. 14-17), инструменты RAD действительно многократно ускоряют разработку компонентов приложений, при этом процесс создания становится простым и легким. Естественно, это привело к тому, что средства быстрой разработки начали выпускать все, кто только мог. Фирмы-производители промышленных СУБД, которые в большинстве случаев запоздали с разработкой подходящих инструментов RAD, начали наверстывать упущенное, чтобы обеспечить легкость доступа и использования предлагаемых ими баз данных. В борьбу за этот сектор рынка включились компании, специализирующиеся на поставке прикладных и общесистемных средств. Кроме того, появились фирмы, предлагающие не только средства быстрой разработки, но и продукты углубленного анализа и интеграции данных из разных источников.

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

По признанию организаторов одного из таких испытаний продуктов RAD, была предпринята попытка протестировать более 60 инструментов, но даже такой обширный список не исчерпывал всех предложений рынка. В конечном счете при анализе результатов испытаний основное внимание было сосредоточено на 11-13 продуктах наиболее крупных производителей, из которых, без сомнения, выделялись Microsoft Visual Basic Professional Edition, PowerBuilder (компании Powersoft Corp.), SQLWindows (Gupta Corp.), Object Studio (Easel Corp.), Unify Vision (Unify Corp.), Delphi (Borland International) и Visual AppBuilder (Novell Inc.).

Бум продуктов RAD не обошел стороной и отечественный рынок ПО, где соперничество производителей, "как всегда", принимает подчас странные формы. Известно, что PowerBuilder и SQLWindows, демонстрирующие отменные функциональные качества при разработке клиентской части приложений, являются активно конкурирующими на мировом рынке. Но борьба за большую долю рынка – это прежде всего привлечение на свою сторону потребителя, а не охаивание продукции соперника. Поэтому странным выглядит появившееся в печати ("GUPTA в России", N 3,1995, "Сравнительный анализ SQLWindows 50 и PowerBuilder 4.0") мнение специалиста, который в первой же строке заявляет, что "каждый из этих продуктов позволяет быстро начать разработку системы, но только SQLWindows 5.0 дает возможность завершить ее"(!?). Свое утверждение автор основывает на мнении разработчиков "одной из российских фирм", но он забывает при этом, что, во-первых, средства RAD как продукты высоких технологий невозможно сравнивать "в лоб", так как они характеризуются большим числом показателей, изменяющихся в разных условиях реализации приложений. Во-вторых, корректность подобного заключения должна базироваться на многократной проверке использования сопоставляемых инструментов при обязательной оценке результатов достаточно большим числом экспертов и пользователей. О корректном сопоставлении можно говорить только на основе тестирования этих продуктов в равнозначных условиях разработки приложения, когда задаются определенный сценарий (условия извлечения данных и представления результатов), типы и масштабы используемых БД, вычислительные и сетевые платформы, определяется срок разработки И лишь затем производится сравнение полученных результатов по множеству объективных показателей.

Что нужно выяснять при тестировании RAD

При проведении независимого тестирования или при анализе потребителем средств RAD необходимо ответить на множество вопросов Например, обеспечивает ли созданное приложение подключение к БД на удаленных серверах и какие для этого существуют возможности – при использовании естественных методов доступа базы или через стандартный интерфейс Microsoft ODBC (Open Database Connectivity)? Способно ли приложение поддерживать связи динамического обмена данными DDE и применять местные форматы баз данных PC? Можно ли заменить источники данных, используя технику pomt-and-click? Легко лис помощью средств RAD формируются отчеты и диаграммы, предназначенные для поддержки принятия решений и создания многоаспектных отчетов? Существуют ли средства для простого формирования сложных запросов? Имеют ли изделия финансовые или другие функции анализа высокого уровня, которые легко встраиваются в приложения?

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

Многие эксперты и разработчики отмечают, что инструменты RAD разных производителей ведут себя совершенно по-разному, в отличие от языков 3GL, демонстрировавших завидную однородность. Некоторые RAD позволяют непосредственно создавать визуальные объекты на экране, в то время как другие требуют от разработчика первоначального определения источников данных и только затем генерируют объекты. Отдельные инструменты напрямую привязывают приложение к интерфейсу объектов, а другие сохраняют программируемую предопределенную функциональность объектов в отдельных и изолированных компонентах системы.

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

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

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

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

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

Оценка степени доступности данных из внешних источников должна включать: возможности поддержки конечных серверов данных и наличие интерфейсов к СУБД – как прямых, так и использующих ODBC-драйверы (что является положительным качеством RAD). Должны рассматриваться возможности поддержки стандартов DDE и OLE, местных форматов базы данных PC и возможности использования источников данных. Насколько полно средства RAD обеспечивают доступ во внешний мир, когда требуется использование информации из гетерогенных источников данных, включая БД, созданные на основе систем управления других производителей, и файловые системы больших mainframe? Обеспечивают ли инструменты RAD способности наследования применяемых приложений?

Оценка профессионализма разработки должна определить мощность языка программирования, используемого для конкретной разработки приложений требует ли он расширения с помощью языков 3GL или библиотек DLL? Способны ли средства RAD осуществлять компиляцию для создания выполняемых программ, и насколько развиты средства отладки? Потребуется ли большой объем кодирования для формирования функциональных приложений, и насколько прост в работе язык продукта? Те средства RAD, которые поддерживают многократное использование кодов, должны оцениваться значительно выше остальных. Способность эксплуатировать предварительно подготовленные компоненты заслуживает дополнительных оценок. Этот же обобщенный показатель должен включать оценку поддержки групповой разработки многими программистами, возможности контроля и распространения версий. Очень важным является показатель полноты справок помощи и документации рассматриваемого продукта.

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

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

В связи с этим, как нам кажется, читателям будет интересно познакомиться с тем, как ведущие фирмы-производители промышленных СУБД развивают собственные средства RAD. Из четверки основных производителей индустриальных СУБД мы остановились на Informix. Тем более, что в упоминавшемся выше опросе журнала VARBusmess эта фирма заняла третье место после Progress и Microsoft как по уровню технической поддержки производимых продуктов, так и по наметившемуся прогрессу в развитии средств разработки для архитектуры "клиент-сервер". С этой целью мы обратились к Надежде Вьюковой, сотруднику российской фирмы Jet (контактные телефоны: (095) 972.11.82, 972.13.32), являющейся экспертом по СУБД Informix. Интервью с ней приведено ниже.

Другая известная фирма-производитель индустриальных СУБД Sybase просто перекупила компанию Powersoft Corp. вместе с продуктом PowerBuilder, чтобы в перспективе, развивая его, предложить потребителям средства быстрой разработки в масштабах предприятия. О том, что имеет в своем арсенале средств PowerBuilder, рассказывает статья "PowerBuilder – взгляд изнутри", написанная Сергеем Гориным и Андреем Тандоевым, сотрудниками российской фирмы "АлконсСофт".

Фирма Gupta Corp., напротив, нацеливает совершенствование своего инструментария RAD SQLWindows на более простой и естественный доступ и полное использование информации из разнообразных источников данных, включая СУБД других производителей. Казалось бы, вопросы взаимодействия вообще не должны возникать: почти все фирмы-производители индустриальных СУБД буквально кричат об открытости своих продуктов. Но, оказывается, таких проблем очень много, и о том, как они решаются при интеграции SQLWindows с СУБД Oracle, говорится в статье Александра Брюзгина, технического директора российской фирмы Interface (контактный телефон: (095) 135.55.00).