Conceptual models of distributed component systems
The paper proposes formal models of software systems (SS) and their families (FS) for their use in a distributed environment. Their design begins with the object model of the subject area (SA) and ends with the construction of the corresponding component models. The basis of the PS and SPS are inter...
Gespeichert in:
| Datum: | 2025 |
|---|---|
| Hauptverfasser: | , |
| Format: | Artikel |
| Sprache: | Ukrainian |
| Veröffentlicht: |
PROBLEMS IN PROGRAMMING
2025
|
| Schlagworte: | |
| Online Zugang: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/774 |
| 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-774 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/2e/96cd3d44a294e1612951032c1464c72e.pdf |
| spelling |
pp_isofts_kiev_ua-article-7742025-08-27T13:11:22Z Conceptual models of distributed component systems Концептуальні моделі розподілених компонентних систем Lavrischeva, K.M. Kolesnyk, A.L. UDC 681.3 УДК 681.03 The paper proposes formal models of software systems (SS) and their families (FS) for their use in a distributed environment. Their design begins with the object model of the subject area (SA) and ends with the construction of the corresponding component models. The basis of the PS and SPS are interoperability and variability models that define how the systems function with each other. The link between the PS and the SPS is the interface that transfers data between systems and environments for execution and formation of new variants of the software product. A significant part of the described models and operations of their implementations is presented on the website of the instrumental and technological complex of the ITC IPS of NASU.Problems in programming 2013; 2: 13-22 Запропоновані формальні моделі програмних систем (ПС) і їх сімейств (СПС) для їх використання у розподіленому середовищі. Їх проектування починається з об'єктної моделі предметної області (ПрО) і закінчується побудовою відповідних компонентних моделей. Основу ПС і СПС складають моделі інтероперабельності і варіабельності, які визначають принцип функціонування систем між собою. Зв'язуючою ланкою між ПС і СПС є інтерфейс, який передає дані між системами і середовищами для виконання і формування нових варіантів програмного продукту. Значна частина описаних моделей і операцій їх реалізацій уявлена на сайті інструментально-технологічного комплексу ІТК ІПС НАНУ.Problems in programming 2013; 2: 13-22 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2025-08-27 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/774 PROBLEMS IN PROGRAMMING; No 2 (2013); 13-22 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 2 (2013); 13-22 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 2 (2013); 13-22 1727-4907 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/774/826 Copyright (c) 2025 PROBLEMS IN PROGRAMMING |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2025-08-27T13:11:22Z |
| collection |
OJS |
| language |
Ukrainian |
| topic |
UDC 681.3 |
| spellingShingle |
UDC 681.3 Lavrischeva, K.M. Kolesnyk, A.L. Conceptual models of distributed component systems |
| topic_facet |
UDC 681.3 УДК 681.03 |
| format |
Article |
| author |
Lavrischeva, K.M. Kolesnyk, A.L. |
| author_facet |
Lavrischeva, K.M. Kolesnyk, A.L. |
| author_sort |
Lavrischeva, K.M. |
| title |
Conceptual models of distributed component systems |
| title_short |
Conceptual models of distributed component systems |
| title_full |
Conceptual models of distributed component systems |
| title_fullStr |
Conceptual models of distributed component systems |
| title_full_unstemmed |
Conceptual models of distributed component systems |
| title_sort |
conceptual models of distributed component systems |
| title_alt |
Концептуальні моделі розподілених компонентних систем |
| description |
The paper proposes formal models of software systems (SS) and their families (FS) for their use in a distributed environment. Their design begins with the object model of the subject area (SA) and ends with the construction of the corresponding component models. The basis of the PS and SPS are interoperability and variability models that define how the systems function with each other. The link between the PS and the SPS is the interface that transfers data between systems and environments for execution and formation of new variants of the software product. A significant part of the described models and operations of their implementations is presented on the website of the instrumental and technological complex of the ITC IPS of NASU.Problems in programming 2013; 2: 13-22 |
| publisher |
PROBLEMS IN PROGRAMMING |
| publishDate |
2025 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/774 |
| work_keys_str_mv |
AT lavrischevakm conceptualmodelsofdistributedcomponentsystems AT kolesnykal conceptualmodelsofdistributedcomponentsystems AT lavrischevakm konceptualʹnímodelírozpodílenihkomponentnihsistem AT kolesnykal konceptualʹnímodelírozpodílenihkomponentnihsistem |
| first_indexed |
2025-09-17T09:21:25Z |
| last_indexed |
2025-09-17T09:21:25Z |
| _version_ |
1850410852975378432 |
| fulltext |
Теоретичні та методологічні основи програмування
© К.М. Лавріщева, А.Л. Колесник, 2013
ISSN 1727-4907. Проблеми програмування. 2013. № 2 13
УДК 681.03
К.М. Лавріщева, А.Л. Колесник
КОНЦЕПТУАЛЬНІ МОДЕЛІ РОЗПОДІЛЕНИХ
КОМПОНЕНТНИХ СИСТЕМ
Запропоновані формальні моделі програмних систем (ПС) і їх сімейств (СПС) для їх використання у
розподіленому середовищі. Їх проектування починається з об'єктної моделі предметної області (ПрО) і
закінчується побудовою відповідних компонентних моделей. Основу ПС і СПС складають моделі ін-
тероперабельності і варіабельності, які визначають принцип функціонування систем між собою. Зв'я-
зуючою ланкою між ПС і СПС є інтерфейс, який передає дані між системами і середовищами для ви-
конання і формування нових варіантів програмного продукту. Значна частина описаних моделей і опе-
рацій їх реалізацій уявлена на сайті інструментально-технологічного комплексу ІТК ІПС НАНУ.
Вступ
Процес побудови моделі ПрО або
домену, орієнтованої на її розуміння лю-
диною, називається концептуальним мо-
делюванням. Проблема, яку моделює ПрО,
формулюється у просторі її понять або на
перехресті декількох пов’язаних між со-
бою областей [1 – 3].
Кожна ПрО має притаманну їй сис-
тему понять, свої характерні властивості,
відношення та правила поведінки. Конце-
птуальна модель є базою знань для май-
бутніх користувачів. Ступінь формалізації
моделі має бути достатньою, щоб забезпе-
чувати точність та однозначність тракту-
вання базових понять і відношень між ни-
ми. Різними носіями інтересів у розробці,
відповідної ПС та водночас не надмірною,
щоб бути доступною для розуміння не
тільки спеціалістом за фахом та спромож-
ною відобразити деталі фахових проблем
для різних верств майбутніх користувачів.
Найпершим аспектом моделювання
домену для усіх відомих підходів може
вважатися його понятійна база, тобто сис-
тема понять, за допомогою якої формулю-
ються усі аспекти проблеми. Понятійна
база визначає не тільки термінологію,
якою мають користуватися носії інтересів,
що приймають участь у процесі аналізу
вимог, а також суттєві відношення між по-
няттями та їх інтерпретація.
У ментальній діяльності людини за-
стосовується ряд відношень, які дозволя-
ють будувати похідні поняття та встанов-
лювати між ними відношення та зв'язки.
Серед таких відношень назвемо найпоши-
реніші:
– узагальнення як звуження істот-
них ознак поняття, при цьому розширю-
ється коло охоплених поняттям об’єктів,
тобто його обсяг;
– конкретизація як додавання істот-
них ознак, завдяки чому зміст поняття ро-
зширюється, а обсяг поняття звужується;
– агрегація як об'єднання ряду по-
нять у нове поняття, істотні ознаки нового
поняття при цьому можуть бути або сумою
ознак компонент або суттєво новими;
– асоціація як найбільш загальне ві-
дношення, що стверджує наявність зв'язку
між поняттями, не уточнюючи залежність
їх змісту та обсягів.
Для окремих доменів чи предмет-
них областей можуть використовуватися
специфічні для них відношення. Ці від-
ношення фіксуються в структурі понятій-
ного базису проблемної області. При цьо-
му сукупність термінології, понять, харак-
терних для них відношень та парадигми
їхньої інтерпретації у межах домену чи
ПрО прийнято називати онтологiєю до-
менних знань.
Підходами для побудови моделі
ПрО є об’єктний і компонентний. Від-
повідно з об’єктної парадигми ПрО бу-
дується з об’єктів і їх відношень, а ком-
понентної парадигми проектування мо-
делі ПрО базується на понятті компоне-
нта (component – С) з реалізованими
Теоретичні та методологічні основи програмування
14
методами чи функціями, які можна вико-
ристовувати, як повторні в майбутній ар-
хітектурі ПС чи СПС.
Об’єктний підхід до
проектування ПрО
Об’єктно-орієнтований підхід
(ООП) визначає стратегію побудови
об’єктної моделі (ОМ) ПрО згідно теорії
Г. Буча, відповідно якої увесь «світ» скла-
дається з об’єктів [1].
Визначення об'єкта, як базисного
поняття ОМ, застосовується на двох при-
пущеннях:
для кожного об'єкта однозначно
визначається його відповідність до сутнос-
ті ПрО, включаючи відображення необхід-
них зв'язків та особливостей поведінки;
засіб подання ПрО за об'єктним
підходом визначає міру повноти відо-
браження сутності та поведінки як об'є-
кта, або міру адекватності його сприй-
няття замовником.
Повнота відображення сутності,
що задається об'єктом, відповідає мірі
абстракції та її відображенню у час його
опису. Для одночасного урахування обох
вимог у запропонованої концепції запро-
ваджується понятійна структура, що від-
повідає поняттю трикутника Фреге (ри-
сунок) згідно якої об'єкт є денотатом.
Символ використовується для ідентифі-
кації об'єкта, а денотат відповідає рівню
знань виконавця про сутність модельо-
ваного світу, що відбивається об'єктом.
Рисунок. Трикутник Фреге
Природно, що денотат можна іден-
тифікувати різним чином, використовую-
чи для цього обрані алфавіти, та одному
об'єкту можуть відповідати декілька кон-
цептів, відображаючи обраний рівень абс-
тракції. Кожному трикутнику Фреге в об-
раній логічній системі буде відповідати
певний об'єкт з власним ім'ям та певним
змістом.
Тобто об’єкт – це іменована части-
на дійсної реальності з певним рівнем абс-
тракції відносно вибраної ПрО та з цілком
обумовленої поведінкою. Поданням
об’єкта є понятійна структура у вигляді
трикутника Фреге.
При розгляду об’єктів ПрО вико-
ристовується принцип відміни кожного
окремого елемента ПрО з припущенням,
що він визначається через його особли-
вість – зовнішню і внутрішню.
Об'єкт, як певна сутність ПрО пере-
буває у різних станах і має певний набір
операцій, які надають іншим об’єктам пос-
луги (сервіси) для виконання методів.
Об'єкти поділяються по класам за їх осо-
бистими властивостями і в суперкласи за
загальними характеристиками (feature).
ОM включає самі об'єкти та їх їнтерфейси,
які відображають зв'язки між ними. Кож-
ний об'єкт має власний стан і набір опера-
цій, які впливають на стан інших об'єктів.
Об'єкти приховують інформацію про зна-
чення станів, операцій і обмежують доступ
до них.
До базових концепцій проектування
ОМ належать такі:
– концепція узагальнення понятій-
ній структурі ПрО, що відповідає форма-
льному поняттю трикутника Фреге;
– теоретико-множинна концепція з
операціями над об’єктами (об’єднання, рі-
зниці, декартового добутку тощо);
– логіко-алгебраїчна концепція для
опису множини об’єктів як алгебраїчної
системи з визначеною сукупністю преди-
катів певної сигнатури;
– концепція поведінки об’єктів у за-
лежності від терміну їх функціонування та
сформованих ними станів, що фіксуються
в діаграми переходів станів і використо-
вуються при виконанні об’єктів.
Теоретичні та методологічні основи програмування
15
Ці концепції реалізуються на рівнях
проектування ОМ з забезпеченням її пов-
ноти та коректності. Головною рисою рів-
нів проектування є зовнішні та внутрішні
характеристики об’єктів та їх опис на за-
даній множині об’єктів з встановленням
типів взаємовідношень: спеціалізація, аг-
регація, класифікація, асоціація, екземпля-
ризація тощо.
Будь яка ПрО подає собою сукуп-
ність понять, пов'язаних деякою множи-
ною відношень, яка визначає її поведінку
на протязі часу.
Базові поняття мають наступний
вигляд:
об’єктна орієнтація = об’єкти +
+ успадкування.
Кожне поняття ПрО, разом з його
властивостями та особливостями поведін-
ки у середовищі, є окремий об'єкт, а вся
ПрО – це сукупність об'єктів зі зв'язками,
які встановлюються на базі відношень між
цими об'єктами. У ролі об'єкта виступають
як абстрактні образи, так і конкретні фізи-
чні предмети або групи предметів з зазна-
ченою підмножиною їх характеристик та
функцій.
Модель предметної області (ПрО)
Предметна область – це сукупність
точних визначень понять, концептів
об’єктів реального простору предметної
області з їхніми характеристиками, а також
множини синонімів і класифікаційних ло-
гічних взаємозв’язків між цими поняттями.
Об’єкти як абстракції реального світу і по-
няттєва структура відображають функції
об’єктів і відношення між ними. Виділені в
ПрО об’єкти структурно впорядковуються
за допомогою теоретично множинних опе-
рацій (селекції, композиції, перетину то-
що) та об’єднуються за загальними озна-
ками у класи й суперкласи. Модель ПрО
подамо у вигляді
{ , , , , , },ПрО ПСM Mo Minc Мсх М P D
де Mo – множина об’єктів і відношень
між ними та відомостей у змісті функ-
цій і даних об’єктів, з якими вони функці-
онують;
Minc – модель взаємозв’язку
об’єктів між собою через інтерфейс;
Мсх – множина загальних характе-
ристик пов’язаних об’єктів через дані та
характеристики внутрішнього типу, що
притаманні кожному об’єкту і входять до
схеми композицій об’єктів задач ПрО;
ПСМ – модель програмної системи
чи СПСМ , які реалізують завдання та фун-
кції предметної області ПрО;
P – множина предикатів з порядку
і умов виконання об’єктів за їх функціо-
нальними і не функціональними характе-
ристиками моделі властивостей (featute) та
взаємозв’язку об’єктів моделі Mo , методи
яких забезпечують їх програмну реаліза-
цію в ПС;
D – множина даних предметної об-
ласті, які необхідні для виконання окремих
компонентів та ПС у цілому та які можуть
зберігатися у базах даних СУБД.
Підхід до подання формальних
компонентних ПС
Парадигма компонентного програ-
мування формулюється таким чином, щоб
перебудувати об’єктну модель ОМ в ком-
понентну, яка визначається на відповідній
множині компонентів, які реалізують ме-
тоди об’єктів моделі ПрО за їх інтерфей-
сами і властивостями, здатними до змін
деяких елементів та механізмів взаємодії
між ними і середовищем [3].
Тобто практично формується мно-
жина компонентів, адекватна множині
функцій (методів) об’єктів ОМ. Створю-
ється множина реальних компонентів С, з
яких необхідно сконструювати ПС за пев-
ними функціональними і нефункціональ-
ними вимогами, що були сформульовані
до об’єктної моделі. Завдання полягає у
тому, щоб представити ПС з об’єктної мо-
делі у вигляді компонентної моделі CM за
умови, що для будь-якого елемента
об’єктної моделі існував програмний ком-
понент із множини 1, 2, ,C C C CN
ОМ або він міг бути отриманий з іншої
множини, як готовий ресурс з раніше роз-
робленої ПС.
На практиці такі умови можуть ви-
конуватися не завжди (наприклад, розроб-
лена ПС має принципово нову функціона-
Теоретичні та методологічні основи програмування
16
льність) або її функції удосконалені, але
вони відповідають функціям об’єктів мо-
делі О. У таких випадках реалізуються до-
даткові компоненти, множина C розши-
рюється або зменшується за рахунок не-
потрібних. Це ініціює конфігурування но-
вого варіанта ПС з урахуванням умов чи
потреб замовника.
Таким чином, ПС створюються, як
правило, з компонентів, що розробляються
для реалізації функцій ПрО, чи відбира-
ються готові компоненти повторного ви-
користання (КПВ), що відповідають но-
вим функціям, накопиченим у сучасних
бібліотеках чи репозиторіях.
Побудова ПС з компонентів вико-
нується за такими принципами:
– композиційність складних систем з
компонентів;
– інженерність компонентної діяль-
ності з побудови реально існуючих
об’єктів ПрО, відповідних множині ком-
понентів і уніфікованих КПВ, каталогізо-
ваних у деяких сховищах для відбору но-
вих, необхідних для ПС;
– інтероперабельність КПВ і ПС за їх
інтерфейсами і правилами взаємодії ком-
понентів між собою та іншими системами
у різних середовищах їх функціонування;
– варіантність як здатність КПВ і
компонентних ПС до змін шляхом заміни
чи додавання нових функціональних
КПВ у конфігураційної структурі ПС чи
СПС;
– продуктивність ПС при обчисленні
в сучасних гетерогенних середовищах з
використанням особистих даних та даних,
що накопичені у сучасних віртуальних
сховищах даних [1 – 3].
Ці принципи є основополагаючими
для побудови розподілених ПС. Значна
частина побудови елементів моделей ПС і
СПС з компонентів і КПВ програмно реа-
лізовані в інструментально-технологіч-
ному комплексі (ІТК) [4] і на фабрики
програм КНУ імені Тараса Шевченка [5].
Для побудови ПС розроблено фо-
рмальну моделі ПрО, на основі якої бу-
дуються моделі ПС і СПС. Вони пода-
ються не тільки формально, але і сучас-
ними засобами типу патернів та workflow
з метою їх реалізації в операційному се-
редовищі для отримання готового про-
грамного продукту ПС компонентного
типу [6].
Далі розглядається низка формаль-
них моделей подання різних моделей ПС
і СПС, які сформовані і вдосконалені в
рамках фундаментальних проектів ІПС
НАНУ (2001 – 2012) на основі методу
ОКМ [6, 7]. В ньому запропоновано метод
проектування моделі ПрО із об’єктів за
теоретико-множинними операціями для
відображення об’єктів у моделі з рішення
задач ПрО, метод трансформації абстракт-
них описів об’єктів у форму програмних
компонентів шляхом їх реалізації і зану-
рювання в операційне середовище з ме-
тою накопичення деяких готових КПВ та
практичного виконання в ньому. ОКМ по-
даний сукупністю простих технологій реа-
лізацій окремих частин цих систем і збор-
ки їх методом конфігурації у нові ПС із
готових компонентів – КПВ, сервісів і
продуктів [5, 8, 9].
Модель програмної системи –
МПС. Програмна система – сукупність
окремих компонентів, які реалізовані з
об’єктів ПрО, з установленими інтерфей-
сами, взаємопов’язаними з функціями де-
якої ПрО у заданому середовищі. Програ-
мний компонент з загальної точки зору –
це самостійний продукт (код) методу чи
функції, що підтримує об'єктну модель,
реалізує частину або усю окрему предмет-
ну область і уміє взаємодіяти з іншими
компонентами системи через інтерфейси.
Модель ПС дамо у такому визначенні:
, , , ,ПСМ L Mf Ms Mi Md ,
де 1, 2, ,L L L Lk – мовні засоби
опису функцій чи задач предметної облас-
ті, одна з мов якої включає набір операцій
(actions) алгебри, щодо дій з реалізації і
виконання відповідних програмних ком-
понентів;
Mf – множина функцій моделі
ПрО, яка є по сутності моделлю об’єктів
ПрО 1, 2, , Mf O O Or цієї ПрО, ко-
жний об’єкт якої трансформується до ком-
понентного коду цієї функції відповідної
ПС ПрО;
Теоретичні та методологічні основи програмування
17
Ms , , , in out inoutMs Ms Ms –
множина сервісів, що базується на моделі
зв’язку і включає моделі передачі вхідних
даних inMs , вихідних даних outMs та сер-
верних даних inoutMs ПС на сервері
Application, базованих на множині систем-
них сервісів (Common Facility Services)
операційного середовища, які виконуються
спеціальним брокером чи монітором сер-
вісів тощо;
Mi – множина інтерфейсів у мові
IDL з описом вхідних (in) і вихідних па-
раметрів (out) та (inout) КПВ об’єднаного
типу для пари зв’язних компонентів у
структурі ПС. З практичної точки зору усі
загальні типи даних специфікуються як
зовнішні дані в паспорті моделі ПС з
об’єктів ПрО;
Md – множина даних та метаданих
предметної області ПС, які специфіковані
в КПВ, як примітивні чи складні фундаме-
нтальні типи даних, що є в кожній мові
програмування. ПС , а також в модулях
посередниках (stub, skeleton) у мові IDL.
Множини Minc, Ms та Mi пов’язані
з інтерфейсними та загальними даними і
мають перетин за даними, що віднесені до
in, out, inout, і входять до складу зовнішніх
типів даних, якими обмінюються по мере-
жі один компонентний об’єкт з іншим, що
розташованій на сервері Application. За пе-
реданими даними виконуються компонен-
ти і відправлять результати компоненту,
що звернувся з запитом чи протоколом до
серверного компонента.
Модель сімейства систем. Сімейст-
во систем СПС – це сукупність ПС, які ви-
значаються спільною множиною понять та
множиною спеціальних понять і характе-
ристик, що притаманні кожному члену
цього сімейства з реалізації деякої ПрО.
Поняття сімейства програм ввів Дей-
кстра (1970), яке основується на тому, що
програми мають спільну родинну мету, з
якої можуть породжуватися різні варіанти
інших програм, що потребують необхід-
ного коректування чи замінювання неко-
ректних або недостатньо визначених фун-
кцій, або для уточнення загальної постано-
вки задач сімейства у цілому.
Модель СПС включає моделі ПС,
задамо у вигляді:
1 2, , , , { ,СПС ПС ПС ПСkМ М М М Mgf
1, 2, , , , ,Msf Msf Msf Msfk Mi Мd
де 1 2 , , , ПС ПС ПСkМ М М – множина
членів сімейства ПС;
Mgf – множина зовнішніх характе-
ристик предметної області чи властивості
загального типу, що визначають загальну
термінологію та властивості усіх ПС сі-
мейства;
1, 2, , Msf Msf Msf Msfr –
множина внутрішніх характеристик кож-
ного окремого члена cімейства, поданого
моделлю ПС ( )ПСiМ тобто 1Msf для
1 , , ПСМ Msfr для ПСkМ ;
Mi – множина загальних інтерфей-
сів СПС, що подаються мовою IDL;
Minc – модель взаємозв’язку ПС
через елементи множини Mi ;
1, 2, , Мd Мd Мd Мdk } –
множина даних, що визначають кожного
члена ПС.
Монітор чи брокер запитів керує
функціями ПрО, відправляє за протокола-
ми типу RPC, RMI, Icontract дані, задані у
Minc і специфіковані мовою інтерфейса у
IDL чи API моделі клієнт-сервер і який
розуміє інтерфейсний посередник (stub,
skeleton).
Компонентна модель ПС – CМ.
Компоненти які використовуються з мно-
жини С типизовані таким чином [1, 2]:
– прості компоненти, що реалізують
деяку функцію ПрО;
– готові компоненти (КПВ, beans–
компоненти у мові Lava тощо);
– складні компоненти (каркас, патер-
ни тощо) зі схемою групування чи конфі-
гурування компонентів;
– інтерфейсні посередники, що міс-
тять опис параметрів з забезпечення
зв’язків між різними функціональними
компонентами між собою;
– сервісні елементи, що підтримують
різні системні дії з організації передачі
параметрів і даних, представлених в інте-
рфейсах чи контрактах, а також керування
Теоретичні та методологічні основи програмування
18
виконанням компонентів;
– засоби розгортання компонентів
через конфігураційний файл у відповідно-
му гетерогенному середовищі.
Таким чином, можливо сказати, що
компонентне програмування є самостій-
ним стилем програмування зі своєю кон-
цептуальною базою, теорією, методологі-
єю та інструментальними засобами. Він
доповнює об’єктну парадигму засобами
збирання чи композиції готових КПВ, що
значно спрощує процеси розробки і супро-
воду ПС за рахунок:
– формалізації та впорядкованості
процесу розробки окремих компонентів та
систем з КПВ зі зменшенням часу розроб-
ки і збільшення якості та надійності ПС з
компонентів;
– механізмів стандартного опису ін-
терфейсів компонентів для передачі да-
них компонентам, що будуть виконувати-
ся в інтегрованому середовищі за допомо-
гою відповідних загальносистемних серві-
сів та ін.;
– спрощення процесів побудови ПС
за формалізованими моделями зв’язку, ін-
терфейсів та компонентної ПС та викорис-
тання методів конфігурування для зби-
рання компонентів з множини С у різні
ПС з варіантами їх виконання.
Компонентна модель ПС є абстрак-
тним уявленням ПС, що конструюється з
компонентів, які є елементами цього уяв-
лення, якому зіставлені реальні функції чи
методи об’єктів ПрО для забезпечення ре-
алізації функціональності ПС та дотри-
мання не функціональних вимог щодо
ПрО. Для однієї і тієї ж ПС може існувати
множина компонентних моделей у зале-
жності від концепцій проектування і ви-
користовуваного компонентного підходу.
Модель компонентної моделі СМ відпові-
дає цілком і повністю структура моделей
МПС або однієї МПС з тою різницею, що
тут використовуються готові програмні
компоненти (КПВ), як ресурси різного
призначення.
На загальному рівні подання моде-
лі СМ ставиться завдання щодо пред-
ставлення її функціональності згідно ви-
мог у вигляді сукупності компонентів і їх
інтерфейсів або контрактів для забезпе-
чення взаємодії між собою окремих про-
грамних компонентів, з яких складається
модель.
1i
Нехай iA – множина інтерфейсів
за контрактами компонентів чи програм,
що визначають її функціональність. Кож-
ному iA описує контракт як клієнт-
серверну взаємодію з відповідними мето-
дами і структурами даних. Кожний інтер-
фейс має опис інтерфейсних даних, які
вже раніш перераховані, а саме – In, Out і
Inout. Їх будемо називати відповідно ви-
значальним поданням інтерфейсу (понят-
тя – вхідний, вихідний та проміжний ін-
терфейс). iIn визначає умови і мету конт-
ракту з боку клієнта, iOut задає реаліза-
цію компоненту з боку сервера, а Inout –
властивості інтерфейсів Ini і і iOut
Визначення інтерфейсів Ai для
компонентів моделі СМ можуть групува-
тися у різні поєднання з урахуванням се-
мантики характеристик загального і внут-
рішнього типів, що визначені для моделі
системи та компонентів і входять до скла-
ду компонентної моделі.
Довільна сукупність інтерфейсів iIn ,
jOut , i jInout , де i J, може не входить в
кожну таку сукупність і одночасно визна-
чати пари програмних компонентів при їх
збиранні в складну структуру.
Для кожної отриманої сукупності
пар , , , ijCi Iv Ci Iv OutJ Inout ство-
рюється модель компонента або шаблон,
який містить деяку множину параметрів,
які визначають і реалізують уявлення
інтерфейсів. За цими уявленнями надалі
здійснюється зіставлення шаблонів і інте-
рфейсів реальних компонентів.
Внаслідок операцій групування ви-
ходить множина пар Ci Iv , що буде зва-
тися контрактом компонентної моделі ПС.
Для однієї і тієї ж програми існує множи-
на таких моделей, які визначаються
множинами контрактів (або інтерфейсів)
зі способами розбиття на шаблони ком-
понентів для послідовного їх виконання.
Теоретичні та методологічні основи програмування
19
Загальне визначення алгебри
компонентів ПС
Нехай Х – множина об’єктів, де
ix X – довільний об’єкт деякої ПрО,
який задає функцію ПрО і пов’язаний з
іншими об’єктами відношенням зв’язку.
Цій множині відповідає множина програ-
мних компонентів C (C X ). Кожен ком-
понент реалізує функцію і характеризу-
ється деякими притаманними йому влас-
тивостями (наприклад, варіантність, змі-
нюваність тощо), які задаються в їх інтер-
фейсах.
Властивості чи характеристики ком-
понентів задаються загальними і особи-
стими типами за предикатами 1 2, ,...P P
..., kP , виходячи з умов виконання компо-
нентів на даних з множини xi X деякими
операціями, результати виконання яких
також будуть елементами множини X .
Тривіальними прикладами таких опера-
цій можуть бути – об’єднання кількох
об’єктів в один або декомпозиція деяко-
го програмного компоненту на окремі
елементи.
Нехай iR – множина операцій над
об'єктами з X . Кожна операція має власну
арність у залежності від її семантики. В
цілому існують операції, які задаються на
підмножинах з X , а також можна створю-
вати підмножину операцій (наприклад,
попередні операції об’єднання та деком-
позиції).
Серед множини операцій розгляда-
ються ті, які зберігають властивості
компонентів і їх результатів. Ці операції
1 2, ,..., mR R R виконуються над будь-якими
компонентами 1 2, ,..., mc c с C з ураху-
ванням арності операції iR та результату
двох видів: 1 2, ,..., mc c с C та 1 2, ,...c c
..., mс C ).
Множина C та операції 1 2, ,...R R
..., mR визначатимуть алгебру компонен-
тів. Прикладами реальних операцій над
компонентами можуть бути операції роз-
ширення інтерфейсів і факторингу для су-
купності нових компонентів за іншими
інтерфейсами, але з такою ж функціона-
льністю. Для кожної алгебри відповідає
властивостям компонентів Pі та операцій
Rі , формально визначених для множини
компонентів і які застосовуються в конк-
ретної теорії компонентного програмуван-
ня щодо конструювання програм і систем з
готових КПВ.
Визначення загальної множини
компонентів. Вищерозглянута множина
компонентів C є математичною абстрак-
цією. У реальному випадку мається на ува-
зі деяка множина реальних компонентів з
іс C . Застосувавши до цієї множини
операції 1 2, .,.., mR R R можна отримати
множину, яку будемо називати замикан-
ням множини С’. Цей термін обраний для
того, щоб підкреслити, що С’ є максима-
льно можливою множиною компонентів,
які можна отримати на основі вибраних
компонентів з множини C , відповідно до
іс C . У реальних процесах конструюван-
ня програм розглядається множина компо-
нентів C (або C’), але при цьому врахову-
ється, що для нього справедливі всі поло-
ження відповідної компонентної алгебри
при конкретній побудові компонентних
ПС, виконаної практично в ІТК [5].
Моделі взаємодії і варіабельності
ПС в сучасних середовищах
Під взаємодією розуміють суміс-
ність двох і більше об'єктів (програм і се-
редовищ між собою), яка пов’язана з об-
міном інформацією і використанням її
для організації обчислень у сучасних
операційних середовищах. Для завдання
взаємодії програм у мовах програмування
(МП) використовується апарат зв’язку
типу CALL, а для розподілених програм –
RPC, RMI, ORB (stub, skeleton), IContract
тощо. Взаємодія здійснюється інтерфей-
сом, який специфікується мовою IDL
(Interface Definition Language) допомогою
якої на загальному рівні передаються да-
ні компонентам, що знаходяться в різ-
них гетерогенних середовищах [7]. Для
опису взаємодії різнорідних компонентів
нами розроблено модель взаємодії. Го-
ловне її призначення – забезпечувати
взаємодію різнорідних компонентів, що
побудовані в інтегрованому середовищі
Теоретичні та методологічні основи програмування
20
ІТК з Eclipse, MS.Net, CORBA, Protégé
тощо [4, 5, 8 – 12].
Модель взаємодії interМ має та-
кий загальний вигляд:
, , inter pro sys envМ М М М ,
де , , proМ Com Int Pro – модель про-
грами, Com – компонент, Int – інтерфейс,
Pro – програма;
, , sysМ PS Int Prot – модель
програмної системи PS, Int – інтерфейс,
Prot – протокол зв’язку для передачі да-
них; через мережу;
, , envМ Envir Int Pro – модель
середовища, в якому Int, Pro відображають
сукупність зовнішніх інтерфейсів, ви-
кликів та протоколів, що забезпечують
передачу даних між програмами або сис-
теми через мережу відповідно.
Фактично Мinter щодо стандартної
семирівневої моделі відкритих систем OSI,
є моделлю верхнього рівня.
Програмні компоненти і системи й
інтерфейси специфікуються відповідною
МП, інтерфейсом IDL, протоколами з
XDL, RDF, що зберігаються в бібліоте-
ках і репозиторіях ІТК. Новим способом
взаємодії між програмами типу клієнт і
сервер є інтерфейс типу Icontract системи
WCF [ ], який призначений для опису ат-
рибутів та операцій для передачі даних
від сервісного об’єкта (Service consumer)
до клієнтського (Service provider) за конт-
рактами Icontracts.
Базисом інструментального середо-
вища ІТК є Eclipse, як засіб керування ре-
позиторієм КПВ і його використання для
зборки в складну структуру. В процесі вза-
ємодії програм і систем через інтерфейс
при обчисленнях у тому чи іншому сере-
довищі застосовуються різні механізми
перебудови типів даних з різних форматів
даних їх опису і формою трансформації
типів даних у системах програмування з
МП та використання бібліотек функцій і
процедур з примітивами перетворення різ-
них даних.
Практичним рішенням задач взає-
модії в ІТК є моделі розподілених систем:
– Visual Studio.Ne Eclipse реалізує
взаємодію програм у мові С# на основі
опису специфікації інтерфейсу, перенесен-
ня готового продукту в репозиторій систе-
ми Eclipse, що відображає зв'язок з даним
середовищем програм через плагини і
конфігураційний файл з параметрами і
операціями оброблення даних у даному
середовищі;
– CorbaJavaMS.Net забезпечує
встановлення зв’язків між цими програм-
ними середовищами шляхом розміщення
програм в МП у репозиторії ІТК та надан-
ня доступу до них інших програм;
– IBM Eclipse орієнтована на нові
програми в МП з використання інтерфей-
су, що допускаються у цьому середовищі
та у віртуальному варіанті VSphere.
Тобто при переході в середовище
Eclipse використовуються вихідні файли
програми, dll–бібліотки VS та файли ресу-
рсів (.resx). Коли необхідно знов перейти із
цього середовище в Visual Studio, вся про-
ектна програма імпортується туди і зворо-
тньо. Обчислення програми та її зміню-
вання можна виконувати як у середовищі
Eclipse, так і у Visual Studio. Модель IBM
Eclipse буде продовжено надалі у випадку
використання сервісів для взаємодії про-
грам, як обчислень у розширеному сере-
довищі ІТК.
Модель варіабельності ПС і СПС.
Варіабельність це властивість де-
якого програмного об’єкта до розширення,
змінювання, пристосування або конфігу-
рування з метою використання у визначе-
ному контексті та забезпечення подальшо-
го еволюціонування. Програмування ПС
як членів СПС з КПВ у парадигмі СПС
стала важливим засобом для забезпечення
еволюційності ПС за рахунок побудови
різних варіантів продукту в залежності від
зміни деяких функцій деяких окремих
компонентів [4, 5, 11, 12].
СПС із ПС має спільну множину
характеристик, відповідних потребам пев-
них функціональних варіантів ПрО, розрі-
зняються способами втілення цих характе-
ристик в окремі ПС і розробляються з ви-
користанням готових ресурсів. ПС ство-
рюються не «з нуля», а породжуються за
моделлю СПС або обираються для неї го-
Теоретичні та методологічні основи програмування
21
тові КПВ з репозиторіїв, після чого адап-
туються і збираються у нову структуру
ПС [ ].
Модель СПС пов’язана з об’єкт-
ною і її компонентною моделлю ПрО і
доповнена точками варіантності, створив
розширену модель сімейства варіантної
системи (СВС) за таким формальним ви-
глядом:
, Int, CСВСМ Мпс , C CC BC ;
**
3, , !Bc ib rb BC o
**
3 3| ( )L ib met o ,
**
3( ) , dat o rb im ib ;
*
3 3 3, ! \ |CC ic rc CC o O L ic
* *
3 3( ), ( ) ,met o dat o
3 3{ ,u uBC met o dat o ,
*
3 3Part _ of ( , )}, ,uo o rc im ic
де bcBC і CC – унікальні імена КПВ, на-
званих базовими та складними;
ib, rb – вхідний інтерфейс і реаліза-
ція базового КПВ, яка підтримує інтерфейс
базового КПВ: 1 2,bc bc BC 1im bc
2im bc ;
ic, rc – вхідний s вихідні інтерфейси
та реалізація складного КПВ;
im() – функція, що надає множину
реалізацій інтерфейсу;
,ij i jcr c c Int – відношення
Part_of: 3 3, Part _ of ,i j i jc c NC o o ,
що пов’язує КПВ, прототипи яких 3 3,i jo o
в об’єктній моделі.
Компонентна модель програмного
КПВ входить в модель CВС. Для забезпе-
чення властивостей варіантності й змінно-
сті ПС з СПС проведено узагальнення на-
ведених моделей для послаблення відно-
шення Part_of.
Нехай tC : 0;1tO і tD : { t tvp O
| 1} 2 0;1Ot
tC vp , 1,...,4t – деякі
предикати, які для об’єкта ,tj t t to O С D
декомпозує варіант об’єкта ti to O
, ; ,t t t i t jVP C D o o , якщо реалізація в
певній ПС об’єкта тягне за собою реаліза-
цію нового об’єкта тоді й тільки тоді, коли
1t tiC o , |ti t ti tjSO O o o
tiSO , , 1t ti tiD o SO , 1,..., 4t .
Об’єкти tio і tjo у даному виразі
будемо звати об’єктною точкою варіант-
ності та варіантом підпорядкованого
об’єкта для tio , а предикати tC і tD – об-
меженням на точки варіантності й залеж-
ністю між варіантами.
Процес розроблення СПС як про-
грамного продукту розроблено на Веб-
сайті, у вигляді декількох спрощених тех-
нологій.
Висновок
Наведені формальні моделі ПС і
СПС та моделі взаємодії і варіабельності з
використанням КПВ пройшли апробацію в
ІТК і відображені в ряді наведених публі-
кацій. Вони є нові й оригінальні, розроб-
лені за участю аспіранта даної роботи та
старшого наукового співробітника Слабо-
спицкої О.О. при виконанні фундамента-
льного проекту ІПС НАНУ «Розробка тео-
ретичного фундаменту генеруючого про-
грамування та інструментальних засобів
його підтримки”(2007 – 2011). Основні ре-
зультати проекта опубліковані в заключ-
ному звіті та в е-монографії, дисертацій-
ної роботі та реалізовані на Веб-сайті
http://sestudy.edu-ua/com.
1. Лавріщева К.М. Взаємодія програм, систем
й операційних середовищ // Проблеми
програмування. – 2011. – № 3. – С. 13–24.
2. Лавріщева К.М., Слабоспицька О.О., Ко-
валь Г.І., Колесник А.О. Теоретичні аспек-
ти керування варіабельністю в сімейст-
вах програмних систем. – Вісник КНУ,
серія фіз.-мат. наук. – 2011. – № 1. –
С. 151 – 158.
3. Лаврищева Е.М., Грищенко В.Н. Сбороч-
ное программирование. Основы индустрии
програмных продуктов. – Киев: Наук. дум-
ка, 2009. – 377 с.
4. Колесник А.Л. Механізми забезпечення
варіабельності в сімействах програмних
систем // Проблеми програмування. – 2010.
– № 1. – C. 35–44.
http://sestudy.edu-ua/com
Теоретичні та методологічні основи програмування
22
5. Колесник А.Л. Підходи до забезпечення
варіабельності схем баз даних у сімействах
програмних систем // Молодь і наука: су-
часний стан, проблеми та перспективи на-
ціонального відродження України: Матері-
али ІІ Міжвузівської студентської науково-
практичної конференції. – К.: МНТУ, 2010.
– С. 323–324.
6. Лавріщева К.М., Коваль Г.І., Бабенко Л.П.
та ін. Нові теоретичні засади технології
виробництва сімейств програмних систем
у контексті ГП – Електронна монографія,
ДРНТІ. – № 67–УК–2011 від 5.10.11.
– 377 с.
7. Лаврищева К.М. Компонентне програму-
вання. Теорія і реалізація // Проблеми
програмування. – 2012. – № 4. – С. 3–18.
8. Лавріщева Е.М., Зинькович В.М., Колесник
А.Л. та ін. Інструментально-технологічний
комплекс розробки та навчання прийомам
виробництва програмних систем. – Держа-
вна служба інтелектуальної власності
України. – Свідоцтво про реєстрацію ав-
торського права на твір. – № 45292, від
27.08.2012.
9. Lavrischeva E., Ostrovski A., Radetskyi I.
Approach to E–Learning Fundamental
Aspects of Software Engineering // 8-th
International Conf. ICTERI – 2012 “ICT
in Education, Research and Industrial
Applications”. – Publ. springer –
sbm.com/ocs/home/ ICTERI–2012.
10. Lavrischeva E., Ostrovski A. General
Disciplines and Tools for E– Learning
Software Engineering. –
http://senldogo0039.springer-sbm.com/ocs/
11. Kolesnyk
A., Slabospitskaya
O. Tested
Approach for Variability Management
Enhancing in Software Product Line. – In:
Ermolayev V., Mayr H.C., Nikitchenko M. et
al. (eds.): ICT in Education, Research and
Industrial Applications: Integration,
Harmonization and Knowledge Transfer.
Proc. // 8-th Int. Conf. ICTERI 2012,
Kherson, Ukraine, June 6-10, 2012, CEUR-
WS.org/Vol: 848, – P. 125–133.
12. Slabospitskaya O., Kolesnyk A. The Model for
Enhanced Variability Management Process in
Software Product Line – Preproc // of 4th
International United Information Systems
Conference (UNISCON 2012), Crimean State
Humanitarian University, Yalta, Ukraine,
June 1 – 3, 2012 – Available at
http://www.uniscon.org/images/
uniscon/downloads/UNISCONPapers.zip
Одержано 10.10.2012
Про авторів:
Лавріщева Катерина Михайлівна,
доктор фізико-математичних наук,
професор, завідуюча відділом,
Колесник Андрій Леонідович,
молодший науковий співробітник.
Місце роботи авторів:
Інститут програмних систем
НАН України,
03187, Київ–187,
проспект Академіка Глушкова, 40.
Тел.: 526 3470.
http://senldogo0039.springer-sbm.com/ocs/
http://www.uniscon.org/images/
|