Ю.К. Петров

АО "Аргуссофт Компани", Тел.: (095) 288-3603, interbas@arguss.msk.su

Архитектура приложения.
JAM - инструментарий разработки приложений
    Ядро системы
    Взаимодействие с СУБД
    Генерация отчетов
    Взаимодействие с upper-CASE
    Взаимодействие с Мониторами Транзакций
    Дополнительные возможности JAM
Переносимость
Заключение.

Данная статья посвящена программному пакету JAM - современному инструментарию разработки приложений в информационных системах архитектуры "клиент-сервер", построенных на базе РСУБД, являющемуся представителем так называемых языков 4-го поколения (4GL). В России уже известны некоторые представители программного обеспечения этого класса. JAM, являясь полноценным представителем 4GL, обладает некоторыми чертами, которые отсутствуют у других систем, но, тем не менее, являются довольно существенными как с точки зрения технологии, так и с точки зрения организации процесса разработки информационных систем (ИС).

1. Архитектура приложения.

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

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

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

2. JAM - инструментарий разработки приложений

Инструментарий разработки приложений JAM разработан и распространяется фирмой JYACC (США) и название продукта расшифровывается как JYACC"s Application Manager. JYACC - не новичок на рынке информационных технологий. Появившись в 1978 году как консалтинговая фирма, работающая в области информационных технологий, в 1985 году JYACC выпустил первую версию JAM. На сегодняшний день поставляется 7-я версия пакета.

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

  • Ядро системы
  • JAM/DBi - модули интерфейса к серверам БД.
  • JAM/RW - генератор отчетов.
  • JAM/CASE - интерфейс к CASE структурного анализа и дизайна.
  • JAM/TPi - интерфейс к монитору транзакций.
  • Jterm - специализированный эмулятор UNIX-терминала.

2.1. Ядро системы

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

2.1.1 Разработка интерфейса

Общепринятое сужение внешнего уровня в информационных системах до экранных форм, отчетов и деловой графики, а также определение стандарта CUA (Common User Access - общий доступ пользователя), в котором описаны базовые интерфейсные конструкции, позволило уйти от 3GL-технологии разработки внешнего уровня, при котором его реализация описывалась в виде текста на каком-либо языке программирования. При использовании JAM разработка внешнего уровня является визуальным проектированием и сводится по сути дела к рисованию на экране компьютера экранных форм путем размещения на них интерфейсных конструкций CUA и определению экранных полей ввода/вывода информации. Такая технология имеет совершенно очевидные преимущества по сравнению с 3GL-разработкой. При использовании визуального проектирования от разработчика уже не требуется профессиональное владение программированием, поэтому разрабатывать интерфейс с помощью таких систем могут даже конечные пользователи, имеющие лишь общие навыки работы на компьютере и изучившие основы этой системы разработки.

Следующее, собственно основное, преимущество заключается в резком повышении производительности труда разработчика. В случае 3GL-программирования создание требуемых интерфейсных элементов (окна, меню, кнопки, поля и т.д.) производится путем вызова в тексте 3GL-программы тех или иных процедур или функций из интерфейсной библиотеки, в случае, если такие библиотеки имеются в распоряжении программиста. Если библиотек нет, то приходится их или приобретать, или разрабатывать самостоятельно, что представляет собой очень сложную задачу. Но даже в случае наличия у разработчика интерфейсных библиотек процесс создания приложения является достаточно сложным. В качестве доказательства этого достаточно привести наиболее современные интерфейсные системы - X Window. Практически все функции, реализующие те или иные элементы интерфейса, являются многопараметрическими и требуют от 3GL-программиста высокой квалификации для полноценного их использования. Данная ситуация усугубляется тем, что идеология программирования в среде X Window базируется на многозадачной основе подобных систем и требует от программиста, имевшего дело только с ОС MS-DOS (каких в настоящее время большинство), значительных усилий на изучение новой системы и приобретение нового опыта. Данные особенности относятся только к одной из стадий 3GL-программирования - созданию исходного текста приложения. Последующие стадии итеративного процесса программирования - компиляция, сборка, отладка. И если время компиляции и сборки можно принять за практически постоянную величину, то отладка приложения является максимально трудоемким процессом, несмотря на современные символические отладчики. После обнаружения и локализации ошибок разработчик возвращается фактически к первой стадии - работе с исходным текстом. И хотя в последние 10-15 лет предлагалось несколько методик программирования - разработка сверху-вниз, структурное программирование, объектно-ориентированное программирование - ни одна из этих методик, как бы широко они не были распространены, не дает гарантий так называемого надежного, т.е. безошибочного, программирования.

2.1.2 Объектно-ориентированное проектирование в JAM

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

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

2.1.3 Открытость

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

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

Но значение фактора гибкости в совокупности с общей тенденцией развития программного обеспечения в направлении открытых систем привело к тому, что JAM не ограничивает разработчика предопределенным набором возможностей, а предоставляет ему средства по расширению возможностей сверх встроенного набора как разрабатываемых приложений, так и самого инструментария. Таким средством в JAM является встроенный язык программирования 3-го поколения JPL (JAM Procedural Language), с помощью которого в случае необходимости можно написать один или несколько модулей, реализующие специфические действия. Данный язык является интерпретируемым, что упрощает отладку. Существует возможность обмена информацией между средой визуально построенного приложения и такими модулями. Кроме того, в JAM помимо встроенного интерпретируемого языка реализована возможность подключения внешних модулей, написанных на каком-либо компилируемом языке 3-го поколения, совместимым по вызовам функций с C. Таким образом, открытость JAM делает его универсальной системой, которая в большинстве реальных прикладных задач (учрежденческие АСУ, бизнес-системы, системы принятия решений, информационно-поисковые системы и т.д.) позволяет избежать традиционного программирования с вытекающим отсюда повышением производительности труда разработчиков и удобством сопровождения, а при наличии уникальных операций дают возможность реализовать их с помощью 3GL, решив остальные части задачи - реализация внешнего уровня и связь его с концептуальным - путем визуального проектирования.

2.1.4 Реализация логики работы приложения

С точки зрения реализации логики приложения JAM является событийно-ориентированной системой. Это означает следующее: в JAM определен набор событий, включающий открытие и закрытие окон, нажатие клавиши клавиатуры, срабатывание системного таймера, получение и передача управления (так называемого фокуса) каждым элементом экрана. Разработчик реализует логику приложения путем определения обработчика каждого события. Например, обработчик события "нажатие кнопки на экране" (мышью или с помощью клавиатуры) может открыть следующее экранное окно. Другой пример, наверное наиболее популярный, - нажатие клавиши F1. Обработчик такого события открывает окно с текстом подсказки. Более серьезный пример - ввод информации в экранное поле из классификатора. Когда экранное поле, требующее ввода, становится активным (т.е. курсор переходит в это поле), оно получает фокус. Обработчик этого события открывает окно с полем типа "скроллируемый массив", которое автоматически заполняется информацией из классификатора БД. Пользователь выбирает требуемый вариант ввода нажатием клавиши "Enter" на нужном элементе. Обработчик этого события закрывает окно с массивом классификатора и возвращает выбранное значение в исходное поле.

Обработчиком событий в JAM могут быть как встроенные функции JAM, так и функции (так называемые hook-функции), написанные разработчиком на C или JPL. Набор встроенных функций достаточно широк и включает в себя более 200 функций различного назначения. Среди них довольно интересны функции динамического изменения свойств объектов, из которых построено приложение. Следует отметить, что встроенные функции доступны для вызовов из hook-функций, написанных как на JPL, так и на C.

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

2.2. Взаимодействие с СУБД

Непосредственное взаимодействие с сервером БД реализует дополнительная компонента JAM - JAM/DBi (Data Base interface). При наличии JAM/DBi разработчик получает возможности, более удобные, чем при использовании так называемого "встроенного SQL" (embedded SQL). При использовании традиционной (3GL) технологии разработки приложений БД разработчик располагает в лучшем случае возможностью использовать в исходном тексте приложения запросы на языке манипулирования данными используемой РСУБД (как правило, это расширенный SQL), которые транслируются специальным препроцессором в конструкции используемого языка 3-го поколения (на практике - это вызовы функций методов доступа к БД). В худшем случае разработчик вынужден самостоятельно использовать эти вызовы. Таким образом 3GL-технология реализации внутреннего уровня и его взаимодействия с внешним и концептуальным уровнями приложения имеет такую же высокую трудоемкость, что и реализация внешнего уровня, так как основа разработки остается та же - 3GL-программирование.

Реализация взаимодействия внутреннего и концептуального уровней в системах, построенных с помощью JAM, в конечном счете базируется на тех же библиотеках методов доступа к СУБД. Такой подход очевидно оправдан, так как наиболее эффективные и корректные методы доступа к конкретной СУБД могут быть созданы только фирмой-разработчиком этой СУБД. Но использование этих библиотек происходит в ряде случаев иначе. Если рассмотреть способы реализации взаимодействия внутреннего и концептуального уровней в JAM, то все они разделяются на два класса: так называемые ручные и автоматические. При ручном способе разработчик приложения самостоятельно пишет запросы на SQL, в которых как источниками, так и адресатами приема результатов выполнения запроса могут быть как интерфейсные элементы визуально спроектированного внешнего уровня, так и внутренние, невидимые для конечного пользователя переменные. Следует отметить, что SQL в качестве языка манипулирования данными выбран практически во всех инструментальных системах, предоставляющих разработчику ручной режим создания запросов. Автоматический режим, реализуемый Менеджером Транзакций JAM, стал возможен благодаря во-первых тому, что большинство современных РСУБД позволяют восстановить логическую модель по структуре БД, а именно - определить родительские и дочерние таблицы, типы связей между ними, ограничения по различным типам целостности БД (ссылочная, прикладная и т.д.). Во-вторых, автоматическая генерация запросов осуществима для типовых и наиболее распространенных видов операций с БД, так называемых QBE (Query By Example - запросы по образцу), с учетом достаточно сложных взаимосвязей между таблицами БД и автоматическим управлением атрибутами экранных полей ввода/вывода информации в зависимости от вида транзакции (чтение, запись и т.д.), в которой участвует сгенерированный запрос.

На сегодняшний день JAM позволяет строить приложения для работы более чем с 20 РСУБД. В их числе ORACLE, Informix, Sybase, Ingres, InterBase, NetWare SQL Server, Rdb, DB2, ODBC-совместимые СУБД и др. Кроме того, JAM обладает собственной встроенной РСУБД - JDB. Это несложная однопользовательская система невысокой производительности, предназначенная в первую очередь для замены на этапе разработки реального сервера БД, если он в силу каких либо причин недоступен. В разработанных приложениях JDB позволяет хранить небольшие объемы личной информации конечного пользователя.

2.3. Генерация отчетов

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

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

Информация, выводимая в отчет JAM/ReportWriter, может детализоваться в подотчетах любой степени вложенности.

Источниками данных отчета являются, во-первых, SQL-запросы, включая сгенерированные Менеджером Транзакций, во-вторых, информация, введенная пользователем в сеансе работы с приложением и, в-третьих, процедуры на C или JPL.

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

Ну и, естественно, в JAM/ReportWriter реализованы возможности, обычные для генераторов отчетов - разбивка на страницы, автоматическое форматирование и выравнивание элементов отчета, использование различных шрифтов и т.п. Выходом отчета могут быть ASCII-текст, PostScript или TrueType (только Windows).

2.4. Взаимодействие с upper-CASE

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

В результате в распоряжении разработчиков проекта имеется согласованная триада "upper-CASE - РСУБД - JAM".

2.5. Взаимодействие с Мониторами Транзакций

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

Но "штатное" использование МТ, т.е. описание сервисов и их вызов из приложений, делается черз 3-GL интерфейс (обычно это C).

При использовании JAM с МТ взаимодействие разработчиков с МТ более удобно, чем традиционное их использование через 3GL-интерфейс. В состав JAM входят 2 модуля к МТ: JAM/TPi-Client и JAM/TPi-Server.

JAM/TPi-Client позволяет уйти от 3GL-технологии вызова сервисов МТ. Теперь любой из сервисов или их набор могут быть методами объектов JAM-приложения.

JAM/TPi-Server позволяет строить сами сервисы МТ, которые реализуют доступ к БД. Эти сервисы определяются уже не с помощью C, а путем визуального объектно-ориентированного проектирования с использованием и Визуального Репозитория Объектов JAM, и Менеджера Транзакций (интеллектуального автогенератора SQL) JAM.

2.6. Дополнительные возможности JAM

Еще одной чертой JAM, заимствованной у традиционного программирования, является поддержка коллективного режима разработки. Такая поддержка необходима для успешного применения JAM в крупных ИС (корпоративного, регионального, государственного уровня), где созданием ИС занимается коллектив разработчиков. Эта поддержка реализуется в виде контроля доступа различных групп разработчиков к различным компонентам проекта и наиболее ярко выражена в совместном использовании Визуального Репозитория Объектов. Такая возможность существенно повышает надежность самого процесса проектирования и, следовательно, законченной ИС.

Следует также отметить возможность ведения нескольких версий проекта, что характерно для крупных систем. В JAM эта возможность обеспечивается взаимодействием с соответствующими механизмами операционной системы, например в ОС UNIX - SCCS (Source Code Control System - система управления исходным кодом) или PVCS.

3. Переносимость

Отличительной чертой JAM, как представителя класса программного обеспечения 4GL, является высокий уровень переносимости между программно-аппаратными платформами. Требование к минимальным трудозатратам при переносе приложений с платформы на платформу обусловлено несколькими факторами. Во-первых, в силу очевидных причин в любой организации периодически происходит переоснащение принципиально иной вычислительной техникой. Во-вторых, перенос приложений, написанных на языках 3-го поколения, исключительно трудоемок, даже при использовании стандарта языка, обычно ANSI, что, кстати, выполняется очень редко. Основная трудность заключается в основном в переносе интерфейсной части приложения, так как каждая ОС имеет свои, существенно отличные от других, особенности интерфейса. Примером могут служить системы Open Look и Motif. Базируясь на протоколе X11 сетевой оконной системы, они в значительной степени несовместимы и процесс переноса требует серьезной адаптации для новой среды. В случае других систем, не базирующихся на едином стандарте, трудности переноса будут еще более серьезными.

При использовании JAM переносимость приложений (естественно, между платформами, поддерживаемыми фирмой-производителем, а их более 100 - MS-DOS/MS-Windows, SunOS, Solaris (i80x86, SPARC), HP-UX, AIX, OS/2, MacOS, VMS/Open VMS, и др.) близка к абсолютной. Может потребоваться лишь "перерисовать" статические текстовые поля на экранах с русским текстом при переносе между средами DOS-Windows-UNIX. Кроме того, переносимость облегчается тем, что в JAM приложения разрабатываются для виртуальных устройств ввода/вывода (клавиатура, терминал), а отображение физических устройств в виртуальные осуществляется средствами конфигурирования. Таким образом при переносе приложения с платформы на платформу как правило требуется лишь определить соответствие между реальными устройствами ввода/вывода и их логическими представлениями для приложения.

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

4. Заключение.

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