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

Р Г Б ОД

СЕ!! -П?

На правах рукописи

БАЛАЯН Аркадий Суренович

ИНСТРУМЕНТАЛЬНАЯ ПОДДЕРЖКА ИНТЕРОПЕР АБЕЛЬНОСТИ КЛИЕНТОВ И СЕРВЕРОВ, РЕАЛИЗОВАННЫХ В РАЗЛИЧНЫХ ПРОГРАММНЫХ СРЕДАХ

05.13.11. — математическое и программное обеспечение вычислительных машин, комплексов, систем и сетей

Автореферат диссертации на соискание ученой степени кандидата технических наук

КАЗАНЬ - 1997

Работа выполнена в Казанском филиале Института проблем информатики Российской Академии Наук

Научный руководитель - доктор физико-математических наук,

профессор Калиниченко Л.А.

Официальные оппоненты - доктор технических наук,

Кузнецов С.Д.; кандидат технических наук, Иванов А.Г.

Ведущая организация - Институт системного программирования

Российской Академии Наук

Защита состоится "____" 19 в ______часов на заседа-

нии диссертационного совета Д 003.56.01 Института проблем информатики Российской АН по адресу: 117334 ГСП-1 г. Москва В-334, ул. Вавилова, 30/6.

С диссертацией можно ознакомиться в библиотеке Института проблем информатики РАН.

Автореферат разослан 19^г.

Ученый секретарь диссертационного совета, доктор технических наук

С.Н. Гринченко

Общая характеристика работы

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

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

Обозначилось и стало главным направление интеграционных стандарте, в котором проблема создания и поддержки ИСНИР решается с наи->лыпей степенью общности. Значительным достижением в этом напра-гонии является продукт CORBA (Common Object Request Broker Architecture архитектура брокера объектных заявок), разработанный консорциумом MG (Object Management Group). Центральным компонентом CORBA 1ляется ORB (Object Request Broker) - брокер объектных заявок, обесне-1вающий механизм прозрачной выдачи заявок и получения ответов между сложениями, работающими в неоднородной распределенной среде.

По технологии CORBA ресурс определяется на языке IDL (Interface Definition Language) как совокупность интерфейсов, составляющих модуль спецификации ресурса, в результате трансляции которого создается мета-база ресурса (repository), и на языке, в который зафиксировано отображение IDL, генерируются программные модули статического вызова (ПСВ, client's stub) и драйвера ресурса (ДР, skeleton), осуществляющие посредством интерфейса ORB "проводку" заявки клиента серверу и результата выполнения серверной функции обратно клиенту.

Такая технология позволяет идеально строить интеропёрабельные среды, однородные в смысле программного языка реализации клиентов, серве ров и ORB. При организации повторного использования уже существующих программных продуктов естественным образом возникают случаи, когда язык реализации клиента или сервера отличается от языка программирования, в который выбрано отображение IDL, и тогда в ПСВ и ДР необходимо выполнить преобразования типов, которые нельзя "запрограммировать" во время генерации этих модулей IDL-транслятором. Для решения этой проблемы, исключающего непредвиденные преобразования типов, в диссертации предлагается отображение унифицированной системы типов (УСТ) языка спецификации ресурсов (ЯСР) в типы независимого представления (НП) данных. Предлагаемый подход учитывает также, что та или иная ИСНЙР может строиться на базе собственной (отличной от IDL) модели ресурса и собственных отображений ЯСР в языки программной реализации. Показывается, как обеспечить процесс самостоятельной генерации модулей ПСВ и ДР и организовать посредством них унифицированную обработку объектных заявок.

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

Для достижения поставленной цели решались следующие задачи:

1. Построение модели ресурсов, представляющих инкапсулируемые программные продукты; определение ЯСР в этой модели и разработка компилятора ЯСР.

2. Определение алгоритмов генерации модулей ПСВ и ДР; разработка структур '"задание сервера" (ЗС) и "результат сервера" (РС), создаваемых и обрабатываемых в генерируемых модулях; определение отображения типов УСТ ЯСР в типы НП (типы данных ЗС и РС).

3. Определение языка и методики его использования для задания генерации модулей ПСВ и ДР; разработка макрогенератора с доступом к метабазе ресурса.

4. Разработка языка спецификации реализации ресурса (ЯРР) для описания отображения модуля спецификации ресурса в его программную реализацию для класса распределяемых ПП.

5. Определение языка управления объектами (ЯУР) - языка программирования клиентов ИСНИР и методов объекта; разработка интерпретатора ЯУР и объектного монитора (ОМ), выполняющего функции брокера заявок и обслуживания объектного пространства ИСНИР.

Методы исследования. При работе над диссертацией использовались 1етоды теории абстрактных типов данных и спецификаций, отображений отделен и объектно-ориентированного (о-о) подхода.

Научная новизна.

1. Предложен и реализован способ генерации программных компонентов архитектур клиентов и серверов ИСНИР с использованием результата компиляции ЯСР-модуля и задаваемого пользователем отображения ЯСР в язык программной реализации.

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

3. Предложен язык спецификации реализации ресурса (ЯРР) для отображения модуля спецификации ресурса в его программную реализацию. Определен и реализован ЯУР - язык о-о программирования в ИСНИР.

4. Представлена технология повторного использования класса распределяемых ГШ без необходимости изменения и перетрансляции исходного кода программ.

Практическая ценность. Полученные в работе результаты представляют собой методологическую основу для организации неоднородных информационных систем на базе сетей ЭВМ и повторного использования уже разработанных информационных ресурсов, г также для организации о-о программирования в процедурной среде. С использованием ЯСР разрабатывались информационные ресурсы, такие как АТД картинно-графического типа и АТД поддержки БД с исчислением времени. Результаты работы внедрены в проект СИНТЕЗ, разрабатываемый в соответствии с планами Российской Академии Наук.

Апробация работы. Основные положения работы докладывались на научных семинарах по проекту СИНТЕЗ в Киеве (1991), Бердянске (1992). Москве (1991, 1992), Казани (1993); Международном научно-техническом семинаре "Современные информационные технологии" (Киев, 1993), Международной конференции Московской секции ACM SIGMOD (Москва, 1993, 1994), Международной научно-технической конференции "Развитие и применение открытых систем" (Казань, 1994). Программное обеспечение, работы и техническая документация демонстрировались межведомственной комиссии по приемке проектов "Интеграция" и "Синтез".

Публикации. По материалам диссертации опубликовано четыре печатные работы и выпущено два научно-технических отчета.

На защиту выносятся:

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

2. Язык и описание процесса макрогенерации программных компонентов, составляющих части архитектур клиента и сервера.

3. Язык и средства управления ресурсами как объектами.

Структура работы. Диссертация состоит из введения, шести глав и заключения в формате машинописного текста, куда входит: рисунко] - 7, таблиц - 3, список литературы из 45 наименований.

II Содержание работы

В первой главе представлены модель и язык определения информационных ресурсов (ИР).

В роли ЙР здесь выступают программные продукты, рассматриваемые с самой общей точки зрения, без учета их семантической специфики. Основной характеристикой ресурсов, пригодных для создания на их базе интероперабельной среды, является ипкапсулируемость. Применительно к программам это означает возможность формального определения функций данной программы и возможность организации выполнения этих функций на базе имеющихся определений. Инкапсулируемые программные продукты делятся на программы-полуфабрикаты ("библиотеки", независимо транслируемые модули процедур и т.п.) и готовые программы (ГП), функции которых доступны только посредством пользовательского интерфейса. Инкапсулирование программ-полуфабрикатов представляет собой чисто техническую задачу. Для некоторых классов ГП задача также разрешима. Например, алгоритм инкапсулирования ГП с диалоговым интерфейсом типа "меню" основывается на представлении меню в виде дерева (в более общем случае, направленного ациклического графа). Тогда вершины дерева интерпретируются как варианты выбора, предоставляемые вершиной, из которой они исходят, а с множеством путей, ведущих из корневой вершины в конечные, связывается множество функций рассматриваемой ГП. Функции, определяемые таким образом, могут иметь аргументы, если при выборе того или иного варианта меню от пользователя дополнительно требуется ввод определенных данных. Тип аргументов таких функций определяется как "строка символов", а сами функции реализуются как процедуры, состоящие из последовательности вызовов функций управления клавиатурой. Соответствующий язык часто называют "макроязыком" или языком "скриптов". Для доступа к функциям инкапсулированной ГП используется процедура-адаптер, способная переназначать стандартные ввод и вывод программы. Подобная техника инкапсулирования ГП была применена автором к продукту Gum (Micro Data Base Systems,Inc.) оболочке лкснертных систем продукционного типа.

Предлагаемая в работе модель ресурса ориентирована главным образом на обеспечение повторного использования подкласса инкапсулируемых программ, которые можно было бы называть "распределяемыми". Распределяемая программа (Р) представляется парой < МС,М„ >, в которой Мс - главный модуль (модуль-клиент), а М3 - вспомогательный модуль (модуль-сервер). Главный модуль содержит ссылки на определения глобальных переменных и функций и главную процедуру программы (Р), в которой, как правило, выполняется инициализация глобальных переменных: Мс =< ... ...;... Ууе/()...; .Р(...,г;,..., /Д),...) >. Вспомогательный модуль содержит определения глобальных переменных и функций: М, =< ...«;...;...//()... >. Связывая один и тот же вспомогательный модуль М, с разными главными , получаем множество разных программ Р{. В традиционных (однородных и нераспределенных) программных средах главный и вспомогательный модули связаны в рамках одного процесса. Одна из целей ИСНИР - обеспечение возможности распределения частей МС),- и М, программы по разным вычислительным средам. При этом в предлагаемом решении повторное использование процедур модуля М3 реализуется без необходимости изменения исходного кода и перетрансляции.

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

Ресурсы представляются либо как множество функций, либо как множество объектов, либо как объединение обоих этих множеств.

Ресурсы, представленные только множеством функций, называются процедурными базами (ПБ). Функции ПБ - простые, в том смысле, что с данным именем функции связывается единственное определение функции. Функции же объекта (методы) - родовые: с данным именем функции

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

Средством спецификации модели ИР является модуль. Определение модуля задается на языке спецификации ресурсов (ЯСР) по схеме:

MODULE имя-модуля;

IMPORT < Список импортируемых модулей > CONST < Раздел определений констант > TYPE < Раздел определений типов > CLASS < Раздел определений классов > FUNCTION < Раздел определений функций ПБ > END

Модуль замкнут в том смысле, что все ПБ и классы, входящие в его состав, определены в нем самом и/или импортируемых модулях и он может быть сак однородным, так и неодородным относительно используемой машинной фхитектуры, операционной системы и программной среды входящих в него ТБ. Функции ПБ могут вызываться из программы пользователя самостоятельно либо служат для ссылки на реализацию методов классов. Классы в ICP соответствуют интерфейсам в IDL. Спецификация класса объединя-!Т в себе определение объекта-класса и объектов-экземпляров этого клас-а. При описании модели данной распределяемой программы глобальные [временные (и;) и функции (f}) отображаются на множества атрибутов и гетодов объекта-экземпляра и/или объекта-класса определяемого класса. ! ЯСР предоставляется возможность определения типов и классов путем онкретизации параметризованных определений.

Отдельный раздел посвящен построению УСТ. Определены примитив-ме типы данных и операции образования сложных типов (типовые oriepa-ии) с использованием логики предикатов 1-го порядка.

Во второй главе дается общее представление об архитектуре ИОНИР описание программных компонентов этой архитектуры, генерация кото-ых поставлена как одна из задач данной работы: модулей ПС'В и ДР. Рас-иатриваются также структуры "задание/результат сервера", с которыми аботают процедуры этих модулей.

Выполняющиеся процессы ИСНИР бывают трех типов: процессы клиента (программы пользователя), серверные процессы (программы, реализующие ресурсы) и процесс объектного монитора (ОМ). По своему архитектурному строению все эти процессы подобны друг другу. В компонентном составе каждого из них можно выделить пять уровней: интерфейс межпроцессной связи; преобразователь примитивных типов данных конкретной среды программирования (клиента или сервера) а типы независимого представления и обратно; модули ПСВ (для клиента) или ДР (для сервера); локальный интерфейс, содержащий специфические для данного клиента или сервера функции; непосредственно программа пользователя (для клиента), программа ресурса (для сервера) или программа, реализующая служебные функции ОМ.

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

Структура ЗС формируется в ПСВ и для случая "вызов функции ПБ" содержит: идентификатор модуля ИР, код вызываемой функции и список значений Ш/ШОиТ-аргументов (с обозначениями позиций для ОХ1Т-аргументов) вызова.

Структура РС формируется в ДР и содержит: значение результата функции, список значений ШОПТ/ОиТ-аргументов (с обозначениями позиций для Ш-аргументов).

ЗС и РС представляются в формате независимого представления (Ей), устанавливающего правила передачи фактических параметров и результатов функций между процессами клиента и сервера. В основе формата НП - три типа данных: "числовой" (ЮиМВЕЫ), "строковый" (ШТЕШС) и "составной" (1УТБ.иСТиЯЕ). Для представления значений этих типов используются АБСИ-символы. Значение типа ШиМВЕЙ представляет со-

бой последовательность десятичных цифр с десятичной точкой или без нее. Значение типа ^ТИШС - строка символов. Тип ШТЯиСТиЯЕ используется для представления значений сложных типов ("массив", "запись" и т.п.) в виде списка, элементами которого могут быть вложенные списки и значения типа ШиМВЕЯ и ШТИШС.

Каждому типу УСТ соответствует тип НП, используемый для представления в структурах ЗС и РС значений конкретного типа данных, в который отображается данный тип УСТ. Таб. 1 показывает соответствие, устанавливаемое между некоторыми типами УСТ, ГОЬ и НП.

Тип УСТ Тип IDL Тип НП

TInt(L=4,С—SIGNED) signed long

TInt(L=4,С—UNSIGNED) unsigned long

TInt(L=2,C=SIGNED) long

TInt(L=2,C=UNSIGNED) short INUMBER

TInt(L=l,C=UNSIGNED) octet

TReal(L=4) float

TReal(L=8) double

TChar char ISTRING

TBool boolean INUMBER

Tstr(L=n) string < n > ISTRING

Tstr() string ISTRING

TEnum enuni INUMBER

a=TArr( ra,B A SE= b) b a[n] ISTRUCTURE

T Record struct ISTRUCTURE

TPowset string ISTRING

Таб. 1: Отображения типов УСТ, IDL и НП

Для каждой используемой программной среды определяется набор функций преобразования данных примитивных типов этой среды в соответствующие типы НП и обратно. Алгоритмы функций преобразования структурных типов встраиваются в процесс макрогенерации и используют поэлементное преобразование (в соответствии со структурой списка) с вызовами

функций преобразования примитивных типов.

Пусть /(..., [IN|OUT|INOUT] а,- : <£,...) : t - обозначение некоторой определенной в ЯСР-модуле функции ПБ, причем U и t - имена типов УСТ ЯСР. Обозначим t{ тип НП представления значений типа В соответствии с некоторым отображением ЯСР в язык реализации клиента в программе пользователя функции / соответствует функция /(...,а,- : t\,...) : tc, определяемая в модуле ПСВ. Следует схема алгоритма, по образцу которого генерируется модуль ПСВ:

1. Объявить строковую переменную (str) достаточной длины для получения значений фактических параметров вызова в формате НП.

2. Выделить буфер памяти достаточного размера для формирования ЗС; определить идентификатор модуля (по имени) и занести в ЗС.

3. Выполнить для каждого "описателя функции" из метабазы ресурса:

a. Определить номер текущей функции и занести его в ЗС.

b. Занести в ЗС список аргументов в формате НП; для каждого IN/INOUT-аргумента а,- выполнить: str <~ to/J?(a,-); добавить str в буфер.

c. Послать ЗС процессу брокера и ждать результата сервера.

d. Извлечь результат функции и значения выходных аргументов; для каждого INOUT/OUT-аргумента а,: считать в str. НП-значешк и выполнить а; <— fromlJ{(sti).

Модуль ДР может быть организован как CASE-оператор, в котором вариант выбора определяется по номеру вызываемой серверной функции f и содержит вызов этой функции. В соответствии с некоторым отображением ЯСР в язык реализации сервера в программе ресурса определена функция /(...,ai : ¿¿,...) : t3. Следует схема алгоритма, по образцу которого генерируется модуль ДР:

1. В цикле по всем "описателям функций" и "описателям аргументов" ai внутри каждой функции /_j объявить переменные: /;_а, типа t',

переменную типа t" (результат функции), строковую переменную

str и переменную /по типа "целый".

2. Принять ЗС; извлечь номер вызываемой фунхции в str; выполнить /по fromIJnt3(str).

3. Выполнить для каждого "описателя функции" метабазы ресурса:

a. Выдать заголовок текущего (j) варианта CASE.

b. В цикле по количеству аргументов: считать очередное НП-значение аргумента в str и выполнить fjjii <— fromlJ*(str).

c. Выдать оператор выполнения вызываемой функции: ВЫПОЛНИТЬ /Д. .. , fj-Oi, ...).

d. Записать результат выполнения lolJ'ir^fj) в PC.

e. Для каждого OUT/INOUT-аргумента выполнить: str toUKfjJZi); записать str в PC.

f. Послать PC процессу брокера.

Модули IICB и ДР используют интерфейсы межпроцессной связи, метабазы есурса, преобразователя типов и обработки структур ЗС и PC.

В третьей глапе дается описание макрогенератора и методика его ис-ользования для генерации модулей ПСВ и ДР.

Обязательный основной вход макрогенератора - это последовательность оманд языка генерации, включающая определения пользовательских ма-рокоманд и образец генерации, называемый макропрограммой. Дополни-ельный вхоц представляет собой БД, реляционная схема которой задается эвокупностыо некоторого главного (MAIN) отношения h (со схемой Н) и ножества его дополняющих (TAIL) r^R,), причем отношения h и г,- со-динимы по единственному атрибуту, являющемуся ключом каждой схемы Программный интерфейс БД должен обеспечивать доступ к записям аждого из отношений h xi г;. Схема Н содержит обязательный атрибут с менем TYPE, который задает "тип" дополнительной записи БД. В данной гботе в роли дополнительного входа выступает метабаза ресурса. Общий формат команд следующий: Имя-команды < G-выражение > < G-выражение > представляет собой сцепление (обозначается: "!") )остых и/или составных G-элементов. К простым относятся: терминально строки символов (переносятся в результирующий выходной файл без вменения), формальные параметры макрокоманд ($1-$9), имена атрибу->в схемы БД (kid) и внутренние переменные генератора (&1 &9). В про-

цессе генерации вместо имени атрибута схемы подставляется символьное значение, лежащее в текущей записи БД (с соответствующим этому атрибуту смещением). Составной G-злемент уточняется (рекурсивно) заданием указателя: @id.< G-элемент >. В этом случае значение берется из записи, номер которой задается значением атрибута-указателя схемы БД.

Внутренние переменные генератора, значениями которых могут быть константы или множества констант, служат для расширения многообразия макрокоманд. Макрокоманды, имена которых содержат внутренние переменные (родовые имена), "размножаются" путем образования пр а аильных сочетаний значений этих переменных. Пусть х&1у&2 - родовое имя и = {fu,г/12,. • •}, = {г'2ь1'22> ■ • •}• Тогда генератор порождает макрокоманды с именами: xvuyvy, i j=l,2,...

Ниже показана система команд генератора:

PRINT[CR] [< G-выражение >]

DBENTRY{MAIN | TAIL титзаписи} список-спецификаций-полсй LOCATE < указатель записи >

< Команды генератора > DISLOCATE

MACRO < Имя >

< Команды генератора > MEND

PERFORM < G-выражение >

REPEAT n|TYPE[=< код >]| ENTRY|PARM jCLASS

< Команды генератора > SEPARATOR[CR] [< G-выражение >]

По команде PRINT (PRINTCR) генератор "вычисляет" < G-выражение . и выводит его значение в результирующую строку символов.

Отдельное поле в команде DB ENTRY это или поле данных (&.имм\тип), или поле ссылки (@имя), содержащее номер славной записи. Допустимые типы полей: В - целое (16) и An - строка символов (» длина). Доступ к записям БД управляется указателем текущей записи сланного отношения, значение которого изменяется либо но команде LOCATE, либо по

команде цикла REPEAT. Макрогенератор использует фиксированный интерфейс, основными функциями которого являются: перевод указателя (на 1-ую запись, на следующую, на 1-ую запись заданного типа, на следующую запись заданного типа) и считывание значения по заданному номеру записи и смещению поля.

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

Команда REPEAT-SEPARATOR задает цикл либо по числу шагов п, либо по типу последовательно выбираемых записей БД: типы данных, функции ПБ, аргументы текущей функции ПБ, классы и др. Значение параметра < G-выражение > в SEPARATOR вычисляется и выводится в результирующий текст после выполнения каждого шага цикла.

Справедливо утверждение о вычислительной полноте предложенной системы команд. Для доказательства достачно убедиться, что отсутствующая команда "условного выбора" (IF-ELSE) успешно моделируется для всевозможных случаев задания условия: простейшее условие (проверка на равенство), проверка на неравенство (отрицание), OR-связка и AND-снязка условий. Доказательство опирается на конечность множеств, представляющих области значений всех используемых переменных макропрограммы, и строится на возможности задания имен выполняемых макрокоманд как "вычисляемых" выражений. Способ доказательства по сути представляет методику "макропрограммирования" в предложенной системе команд.

Для примера приводится макропрограмма генерации "заголовочного файла" определений типов.

PRINTCR TYPE REPEAT TYPE

PERFORM T!fcTYPECODE!&TYPELEW!&INTC0DE SEPARATOR

Она вызывает последовательное считывание всех "описателей типа", извлекая из каждого описателя значения указанных переменных. &TYPECODE цает наименование типа (INT, ARRAY и т.п.). &TYPELEN и &INTCODE пают длину и код способа представления для типа "целый", а для других гипои содержат пустые значения. 13 результате вызывается макрокоманда, генерирующая определение конкретного типа, имя которого подставляется

вместо &NAME. Следуют примеры макрокоманд, задающих отображение типов ЯСР в определения типов на языке Паскаль.

MACRO TINT20 /* Тип "Целый"

PRINTCR #4:ANAME!=INTEGER; MEND

MACRO TENUMERATION /* Тип "Перечисление"

PRINTCR #4:fcNAME!=( REPEAT &FIELDCOUNT

PRINT &FIELDNAME SEPARATOR , PRINTCR ); MEND

MACRO TARRAY /* Тип "Массив"

PRINTCR #4:¿NAME!=ARRAY [!QINDTYPE.&NAME OF !QBASETYPE.&NAME!; MEND

Четвертая глава содержит описание языка спецификации реализации ресурсов, представляющих распределяемые программы. Спецификация реализации задается в модуле IMPLEMENTATION:

IMPLEMENTATION гшя-ЯСР-модуля; < Общие данные реализации > TYPE < Отображение типов > FUNCTION < Отображение функций > CLASS [^FUNCTION] < Отображение классов > END

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

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

СОСТАВ МОДУЛЯ СРЕДА РЕАЛИЗАЦИИ СПЕЦИФИКАЦИЯ РЕАЛИЗАЦИИ

ПБ Процедурная Отображение функций

ПБ; классы ЯСР Процедурная; ОМ-поддержка объектов. Отображение функций; отображение методов с примитивной реализацией.

ПБ; внешние классы О-о, гибридная; собственная реализация методов. Отображение функций и отображение методов; данные реализации -общие, один процесс, поддерживающий и функции, и методы.

Внешние классы О-о, однородная Отображение методов; данные реализации относятся к о-о среде.

Таб. 2: Отображение реализации

Общие данные относятся к реализации ПБ и классов. Каждый класс, однако, может иметь свои собственные данные реализации. Обязательными являются: идентификатор узла сети, в котором функционирует процесс (программа) ресурса (LOCATION=adpfic), и логическое имя процесса в рамках действующей в этом узле операционной системы (PROG=iuttf).

Отображения реализаций типов, функций и классов используются в процессе генерации модулей ПСВ, ДР и "заголовочных" файлов, а также во время динамического вызова функций ПБ и объектов. .

Для каждого типа t, определенного в модуле спецификации ресурса посредством одного из прилштивных типов УСТ (t=TIntcger(),...), в соответствующем. модуле реализации задаются: t:: [атрибуты-гпипа] ТО=гшя FROM = «.111/ [GFjN=мл1Я-лкж/:>о];

ТО и FROM задают имена определяемых в модуле функций преобразования значений конкретного типа (образа типа УСТ) в HII и обратно. GEN

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

Функция ИВ (f) может быть реализована как функция PROG-нроцесса (/ :: имя- Р RO G - проц с дур ы;), как интерпретируемое выражение PROG-процесса или команда ОС (/ :: {PROG | SHELL) Скрипт;). Скрипт -строка символов в формате интерпретатора или команды ОС.

Для классов, реализованных в о-о среде, отображение реализации задается простым сопоставлением имени ЯОР-класса с именем класса PROG-процесса. Отображение методов (сопоставлением имен) задается в контексте классов. Для классов, реализуемых в процедурной среде (примитивная реализация), задается отображение метода на соответствующую функцию ПБ. Метод т с аргументами а™ : ..., а™ : и результатом типа tm, принадлежащего классу с, соответствует функции / с аргументами a,f : tc, а{ : t{,..., а{ : t{ и результатом типа t* если:

• количество аргументов функции (к 4- 1) на 1 больше, чем у метода;

• первый аргумент функции а? соответствует объекту-получателю сообщения и принадлежит типу tc = typeof(c) (тип класса с);

• t{ = <™ или t{ = typeof(i™), если а™ - объект.

Примитивная реализация метода выполняется объектным монитором, который, анализируя класс объекта-получателя, находит и запускает соответствующую функцию ПБ. Непосредственная реализация метода задается как программа на ЯУР (ш :: {ЯУР-программа}), выполняемая интерпретатором ОМ.

В пятой главе дается описание "макроязыка" управления ресурсами (ЯУР), являющегося языком программирования методов классов и программ пользователя. С точки зрения архитектуры CORBA функции ЯУР относятся к различным службам "объектного сервиса" (Object Services).

Синтаксис и семантика ЯУР как о-о языка проектировались по аналогии с языком Эйфель. Параллельно ЯУР поддерживается программный Си-интерфейс ОМ, одна из функций которого - выполнение ЯУР-процедуры, заданной в текстовом формате. Для использования функций ОМ из среды клиента достаточно «енеркровать соответствующий модуль

Необходимая для этого спецификация ПБ ОМ на ЯСР дана в приложении к работе. ЯУР является входным языком ОМ и в этом качестве в среде ОМ может использоваться в режиме диалога.

Принципиальным оператором ЯУР является оператор загрузки мета-базы ресурса, в процессе выполнения которого в объектном пространстве ОМ создаются все объекты-классы и запускаются процессы, реализующие ПБ и классы загружаемого модуля. Объекты-классы доступны по своим именам, которые выступают как предварительно объявленные объектные переменные. Далее можно объявлять объектные переменные для доступа к объектам-экземплярам, создавать новые объекты, присваивать и изменять значения их атрибутов, выполнять функции объектов и ПБ. Оператор загрузки выполняет функции службы именования (Naming) объектного сервиса CORBA.

При объявлении объектной переменной содержащийся в ней объектный указатель может связываться с объектом определенного в модуле класса, множеством объектов, массивом объектов или со значениями типов НИ (в :оотвотствии с отображением УСТ - НП). Над понятием объектной переменной строится понятие объектного выражения (О-выражение), которое зместе с оператором связывания заключает в себе практически все выра-штельные возможности ЯУР. Простое О-выражение может быть объект-юй переменной (о), индексированной переменной o[i] (о - массив объектов), 1Трибутом объекта (о.р, р - имя атрибута), методом (о.р(), р - имя метода), »строенной функцией ОМ (например, COPY - копирование объекта) или (ызовом функции ПБ f, принадлежащей модулю m (m.fQ). О-выражение это цепочка ol.o2...., интерпретируемая слева направо, как простое 0-!ыражение: ol,(o2.( ... )).

Оператор связывания: = Од; (0^,0^ - О-выражения) имеет сле-lyioiuyio семантику. Если объект обозначить как пару < ймя,Адр >, то юсле выполнения связывания (при условии, что класс R-объекта является годклассом класса L-объекта) объект в левой части будет < Имя^, Адр^ >.

ЯУР независим в том смысле, что используемые в нем значения при-[адлежат типам НП, а выполняемые операции - только объектные. Для ыполнения операций конкретных типов данных вызываются функции IIБ [ли методы объектов.

В шестой главе рассматриваются технические вопроси поддержки объ ектного пространства ИСНИР. Дано описание структуры объектного указателя (ОР), используемой для организации стека вычислений интерпретатора ОМ и для приведения к однородному представлению структур хранения сосуществующих объектов и простых значений. Рассматриваются необходимые для работы ОМ управляющие структуры данных. Центральной является таблица загружаемых модулей. Активному модулю, в контексте которого выполняются вычисления, соответствует текущий элемент таблицы, который может быть переназначен. Каждый новый элемент создастся в результате выполнения оператора загрузки модуля и содержит ссылку на метабазу модуля и связанные с ним таблицу процессов, реализующих функции IIB и классы, таблицу объектов, таблицу имен объектных переменных (с каждым именем связывается элемент таблицы объектов), область значений объектов и простых,значений и др.

На примере "вызова метода" дан разбор процесса интерпретации ЯУР.

Отдельно представлен интерфейс ПБ, используемый для динамического вызова функций ПБ из программ пользователя.

III Основные результаты и выводы

При организации интероперабельной среды ИР проблема неоднородности является принципиальной. Дано технологическое решение этой проблемы, основанное на фиксированном отображении типов УСТ в типы НП.

1. Разработаны средства спецификации и представления ресурсов, представляющих собой инкапсулируемые ГП и программы-полуфабрикаты в виде множества процедурных баз и/или классов.

2. Разработан макрогенератор, основной вход которого - набор макрокоманд и макропрограмма на языке генерации, а дополнительный -реляционная БД с заданным описанием схемы.

3. Дан метод описания генерируемых языковых конструкций конкретной программной среды на языке команд макрогенератора. Разработанные макроописания для языков Си и Паскаль могут быть адаптированы для других языков.

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

Возможность самостоятельной генерации модулей ПСВ и ДР позволяет сделать вы под о том, что ИСН ИР с заданным интерфейсом брокера объектных заявок можно строить на базе собственного ЯСР и собственных отображений ЯСР в конкретные программные среды.

IV Список публикаций по теме диссертации

1. Балаян Л.С., Калиниченко J1.A. Язык спецификаций типов и процедур. - Препринт ИПЙ АН СССР. Проект Синтез, ИПИ АН СССР, 1991. 42 с.

2. Балаян А.С. Отображение баз знаний экспертных систем продукционного типа в модель информационных ресурсов системы Синтез. - Труды рабочего семинара "Перспективы развития систем баз данных и информационных систем" (ADBIS'93), Институт проблем информатики РАН, Москва, 1993. С.86-93.

3. Balaian A.S. Encapsulating Expert Systems for Reuse in the Synthesis environment. - Proceedings of the international Workshop on "Advances in Databases and Information Systems" (ADB1S'94). Institute for Problems of Informatics of the Russian Academy of Sciences, Moscow, May 23-26, 1994. -P. 197-201.

4. Balaian A.S. A Proposal of Languages in Support of interoperability Environments. - Proceedings of the Second International Workshop on "Advances in Databases and Information System:;" (ADBIS'95). Moscow, June 27-30, 1995. Moscow: Phasis Publishing House. Volume 2: Extended Abstracts. - P.25-28.

Сдано в набор 29.07.97 г. Подписано в печать 04.08.97 г. Форм. бум. 60x84 1/16. Печ.л. 1. Тираж 100. Заказ 209.

Лаборатория оперативной полиграфии КГУ 420008 Казань, Кремлевская, 4/5