Опыт применения SILVERRUN и JAM при разработке приложений архитектуры клиент-сервер

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

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

1. Пакет CASE-средств SILVERRUN

По желанию заказчика, в качестве SQL-сервера была избрана СУБД Oracle. Таким образом, можно было вести проектирование приложения, пользуясь собственным CASE-средством от Oracle. Тем не менее мы сделали выбор в пользу независимого пакета SILVERRUN. Одним из мотивов в пользу такого выбора послужило то обстоятельство, что SILVERRUN (в дальнейшем SR) не привязан жестко к каким-либо СУБД, давая возможность повторно использовать готовый проект для разработок на других SQL-серверах. "Мост" к каждой СУБД нужно, разумеется, приобретать дополнительно, но стоимость каждого такого моста невелика по сравнению с ценой основных модулей SR. Интерфейс к каждой (или, по крайней мере, к большинству) из более чем десятка распространенных СУБД (назову, к примеру, Oracle, Progress, Ingres, Sybase, DB2 и т. д.) включает в себя средства прямого и обратного проектирования, что позволяет не только сгенерировать базу в соответствии с разработанным проектом (прямая задача), но и воссоздать структуру и свойства реляционной СУБД (включая тексты триггеров реляционной целостности) по "горячей" базе (обратная задача). Это свойство является чрезвычайно важным при модернизации действующих систем в тех случаях, когда разработка велась достаточно давно, переделки вносились "на ходу", а ни подробной документации, ни живых разработчиков в наличии нет. В последней появившейся версии SR есть возможность прямого подключения к SQL-серверу для считывания информации и воссоздания схемы действующей базы данных. Но эту особенность SR мне проверить на практике пока не удалось. Кроме интерфейсов к СУБД SR может взаимодействовать и с некоторыми средствами программирования приложений (например популярным пакетом PowerBuilder).

Пакет SR состоит из четырех практически независимых модулей (не считая моста к СУБД), каждый из которых может функционировать и как отдельное приложение, и в комплексе с другими.

Наибольший интерес для разработчиков-программистов представляет модуль RDM (Relational Data Modeling - Реляционные Модели Данных), результатом работы которого и является собственно проект реляционной СУБД; этот проект служит исходными данными для моста к выбранному SQL-серверу для генерации SQL-кода создания таблиц, ключей, триггеров и т. п.

Как и другие модули SR, он построен в виде графической оболочки с достаточно удобным и дружественным интерфейсом. Графическое представление существует почти для всех основных элементов проектируемой базы: таблиц, связей, первичных и внешних ключей, правил поддержки реляционной целостности и т. п. SR поддерживает наиболее распространенные системы обозначений для реляционных баз, так что пользователь, имеющий опыт в "бумажном" проектировании баз, увидит привычное для себя представление. В течение всей работы над проектом (включая составление отчета) можно пользоваться псевдонимами для обозначения всех объектов схемы, что практически снимает проблему языкового барьера при демонстрации проекта заказчику. Более того, при желании можно составлять отчеты по готовому проекту, пользуясь собственными шаблонами, - для этого лишь необходимо экспортировать проект в формат текстового файла типа SDF, а затем воспользоваться развитыми средствами генерации отчетов таких распространенных СУБД, как FoxPro, Clarion, Dbase...

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

Когда разработку структурной модели базы ведет программист или, по крайней мере, пользователь, имеющий большой опыт работы с СУБД, модуль RDM с мостом к SQL-серверу может оказаться достаточным для полной разработки проекта. Однако в большинстве случаев слабым местом в проектировании оказывается стык между специалистом в предметной области и системным аналитиком. Еще один модуль, входящий в состав комплекта SR, - модуль ERX (Entity-Relationship, или Сущность-Связь ) - может оказать значительную помощь на этом этапе. По существу, ERX - это тоже средство построения реляционных моделей. Модель, построенная в ERX, не обязательно должна иметь нормализованную форму, в частности, связи между таблицами (в терминологии ERX - сущностями) могут сами иметь атрибуты, допустимы связи типа "многие-ко-многим". Модуль ERX снабжен экспертной системой, отвечая на вопросы которой, пользователь легко может вычленить скрытые сущности (практически система это сделает сама) и нормализовать связи. Созданный ERX файл может быть передан в RDM для окончательной доработки. Таким образом, в разработке проекта приложения может с самого начала принимать участие специалист, вовсе не знакомый с теорией баз данных и принципами их проектирования.

Третий модуль комплекта SR - BPM (Business Process Modeler - Моделирование Бизнес-Правил) занимает несколько изолированное положение. В настоящее время он может использоваться только для анализа и документирования деловых правил обработки информации в приложении. При этом заложенные в модуле концепции создания, объединения и каскадирования подсхем позволяют, в принципе, достичь сколь угодно высокой степени детализации описания алгоритмов, вплоть до подробных блок-схем отдельных программных модулей. Однако часть информации, закладываемой в проект BPM, могла бы быть применена и при генерации собственно базы данных. Речь идет о следующем.

В схемах BPM основными объектами являются, по существу, рабочие места (или группы рабочих мест) исполнителей и выполняемые на них операции. При этом, в зависимости от степени детализации подсхемы, для каждого рабочего места и выполняемой операции указываются входящая и исходящая информация, в том числе и хранимая в таблицах базы данных. Пользуясь терминологией SQL-серверов, можно сказать, что тем самым определены ролевые функции исполнителей в СУБД, и эти данные можно было бы непосредственно использовать при генерации базы для определения ролевых прав доступа к таблицам базы. В действующих версиях BPM ничего подобного не делается, и остается надеяться, что такая нехитрая процедура будет реализована разработчиками SR в последующих версиях.

Четвертый модуль SR - WRM (Workgroup Repository Manager), или модуль управления репозитарием, строго говоря, необходим лишь при разработке проекта большими коллективами. Этот модуль не дает каких-то новых возможностей индивидуальному проектировщику, поскольку он предназначен исключительно для аккуратного обобщения результатов, полученных при параллельной разработке отдельных частей большого проекта.

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

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

2. Генератор приложений JAM

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

JAM не пользуется ODBC для установления связи с SQL-серверами. Вместо этого в исполняемый модуль (как в среде разработки, так и в run-time-модуле) встроены "родные" библиотеки вызова соответствующих функций клиентской части той СУБД, с которой вы намерены работать. В один модуль можно встроить поддержку нескольких СУБД, что аналогично подключению нескольких драйверов ODBC. Использование "родных" библиотек дает некоторый выигрыш в скорости обработки запросов и освобождает от ограничений, накладываемых ODBC. С другой стороны, при переходе на другой SQL-сервер необходимо заново собирать исполняемый модуль приложения. Повторная сборка в любом случае окажется необходимой при переходе на другую платформу в клиентской части приложения - JAM поддерживает множество аппаратных и операционных платформ, начиная от PC с Windows или OS/2 интерфейсом, Mac и вплоть до Unix в различных аппаратных версиях. В последних версиях JAM отпала поддержка текстового режима MS DOS, но его перестают поддерживать также и некоторые SQL-серверы.

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

Репозитарий JAM заполняется не только созданными разработчиком формами, но и импортированными из базы таблицами, которые приобретают вид простейшей экранной формы. В последней версии JAM 7.0 есть Мастер, позволяющий быстро создать экран для работы с отдельной таблицей или несколькими связанными таблицами.

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

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

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

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

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

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

При импорте таблиц в репозитарий JAM каждой колонке назначается по умолчанию определенный тип внутренних данных. Поскольку JAM поддерживает различные аппаратные платформы и операционные системы, этот перечень типов данных нужно понимать достаточно условно. Тем не менее оказывается, что способ обработки данных при выборке их из таблиц зависит от назначенного (хотя бы и условно) типа. Так, числовым колонкам Oracle (тип NUMBER (m,n)) ставится в соответствие тип DOUBLE (что естественно с точки зрения C). Но при этом число значащих цифр в данных Oracle может быть до 38, и JAM молчаливо проставляет (или позволяет проставить) ту же значность импортированному объекту. При выборке данных, естественно, воспроизводятся лишь 16 значащих цифр, как и положено типу DOUBLE. Невнимательный пользователь узнает об этом только по каким-либо известным ему с высокой точностью данным.

Природа другого "прокола" менее понятна. В Oracle, как и в других СУБД, имеющих поддержку различных кодовых таблиц, есть тип данных RAW, полностью аналогичных символьным, но не подлежащих перекодировке при транспортировке между разными кодовыми таблицами (это может быть, например, графический образ). При импорте в JAM этим данным назначается специальный тип Hex Dec, и при выборке одной строки с такими данными никаких недоразумений не происходит. Однако стоит выбрать группу строк в массив (или список) объектов JAM, как обнаруживается, что только некоторые строки выбраны правильно, а в большую часть переменных попали совершенно произвольные значения (чаще всего - дубликаты правильно выбранных строк).

К счастью, эти ловушки сравнительно легко обходятся средствами самого JAM. Так, в указанных случаях достаточно назначить переменным тип CHARACTER (в который они в конечном итоге все равно преобразуются), как все становится на свои места. В других случаях (например General Protection Fault при отработке некоторых функций) есть альтернативные методы в собственных библиотеках JAM. В скором времени должна появиться новая версия 8.0, в которой замеченные ошибки будет устранены.

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