ТЕМА 7
ІНТЕРФЕЙСИ, ВЗАЄМОДІЯ, ЕВОЛЮЦІЯ ПРОГРАМ І ДАНИХ

 

У цій темі розглядаються базові поняття з програмної інженерії, які необхідні для виробництва ПС. До них відносять: інтерфейси, засоби їхнього подання; взаємодія різномовних програм за інтерфейсом; перетворення і змінювання програм і даних. Описано різні види інтерфейсів, методи перетворення нееквівалентних типів даних взаємодіючих різномовних програм. Визначено задачі неоднорідності МП, платформ і середовищ, що впливають на зв’язки різномовних програм, сформульовано шляхи їхнього розв’язання. Розглянуто стандарт ISO/IEC 11404 –1996 про незалежні від сучасних МП типів даних і забезпечення універсальним апаратом їхнього перетворення і форматів даних, а також еволюційне змінювання програм.

 

7.1. Визначення інтерфейсу у програмуванні

Інтерфейс – це зв’язок двох окремих сутностей. Види інтерфейсів: мовні, програмні, апаратні, призначені для користувача, цифрові і т.п. Програмний (API) і/або апаратний інтерфейс (port) – це способи перетворення вхідних/вихідних даних під час об’єднання комп’ютера з периферійним обладнанням. У МП – це програма або частина програми, в якій визначаються константи, змінні, параметри і структури даних для передачі іншим.

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

У разі, коли один з елементів (програма, процедура або функція) записаний на різних МП і, крім того, якщо всі ці елементи розташовуються на різних комп’ютерах, то виникають проблеми неоднорідності типів даних в цих МП, структурах пам’яті платформ комп’ютерів і операційних середовищ, де вони виконуються.

Поняття інтерфейсу як самостійного об’єкта сформувалося у зв’язку із складанням або об’єднанням різномовних програм і модулів в монолітну систему на великих ЕОМ (mainframes) [1, 2].

Інтерфейс відігравав роль посередника між модулями, що викликаються і викликають. У ньому задавали опис формальних і фактичних параметрів, проводили перевірку відповідності параметрів, що передаються (кількість і порядок розташування), а також їхніх типів даних. Якщо типи даних параметрів виявлялися нерелевантними (наприклад, передається ціле, а результат функції – дійсне або навпаки), то проводилося їхнє пряме і обернене перетворення з урахуванням структури пам’яті комп’ютерів. На рис. 7.1 наведено схему програми С, в якій містяться два виклики – Call A () і Call B () з параметрами, що через інтерфейсні модулі-посередники A’ і B’ здійснюють перетворення даних і їх передачу модулям А і В.

Після виконання модулів А і В їхні результати передаються тим же модулями-посередникам, які перетворюють отримані дані до типів даних програми С.

Рис. 7.1. Схема зв’язків модулів А і В із С через інтерфейси А’ і B’

 

7.1.1. Інтерфейси в сучасних середовищах

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

 

Рис. 7.1. Структура представлення класу

 

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

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

Нове тлумачення інтерфейсу об’єктів наведено в праці П. Вегнера [3], який сформулював парадигму переходу від алгоритмів обчислень до взаємодії об’єктів. Суть цієї парадигми полягала в тому, що обчислення і взаємодія об’єктів розглядалися як дві ортогональні концепції. Взаємодія – це деяка дія (action), але не обчислення, а повідомлення – не алгоритм, а дія, відповідь на яку залежить від послідовності операцій (Op), що впливають на стан розподіленої (shared state) пам’яті локальної програми (рис. 7.2). Операції інтерфейсу (Op1 і Op2) належать до класу неалгоритмічних і забезпечують взаємодію об’єктів через повідомлення.

 

Рис. 7.2. Інтерфейс взаємодії через операції інтерфейсу (за Вегнером)

 

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

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

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

Мережі будуються на основі стандартної семирівневої моделі відкритих систем OSI (Open Systems Interconnection) [5]. Об’єкти рівнів у цій моделі зв’язуються між собою по горизонталі і вертикалі. Запити від застосувань надходять на рівень представлення даних для їхнього кодування (перекодування) до виду платформи, що використовується в застосуванні. Відкриті системи надають будь-яким застосуванням різного роду послуги: керування віддаленими об’єктами, обслуговування черг і запитів, обробка інтерфейсів і т.п.

Доступ до послуг здійснюється за допомогою різних механізмів:

– виклику віддалених процедур 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), які взаємодіють один з одним через механізм виклику інтерфейсних функцій або посередників двох типів програм (клієнт і сервер), що виконуються на різних процесах.

До функції інтерфейсного посередника клієнта належать:

– підготовка зовнішніх параметрів клієнта для звернення до сервісу сервера;

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

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

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

– повернення результату клієнту через параметри повідомлення і знищення віддаленої процедури і ін.

Опис інтерфейсного посередника не залежить від МП взаємодіючих об’єктів і в цілому однаковий для всіх об’єктів, що викликають або викликаються. Посередник описується в мові специфікації інтерфейсу 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.2. Інтерфейс мов програмування

7.2.1. Інтерфейс і взаємозв’язок мов програмування

Основні МП, що використовуються для опису компонентів в сучасних середовищах, це С++, Паскаль, JAVA та ін. [11-14].

Різномовні програми, написані в цих мовах, звертаються одна до одної через віддалений виклик, який припускає взаємно однозначну відповідність між фактичними параметрами V = {v1, v2,..., vк} програми, що викликає, і формальними параметрами F = {f1, f1,...,fк1} програми, що викликається. При неоднорідності одного з параметрів із множин формальних або фактичних параметрів різномовних програм необхідно здійснути відображення (mapping) нееквівалентного типу даних параметра в одній МП у відповідний тип даних в іншій МП.

Аналогічно розв’язується задача перетворення нееквівалентних типів даних в МП. Подамо це перетворення такими етапами.

Етап 1. Побудова операцій перетворення типів даних  = { } для множини мов програмування L =  = 1, n.

Етап 2. Побудова відображення простих типів даних для кожної пари взаємодіючих компонентів в  і , а також застосування операцій селектора S і конструктора С для відображення складних структур даних в цих мовах.

Один із способів формалізованого перетворення типів даних – створення алгебраічних систем для кожного типу даних :

 

,

 

де t – тип даних,  – множина значень, які можуть набути змінні цього типу даних,  – множина операцій над цими типами даних.

Як прості типи даних сучасних МП можуть бути t = b (bool), с (char), i (int), r (real). Складні типи даних t = а (array), z (record), u (union), e (enum) – комбінація простих типів даних. Цим типам даних відповідають такі класи алгебраїчних систем:

 

 

Кожний елемент класу простих і складних типів даних визначається на множині значень цих типів даних і операцій над ними:

 

,                                                                                                               (7.2)

де t = b, с, i, r, а, z, u, e.

 

Операціям перетворення кожного t типу даних відповідає ізоморфне відображення двох алгебраїчних систем з сумісними типами даних двох різних мов. У класі систем (7.1) перетворення типів даних t, q для пари мов  і  має такі властивості відображень:

1) системи  і  для мов  і  ізоморфні, якщо їхні типи даних q, t визначені на одній і тій же множині простих або складних типів даних;

2) між значеннями  і  типів даних t, q існує ізоморфізм, якщо множина операцій  і , які використовуються для перебудови цих типів даних, різні. Якщо ця множина  і  не пуста, то маємо ізоморфізм двох систем  і . Якщо тип даних t є рядковий, а тип q – дійсне, то між множиною  і  не існує ізоморфної відповідності;

3) алгебраїчні системи  за потужністю повинні бути рівні, оскільки вони представлені на безлічі типів даних мов  і .

Відображення 1, 2 зберігають лінійний порядок елементів, оскільки алгебраїчні системи є лінійно впорядкованими.

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

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

– різні двійкові представлення результатів компіляторів для однієї й тієї ж МП, реалізованих на різних комп’ютерах;

– двонаправленість зв’язків між МП і їхня залежність від середовища і платформи;

– параметри виклику об’єктів відображаються в операції методів;

– зв’язок з різними МП реалізується посиланнями на відповідні точки в компіляторах;

– зв’язок МП здійснюється через інтерфейси кожної пари з множини мов (L1, ..., Ln) проміжного середовища.

Зв’язок між різними мовами L1, ..., Ln здійснюється через інтерфейс пари мов Li, …, Ln, що взаємодіють між собою в середовищі, яке генерує відповідні конструкції 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.3). Якщо в загальну об’єктну модель CORBA входить об’єктна модель СОМ, то в ній типи даних визначаються статично, а конструювання складних типів даних здійснюється тільки для масивів і записів.

 

Рис. 7.3. Інтегроване середовище системи CORBA

 

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

У разі входження до складу моделі CORBA об’єктної моделі JAVA/RMI виклик віддаленого методу об’єкта здійснюється посиланнями на об’єкти, що задаються показником адреси пам’яті.

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

 

7.2.2. Взаємодія різномовних програм

Проблемі взаємодії різномовних програм на множині сучасних мов (C/C++, Visual C++, Visual Basic, Matlab, Smalltalk, Lava, LabView, Perl) присвячена праця [15]. У ній представлено різні варіанти і конкретні приклади зв’язків кожної пари МП з цієї множини за допомогою практично реалізованих і наведених функцій перетворення, методів звернення до них з програм в одній мові до програми в іншій мові. У табл. 7.1. подано варіанти взаємозв’язку різних МП.

 

Таблиця 7.1. Інтерфейс сучасних мов і засобів програмування

Засіб опису програм

Мова взаємодії

Вид інтерфейсу

Visual Basic

– ANCI C

– C C++

– Windows API

– DLL

– VisualBasic 6.0

– Win 32

–API Viewer

Платформо-орієнтовані

функції

Програмний інтерфейс

Динамічна бібліотека функцій

Інтерфейс між Visual Basic

Функції обробки подій

Інтерфейс в API

Matlab

– C C++

– Matlab Engine

– Matlab в JNI

– Visual Basic 6.0

– Java

Виклик застосування з середовища

Вбудовування функцій в VC++

Використання інтерфейсу JNI

Функції з Matlab

Функції в Java

Smalltalk

– C++

– Matlab

– Start V1

Модель додатку в Visual Works

Функції графічної бібліотеки

Бібліотеки С, С++ і процедури Visual Works

Lab View

– ANCI C

– Visual C++

– Visual Basic 6.0

– C C++

Інтерфейс VI і API

Зв’язок Visual C, DLL, Obj

Lib С C++

Інтерфейсні функції драйвера

Java

– C, C++

– Visual C++

– Matlab

Платформо-орієнтовані функції

Бібліотеки функцій в С++, С

Функції в JNI

Perl

– C, C++

– API

– Visual C++

Платформо-орієнтовані функції

Програмний інтерфейс

Інтерфейсні функції в С++

 

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

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

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

Далі коротко описано шість схем засобів опису різномовних програм, що взаємодіють з мовами, наведеними в другому стовпці цієї таблиці.

Інтерфейс між Visual Basic і іншими МП здійснюється за допомогою оператора звернення, параметрами якого можуть бути текстові рядки, значення, масиви та інші типи даних. Їхня обробка виконується функціями Windows API, API DLL і операціями перетворення типів даних. Як приклад наведено схему обробки Інтернет-застосувань, що задаються HTML-сторінками Basic Visual, які розміщуються у веб-браузері і базах даних.

Matlab містить у собі засоби для розв’язання задач лінійної і нелінійної алгебри, операцій над матрицями і забезпечує математичні обчислення за допомогою Matlab Compiler, Matlab C++, Matlab Libriary, Matlab Graphic Library.

Наведено схему незалежного застосування у середовищі Matlab, яке містить у собі інтерфейс між VC і Matlab, що створюється MatlabCompiler шляхом перетворення програми у форматі Matlab (М-файли або М-функції) у формат мови С. Сформований файл викликається з програми в С++ і перетворюється до виду архітектури комп’ютера, куди відсилається результат.

Базові засоби Smalltalk забезпечують створення застосувань у середовищі VisualWorks і вміщують модель застосувань, методи об’єктів, повідомлення для передачі значень зовнішнім об’єктам і призначений для користувача інтерфейс (рис. 7.4). Модель застосування містить у собі функції DLL з класу зовнішнього інтерфейсу, які взаємодіють з функціями бібліотеки С++.

 

Рис. 7.4. Схема взаємодії моделі застосування у Smalltalk

 

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

Система взаємодіє з ANS C, Visual Basic, Visual C++ Lab Windows/CV. Ці засоби розширюють можливості створення систем реального часу, які дозволяють виконувати за допомогою функцій зв’язку вимірювати апаратури типу термометрів, перемикачів тощо. Результати вимірювань можуть передаватися через мережу.

Середовище Java містить у собі інструменти взаємодії зі всіма мовами, наведеними в другому стовпці таблиці. Загальна схема зв’язку мов JAVA, C і C++ програм наведена на рис. 7.5.

 

Рис. 7.5. Схема взаємодії програм в мовах Java, C, C++ в системі Java

 

Мова Perl з’явилася в 80-х роках минулого сторіччя як мова опису сценаріїв для взаємодії з Інтернетом, керування завданнями і створення CGI-сценаріїв на сервері в системі Unix. Ця мова має інтерфейс із С, С++, Visual Basic і Java. Інтерпретатор з мови Perl написано на мові С, і кожний інтерфейс з іншою мовою розглядається як розширення, що представляється процедурами динамічної бібліотеки.

Оператор виклику програми в С або С++, забезпечує перетворення її у спеціальний код, який розміщується в бібліотеці інтерпретатора Perl. Сам інтерпретатор може бути вміщені у Win32 для програм на C / C++.

Таким чином, в праці [15] ретельно досліджені найсучасніші засоби і інструменти представлення різномовних програм і принципи їхній взаємодії з широко використовуваними МП. Подано рекомендації щодо конкретного застосування кожного засобу з урахуванням умов середовища і правил прямої і оберненої передачі параметрів програми в МП з класу розглянутих МП. Наведено численні приклади, які перевірено експериментально, ними можна користуватися на практиці або використовувати як зразки.

 

7.2.3. Стандарт ISO/IEC 11404–96 з незалежних від мов типів даних

Мета даного стандарту [16] та гармонизованого ГОСТ 30664-99 полягає в тому, щоб забезпечити не тільки опис типів даних в стандартній мові LI (Language Independent) і їхню генерацію, а й перетворення типів даних МП у LI-мову, і навпаки. Стандарт пропонує спеціальні правила і характеристичні операції генерації примітивних типів даних і об’єднань LI-мови в простіші структури даних МП, а також визначення параметрів інтерфейсу засобами мов IDL, RPC і API. Незалежні від МП типи даних стандарту розділено на примітивні, агрегатні і такі, що згенерувані (рис. 7.6).

У цю мову також вміщено генератор типів даних. Типи даних в стандарті описуються в LI-мові, яка є більш загальною мовою, на відміну від конкретних засобів опису типів даних МП.

Він містить у собі всі існуючі типи МП і загальні типи даних, орієнтовані на генерацію інших типів даних. Стандарт складається з розділів (рис. 7.7): об’ява (declaration) типів даних, об’явлені типи даних, об’явлені генератори.

 

Рис. 7.6. Незалежні від МП типи даних стандарту ISO/IEC 11404–1996

 

Рис. 7.7. Об’ява типів даних у стандарті ISO/IEC 11404–1996

 

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

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

Засобами мови LI описуються параметри виклику як елементи інтерфейсу, необхідні при зверненні до стандартних сервісів і готових програмних компонентів.

LI-мова стандарту рекомендує такі види перетворення даних:

– зовнішнє перетворення типів даних МП в LI-типи даних;

– внутрішнє перетворення з LI-типу даних в тип даних МП;

– зворотне внутрішнє перетворення.

Зовнішнє перетворення типів даних і генераторів типів даних полягає в такому:

а) перетворення кожного примітивного типу з зовнішнього типу даних зв’язується з одним LI-типом даних;

б) перетворення кожного внутрішнього типу даних перетворення визначає зв’язок між припустимим значенням внутрішнього типу даних і еквівалентним значенням відповідного LI-типу даних;

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

Внутрішнє перетворення зв’язує примітивний тип даних або те, що згенеровано, в LI-тип даних з конкретним внутрішнім типом даних МП. Представники окремого сімейства LI-типу даних можуть перетворюватися в різні внутрішні типи даних МП. Це перетворення має такі особивості:

а) для кожного LI-типу даних (примітивного або згенерованого) перетворення визначає наявність цього типу даних в МП або відношення між допустимим значенням цього типа і еквівалентним значенням відповідного внутрішнього типу МП;

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

Зворотне внутрішнє перетворення для LI-типу даних полягає в перетворенні значень внутрішнього типу даних у відповідне значення LI-типу за наявності відповідності і відсутності двозначності. Це перетворення для МП є колекцією зворотних внутрішніх перетворень LI-типу даних.

У даному стандарті є набір додатків.

У додатку 1 наведено перелік діючих стандартів (близько 40), що визначають набори символів. Для забезпечення сумісності типів даних, що використовуються і реалізуються, в додатку 2 містяться рекомендації щодо ідентифікації типів даних і опису анотацій для атрибутів, параметрів тощо.

У додатку 3 подано рекомендації щодо відповідних внутрішніх типах даних, які повинні перетворюватися в LI-типи даних. У додатку D показано, що синтаксис LI-мови є підмножиною стандарту IDM (Interface Definition Notation), призначеного для опису інтерфейсу в LI-мові. Наведено варіант внутрішнього перетворення LI- типів даних в типи даних МП Паскаль (ISO/IEC 7185–90). У ньому розглянуто приклади перетворення примітивних типів даних LI-мови (логічний, перерахований, символьний, цілий раціональний і ін.) в типи даних мови Паскаль.

Запропоновані в стандарті рекомендації, а також засоби опису типів даних і методів їхнього перетворення є універсальними. Потрібна програмна підтримки цього стандарту для масового застосування.

 

7.3. Перетворення даних за інтерфейсом

7.3.1. Перетворення форматів даних

Програми, розташовані на різних типах комп’ютерів, передають один одному дані через протоколи, їхні формати перетворюються до формату даних приймаючої серверної платформи (так званий маршаллинг даних) з урахуванням порядку і стратегії вирівнювання, прийнятої на цій платформі. Демаршаллинг даних – це зворотне перетворення даних (тобто отриманого результату) до виду клієнтської передавальної програми. Якщо серед переданих параметрів оператора виклику містяться нерелевантні типи або структури даних, які не відповідають параметрам викликаного об’єкта, то проводиться пряме і зворотне їхнє перетворення засобами стандарту або МП [8, 11, 12].

До засобів перетворення даних і їхніх форматів належать:

– стандарти кодування даних (XDR – eXternal Data Representation, CDR – Common Representation Data [8]), NDR – Net Data Representation) і методи їхнього перетворення;

– МП і механізми звернення компонентів один до одного;

– мови опису інтерфейсів компонентів – RPC, IDL і RMI для передачі даних між різними компонентами.

На кожній платформі комп’ютера використовуються угоди про кодування символів (наприклад, ASCII), про формати цілих чисел і чисел з плаваючою точкою (наприклад, IEEE, VAX і ін.). Для представлення цілих типів, як правило, використовується додатковий код, а для типів float і double – стандарт ANSI/IEEE та ін.

Порядок розташування байтів залежить від структури платформи (Big Endian або Little Endian) від старшого до молодшого байта і від молодшого до старшого байта. Процесори 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 – альтернатива сервісам CORBA в плані забезпечення взаємозв’язків різномовних програм.

XML має різну системну підтримку: браузер Internet Explorer для візуалізації XML-документів, об’єктна модель DOM (Document Object Model) для відображення XML-документів і інтерфейс IDL в системі CORBA.

Тексти в XML-стандарті описуються у форматі ASCII, що дає можливість ефективніше застосовувати їх при обміні даними. XML використовується для кодування типів даних за допомогою файлових форматів. При необхідності переходу програмної системи до XML-стандарту проводиться переформатування даних у формат XML, і навпаки.

Таким чином, XML-мова дозволяє представляти об’єкти для різних моделей на єдиній концептуальній, синтаксичній і семантичній основі. Він не залежить від платформи і середовища моделі взаємодії компонентів прикладного рівня. XML спрощує обробку документів, роботу з БД за допомогою стандартних методів і засобів (XML-парсеры, DOM-інтерфейси, XSL-відображення XML в HTML та ін.).

 

7.3.2. Перетворення даних з баз даних

Перетворення даних БД пов’язане з різницею логічних структур даних, а також з такими проблемами:

1) багатомодельність представлення даних (ієрархічні, мережні, реляційні) в різних БД і СКБД;

2) різниця в логічних структурах даних, в довідниках, класифікаторах і в системах кодування інформації;

3) використання різних мов для представлення текстової інформації;

4) різні типи СКБД і постійний розвиток даних БД в процесі експлуатації.

Проблема 1 розв’язується шляхом переходу до реляційної моделі даних і СКБД, яка є потужним математичним апаратом, який ґрунтується на теорії множин і математичній логіці. Ця модель складається із структурної, маніпуляційної і цілісної частин. У цих частинах, відповідно, фіксується структура даних, опис програм в SQL-мові і вимоги до цілісності. Ієрархічні або мережні моделі даних загалом не підтримують цілісність, тому при переході від них до реляційних БД виникає порушення цілісності даних.

Проблема 2 викликана тим, що логічна структура даних або концептуальна схема БД припускають проектування нової структури БД при зміні наочної області або при переході до нового типу СКБД. При цьому зіставляються дані старої і нової БД і змінюється довідкова інформація і класифікатори.

Проблема 3 визначається різномовними текстовими представленнями інформації в БД. У старих БД використовувалася, як правило, одна мова, а в нових їх може бути декілька, тому для зберігання даних з простим доступом до текстових даних встановлюється відповідність текстових даних, записаних в різних мовах.

Проблему 4 можна сформулювати як метод зберігання і обробки різних даних, викликаних специфікою СКБД ієрархічного, мережного і реляційного типів. Наявність явної несумісності типів і структур цих моделей даних, різні мови маніпулювання даними призводять до того, що не можна згенерувати мовою старої СКБД скрипти для перенесення даних і подальшого запуску БД в середовище іншої СКБД. Кожна СКБД забезпечує внесення змін в БД, які певною мірою змінюють і концептуальну модель даних, якщо до неї вносять нові об’єкти. Внесені зміни повинні відображатися в довідниках і класифікаторах, що забезпечує перенесення даних із старої БД до нової з урахуванням поточних змін [19, 20].

Перетворення даних. Враховуючи наведені проблеми, розглянемо шляхи їхнього вирішення. При тривалій промисловій експлуатація систем, що працюють з БД, можуть змінюватися прикладні програми і дані, якщо в систему введена нова БД, а частина раніше визначених даних перенесена до нової БД.

Це спричиняє необхідність доопрацювання прикладних програм доступу, щоб пристосувати їх до зміненої структури нової БД або до старої БД. Для перенесення даних із старої БД до нової створюються скрипти або DBF-файли, які розміщуються в транзитній БД для перенесення до нової БД. Якщо виявиться, що процес зведення структури транзитної БД до нової виявився недоцільним, то розробка нової БД проводиться «з нуля». При цьому довідники і класифікатори доповнюються новими даними, що з’явилися.

Проблеми перетворення даних при використанні різних СКБД виникають також через те, що дані мають різні способи зберігання, серед яких можуть опинитися несумісні типи даних або доступ до даних здійснюється різними мовами маніпулювання.

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

Процеси перетворення даних базуються на використанні:

методу 1, що переносить дані із старої БД до транзитних файлів, а потім заносить ці файли до транзитної БД;

методу 2 для обробки даних в транзитній базі при зміні кодування даних, приведенні відповідності між структурами старої і нової БД, а також кодів довідників і класифікаторів;

методу 3 для системного перенесення даних з транзитної бази до основної БД з перевіркою перетворених даних.

Перший метод – найбільш безболісний для користувачів і розробників. Другий метод є створенням нового проекту системи із заданою моделлю даних. При третьому методі – система створюється заново, до нової БД можуть заноситися успадковані дані із старої БД. Оскільки структури БД можуть виявитися різними, то, як правило, створюються тимчасові застосування, в яких здійснюються необхідні перетворення даних при перенесенні до нової БД.

При застосуванні першого і другого методів структура старої БД зберігається і ніякого перетворення даних, відповідності довідників і класифікаторів не вимагається, оскільки вони використовують єдиний формат зберігання даних.

Файли передачі даних між різними БД. Проблема перетворення і перенесення даних між різними СКБД розв’язується через:

1) спеціальний драйвер (дві СКБД з’єднуються один з одним і безпосередньо передають дані, використовуючи інтерфейс);

2) транзитні файли, в які копіюються дані із старої БД для перенесення їх у нову БД.

Перетворення і перенесення даних з різних БД до нових БД наведено на рисунку 7.8.

 

Рис. 7.8. Процес перетворення і формування нової БД із старих БД

 

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

Такий метод складний в реалізації і вимагає постачання програм перенесення даних з інших СКБД, які прив’язано до старої і нової СКБД. Тому другий метод перенесення даних між різними СКБД більш прийнятний.

У другому випадку дані із старої БД переносяться до транзитних файлів, SGL-скриптів, DBF-файлів з наперед заданими форматами даних, які пересилаються до нової транзитної БД через мережу за допомогою спеціальних утиліт або засобів нової СКБД.

Якщо друга СКБД реляційного типа, то дані в транзитних файлах перетворяться до табличного вигляду. Якщо перша СКБД не реляційна, то дані повинні бути приведені до табличного вигляду і першої нормальної форми.

Подальша нормалізація даних і зведення їх до структури нової БД здійснюється в транзитній БД з використанням 3- або 4- нормальної форми для подання структур даних. Кожна вища форма нормалізації містить у собі як підмножину нижчу форму, наприклад, першу нормальну форму у вигляді скалярних значень.

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

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

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

Процес нормалізації відношень дозволяє позбавитися проблем, які можуть виникнути при оновленні, внесенні або видаленні даних, а також при забезпеченні цілісності даних. Структури старих БД не завжди можна привести до третьої нормальної форми, тому потрібно, щоб дані, що знаходяться в транзитних файлах, існували хоч би в першій нормальній формі і належали до реляційної моделі.

Як уніфікований формат транзитних файлів використовують формат DBF- файлів, оскільки багато СКБД, такі, як DB2, FохРго і деякі інші, зберігають дані в таких файлах, тим самим немає потріби у початковому перенесенні даних із старої СКБД до транзитних файлів. Більшість СКБД, формат зберігання даних яких відрізняється від формату DBF-файлів, забезпечується утилітами або драйверами, що дозволяють перенести дані в такий формат.

 

7.4. Методи еволюційного змінювання компонентів і систем

Готові ПС активно використовують при створенні і супроводі нових систем. При цьому виникають різного роду помилки, які вимагають внесення змін у систему після того, як помилка виявлена або виникла необхідність у зміні або покращенні певних характеристик системи [17-24].

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

Типові причини внесення змін це:

– виявлення дефектів в системі під час експлуатації, які не були виявлені на процесі тестування;

– з’ясування невідповідності або невиконання деяких вимог замовника, через що система не виконує окремі функції;

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

Як стверджують експерти, процес внесення змін в експлуатовану систему досить дорогий, його вартість досягає від 60 до 80 % загальної вартості розробки системи.

До видів супроводу належать:

– коригування – внесення змін в діючу ПС для усунення помилок, які були виявлені після передачі системи до експлуатації;

– адаптація продукту до змінених умов (апаратури, ОС) використання системи після її передачі в експлуатацію;

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

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

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

В цілому процес зміни (еволюції) ПС проводиться шляхом:

– аналізу початкового коду для внесення в нього змін;

– настроювання компонентів і системи на нові платформи;

– кодування і декодування даних при переході з однієї платформи на іншу;

– зміни функцій системи або додавання нових;

– розширення можливостей (сервісу, мобільності та ін.) компонентів;

– перетворення структури системи або окремих її компонентів.

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

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

 Внесення змін до ПС можна розглядати як еволюційний шлях його розвитку. Еволюція ПЗ здійснюється такими зовнішніми методами обробки компонентів в розподіленому середовищі і внутрішніми методами, як зміна компонентів (Сом), інтерфейсів (Int) і/або систем. До внутрішніх методів еволюції належать методи реінженерії, рефакторинга і реверсної інженерії (рис. 7.9).

 

Рис. 7.9. Схема методів еволюційної зміни компонентів ПС

 

Ці методи забезпечують різнопланову зміну програм або систем.

До них належить коригування специфікацій, документації і програмного коду відповідно до вимог на зміни [15-20].

Суть цих методів полягає в такому:

– реінженерія забезпечує перепрограмування окремих компонентів на нові МП, платформи і середовища, а також розширення можливостей ПС;

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

 реверсна інженерія означає повну переробку компонентів, а іноді і перепрограмування всієї системи.

 

7.4.1. Реінженерія програмних систем

Реінженерія (reengineering) – це еволюція програми (системи) шляхом її зміни з метою підвищення зручності її експлуатації, супроводу або зміни її функцій. Вона містить у собі процеси реорганізації і реструктуризації системи, переведення окремих компонентів системи в іншу, сучаснішу МП, а також процеси модифікації або модернізації структури і системи даних. При цьому архітектура системи може залишатися незмінною [18].

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

З технічної точки зору реінженерія – це вирішення проблеми еволюції системи шляхом зміни її компонентів, архітектури в середовищі, в якому компоненти розміщуються на різних комп’ютерах. Причиною еволюції може бути зміна МП системи, наприклад, Fortran, Сobol і ін. з переходом на сучасні об’єктно- орієнтовані мови, такі, як Java або C++.

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

Порівнянну з радикальнішими підходами до вдосконалення систем реінженерія має такі переваги:

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

2. Зниження витрат за рахунок використання компонентів повторного використання при розробці нової ПС. Згідно з даними різних комерційних структур повторне використання в чотири рази дешевше, ніж нова розробка системи.

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

Головна відмінність між реінженерією і новою розробкою системи полягає в тому, що опис системної специфікації починається не з «нуля», а з розгляду можливостей старої успадкованої системи.

До основних процесів процесу реінженерії належать:

– переклад початкового коду в старій МП на сучасну версію цієї мови або в іншій МП;

– аналіз програм згідно з документованою структурою і функціональними можливостями системи;

– модифікація структури програм для нарощування нових властивостей і можливостей;

– розбиття системи на модулі для їхнього групування і усунення надмірності;

– зміна даних, з якими працює програма.

Причинами, що вимагають перетворення початкового коду програм в іншу мову, можуть бути:

– оновлення платформи апаратних засобів, на якій може не виконуватися компілятор МП;

– недолік кваліфікованого персоналу для програм, написаних в МП, що вже не застосовують;

– зміна структури програми у зв’язку з переходом на нову стандартну МП.

До операцій реінженерії належать:

– іменування змінних компонентів і їхня ідентифікація;

– розширення функцій існуючої реалізації компонентів;

– переклад мови компонента в нову сучасну МП;

– реструктуризація компонента;

– модифікація опису компонента і його даних.

 

7.4.2. Рефакторінг компонентів

Рефакторінг розвивається в об’єктно-орієнтованому програмуванні у зв’язку з широким застосуванням інтерфейсів, шаблонів проектування і методів покращання коду [5, 17]. Розроблено бібліотеки типових трансформацій пошукових об’єктів (класів), які покращують ті або інші характеристики ПС.

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

Процес рефакторингу орієнтується на отримання нових компонентів, які містять у собі такі операції з організації проведення змін:

– додавання нової реалізації для існуючого і нового інтерфейсу;

– заміна існуючої реалізації нової з еквівалентною функціональністю;

– додавання нового інтерфейсу (за наявності відповідної реалізації);

– розширення існуючого інтерфейсу для нових системних сервісів у компонентному середовищі.

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

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

Операції над компонентами задовольняють умови:

– об’єкт, одержаний внаслідок рефакторингу,

– це компонент з відповідними властивостями, характеристиками і типовою структурою;

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

– перебудова компонентів, а іноді і перепрограмування проводиться в процесі реверсної інженерії [15, 18].

 

7.4.3. Реверсна інженерія

Методи реверсної інженерії, які розроблено в середовищі об’єктно-орієнтованого програмування, ґрунтуються на виконанні базових операцій візуалізації (visual) і вимірювання метрик (metric) ПС в рамках моделі, яка пропонує такі цілі:

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

– пошук ієрархії класів і атрибутів програмних об’єктів з метою успадковання їх в ядрі системи;

– ідентифікація класів об’єктів з визначенням розміру і/або складності всіх класів системи;

– пошук патернів, їхня ідентифікація, а також фіксація їхнього місця і ролі в структурі системи.

Цей підхід орієнтується на індустріальні системи в мільйон рядків коду з використанням метричних оцінок характеристик системи. Він вирішує генерацію тестів для перевірки кодів, а також проведення метричного аналізу системи для отримання фактичних значень внутрішніх і зовнішніх характеристик системи [21].

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

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

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

Висновки. Розглянуто базові поняття інтерфейсу, підходи до забезпечення інтерфейсу, мов програмування і взаємодії різномовних програм і даних. Визначено загальні проблеми неоднорідності МП, платформ комп’ютерів і середовищ, що впливають на виконання зв’язків між різномовними програмами, сформульовано шляхи їхнього вирішення. Викладено стандартні рішення ISO/IEC 11404–1996 з забезпечення незалежних від МП типів даних, стандарти з перетворення форматів даних і еволюційного змінювання програмних систем.