- Традиционные системы программирования
- Инструменты для создания файл-серверных приложений
- Средства разработки приложений клиент-сервер
- Средства автоматизации делопроизводства и документооборота
- Средства разработки Internet/Intranet-приложений
- Средства автоматизации проектирования приложений
- Объектная ориентация
Визуальный характер программирования
Событийное программирование
Распределенные приложения
Влияние Web-технологии
Сближение с CASE-технологиями
Типы информационных приложений
Разработка информационных приложений становится широко распространенной задачей, решаемой различными государственными органами управления и коммерческими организациями. Поэтому важно разобраться, что собой представляют информационные приложения, выделить наиболее характерные области их применения и соотнести их с типами информационных систем.
Информационное приложение - прикладная программная подсистема, ориентированная на сбор, хранение, поиск и обработку текстовой и/или фактографической информации. Подавляющее большинство информационных приложений работает в режиме диалога с пользователем. В общем случае типовые программные компоненты информационного приложения включают: диалоговый ввод-вывод, логику диалога, прикладную логику обработки данных, логику управления данными, операции манипулирования файлами и/или базами данных. Для сетевых информационных приложений важным элементом является коммуникационный сервис, обеспечивающий взаимодействие узлов сети при совместном решении информационной задачи.
Значительная часть возможностей приложения закладывается в системном программном обеспечении, в библиотеках и конструкциях инструментальных средств разработки. Однако остается часть приложения, специфичная для конкретной предметной области. Основными объектами разработки являются компоненты приложения, определяющие логику диалога, а также логику обработки и управления данными. Часто преобладающее значение имеет диалог, пронизывающий все приложение, поэтому многие инструменты ориентированы именно на упрощение и ускорение создания диалога в приложении. Несмотря на манипуляционный характер процесса разработки, промежуточное представление приложения оформляется в виде языкового описания, что позволяет быстро разработанный макет в дальнейшем начинять содержательной обработкой данных, но уже с помощью языка программирования.
Кроме программной составляющей приложения существенную роль играет информационная составляющая, которая задает структуру, атрибутику и типизацию данных, а также ограничения целостности для баз данных. Информационная составляющая тесно связана с логикой управления данными. Вот почему средства автоматизации проектирования приложений отдают приоритет информационной модели, из которой выводится все остальное, включая диалог.
Информационные системы прежде всего различаются по масштабу на одиночные, групповые и корпоративные. Одиночные информационные системы реализуются на автономном компьютере, как правило, ПК. Такая система может содержать несколько простых приложений, связанных общим информационным фондом, и рассчитана на работу одного пользователя или группы пользователей, разделяющих по времени одно рабочее место. Подобные приложения создаются с помощью так называемых "настольных СУБД" (Clarion, Clipper, FoxPro, Paradox, dBase, MS Access) или с помощью файловой системы и диалоговой оболочки для ввода, редактирования и обработки данных.
Групповые информационные системы ориентированы на коллективное использование информации членами рабочей группы (одного подразделения), чаще всего строятся как локальная вычислительная сеть ПК или реже как многотерминальная централизованная вычислительная система. Однотипные или специализированные рабочие места обеспечивают вызов одного или нескольких конкретных приложений. Общий информационный фонд представляет собой базу данных или совокупность файлов документов. Совместное использование информации организуется с помощью блокировок записей и файлов. При разработке таких приложений используются многопользовательские "настольные СУБД", серверы БД для рабочих групп (Btrieve, NetWare SQL, Gupta SQLBase, Sybase Anywhere SQL, MS SQL Server, Progress, Informix-SE, Workgroup Oracle и др.) и соответствующие инструменты разработки или системы управления документами и их инструментальные средства. Взаимодействие пользователей происходит через централизованную базу данных или посредством сетевой файловой системы или через электронную почту.
Корпоративные информационные системы являются развитием систем для рабочих групп и ориентированы на масштаб предприятия, могут поддерживать территориально разнесенные узлы или сети. Они могут иметь иерархическую структуру из нескольких уровней. Главная особенность - обеспечение доступа из подразделения к центральной или распределенной базе данных предприятия (организации) помимо доступа к информационному фонду рабочей группы. Для таких систем характерна архитектура клиент-сервер со специализацией серверов. Они строятся на корпоративных SQL-серверах БД (Oracle7, Informix-OnLine, Informix-DSA, Sybase, CA-Ingress и др.) и соответствующих инструментальных средствах. Помимо собственных средств разработки часто находят применение независимые многоплатформенные инструментальные средства, дополненные интерфейсами, драйверами и шлюзами для связи с разными СУБД.
Для таких систем повышаются требования к надежности функционирования и сохранности данных. Последнее свойство обеспечивается поддержкой целостности данных, ссылок и транзакций в серверах баз данных. Транзакция представляет собой неделимый набор операций с БД, она завершается успешно, когда выполнены все ее операции, в противном случае происходит откат в состояние, предшествующее выполнению транзакции.
Рассмотрим основные типы информационных систем (рисунок 1) и связанные с ними приложения. По оперативности обработки данных различают пакетные и оперативные информационные системы (реального времени). Информационные системы с пакетной обработкой в чистом виде можно встретить на больших централизованных ЭВМ. В информационных системах организационного управления преобладает режим оперативной обработки транзакций OLTP (OnLine Transaction Processing) для отражения актуального состояния предметной области в любой момент времени, а пакетная обработка занимает весьма ограниченную нишу. Для систем OLTP характерен регулярный (возможно, интенсивный) поток довольно простых транзакций, играющих роль заказов, платежей, запросов и т. п. Важными требованиями являются высокая производительность обработки транзакций и гарантированная доставка информации при удаленном доступе к БД по телекоммуникациям.
Рисунок 1.
Классификация информационных систем.
Системы поддержки принятия решений DSS (Decision Support System) представляют собой другой тип информационных систем, в которых с помощью довольно сложных запросов производится отбор и анализ данных в различных разрезах: временных, географических и по различным показателям. Помимо традиционных средств доступа к БД развитые системы DSS включают следующие средства:
- извлечения данных из разнородных источников, включая неструктурированную информацию;
- многомерного анализа данных;
- обработки статистики;
- моделирования правил и стратегии деловой деятельности;
- деловой графики для представления результатов анализа;
- анализа "что если";
- искусственного интеллекта.
Средства искусственного интеллекта составляют экспертную подсистему, основанную на правилах или прецедентах из базы знаний и соответствующих механизмов вывода. В общем случае требование оперативности не является обязательным для таких систем с учетом сложности транзакций и аналитической обработки.
В классе систем поддержки принятия решений выделяется отдельный класс систем оперативной аналитической обработки OLAP (OnLine Analysis Processing). Здесь оперативность обработки достигается за счет применения мощной многопроцессорной вычислительной техники, специальных OLAP-серверов, изощренных методов многомерного анализа и специальных хранилищ данных Data Warehouse, накапливающих информацию (из разных источников за большой период времени) и обеспечивающих к ним оперативный доступ. Кроме готовых OLAP-систем для конкретных областей, например финансовой, существуют инструментальные наборы для разработки подобных приложений на базе СУБД или OLAP-серверов и хранилищ данных.
Существует обширный класс информационно-справочных систем, основанных на гипертексте и мультимедиа. Гипертекст (гипермедиа) представляет собой совокупность логически связанных текстовых, графических, аудио- и видео-материалов. Многие программные продукты поставляются со справочными системами или электронной документацией, организованной похожим образом. В обучающих программах также часто используется принцип гипертекста. Дальнейшее развитие такие информационные системы получили в сети Internet, в частности в мировой сети WWW. Здесь понятие гипертекстовой ссылки было расширено на глобальную сеть, она включает имя узла, имя файла и позицию внутри файла. Специальные WWW-серверы являются хранилищем такого гипертекста, клиенты имеют программы просмотра (браузеры). В последнее время пассивный характер подобных систем изменился, в них появились средства диалога для формирования заказов на продукцию и для проведения оплаты товара. Перспективы развития при этом связывают с языком Java (предложен Sun), ориентированным на разработку информационных приложений для Internet.
Самостоятельный подкласс информационно-справочных систем составляют географические информационные системы GIS. Здесь информация привязана к точкам на карте или плане местности. Для одной географической области могут быть представлены несколько картографических слоев с разными объектами и соответственно разной информацией по этим объектам, например городские коммуникации, транспортные связи, лесные массивы, водоемы и т. п. Слои могут накладываться, образуя карту, ориентированную на решение конкретных задач.
Значительная доля информации, циркулирующей в учреждениях, представляет собой неструктурированные данные из бумажных документов. Современные системы управления электронными документами EDMS нацелены на перевод бумажных документов в электронный вид, обеспечиваются средствами индексирования и поиска, некоторые из них обладают свойствами гипертекста. Развитые офисные системы включают средства коллективной работы Groupware, обеспечивающие автоматизацию делопроизводства с использованием электронной почты, средств заполнения бланков, электронных таблиц и текстовых редакторов.
Для автоматизации документооборота и контроля исполнительской дисциплины применяются методы и средства Workflow. В систему закладываются графы взаимоотношений работников учреждения, задания, привязка к документам и БД, маршруты движения документов. Предметом разработки в таких системах служат диалоговые формы в узлах графовых моделей. Специальные средства помогают сгенерировать прототип формы, а разработчик лишь расширяет ее для обработки нетривиальных ситуаций. Здесь основная трудность заключается в построении целостной системы графов, описывающих деловую деятельность учреждения.
В данном обзоре подробно рассматриваются вопросы построения информационных приложений класса OLTP на основе реляционных баз данных.
Варианты построения информационных приложений
Групповые и корпоративные информационные системы и соответствующие приложения могут строиться различными способами:
- многотерминальные централизованные вычислительные системы;
- системы на основе локальной сети ПК (файл-серверные приложения);
- системы с архитектурой клиент-сервер;
- системы с распределенными вычислениями;
- офисные системы;
- системы на основе Internet/Intranet-технологий.
Для лучшего понимания ограничений различных архитектур информационных систем, разделим приложения на типовые компоненты.
Типовые компоненты информационных приложений
Выделим в информационном приложении типовые функциональные компоненты, достаточные для формирования любого приложения на основе БД.
PS (Presentation Services) - средства представления. Обеспечиваются устройствами, принимающими ввод от пользователя и отображающим то, что сообщает ему компонент логики представления PL, плюс соответствующая программная поддержка. Может быть текстовым терминалом или Х-терминалом, а также ПК или рабочей станцией в режиме программной эмуляции терминала или Х-терминала.
PL (Presentation Logic) - логика представления. Управляет взаимодействием между пользователем и ЭВМ. Обрабатывает действия пользователя по выбору альтернативы меню, по нажатию кнопки или при выборе элемента из списка.
BL (Business or Application Logic) - прикладная логика. Набор правил для принятия решений, вычислений и операций, которые должно выполнить приложение.
DL (Data Logic) - логика управления данными. Операции с базой данных (SQL-операторы SELECT, UPDATE и INSERT), которые нужно выполнить для реализации прикладной логики управления данными.
DS (Data Services) - операции с базой данных. Действия СУБД, вызываемые для выполнения логики управления данными, такие как манипулирование данными, определения данных, фиксация или откат транзакций и т. п. СУБД обычно компилирует SQL-предложения.
FS (File Services) - файловые операции. Дисковые операции чтения и записи данных для СУБД и других компонент. Обычно являются функциями ОС. Можно привести несколько схем построения информационных систем (таблица 1) в зависимости от размещения типовых компонентов приложения по узлам сети.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Централизованные многотерминальные системы
В централизованной системе, характерной для Unix, терминал реализует лишь функции представления данных PS, тогда как остальные функции обеспечивает центральный узел. Центр должен реагировать на каждый запрос пользователя (PL), выполнять логику приложения (BL, DL) и извлекать данные из БД (DS, FS). Имеются две серьезные проблемы для централизованной схемы: трудно обеспечить графический интерфейс; каждый дополнительный пользователь и приложение вносят существенную нагрузку на сервер, теряется масштабируемость.
Файл-серверные приложения
В отличии от централизованной системы архитектура "файл-сервер" (таблица 1 и рисунок 2) не имеет сетевого разделения компонентов диалога PS и PL, использует ПК для функций отображения, что облегчает построение графического интерфейса. Файл-сервер только извлекает данные из файлов, так что дополнительные пользователи и приложения добавляют лишь незначительную нагрузку на ЦП. Каждый новый клиент добавляет вычислительную мощность к сети.
Рисунок 2.
Варианты построения файл-серверных приложений.
Объектами разработки в файл-серверном приложении являются компоненты приложения, определяющие логику диалога PL, а также логику обработки BL и управления данными DL. Разработанное приложение реализуется либо в виде законченного загрузочного модуля или в виде специального кода для интерпретации.
Однако такая архитектура имеет два основных недостатка: некоторые запросы к БД могут перекачивать всю БД клиенту, загружая сеть и имея непредсказуемое время реакции, тем самым, создавая значительный сетевой график, а также возникающая проблема "толстого клиента" - Windows-интерфейс, коды приложения и СУБД могут перегрузить даже мощный ПК.
Первый недостаток особенно сказывается при организации удаленного доступа к базам данных на файл-сервере через низкоскоростные каналы связи. В этом случае система с удаленными рабочими станциями оказывается практически неработоспособной. В данным случае единственное решение - удаленное управление файл-серверным приложением в сети (таблица 1 и рисунок 2). В локальной сети ставится сервер приложений, совмещенный с телекоммуникационным сервером (сервер доступа). В многозадачной среде этого сервера выполняются обычные файл-серверные приложения. Особенность состоит в том, что диалоговый ввод-вывод поступает через телекоммуникации от удаленных клиентов. Приложения не должны быть слишком сложными, иначе шансы перегрузки сервера увеличиваются, или же нужна очень мощная платформа для сервера приложений. На клиентских узлах работают программы удаленного управления или эмуляции терминалов, которые передают сигналы от клавиатуры и мыши серверу приложений, а в ответ получают копии экранов и отображают их на видеомониторе. Помимо перечисленных недостатков нужно отметить, что многие "настольные СУБД", как традиционные инструменты файл-серверных приложений, не отвечают требованиям сохранности данных, в частности не поддерживают транзакции. Однако СУБД для ПК привлекают простотой использования и доступностью, поэтому файл-серверные приложения еще будут использоваться для рабочих групп.
Приложения клиент-сервер
Архитектура клиент-сервер предназначена для разрешения проблем файл-серверных приложений путем разделения компонентов приложения и размещение их там, где они будут функционировать более эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL и выполняющих поиск, сортировку и агрегирование информации на месте без излишней перекачки данных на рабочие станции.
Другая отличительная черта серверов БД - наличие справочника данных, в котором записаны структура БД, ограничения целостности данных, форматы и даже серверные процедуры обработки данных по вызову или по событиям в программе. Объектами разработки в таких приложениях помимо диалога и логики обработки являются прежде всего реляционная модель данных и связанный с ней набор SQL-операторов для типовых запросов для этой БД.
Большинство конфигураций клиент-сервер использует двухзвенную модель, состоящую из клиента, который обращается к услугам сервера (сх. 3-6 в таблице 1, рисунок 3). Для эффективной реализации такой схемы часто применяют неоднородную сеть. Как минимум, предполагается, что диалоговые компоненты PS и PL размещаются на клиенте, что позволяет обеспечить графический интерфейс. Далее возможно разместить компоненты управления данными DS и FS на сервере, а диалог (PS, PL), логику BL и DL на клиенте - сх. 3 в таблице 1). Типовое определение архитектуры клиент-сервер - приложение на клиенте, СУБД - на сервере - использует эту схему.
Рисунок 3.
Варианты построения приложений клиент-сервер.
Поскольку эта схема предъявляет наименьшие требования к серверу, она обладает наилучшей масштабируемостью. Однако сложные приложения, вызывающие большое взаимодействие с БД, могут жестко загрузить как клиента, так и сеть. Результаты SQL-запроса должны вернуться клиенту для обработки, потому что там находится логика принятия решения. Такая схема возлагает дополнительное бремя администрирования приложений, разбросанных по различным клиентским узлам.
Можно сократить нагрузку на клиента и сеть, переместив целиком компонент BL на сервер, при этом вся логика принятия решений оформлена в виде хранимых процедур и выполняется на сервере БД. Хранимая процедура - процедура с операторами SQL для доступа к БД, вызываемая по имени с передачей требуемых параметров и выполняемая на сервере БД. Компиляция повышает скорость исполнения хранимых процедур и сокращает нагрузку на сервер. Но, перегрузив хранимые процедуры прикладной логикой, можно потерять преимущества по производительности. Хранимые процедуры улучшают целостность приложений и БД, гарантируют актуальность коллективно используемых операций и вычислений. Улучшается сопровождение таких процедур, а также безопасность (нет прямого доступа к данным).
Переместив с клиента часть логики приложения на сервер, получим систему клиент-сервер с разделенной логикой. Часть прикладной логики может быть реализована на клиенте, а другая часть логики - в виде обработчиков событий (триггеров) и хранимых процедур на сервере БД. Такая схема при удачном разделении логики приводит к сбалансированной загрузке клиентов и сервера, но при этом затрудняется сопровождение приложений.
На основе многотерминальной системы в качестве сервера приложений также возможно создание архитектуры клиент-сервер (рисунок 4). В этом случае в многозадачной среде сервера приложений выполняются программы пользователей, а клиентские узлы вырождены и представлены терминалами. Подобная схема информационной системы характерна для Unix.
Рисунок 4.
Приложения клиент-сервер на основе многотерминальной системы.
Двухзвенные схемы приводят к некоторым проблемам в сложных приложениях со множеством пользователей, с запутанной логикой, с неоднородными БД и разнородными входами в БД:
- необходимость администрирования приложений для большого числа клиентов при отсутствии унификации в конфигурациях клиентов и средств управления изменениями;
- чрезмерное использование хранимых процедур для реализации прикладной логики снижает масштабируемость сервера и не способствует переносимости приложений;
- возрастает время реакции из-за ожидания завершения пакетного задания на сервере и влияния таких заданий на диалоговых пользователей;
- проблема обеспечения целостности распределенной транзакции в неоднородной распределенной БД.
Ряд перечисленных проблем могжет быть решены при использовании режима распределенных вычислений.
Распределенные вычисления
Удаленный доступ к базам данных является частным случаем режима распределенных вычислений, при котором клиент запрашивает выполнение операторов или процедур управления данными (хранимых процедур и триггеров) на удаленном сервере баз данных. Распределенные вычисления представляют собой процедурный подход к реализации распределенных приложений, при этом клиент вызывает удаленное выполнение процедур, запросов и заданий на сервере приложений. Распределенные вычисления появляются в том случае, когда явно выделяется сервер приложений, который обеспечивает прикладную логику обработки данных, что присуще трехзвенным архитектурам клиент-сервер.
Трехзвенная архитектура позволяет еще больше сбалансировать нагрузку на разные узлы и сеть, а также способствует специализации инструментов для разработки приложений. Сбалансированная трехзвенная архитектура (сх. 9-10 в таблице 1) устраняет недостатки двухзвенной модели. В этих схемах клиент выделен для выполнения функций и логики представлений PS и PL, имеет программный интерфейс для вызова приложения на среднем уровне. Сервер БД выделен для услуг обработки данных DS и файловых операций FS (без риска использования хранимых процедур). Средний уровень представляет собой сервер приложений, на котором выполняется прикладная логика BL и с которого логика обработки данных DL вызывает операции с БД DS. Примером такой системы является неоднородная архитектура клиент-сервер на основе ПК в локальной сети NetWare, Unix-сервера приложений c монитором транзакций Tuxedo на Sun SPARCserver 20 MP и сервера баз данных Oracle7 в среде Solaris на Sun SPARCserver 1000.
Централизация логики приложения упрощает администрирование и сопровождение, а также обеспечивает доступ к ресурсам по именам. Четко разделяются платформы и инструменты для реализации интерфейса и прикладной логики, что позволяет с наибольшей отдачей реализовать их специалистам узкого профиля. И, наконец, изменения прикладной логики не затрагивают интерфейса, и наоборот. Но поскольку границы между компонентами PL, BL и DL размыты, прикладная логика может появиться на всех трех звеньях. Сервер приложений с помощью монитора транзакций обеспечивает интерфейс с клиентами и другими серверами, может управлять транзакциями и гарантировать целостность распределенной БД путем двухфазной фиксации в неоднородной среде. Средства удаленного вызова процедур наиболее соответствуют идее распределенных вычислений, они обеспечивают вызов из любого узла сети прикладной процедуры, расположенной на другом узле, передачу параметров, удаленную обработку и возврат результатов. Сервер приложений может также управлять асинхронными очередями сообщений, которые обеспечивают надежное завершение транзакций. С ростом систем клиент-сервер необходимость трех звеньев становиться более очевидной. Продукты для трехзвенной архитектуры являются относительно новыми. Несколько производителей продают мониторы транзакций для построения таких систем: Tuxedo (BEA System), Encina TP monitor (IBM), TopEnd (NCR) и ACMS TP monitor (DEC). Эти инструменты в основном ориентированы на среду Unix, однако прикладные серверы можно строить на MS Windows NT с использованием вызова удаленных процедур RPC и протокола Named Pipes для организации связи клиентов с сервером приложений. На практике в локальной сети могут использоваться смешанные архитектуры двухзвенные и трехзвенные с одним и тем же сервером БД. С учетом глобальных связей архитектура может иметь больше трех звеньев. Сейчас появляются новые инструментальные средства для гибкой сегментации приложений клиент-сервер по различным узлам сети.
Офисные системы
Архитектура офисных систем может быть весьма разнообразной. В простом случае схема подобна файл-серверным приложениям, при этом используются файловый или почтовый серверы для хранения коллективно обрабатываемой информации с помощью средств офисной автоматизации (текстовых процессоров и электронных таблиц). В системах управления электронными документами чаще всего файл-сервер используется для хранения документов, а сервер БД служит для ведения библиотеки карточек документов. Существуют универсальные серверы БД, которые интегрируют фактографическую и неструктурированную информацию.
Информационные системы на основе Internet/Intranet-технологии
Изначально технология Internet/Intranet/ WWW предназначалась для облегчения доступа к информации и публикации документов. Программа-клиент выполняет функции интерфейса пользователя и обеспечивает доступ практически ко всем информационным ресурсам Internet. База данных HTML-документов - это часть файловой системы, которая содержит текстовые файлы в формате гипертекста и связанные с ними графику и другие ресурсы. Фактически браузер является интерпретатором HTML-текста. И, как типичный интерпретатор, клиент в зависимости от команд разметки выполняет различные функции. В круг этих функций входит не только размещение текста на экране, но и обмен информацией с сервером по мере анализа полученного HTML-текста, что наиболее наглядно происходит при отображении встроенных графических образов. При анализе URL-спецификаций или по командам сервера клиент запускает дополнительные внешние программы для работы с документами в форматах, отличных от HTML, например GIF, JPEG, MPEG, Postscript и т. п. В последнее время все большее распространение получает механизм согласования запускаемых программ через MIME-типы.
До недавнего времени сеть Internet была "улицей с односторонним движением" - информация с Web-страниц поступала к пользователю от Web-сервера при наличии запроса. Обратная связь с пользователем - анкетные листы и параметры запроса для работы поисковых систем. При этом программирование серверной части осуществляется с использованием CGI-скриптов.
Если Web-сервер использует традиционные статичные Web-страницы, то в ответ на запрос клиента Web-сервер передает страницу в формате HTML. Однако при работе с приложениями базы данных адрес URL указывает не на Web-страницу, а на программу или сценарий, который запускает запрос к базе данных и преобразует результаты в формат HTML. Затем Web-сервер посылает полученную HTML-страницу Web-клиенту. Так как этот процесс основан на технологии Web, клиентской платформой может стать любой компьютер, на котором исполняется Web-браузер, а серверной платформой - любая ЭВМ под управлением Web-сервера.
Использование CGI-скриптов имеет ряд недостатков - статичное представление информации, преобразование результата запроса - отчета в HTML-файл, отсутствие динамического просмотра изменения информации в базе данных. Кроме того, такой принцип работы перегружает каналы связи.
Предложенная фирмой Sun технология Java ориентирует взаимодействие между клиентом и сервером на поток команд, а не данных. В ходе сеанса обеспечивается фоновая подкачка через сеть на компьютер клиента программных агентов - апплетов, которые берут на себя функции обеспечения гибкого взаимодействия. Все, что нужно для этого, - встроить в Web-браузер исполняющую систему для апплетов.
Для исполнения апплетов на любой архитектуре необходимо обеспечить их выполнение на абстрактной архитектуре. Конкретизацией занимается Web-браузер. Апплеты представляют собой переносимый бинарный код, способный функционировать на любой архитектуре, где реализована виртуальная Java-машина, интерпретирующая байт-коды, порожденные соответствующим компилятором. Байт-коды были впервые реализованы при создании переносимых Pascal-программ и получили название P-кодов.
Схема, используемая при реализации языка Java, во многом схожа с принципами P-кодов. Исходный текст на языке Java транслируется специальным конвертером (Java Compiler) в Java-байт-код. При использовании в Internet/Intranet этот код передается по каналам связи на удаленную машину, где попадает в загрузчик байт-кодов (Bytecode Loader). Затем он подвергается специальной динамической проверке, которую осуществляет верификатор байт-кодов (Bytecode Verifier). Предварительные проверки, возложенные на верификатор, гарантируют корректность типов параметров всех пришедших байт-инструкций, отсутствие переполнения стека операндов и, наконец, корректность доступа к полям объекта с учетом атрибутов. Это предпринято с целью обеспечить безопасность исполняемого кода, а также для проведения скрытой оптимизации.
Затем проверенный байт-код передается интерпретатору, который посредством исполняющей системы виртуальной Java-машины осуществляет привязку к конкретной архитектуре.
Классификация средств разработки информационных приложений
Среди средств разработки информационных приложений можно выделить следующие основные группы:
- традиционные системы программирования;
- инструменты для создания файл-серверных приложений;
- средства разработки приложений клиент-сервер;
- средства автоматизации делопроизводства и документооборота;
- средства разработки Internet/Intranet-приложений;
- средства автоматизации проектирования приложений.
Рассмотрим кратко отличительные черты и область применения каждой группы инструментальных средств создания информационных приложений.
Традиционные системы программирования
Традиционные системы программирования представлены средствами создания приложений на языках третьего поколения 3GL: C, Pascal, Basic и др. Среди них по способам подготовки и выполнения программных модулей различают системы компилирующего и интерпретирующего типа. Инструментальные средства программирования могут быть представлены набором отдельных утилит (редактор текстов, компилятор, компоновщик и отладчик) или интегрированной средой программирования.
Процедурные языки программирования являются традиционными, они лишь претерпели изменения от неструктурных до структурных языков программирования. Объектно-ориентированное программирование - сравнительно новое направление, однако оно в концептуальном плане более привлекательно, позволяет рассматривать и реализовывать информационные и функциональные свойства объектов в неразрывной связи. Свойствами объектно-ориентированных языков, обуславливающими их преимущества, являются сокрытие деталей реализации объекта (инкапсуляция), наследование процедурных и информационных частей от объектов-родителей, полиморфизм как возможность настройки на различные типы данных и др. Примерами объектно-ориентированных систем программирования являются C++ и Object Pascal.
Системы программирования 3GL нужны для организации специальных модулей в информационных приложениях, для создания эффективных по быстродействию программ обработки данных. Для создания с помощью систем программирования полноценных информационных приложений необходимо расширить их за счет использования библиотек диалога и доступа к базам данных, а также макросредств встроенного языка структурированных запросов Embeded SQL.
Систему программирования Visual Basic можно использовать для создания простых автономных приложений и компонентов VBX и OCX, для расширения и интеграции функциональных пакетов (Word, Excel, Access), а также как средство программирования для расширения систем документооборота и для создания утилит администрирования. В настоящее время Visual Basic самый распространенный язык программирования
С момента выхода продано существенно меньше копий Delphi, чем Visual Basic. Поэтому решение вопроса об использовании Delphi для серьезных коммерческих приложений буде зависеть от перспектив распространения этого продукта на рынке. Применение продукта возможно для создания расчетно-аналитических программ, для разработкии DLL, для сопровождения и развития разработок, выполненных на Turbo и Borland Pascal, а также для быстрого прототипирования будущих приложений. В ряде случаев решающим для выбора будут умеренные требования Delphi-приложения к системно-техническому обеспечению.
Рисунок 5.
Основные способы построения Internet/Intranet-приложений.
С++ применяется для расширения системного программного обеспечения, для разработки крупных проектов, специальных приложений, создания библиотек и классов для предметной области, разработки динамических библиотек DLL, создания программного обеспечения для серверов приложений, разработки ОСХ, использования совместно с CASE-системами, обеспечения многоплатформенности и переносимости (по стандарту ANSI).
Рисунок 6.
Использование загружаемых интерпретируемых программ.
Инструменты для создания файл-серверных приложений
Основой разработки файл-серверных приложений для локальных сетей ПК является инструментальное окружение различных "персональных" СУБД: FoxPro, Clipper, Paradox, Clarion, Paradox, dBase и т. п. Такие средства, как правило, реализованы в виде диалоговой интегрированной среды, предоставляющих три уровня доступа:
- программирование и создание приложений на языке, сочетающем возможности языка 3GL с некоторыми возможностями языков четвертого поколения 4GL;
- создание и ведение структуры БД и индексов, а также интерактивная генерация макетного приложения и его компонентов (меню, форм или окон, отчетов, запросов и программных модулей);
- использование диалоговой среды и генераторов конечными пользователями для создания, ведения и просмотра БД, а также формирования несложных запросов и отчетов.
Диалоговые среды поддерживают как текстовой для DOS, так и графический интерфейс пользователя для Windows. Внедрение графического интерфейса привело к развитию объектных свойств инструментов, средств визуальной генерации программ и событийного механизма приложений.
База данных для этих СУБД представляет собой совокупность файлов БД и индексов, а не единое информационное пространство, что усложняет ее сопровождение. Ни одна из традиционных СУБД для ПК не имеет средств ограничения целостности. Среди инструментальных средств СУБД для ПК преобладают интерпретирующие системы, хотя многие предоставляют и альтернативную возможность создания загрузочных модулей приложений.
СУБД для ПК MS Access может использоваться для создания масштабируемых одиночных и групповых информационных приложений и для разработки клиентской части приложений клиент-сервер, а также как средство автоматизации делопроизводства в составе MS-Office.
Традиционные инструментальные средства класса xBase (такие как FoxPro, Clipper, dBase и др.) теряют рынок (число их продаж значительно сокращается) из-за несоответствия современным требованиям. По мере того, как предприятия все шире используют СУБД MS Access и новые средства разработки, такие как Visual Basic и Delphi, популярность среды Xbase уменьшается. Более того, Microsoft может прекратить поддержку FoxPro, так как эта СУБД с устаревшим языком и сокращающейся рыночной долей не вписывается в долговременную стратегию развития средств разработки, которую Microsoft строит вокруг Visual Basic и Access. Новые "визуальные" инструменты этого класса (Visual FoxPro, CA-Visual Objects, Visual dBase) пытаются сохранить и расширить прежний ареал. Они могут быть рекомендованы для сопровождения и развития прежних xBase-разработок, для создания масштабируемых одиночных и групповых файл-серверных приложений и для переноса и адаптации приложений в архитектуру клиент-сервер с использованием интерфейса ODBC. Но нужно четко осознавать, что при применении нового инструментария для создания диалога и с переходом на SQL-операторы от прежних xBase-приложений остается ничтожно мало, а, кроме того, существенно меняется подход к разработке, и прежние навыки вряд ли будут востребованы.
Инструментальное средство MS Access хорошо зарекомендовало себя в разработке файл-серверных приложений с возможностью масштабирования, так как оно имеет удобные средства визуального конструирования, отладки и возможности использования как Access Basic, так и SQL. Интерфейс ODBC открывает широкие возможности интероперабельности с различными СУБД. В 1995 г. на долю MS Access пришлось 57% рынка настольных баз данных, а FoxPro и dBase - 9% и 2%, соответственно.
Средства разработки приложений клиент-сервер
Группу инструментальных средств для создания информационных приложений с архитектурой клиент-сервер можно разделить на следующие подгруппы: среды разработки приложений для серверов баз данных, независимые от СУБД инструменты для создания приложений клиент-сервер, средства поддержки распределенных информационных приложений.
Среды разработки приложений для серверов БД представляют собой системы программирования четвертого поколения 4GL или инструментальные средства быстрой разработки приложений RAD (Rapid Application Development). Особенностями этой подгруппы средств являются: реализация удаленного доступа к СУБД по двухзвенной схеме клиент-сервер; связь клиентских приложений с серверами БД с помощью непроцедурного языка структурированных запросов SQL (кроме серверов Btrieve); обеспечение целостности БД, включая целостность транзакций; поддержка хранимых процедур на серверах БД; реализация клиентских и серверных триггеров-процедур; генерация элементов диалогового интерфейса и отчетов.
В качестве примера можно назвать инструменты Informix/4GL, Oracle*Forms и др. Сейчас новые среды разработки SQL-серверов БД (Informix NewEra и Oracle Power Objects) развиваются в сторону независимых от СУБД инструментов. Независимые инструментальные средства, ориентированные на многие платформы СУБД, представлены в виде средств быстрой разработки приложений RAD. Для таких средств создания приложений клиент-сервер характерны: возможность распределения приложения на клиентах и/или серверах; создание приложений для разных серверов БД; поддержка спецификации ODBC для доступа к различным серверам БД, включая СУБД для ПК; связь с мониторами транзакций для организации трехзвенной архитектуры приложений клиент-сервер; объектно-ориентированное программирование приложений; визуальный характер генерации приложения; ведение репозитария объектов и их свойств, что облегчает интеграцию со средствами автоматизации проектирования программ CASE; управление проектами и версиями приложений; интеграция приложения с электронной почтой и средствами офисной автоматизации.
Известными примерами независимых инструментальных средств разработки являются: SQLWindows, PowerBuilder, JAM и Uniface.
Средства поддержки распределенных приложений относятся к категории промежуточного программного обеспечения middleware для организации серверов приложений. Сюда входят разнообразные библиотеки и наборы инструментальных средств: интерфейсы доступа к базам данных ODBC и IDAPI; шлюзы для систем управления базами данных; протоколы и команды мониторов обработки транзакций; почтовые интерфейсы MAPI, VIM, MHS, X.400 и EDI; средства обмена сообщениями MOM; протоколы связывания и включения объектов OLE и динамического обмена данными DDE; протоколы удаленного вызова процедур RPC и именованных конвейеров Named Pipes, средства коммуникационного ввода-вывода BSD Sockets и WinSock.
Инструментальные наборы для разработки приложений клиент-сервер необходимо выбирать, исходя из следующих критериев (см. таблицу 2): наличие объектно-ориентированной инфраструктуры, возможности распределения приложений между клиентом и сервером, обеспечена ли поддержка мониторов транзакций, доступность CASE-репозитария, возможность переноса приложений и контроль версий. При этом следует выяснить, насколько опыт разработчиков предприятия соответствует требованиям продукта, важна ли переносимость приложений на другие аппаратные платформы и базы данных, какая степень интеграции приложений устроит заказчика и нужно ли будет в дальнейшем подключать к приложению дополнительных пользователей, функции и данные.
Таблица 2.
|
|
тированная инфраструктура |
|
|
|
зитарий |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Кроме того, развитие современных программных средств приводит к расширению их функциональных возможностей, в результате чего программные обеспечения разных типов конкурируют друг с другом. Так, продукт Borland C++ Builder превращающий компилятор Borland Visual C++ в полноценную среду разработки приложений в архитектуре клиент-сервер. Предлагаемый продукт дополняет C++ визуальными "дизайнерами", интуитивными "мастерами" и средствами доступа к объектно-ориентированным данным, сохраняя знакомое окружение Visual C++.
Мощное средство Oracle Forms из набора Developer/2000 предназначено для создания приложений баз данных в среде клиент/сервер, которые могут быть перенесены на платформы с различными графическими и символьными пользовательскими интерфейсами. Oracle Forms является частью Developer/2000, который поддерживает разработку приложений во время всего жизненного цикла. Приложения, созданные с помощью Developer/2000, полностью масштабируемы и применимы на любом уровне: от систем поддержки принятия решений для небольших рабочих групп до проектов с большим объемом транзакций, которые поддерживают сотни пользователей. Приложения, созданные с помощью Developer/2000, оптимизированы с целью использования всех преимуществ сервера Oracle7, поэтому они должны быть основными средствами при разработке приложений в среде Oracle7.
Инструментальная среда NewEra для СУБД Informix обладает всеми свойствами для эффективной разработки приложений в этой среде. Дополнительные преимущества - возможность интеграции с программами на С и многоплатформенность - делают ее пригодной не только при разработке приложений для СУБД Informix, но и для других систем. Следует заметить, что вопрос интероперабельности Informix-Oracle решен неудовлетворительно.
Uniface поддерживает интерфейс практически со всеми известными программно-аппаратными платформами, протоколами, СУБД и мониторами транзакций. Это средство необходимо использовать при разработке и сопровождении типовых комплексов приложений с высокой тиражируемостью. Платой за универсализм является высокая стоимость продукта.
Анализ и апробация возможностей MS Access показал, что это инструментальное средство хорошо зарекомендовало себя как в разработке файл-серверных приложений, так и для разработки клиентской части приложений в архитектуре клиент/сервер, наличие поддержки языка SQL и интерфейса ODBC открывает доступ к SQL-серверам БД. Имеется средство для миграции приложений MS Access в среду MS SQL Server. К достоинствам Access следует отнести и пониженные требования к ресурсам. К сожалению, последние версии пакета ориентированы лишь на офисную автоматизацию и не содержат runtime-компонент для создания законченного информационного приложения.
Средство JAM имеет недостаточную разрядность и может быть использовано только в приложениях, не требующих высокой точности, например для создания аналитических систем. Но его отличает многоплатформенность и поддержка мониторов транзакций.
Пакет Oracle Power Object предназначен для разработчиков, впервые приступающих к разработке приложений клиент-сервер и переходящих от таких систем, как FoxPro или Clipper, и наиболее пригоден для создания прототипов больших систем.
Система Delphi чрезвычайно удобна для разработки приложений локальных баз данных, которые при необходимости могут быть конвертированы в приложения типа клиент-сервер. Delphi следует использовать для создания масштабируемых приложений для рабочих групп, для разработки средств доступа к различным БД, для создания аналитических систем, для создания одиночных и групповых приложений, критичных по времени выполнения.
Все три средства - JAM, Oracle Power Object и Delphi - пригодны для создания быстрых прототипов, и их использование в таком качестве может иметь определенные достоинства.
Средства автоматизации делопроизводства и документооборота
В группе средств автоматизации делопроизводства и документооборота можно выделить следующие подгруппы:
- средства автоматизации учрежденческой деятельности Office Automation;
- системы управления электронными документами EDMS;
- средства обеспечения коллективной работы Groupware;
- средства автоматизации документооборота Workflow.
Средства автоматизации учрежденческой деятельности включают в свой состав: текстовые редакторы для подготовки и корректировки документов; процессоры электронных таблиц для расчетов, анализа и графического представления данных; программы генерации запросов по образцу из различных БД; сетевые планировщики для назначения рабочих встреч и совещаний; средства разработки и демонстрации иллюстративных материалов для презентаций; словари и системы построчного перевода; программы посылки и приема факсов; локальную электронную почту для обмена сообщениями и пересылки файлов.
Эти средства могут представлять собой отдельные пакеты (WinWord, WordPerfect, Excel, Lotus 1-2-3 и т. п.), интегрированный пакет программ (MS Works) или согласованный набор пакетов (Microsoft Office или Corel Perfect Office). Для создания приложений на основе этих пакетов используют макроязыки или диалекты Basic (Word Basic, Excel Basic и др.) или единый язык для расширения приложений, например Visual Basic for Applications для продуктов Microsoft. Для многих пакетов характерно использование так называемых "мастеров" Wizard, которые в режиме диалога помогает неподготовленному пользователю выполнить сложную процедуру обработки.
Системы управления электронными документами имеют следующие функции: создание электронной копии документа путем сканирования бумажного оригинала или ввода его текста в ПК; построение полнотекстового индекса документа; создание учетной карточки документа и заполнение атрибутов; организация тематических папок и/или гипертекстовых ссылок; блокировка документов при коллективном использовании; поиск документов по атрибутам и ключевым словам. Широко известными примерами систем управления электронными документами являются DOCS Open и Excalibur EFS.
Средства обеспечения коллективной работы Groupware ориентированы на автоматизацию работы небольшого коллектива и поддерживают корректное совместное использование информации группой пользователей. Такое разделение информационных ресурсов возможно организовать в локальной сети ПК с помощью средств офисной автоматизации (Microsoft Office) и сетевой файловой системы или электронной почты и форматного ввода документов (Novell GroupWise и Perfect Office или Lotus Notes). При этом отсутствует структуризация в проведении работ, т. е. нет правил и предписаний по выполнению работ в системе. Эта подгруппа практически совпадает со средствами автоматизации учрежденческой деятельности, ее отличия заключаются в интеграции средств, коллективном использовании ресурсов и применении электронной почты.
Средства автоматизации документооборота Workflow нацелены на автоматизацию деятельности корпорации и поддерживают разделение работ, т. е. многопользовательскую обработку нескольких задач одновременно в синхронном или в асинхронном режиме. Для автоматизации документооборота и контроля исполнительской дисциплины применяются методы теории Workflow. В систему закладываются описания графов взаимоотношений работников, выполнение работ четко структуризовано: расписано по ролям, документам, времени обработки документов и заданы маршруты движения документов. Эти графовые модели и их параметры сохраняются в базе данных. Основная трудность при этом заключается в построении системы графов, описывающих деловую деятельность всего учреждения. В простейшем случае для поддержки документооборота бывает необходимо обеспечить маршрутизацию документов по электронной почте. Система может быть интегрирована как с системой управления документами, так и с СУБД. Она реализуется в среде клиент-сервер и ориентирована на корпоративную сеть.
Предметом разработки в системах автоматизации документооборота являются экранные формы в узлах графов. Существуют генераторы форм, но для описания действий необходимо использовать макроязык или Visual Basic. В качестве примеров систем автоматизации документооборота назовем пакеты Action Workflow (Action Technologies) и Staffware (Staffware plc).
Средства разработки Internet/Intranet-приложений
Новый быстро развивающийся сектор Internet/Intranet-приложений включает следующие группы средств разработки информационных систем:
- традиционные средства разработки гипертекстовых информационных систем для публикации и поиска документов;
- средства для организации шлюза в другие приложения из традиционных Internet/Intranet-приложений;
- развитые средства программирования Internet/Intranet-приложений.
Традиционные средства разработки гипертекстовых ИС включают:
- редакторы и преобразователи гипертекста на основе языка разметки документов HTML;
- программы подготовки и встраивания гипермедиа-материалов (графики, аудио, видео);
- браузеры - программы просмотра и интерпретации гипертекста и гипермедиа;
- модули расширения браузеров.
Средства для организации шлюза в другие приложения из Internet/Intranet-приложений основаны на интерфейсах CGI и API Web-серверов, содержат средства выполнения CGI-процедур, расширения для связи с БД и для заполнения HTML-шаблонов. Интерфейс CGI может обеспечить вызов любых программ и в частности программ доступа к БД.
Развитые средства программирования Internet/ Intranet-приложений представлены различными системами программирования на интерпретируемых языках Java, JavaScript, Tcl и др. Приложения, построенные с использованием таких средств, могут загружаться с любого Web-сервера сети и интерпретироваться на клиентском узле. Это сохраняет платформенную независимость при расширении функциональности приложений. Возможно организовать оперативный доступ из Java к БД через интерфейс JDBC и сокеты.
Средства автоматизации проектирования приложений
Средства автоматизации проектирования приложений (CASE-средства) предназначены для анализа предметной области, для проектирования и генерации программ информационных приложений. Могут существовать в виде отдельных утилит или интегрированной среды проектирования. Системы CASE реализуют либо структурные, либо объектно-ориентированные методы анализа, проектирования и программирования. Кроме того, для каждой методики проектирования несколько различаются нотации схематических описаний. Различают следующие виды систем автоматизации проектирования приложений: независимые CASE-системы (например IDEF/Design); системы, интегрированные с СУБД (WestmountI-CASE for Informix и Oracle Designer/2000); системы проектирования БД (SILVERRUN и ERWin/ERX).
Характерными особенностями CASE-систем являются: наличие графических редакторов схем проекта, хранение описаний проектов в репозитарии объектов и генерация описания структуры и свойств БД, а также модулей приложения.
Средства управления версиями проектов должны поддерживать целостность системы в течение жизненного цикла, обеспечивать коллективную разработку, параллельное внесение изменений, откат к предыдущей версии и контроль доступа. Учитывая эти требования и свойства средств управления версиями SS и Intersolv PVSC, первое может быть рекомендовано для первоначального ведения версий, а второе - для полномасштабной работы с версиями.
Новые тенденции в средствах построения приложений
До недавнего времени все разработки ИС велись в основном на традиционных языках программирования. Необходимость учета многочисленных условий функционирования ИС и требований пользователей приводили к тому, что процесс создания слагался из нескольких циклов последовательного приближения к желаемому облику. При такой технологии ИС "отчуждали" пользователей от информации и вынуждали их занимать пассивную позицию наблюдателя. Бесчисленные модификации и стремительность изменений деловых процессов потребовала значительного сокращения сроков их создания. Пользователи локальных сетей ПК уже успели вкусить удобства решения своих частных задач "на рабочем столе" и прелесть графического интерфейса Windows GUI.
Все это послужило предпосылкой к рождению целого направления в индустрии программного обеспечения, чье имя - создание инструментов быстрой разработки приложений RAD (Rapid Application Development).
Объектная ориентация
RAD - это комплект специальных инструментальных средств быстрой разработки прикладных ИС, позволяющих оперировать с определенным набором графических объектов, функционально отображающих отдельные информационные компоненты приложений.
Средства RAD дали возможность реализовывать совершенно иную технологию создания приложений: информационные объекты формируются как некие действующие модели (прототипы), чье функционирование согласовывается с пользователем, а затем разработчик может переходить непосредственно к формированию законченных приложений, не теряя из виду общей картины проектируемой системы.
Подобное свойство инструментов RAD появилось как результат объектно-ориентированного подхода. Одна из трудностей в написании программного обеспечения заключается в глубокой пропасти между реальным миром, где существует описываемая проблема, и имитирующей средой. Один из путей упрощения разработки системы - создание отражений элементов предметной области в виде объектов.
Объектно-ориентированное программирование реально возникло тогда, когда было обеспечено слияние (инкапсуляция) данных с процедурами, описывающими поведение реальных объектов, в объекты программ, которые могут быть отображены определенным образом в графической пользовательской среде. Это позволило приступить к созданию программных систем, максимально похожих на реальные, и добиваться наивысшего уровня абстракции. В свою очередь, объектно-ориентированное программирование позволяет создавать более надежные коды, так как у объектов программ существует точно определенный и жестко контролируемый интерфейс.
Разработка приложений с помощью инструментов RAD ведется на основе использования множества готовых объектов, сохраняемых в общедоступном хранилище. При этом важно, чтобы инструменты RAD в полной мере были объектно-ориентированными, что становится возможным тогда, когда используемый для их написания язык программирования сам является объектно-ориентированным.
Объектно-ориентированные инструменты RAD в среде GUI позволяют на основе стандартных классов объектов, для которых инкапсулированы атрибуты и внутренние процедуры, формировать простые приложения без написания кода программы. Это составляет первое преимущество RAD, так как теперь даже конечный пользователь может создавать приложения, предназначенные для решения собственных задач. Объектная ориентация инструментов RAD позволяет самим разработчикам сосредоточиться на сущности реальных деловых процессов предприятия, для которого создается ИС. Это в итоге не может не повлиять на качество отображения моделируемых условий функционирования системы и требований пользователей в создаваемых прототипах и приложениях.
Визуальный характер программирования
Объектно-ориентированные языки 4GL оперируют в первую очередь со стандартными информационными объектами - окнами, списками, текстами, которые можно довольно просто связать с данными из БД и отобразить на экране монитора. Другая группа объектов представляет собой элементы управления (графические кнопки, "радиокнопки", меню, линейки скроллинга и т. д.), с помощью которых можно легко осуществлять управление отображаемыми данными. Все эти объекты могут быть стандартным образом описаны средствами языка, а сами описания сохранены для дальнейшего повторного использования.
С появлением объектно-ориентированных языков 4GL, включающих в себя средства формирования GUI, ситуация в разработке прикладных ИС принципиально меняется: инструменты RAD становятся визуальными и позволяют на любом этапе наблюдать то, что закладывается в основу принимаемых решений. Появился даже термин "визуальное программирование", определяющий новую технологию разработки. Некоторые RAD способны преобразовывать и отображать данные в виде графиков и диаграмм, а наиболее совершенные могут включать в создаваемые приложения звук, рисунки и графику, как мультимедийные объекты.
Поскольку разработка прототипов и пользовательского интерфейса по существу стала одной и той же задачей, программист получает непрерывную обратную связь с конечными пользователями, которые могут не только наблюдать за созданием приложения, но и активно участвовать в нем, корректировать результаты и свои требования. Это также способствует сокращению сроков разработки и является важным психологическим аспектом, который привлекает к RAD все большее число пользователей.
Визуальные инструменты RAD позволяют максимально сблизить этапы создания ИС: анализ исходных условий, проектирование системы, разработка прототипов и окончательное формирование приложений становятся сходными, так как на каждом этапе разработчики оперируют с визуальными объектами.
Событийное программирование
Логика приложения, построенного с помощью RAD, является событийно-ориентированной. Это означает следующее: в RAD определен набор событий, включающий открытие и закрытие окон, нажатие клавиши клавиатуры, срабатывание системного таймера, получение и передача управления (так называемого фокуса) каждым элементом экрана, некоторые события управления базой данных. Разработчик реализует логику приложения путем определения обработчика каждого события. Например, обработчик события "нажатие кнопки на экране" может открыть следующее экранное окно. Обработчиком событий в RAD могут быть как встроенные функции RAD, так и внешние функции. С точки зрения объектно-ориентированного проектирования, обработчики событий реализуют методы объектов, из которых состоит приложение. Программы обработчиков событий весьма короткие и простые. Для стандартных диалоговых элементов и экранных форм, отображающих записи БД, они определены по умолчанию и часто не требуют изменения.
Обработчики событий, связанных с управлением базой данных (DELETE, INSERT, UPDATE), реализуются в виде триггеров на клиентском или серверном узле. Такие обработчики позволяют обеспечить ссылочную целостность БД при операциях удаления, вставки и обновления.
Распределенные приложения
Средства разработки приложений нового поколения обеспечивают более сбалансированный и гибкий подход к созданию приложений клиент-сервер. Есть возможность перемещать прикладную логику на разные клиенты или сервера, это может делаться как статически при разработке, так и динамически в процессе эксплуатации.
В качестве примеров инструментальных средств, относящихся к последней группе, можно привести продукты фирм Informix, Progress, Dynasty Technologies, Forte и Seer Technology, с которыми связано новое понятие "сегментация приложений". Сегментация приложений - это технология создания прикладных систем, позволяющая разработчикам писать и сопровождать программы, ничего не зная ни об аппаратной платформе, ни о сетях, на которых они будут выполняться. Позже программа сетевого администрирования или персонал сопровождения распределяют приложения или их компоненты между серверами и клиентами, расположенными в разных узлах сети, выбирая конфигурацию, которая обеспечивает наибольшую производительность и надежную защиту данных. При наличии определенных инструментов компоненты приложений могут быть перераспределены динамически.
Построение распределенного приложения обеспечивается поддержкой широкого спектра протоколов и средств для создания распределенных вычислений и удаленного доступа: мониторов транзакций, почтовых интерфейсов, архитектуры WOSA фирмы Microsoft, где предусматривается связь с офисными приложениями.
Влияние Web-технологии
Инструменты файл-серверных, клиент-серверных и офисных приложений в настоящее время адаптируются к Internet/Intranet-технологии. Применение этих технологий обеспечивает:
- работу приложений на многих платформах;
- унификацию диалогового интерфейса и рабочих мест;
- упрощение разработки информационных приложений;
- механизм ссылок для организации логической связи информации;
- закрепление наработок диалога в HTML и Java;
- упрощение администрирования приложений и рабочих мест;
- несколько способов построения приложения;
- интеграцию офисных приложений и приложений, работающих с БД.
Web-технология в перспективе несколько потеснит традиционную технологию клиент-сервер и хорошо адаптируется к офисным приложениям.
Сближение с CASE-технологиями
Сближению новых инструментальных средств и систем автоматизации проектирования способствует наличие у инструментов: репозитария для хранения описаний проектируемых объектов; средств ведения коллективной разработки; средств управления проектами и версиями программ.
Ряд пакетов имеет графические средства для проектирования запросов и развитые средства документирования. Третьи фирмы выпускают мосты для связи CASE-систем и инструментальных средств. При этом может обеспечиваться неоперативный импорт/экспорт или оперативная связь в обе стороны и соответствующая утилита синхронизации двух репозитариев. Обратная связь важна для обеспечения перепроектирования по готовым программам и базе данных.
Заключение
Инструментальные программные средства разработки информационных приложений должны обеспечивать следующие важные свойства:
- поддержку многоплатформенности;
- независимость от производителя;
- унификацию средств разработки;
- создание надежного и качественного программного обеспечения;
- поддержку разработанного ПО на протяжении всего времени жизни;
- проектирование с использованием различных современных методик;
- ведение версий;
- поддержку Web-технологии.
В условиях быстрой эволюции вычислительной техники, смены операционных систем, схода с рынка ряда фирм-производителей, не вполне ясных альтернатив "клиент-сервер или мейнфрейм", "Unix или Windows NT", "закрытые сети или Internet" устойчивость информационно-вычислительной среды может быть обеспечена разумным консерватизмом в сочетании с трезвым анализом тенденций современного рынка.
Артемьев Валерий Иванович ГЦИ ЦБ РФ, тел.: 928-90-07