УДК 519.683.2:681.3.02

 

ТЕХНОЛОГИЯ КРОСС-ПЛАТФОРМЕННОЙ РАЗРАБОТКИ МОДУЛЬНЫХ ПРОГРАММНЫХ СИСТЕМ

 

А. М. Князев, Р. Н. Шакиров

Россия, 620219, г. Екатеринбург, ул. Первомайская, 91, ИМаш УрО РАН

(3432)742594

raul@imach.uran.ru

 

Описывается кросс-платформенная технология сборки модульных программных систем (ПС). Сборка и тестирование ПС проводится на платформе MS DOS с помощью встроенных средств развития, обеспечивающих автоматическое формирование функционального описания (ФО) ПС на специализированном  табличном языке. Эксплуатация ПС ведется на любой целевой платформе, для которой разработан интерпретатор ФО. Интерпретатор ФО реализует человеко-машинный интерфейс ПС в соответствии с требованиями целевой платформы.

 

Кросс-платформенная разработка; модульные программные системы; мобильные системы; мобильное программирование.

 

1. Принципы создания кросс-платформенных ПС

Одна из наиболее сложных проблем, возникающих при разработке современных ПС, в частности САПР приборостроения, заключается в необходимости периодического переноса системы на новые аппаратно-программные платформы. Такой перенос редко происходит автоматически, т.к. с появлением новой платформы появляется новый программный интерфейс операционной системы. Поддержка старого программного интерфейса если и сохраняется по соображениям обратной совместимости, то, как правило, не обеспечивает доступ ко всем новым возможностям аппаратуры. Например, интерфейс DPMI, применяемый для разработки 32-разрядных программ MS-DOS, не обеспечивает возможность прямого доступа к видеопамяти в среде Windows, в результате чего перестают работать многие графические библиотеки, такие, как Borland Graphics Interface (BGI).

Одно из решений проблемы мобильности заключается в том, чтобы использовать при программировании только стандартизированные языки и библиотеки. К сожалению, даже такие проработанные стандарты, как ANSI C, не являются функционально полными с точки зрения потребностей практического программирования. Поэтому разработчикам ПС приходится использовать нестандартные решения, предлагаемые коммерческими фирмами. Прекращение поддержки того или иного инструментального средства фирмой-разработчиком или даже прекращение существования самой фирмы является обычной практикой. Разработчики ПС, выбравшие “не тот” инструментарий, оказываются перед необходимостью переработки программного кода.

 

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

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

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

Оболочка ПС создается в рамках фиксированной модели человеко-машинного взаимодействия с использованием встроенных средств развития, обеспечивающих сборку и тестирование ПС без необходимости программирования [1]. Сборка ПС ведется на платформе разработчика и завершается автоматической генерацией формализованного функционального описания (ФО), которое передается на целевую платформу. Для вызова ПС на целевой платформе создается интерпретатор ФО (рис. 1).

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Рис. 1. Технология кросс-платформенной разработки ПС

 

2. Функциональное описание ПС

Функциональное описание ПС представляется в виде набора текстовых файлов, описывающих отдельные компоненты ПС:

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

2.   Проблемные действия представляются в виде схем потоков данных (СПД) между  проблемными модулями. Для каждого действия автоматически формируется исполняющая программа в формате командного файла MS DOS.

3.   Таблицы применяются для ввода инструкций и режимных параметров проблемных модулей.

4.   Инструментальная база данных (ИБД) предназначена для долговременного хранения информации. ИБД представляется в виде иерархии каналов, библиотек, разделов, атрибутов и значений атрибутов. Значения атрибутов хранятся в отдельных файлах. Для доступа конечного пользователя к ИБД применяются библиотечные окна.

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

Перечисленные компоненты (кроме таблиц) подробно рассмотрены в работе  [1]. Здесь рассматривается формат описаний окон и таблиц.

 

2.1.      Описание окна

В файле описания окна первая строка содержит заголовок окна, а последующие строки - описания  пунктов меню (рис.2). Для каждого пункта меню указывается:

-         имя, под которым будет ви­ден данный пункт меню на экране;

-         цвет текста;

-         цвет фона;

-         тип компоненты ПС, вызываемой в данном пункте: D – библиотечное окно, M – проблемное окно, N - процедура, X – действие, T – таблица;

-         имя компоненты, вызываемой в данном пункте (например, для типа M это имя окна следую­щего уровня, для типов N, X  - имена командных файлов).

-         признак запроса подтверждения (1) или ввода символа (2).

          Пункты, тип которых не указан (на рис.2 - это пункты  СХЕМА, УГО, ФУНКЦИЯ), соответствуют вызову значения атрибута ИБД на экран для целей просмотра или коррекции.

 

Графическое редактирование

ВЫБОР            ,0,0,D,S_GET

 

ГР.РЕДАКТОР      ,5,0,N,SGO_NEW

ВОЗВРАТ ЭСКИЗА   ,0,0,N,SGO_

  РЕЖИМ ЧЕРЧЕНИЯ ,0,0,T,TDP

ВОЗВРАТ СХЕМЫ    ,0,0,N,SGO_BS2,1

  СХЕМА          ,0,0, ,BS2

РЕДАКТОР УГО     ,0,0,X,PGO_

  УГО            ,0,0, ,UGO

АНАЛИЗ           ,0,0,N,BS2_BL

  ФУНКЦИЯ        ,0,0, ,BL

КОРРЕКЦИЯ        ,0,0,M,_SCOR

 

МОДЕЛИРОВАНИЕ    ,0,0,M,_SIM

ЗАПИСЬ           ,0,0,D,S_PUT

 

Рис. 2. Пример описания проблемного окна

 

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

 

2.2.      Описание формата таблицы

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

 

Вертикальная разметка

Первые 10 строк формата невидимы при вызове таблицы на экран и определяют правила загрузки и ввода данных для каждого столбца.

Строки 1-6 не используются.

В строке 7 указывается тип столбца:

I     - столбец содержит одинарную линию разграфки;

II   - столбец содержит двойную линию разграфки;

1      - столбец содержит имена параметров;

2       - столбец содержит варианты значений параметров;

+    - столбец доступен для ввода данных;

#    - столбец для отображения данных без возможности их ввода.

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

Строка 8 используется для декларации перебора значений в данном столбце, который выполняется при вводе данных пользователем. Значения разделяются пробелами. Числа могут задаваться диапазоном N1..N2. Если список перебора отсутствует, то ввод данных выполняется с клавиатуры.

В строке 9 расставляются признаки скрытия столбцов (символ -). Скрытые столбцы не будут видны на экране. В этой же строке могут размещаться признаки выравнивания: < - ­влево, > - вправо. Если признак выравнивания не указан, то данные размещаются по центру.

В строке 10 содержится информация о ширине каждого столбца.

 

Горизонтальная разметка

Горизонтальная разметка декларируется в первом столбце, помеченном символом I или II. В столбце сначала размещается символ горизонтальной линии – или =, что указы­вает на верхнюю границу таблицы. Далее помещаются символы – ­или =, отделяющие группы строк.

Строки, доступные для размещения и ввода данных, отмеча­ются символом +, а только для размещения данных - символом #. Если последняя строка отмечена символами + или #, то таблица считается открытой снизу.

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

 

 

║,#       ,#       ,│,+

 ,        ,        , ,0 1 X

 ,<       ,<

=,========,========,=,===

=

 ,Входы   ,Выходы  , ,Наборы

=

+

 

Рис. 3. Пример описания таблицы

 

║,             ,│,                   ,│,1    ,2  ,+      ,║

 

 ,<            , ,                   , ,-    ,-  ,

=,=============,=,===================,=,=====,===,========,=

=

 ,Параметры    , ,Допустимые значения, ,Имя  ,Зн.,Значения

=

+,Алфавит      , ,01                 , ,ALF  ,01

+,генератора   , ,01X                , ,ALF  ,01X

+,             , ,<=>                , ,ALF  ,<=>

+,             , ,Иной               , ,ALF

-

+,Число входов , ,1..20              , ,STR

-

+,Порядок строк, ,Прямой             , ,MODE ,0

+,             , ,Обратный           , ,MODE ,1

=

 

Рис. 4.  Пример описания таблицы параметров

 

3. Реализация интерпретатора ФО для среды Windows

Для испытания технологии кросс-платформенной разработки ПС проводится перенос САПР дискретных систем ДИСКО [2], первоначально разработанной для операционной MS DOS в операционную систему Windows 95/98/NT.

Поскольку Windows содержит в своем составе эмулятор MS DOS, то большинство проблемных модулей САПР ДИСКО работают в этой операционной системе без необходимости какой-либо переработки. Исключение составляют только модули, использующие графический интерфейс BGI. Поэтому основная работа по переносу САПР заключается в создании интерпретатора ФО, реализующего графический человеко-машинный интерфейс в стиле Windows.

Разработка интерпретатора ФО ведется в среде программирования Borland C++ 4.5.

 

3.1.      Окна

Проблемное окно делится на две части: изображение и меню. Интерпретатор ФО считывает файл с изображением и файл с описанием окна, формирует окно и выводит его на экран.

Пример проблемного окна, соответствующего описанию на рис.2, приведен на рис. 5. В левую часть окна загружено псевдографическое изображение, а в правой части сформировано меню.

При выборе пунктов ВЫБОР и ЗАПИСЬ вызывается библиотечное окно, в котором пользователь имеет возможность извлекать или сохранять информацию в ИБД. При этом сначала выбирается используемая библиотека, а затем – требуемый раздел, причем список доступных разделов сопровождается меню, с помощью которого можно создавать, удалять, копировать разделы и выполнять другие действия. Пример библиотечного окна приведен на рис. 6.

 

 

 

 


Рис. 5. Пример проблемного окна

 

 



Рис. 6. Пример библиотечного окна

 


3.2.      Таблицы

Таблицы строятся на основе описания формата таблицы и вызываются на фоне текущего проблемного или библиотечного окна. Примеры таблиц, соответствующих форматам на рис. 3 и 4, приведены на рис 7 и 8.

 

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

 

 

 

 

 

Входы

Выходы 

Наборы

NR

 

1

 

 

 

 

 

 

 

C

 

0

1

0

1

0

1

 

 

D

 

1

1

0

0

1

1

 

 

NS

 

1

 

 

 

 

 

 

 

 

Q

 

 

 

 

 

 

 

 

 
NQ

 

 

 

 

 

 

 

 

 

Рис. 7. Пример таблицы

 

 

Параметры

Допустимые значения

Значения

Алфавит

01

 

генератора

01X

 

 

<=>

 

 

Иной

01Z

Число входов

1..20

3

Порядок строк

Прямой

<——

 

Обратный

 

Рис. 8. Пример таблицы параметров

 

3.3.      Настройка человеко-машинного интерфейса

Интерпретатор ФО позволяет конечному пользователю настраивать  некоторые параметры интерфейса:

-     вид окон и таблиц в программе: обычные или рельефные;

-     тип используемого шрифта (растровый или TrueType) и его начертание (обычный или жирный);

-     раскраска отдельных элементов окон и таблиц.

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

 

Литература

1.        В.П.Чистов, Р.Н.Шакиров. Оболочка модульных программных систем со встроенными средствами развития // Автоматизация проектирования дискретных систем: Докл. III Междунар. конф. Минск, 1999. T.3, С.116-123.

2.        Г.Б.Захарова, И.А.Кононенко, В.Г.Титов, В.П.Чистов. Система автоматизации структурно-логического этапа проектирования  // Автоматизация проектирования дискретных систем: Докл. III Междунар. конф. Минск, 1999. T.3, С.108-115.

UDK 519.683.2:681.3.02

 

 

THE TECHNOLOGY OF CROSS-PLATFORM DEVELOPMENT
OF THE MODULAR PROGRAM SYSTEMS

 

A.M. Knyazev, R.N. Shakirov

 

Institute of Engineering Science, RAS (UB)

91, Pervomayskaya str., Ekaterinburg, Russia, 620219

 

Tel.:  (3432) 74-25-94

E-mail: raul@imach.uran.ru

 

One of the most complicated   problems while developing  modern program systems (PS),  particularly CAD of microelectronics, is in necessity of periodic transference of system into new hardware-software platforms. In a modern view of absence of the generally accepted standard of mobile programming, the development of the mobile PS can be carried out only on the basis of specialized technologies.

The well known principle which is considered to be a basis of this technology  is a division of system into problem units working under the control of the integrating component , that is the shell of the PS.

The problem units are not loaded with functions of human-machine interaction and consequently they can develop with applying of standardized computer-independent programming languages. The database is realized by file system means without usage of any commercial DBMS. The problem units represented as executed programs, which depend on hardware-software platform.

The shell of the PS creates within the fixed model of human-machine interaction with usage of the built-in development tools providing assemblage and testing of the PS without programming. The assemblage is carried out on the developer platform and is completed by automatic generation of formalized functional description (FD), transferring to the target platform. There is an interpreter of the FD for call the PS on the target platform.

The functional description of the PS is represented as a set of text files describing separate components of the PS: problem units, problem operations, tables, tool database, problem windows.

The transference of  CAD DISCO, originally developed for MS DOS environment into Windows 95/98/NT is used to test the  technology of the cross-platform PS development.