Московский физико-технический институт
Опубликован: 24.09.2008 | Доступ: свободный | Студентов: 2909 / 939 | Оценка: 4.52 / 4.48 | Длительность: 25:15:00
Специальности: Системный архитектор
Лекция 9:

Интерфейсы, взаимодействие и изменение программ и данных

< Лекция 8 || Лекция 9: 12345 || Лекция 10 >
Аннотация: Рассмотрены основы интеграции и преобразования разноязыковых программ и данных, методы изменения (реинженерия, реверсная инженерия и рефакторинг) компонентов и систем, дана характеристика стандарта о независимости типов и структур данных от языков программирования, а также рассмотрены принципы взаимодействия неоднородных компонентов в современных промежуточных средах

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

Определены общие задачи неоднородности ЯП, платформ и сред, влияющих на установление связей между разноязыковыми программами, сформулированы пути их решения. Рассмотрены рекомендации стандарта ISO/IEC 11404-1996 по обеспечению независимых от современных ЯП типов данных.

Рассмотрены подходы к преобразованию форматов данных и данных в БД, а также методы изменения (эволюции) программ.

8.1. Задачи интерфейса при разработке программ

Общее определение. Интерфейс - это связь двух отдельных сущностей. Виды интерфейсов: языковые, программные, аппаратные, пользовательские, цифровые и т. п. Программный (API) и/или аппаратный интерфейс (port) - это способы преобразования входных/выходных данных во время объединения компьютера с периферийным оборудованием. В ЯП - это программа или часть программы, в которой определяются константы, переменные, параметры и структуры данных для передачи другим.

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

В случае, когда один из элементов (программа, процедура или функция) записаны на разных ЯП и, кроме того, если они располагаются на разных компьютерах, то возникают проблемы неоднородности типов данных в этих ЯП, структур памяти платформ компьютеров и операционных сред, где они выполняются. Понятие интерфейса, как самостоятельного объекта, сформировалось в связи со сборкой или объединением разноязыковых программ и модулей в монолитную систему на больших ЭВМ (mainframes) [8.1, 8.2].

Схема вызова модулей А и В из С через интерфейсы А'и B'

Рис. 8.1. Схема вызова модулей А и В из С через интерфейсы А'и B'

Интерфейс играл роль посредника между вызываемым и вызывающим модулями. В нем давалось описание формальных и фактических параметров, производилась проверка соответствия передаваемых параметров (количества и порядка расположения), а также их типов данных. Если типы данных параметров оказывались не релевантными (например, передается целое, а результат функции - вещественное или наоборот), то производилось прямое и обратное их преобразование с учетом структуры памяти компьютеров. На рис. 8.1 приведена схема программы C, в которой содержатся два вызова - Call\;A() и Call\;B() с параметрами, которые через интерфейсные модули-посредники A^\prime и B^\prime производят преобразование данных и их передачу модулям А и В. После выполнения А и В результаты преобразуются обратно к виду программы С.

8.1.1. Интерфейс в ООП и в современных средах

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

Таблица 8.1. Структура представления класса и интерфейса
Класс
Внешнее представление Внутреннее представление
Интерфейсные операции:
  • публичные, доступные всем клиентам:
  • защищенные, доступные классу п подклассу:
  • приватные, доступные классу.
Реализация операций класса, определение поведения.

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

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

Новое толкование интерфейса объектов дано в работе П.Вегнера [8.3], который сформулировал парадигму перехода от алгоритмоввычислений к взаимодействию объектов. Суть этой парадигмы заключалась в том, что вычисление и взаимодействие объектов рассматривались как две ортогональные концепции. Взаимодействие - это некоторое действие ( action ), но не вычисление, а сообщение - не алгоритм, а действие, ответ на которое зависит от последовательности операций ( Op ), влияющих на состоянии разделенной ( shared\; state, ss ) памяти локальной программы (рис. 8.3). Операции интерфейса ( Op1 и Op2 ) относятся к классу неалгоритмических и обеспечивают взаимодействие объектов через сообщения.

Интерфейс взаимодействия через операции интерфейса (по Вегнеру)

увеличить изображение
Рис. 8.3. Интерфейс взаимодействия через операции интерфейса (по Вегнеру)

Вегнер рассматривает модель взаимодействия, как обобщение машины Тьюринга - распределенной интерактивной модели взаимодействия объектов с входными (input) и выходными (output) действиями и возможностью продвижения в ней потенциально бесконечного входного потока (запросов, пакетов) в заданном интервале времени.

Дальнейшим развитием идеи взаимодействия, основанного на действиях, является язык AL (Action language), обеспечиывющий вызовов процедур (локальных или распределенных) с разверткой каждого вызова в программу [8.4], состоящую из операторов действий. Программа из вызовов процедур рассматривается в AL как ограниченное множество конечных программ, взаимодействующих со средой, в которую они погружаются.

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

Сети строятся на основе стандартной семиуровневой модели открытых систем OSI (Open Systems Interconnection) [8.5]. Объекты уровней в этой модели связываются между собой по горизонтали и вертикали. Запросы от приложений поступают на уровень представления данных для их кодирования (перекодирования) к виду используемой в приложении платформы. Открытые системы предоставляют любым приложениям разного рода услуги: управление удаленными объектами, обслуживание очередей и запросов, обработка интерфейсов и т. п.

Доступ к услугам осуществляется с помощью разных механизмов:

  • вызова удаленных процедур RPC (Remote Procedure Call) в системах ОNС SUN, OSF DSE [8.5, 8.6];
  • связывания распределенных объектов и документов в системе DCOM [8.7];
  • языка описания интерфейса IDL (Interface Definition Language) и брокера объектных запросов - ORB (Object Request Broker) в системе CОRBA [8.8];
  • вызова RMI (Remote Methods Invocation) в системе JAVA [8.9, 8.10] и др.

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

Взаимосвязь процесса с удаленно расположенным от него другим процессом (например, сервером) на другом компьютере выполняет протокол UDP или TCP/IP, который передает параметры в stub- интерфейсе клиента stub-серверу для выполнения удаленной процедуры.

Механизм посылки запроса в системе CORBA базируется на описании запроса в языке IDL для доступа к удаленному методу/функции через протокол IIOP или GIOP. Брокер ORB передает запрос генератору, затем посылает stub/skeleton серверу, выполняющему интерфейс средствами объектного сервиса (Common Object Services) или общими средствами (Common Facilities). Так как брокер реализован в разных распределенных системах: CORBA, COM, SOM, Nextstep и др. [8.2], то он обеспечивает взаимодействие объектов в разных сетевых средах.

Вызов метода RMI в системе JAVA выполняет виртуальная машина (virtual machine), которая интерпретирует byte-коды вызванной программы, созданные разными системами программирования ЯП (JAVA, Pascal, С++) на разных компьютерах и средах. Функции RMI аналогичны брокеру ORB.

8.1.2. Интерфейс в среде клиента и сервера

В распределенной среде реализуется два способа связывания: на уровне ЯП через интерфейсы прикладного программирования и компиляторов IDL, генерирующих клиентские и серверные Stab. Интерфейсы определяются в языках IDL или APL, динамический интерфейс от объектаклиента к объектусервера и обратно выполняет брокер ORB. Интерфейсы имеют отдельную реализацию на ЯП и доступны разноязыковым программам. Компиляторы с IDL как часть промежуточного слоя сами реализуют связывание с ЯП через интерфейс клиента и сервера, заданного в том же ЯП [8.8, 8.11-8.13].

Интерфейс в IDL или в API включает описание формальных и фактических параметров программ, их типов и порядка задания операций передачи параметров и результатов при их взаимодействии. Это описание есть не что иное, как спецификация интерфейсного посредника двух разноязыковых программ (аналогично, как на рис. 8.1), которые взаимодействуют друг с другом через механизм вызова интерфейсных функций или посредников двух типов программ (клиент и сервер), выполняемых на разных процессах.

В функции интерфейсного посредника клиента входят:

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

Общие функции интерфейсного посредника сервера состоят в следующем:

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

Описание интерфейсного посредника не зависит от ЯП взаимодействующих объектов и в целом одинаково для всех вызывающих и вызываемых объектов. Посредник описывается в языке спецификации интерфейса IDL.

Интерфейсные посредники задают связь между клиентом и сервером (stub для клиента и skeleton для сервера). Их описания отображаются в те ЯП, в которых представлены соответствующие им объекты или компоненты. Эти интерфейсы используются в системах CORBA, DCOM, LAVA и др. Они предоставляют всевозможные сервисы разработки и выполнения приложений в распределенной среде. Системные сервисы подключаются к приложению с помощью брокера. Брокер обеспечивает интероперабельность компонентов и объектов при переходе из одной среды другую.

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

К средствам обеспечения интероперабельности и передачи данных между разными средами и платформами относится, например, стандартный механизм связи между JAVA и C/C++ компонентами, основанный на применении концепции Java Native Interface (JNI), реализованной как средство обращения к функциям из JAVA- классов и библиотек, разработанных на других языках.

Эти средства включает в себя анализ JAVA-классов в целях поиска прототипов обращений к функциям, реализованных на языках C/C++, и генерацию заголовочных файлов для использования их при компиляции C/C++ программ. В средстве JAVA классу известно, что в нем содержится обращение не к JAVA-методу (он называется native и для загрузки необходимых C/C++ библиотек добавляется вызов функции), ориентируется именно на такую связь. Данная схема действует в одном направлении - от JAVA к C/C++ и только для такой комбинации ЯП.

Еще вариант реализации аналогичной задачи предлагает технология Bridge2Java,которая обеспечивает обращение из JAVA- классов к COM-компонентам. В этих целях генерируется оболочка для COM-компонента, который включает прокси-класс, обеспечивает необходимое преобразование данных средствами стандартной библиотеки преобразований типов. Данная схема не требует изменений в исходном Java-классе и COM-компоненты могут быть написаны в разных языках.

Механизм интероперабельности реализован также на платформе . Net с помощью языка CLR (Common Language Runtime). В этот язык транслируются коды, написанные в разных ЯП (C#, Visual Basic, C++, Jscript). CLR разрешает не только интегрировать компоненты, разработанные в разных ЯП, а и использовать библиотеку стандартных классов независимо от языка реализации.

Такой подход позволяет реализовать доступ к компонентам, которые были разработаны раньше без ориентации на платформу . Net, например к COM-компонентам. Для этого используются стандартные средства генерации оболочки для COM-компонента, с помощью которой он представляется как . Net-компонент. При такой схеме реализуются все виды связей и для любых ЯП данной среды.

< Лекция 8 || Лекция 9: 12345 || Лекция 10 >
Александр Медов
Александр Медов

Здравствуйте,при покупке печатной формы сертификата,будут ли выданы обе печатные сторны?

Александр Медов
Александр Медов

Здравствуйте, прошел курс МБА Управление ИТ-проектами и направил документы на получение диплома почтой. Подскажите, сроки получения оного в бумажной форме?

:

Михаил Першаков
Михаил Першаков
Россия, Perm