The formal basic developing and testing the distributed program systems

The formal basic developing and testing the distributed program systems

Problems in programming 2013; 4: 25-34

Gespeichert in:
Bibliographische Detailangaben
Datum:2025
Hauptverfasser: Lavrischeva, K.M., Stenyashin, A.Yu.
Format: Artikel
Sprache:Ukrainian
Veröffentlicht: Інститут програмних систем НАН України 2025
Schlagworte:
UDC 681.3
Online Zugang:https://pp.isofts.kiev.ua/index.php/ojs1/article/view/739
Tags: Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
Назва журналу:Problems in programming

Institution

Problems in programming
id pp_isofts_kiev_ua-article-739
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 Інститут програмних систем НАН України 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
institution Problems in programming
baseUrl_str https://pp.isofts.kiev.ua/index.php/ojs1/oai
datestamp_date 2025-04-16T13:52:57Z
collection OJS
language Ukrainian
topic
UDC 681.3
spellingShingle
UDC 681.3
Lavrischeva, K.M.
Stenyashin, A.Yu.
The formal basic developing and testing the distributed program systems
topic_facet
UDC 681.3

УДК 681.3
format Article
author Lavrischeva, K.M.
Stenyashin, A.Yu.
author_facet Lavrischeva, K.M.
Stenyashin, A.Yu.
author_sort Lavrischeva, K.M.
title The formal basic developing and testing the distributed program systems
title_short The formal basic developing and testing the distributed program systems
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_sort formal basic developing and testing the distributed program systems
title_alt Формалізми об’єктного проектування і тестування розподілених програмних систем
description Problems in programming 2013; 4: 25-34
publisher Інститут програмних систем НАН України
publishDate 2025
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
first_indexed 2025-07-17T09:37:32Z
last_indexed 2025-07-17T09:37:32Z
_version_ 1838499757978288128
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. Якщо у об’єкта 1CТ або 0CТ , то це означає, що об'єкт 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]. У зв’язку з тим, що отримується СT1 просто, маємо формулу:    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

Ähnliche Einträge