3.1.2. Моделі взаємозв’язку об’єктів

При аналізі ПрО і проектуванні розподілених систем з приміненням методу ООП і концепції розподілу об'єктів по різних вузлах середовища створюються інтерфейси у вигляді stub/skeleton для забезпечення їх взаємозв'язку. В [8, 9] запропонований формальний апарат опису взаємодії об'єктів, які розділені на об'єкти двох типів, що розрізняються семантикою.

Далі розглядається підхід з використанням ООП і умов їх виконання у сучасних гетерогенних середовищах. В ООП розглядаються програмні об’єкти двох типів, які розрізняються семантикою [ Остр, Рад, Лавр].

Під об'єктами 1-го типу будимо розуміти об'єкти або компоненти, які відповідають прикладним функціям ПрО і забезпечують рішення задач предметної області. До об'єктів 2-го типу відносимо об'єкти-інтерфейси, що включають операції виклику методів об'єктів 1-го типу і грають роль посередників для забезпечення взаємозв'язку між функціональними об'єктами 1-го типу, віддаленими один від одного по різним середовищам. Тобто інтефейсні об’єкти виконують зв’язок об’єктів 1-типу кліента з сервісними функціями - віддаленними процедурами мережі, розташованими у серверній частині РПС. Його загальними функціями є:: підготовка зовнішніх даних клієнта (параметрів), набір викликів цих процедур або сервісу до сервера, обробка різних помилок, повернення даних від сервера до клієнта тощо.

Прикладами операцій взаємодії - інтерфейсні операції, операції проекції і операція спадкоємства наведені на рис.1 і рис. 2.

Рис. 3.1. Взаємодія об'єктів 1-го типу

На даної загальної схемі взаємодії об’єкти Ok1, Ok3 визначають функціональні об’єкти, а Ok2 – інтерфейсний об’єкт. В ньому виконуються операції підготовки даних для Ok3, звернення до нього для виконання і отримання результату, який спочатку повертається обернено до нього, перетворюється в ньому до вигляду даних Ok1 і повертається йому.

Операція спадкоємства на схемі рис. 2 в першої верхній частини таж сама, що і на рис. 1. Вона має той ж зміст, але таке тлумачення, що Ok3 наслідує відповідні дані з класу об’єктів Ok1. Нижня частина взаємодії демонструє пряме, транзитне наслідування даних з Ok1 у Ok3.

Рис.3.2. Взаємодія об'єктів 2-го типу

Операції взаємодії і відповідні для них інтерфейси визначаються для об'єктів 1-го типу. Самі об’єкти описуються мовами програмування (МП) (наприклад, С++, Паскаль), а їх інтерфейси в мові IDL.

Модель взаємозв’язку можна розглядати як узагальнення машини Тюрінга. В загальному випадку в ній реалізується модель обчислення алгоритму. Узагальнену модель цієї машини будемо називати розподіленою інтерактивною машиною з моделлю взаємодії об'єктів чи компонентів. Ця машина розширює машину Тюрінга вхідними і виходами (input, output) діями (actions), виробляючими динамічну генерацію і просування потенційно нескінченного потоку даних.

Розподілена інтерактивна машина включає машину Тюрінга для проведення обчислень, тобто її модель допускає обчислення і обмін повідомленнями в заданий інтервал часу, тоді як в машині Тюрінга на обчислення алгоритмів чинник часу не впливає. Інша важлива відмінність між цими машинами полягає в тому, що машині Тюрінга відповідає вхідна стрічка з кінцевим числом символів, а розподіленій інтерактивній машині – необмежений вхідний потік (запитів, пакетів).

Таким чином, інтерпретація моделі взаємодії за допомогою розподіленої інтерактивної машини ґрунтується на діях і станах загальної (розділеній) пам'яті взаємодіючих об'єктів.

Мова специфікації об’єктів 2 типу РПС

Структура об’єкту 2-типу, чи посереднику незалежно від мови у цілому однакова. Це дає змогу стандартизувати структуру посередника та визначити ії за допомогою однієї з вказаних мов. РПС складається із двох частин, кожна з яких виконується у різних процесах, а взаємодіють вони шляхом виклику інтерфейсних функцій. Перша частина — серверна програма, а друга — клієнтська.

Пропонуємо мову опису інтерфейсів об’єктів за допомогою правил Бекуса-Наура (БНФ):

<інтерфейс об’єкта> ::= Object <ім’я_Об’єкту> :{ <множина вихідних інтерфейсів>}; {<множина вхідних інтерфейсів>} end

<множина вхідних інтерфейсів> ::= <множина інтерфейсів>

<множина вихідних інтерфейсів> ::= <множина інтерфейсів>

<множина інтерфейсів> ::= Æ | <інтерфейс>; <множина інтерфейсів>;

<інтерфейс> ::= Interface <ім’я_інтерфейсу>: {<множина функцій>} end

<множина функцій> ::= Æ | <функція>; <множина функцій>;

<функція> ::= function <iм’я_функції>: <множина параметрів> еnd

<множина параметрів> ::= <параметр> | <параметр>, <множина параметрів>

<параметр> ::= <тип> (<вид параметру>)

<вид параметру> ::= in | out | inout

Тип описує множину типів, які підтримуються мовами програмування (C++, Pascal т.і.) та забезпечують взаємодію між процесами, а <вид параметру> це: in — вхідний параметр, out — вихідний параметр, inout — сумісний параметр.

Множини вхідних та вихідних інтерфейсів мають різну семантику, але однаковий синтаксис. Взаємодію між об’єктами будемо описувати за допомогою операції конкатенації (×).

Введемо формальне визначення РПС у термінах процесів–об’єктів та за допомогою запропонованої мови специфікацій інтерфейс них об’єктів. Будемо використовувати такі позначення:

F- множина функцій,

O - множина об’єктів-процесів,

I - множина інтерфейсів,

- множина вхідних інтерфейсів (які використовуються як клієнт),

- множина вихідних інтерфейсів (які об’єкти надають сервери) .

Визначення взаємодій об’єкту (взаємодія першого роду). Результатом взаємодії двох об’єктів буде об’єкт, у якого множина вхідних інтерфейсів співпадає з множиною вхідних інтерфейсів об’єкта-сервера, а множина вихідних інтерфейсів — з множиною вихідних інтерфейсів об’єкта-клієнта:

Ні усі об’єкти можуть взаємодіяти один з одним, тому накладемо певні умови. Взаємодія об’єктів є коректною, якщо об’єкт-сервер повністю забезпечує сервіс, необхідний об’єкту-клієнту

Інтерфейс буде вхідним для об’єкту, якщо об’єкт отримує сервіс за допомогою цього інтерфейсу. І вихідним, якщо за допомогою цього інтерфейсу об’єкт надає сервіс об’єктам.

Визначення проекції об’єкту. Результатом проекції об’єкту на інтерфейс буде об’єкт, у якого множина вхідних інтерфейсів містить один елемент – цей інтерфейс, а множина вихідних інтерфейсів містить тільки ті інтерфейси, які необхідні для надання сервісу цього інтерфейсу.

де - предикат, що вказує на необхідність інтерфейсу для виконання інтерфейсу.

Визначимо проекцію об’єкту на множину інтерфейсів:

Результатом проекції об’єкту на об’єкт є проекція об’єкту на множину вхідних інтерфейсів об’єкта:

З визначення операцій проекції об’єкта та взаємодії між об’єктами випливає рівність: _.

Операція проекції об’єкту має вищий пріоритет, ніж операція взаємодії (що позначається конкатенацією), тобто:

Визначення операції успадкування (взаємодія другого роду). Успадкування серед об’єктів РПС відбувається на рівні інтерфейсів. Так, якщо об’єкт успадковує інтерфейси іншого об’єкту ( ), то він надає сервіс всієї множини вихідних інтерфейсів цього об’єкту. Тобто:

Це положення випливає із ООП програмування РПС, де виконання програми може змінюватися динамічно, а не статично.

Отже, успадкування об’єктом іншого об’єкту — це об’єкт, у якого множина вихідних інтерфейсів містить всі інтерфейси як першого, так і другого об’єкту, а множина вхідних інтерфейсів містить тільки ті інтерфейси, які необхідні для надання сервісу цих інтерфейсів.

При операції успадкування об’єкт, що наслідується, делегує іншому об’єктові свої інтерфейси.

З визначення операції успадкування інтерфейсів об’єктів випливають її властивості:

Транзитивності .

Симетричності .

Розкриття проекції над об’єктами, між якими існує взаємодія другого роду:

.

Мова опису розподіленого середовища

Основне призначення специфікації полягає в тому, щоб описати основні властивості і функції розподіленого середовища. Мова специфікацій cередовища близька до мови опису РПС.

Послідовне середовище можна описати за допомогою опису програми, що виконується у цьому середовищі. Оскільки, основною відмінністю між послідовним та розподіленим середовищем є можливість паралельної еволюції об’єктів у останьому, то необхідно ввести операцію, що описує цю властивість. За допомогою цієї операції виникає можливість розширення класу РПС, тобто опису інших РПС, що не ввійшли до опису операцій над об’єктами.

Надалі елемент множини РПС позначимо Р та дамо визначення операцій над ним.

Визначення паралельного виконання РПС. Результатом паралельної виконання двох РПС буде середовище: P_o êê P_r

Якщо у розподіленому середовищі РС виконується не лише два РПС, а декілька, тоді розподілене середовище описується: P_o êê...êê P_r

Операцію паралельного виконання можна розширити і перенести на множину об’єктів, оскільки РПС є об’єктом. Але зауважимо, що результатом паралельного виконання об’єктів буде не об’єкт, а середовище, у якому між об’єктами не виникає взаємодії ні першого, ні другого типу

Розширимо раніше визначені операції над об’єктами.

Визначення взаємодії об’єкту і середовища (взаємодія першого роду). Результатом взаємодії об’єкта і середовища буде об’єкт, у якого множина вхідних інтерфейсів співпадає з множиною вхідних інтерфейсів об’єкта-сервера, а множина вихідних інтерфейсів — об’єднання множин вихідних інтерфейсів об’єктів середовища.

Для подальшого використання вважаємо, що множина вхідних інтерфейсів при такій взаємодії є порожньою (накладемо таке обмеження). Оскільки при взаємодії об’єкта виникає недетермінованість взаємодії (який із об’єктів середовища взаємодіє з об’єктом-сервером), тобто .

Взаємодія об’єкту і середовища є коректною, якщо виконується умова: середовище повністю забезпечує сервіс, необхідний об’єкту-кліенту

Визначення проекції середовища. Результатом проекції середовища на інтерфейс буде середовище, у якого всі об’єкти є проекціями об’єктів середовища.

Аналогічно визначаємо проекцію середовища на множину інтерфейсів та на об’єкт. З визначення операцій проекції об’єкта та взаємодії між об’єктами випливає рівність:

_.

Визначення операції успадкування (взаємодія другого роду). Успадкування об’єктом інтерфейсів від РС є об’єкт, що успадковує інтерфейси всіх об’єктів середовища. Дана операція в ООП також називається як множинне успадкування. Надалі будемо використовувати цей термін як синонім.

При успадкуванні інтерфейсів від середовища виникає недетерміновність коли існують два (або декілька) об’єкти, що надають сервіс по одному інтерфейсу. Для виключення недетермінованості запропоновано вважати, що операція паралельного виконання (в даному випадку) не симетрична, тобто:

.

Класи РПС, що описуються за допомогою мови специфікації. Описавши операції паралельного виконання РПС та об’єктів розширимо множину РПС, що описуються мовою специфікації. Тепер об’єкт може отримувати сервіс не тільки від одного, але і від багатьох об’єктів. Всі запити щодо інтерфейсу та сервіс об’єкт отримує тільки від об’єкту , який в свою чергу, якщо виникає необхід­ність, отримує сервіси від . Тобто між об’єктами та існує взаємо­дія першого роду, а об’єкти виконуються паралельно, і визначають РПС класу .

Запити щодо інтерфейсу та сервіс об’єкт отримує від об’єкту , якщо цей об’єкт надає сервіс по цьому інтерфейсу, в противному разі від першого із об’єктів , який надає цей сервіс. Тобто об’єкт наслідує інтерфейси від (взаємодія другого роду).

Опис класів РПС. Розширимо безліч об'єктів, які будуть описуватися мовою IDL. Об'єкт може одержувати сервіс не тільки від одного об'єкту, але і від багато яких об'єктів. Всі запити щодо інтерфейсу і сервісу об'єкт одержує тільки від об'єкту, який у свою чергу одержує сервіси від .

Іншими словами, між об'єктами і існує взаємодія 1-го типу, а об'єкти виконуються паралельно, і визначають РС у вигляді .

Опис об'єктів 2-го типу в мову IDL включає опис типів даних параметрів інтерфейсів об'єктів 1-го типу і операції виклику методу для посилання запиту по мережі іншому об'єкту, видаленому від нього. Ці об'єкти є посередниками між клієнтом і сервером (stub для клієнта і skeleton для серверу). Їх описи відображаються в ті МП, в яких описані відповідні йому об'єкти 1-го типу.

Моделі взаємозв'язку за інформацією

Для опису взаємозв'язку об'єктів пропонується використання двох моделей – моделі інформаційного об'єднання і моделі управління об'єктами в динаміці виконання у середовищі.

Моделі інформаційного об'єднання включає засоби перетворення типів даних компонентів в одному ЯП до типів даних в іншому ЯП, а також операції зниження рівня структуризації даних для складних і структурних типів даних.

Модель управління об'єктами в інтегрованому середовищі включає опис умов виконання і вибору об'єктів. З кожним об'єктом середовища зв'язані пред– і постумови, визначені на безлічі керівників змінних. Дамо формальне уявлення цій моделі.

Спочатку в множиніі даних D виділимо дві підмножини

_s

D = ( È Di ) È Dc,

де Dc – позначає множину управляючих даних, в якій містяться змінні, визначальні умови виконання компонентів, імена компонентів інтегрованого комплексу і умови середовища їх виконання. До складу цієї множини можуть також входити спеціальні функції управління даними і операціями виклику компонентів.

Для кожного об'єкту Ki з множини K визначимо предумова Ri  R і постумова Qi  Q, які задаються на безлічі керівників змінних Dc_. Предумова Ri перевіряється перед викликом компоненту Ki і визначає умову його виклику. Після цього притягуються механізми аналізу і перетворення типів даних і їх підготовка для запуску викликаного компоненту. Постумова Qi перевіряється після виконання Ki як умова завершення основної програми і перетворення результату до необхідного виду викликала компоненти, а також перевіряється готовність до вибору нового компоненту.

Таким чином, множини R ={Ri} і Q ={Qi}_і=1,s визначають модель управління для вибору одного з об'єктів множини Р і аналізу множини R в цілях знаходження першої правильної умови виконання елемента з множини K. Якщо відповідна умова з R істинно, то відбувається виклик цього компоненту, інакше, шукається нова умова з R і процес повторюється, поки не відбудеться вибір необхідної умови перетворення передаваних параметрів, виконання вибраного з K компоненту і відправка результату після аналізу відповідної умови Qi.

Органызацыя взаємозв'язку в мережних середовищах

В інтегрованому мережному середовищі клієнт–сервер обмін даними між об'єктами/компонентами проводиться за допомогою операторів видаленого виклику, в яких пересилаються параметри одному одному. При цьому в рамках розподілених систем сформувалося декілька видів інтерфейсних посередників (сервер файлів, портмейкер RPC, брокер ORB, VM–машина), що підтримують відповідні моделі інтеграції програмних об'єктів до інтегрованої програмної структури Р [3–7, 29–34]. Розглянемо їх.

Посередник – сервер файлів. Інтерфейс між взаємодіючими програмними об'єктами в середовищі клієнт–сервер виконує сервер файлів. Модель взаємозв'язку об'єктів М2 = {P { P1_, P2_, P3}_{, D}} через сервер файлів визначається на vyмножині об'єктів Р і даних D, на якій визначаються передані серверу дані.

Зв'язок об'єктів через stub. Середовищем підтримки взаємодії компонентів через stub-клієнта і stub-серверу є ОNС SUN, OSF DSE [1, 2] і CORBA.

В stub міститься опис в мові високого і низького рівнів інтерфейсу взаємодіючих видалених компонентів. В ньому приводяться RPC-оператори, описані на мові низького рівня для проходження оператора по сіті (тип протоколу, розмір буфера даних і ін.).

Модель зв'язку М3 = {P, І, RPC, D} задає гнучку структуру, компоненти якої задані на множині мов І і відповідних інтерфейсах в мові RPC.

Опис інтерфейсу забезпечує виклик видалених процедур з бібліотеки системи і передачу параметрів в запиті транспортним протоколом (UDP, TCP/IP) мережного середовища ОNС SUN [1, 2].

Зв'язуючою ланкою між об'єктами, що викликаються і викличним, є stub-клієнта, який і посилає повідомлення до stub-серверу для виконання заданої видаленої процедури. Відповідно stub-серверу ініціює виконання цієї процедури і повертає результат назад через сіть клієнту.

Рис.3.3. Модель взаємозв'язку об'єктів в мережному середовищі

Вхідні Fi і Vi параметри виходів перевіряються на типи даних, які могли бути уявлені на різних машинах і зажадати декодування їх з причини платформи серверу і зворотного перекодування до виду платформи клієнта при відправці результату. Крім того, можуть виникнути і інші проблеми, пов'язані з необхідністю перетворення типів даних параметрів, наприклад, цілих до дійсного типу і т.п.

Зв'язок об'єктів в середовищі DCOM. Модель об'єктних компонентів DCOM задає зв'язок розподілених об'єктів і документів у версії IDL, а система CORBA забезпечує взаємодію об'єктів через брокера ORB.

Система DСОМ включає формалізмы:

– механізм RPC – виклику видаленої процедури і передачі їй даних;

– мережний обмін даними;

– системи передачі даних, перетворення даних, кодування і декодування даних для різної архітектури машин.

Зв'язок об’єктів брокером ORB. Модель інтеграції компонентів створюваної системи в розподіленому середовищі CORBA має наступний вигляд: М = { P, І, ORB, D, W }, де Р-програма, І- інтерфейс, ORB –зв'язник об'єктів в розподіленому середовищі W.

У середовищі система CORBA головну зв’язуючу роль між програмними об'єктами виконує брокер ORB через описаний інтерфейс stub/skeleton в мові IDL (рис. 3.3).

Інтеграція об’єктів в системі CORBAвключає:

– механізми передачі запитів видаленим об'єктам через інтерфейсні об'єкти stub і skeleton;

– мережний обмін даними і їх перетворення (кодування і декодування при розбіжності архітектури програмних компонентів);

– системи перетворення типів даних об'єктів, якими обмінюються між собою компоненти кожної пари в ЯП: З  Смолток, Смолток  Ада, Ада  Кобол, Кобол  Java і ін.

Для завдання інтерфейсу в системі CORBA розроблена я мова IDL, яка незалежна від мов опису об'єктів (С, С++, Паскаль і ін.). Інтерфейси об'єктів в цій мові запам'ятовуються в репозиторії інтерфейсів (Interface Repository), а реалізації об'єктів – в репозитарії реалізацій (Implementation Repository). Незалежність інтерфейсів від реалізацій об'єктів дозволяє їх використовувати в статиці і в динаміці.

Інтерфейс клієнта (Сlient Interface) складається з трьох інтерфейсів:

–  stub-інтерфейсу, що містить опис зовнішньо видимих параметрів і операцій об'єкту в мові IDL, генерується в статичну частину програми клієнта і зберігається в репозитарії інтерфейсів;

–  інтерфейсу динамічного виклику DII (Dynamic Invocation Interface) об'єкту, визначуваного під час виконання програми клієнта за допомогою пошуку опису інтерфейсу в репозитарії інтерфейсів;

–  інтерфейсу сервісів ORB (ORB Services Interface), що містить набір сервісних функцій, які клієнт запрошує в серверу.

Сервіс надається наступними видами адаптерів:

–  об'єктний адаптер (Object Adapter), який забезпечує екземплярам об'єктів звертатися до сервісних функцій;

–  базовий адаптер (Basic Object Adapter), який може забезпечувати виконання об'єктів незалежно від брокера;

–  бібліотечний адаптер (Library Adapter), що забезпечує виконання об'єктів, що зберігаються в бібліотеці об'єктів і що викликаються з прикладної програми клієнта;

–  адаптер БД (Database Adapter), що забезпечує доступ до об'єктно-орієнтованих БД.

Запити реалізуються за допомогою шаблонів інтеграції компонентів:

–  Client class для виклику методу, який буде виконаний сервером.

–  Stub class для конвертації методу на стороні клієнта;

–  ORB class управляє методами передачі даних і викликами методів між процесами;

–  Implementation class містить ділову логіку серверу, екземпляр цього класу – сервент – реєструється в ORB і може використовуватися клієнтом для запуску іншого процесу;

–  Server class створює сервлет і посилання, яке він записує в стандартний файл виходу;

–  Skeleton class конвертує ініціюючий метод за допомогою ORB брокера у формат, який може прочитати екземпляр сервента.

–  адаптер POA (Portable Object Adapter) забезпечує доступ до різних ORB.

При виконанні сервісних функцій брокер ORB використовує наступні загальносистемні засоби CORBA:

–  об'єктні сервіси, які призначені для логічного моделювання і фізичного зберігання об'єктів (наприклад, їх імен, подій, взаємодій і т.п.), підтримки роботи з об'єктами, забезпечення їх існування і незалежності від додатків, які до них звертаються;

–  засоби обслуговування полегшують побудову додатків, які будуть функціонувати в середовищі ORB, надають уніфіковану семантику загальних компонентів і взаємодію з іншими об'єктами через брокер ORB і об'єктний інтерфейс;

–  об'єктні застосуванні – це додатки, що розробляються незалежними розробниками на основі об'єктного підходу з використанням стандартного інтерфейсу і брокера ORB.

Взаємозв'язки в JAVA. Мова JAVA орієнтована на проектування розподілених додатків, які взаємодіють між собою за допомогою методу виклику RMI [6, 7]. Інструментом інтеграції є virtual machine, яка працює з byte–кодами компонентів в ЯП. Взаємодія компонентів на мовах JAVA і С++ здійснюється за допомогою брокера ORB, розглянутого вище. При цьому перетворення типів даних цих двох мов відноситься до bite-код програм, що відтранслюють, які інтерпретуються на віртуальній машині.

Формалізми в системі JAVA включають:

–  механізм виклику видалених методів RMI;

–  мережний обмін даними між видаленими компонентами;

–  віртуальну машину для інтерпретації кодів компонентів компілятора С++ в середовищі JAVA.

Альтернативою інтерфейсу компонентів є CGI (Common Gateway Interface), через який взаємодіє клієнт з WEB-сервером. Для доступу до інформації і формування відповіді клієнту використовується сервлет, який описується на мові JAVA, не залежить від платформи і використовує бібліотеку класів JAVA. Реалізація сервлетов в JAVA здійснюється за допомогою інструменту Servlet Development Kit.