The formal basic developing and testing the distributed program systems
Problems in programming 2013; 4: 25-34
Збережено в:
| Дата: | 2025 |
|---|---|
| Автори: | , |
| Формат: | Стаття |
| Мова: | Українська |
| Опубліковано: |
PROBLEMS IN PROGRAMMING
2025
|
| Теми: | |
| Онлайн доступ: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/739 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Problems in programming |
| Завантажити файл: |  |
Репозитарії
Problems in programming| _version_ | 1859502454428663808 |
|---|---|
| author | Lavrischeva, K.M. Stenyashin, A.Yu. |
| author_facet | Lavrischeva, K.M. Stenyashin, A.Yu. |
| author_sort | Lavrischeva, K.M. |
| baseUrl_str | https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| collection | OJS |
| datestamp_date | 2025-04-16T13:52:57Z |
| description | Problems in programming 2013; 4: 25-34 |
| first_indexed | 2025-07-17T09:37:32Z |
| format | Article |
| fulltext |
Методи та засоби програмної інженерії
© К.М. Лавріщева, А.Ю. Стеняшин, 2013
ISSN 1727-4907. Проблеми програмування. 2013. № 4 25
УДК 681.03
К.М. Лавріщева, А.Ю. Стеняшин
ФОРМАЛІЗМИ ОБ’ЄКТНОГО ПРОЕКТУВАННЯ І ТЕСТУВАННЯ
РОЗПОДІЛЕНИХ ПРОГРАМНИХ СИСТЕМ
Розглядається підхід до проектування розподілених програмних систем формальним поданням
об’єктів функціонального і інтерфейсного типів. Дається визначення об’єктів та операцій проекції,
взаємодії та паралельного виконання. Дано опис мови подання інтерфейсів об’єктів IDL (stub,
skeleton) і оброблення їх брокером ORB сиcтеми CORBA. Запропоновано процес тестування
об’єктних структур програм та перетворення даних різнорідних об’єктів для забезпечення їх взаємодії
у операційному середовищі.
Вступ
Проектування розподілених про-
грамних систем (РПС) виконується різни-
ми методами і підходами. Нині набувають
чинності підходи проектування з викорис-
танням об’єктно-орієнтованого підходу
(ООП), компонентного та сервісного про-
грамування.
При проектуванні РПС з застосу-
ванням ООП [1–5] і концепції розподілу
об'єктів за різними вузлами середовища
виникає проблема забезпечення їх взає-
мозв'язку, яка вирішується за допомогою
інтерфейсів подібно зв’язку через stub,
skeleton системи Corba [4]. В ній дані
механізми створення об’єктної моделі
(ОМ), яка орієнтована на функціонування
в гетерогених середовищах. Інтерфейсні
об’єкти ОМ описуються новою мовою
IDL, яка робить цю модель узгодженою,
чітко організованою з сучасними умовами
середовищ. Метамодель ОМА системи
CORBA підтримується різними сучас-
ними платформами, у тому числі мейнф-
реймами і мінікомп’ютерами, Unix-
системами тощо.
Міжнародною групою (Object
Managment Group – OMG) розроблено
проект стандарту об’єктної й еталонної
моделей OMA для проектування нових за-
стосувань. Для об’єкта визначаються вла-
стивості, характеристики і типи даних.
Об’єкти, що володіють загальними власти-
востями, групуються в класи. Тип примір-
ника класу розглядається як відношення
підтип/супертип. Кожному об’єкту відпо-
відає одна або декілька операцій, що
завдають виклику його методів. Операції
визначають дії за об'єктами і їхній поведі-
нці. Після виконання операції об’єкт набу-
ває деякий стан, що впливає на його пове-
дінку. Основними компонентами еталон-
ної моделі ОМА є:
– мова IDL і транслятор інтерфейсу
компонент застосувань (Application Inter-
face); загальний об’єктний сервіс (Common
Object Services), що забезпечує керування
подіями, транзакціями, інтерфейсами, за-
питами й ін.;
– загальні засоби (Common
facilities), необхідні для груп компонентів і
застосувань (електронна пошта, телеко-
мунікація, керування інформацією, емуля-
тор програм й ін.);
– брокер об’єктних запитів (брокер
ORB) для організації взаємозв'язку різно-
рідних об'єктів.
Таким чином, брокер ORB – це го-
ловний «зв’язок» об’єктів і компонентів із
різних застосувань і середовищ. Є його
опис на багатьох мовах програмування
(МП) для поширеного використання у ін-
ших середовищах. Наприклад, у сучасних
середовищі Grid, Cloud Computing [1].
Далі пропонується підхід до про-
ектування РПС з використання функ-
ціональних й інтерфейсних об'єктів.
1. Засоби опису об’єктів РПС
Пропонується використання ООП
для формального завдання функціональ-
них й інтерфейсних об’єктів з метою їх ви-
конання у сучасних гетерогенних середо-
вищах. В ООП розглядаються програмні
Методи та засоби програмної інженерії
26
об’єкти двох типів, які розрізняються між
собою семантикою [5, 6].
Під об’єктами 1-го типу розумі-
тимемо об’єкти, які відповідають приклад-
ним функціям ПрО і забезпечують рішен-
ня задач предметної області. До об'єктів
2-го типу відносимо об’єкти-інтерфейси,
що включають операції виклику методів
об'єктів 1-го типу і грають роль посеред-
ників для забезпечення взаємозв’язку між
функціональними об’єктами 1-го типу,
віддаленими один від одного за різними
середовищами. Тобто, інтерфейсні об’єкти
виконують зв’язок об’єктів 1-типу клієнта
з сервісними функціями – віддаленими
процедурами мережі, розташованими у
серверній частині РПС. Його загальними
функціями є: підготовка зовнішніх даних
клієнта (параметрів), набір викликів цих
процедур або сервісу до сервера, обробка
різних помилок, повернення даних від
сервера до клієнта тощо.
Операції взаємодії і відповідні для
них інтерфейси визначаються для об’єктів
1-го типу. Самі об’єкти описуються сучас-
ними МП (наприклад, С++, Java, Паскаль),
а їх інтерфейси в мові IDL.
Модель взаємозв’язку можна розг-
лядати як узагальнення машини Тюрінга.
В загальному випадку в ній реалізується
модель обчислення алгоритму. Узагальне-
ну модель цієї машини будемо називати
розподіленою інтерактивною машиною з
моделлю взаємодії об’єктів чи компонен-
тів. Ця машина розширює машину Тюрінга
вхідними і виходними (input, output) діями
(actions), виробляючими динамічну гене-
рацію і просування потенційно нескінчен-
ного потоку даних.
Розподілена інтерактивна машина
включає машину Тюрінга для проведення
обчислень, тобто її модель допускає обчи-
слення й обмін повідомленнями в зада-
ний інтервал часу, тоді як у машині Тюрін-
га на обчислення алгоритмів чинник часу
не впливає. Інша важлива відмінність між
цими машинами полягає у тому, що ма-
шині Тюрінга відповідає вхідна стрічка з
кінцевим числом символів, а розподіленій
інтерактивній машині – необмежений вхі-
дний потік (запитів, пакетів).
Таким чином, інтерпретація моделі
взаємодії за допомогою розподіленої інте-
рактивної машини ґрунтується на діях і
станах загальної (розділеній) пам'яті взає-
модіючих об'єктів.
Специфікація об’єктів 2-го типу
Структура об’єкта 2-типу, чи посе-
редника незалежно від мови у цілому од-
накова. Це дає змогу стандартизувати
структуру посередника та визначити її за
допомогою однієї з зазначених мов. РПС
складається із двох частин, кожна з яких
виконується у різних процесах, а взаємо-
діють вони шляхом виклику інтерфейсних
функцій. Перша частина – серверна про-
грама, а друга – клієнтська.
Пропонуємо фрагмент мови опису
інтерфейсів IDL у формі правил Бекуса–
Наура [4]:
<інтерфейс об’єкта> ::= Object
<ім’я_Об’єкта> :{<множина вихідних ін-
терфейсів>}; {<множина вхідних інтер-
фейсів>} end;
<множина вхідних інтерфейсів> ::=
<множина інтерфейсів>;
<множина вихідних інтерфейсів>
::= <множина інтерфейсів>;
<множина інтерфейсів> ::= | <ін-
терфейс>; <множина інтерфейсів>;
<інтерфейс>::= Interface <ім’я_ ін-
терфейсу>: {<множина функцій>} end
<множина функцій> ::= | <функ-
ція>; <множина функцій>;
<функція> ::= function <iм’я_ фун-
кції>: <множина параметрів> еnd;
<множина параметрів> ::= <пара-
метр> |<параметр>, <множина параметрів>
<параметр> ::= <тип> (<вид пара-
метру>);
<вид параметра> ::= in | out | inout.
Тип описує множину типів, які під-
тримуються мовами програмування (C++,
Pascal, т. п.) та забезпечують взаємодію
між процесами, а <вид параметра> це: in –
вхідний параметр, out – вихідний пара-
метр, inout – сумісний параметр.
Множини вхідних та вихідних ін-
терфейсів мають різну семантику, але
Методи та засоби програмної інженерії
27
однаковий синтаксис. Взаємодію між
об’єктами будемо описувати за допомогою
операції конкатенації ().
Формальне визначення базових
понять у термінах об’єктів за допомогою
запропонованої мови специфікації [6]:
F – множина функцій,
O – множина об’єктів,
I – множина інтерфейсів об’єктів,
kk OInOO ,
– множина вхід-
них інтерфейсів (як клієнтських),
,OOk kOOut
– множина вихі-
дних інтерфейсів (серверних).
Визначення взаємодій об’єкта (вза-
ємодія першого типу). Результатом взає-
модії двох об’єктів буде об’єкт, у якого
множина вхідних інтерфейсів збігається з
множиною вхідних інтерфейсів об’єкта-
сервера, а множина вихідних інтерфейсів –
з множиною вихідних інтерфейсів об’єкта-
клієнта:
,, kkk OInOOutO
,, lll OInOOutO
., lklk OInOOutOO
Не всі об’єкти можуть взаємодіяти
один з одним, тому накладемо певні умо-
ви. Взаємодія об’єктів lk OO є коректною,
якщо об’єкт-сервер повністю забезпечує
сервіс, необхідний об’єкту-клієнту
.nmlnkm IIOOutIOInI
Інтерфейс буде вхідним для об’єкта,
якщо об’єкт отримує сервіс за допомогою
цього інтерфейсу. І вихідним, якщо за до-
помогою цього інтерфейсу об’єкт надає
сервіс об’єктам.
Визначення проекції об’єкта. Ре-
зультатом проекції об’єкта на інтерфейс
буде об’єкт, у якого множина вхідних
інтерфейсів містить один елемент – цей
інтерфейс, а множина вихідних інтер-
фейсів містить тільки ті інтерфейси, які
необхідні для надання сервісу цього
інтерфейсу.
,, kkk OInOOutO
,,
,
:
, else
IIexec
OInII
Ithen
OOutIifIO
nm
knn
m
kmmk
де nm IIexec , – предикат, що вказує на
необхідність інтерфейсу nI для виконання
mI інтерфейсу.
Визначимо проекцію об’єкта на
множину інтерфейсів:
1
1 2
1
, , , .
M
k m
m
k M M
k m
m
Out O I
O I I I
In O I
Результатом проекції об’єкта на
об’єкт є проекція об’єкта на множину вхі-
дних його інтерфейсів:
.lklk OInOOO
З операцій проекції та взаємодії
об’єктів випливає рівність об’єктів:
.klklk OOOOO
Операція проекції об’єкта має ви-
щий пріоритет, ніж операція взаємодії.
Вона позначається конкатенацією:
.k l m k m lO O I O I O
Визначення операції успадкування
(взаємодія другого типу). Успадкування
серед об’єктів РПС відбувається на рівні
інтерфейсів. Так, якщо об’єкт успадковує
інтерфейси іншого об’єкта ( lk OO ), то
він надає сервіс всієї множини вихідних
інтерфейсів цього об’єкта:
.lklk OOutOOutOO
Це положення випливає із ООП
програмування РПС, де виконання про-
грами може змінюватися динамічно, а не
тільки статично.
Отже, успадкування об’єктом іншо-
го об’єкта – це об’єкт, у якого множина
вихідних інтерфейсів містить всі інтерфей-
си як першого, так і другого об’єкта, а
множина вхідних інтерфейсів містить
Методи та засоби програмної інженерії
28
тільки ті інтерфейси, які необхідні для на-
дання сервісу цих інтерфейсів.
.
,:
:
,
mnlkn
lkmm
lk
lk
IIexecOOOutI
OInOInII
OOutOOut
OO
Операція успадкування об’єкта де-
легує іншому об’єктові свої інтерфейси.
З визначення операції успадкування
інтерфейсів випливають такі властивості:
транзитивності
;,: 3132213,2,1 OOOOOOOO
симетричності
.kkk OOOO
Розкриття проекції над об’єктами,
між якими існує взаємодія другого типу:
1 2 1 2O O O O .
Опис розподілених РПС. Основне
призначення мови специфікації РПС по-
лягає у тому, щоб описати основні її вла-
стивості та функції для функціонування у
розподіленому середовищі. Мова специ-
фікації об’єктів середовища близька до мо-
ви опису РПС.
Для послідовного опису об’єктів
середовища використовуються мови опису
різних програми, що виконуються в цьому
середовищі. Основною відмінністю між
послідовним та розподіленим середови-
щем є можливість паралельного виконання
об’єктів і програм. Ця можливість за-
дається відповідними операціями опису
паралельного виконання. Ці операції да-
ють можливість розширити клас систем
шляхом додавання інших ПС, що не уві-
йшли до цього класу.
Надалі елемент множини РПС
(об’єкт чи ПС) позначимо Р та дамо визна-
чення операцій над системами РПС.
Визначення паралельного виконання
РПС. Результатом паралельного виконання
двох РПС буде середовище: Po Pr.
Якщо у розподіленому середови-
щі РС виконується не лише два РПС, а
декілька, тоді розподілене середовище
описується: Po ... Pr.
Операцію паралельного виконання
можна розширити і перенести на множи-
ну об’єктів і ПС, оскільки РПС є об’єк-
том складної структури. Але зауважимо,
що результатом паралельного виконання
об’єктів буде не об’єкт, а середовище, в
якому між об’єктами не виникає взаємо-
дії ні першого, ні другого типу ||kO
.|| lO
Розширимо раніше визначені опе-
рації над об’єктами щодо середовища.
Визначення взаємодії об’єкта і се-
редовища (взаємодія першого роду). Ре-
зультатом взаємодії об’єкта і середовища
буде об’єкт, у якого множина вхідних ін-
терфейсів збігається з множиною вхідних
інтерфейсів об’єкта-сервера, а множина
вихідних інтерфейсів – об’єднання мно-
жин вихідних інтерфейсів об’єктів середо-
вища:
.,||||
1
1
n
j
lkllk jn
OInOOutOOO
Для подальшого використання вва-
жаємо, що множина вхідних інтерфейсів
при такій взаємодії є порожньою (на-
кладемо таке обмеження). Оскільки при
взаємодії об’єкта
nllk OOO ||||
1
вини-
кає не детермінованість взаємодії (який із
об’єктів середовища взаємодіє з об’єктом-
сервером), тобто
,||||
1 kllk OOutOOO
n
.
Взаємодія об’єкта і середовища
nllk OOO ||||
1
є коректною, якщо вико-
нується умова: середовище повністю за-
безпечує сервіс, необхідний об’єкту-
клієнту
.
1
nm
n
j
lnkm IIOOutIOInI
j
Визначення проекції середовища.
Результатом проекції середовища на інте-
рфейс буде середовище, у якого всі
об’єкти є проекціями об’єктів середовища.
.|||||||| mlmkmlk IOIOIOO
Методи та засоби програмної інженерії
29
Аналогічно визначаємо проекцію
середовища на множину інтерфейсів та на
об’єкт. З визначення операцій проекції
об’єкта та взаємодії між об’єктами випли-
ває рівність:
.||||||||
11 kllkllk OOOOOOO
nn
Визначення операції успадкування
(взаємодія другого роду). Успадкування
об’єктом інтерфейсів від РПС є об’єкт,
що успадковує інтерфейси всіх об’єктів
середовища. Дана операція в ООП також
називається як множинне успадкування.
Надалі будемо використовувати цей тер-
мін як синонім.
При успадкуванні інтерфейсів від
середовища виникає недетерміновність
коли існують два (або декілька) об’єкти,
що надають сервіс по одному інтерфейсу.
Для виключення не детермінованості за-
пропоновано вважати, що операція пара-
лельного виконання (в даному випадку) не
симетрична, тобто:
1221
|||| llkllk OOOOOO .
Класи РПС, що описуються за до-
помогою мови специфікації. Описавши
операції паралельного виконання РПС та
об’єктів розширимо множину ПС, що опи-
суються мовою специфікації. Тепер об’єкт
може отримувати сервіс не тільки від од-
ного, але і від багатьох об’єктів. Всі запи-
ти щодо інтерфейсу та сервіс об’єкт
1kO отримує тільки від об’єкта
2kO , який в
свою чергу, якщо виникає необхідність,
отримує сервіси від
nll OO
1
. Тобто між
об’єктами
1kO та
2kO існує взаємодія пер-
шого типу, а об’єкти
nkk OO
1
виконують-
ся паралельно, і визначають ПС класу
nllkk OOOO ||||
121
.
Запити щодо інтерфейсу та сервіс
об’єкт
1kO отримує від об’єкта
2kO , якщо
цей об’єкт надає сервіс по цьому інтерфей-
су, в противному разі від першого із
об’єктів
nll OO
1
, який надає цей сервіс.
Тобто об’єкт
2kO наслідує інтерфейси від
(взаємодія другого типу).
2. Тестування об'єктів 1-го і
2-го типів
Під перевіркою правильності інтер-
фейсів віддалених об'єктів розуміється ви-
значення коректності завдання операцій
виклику в stub-об'єкта і динамічної пе-
ревірки проходження протоколу повідом-
лення від локального об'єкта до віддале-
ного й обернено [6–8].
Результатом досліджень взаємодії
об’єктів є розроблений оригінальний під-
хід для перевірки коректності уявлення
об'єктів і засобів передачі параметрів від-
даленого виклику через мережне середо-
вище. Суть підходу полягає у вбудовуван-
ні механізмів спостереження того, в що
перевіряється об’єкт, у stub-об’єкт та у по-
відомлення для виконання методу об’єкта.
Далі розглядаються основні його по-
ложення.
РПС складається з об’єктів 1-, 2- і 3-
го типів. Об'єкти 1-го типу відображають
прикладні функції застосування і забез-
печують рішення задач кінцевого корис-
тувача. До об'єктів 2-го типу ставляться
об’єкти-інтерфейси, що включають опис
зовнішніх змінних і операції віддаленого
виклику, що реалізують взаємодії об’єктів
1-го типу, коли ці операції у виді запитів
потрапляють у розподілене середовище.
Об'єкти 3-го типу – це повідомлення від
одного об'єкта до іншого.
Підхід до тестування орієнтований
на перевірку об'єктів 1-го – 3-го типів
РПС окремо, їхніх взаємодій між собою і
роботи об’єктів у комплексі. Об’єкти 1–го
типу можна тестувати і традиційними ме-
тодами, вставляючи заглушки на місцях
звернення до посередників [6].
Тестування об’єктів 2-го типу по-
лягає у перевірці правильності й описів
інтерфейсів взаємодіючих об’єктів 1-го
типу та операцій викликів методів у ло-
кальному режимі без виходу в мережу.
При мережному варіанті об’єкти ПС їде
перевірка на наявність або відсутність по-
середників у репозиторії, а також на пере-
вірку переданих параметрів, маршалінг
даних і шляхи проходження запитів від
клієнта до сервера й зворотно.
Методи та засоби програмної інженерії
30
Тестування об'єктів 1-го типу
Кожний об’єкт 1-го типу включає
базові структури керування (БСК) обчис-
леннями: умови, ітерацію і послідовне ви-
конання. Ці структури визначають шлях
обчислень об’єктів 1-го типу в залежності
від значень виражень, що утримуються в
них , і умов, які впливають на керування.
До БСК об’єктів 1-го типу саме і застосо-
вується метод вбудовування механізмів
тестування для перевірки правильності
їхнього виконання.
Об’єкт 1-го типу тестується з вмо-
нтованим механізмом тестування, що до-
зволяє переходити в режим тестування для
перевірки правильності виконання БСК.
Кероване тестування об’єктів 1-го
типу – це спроможність механізму
управляти (контролювати) поводженням
об'єкта під час тестування за допомогою
вибору шляху виконання в його керуючих
структурах (гілках програми) для
виявлення структурних і семантичних
помилок.
Спостережність тестування
об’єктів 1-го типу – це спроможність
механізму переглядати значення будь-яких
змінних програмного об'єкта, отримуваних
під час обчислень.
Метрики тестування об'єктів 1-го
типу. Метод тестування об'єктів 1-го типу
включає метрики, засновані на двох основ-
них властивостях установлення ступеня
тестування: контрольованістю (КТ) тесту-
вання БСК і спостережністю за тесту-
ванням (НТ).
Контрольованість БСК – це влас-
тивість незалежного присвоєння керуючим
змінним або вираженням цих структур та-
ких значень, щоб будь-який шлях об-
числень об’єктів 1-го типу був контролю-
ємо доступний. КТ будь-якої БСК кіль-
кісно визначимо у такий спосіб:
КТБСК = 1, якщо БСК – незалежні
один від одного,
КТБСК = 0, якщо БСК залежить від
шляху виконання або взаємозалежностей
виражень.
Контрольованість тестування КТ
окремого об'єкта опишемо формулою:
,
1
1
n
i
БСК i
КТ
n
КТ (1)
де
iБСкКТ – контрольованість усіх БСК
об’єкта.
Область визначення КT – [0; 1]. Да-
на властивість інформує про ступінь пере-
вірки слушності об’єкта, якщо
1КТ , то об’єкт цілком прокон-
трольований;
0КТ , то об’єкт не про контро-
льований.
10 КТ , то об’єкт частково про-
контрольований.
Під спостережністю тестування
(СТ) об’єкта 1-го типу будемо розуміти
властивість перегляду значень, прийнятих
для будь-якої змінної усередині шляху те-
стування.
Область визначення СT збігається з
областю КT. Якщо у об’єкта 1CТ або
0CТ , то це означає, що об'єкт 1-го типу
досліджено або ні. Одним із засобів ре-
алізації дослідження об’єкта є, наприк-
лад, додавання в програму таких опера-
торів, як write або print, тоді можна
досягти СT 1.
Очевидно, чим більше КT і СТ, тим
більший ступінь повноти тестування.
Тестовність об'єкта 1-го типу
(ТО1) можна визначити як функцію від
конрольованості КТ і спостереженості
СТ за тестуванням:
ТО1= f (КТ, СТ) = КТ*СТ. (2)
Тут: ТO1 = 1, якщо КТ і СТ рівні 1.
ТO1 = 0, якщо хоча б один або обид-
ва рівні 0.
Область значень ТO1 [0;1], при
КT [0;1] і СT [0;1]. У зв’язку з тим, що
отримується СT1 просто, маємо формулу:
n
i
БСК i
КТ
n
КТТО
1
1
11 . (3)
Очевидно, ТO1 значно менше 1, що
припускає повну тестовність об’єкта 1-го
типу.
Таким чином, замінюючи БСК
об’єктів 1-го типу відповідними БСК з
вмонтованим механізмом тестування,
Методи та засоби програмної інженерії
31
отримуємо повну керовність тестуванням
об’єктів.
Тестування об'єктів 2-го типу.
Об'єкти 2-го типу є посередниками
stub/skeleton і генеруються у вигляді само-
стійних об’єктів-інтерфейсів для об’єктів
1-го типу. Таким чином, існують об’єкти
інтерфейсу, що використовуються для вза-
ємодії об’єктів 1-го типу.
Під тестуванням об'єктів 2-го типу
розуміється тестування інтерфейсів вза-
ємодіючих об'єктів і є самостійною про-
цедурою, що не включає питання передачі
повідомлень, які спеціально підтри-
муються мережними засобами (IPX, IP,
TCP й інші).
Перевірка коректності здійснюється
за допомогою спеціальної системної ком-
поненти, названої Контролер інтерфейсів.
Ця компонента є елемент РПС, що розта-
шовується в мережному середовищі, як
віддалений системний об'єкт. Для проход-
ження через Контролер інтерфейсу у
вихідний опис stub-об'єкта включаються
спеціальні вмонтовані властивості спос-
тереження за процесом обертання до
віддаленого методу об'єкта і його перевір-
ки до сервера і після його виконання.
Фактично зазначені дії аналізо-
ваного підходу забезпечують перевірку
правильності інтепретації переданих і/або
отриманих даних від взаємодіючих об'єк-
тів мережі.
Для проведення тестування у вихід-
ний опис об'єкта 2-го типу включаються
спеціальні механізми, створюючи за своєю
суттю вмонтовані властивості.
Метрики тестування об'єктів 2-го
типу. Розглянемо метрики тестування
об'єктів 2-го типу для систематичного і кі-
лькісного оцінювання результатів тесту-
вання за допомогою запропонованих моде-
лей метрик для них. Основою тестування
тут є інтерфейс.
Керування тестуванням інтер-
фейсів об'єкта 2-го типу – це контроль над
поводженням об'єкта 1-го типу при взає-
модії через заданий інтерфейс. Результа-
том керованого тестування інтерфейсу
може бути: втрата запиту з віддаленим ви-
кликом (переданого або отриманого), від-
сутність об'єкта для взаємодії, перевірка
поводження об'єкта на різноманітних ета-
пах його життєвого циклу та ін.
Таким чином, керування інтерфей-
сами об'єкта розподіленого середовища
(УИ) – це властивість керування об'єктом
при його взаємодії з іншими об'єктами се-
редовища умикання механізмів тестування
в процесі виконання.
Тестовність об'єктів 2-го типу –
це властивість незалежного керування всі-
ма інтерфейсами об'єкта. Фізичний зміст
УТО – це властивість примушувати об'єкт
виконувати визначені інтерфейси в режимі
тестування, спонукати об'єкт до визначе-
ного поводження при взаємодії з іншими
об'єктами 1-го типу. УТО опишемо за фор-
мулою:
n
i
ИО i
У
n
УТ
1
1
, (4)
де
iИУ – керування j–інтерфейсом об'єкта
2-го типу РПС.
Область визначення УТО – [0; 1].
Якщо в об'єкта УТО = 1 то він цілком ке-
руючий; якщо УТ = 0 об'єкт – не керуючий.
У інших випадках – об'єкт частково керу-
ючий.
Спостереженість за тестуванням
інтерфейсу об'єкта 2-го типу (СІ) – це вла-
стивість перегляду значень стимулювання
запиту або відповіді після взаємодії об'єк-
тів. Спостереження тестування об'єкта
2-го типу (СТО) – це властивість незалеж-
ного спостереження за всіма інтерфейсами
об'єкта 1-го типу за допомогою вмонтова-
них механізмів:
n
i
ИО i
Н
n
СТ
1
1
, (5)
де
iИН – можливість спостереження за i–
інтерфейсом об'єкта.
Кількісні значення СІ і СТО такі:
НІ = 1, якщо значення стимулюван-
ня або відповіді інтерфейсу можна спосте-
рігати;
НІ = 0, якщо в інтерфейсу значення
не можна спостерігати.
Область визначення СТО збігається
з областю НІ. Якщо в об'єкта СТО = 1
Методи та засоби програмної інженерії
32
або СТО = 0, то він являє собою цілком
досліджуваний або цілком не досліджу-
ваний об'єкт. Реалізувати повну спостере-
жність не так просто, як це можна
зробити в нерозподіленому застосуванні,
оскільки на тестовність ресурсів не на-
кладається обмежень, пов'язаних із точка-
ми виконання.
Очевидно, що чим більше значення
УТО і СТО, тим легше провести повне тес-
тування об'єкта 2-го типу РПС. Базуючись
на визначеннях УТО і СТО, отримуємо, що
тестовність об'єкта 2-го типу (ТО2) – це
функція від тестовності та спостережності
даного об'єкта:
ОООО НТУТНТУТfТО *,2 . (6)
Дана формула дає уявлення про
значення ОТ2, якщо:
ТО2 = 1, якщо й УТО і НТО рівні 1.
ТО2 = 0, якщо хоча б УТО або СТО
рівні 0.
Областю значень ТО2 [0;1], при
УТО [0;1] і СТО [0;1]. Розкриваючи да-
ну формулу, отримуємо:
.
11
2
11
n
i
И
n
i
ИОО ii
Н
n
У
n
НТУТТО (7)
Зазначимо, що при тестуванні об'є-
ктів 2-го типу важливу роль відіграє тесто-
вність об'єкта 1-го типу, в яких відбуваєть-
ся взаємодія, тобто для повного тестування
інтерфейсу необхідно отримати тестов-
ність двох об’єктів 1-го типу, що дає мож-
ливість провести порівняльний аналіз ін-
тепретацій інтерфейсів системним Конт-
ролером.
Тестування об'єктних РПС. Після
тестування об'єктів 1-го і 2-го типу та
встановлення ступеня їх тестовності, по-
чинається тестування окремих ПС у ком-
плексі з використанням усіх механізмів
тестування об'єктів. Тестовність РПС (То-
орп) визначимо через тестовність об'єк-
тів 1-го і 2-го типу ПС:
,21
1
1
m
j
jjООРП ТОТО
m
Т (8)
де ТО1m – тестовність об'єкта 1-го
типу;
ТО2m – відповідного йому об'єкта
2-го типу;
m – кількість розподілених об'єктів
у об’єктно-орієнтованих ПС. Підставимо
замість цих розмірів відповідні формули,
отримуємо:
m
j
n
i
БСК
j
ООРП
j
i
КТ
nm
Т
1 1
11
,
11
11
j
i
j
i
k
i
И
j
k
i
И
j
Н
k
У
k
(9)
де nj – кількість БСК j-го об'єкта 1-го
типу у складі об’єктно-орієнтованого ПС,
kj – кількість інтерфейсів j-го
об'єкта 2-го типу.
Дана формула показує, що якщо для
всіх об'єктів ПС змінна ТО1 = 1 і ТО2 = 1,
тестовність РПС приймає значення 1 і
окреме ПС є цілком тестовано. У против-
ному випадку тестовність РПС має бути
поліпшена за допомогою інших методів.
Базуючись на метричних моделях тестов-
ність РПС на рівні керуючих структур
БСК і спостережність за тестуванням об'є-
ктів 1–го типу або прикладної частини до-
датка зробимо такий висновок.
Твердження. РПС розподілене за-
стосування є цілком тестовним, якщо:
а) Тоопр = 1 або
б) ТО1j = 1, ТО2j = 1, j = 1, 2, ..., m.
Дане твердження і формули для
ТО1 И ТО2, показують, що поліпшення
тестовності РПС можна досягти на рівні
БСК об'єктів 1-го типу і керуючих змінних
об'єктів 2-го типу.
Запропоновано тестування РПС
провадити за чотирма етапами:
1) тестування об’єктів 1-го типу
(можливо традиційними методами тесту-
вання) незалежно від їхніх інтерфейсів;
2) тестування об'єктів 2-го типу на
момент побудови як мінімум двох об’єктів
РПС для перевірки їхньої взаємодії через
інтерфейс;
3) тестування об’єктів 3-го типу,
при проходженні повідомлень по мережі;
Методи та засоби програмної інженерії
33
4) тестування РПС у комплексі з
усіх об’єктів, коли перевірені функції об'є-
ктів, їхні інтерфейси і треба перевірити
протоколи-інтерфейси в динаміці їх вико-
нання.
3. Операції взаємодії різнорідних
об’єктів
Аналіз опису програм з викорис-
танням різних ТД показує, що головною
проблемою взаємодії програм є інтерфейс,
в якому дається набір параметрів з описом
їх типів даних. Для забезпечення інформа-
ційного зв’язування пари різномовних мо-
дулів склалися три класи операцій [2, 9]:
1) Р – операції перетворення ТД
модулів, що зв’язуються між собою;
2) S – операції селектора компонен-
тів складного ТД;
3) С – операції конструювання
структурних типів.
Операції класу 1 дозволяють здійс-
нювати безпосереднє перетворення типу
даних Та
t
у Тβ
t
без додаткових операцій
зміни рівня структурування [2, 8]. Опера-
цію перетворення ТД запишемо у вигля-
ді: P
tq
аβ = (Та
t
, Т
q
β).
Тут дані ТД Та
t
перетворяться в Т
q
β,
а і β відповідають мовам lа і lβ. Множина
ТД кожної МП впорядкована й індекси t і q
визначають конкретні елементи цієї мно-
жини. Для деяких МП t і q будуть функ-
ціями від інших індексів і упорядкованість
їх типів може визначатися конструюван-
ням нового типу t з типів у яких індекси не
більше t. Новий тип буде мати індекс, що
функціонально залежить від індексів ви-
значених типів і конкретних операцій
конструювання.
Операції класу 2 слугують вибору
зі структурного типу його окремих компо-
нентів з меншим рівнем структурування.
Механізми реалізації цих операцій відмін-
ні від аналогічних, наявних у МП, тому що
вони не повинні змінювати структури да-
них, тих, що безпосередньо обробляються
в модулях.
Операції класу 3 є зворотними сто-
совно операцій селектора. Їхні механізми
конструювання відмінні від аналогічних
операцій, що є в МП.
Множина розглянутих операцій
класу 1, 2, 3 охоплює перетворення ТД
для МП, функції конструювання структу-
рних типів і вибору окремих компонентів.
Детальний розгляд показує, що для даної
множини операцій повнота відсутня. При-
чини цього розглядаються далі.
Виходячи з наведених визначень
постановка задачі перетворення ТД за за-
даним набором операцій класів 1–3 має
такий вигляд.
Нехай дано клас L = {l1,l2, ..., ln} і
для кожної з окремої мови відомі множи-
ни ТД і операції конструювання нових ти-
пів.
Необхідно: побудувати операції
перетворення ТД P = { Ptq
}, операції се-
лектора S і конструювання C.
Для рішення поставленої задачі
проводимо розбивку множин фактичних і
формальних параметрів і будування відо-
бражень ТД за допомогою операцій Р, S і
С. Якщо відображення одного типу до ре-
левантного типу іншого не вдається, то це
означає, зв’язування пари модулів не мо-
жливо або воно може бути реалізоване з
порушенням деяких властивостей, що роз-
глядалися.
Визначимо апарат опису ТД МП.
Кожен ТД характеризується множиною
значень, що можуть приймати змінні цього
типу, і множини операцій над цими змін-
ними.
Тому найбільш підходящим мето-
дом є опис ТД як алгебраїчних систем.
Операції перетворення типів P
tq
мають забезпечувати не тільки однозначну
відповідність множини значень перетво-
рюваних типів даних у модулях, які ви-
кликають, та тих модулях що виклика-
ються, але й однакову інтерпретацію опе-
рацій над даними в цих модулях. При цьо-
му має здійснюватися як пряме перетво-
рення даних викликаючого до викликаного
модуля, так і зворотне. При такому підході
операції перетворення P
tq
відповідають
ізоморфним відображенням однієї алгебра-
їчної системи в іншу. Тобто ми маємо
справу з ізоморфним відображенням мно-
жин фактичних і формальних параметрів.
Методи та засоби програмної інженерії
34
Висновок
У роботі розглянуто формальні під-
ходи до проектування РПС, які базуються
на ООП. Розроблено клас функціональних
і інтерфейсних об’єктів, які моделюються
при аналізі предметної області. Дано опис
мови IDL для подання даних функціональ-
них і інтерфейсних об’єктів, що забезпе-
чують їхню взаємодію у межах сучасних
середовищ. Запропоновано методику тес-
тування цих об’єктів окремо і разом в
комплексної структурі РС. Наведено фор-
мальні механізми перетворення з подання
простих і складних типів даних МП. Об-
ґрунтовано місце цього напряму дослі-
дження при проектуванні і тестуванні
РПС з різномовних програм й забезпечен-
ня їх взаємодії у сучасних середовищах
типу Grid та Cloud Computing.
1. Лаврищева Е.М. Проблема интероперабе-
льности разнородных объектов, компонен-
тов и систем. Подходы к ее решению //
Мат. VII Міжнар. конф. З програмуван-
ня “Укрпрог-2008.” –2008. – № 2–3. –
С. 28–41.
2. Лаврищева Е.М., Грищенко В.Н. Сбороч-
ное программирование. Основы индустрии
программных продуктов. – К.: Наук. дум-
ка, 2009. – 371 с.
3. Siegel J. CORBA Fundamentals and
Programming, Wiley Co. Publ. Group, John
Wiley & Sons, Inc. – USA. – 1996. – 694 p.
4. Эммерих В. Конструирование распреде-
ленных объектов // Методы и средства
программирования интероперабельных
объектов в архитектурах OMG/CORBA,
Microsoft COM и Java RMI. – М.: Мир,
2002. – 510 с.
5. Андон Ф.И., Лаврищева Е.М. Методы ин-
женерии распределенных компьютерных
приложений – К., Наук. думка, 1997. –
С. 228
6. Лаврищева Е.М. Методы програмирования
// Теория, инженерия, практика. – К.: Наук.
думка. – С. 451.
7. Лаврищева Е.М. Сборочное программиро-
вание. Теория и практика // Кибернетика и
системный анализ. – 2009. – № 6. –
C. 3–12.
8. Лаврищева Е.М. Програмна інженерія. –
Підручник.– К.: Академперіодика, 2008. –
317 с.
Одержано 24.02.2013
Про авторів:
Лавріщева Катерина Михайлівна,
доктор фізико-математичних наук,
професор,
завідувачка відділу програмна інженерія,
Стеняшин Адрій Юрійович,
аспірант Інституту програмних систем
НАН України.
Місце роботи авторів:
Інститут програмних систем
НАН України,
03187, Київ-187,
проспект Академіка Глушкова, 40.
Тел.: (044) 526 4579.
E-mail: lavryscheva@gmail.com
andrey.stenyashin@gmail.com
|
| id | pp_isofts_kiev_ua-article-739 |
| institution | Problems in programming |
| keywords_txt_mv | keywords |
| language | Ukrainian |
| last_indexed | 2025-07-17T09:37:32Z |
| publishDate | 2025 |
| publisher | PROBLEMS IN PROGRAMMING |
| record_format | ojs |
| resource_txt_mv | ppisoftskievua/96/a4522b0b05a5b7872d182f2968a0e596.pdf |
| spelling | pp_isofts_kiev_ua-article-7392025-04-16T13:52:57Z The formal basic developing and testing the distributed program systems Формалізми об’єктного проектування і тестування розподілених програмних систем Lavrischeva, K.M. Stenyashin, A.Yu. UDC 681.3 УДК 681.3 Problems in programming 2013; 4: 25-34 Розглядається підхід до проектування розподілених програмних систем формальним поданням об’єктів функціонального і інтерфейсного типів. Дається визначення об’єктів та операцій проекції, взаємодії та паралельного виконання. Дано опис мови подання інтерфейсів об’єктів IDL (stub, skeleton) і оброблення їх брокером ORB сиcтеми CORBA. Запропоновано процес тестування об’єктних структур програм та перетворення даних різнорідних об’єктів для забезпечення їх взаємодії у операційному середовищі.Problems in programming 2013; 4: 25-34 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2025-04-16 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/739 PROBLEMS IN PROGRAMMING; No 4 (2013); 25-34 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 4 (2013); 25-34 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 4 (2013); 25-34 1727-4907 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/739/791 Copyright (c) 2025 PROBLEMS IN PROGRAMMING |
| spellingShingle | UDC 681.3 Lavrischeva, K.M. Stenyashin, A.Yu. The formal basic developing and testing the distributed program systems |
| title | The formal basic developing and testing the distributed program systems |
| title_alt | Формалізми об’єктного проектування і тестування розподілених програмних систем |
| title_full | The formal basic developing and testing the distributed program systems |
| title_fullStr | The formal basic developing and testing the distributed program systems |
| title_full_unstemmed | The formal basic developing and testing the distributed program systems |
| title_short | The formal basic developing and testing the distributed program systems |
| title_sort | formal basic developing and testing the distributed program systems |
| topic | UDC 681.3 |
| topic_facet | UDC 681.3 УДК 681.3 |
| url | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/739 |
| work_keys_str_mv | AT lavrischevakm theformalbasicdevelopingandtestingthedistributedprogramsystems AT stenyashinayu theformalbasicdevelopingandtestingthedistributedprogramsystems AT lavrischevakm formalízmiobêktnogoproektuvannâítestuvannârozpodílenihprogramnihsistem AT stenyashinayu formalízmiobêktnogoproektuvannâítestuvannârozpodílenihprogramnihsistem AT lavrischevakm formalbasicdevelopingandtestingthedistributedprogramsystems AT stenyashinayu formalbasicdevelopingandtestingthedistributedprogramsystems |