Интерфейс в программировании
Рассмотрены базовые понятия интерфейса, подходы к обеспечению интерфейса языков программирования (ЯП) и взаимодействия разноязыковых программ и данных. Определены общие проблемы неоднородности ЯП, платформ компьютеров и сред, влияющие на выполнение связей между разноязыковыми программами, сформулиро...
Saved in:
| Date: | 2007 |
|---|---|
| Main Author: | |
| Format: | Article |
| Language: | Russian |
| Published: |
Інститут програмних систем НАН України
2007
|
| Subjects: | |
| Online Access: | https://nasplib.isofts.kiev.ua/handle/123456789/293 |
| Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
| Journal Title: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Cite this: | Интерфейс в программировании / Е.М. Лаврищева // Пробл. програмув. — 2007. — N 2. — C 126-139. — Библиогр.: 23 назв. — рус. |
Institution
Digital Library of Periodicals of National Academy of Sciences of Ukraine| _version_ | 1859587480788926464 |
|---|---|
| author | Лаврищева, Е.М. |
| author_facet | Лаврищева, Е.М. |
| citation_txt | Интерфейс в программировании / Е.М. Лаврищева // Пробл. програмув. — 2007. — N 2. — C 126-139. — Библиогр.: 23 назв. — рус. |
| collection | DSpace DC |
| description | Рассмотрены базовые понятия интерфейса, подходы к обеспечению интерфейса языков программирования (ЯП) и взаимодействия разноязыковых программ и данных. Определены общие проблемы неоднородности ЯП, платформ компьютеров и сред, влияющие на выполнение связей между разноязыковыми программами, сформулированы пути их решения. Изложены стандартные решения ISO/IEC 11404-1996 по обеспечению независимых от ЯП типов данных и стандарты преобразования форматов данных.
|
| first_indexed | 2025-11-27T10:59:48Z |
| format | Article |
| fulltext |
Інструментальні засоби і середовища програмування
© Е.М. Лаврищева, 2007
126 ISSN 1727-4907. Проблеми програмування. 2007. № 2
УДК 681.3
Е.М. Лаврищева
ИНТЕРФЕЙС В ПРОГРАММИРОВАНИИ
Рассматриваются базовые понятия интерфейса, подходы к обеспечению интерфейса языков програм-
мирования (ЯП) и взаимодействия разноязыковых программ и данных. Определены общие проблемы
неоднородности ЯП, платформ компьютеров и сред, влияющие на выполнение связей между разноязы-
ковыми программами, сформулированы пути их решения. Изложены стандартные решения ISO/IEC
11404–1996 по обеспечению независимых от ЯП типов данных и стандарты преобразования форматов
данных.
1. Определение интерфейса
Общее определение. Интерфейс –
это связь двух отдельных сущностей. В
компьютерной области интерфейс опреде-
ляется на разных уровнях: от уровня ви-
димых коммуникаций между людьми до
аппаратных, программных, пользователь-
ских, языковых и других интерфейсов.
Аппаратный интерфейс – это разъемы, ко-
некторы и другие устройства для объеди-
нения компонентов в компьютерную сис-
тему и обеспечения перемещения инфор-
мации с одного компьютера в другой. На
программном уровне интерфейс между
программами и ОС, между ОС и аппарату-
рой обеспечивает передачу и преобразова-
ние входных/выходных данных взаимо-
действующих программ в ОС или во
время объединения компьютера с перифе-
рийным оборудованием. Пользовательский
интерфейс включает средства взаимодей-
ствия пользователя с некоторой програм-
мой через графический дизайн, панели
выбора меню, подсказки и др. В ЯП ин-
терфейс – типы данных и описание кон-
стант, переменных, параметров и сложных
структур данных, которые образуют межъ-
языковой интерфейс ЯП как способ экви-
валентных взаимосвязей.
В практическом программировании
интерфейс представляется набором опера-
ций, обеспечивающих определение видов
услуг и способов их получения от про-
граммного объекта/компонента, предос-
тавляющего эти услуги. На начальном
этапе практического программирования в
роли интерфейса выступали операторы
обращения программы к ее процедурам и
функциям через формальные параметры,
которые записывались в одном ЯП. Опе-
раторы обращения включают имена вызы-
ваемых объектов (процедур и функций),
список фактических параметров, задаю-
щих значения формальным параметрам, и
получаемых результатов. Выполнение
функции или подпрограммы в рамках про-
граммы на одном ЯП не вызывало про-
блем, так как соответствие типов данных
устанавливается автоматически.
Когда один из элементов – про-
грамма, процедура или функция записаны
на разных ЯП и, кроме того, если они рас-
полагаются на разных компьютерах, то
возникают проблемы неоднородности
представления типов данных параметров в
этих ЯП, структурах памяти платформ
компьютеров и операционных сред вы-
полнения программных объектов. Поня-
тие интерфейса как посредника между
двумя взаимодействующими програм-
мами, сформировалось в связи со сборкой
или объединением разноязыковых про-
грамм и модулей в монолитную систему
на ЕС ЭВМ, память которых позволяла
получать большие размеры программ (до
100–200 тыс. команд).
Основу модуля–посредника со-
ставляет оператор связи между вызывае-
мым и вызывающим разноязыковыми
модулями в языках Алгол, Фортран, Ко-
бол, Ассемблер в системе АПРОП (1976–
985) [1, 2], первой в СССР фабрики про-
грамм, идею которой предложил В.М.
Глушков. Интерфейсный модуль–посред-
ник включал описание формальных и фак-
тических параметров, операторы вызова и
проверки соответствия передаваемых па-
раметров (по количеству и порядку распо-
ложения), а также эквивалентности типов
Інструментальні засоби і середовища програмування
127
передаваемых данных. Если типы данных
параметров оказывались не релевантными
(например, передается целое, а результат
функции – вещественное или наоборот), то
осуществлялось прямое и обратное пре-
образование передаваемых типов данных
с учетом ЯП и структуры памяти компь-
ютеров. На рис.1 показана общая схема
интерфейса программы С, содержащая
два вызова – Call A (… ) и Call B (…) с
параметрами, которые через интерфейсные
модули–посредники A’и B’ осуществляет
преобразование данных и их передачу мо-
дулям А и В. После выполнения модулей
А и В их результаты преобразуются об-
ратно к виду программы С в тех же моду-
лях A’и B’ .
Проблема интерфейса обсуждалась
на международной конференции «Интер-
фейс СЭВ» (1987), на которой было при-
знано, что интерфейс является стратегиче-
ским направлением в решении задач свя-
зывания программ и систем, записанных в
разных языках четвертого поколения на
машинах ЕС.
Общая идея интерфейса отобра-
жена в стандарте открытых систем (Open
Systems Interconnection – OSI) [3]. В нем
комбинируются принципы управления ар-
хитектурой и посредством программиро-
вания, обозначающие пути интеграции
разных систем для их взаимодействия и
общения. Согласно модели OSI приложе-
ние передает запросы другому приложе-
нию через уровень представления данных,
устанавливая интерфейс с системой коди-
рования (перекодирования) данных к виду
заданных компьютеров. Это направление
остается важным, особенно когда появля-
ются новые ЯП.
1.1. Интерфейс и объектно-ориентиро-
ванное программирование (ООП)
Интерфейс получил новое развитие
в ООП. В нем главным элементом является
класс, включающий множество объектов с
одинаковыми свойствами, операциями и
отношениями. Класс имеет внутреннее
(реализацию) и внешнее представление –
интерфейс (рис. 2).
Интерфейс содержит множество
операций, описывающих его поведение.
Класс может поддерживать несколько ин-
терфейсов, каждый из которых содержит
операции и сигналы, которые использу-
ются для задания услуг класса или про-
граммного компонента. Интерфейс опре-
деляет сигнатуру множества операций
и/или результирующие действия. Если ин-
терфейс реализуется с помощью класса, то
он наследует все его операции. Одни и те
же операции могут появляться в различ-
ных интерфейсах. Если их сигнатуры сов-
падают, то они задают одну и туже опе-
рацию, соответствующую поведению сис-
темы. Класс может реализовывать другой
класс через интерфейс [4].
Входные данные
Программа С Интерфейс А’ Модуль А
Call A ( ) в ЯП1
(преобразование
типов данных)
Сall B ( ) Интерфейс В’ Модуль В
в ЯП2
(преобразование
типов данных)
Выходные данные
Рис.1. Схема вызова модулей А и В из программы С через модулей–посредников А’и B’
Інструментальні засоби і середовища програмування
128
Операции и сигналы могут быть
связаны отношениями обобщения. Интер-
фейс–потомок включает в себя все опера-
ции и сигналы своих предков и может до-
бавлять собственные путем наследования
всех операций прямого предка, т.е. его
реализация рассматривается как наследо-
вание поведения.
Новое толкование интерфейса
объектов дано в работе П. Вагнера [5],
который сформулировал парадигму пере-
хода от алгоритмов вычислений к взаи-
модействию объектов. Суть этой пара-
дигмы заключалась в том, что вычисление
и взаимодействие объектов рассматрива-
лись как две ортогональные концепции.
Взаимодействие – это некоторое действие
(action), но не вычисление, а сообщение –
не алгоритм, а действие, ответ на которое
зависит от последовательности операций
(Op), влияющих на состоянии разделен-
ной (shared state, ss) памяти локальной
программы (рис. 3). Операции интерфейса
(Op1 и Op2) относятся к классу неалго-
ритмических и обеспечивают взаимодей-
ствие объектов через сообщение.
Модель взаимодействия – это
обобщение машины Тьюринга, как рас-
пределенной интерактивной модели взаи-
модействия объектов с входными (input) и
выходными (output) действиями (actions) и
возможностью продвижения в ней потен-
циально бесконечного входного потока
(запросов, пакетов) в заданном интервале
времени.
Дальнейшим развитием идеи взаи-
модействия, основанного на действиях,
является язык AL (Action language), осно-
ванный на задании вызовов процедур
(локальных или распределенных) и раз-
вертки каждого вызова в программу [6, 7],
состоящую из операторов действий. Про-
грамма из вызовов процедур рассматрива-
ется в AL как ограниченное множество
конечных программ, взаимодействующих
со средой, в которую они погружаются.
Класс
. Внешнее представление Внутреннее
представление
Интерфейсные операции: Реализация
– публичные, доступные всем операций
клиентам, класса и
– защищенные, доступные классу и определение
подклассу поведения
– приватные, доступные классу
Рис. 2. Структура представления класса с интерфейсом
Интерфейс Объект – связь
операции Ор1 Ор1 (Оp1, Оp2, состояние)
Внешнее взаимо– Разделенное
действие через состояние (ss)
сообщение
Операции – не алгоритмы,
Интерфейс Ор2 Ор2 Внутренне они не контролируют ss
взаимодействие
через ss
Рис. 3. Интерфейс взаимодействия через операции Ор1, Ор2
Інструментальні засоби і середовища програмування
129
1.2. Интерфейс в современных средах и
сетях
Появление разных ПК и их объе-
динение в локальные и глобальные сети
привело к уточнению понятия интер-
фейса, в виде удаленного вызова про-
грамм, расположенных в разных узлах
сети или среды и получающих входные
данные из сообщений.
Сети базируются на стандартной
семиуровневой модели открытых систем
OSI (Open Systems Interconnection) [3].
Объекты уровней этой модели связыва-
ются между собой по горизонтали и вер-
тикали. Запросы от приложений посту-
пают на уровень представления данных
для их кодирования (перекодирования) к
виду используемой в приложении плат-
формы. Открытые системы предоставляют
разным приложениям разного рода услуги:
управление удаленными объектами, об-
служивание очередей и запросов, обра-
ботка интерфейсов и т.п. Доступ к услу-
гам осуществляется с помощью таких ме-
ханизмов:
– вызова удаленных процедур RPC
(Remote Procedure Call) в системах ОNС
SUN, OSF DSE [8];
– связывания распределенных объ-
ектов и документов в системе DCOM [9];
– языка описания интерфейса IDL
(Interface Definition Language) и брокера
объектных запросов – ORB (Object Request
Broker) в системе CORBA [10, 11];
– вызова RMI (Remote Methods In-
vocation) в системе JAVA [12] и др.
Удаленный вызов RPC задает ин-
терфейс к удаленным программам сети в
языках высокого или низкого уровней.
Язык высокого уровня определяет в RPC–
вызове параметры удаленной процедуры,
значения которых передаются ей сетевым
сообщением. Язык низкого уровня позво-
ляет указать более подробную информа-
цию удаленной процедуре, например, тип
протокола, размер буфера данных и т.п.
Взаимосвязь процесса с удаленно
расположенным другим процессом (на-
пример, сервером) на другом компьютере
выполняет сетевой протокол UDP или
TCP/IP для передачи параметров в stub–
интерфейсе клиента stub–интерфейсе
сервера для выполнения удаленной проце-
дуры.
Механизм посылки запроса в сис-
теме CORBA базируется на описании за-
проса в языке IDL для доступа к удален-
ному методу/функции через сетевой про-
токол IIOP или GIOP. Брокер ORB пере-
дает запрос генератору, посылает резуль-
тат stub / skeleton серверу, выполняю-
щему интерфейс средствами объектного
сервиса (Common Object Services) или
общими средствами (Common Facilities).
Так как брокер реализован в разных рас-
пределенных системах: CORBA, COM,
SOM, Nextstep и др., то он обеспечивает
интерфейс (взаимодействие) объектов в
разных сетевых средах.
Вызов метода RMI в системе
JAVA выполняет виртуальная машина
(virtual machine), которая интерпретирует
byte–коды программ, созданные разными
системами программирования ЯП (JAVA,
Pascal, C++) на компьютерах. Функции
RMI аналогичны брокеру ORB.
1.3. Интерфейс IDL как способ взаимо-
связи клиента и сервера
В распределенной среде интерфейс
реализуется двумя способами: на уровне
ЯП через вызовы удаленных программ и
интерфейсы в IDL, которые генерируются
компиляторами для клиентских и сервер-
ных stab’s. Интерфейс – это описание кли-
ентских и серверных stab в языке IDL, вы-
полняющих связь объекта–клиента с объ-
ектом-сервером и обратно. Интерфейсы
имеют отдельную реализацию и доступны
разноязыковым программам. Компиля-
торы с IDL как часть промежуточного слоя
реализуют связывание с ЯП через интер-
фейсы программ клиента и сервера, за-
данные в этом ЯП [10].
Интерфейсные программы в IDL
или в API включают в себя описание фор-
мальных и фактических параметров про-
грамм, их типов и порядка задания опера-
ций передачи параметров и результатов
для взаимодействующих программ. Это
описание есть ничто иное, как интерфейс-
ный посредник (stub для клиента и skeleton
Інструментальні засоби і середовища програмування
130
для сервера) двух разноязыковых про-
грамм (аналогично, как на рис.1), которые
взаимодействуют друг с другом через ме-
ханизм вызова двух типов программ
(клиента и сервера), выполняемых на раз-
ных процессах. Их описания отобража-
ются в те ЯП, в которых представлены
соответствующие им объекты или компо-
ненты.
В функции интерфейсного посред-
ника клиента входят:
– подготовка внешних параметров
клиента для обращения к сервису сервера,
– посылка параметров серверу и
его запуск в целях получения результата
или сведений об ошибке.
Общие функции интерфейсного по-
средника сервера состоят в следующем:
– получение сообщения от кли-
ента, запуск удаленной процедуры, вы-
числение результата и подготовка (коди-
рование или перекодирование) данных в
формате клиента;
– возврат результата клиенту через
параметры сообщения и уничтожение
удаленной процедуры и др.
Описание интерфейсного посред-
ника в языке IDL не зависит от ЯП взаи-
модействующих программ и в целом оди-
наково для всех вызывающих и вызывае-
мых программ или объектов. Типы пара-
метров в программе клиента в ЯП (C++,
Pascal и т.п.) передаются взаимодейст-
вующим процессам, ими могут быть: in –
входной параметр, out – выходной пара-
метр, inout – совместный параметр.
Описание интерфейсного посред-
ника в IDL начинается со слова interface, за
которым следует описание типов данных
(integer, boolean, string, float, char и др.).
Операции интерфейса включают в себя:
наименование операции, список парамет-
ров, типы аргументов и результатов, а
также управляющий параметр для случая
возникновения исключительной ситуации
и др. Это описание может наследоваться
другим объектом класса, становясь базо-
вым, и выполняется в среде CORBA, ко-
торая генерирует stub и skeleton для
взаимодействия программ клиента и сер-
вера.
2. Интерфейс и взаимосвязь ЯП
2.1. Формализация интерфейса
ЯП. Основные ЯП, используемые для опи-
сания компонентов в современных сре-
дах, – это С++, Паскаль, JAVA и др. [1, 2,
10, 13].
Разноязыковые программы в ЯП
обращаются друг к другу через удален-
ный вызов, являющийся интерфейсом
этих программ. Он устанавливает взаимно
однозначное соответствие между задан-
ными фактическими параметрами V=
{v1,v2,..,vк} вызывающей программы и
формальными параметрами F = {f1, f2 ,
..., fк1} вызываемой программы. При неод-
нородности одного из параметров из мно-
жества формальных или фактических па-
раметров разноязыковых программ необ-
ходимо провести отображение (mapping)
неэквивалентного типа данных параметра
в одном ЯП в соответствующий тип дан-
ных в другом ЯП.
Аналогично решается задача преоб-
разования неэквивалентных типов данных
ЯП. Представим ее так.
Этап 1. Построение операций пре-
образования типов данных T α = {Tα
t} во
множестве языков L = {lα }α=1, n .
Этап 2. Построение отображения
неэквивалентных простых типов данных
каждой пары lα1 и lα2. В случае отображе-
ния неэквивалентных сложных структур
данных в этих ЯП применяются опера-
ции селектора S или конструктора С.
Для преобразования типов данных
ЯП для каждого типа строится алгебраи-
ческая система такого вида: Gα
t = <Xα
t
,
Ωα
t >, где t∈ Tα
t – множество типов дан-
ных, Xα
t – множество значений, которые
могут принимать переменные этого t
типа данных, Ωα
t – множество операций
над этим типом данных.
Современные ЯП имеют следую-
щие простые типы данных t = b (bool), c
(char), i (int), r (real), а также сложные
типы данных t = a (array), z (record), u
(union), e (enum), как комбинации про-
стых типов данных. Простые и сложные
типы данных представим следующими
двумя классами алгебраических систем:
Інструментальні засоби і середовища програмування
131
Σ1 = { G α
b , Gα
c , Gα
i , Gα
r },
Σ2 = { Gα
a , Gα
z G α
u , Gα
e ...}.
Каждый элемент класса – это ал-
гебраическая система Gα
t = <Xα
t
, Ωα
t >,
заданная на множестве значений типов
данных (простых или сложных) и опера-
ций над ними. Преобразование t типа дан-
ных будем проводить путем изоморфного
отображения двух алгебраических систем
с совместимыми типами данных lα1 и lα2
языков, которые обладают следующими
свойствами:
1) системы Gα
t и Gβ
q для языков lα и
lb являются изоморфными, если типы дан-
ных q, t определены на множестве про-
стых или сложных типов данных.
2) между значениями Xα
t и Xβ
q
типов данных t, q существует изомор-
физм, если множества операций Ωα
t и Ωβ
q
для этих типов данных различны. Изо-
морфизм двух систем G α
t′ = < Xα
t , Ω >
и Gβ
q′ = < Xβ
q , Ω > имеет место, если
множество операций Ω = Ωα
t ∩ Ωβ
q не
пусто. Между множествами Xα
t и Xβ
q не
существует изоморфного соответствия в
случае, если тип данных t и q неэквива-
лентны. Например, t является строкой
цифр, а тип q – вещественное, тогда стро-
ится функция прямого и обратного преоб-
разования.
3) алгебраические системы Gα
t =
= Gβ
q равны по мощности, если они
представлены на множестве типов данных
языков lα и lb.
Отображение со свойствами 1), 2)
сохраняет линейный порядок элементов,
поскольку элементы множества алгебраи-
ческих систем линейно упорядочены.
2.2. Общая схема связи ЯП через
интерфейс. В виду неоднородности ЯП,
как в смысле представления в них типов
данных, так и их реализации системами
программирования на разных платформах
компьютеров, интерфейс имеет следую-
щие особенности:
– разные двоичные представления
результатов работы компиляторов для од-
ного и того же ЯП, реализованных на раз-
ных компьютерах;
– двунаправленность связей между
ЯП и их зависимость от среды и плат-
формы;
– отображение параметров вызо-
вов в операции методов;
– реализация ссылками на указа-
тели связей ЯП в компиляторах;
– связь между типами данных ЯП
осуществляется через интерфейсы для ка-
ждой пары из множества языков (L1, …,
Ln) (рис. 3).
Как видно из рис. 3, связь между
различными языками L1,…, Ln, осуществ-
ляется через интерфейс каждой пары
языков Li, Ln, который генерирует соот-
ветствующие конструкции языка Li в
язык Ln и наоборот. Она устанавливается с
учетом механизмов класса алгебраических
систем и функций преобразования неэкви-
валентных типов данных ЯП этих систем.
Рис.3. Связь между L1 , L2 , …, Ln через интерфейсы для каждой пары языков
Интерфейс L1 , L3
Интерфейс L1 , L4
Интерфейс L2 , L4
. . .
Интерфейс Li , Ln
L1 L3
L4
Ln
L2
Li
Інструментальні засоби і середовища програмування
132
2.3. Независимые от ЯП типы данных
стандарта ISO/IEC 11404–1996
Одним из способов решения про-
блемы интерфейса ЯП является стандарт
[14], который рекомендует определение
интерфейса для независимых от ЯП ти-
пов данных средствами стандартного языка
LI (Language Independent). Он объединяет
существующие типы данных ЯП, расши-
ряет их новыми типами и структурами,
предоставляет механизмы генерации но-
вых типов данных и преобразования ти-
пов данных ЯП в LI-язык и наоборот.
Стандарт задает правила и операции ге-
нерации примитивных типов данных и
объединений LI-языка в более простые
структуры данных ЯП, а также подходы к
определению интерфейса ЯП с помощью
языков IDL, RPC и API. Типы данных LI-
языка разделены на примитивные, агре-
гатные, сгенерированные (рис. 4). Кроме
того, LI-язык включает семейство данных
и механизмы генерации типов данных.
Типы данных в стандарте описыва-
ются в LI-языке, который претендует на
статус более общего языка описания ти-
пов данных ЯП, содержит все типы дан-
ных существующих ЯП и собственные
типы данных, с помощью которых генери-
руются новые отсутствующие типы дан-
ных. Он позволяет описывать параметры
вызова в интерфейсе для обращения к
стандартным сервисам и готовым про-
граммам. В стандарте содержатся средства
объявления разных типов данных, которые
включены в LI-язык. Кроме того, в нем
представлены 33 проблемы, которые ре-
шались при создании данного языка.
В [21, 22] LI-языке могут описы-
ваться типы данных и выполняться сле-
дующие виды преобразований:
– внешнее преобразование – типы
данных ЯП в LI-тип данных;
– внутреннее преобразование – из
LI-типа данных в тип данных ЯП;
– обратное преобразование.
Внешнее преобразование типов
данных и генераторов типов данных со-
стоит в следующем:
а) связывание сгенерированного
внешнего типа данных с LI-примитивным
типом данных;
в) установление связи между до-
пустимым значением типа данных ЯП и
эквивалентным LI-типом данных;
Рис. 4. Независимые от ЯП типы данных стандарта ISO/IEC 11404–1996
Стандартные
типы данных LI
Примитивные
типы данных LI
Типы
Логический,
перечислимый,
символьный,
целый,
рациональный,
действительный,
комплексный,
порядковый,
масштабный
Свойства
Равенства,
порядка,
кардиналь-
ности,
точные,
приближен-
ные
Агрегатные типы
данных LI
Типы
Запись,
набор,
портфель,
массив,
таблица
Свойства
Однородные,
размерность,
уникальность,
упорядочен-
ность,
доступность,
рекурсивность,
Сгенерированные
типы данных LI
Типы
Выбор,
указатель,
процедура
Інструментальні засоби і середовища програмування
133
с) определение значения внутрен-
него типа данных ЯП, участвующего в
преобразовании, к LI-типу данных.
Внутреннее преобразование
обеспечивает связь примитивного типа
данных или сгенерированного в LI-тип
данных с внутренним типом данных ЯП.
Представители LI-типов данных могут
преобразовываться в различные внутрен-
ние типы данных ЯП при условии, если
для каждого LI-типа данных (примитив-
ного или сгенерированного) имеется соот-
ветствующий тип данных в ЯП или уста-
новлено отношение между допустимым
значением его типа и эквивалентным зна-
чением соответствующего внутреннего
типа ЯП. Для внутреннего типа данных
ЯП стандарт определяет способ его пре-
образования в соответствующий LI-тип
данных.
Обратное внутреннее преобразо-
вание – это преобразование значений
внутреннего LI-типа данных в тип данных
ЯП и соответственно обратное преобразо-
вание типа данных ЯП в LI-тип данных.
3. Взаимодействие разноязыковых про-
грамм в современных средах
3.1. Интерфейс как средство
взаимодействия объектов. Интерфейс –
основа взаимодействия объектов в среде
CORBA. Он включает удаленный запрос
клиента на выполнение метода (функции,
сервиса, операции) или программы [11,
15–17]. Для обеспечения взаимодействия
ЯП осуществляется отображение типов
данных в типы данных клиентских и
серверных стабов путем:
– отображения запроса клиента в
ЯП в операции IDL;
– преобразования операций IDL в
конструкции ЯП и передачу их серверу
брокером ORB для реализации stub кли-
ента.
Так как ЯП системы CORBA могут
быть реализованы на разных платформах
и в разных средах, то их двоичное пред-
ставление зависит от конкретной аппарат-
ной платформы. Для всех ЯП системы
CORBA (С++, JAVA, Smalltalk, Visual
C++, COBOL, Ada–95) предусмотрен об-
щий механизм связи и расположения па-
раметров методов объектов в промежу-
точном слое. Связь между объектными
моделями каждого ЯП системы СОМ и
JAVA выполняет брокер ORB (рис. 5).
Если в общую объектную модель
CORBA входит объектная модель СОМ,
то в ней типы данных определяются ста-
тически, а конструирование сложных ти-
пов данных осуществляется только для
массивов и записей. Методы объектов ис-
пользуются в двоичном представлении,
допускается соответствие машинного кода
объекта, созданного в одной среде
разработки, коду другой среды, а также
совместимость разных ЯП за счет свой-
ства отделения интерфейсов объектов от
реализаций.
В случае вхождения в состав мо-
дели CORBA объектной модели JAVA/
RMI, вызов удаленного метода объекта
осуществляется посредством ссылок на
JAVA Система JAVA COBOL
Брокер ORB
Общая объектная
C++ модель Smalltalk
Visial C ++ Ada–95
Cистема СОМ
Рис. 5. Интегрированная среда систем CORBA, JAVA и COM
Інструментальні засоби і середовища програмування
134
объекты, задаваемые указателями на соот-
ветствующие адреса памяти.
Интерфейс как объектный тип реа-
лизуется классами и предоставляет уда-
ленный доступ к нему сервера.
Компилятор JAVA создает байт–
коды, которые интерпретируются вирту-
альной машиной, обеспечивающей пере-
носимость байт–кодов и однородность
представления данных на всех платформах
среды СORBA.
3.2. Взаимодействие разноязыко-
вых программ. Проблема взаимодействия
программ между собой постоянно возни-
кает в программировании, как только по-
являются новые ЯП и системы их под-
держки. Механизм связи разноязыковых
программ при этом решается каждый раз
индивидуально с учетом новых возможно-
стей реализаций ЯП. Так в руководстве
программиста [18] автором проделана ог-
ромная работа по исследованию про-
блемы взаимодействия разноязыковых
программ в классе современных ЯП
(C/C++, Visual C++, Visual Basic, Matlab,
Smalltalk, Lava, LabView, Perl), широко ис-
пользуемых в практике программирова-
ния. В книге объемом 868 страниц пред-
ставлено множество различных вариантов
конкретных примеров связей каждой пары
ЯП из класса ЯП. Эти варианты практиче-
ски реализованы и проверены на практике.
Они включают функции преобразова-
ния, методы обращения программы на
одном языке к программе на другом
языке и средства поддержки интерфейсов
(IDL, API и др.).
В таблице сведены проанализиро-
ванные варианты взаимосвязи в классе
приведенных ЯП и дана характеристика
особенностей их взаимодействия через
разные виды интерфейсов.
В приведенной таблице отображено
более 25 видов пар современных ЯП и со-
ответственно прямого и обратного взаимо-
Таблица. Интерфейс в классе современных языков программирования
Средства описания
Программ
Языки для
взаимодействия
Виды интерфейсов
Visual Basic – ANCI C
– C, C++
– Windows API
– DLL
– Visual Basic 6.0
– Win 32
–API Viewer
Платформенно–ориентированные
функции
Программный интерфейс
Динамическая библиотека функций
Интерфейс между Visual Basic
Функции обработки событий
Интерфейс в API
Matlab – C, C++
– Matlab Engine
– Mat lab в JNI
– Visual Basic 6.0
– Java
Вызов приложения из среды
Встраивание функций в VC++
Использование интерфейса JNI
Функции из Matlab
Функции в Java
Smalltalk – C++
– Matlab
– Start V1
Модель приложения в VisualWorks
Функции графической библиотеки
Библиотеки С, С++ и процедуры
VisualWorks
Lab View – ANCI C
– Visual C++
– Visual Basic 6.0
– C, C++
Интерфейс VI и API
Связь Visual C, DLL, Obj
Lib c, C++
Интерфейсные функции драйвера
JAVA – C, C++
– Visual C++
– Matlab
Платформенно–ориентированные
функции
Библиотеки функций в С++, С
Функции в JNI
Perl – C, C++
– API
– Visual C++
Платформенно–ориентированная
функции
Программный интерфейс
Интерфейсные функции в С++
Інструментальні засоби і середовища програмування
135
действия разноязыковых программ. Для
этих пар ЯП изложены принципы запуска
разных программ и все технические во-
просы передачи данных и преобразования
параметров. Материал книги содержит
многочисленные примеры интерфейсных
программ, которые разработаны для пре-
образования разнотипных параметров с
учетом особенностей их реализации сис-
темами программирования.
В отличие от рассмотренной общей
схемы взаимодействия программ с двумя
модулями (рис.1), здесь предложены вы-
сокотехничные средства обеспечения про-
цесса преобразования: панели, сценарии,
иконки и образцы интерфейсных про-
грамм для каждого конкретного случая
взаимодействия программ.
Далее дается краткое описание ос-
новных схем средств описания разноязы-
ковых программ (наименование средств –
первая колонка), взаимодействующих с
языками описания разноязыковых про-
грамм второй колонки таблицы.
Интерфейс между Visual Basic и
другими ЯП осуществляется с помощью
оператора обращения, параметрами кото-
рого могут быть строки, значения, мас-
сивы и другие типы данных. Их обработка
проводится с помощью функций Windows
API, API DLL и операций преобразования
типов данных. Проверка интерфейса про-
ведена для схемы обработки Интернет-
приложений, задаваемых HTML-страни-
цами BasicVisual и размещаемых в Web-
браузере и БД.
Система Matlab содержит средства
для решения задач линейной и нелинейной
алгебры, действий над матрицами и др. и
обеспечивает математические вычисления
с помощью MatlabCompiler, Matlab C++,
MatlabLibriary, Matlab Graphic Library.
Схема независимого приложения в среде
Matlab включает интерфейс между VC и
Matlab, создаваемый MatlabCompiler пу-
тем преобразования программы в формате
Matlab (М- файлы или М-функции) в фор-
мат С. Сформированный файл вызывается
из программы на С++ и преобразуется к
виду архитектуры компьютера, куда посы-
лается результат.
Базовые средства Smalltalk обес-
печивают создание приложений в среде
VisualWorks и включают: модель прило-
жений, методы объектов, сообщения для
передачи значений внешним объектам и
пользовательский интерфейс (рис. 6). Мо-
дель приложения содержит функции DLL
из класса внешнего интерфейса, элементы
которого применяются для взаимодейст-
вия с функциями преобразования библио-
теки С++. В эту библиотеку помещаются
результаты обработки атрибутов парамет-
ров объектов модели домена.
Система LabView предназначена
для автоматизации производственных
процессов, сбора данных, проведения из-
мерений и управление созданием про-
грамм, взаимодействующих с аппаратурой.
В ее состав входит прикладные
средства, тестирования программ и
драйверы взаимодействия с аппаратурой,
запускаемых с пульта. Система
взаимодействует с ANS C, Visual Basic,
Visual C++ Lab Windows/CV. Эти средства
расширяют возможности создания систем
Модель приложения
Методы Пользовательский
интерфейс
Сообщение Возврат
атрибута
Библиотека С++
Метод обработки – mMax,
атрибута объекта – атрибуты,
модели – модели доменов
Рис. 6. Схема взаимодействия модели приложения с библиотекой
Інструментальні засоби і середовища програмування
136
реального времени, которые позволяют
производить измерение аппаратуры типа:
регуляторы, термометры, переключатели и
др. Результаты измерений могут пере-
даваться по сети.
Среда Java содержит инструменты
взаимодействия со всеми языками, приве-
денными во второй колонке таблицы.
Общая схема связи языков JAVA и C,
C++ при взаимодействии соответствую-
щих программ показана на рис. 7.
Язык Perl появился в 80–х годах
прошлого столетия как язык задания
сценариев для взаимодействия с Интернет,
управления задачами и создания CGI –
сценариев на сервере в системе Unix.
Данный язык имеет интрфейс с С.С++б,
Visual Basic и Java. Интерпретатор с языка
Perl написан в языке С и каждый ин-
терфейс с другим языком рассматривается
как расширение, представляемое процеду-
рами динамической библиотеки. Оператор
вызова программы в С или С++ преобра-
зуется в специальный код, который также
размещается в библиотеке интерпретатора
Perl. Сам интерпретатор может быть вклю-
чен в Win 32 или в программу на C/C++.
Рассмотренные схемы взаимодей-
ствия современных средств и класса ЯП
для представления разноязыковых про-
грамм рекомендуются для практического
применения, так как они эксперимен-
тально проверены на многочисленных
примерах.
4. Интерфейс платформенного преобра-
зования данных
Программы, расположенные на
разных типах компьютеров сети, передают
друг другу данные через интерфейсные
протоколы. Переданные данные в фор-
мате одного компьютера преобразуется к
формату данных (так называемая проце-
дура маршалинга данных) принимающей
серверной платформы с учетом порядка и
стратегии выравнивания, принятой на ней.
Демаршалинг данных обеспечивает об-
ратное преобразование полученного на
сервере результата к виду клиентской про-
граммы. Если среди передаваемых пара-
метров в операторе вызова оказались не-
релевантные типы данных, то осуществ-
ляется прямое и обратное их преобразо-
вание средствами ЯП или стандарта [14].
К средствам преобразования дан-
ных и их форматов относятся:
– стандарты кодировки данных
(XDR – eXternal Data Representation [8],
CDR – Common Representation Data [10,
11], NDR – Net Data Representation [19],
XML [20]) и методы их преобразования;
– механизмы обращения компо-
нентов друг к другу;
– языки описания интерфейсов
компонентов – RPC, IDL и RMI для пере-
дачи данных между разными компонен-
тами [21, 22].
На каждой платформе компьютера
используются соглашения о кодировке
символов, о форматах целых чисел и чисел
с плавающей точкой (например, IEEE,
VAX и др.). При представлении целых ти-
пов, как правило, используется дополни-
тельный код, а для типов float и double –
стандарт ANSI / IEEE и др. [21].
Порядок расположения байтов за-
висит от структуры платформы (Big
Endian или Little Endian) и устанавлива-
Приложение Java Native Виртуальная Платформенно–
в Java Interface (JNI) машина ориентированные
библиотеки С, С++
Программа Интерфейсные
на языке Java функции в С, С++
Рис. 7. Схема взаимодействия приложения и программы Java, C и C++
Інструментальні засоби і середовища програмування
137
ется от старшего к младшему байту или от
младшего байта к старшему. Процессоры
UltraSPARC и PowerPC поддерживают обе
возможности. При передаче данных с од-
ной платформы на другую учитывается
возможное несовпадение порядка байтов.
Маршаллинг данных поддерживается не-
сколькими стандартами, которые рас-
смотрены далее.
XDR–стандарт содержит язык опи-
сания структур данных произвольной
сложности и средства преобразования
данных, передаваемых на платформы
(Sun, VAX, IBM и др.). Программы в лю-
бом ЯП могут использовать данные в
XDR–формате с учетом того, что компи-
ляторы выравнивают их в памяти ма-
шины по–разному.
В XDR–стандарте целые числа с
порядком "от младшего" приводятся к по-
рядку байтов «от старшего» и обратно.
Преобразование данных – кодирование
(code) или декодирование (decode) – дан-
ных выполняется с помощью XDR–проце-
дур. Кодирование – это преобразование из
локального представления в XDR–пред-
ставление и запись в XDR–блок. Декоди-
рование – это чтение данных из XDR–
блока и преобразование в локальное пред-
ставление заданной платформы.
Выравнивание данных состоит в
размещении значений базовых типов с ад-
реса, кратного (2, 4, 8, 16) по границе с
наибольшей длиною (например, 16). Сис-
темные процедуры оптимизируют распо-
ложение полей памяти под сложные
структуры данных и преобразуют их к
формату принимающей платформы. Об-
работанные данные декодируются об-
ратно к виду формата платформы, отпра-
вившей эти данные.
CDR–cтандарт обеспечивает пре-
образование данных в форматы передаю-
щей и принимающей платформ в среде
CORBA. Маршаллинг данных выполня-
ется интерпретатором TypeCode и броке-
ром ORB. Процедуры преобразования
сложных типов включают в себя:
– дополнительные коды для пред-
ставления целых чисел и чисел с плаваю-
щей точкой (стандарт ANSI / IEEE);
– схему выравнивания значений
базовых типов в среде компилятора;
– базовые типы (signed и unsigned)
языка IDL, а также плавающий тип двой-
ной точности и др.
Преобразование данных выполня-
ются процедурами encoder (…) и decoder
(…) интерпретатора TypeCode с помощью
базовых примитивов выравнивания ин-
формации и помещения ее в буфер. Для
сложного типа вычисляется размер и гра-
ницы выравнивания, выполняется их раз-
мещение в таблице TCKind с индексами
значений, которая используется при
инициализации брокера ORB.
ХМL–стандарт устраняет неодно-
родность во взаимосвязях компонентов в
разных ЯП с помощью XML–формата
данных. Он учитывает разные платформ
и среды (CORBA, DCOM, JAVA и др.),
которые имеют в своем составе функ-
ции, аналогичные XML. Данный стандарт
имеет различные системные поддержки:
браузер – Internet Explorer для визуализа-
ции XML–документов, объектная модель
DOM (Document Object Model) для ото-
бражения XML–документов и интерфейс
IDL в системе CORBA.
Тексты в XML описываются в
формате ASCII, что дает возможность бо-
лее эффективно применять их при обмене
данными и кодировании типов данных с
помощью файловых форматов. Переход
программной системы к XML–стандарту
предполагает переформатирование дан-
ных в формат XML и обратно.
Таким образом, XML–язык позво-
ляет представлять объекты для разных
объектных моделей на единой концепту-
альной, синтаксической и семантической
основе. Он не зависит от платформы и
среды взаимодействия, имеет стандарт-
ные методы и средства (XML–парсери,
DOM–интерфейсы, XSL–отображение
XML в HTML и др.).
Інструментальні засоби і середовища програмування
138
5. Перспективы развития проблематики
интерфейса
Дальнейшее развитие методов и
средств интерфейса обусловлено созда-
нием:
– новых интерфейсных языков
(Domain Specific Langiage) для взаимодей-
ствия доменов и предметных областей,
объекты которых можно будет динамиче-
ски изменять и синхронизировать в рас-
пределенных средах;
– языково–ориентированного
программирования предметных областей
типа Language Workbench, включающего
подмножество языков описания специ-
альных задач предметной области и их ге-
нерации к языкам типа XML;
– интегрированной среды под-
держки генерирующего программирова-
ния на основе IDE Eclipse и систем UML,
Aspect, Junit, Corba, Java, СУБД,
GreenStone и др.
1. Лаврищева Е.М., Грищенко В.Н. Связь
разноязыковых модулей в ОС ЕС.– М:
Финансы и статистика, 1982.–127 с.
2. Лаврищева Е.М., Грищенко В.М. Сбороч-
ное программирование.– Киев.– Наук.
думка, 1991. –213 с.
3. OSI 7498 –1989. Open System Interconnec-
tion.– Basic Reference Model. – Technical
Report, Iinternational Standartization Or-
ganization.
4. Open Software Foundation. Inroduce to
Disributed Computed Environments.– En-
glewood Cliffs: Prentice Hall, 1993.– 437 p.
5. Буч Г. Объектно-ориентированный ана-
лиз .– М.: Бином, 1998. – 560 с.
6. Wegner P. Interaction Foundation of Object–
oriented Programming ECOOP–97 th Euro-
pian Conference on OOP Finland, June 9–12,
1997.– C. 123–139.
7. Letichevsky A.A., Gilbert D.R . A General
Theory of Action Language // Кибернетика
и системный анализ. – 1998. – № 1.–
С. 16 – 36.
8. Летичевский А.А., Капитонова Ю.В. и
др. Инсерционное программирование //
Там же.– 2003.– № 1.– C. 12–32.
9. Corbin J. The art of Distributed Application.
Programming Techn. For Remote Procedure
Calls.– Berlin: Springer Verlag, 1992.–
305 p.
10. Роджерсон Д. Основы СОМ. Русск..пер.–
Microsoft Press,1996.– 361 c.
11. Эммерих В. Конструирование распре-
деленных объектов // Методы и средства
программирования интероперабельных
объектов в архитектурах OMG/CORBA,
Microsoft COM и Java RMI. – М.: Мир,
2002. – 510 с.
12. Сигел Дж. CORBA 3. – М.: Малип, 2002.
– 412 c.
13. Барлет Н., Лесли А., Симкин С. Програм-
мирование на JAVA // Путеводитель.–
Киев.–1996.– 736 с.
14. Лаврищева Е.М. Методы программирова-
ния // Теория, инженерия, практика.– К .:
Наук. думка, 2006. – 451 с.
15. Гост 30664 (ИСО/МЭК 11404:1996). Ин-
формационные технологии. Языки про-
граммирования, их среда и системный ин-
терфейс // Независимые от языков типы
данных.– 2000. – 109 с.
16. Бакалов Ю.В., Смелянский Р. Л. Язык спе-
цификации распределенных программ //
Программирование.– 1996.– № 5.–
C. 41-52.
17. Цимбал А., Аншина М. Технология созда-
ния распределенных систем. – Пи-
тер*Санкт–Петербург* Москва* Харьков*
Минск, 2003.– 575 с.
18. Бабенко Л.П., Лаврищева Е.М. Основы
программной инженерии.– Киев: Знание,
2001.– 269 с.
19. Бей И. Взаимодействие разноязыковых
программ // Руководство программиста.–
М.: Издательский дом «Вильямс», Мо-
сква–Санкт–Петербург–Киев, 2005. –
868 с.
20. Просиз Дж. Программирование для
Microsoft .NET. – М.: Издательско–торго-
вый дом “Русская Редакция”, 2003. –
704 с.
21. Питц–Моултис Н., Кирк Ч. XML: Пер. с
англ. – СПб.: BHV–Санкт–Петербург,
2000.– 736 с.
22. Иванников В.П., Дышлевый К.В., Мажелей
С.Г и др. Распределенные объектно–ори-
ентированные среды. – Москва //
РАН.ИСП. Труды ИСП, 2000.– C. 84–100.
23. Иванова Е. Б., Вершинин М.М. Java 2,
Enterprise Edition. Технологии проектиро-
вания и разработки. – СПб.: БХВ–Петер-
бург, 2003. – 1088 с.
Получено 23.04.2007
Інструментальні засоби і середовища програмування
139
Об авторе:
Лаврищева Екатерина Михайловна,
заведующая отделом, доктор физико-
математических наук, профессор.
Место работы автора:
Институт программных систем
НАН Украины, 03680,
Киек–187, Украина,
проспект Академика Глушкова, 40.
тел. 526 3470
|
| id | nasplib_isofts_kiev_ua-123456789-293 |
| institution | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| issn | 1727-4907 |
| language | Russian |
| last_indexed | 2025-11-27T10:59:48Z |
| publishDate | 2007 |
| publisher | Інститут програмних систем НАН України |
| record_format | dspace |
| spelling | Лаврищева, Е.М. 2008-02-22T19:01:35Z 2008-02-22T19:01:35Z 2007 Интерфейс в программировании / Е.М. Лаврищева // Пробл. програмув. — 2007. — N 2. — C 126-139. — Библиогр.: 23 назв. — рус. 1727-4907 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/293 Рассмотрены базовые понятия интерфейса, подходы к обеспечению интерфейса языков программирования (ЯП) и взаимодействия разноязыковых программ и данных. Определены общие проблемы неоднородности ЯП, платформ компьютеров и сред, влияющие на выполнение связей между разноязыковыми программами, сформулированы пути их решения. Изложены стандартные решения ISO/IEC 11404-1996 по обеспечению независимых от ЯП типов данных и стандарты преобразования форматов данных. ru Інститут програмних систем НАН України Інструментальні засоби і середовища програмування Интерфейс в программировании Article published earlier |
| spellingShingle | Интерфейс в программировании Лаврищева, Е.М. Інструментальні засоби і середовища програмування |
| title | Интерфейс в программировании |
| title_full | Интерфейс в программировании |
| title_fullStr | Интерфейс в программировании |
| title_full_unstemmed | Интерфейс в программировании |
| title_short | Интерфейс в программировании |
| title_sort | интерфейс в программировании |
| topic | Інструментальні засоби і середовища програмування |
| topic_facet | Інструментальні засоби і середовища програмування |
| url | https://nasplib.isofts.kiev.ua/handle/123456789/293 |
| work_keys_str_mv | AT lavriŝevaem interfeisvprogrammirovanii |