К. М. Лавріщева програмна інженерія підручник Київ, 2008
 Скачать 5.23 Mb.
|
|
7.1.1. Інтерфейси в сучасних середовищах Інтерфейс об’єктів. В об’єктно-орієнтованому програмуванні головним елементом є клас, що містить у собі безліч об'єктів з однаковими властивостями, операціями і відношеннями. Він має внутрішнє (реалізацію) і зовнішнє подання, а саме, інтерфейсні операції (рис. 7.2.). Клас Зовнішнє подання Внутрішнє подання Інтерфейсні операції: – публічні, доступні всім клієнтам; – захищені, доступні класу і підкласу; – приватні, доступні класу Реалізація операцій класу визначення поведінки Рис. 7.2. Структура представлення класу Інтерфейсні операції описують поведінку класу. Клас може підтримувати декілька інтерфейсів, кожний з яких має операції і сигнали, які використовуються для завдання послуг класу або програмного компонента. Інтерфейс іменує множину операцій або визначає їхню сигнатуру і результуючі дії. Якщо інтерфейс реалізується за допомогою класу, то він успадковує всі його операції. Одні і ті ж операції можуть з'являтися в різних інтерфейсах. Якщо їхні сигнатури збігаються, то вони задають одну і ту ж операцію, відповідну поведінці системи. Клас може реалізувати інший клас через інтерфейс. 186 Розділ 7 Операції сигнатури можуть бути зв'язані відношеннями узагальнення. Інтерфейс-нащадок містить у собі всі операції і сигнали своїх батьків і може додавати власні шляхом успадкування всіх операцій прямого предка, тобто його реалізацію можна розглядати як спадковість поведінки. Нове тлумачення інтерфейсу об'єктів наведено в праці П. Вегнера [3], який сформулював парадигму переходу від алгоритмів обчислень до взаємодії об'єктів. Суть цієї парадигми полягала в тому, що обчислення і взаємодія об'єктів розглядалися як дві ортогональні концепції. Взаємодія – це деяка дія (action), але не обчислення, а повідомлення – не алгоритм, а дія, відповідь на яку залежить від послідовності операцій (Op), що впливають на стан розподіленої (shared state) пам'яті локальної програми (рис. 7.3). Операції інтерфейсу (Op 1 і Op 2 ) належать до класу неалгоритмічних і забезпечують взаємодію об'єктів через повідомлення. Рис.7.3. Інтерфейс взаємодії через операції інтерфейсу (за Вегнером) Вегнер розглядає модель взаємодії як узагальнення машини Т'юрінга – розподіленої інтерактивної моделі взаємодії об'єктів з вхідними (input) і вихідними (output) діями і можливістю просування в ній потенційно нескінченного вхідного потоку (запитів, пакетів) в заданому інтервалі часу. Подальшим розвитком ідеї взаємодії, грунтованого на діях, є мова AL (Action language), яка забезпечує виклики процедур (локальних або розподілених) з розгорткою кожного виклику в програму [4], що складається з операторів дій. Програма з викликів процедур розглядається в AL як обмежена множина скінченних програм, що взаємодіють з середовищем, в якому вони працюють. Інтерфейс в сучасних середовищах і мережах. Поява різних комп'ютерів і їхнє об'єднання в локальні і глобальні мережі привела до уточнення поняття інтерфейсу як віддаленого виклику (повідомлення) програм, які розташовані в різних вузлах мережі або середовища і отримують вхідні дані з повідомлень. Мережі будуються на основі стандартної семирівневої моделі відкритих систем OSI (Open Systems Interconnection) [5]. Об'єкти рівнів у цій моделі зв'язуються між собою по горизонталі і вертикалі. Запити від застосувань надходять на рівень представлення даних для їхнього кодування (перекодування) до виду платформи, що використовується в застосуванні. Відкриті системи надають будь-яким застосуванням різного роду послуги: керування віддаленими об'єктами, обслуговування черг і запитів, обробка інтерфейсів і т.п. Розділ 7 187 Доступ до послуг здійснюється за допомогою різних механізмів: – виклику віддалених процедур RPC (Remote Procedure Call) в системах ОNС SUN, OSF DSE [5, 6]; – скріплення розподілених об'єктів і документів в системі DCOM [7]; – мови опису інтерфейсу IDL (Interface Definition Language) з підтримкою його брокером – ORB (Object Request Broker) в системі CОRBA [8]; – виклику RMI (Remote Methods Invocation) в системі JAVA [9, 10] і ін. RPC-виклик задає інтерфейс віддаленим програмам у мовах високого або низького рівня. Мова високого рівня слугує для подання в RPC-виклику параметрів віддаленої процедури, які передаються їй через мережне повідомлення. Мова низького рівня дозволяє надавати докладнішу інформацію віддаленій процедурі: тип протоколу, розмір буфера даних і т.п. Взаємозв'язок процесу з віддалено розташованим від нього іншим процесом (наприклад, сервером) на іншому комп'ютері виконує протокол UDP або TCP/IP, який передає параметри в stub–інтерфейсі клієнта stub-серверу для виконання віддаленої процедури. Механізм посилання запиту в системі CORBA базується на описі запиту в мові IDL для доступу до віддаленого методу/функції через протокол IIOP або GIOP. Брокер ORB передає запит генератору, потім посилає stub/skeleton серверу, що реалізує інтерфейс засобами об'єктного сервісу (Common Object Services) або загальними засобами (Common Facilities). Оскільки брокер реалізовано в різних розподілених системах: CORBA, COM, SOM, Nextstep і ін.[11], то він забезпечує взаємодію об'єктів в різних мережних середовищах. Виклик методу RMI в системі JAVA виконує віртуальна машина (virtual machine), яка інтерпретує byte-коди програми, що викликаються, створені різними системами програмування МП (JAVA, Pascal, С++) на різних комп'ютерах і середовищах. Функції RMI аналогічні брокеру ORB. 7.1.2. Інтерфейс між клієнтом і сервером У розподіленому середовищі реалізується два способи зв’язування: на рівні МП через інтерфейси прикладного програмування і компілятори IDL, що генерують клієнтські і серверні Stab. Інтерфейси визначаються в мові IDL або APL, динамічний інтерфейс від об'єкта-клієнта до объекта-сервера і назад виконує брокер ORB. Інтерфейси мають окрему реалізацію на МП і доступні різномовним програмам. Компілятори з IDL як частина проміжного рівня самі реалізують зв’язування з МП через інтерфейс клієнта і сервера, заданого в тому ж МП [8, 11– 14]. Інтерфейс в IDL або в API вміщує опис формальних і фактичних параметрів програм, їхніх типів і порядку завдання операцій передачі параметрів і результатів при їхній взаємодії. Цей опис є не що інше, як специфікація інтерфейсного посередника двох різномовних програм (аналогічно до рис. 7.1), які взаємодіють один з одним через механізм виклику інтерфейсних функцій або посередників двох типів програм (клієнт і сервер), що виконуються на різних процесах. До функції інтерфейсного посередника клієнта належать: – підготовка зовнішніх параметрів клієнта для звернення до сервісу сервера, – посилка параметрів сервера і його запуск в цілях отримання результатів або відомостей про помилку. 188 Розділ 7 Загальні функції інтерфейсного посередника сервера забезпечують: – отримання повідомлення від клієнта, запуск віддаленої процедури, обчислення результату і підготовка (кодування або перекодування) даних у форматі клієнта; – повернення результату клієнту через параметри повідомлення і знищення віддаленої процедури і ін. Опис інтерфейсного посередника не залежить від МП взаємодіючих об'єктів і в цілому однаковий для всіх об'єктів, що викликають або викликаються. Посередник описується в мові специфікації інтерфейсу IDL. Інтерфейсні посередники задають зв'язок між клієнтом і сервером (stub для клієнта і skeleton для сервера). Їхні описи відображаються в тих МП, в яких представлено відповідні їм об'єкти або компоненти. Ці інтерфейси використовуються в системах CORBA, DCOM, JAVA та ін. Вони надають різні сервіси розробки і виконання застосувань в розподіленому середовищі. Системні сервіси підключаються до застосування за допомогою брокера. Брокер забезпечує інтероперабельність компонентів і об'єктів при переході з одного середовища в інше. Під інтероперабельністю розуміють здатність сумісної, узгодженої взаємодії різнорідних компонентів системи для вирішення певної задачі. До засобів забезпечення інтероперабельності і передачі даних між різними середовищами і платформами належить, наприклад, стандартний механізм зв'язку між 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++, J#). CLR дозволяє не тільки інтегрувати компоненти, розроблені в різних МП, а й використовувати бібліотеку стандартних класів незалежно від мови реалізації. Такий підхід дозволяє реалізувати доступ до компонентів, які були розроблені раніше без орієнтації на платформу .Net, наприклад, до COM- компонентів. Для цього використовуються стандартні засоби генерації оболонки для COM-компонента, за допомогою якої він представляється як .Net–компонент. Розділ 7 189 При такій схемі реалізуються всі види зв'язків і для будь-яких МП даного середовища. 7.2. Інтерфейс мов програмування 7.2.1. Інтерфейс і взаємозв'язок мов програмування Основні МП, що використовуються для опису компонентів в сучасних середовищах, це С++, Паскаль, JAVA та ін. [11–14]. Різномовні програми, написані в цих мовах, звертаються одна до одної через віддалений виклик, який припускає взаємно однозначну відповідність між фактичними параметрами V = {v 1 , v 2 ,..., v к } програми, що викликає, і формальними параметрами F = {f 1 , f 1 ,...,f к1 } програми, що викликається. При неоднорідності одного з параметрів із множин формальних або фактичних параметрів різномовних програм необхідно здійснути відображення (mapping) нееквівалентного типу даних параметра в одній МП у відповідний тип даних в іншій МП. Аналогічно розв'язується задача перетворення нееквівалентних типів даних в МП. Подамо це перетворення такими етапами. Етап 1. Побудова операцій перетворення типів даних T = {T t } для множини мов програмування L = { l } =1, n Етап 2. Побудова відображення простих типів даних для кожної пари взаємодіючих компонентів в l 1 і l 2 , а також застосування операцій селектора S і конструктора С для відображення складних структур даних в цих мовах. Один із способів формалізованого перетворення типів даних – створення алгебраічних систем для кожного типу даних T t : G t = t , t >, де t – тип даних, X t – множина значень, які можуть набути змінні цього типу даних, t – множина операцій над цими типами даних. Як прості типи даних сучасних МП можуть бути t = b (bool), с (char), i (int), r (real). Складні типи даних t = а (array), z (record), u (union), e (enum) – комбінація простих типів даних. Цим типам даних відповідають такі класи алгебраїчних систем: 1 = {G b , G c , G i , G r }, 2 = {G a , G z , G u , G e }. (7.1) Кожний елемент класу простих і складних типів даних визначається на множині значень цих типів даних і операцій над ними: Gt = t , t >, (7.2) де t = b, с, i, r, а, z, u, e. Операціям перетворення кожного t типу даних відповідає ізоморфне відображення двох алгебраїчних систем з сумісними типами даних двох різних мов. У класі систем (7.1) перетворення типів даних t, q для пари мов l t і l q має такі властивості відображень: 1) системи G t і G q для мов l t і l q – ізоморфни, якщо їхні типи даних q, t визначені на одній і тій же множині простих або складних типів даних; 2) між значеннями X t і X q типів даних t, q існує ізоморфізм, якщо множина операцій t і q , які використовуються для перебудови цих типів даних, різні. Якщо ця множина t і q не пуста, то маємо ізоморфізм двох систем G t = t , 190 Розділ 7 t > і G t = t , q >. Якщо тип даних t є рядковий, а тип q – дійсне, то між множиною X t і X q не існує ізоморфної відповідності; 3) алгебраїчні системи G t = G q за потужністю повинні бути рівні, оскільки вони представлені на безлічі типів даних мов l t і l q Відображення 1, 2 зберігають лінійний порядок елементів, оскільки алгебраїчні системи є лінійно впорядкованими. Загальна схема зв'язку МП у розподіленому середовищі. Характерна особливість МП, що використовуються розподілених середовищах, – їхня неоднорідність як в сенсі представлення типів даних в них, так і платформ комп'ютерів, де реалізовані відповідні системи програмування. Причина неоднорідності – це різні способи передачі параметрів між об'єктами в різних середовищах, наявність різних типів об'єктних моделей і форматів даних для подання параметрів, різні види операторів віддаленого виклику і отримання результатів виконання запитів та ін. Системи програмування з МП мають такі особливості компіляції програм: – різні двійкові представлення результатів компіляторів для однієї й тієї ж МП, реалізованих на різних комп'ютерах; – двонаправленість зв'язків між МП і їхня залежність від середовища і платформи; – параметри виклику об'єктів відображаються в операції методів; – зв'язок з різними МП реалізується посиланнями на відповідні точки в компіляторах; – зв'язок МП здійснюється через інтерфейси кожної пари з множини мов (L 1 , ..., L n ) проміжного середовища. Зв'язок між різними мовами L 1 , ..., L n здійснюється через інтерфейс пари мов L i ,…,L n , що взаємодіють між собою в середовищі, яке генерує відповідні конструкції Li в операції опису інтерфейсу і навпаки. Взаємодія МП в середовищі CORBA. Принцип взаємодії об'єктів в середовищі CORBA полягає в тому, що будь-який об'єкт виконує метод (функцію, сервіс, операцію) за умови, якщо інший об'єкт, який вистує в ролі клієнта для нього, посилає йому запит для виконання цього методу. Об'єкт виконує метод через інтерфейс. Взаємодія МП в системі CORBA полягає у відображенні типів об'єктів в типи клієнтських і серверних stub шляхом: – відображення опису запиту клієнта в МП в операції IDL; – перетворення операцій IDL в конструкції МП і передачу їх серверу засобами брокера ORB, що реалізовує stub в типи даних клієнта. Оскільки МП системи CORBA можна реалізовувати на різних платформах і в різних середовищах, то їхнє двійкове представлення залежить від конкретної апаратної платформи [7, 8, 11, 13, 14]. Для всіх МП системи CORBA (С++, JAVA, Smalltalk, Visual C++, COBOL Ada-95) передбачено загальний механізм зв'язку і розташування параметрів методів об'єктів в проміжному рівні. Зв'язок між об'єктними моделями кожної МП системи СОМ і JAVA виконує брокер ORB (рис. 7.4). Якщо в загальну об'єктну модель CORBA входить об'єктна модель СОМ, то в ній типи даних визначаються статично, а конструювання складних типів даних здійснюється тільки для масивів і записів. Розділ 7 191 Брокер ORB Загальна об'єктна модель JAVA C++ Visial C ++ Cистема СОМ Система JAVA COBOL Smalltalk Ada–95 Рис. 7.4. Інтегроване середовище системи CORBA Методи об'єктів використовуються в двійковому коді і допускається двійкова сумісність машинного коду об'єкта, створеного в одному середовищі розробки, коду іншого середовища, а також сумісність різних МП за рахунок властивості відділення інтерфейсів об'єктів від реалізацій. У разі входження до складу моделі CORBA об'єктної моделі JAVA/RMI виклик віддаленого методу об'єкта здійснюється посиланнями на об'єкти, що задаються показником адреси пам'яті. Інтерфейс як об'єктний тип реалізується класами і надає серверу віддалений доступ до нього. Компілятор JAVA створює код байта, який інтерпретується віртуальною машиною, що забезпечує переносність байтових кодів і однорідність представлення даних на всіх платформах середовища СORBA. |