Программные продукты и системы

Большое количество программных продуктов, созданных в прошлом для работы в MS DOS, работают и по сей день, вызывая у пользователей и разработчиков желание перепрограммировать их с помощью современных инструментальных средств MS Windows или иной операционной системы.

Когда компьютеры начали оснащаться дисплеями [1], языки программирования высокого уровня не имели процедур для работы с ними. Однако неодолимое желание программистов задействовать дисплеи в своих программах нашло выход в создании нужных процедур на языке ассемблера [2]. К моменту появления персональных ЭВМ у программистов уже имелись наработанные принципы использования алфавитно-цифровых дисплеев в своих разработках.

Позже в языки программирования высокого уровня стали добавлять графические пакеты или процедуры для работы с дисплеями [3]. Но не все программисты спешили переделывать под новые инструменты программирования свои старые программы и создавать новые [4].

Однако со временем конкурентная борьба между небольшими коллективами созателей и крупными фирмами-разработчиками программных инструментов привела к победе последних. Этот период совпал с закатом операционной системы MS DOS и началом глобального господства MS Windows с ее гигантской инфраструктурой программных инструментов.

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

Естественно, речь идет о крупных проектах, перед которыми стоит проблема переноса их на новую операционную среду и новые инструментальные средства: базы данных и средства разработки геоинформационных систем (ГИС). Главное обстоятельство, которое нужно учитывать при переделке проекта, – это выполнен ли старый проект с помощью инструмента, которого нет в новой операционной системе.

Распространенные языки программирования высокого уровня, например Фортран и QBasic, работающие в MS DOS, имеют конвертеры для преобразования исходных текстов программ на современные языки программирования С++ и Visual Basic. С их помощью переделка проектов существенно упрощается. От программистов требуется хорошее знание современного языка, на который переделывается проект, а освоить при необходимости операторы старого языка, на котором был выполнен проект, ему не составит труда.

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

Конвертер проектов конвертирует и старый проект, и средства старого инструмента, использованные при работе проекта.

Создание конвертера проектов – работа, требующая знания инструментария, использованного при создании старого проекта, языка (языков) программирования, языка нового проекта, на который ориентируется конвертер, и тех современных СУБД и ГИС, которые предполагается использовать в новых проектах. Работа по созданию конвертера проектов интересна, трудоемка и требует достаточно высокой квалификации исполнителей. Очевидно, что выполнение подобной работы имеет смысл, когда объем конвертируемых проектов достаточно велик.

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

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

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

–      основная работа состоит в создании современными средствами библиотеки процедур или классов объектов с их свойствами и методами, эквивалентными использованным в проектах возможностям старого инструментального средства; эти процедуры или методы и свойства объектов классов будут использоваться, главным образом, дисплейными формами новых проектов;

–      табличные данные, переносимые в новую базу данных, перекодируются конвертером в соответствующий формат, поэтому процедуры и методы, работающие с ними в новом проекте, не потребуют перекодировки данных во время работы нового проекта;

–      процедуры и исполняемые файлы старых проектов, отсутствующие в старом инструментарии, необходимо перепрограммировать вручную или с помощью языковых конвертеров, создавая дополнительные модули в новых проектах;

–      для невидимых форм (темных кадров) старых проектов, предназначенных только для выполнения неких функций, не связанных с выдачей на дисплей соответствующих форм, конвертер для ускорения работы нового проекта вместо невидимых форм должен создавать специальные процедуры типа Load – Unload в дополнительных модулях проекта; процедуры в новом проекте вызываются для исполнения значительно быстрее, чем создаются объекты-формы;

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

–      процедуры старого инструментария, реализующие функции ГИС, заменяются их аналогами из выбранной ГИС.

Инструментальное средство – система Фрагмент – было создано в 80-х годах прошлого века в среде MS DOS с использованием языков Фортран [5] и ассемблера [6]. С его помощью были выполнены проекты различного назначения, среди которых – проекты для управления производством в нефтехимии, нефтепереработке, ГИС в цементной промышленности [7], для городского теплоснабжения [8] и т.п.

Возможности системы Фрагмент достаточно обширны:

–      создание и ведение реляционных баз данных с соответствующими средствами импорта-экспорта в DBF-формате;

–      наличие средств разработки диалогового интерфейса с пользователем проекта;

–      наличие средств для создания геоинформационных элементов проекта (ввод и редактирование карт, импорт-экспорт их в DXF-формате, связь с базами данных, визуализация файлов инфракрасного сканирования поверхности в совокупности с картой местности и с расположенными на ней объектами проекта).

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

Принципы разработки конвертера

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

Новый проект, как правило, полностью работоспособный, функционально эквивалентный устаревшему проекту, только выполненный на новых средствах.

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

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

При разработке конвертера, о котором идет речь в статье, за основу были приняты следующие принципиальные решения (см. рис.).

·       В качестве языка программирования выбран язык MS Visual Basic (VB) [9]. Важным обстоятельством VB-проектов является то, что все компоненты проекта (сам файл проекта, файлы его форм и модулей) представляются в символьном виде с хорошо документированной структурой, что позволяет конвертеру собирать, например, формы из постоянных файлов-заготовок, содержащих, в частности, некоторые referens-ссылки, и переменных частей, генерируемых конвертером автоматически. Важно то, что в качестве языка разработки приложений в MS Office используется родственный VB язык VBA [10].

Основная сложность при создании конвертера состоит в создании библиотеки процедур или классов объектов с их свойствами и методами (в дальнейшем для краткости – процедуры), эквивалентными старому инструментальному средству в части тех процедур, которые используются при работе новых проектов.

Наряду с VB в качестве языка программирования может быть выбран и иной язык в зависимости от предпочтений разработчиков.

·       В качестве новой СУБД выбран MS Office Access [11]. Если возможности новой СУБД недостаточны, например, для многопользовательской работы или для работы с большими объемами информации, то замена ее на более мощную может быть выполнена на последующих, ручных, этапах работы, в некоторых случаях достаточно просто, например, при переходе на SQL Server.

Таблицы старой БД переносятся конвертером в таблицы новой базы Access. При переносе выполняется перекодирование из кодировки MS DOS в кодировку MS Windows столбцов таблиц, а также имен таблиц и имен их столбцов с учетом того, что в Access в именах не учитывается регистр символов, а в старом инструментальном средстве регистр символов учитывался.

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

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

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

Мы выбрали ГИС Панорама [12, 13]. Многие ее средства бесплатно можно скачать в Интернете и опробовать, другие доступны за умеренную плату.

Особенности и ограничения конвертера Фрагмент-проектов

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

Процедуры системы Фрагмент, используемые при выполнении проектов, были перепрограммированы в соответствующий стандартный модуль конвертера в период разработки конвертера. Дополнительные процедуры и исполняемые EXE-файлы переписывались вручную в соответствующий стандартный модуль или DLL нового проекта в период конвертации или после него.

Если старый проект имел функции ГИС, то в новый проект включались соответствующие стандартные модули с процедурами ГИС Панорама.

БД. В системе Фрагмент БД – это файл, состоящий из частей (фрагментов), содержащих как сами данные, так и диалоги интерфейса с пользователем проекта. Данные могли быть двух видов: таблицы и данные произвольной структуры. Диалоги интерфейса представлялись в базе фрагментами с данными стандартной для диалогов структуры.

Конвертация старого проекта происходит в два этапа.

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

Далее конвертер преобразует файл базы данных старого проекта в MDB-файл MS Access, куда конвертер помещает таблицы, и подпапку RAB с файлами, создаваемыми из фрагментов произвольной структуры и файлов диалогов. В качестве префикса имена файлов в папке RAB содержат имя файла базы системы Фрагмент. За префиксом идет имя фрагмента. Для имен фрагментов, отличающихся от уже конвертированных лишь регистрами символов, добавляется некий суффикс, придающий им уникальность. Уникальность имен файлов позволяет располагать файлы в одной папке RAB на диске.

Аналогично с помощью суффиксов обеспечивается и уникальность имен таблиц в MDB-файле базы Access. Имя MDB-файла базы Access составляется из имени файла базы Фрагмент и расширения MDB.

Естественно, все имена имеют кодировку MS Windows.

На втором этапе конвертации создается сам проект.

Создаваемый конвертером проект. В корневой папке, заданной пользователем на первом этапе конвертации, помещаются VBP-файл нового проекта, MDB-файл базы MS Access, сгенерированные формы и стандартные модули проекта. В подпапке RAB содержатся файлы, полученные из фрагментов произвольной структуры и фрагментов-диалогов. На втором этапе конвертации из файлов фрагментов-диалогов конвертером создаются формы (FRM-файлы) нового проекта. Файлы данных из папки RAB используются формами и процедурами модулей нового проекта уже во время работы созданного нового проекта.

Для выполнения функций ГИС в новом проекте используются файлы карт и прочие файлы, помещаемые конвертером в подпапку Kart.

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

Диалоги. В системе Фрагмент диалог состоит из разделов, а раздел из кадров, появляющихся на дисплее. Перед появлением кадра из базы вводятся данные для полей кадра и для выполняющихся перед появлением кадра процедур. При закрытии кадра выполняются некоторые процедуры и производится запись в базу измененных в кадре данных. При конвертации старого диалога в новом проекте создаются соответствующие формы – FRM-файлы. Каждый кадр диалога Фрагмент преобразуется конвертером в свой FRM-файл проекта со своими процедурами обработки событий формы Form_Load, Form_Unload и пр.

Таблица, виртуальная (из нескольких таблиц в базе) или реальная (из одной таблицы), представляется в FRM-файле нового проекта элементом управления DataGrid.

Вычисления, привязанные к кадру диалога, при конвертации преобразуются в операторы процедуры Form_Load-формы. Операции, выполняемые при закрытии кадра диалога, преобразуются в операторы процедуры Form_Unload-формы. В упомянутых процедурах производятся, соответственно, ввод данных из таблиц MDB-файла и файлов RAB для полей формы и запись в таблицы MDB-файла и в файлы RAB измененных в форме данных.

Вследствие ограниченности размера процедур, привязываемых к кадру системы Фрагмент, для выполнения вычислительных операций большого объема использовались темные кадры, предназначенные только для выполнения некоторых операций без появления самого кадра на дисплее. Таких кадров в диалогах бывает достаточно много. При конвертировании для них принципиально не создаются соответствующие невидимые FRM-формы проекта, а соответствующие процедуры Form_Lo­ad и Form_Unload помещаются в стандартный модуль проекта ModuleRab. Это существенно повышает скорость выполнения проекта из-за того, что создание соответствующих объектов-форм заменяется вызовом процедур.

Условные и безусловные переходы между формами нового проекта осуществляются с помощью вспомогательных процедур переходов, помещаемых в стандартный модуль проекта ModuleViz, и специальных команд, вставляемых конвертером в процедуры Form_Unload.

При наличии большого количества невидимых форм в циклах прием с заменой невидимых форм вызовами соответствующих процедур существенно ускоряет работу созданного проекта. Так, например, в первом варианте конвертера в созданном им проекте, в котором последовательно из таблицы с помощью цепочки невидимых FRM-форм отрисовывались на карте несколько тысяч геологических скважин и бровок, на работу уходило 40 минут на машине с тактовой частотой 534 МГц и 256 МБ ОЗУ. В проекте, созданном усовершенствованным конвертером с упомянутыми модулями ModuleRab и ModuleViz, работа выполнялась за 7 минут.

Стандартные модули проекта. Конвертер создает несколько стандартных модулей проекта.

О ModuleRab и ModuleViz было сказано выше. Они генерируются конвертером для невидимых форм нового проекта.

Стандартный модуль ModuleFR содержит переписанные с языков Фортран и ассемблера на Visual Basic при создании конвертера процедуры самой системы Фрагмент, которые используются при работе нового проекта. При конвертации этот модуль копируется в каждый новый проект без изменений.

Стандартные модули F_Mapapix, F_Pan_GIS и Mapprint содержат некоторые процедуры ГИС Панорама, дополненные специфическими для функций системы Фрагмент процедурами. Они тоже копируются в каждый новый проект в неизменном виде.

Кроме того, в системную папку Windows устанавливаются библиотеки ГИС Панорама.

Создание EXE-файла нового проекта. При создании EXE-файла нового проекта может возникнуть ошибка компилятора, связанная с большим количеством процедур в модулях ModuleRab и ModuleViz, заменяющих невидимые формы в новом проекте. В этом случае достаточно вручную разбить эти модули на 2-3 части.

Таким образом, изложенные принципы создания конвертера проектов, выполненных в среде MS DOS с помощью специализированного инструментария, отработаны на примере разработки конвертера проектов, выполненных с применением инструментального средства – системы Фрагмент, и подтвердили свою работоспособность.

Создание конвертера оправдано, когда затраты на его разработку не превышают трудозатрат на прямое перепрограммирование проектов, кроме того, создание конвертера является более интеллектуальной и интересной работой по сравнению с перепрограммированием и требует участия в работе специалистов высокого уровня.

Литература

1.     Диалоговые устройства отображения информации на электронно-лучевых трубках; [под ред. М.К. Сулима]. М.: Статистика, 1977. 184 с.

2.     Зенков В.В. Диалоговая система оперативного управления производством // Управляющие системы и машины. 1979. № 2. С. 98–101.

3.     Баяковский Ю.М., Галактионов В.А., Михайлова Т.Н. ГРАФОР. Графическое расширение Фортрана. М.: Наука. Глав. ред. ФИЗМАТЛИТ, 1985. 288 с.

4.     Зенков В.В. Диалоговая система ФРАГМЕНТ для работы с данными // Управляющие системы и машины. 1980. № 4. С. 68–72.

5.     Соловьев П.В. Fortran для персонального компьютера. М.: Арист, 1991. 223 с.

6.     Новиков М.Г. Программирование на языке ассемблера под MS-DOS. URL: http://novikovmaxim.narod.ru/index.htm? http://novikovmaxim.narod.ru/statyi/ur_progr/asm_dos/assbook1.htm (дата обращения: 07.10.14).

7.     Юрченко В.Е., Поляков О.А., Степанов А.Е. Геолого-маркшейдерская компьютерная технология «АНКАР» – опыт эксплуатации на различных предприятиях // ВЮСМ-2000: сб. тез. Всерос. симпоз. М., 2000. С. 34–35.

8.     Зенков В.В., Добротворцев Ю.М., Паньшин А.С. и др. Справочная система для районных теплосетей // Приборы и системы управления. 1998. № 5. С. 56–59.

9.     Visual Basic 6.0. Наиболее полное руководство для профессиональной работы в среде Visial Basic 6.0. СПб: БХВ-Петербург, 2003. 950 с.

10.  Михеев Р. VBA и программирование в MS Office для пользователей. СПб: БХВ-Петербург, 2006. 361 с.

11.  Элисон Балтер. Microsoft Office Access 2007: профессиональное программирование. СПб: Вильямс, 2009. 1296 с.

12.  Причины, по которым стоит выбрать продукт «Панорама». URL: http://loi.sscc.ru/gis/panorama/item.htm (дата обращения: 07.10.14).

13.  КБ ПАНОРАМА. Геоинформационные технологии. ГИС «Панорама». URL: http://www.gisinfo.ru (дата обращения: 07.10.14).