Базы данных xBase и как с ними бороться
Андрей Терехов, Виталий Гордеев 
Плывет «Клиппер»...
Российское программное обеспечение имеет по-своему уникальную историю. В конце 80-х, сразу же после разнообразных политических преобразований, в страну хлынул неудержимый поток персональных компьютеров (тогда это были в основном PC XT), а бурно развивающийся частный сектор предпринимательства обусловил потребность в огромном количестве программ.
В течение нескольких лет создание небольших бухгалтерских и производственных систем стало воистину «золотой жилой» для самых «рыночно-ориентированных» программистов. Чаще всего такие приложения создавались на базе ПО Clipper, FoxPro или Clarion (так называемые xBase-системы). Затем на рынке появились крупные фирмы с типовыми пакетами, и вопрос во многом потерял свою актуальность.
Однако период «кустарного производства» не прошел бесследно. Многие фирмы до сих пор используют приложения, созданные в начале 90-х. За это время многие из них успели обзавестись собственным штатом программистов, базы данных обросли мегабайтами информации, компьютеры проделали путь от XT до Pentium, но программы остались практически неизменными. Можно сказать, что на российском рынке Clipper-программы выступают в роли «унаследованных систем» (legacy systems). С каждым днем они все меньше соответствуют поставленным задачам, поэтому сопровождать и развивать подобные системы становится все труднее.
Наиболее значительные трудности сопровождения xBase-систем связаны с их файл-серверной архитектурой, что влечет за собой следующие проблемы:
- проблемы безопасности и защиты от несанкционированного доступа к данным;
- невозможность разделения доступа к ресурсам на уровне отдельных записей;
- большой объем пересылаемых данных, а значит, существенная зависимость общей производительности системы от пропускной способности сети;
- постоянно растущие требования к рабочим местам, связанные с тем, что практически все вычисления производятся на клиентских компьютерах.
Все это создает труднопреодолимые препятствия на пути развития и масштабирования системы.
Например, в одном из петербургских банков автору довелось наблюдать работу реальной системы автоматизации внутрихозяйственной деятельности. Система состояла из 120 АРМов, написанных на FoxPro и Clipper. Ежедневным сопровождением системы занимался специальный отдел, причем некоторые АРМы приходилось сопровождать трем-четырем программистам!
Естественно, что в подобных случаях руководство информационных отделов вынуждено всерьез задумываться о переходе на новые технологии.
 |
|
xBase-системы в России
В поле зрения нашей компании проблемы xBase-систем попали сравнительно недавно. Одним из направлений нашей деятельности является реинжиниринг устаревших систем, но, поскольку мы начали свою деятельность в этой области, ориентируясь на западных заказчиков, проблемы настольных баз данных не сразу стали предметом нашего внимания.
Действительно, для западных информационных систем движение от локальных сетей, состоящих из персональных компьютеров, к более сложным сетевым структурам (процесс этот носит название upsizing) не является типичным, скорее, наоборот — значительно чаще происходит движение от мощных централизованных систем на мэйнфреймах к распределенным сетевым приложениям (downsizing). Поэтому особенно надеяться на то, что «заграница нам поможет», не приходится.
В то же время проблемы xBase-систем очень мало обсуждаются на страницах российских компьютерных изданий. Порой возникает ощущение, что подобных проблем просто не существует. Возможно, оправданием такого информационного вакуума явилось хроническое отсутствие у программистов, имеющих дело с CУБД Clipper, времени на чтение журналов или написание писем в редакцию.
Только в конце 1998 года на страницах журнала PC Week появилась статья, посвященная проблемам Clipper [2]. Точнее, в ней описывалась специфическая ошибка, возникавшая при запуске Clipper-программ на процессорах К5 фирмы AMD и последних моделях процессоров Intel. Оказалось, что компилятор «Клиппера» для своих внутренних целей подсчитывает производительность компьютера, и для новейших процессоров этот показатель попросту переполняется.
Для решения данной проблемы в статье предлагались конкретные способы исправления объектных кодов библиотек поддержки «Клиппера». Позднее выяснилось, что компания Computer Associates предлагала и официальную «заплатку» для исправления данной ошибки [3]. Однако сама ситуация и предложенные программистским сообществом пути ее решения очень характерны для xBase-систем, трудности сопровождения которых связаны не только с ветшанием технологий, но и с потерей интереса к ним со стороны самих компаний-разработчиков.
|
|
Назад в будущее
Одним из первых о предоставлении решения для миграции xBase-систем заявило российское представительство компании Informix. Программа, получившая оптимистичное название Gateway to the Future, широко рекламировалась, в том числе и в русле деятельности по решению проблемы 2000 года. В рамках предложения Gateway to the Future компания Informix бесплатно предлагает пользователям пакет программного обеспечения и услуг, с помощью которых данные переносятся из DBF-файлов на Informix Dynamic Server, а прикладные программы на Clipper или Clarion остаются без изменений.
Взаимодействие между программами и данными обеспечивается путем замещения на клиентской стороне драйвера доступа к базам данных Clipper на специально написанный драйвер Informix и использования дополнительных промежуточных компонентов (middleware), поддерживающих доступ к базе данных Informix для нескольких пользователей одновременно.
Таким образом, в процессе миграции двухзвенная система преобразуется в трехзвенную. Это изменение призвано повысить безопасность данных и дать возможность сохранения работоспособности старых компьютеров под управлением MS-DOS. Кроме того, промежуточный компонент, в принципе, может выполнять буферизацию данных, повышая тем самым производительность системы.
Среди основных достоинств описанного подхода компания Informix называет следующие:
- существующие приложения работают сразу же, без изменений;
- не надо заменять существующие ПК, например, на процессоры 286, 386, и т.д.;
- не надо переучивать персонал;
- существует полная поддержка для стандартных унаследованных сред, включая MS-DOS, Windows 3.1, Windows 95.
Тем не менее концепция Gateway to the Future не лишена недостатков, которые, к сожалению, носят принципиальный характер и заключаются в том, что в долгосрочной перспективе миграция такого рода не сулит никаких преимуществ.
Перенос данных из DBF-файлов во внутренний формат сегодня может выполнить любая современная база данных, потому этот шаг не является самостоятельным достижением. А вот программы, созданные на языке Clipper, все равно придется переписывать, и для решения этой проблемы Informix не предлагает никаких средств.
Таким образом, подход компании Informix можно вкратце описать так: «Давайте перенесем ваши данные из xBase-систем именно на нашу платформу, а программы на Clipper вы как-нибудь потом перепишете самостоятельно».
Но это совсем не так просто, как хотелось бы. Несмотря на свою ориентированность на работу с базами данных, Clipper остается достаточно сложным языком программирования, сопоставимым по своим выразительным возможностям с обычными языками разработки приложений.
Поэтому попытки свести проблемы Clipper, Clarion и FoxPro на уровень «чистых» баз данных кажутся нам несостоятельными. Можно провести следующую аналогию. Программы, написанные на Visual Basic и взаимодействующие с базами данных, немногим отличаются от xBase-систем (если не считать более современного интерфейса), однако никому не приходит в голову при миграции с Visual Basic переносить только базу данных, с которой работает приложение, и игнорировать сами программы!
|
|
Реинжиниринг xBase-систем
Итак, мы считаем, что xBase-системы нужно не низводить до уровня чистых баз данных, а поднимать до уровня обычных программных комплексов. На эту мысль наводит, в числе прочего, тот факт, что процедуры взаимодействия xBase-систем с базами данных имеют мало общего с запросами языка SQL и, скорее, напоминают принципы доступа к базам данных, реализованные в DAO (Data Access Objects), включая в себя понятие набора записей, методы перемещения по набору записей и т.п.
Поэтому мы придерживаемся следующей модели переноса xBase-систем:
Такая схема работы реализована в автоматизированном средстве реинжиниринга xBase-систем, входящем в пакет «Сталкер». С его помощью можно автоматизировать основные процессы реинжиниринга приложений, написанных на Clipper и FoxPro: от изучения программ до автоматической генерации текстов программ на С++.
Тем не менее «Сталкер» — это не панацея, и даже с его использованием перенос Clipper-приложений остается трудоемкой и кропотливой работой, отнимающей много времени и сил. Далеко не все можно получить автоматически, поэтому во многих вопросах приходится полагаться на навыки специалиста, выполняющего преобразования. Среди подобных проблем можно выделить следующие.
Трансформация интерфейсов Clipper. Дело в том, что в Clipper операции вывода на экран и считывание с экрана никак не отделялись от прочей функциональности и производились лишь по мере необходимости. Конечно, механизм ввода/вывода Clipper при переносе на новую платформу можно эмулировать, но хотелось бы использовать возможность создания современного графического интерфейса.
К сожалению, для этого в исходных текстах необходимо выделить отдельную часть приложения, отвечающую за интерфейс, а это удается только в тех редких случаях, когда исходная система разрабатывалась с помощью специальных надстроек над Clipper с формализованным видом экрана. Одним из примеров такой надстройки является достаточно популярная в странах бывшего СССР технология FLINT (Formal Language of INteractive Talk), ориентированная на обработку документов анкетного типа и формирование баз данных по типу картотеки.
Кроме того, некоторые функции экранного интерфейса плохо поддаются переносу в графический интерфейс (например, пара функций SAVESCREEN и RESTSCREEN, сохраняющих и восстанавливающих внешний вид некоторой области экрана).
Перевод наиболее сложных конструкций Clipper. Многие конструкции языка Clipper имеют весьма сложный вид. В общем случае для них не удается подобрать удовлетворительные эквиваленты. Чаще всего это связано с интерпретативными особенностями Clipper. Приведем несколько примеров:
1. Богатые возможности макроподстановок времени исполнения:
cMacro := «there»
? «Hello &cMacro»
INPUT cMacro
? &cMacro
Приведенный пример становится еще более запутанным, если учесть, что пользователь может ввести с клавиатуры выражение, содержащее переменные.
2. Проблемы описания таких переменных, как динамическая типизация, или возможность использования динамически создаваемых переменных, таких, например, как в следующем примере исходного текста:
PROCEDURE P1()
PUBLIC A
P2()
RETURN
PROCEDURE P2()
? A
RETURN
В данном примере в процедуре P2 будет выведено значение переменной A, создаваемой лишь во время исполнения оператора PUBLIC в процедуре P1.
3. Существование программных (кодовых) блоков — аналогов переменных процедурного типа в современных языках программирования.
FUNCTION One()
LOCAL myVar
myVar := 10
bBlock := { |number| number + myVar }
NextFunc(bBlock)
RETURN NIL
FUNCTION NextFunc( bBlock )
RETURN (EVAL(bBLock, 200))
В данном примере создается программный блок bBlock с параметром number. Затем этот блок передается в качестве параметра другой функции, в которой происходит его выполнение. Этот вариант сильно отличается от макроподстановки, так как компиляция производится один раз во время создания (в данном примере — во время исполнения операции присваивания), и потому данный механизм работает намного быстрее макроподстановки.
Если же при создании программного блока применялась также и макроподстановка, то программа становится очень неудобной для трансляции в С++.
4. Допустимость применения выражений Clipper в качестве индекса:
INDEX ON PADR(RTRIM(Last) + First, 40) TO CastName
Индексы подобного типа использовались очень широко, так как работали в высшей степени быстро. Однако выразить подобные индексы с помощью традиционных индексов типа GROUP BY не представляется возможным.
Следовательно, для перевода подобных участков исходного текста требуется вмешательство человека. Кроме того, эти и прочие проблемы вызывают потребность в создании для переведенных систем существенной поддержки времени исполнения.
|
|
Заключение
xBase-приложения справедливо считаются «болезнью роста» российского программного рынка, и тем не менее от их функционирования зависит бизнес многих организаций. Только после успешного завершения переноса файл-серверных систем на современную технологическую платформу можно переходить к более амбициозным планам развития корпоративных информационных систем. Но это уже тема другой статьи.
|
|
Литература:
[1] А.Ю.Грачев, Ю.А.Подколзин, Д.В.Серегин. Технология перевода корпоративных информационных систем в среду клиент-сервер // Informix Magazine Russian Edition, осень 1998.
[2] А. Колесов. Clipper-программы могут работать на современных ПК // PC Week/RE, №46, 1998.
[3] А. Колесов. О проблемах Clipper-программ. Точнее — не совсем о них // PC Week/RE Online, 9 марта 1999 года — см. http://www.zdnet.ru/pcweek/news.asp.
КомпьютерПресс 8'1999
