Метод об'єктно-компонентного проектування програмних систем

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

Повний опис

Збережено в:

Бібліографічні деталі
Дата:	2007
Автор:	Грищенко, В.М.
Формат:	Стаття
Мова:	Українська
Опубліковано:	Інститут програмних систем НАН України 2007
Теми:	Інструментальні засоби і середовища програмування
Онлайн доступ:	https://nasplib.isofts.kiev.ua/handle/123456789/292
Теги:	Додати тег Немає тегів, Будьте першим, хто поставить тег для цього запису!
Назва журналу:	Digital Library of Periodicals of National Academy of Sciences of Ukraine
Цитувати:	Метод об'єктно-компонентного проектування програмних систем / В.М. Грищенко // Пробл. програмув. — 2007. — N 2. — С. 113-125. — Бібліогр.: 9 назв. — укp.

Репозитарії

Digital Library of Periodicals of National Academy of Sciences of Ukraine

_version_	1859584071951187968
author	Грищенко, В.М.
author_facet	Грищенко, В.М.
citation_txt	Метод об'єктно-компонентного проектування програмних систем / В.М. Грищенко // Пробл. програмув. — 2007. — N 2. — С. 113-125. — Бібліогр.: 9 назв. — укp.
collection	DSpace DC
description	Запропоновано комплексний метод проектування компонентних програмних систем, який засновано на концепції двофазового аналізу та проектування. Завдання першої фази полягає в аналізі предметної області (ПрО) з метою побудови моделі, яка адекватно відображає структуру ПрО та її властивості. До складу задач другої фази входить проектування конкретних компонентів і компонентних систем на базі результатів аналізу ПрО. Наведено необхідну термінологію, формальні моделі, математичний апарат, які визначають концепції та зміст запропонованого методу.
first_indexed	2025-11-27T08:59:43Z
format	Article
fulltext	Інструментальні засоби і середовища програмування © В.М. Грищенко, 2007 ISSN 1727-4907. Проблеми програмування. 2007. № 2 113 УДК 681.03 В.М. Грищенко МЕТОД ОБ’ЄКТНО-КОМПОНЕНТНОГО ПРОЕКТУВАННЯ ПРОГРАМНИХ СИСТЕМ Запропоновано комплексний метод проектування компонентних програмних систем, який за- снований на концепції двохфазового аналізу та проектування. Завдання першої фази полягає в аналізі предметної області з метою побудови моделі, яка адекватно відображає структуру ПрО та її властивості. До складу задач другої фази входить проектування конкретних компонентів та компонентних систем на основі результатів аналізу ПрО. Наведено необхідну термінологію, формальні моделі, математичний апарат, які визначають концепції та зміст запропонованого методу. Вступ Одним з найбільш поширених су- часних методів програмування є компоне- нтний підхід, суть якого полягає у побу- дові програмних систем шляхом інтеграції окремих самостійних програмних елемен- тів – програмних компонентів [1]. Поняття самостійності компонента означає, що він у загальному випадку створюється без орієнтації на конкретне застосування, тобто передбачається, що компонент буде застосовуватись у різних компонентних системах за умови виконання вимог щодо його функціональних можливостей та вла- стивостей у компонентному середовищі. Забезпечення умов широкого засто- сування компонента є однією з головних цілей на етапі його розробки. Крім уніфікації та стандартизації архітектурних, структурних, технологічних характеристик компонента, важливу роль відіграє вибір його функціональності та методів доступу до неї. Це, у свою чергу, потребує більш детального підходу до визначення та специфікації компонента щодо певної предметної області (ПрО), задач, які вирішуються цією ПрО, конкретних функцій обробки даних тощо. Складність цього підходу полягає у тому, що для ком- понента не існує наперед визначених фун- кціональних вимог, як у випадку специфі- кації компонентів для конкретної цільової системи. Тому необхідною умовою розро- бки компонентів багаторазового застосу- вання є умова існування певних об’єктивних концепцій, принципів, крите- ріїв щодо вибору та специфікації їх функ- ціональних властивостей. Одним з найбільш обгрунтованих підходів щодо визначення таких концепій та принципів є застосування процесів кон- цептуального моделювання ПрО з відпові- дним визначенням понять та сутностей предметної області, їх взаємовідношень, атрибутів, поведінки тощо. Умова об’єктивності цього підходу полягає у аде- кватності подання елементів ПрО щодо понять та об’єктів дійсної реальності, які входять до складу відповідної предметної області. Одним з основних результатів концептуального моделювання є об’єктна модель ПрО, на основі окремих об’єктів чи фрагментів якої визначаються функціона- льні властивості компонентів, що будуть розроблені у рамках цієї ПрО та застосо- вані при побудові різних компонентних систем з відповідними функціональними вимогами. У роботі пропонується метод об’єктно-компонентного проектування програмних систем, який узагальнює та формалізує підхід щодо створення компо- нентних систем із застосуванням концеп- туального моделювання ПрО. Сутність ме- тода полягає у формалізації процесу прое- ктування програмної системи, який скла- дається з двох фаз. На першій фазі засто- совуються формальний апарат та методи об’єктно-орієнтованого аналізу для кон- цептуального моделювання ПрО та побу- дови об’єктної моделі. З другою фазою пов’язане безпосереднє проектування окремих компонентів та компонентних програм їз застосуванням компонентно- орієнтованих моделей. При цьому між обома типами моделей встановлюються Інструментальні засоби і середовища програмування 114 еквівалентні відображення, що забезпечу- ють формальне перетворення об’єктного подання в компонентне. Мета, принципи та сутність фази об’єктного аналізу Для розробки формалізмів першої фази методу об’єктно-компонентного про- ектування застосовуються загальні конце- пції щодо підходів та методів об’єктно- орієнтованого аналізу та проектування [2, 3]. Проте їх сутність та зміст підпорядко- вані побудові подання об’єктної моделі, яке забезпечує його подальше відобра- ження у компонентну модель. Головна мета об’єктного аналізу – подати предметну область як множину об’єктів з властивостями та характеристи- ками, які необхідні й достатні для визна- чення та ідентифікації окремих об’єктів, а також опису їх поведінки у рамках вибра- ної системи понять та абстракцій. Визначення поняття об’єкту. Ви- ходячи з умови максимальної адекватності об’єктної моделі дійсній реальності, у ме- тоді об’єктно-компонентного проекту- вання визначається поняття об’єктів на ос- нові концепцій теорії Фреге [4]. Кожен з об’єктів подається як трикутник Фреге з наступними складовими (рис.1): – знак – ідентифікатор, який має властивість позначати певну сутність з дійсної реальності, що може бути предметом, подією, поняттям тощо з певним змістом; – денотат – сутність з дійсної реа- льності, яку позначає знак; – концепт – сутність (семантика) денотату. Згідно з такою концепцією визнача- ється поняття об’єкта. Об’єкт – іменована частина дійсної реальності з певним рів- нем абстракції щодо вибраної предметної області та з цілком обумовленою поведін- кою. Поданням об’єкта є понятійна струк- тура у вигляді трикутника Фреге. Процес об’єктного аналізу ПрО ви- конується згідно з наступними принци- пами. Принцип загальності об’єктного визначення. На довільному кроці об’єктного аналізу всі сутності – суть об’єкти. Наслідок 1. Предметна область, що моделюється, сама є об’єктом. Рис.1. Подання об’єкту як трикутника Фреге Знак Концепт Денотат Дійсна реальність Виражає Визначає Позначає Інструментальні засоби і середовища програмування 115 Наслідок 2. Предметна область, що моделюється, може бути окремим об’єк- том у складі іншої предметної області (ви- значається ієрархія предметних областей). Принцип суттєвості об’єктних ві- дмінностей. На довільному кроці об’єктного аналізу кожний об’єкт є уніка- льним елементом. Наслідок. Кожний об’єкт має при- наймі одну властивість чи характеристику, яка дозволяє його унікальну ідентифікацію у множині об’єктів. Принцип об’єктної впорядкова- ності. На довільному кроці об’єктного аналізу всі об’єкти впорядковані відпові- дно до відношень між об’єктами. Наслідок. Кожний об’єкт має при- наймі одне відношення з іншим об’єктом, яке забезпечує його впорядкованість в ра- мках цієї пари об’єктів. Принцип цілісності об’єктної мо- делі. На довільному кроці об’єктного ана- лізу сукупність об’єктів та відношень між ними однозначно визначає об’єктну мо- дель (ОМ) вибраної предметної області для певного рівня абстракції опису цієї ПрО. Наслідок. На довільному кроці об’єктного аналізу об’єктну модель можна подати у вигляді орієнтованого зв’язного графу, вершинами якого є об’єкти, а дугам відповідають відношення між об’єктами. Основні формальні рівні абстра- кції подання об’єктів. Вищенаведені принципи та загальне визначення об’єкта є основою формування послідовності рівнів подання об’єктів та об’єктної системи в цілому. На кожному з цих рівнів застосо- вується певний математичний апарат [5]. Узагальнюючий рiвень. Об’єкт – це клас (клас у цьому випадку розгляда- ється як відповідне математичне поняття згідно з аксиоматичної теорії множин Ге- деля–Бернайса). Нехай E=(E0, E1, … En) – сукупність об’єктів для предметної обла- сті, де E0 відповідає самій предметній об- ласті (принцип загальності об’єктного ви- значення). Тоді ∀i∃j[(i>0)&( j≥0)& (i ≠ j)& (Ei∈ Ej)]. (1) Між певними елементами множини E існують відношення належності. Структурно-впорядковуючий рiвень. Об’єкти вже визначені на узагаль- нюючому рівні і кожен з них подається як множина або елемент певної множини. Виключаючи з E елемент E0, який не на- лежить іншим елементам, отримуємо множину E'=(E1, E2, … En). Вираз (1) тран- сформується у такий: ∀i∃j[(i>0)&( j>0)& (i ≠ j)& (Ei∈ Ej)]. (2) У виразі (2) кожен з об’єктів є мно- жиною або елементом певної множини (згідно з визначенням множини в теорії Геделя–Бернайса) і до них застосовуються операції теоретико-множинної алгебри. Також цей вираз визначає об’єктні відношення “частка-ціле”, екземпляриза- ція, агрегація тощо. Нехай Ω – сукупність теоретико-множинних операцій. Тоді Σ = (E', Ω) визначає алгебраїчну систему для структурно-впорядковуючого рівня. Характеристичний рівень. Об’єк- ти вже визначені на структурно-впоряд- ковуючому рівні і для кожного з них формується його концепт. Якщо E'=(E1, E2, … En) – сукупність об’єктів ПрО, а P'=(P1, P2, … Pr) – множина унарних предикатів, які пов’язані із властивостями об’єктів ПрО, то концепт об’єкта Ei є множиною тверджень, які побудовані на основі пре- дикатів з P', що приймають значення істи- ни для відповідного об’єкта. Концепт Coni = {Pik} за умови, що Pk( Ei) = true, де Pik є твердженням для об’єкта Ei згідно з предикатом Pk. Цим для об’єктів визна- чаються їх властивості і характеристики в рамках певної системи абстракцій для кон- кретної ПрО. Вираз Λ = (E', P') визначає алгебраїчну систему (алгебраїчну модель) для характеристичного рівня. Згідно зі структурами концептів між об’єктами визначаються відношення типу “рід–вид” та похідні від нього. Поведінковий рівень. Об’єкти вже визначені на характеристичному рівні. У відповідності з концепціями формування поведінки [6] на основі сукупності атрибу- тів об’єктів та їх значень визначаються по- слідовності станів об’єктів та будуються їх життєві цикли, що відображається у діаг- рамах переходів станів. Взаємозв’язки між Інструментальні засоби і середовища програмування 116 об’єктами формуються на основі бінарних предикатів, які пов’язані із властивостями об’єктів ПрО, і деталізуються до рівня вза- ємозв’язків між станами об’єктів. Залеж- ність від параметра часу досягається вне- сенням у об’єктну модель спеціального об’єкта Timer, основне призначення якого полягає у розсилці спеціальних повідом- лень поточного часу з певним рівнем дис- кретності. Кожен об’єкт має відповідний метод, який аналізує отримане значення і виконує перехід до іншого стану або за- лишає його без змін. Основні функції об’єктного ана- лізу. Відповідно до розробленого форма- льного апарату визначено множину базо- вих функцій об’єктного аналізу, які пов’язані з декомпозиційними та компози- ційними змінами денотатів та концептів об’єктів під час концептуального моделю- вання ПрО. Множина складається з 10 фу- нкцій, які охоплюють трансформації дено- татів та концептів у процесі об’єктного аналізу і до складу яких входять зміни, що пов’язані із збільшенням або зменшенням кількості об’єктів (деталізація, екземпля- ризація, агрегація та ін.) та розширенням або звужуванням концептів об’єктів. Проте ці зміни підпорядковуються певним правилам та умовам, які забезпечують ко- ректність виконання функцій, а також від- буваються у відповідності до наведеного багаторівневого підходу. Визначені насту- пні функції об’єктного аналізу. Декомпозиційні зміни денотату: – відповідна сутність дійсної реаль- ності, яка відповідає певному об’єкту, по- дається як сукупність однорідних предме- тів; – відповідна сутність дійсної реаль- ності, яка відповідає певному об’єкту, по- дається як сукупність неоднорідних пред- метів. Композиційні зміни денотату: – денотати кількох однорідних пре- дметів подаються як складові певної сут- ності з вибраної предметної області; – денотати кількох неоднорідних предметів подаються як складові певної сутності з вибраної предметної області. Зміни концептів, які відповідають декомпозиційним змінам денотатів: – концепти нових деталізованих об’єктів формуються на основі концепту початкового об’єкта; – концепти нових деталізованих об’єктів формуються без врахування кон- цепту початкового об’єкта. Зміни концептів, які відповідають композиційним змінам денотатів: – концепт нового композиційного об’єкта формується на основі однакових концептів початкових об’єктів; – концепт нового композиційного об’єкта формується на основі різних кон- цептів початкових об’єктів. Зміни рівня деталізації (абстрак- ції) концептів: – з концепту об’єкта виключається одна чи кілька властивостей або характе- ристик при формуванні концепту нового об’єкта з однаковим денотатом; – в концепт об’єкта включається одна чи кілька властивостей або характе- ристик при формуванні концепту нового об’єкта з однаковим денотатом. Алгебра об’єктного аналізу. Не- хай E=(E1, E2, … En) – множина об’єктів на певному кроці об’єктного аналізу і Ei = Ei(Namei, Deni, Coni), де Namei, Deni, Coni – знак (ім’я), денотат та концепт відповідно. P=(P1, P2, … Pr) – множина предикатів, на основі яких визначаються концепти об’єктів Coni = (Pi1, Pi2, … Pis). Введемо на- ступні базові операції: 1. Декомпозиційна зміна денотату для формування нових однорідних об’єктів: decds(Ei): Ei → (Ei1, … Eik), де Eij = Eij(Nameij, Denij, Conij); ∀j Conij = = Coni; Deni = Deni1 ∪ . . . ∪ Denik. 2. Декомпозиційна зміна денотату для формування нових неоднорідних об’єктів: decdn(Ei): Ei → (Ei1, … Eik), де Eij = Eij(Nameij, Denij, Conij); ∀j Conij = = ∅; Deni = Deni1 ∪ . . . ∪ Denik. 3. Композиційна зміна денотатів однорідних об’єктів для формування но- вого об’єкта: comds(Ei1, … Eik): (Ei1, … Eik) → Ei, де Ei = Ei(Namei, Deni, Coni); ∀j Coni = = Conij; Deni1 ∪ . . . ∪ Denik = Deni. Інструментальні засоби і середовища програмування 117 4. Композиційна зміна денотатів неоднорідних об’єктів для формування но- вого об’єкту: comdn(Ei1, … Eik): (Ei1, … Eik) → Ei, де Ei = Ei(Namei, Deni, Coni); Coni = ∅; Deni1 ∪ . . . ∪ Denik = Deni. 5. Розширення концепту існуючого об’єкта. Якщо предикат Pt ∈ P, Pt ∉ Coni і Pt(Ei) приймає значення істини, то conexp(Ei, Pt): Ei → Ei`, де Ei` = Ei`(Namei, Deni, Coni`); Coni ∪ ∪ {Pt} = Coni`. 6. Звуження концепту існуючого об’єкта. Якщо предикат Pt ∈ Coni, то connar(Ei, Pt): Ei → Ei`, де Ei` = Ei`(Namei, Deni, Coni`); Coni`= = Coni \ Pt. Цим для множини функцій об’єктного аналізу побудована алгебра об’єктного аналізу Σ = (E', Ψ), де E'=(E1, E2, … En) – множина об’єктів, а Ψ = {decds, decdn, comds, comdn, conexp, connar} – множина операцій над елемен- тами E'. Кожна з операцій має певний пріоритет та арність, а також пов’язана з відповідними допустимими змінами дено- татів та концептів. Для обгрунтування переходу від функцій об’єктного аналізу до операцій алгебри об’єктного аналізу сформульовано та доведено наступну теорему. Теорема 1. Множина операцій Ψ алгебри Σ – повна система операцій щодо функцій об’єктного аналізу. Правила об’єктного аналізу. Кон- цептуальне моделювання певної ПрО має ітеративний характер і починається з ви- значення самої ПрО як початкового об’єкта ОМ. На кожній ітерації у відповід- ності до потреб моделювання застосову- ються функції об’єктного аналізу, які на- ближають структуру та властивість ОМ до кінцевих цілей. Кожна з функцій розгляда- ється як послідовність виконання операцій алгебри об’єктного аналізу, чим підтриму- ється цілісність подання ОМ. Процес заве- ршується формалізованим описом сутнос- тей та моделі ПрО з урахуванням кожного аспекту абстрагування та застосування ві- дповідного математичного апарату. Сфор- мовані наступні правили об’єктного ана- лізу: – об’єктний аналіз виконується за умови мінімізації втрати інформації щодо опису дійсної реальності для вибраної предметної області; – всі зміни, які відбуваються з об’єктною моделлю, відповідають проце- сам деталізації опису предметної області та визначаються у рамках подання мно- жини об’єктів як сукупності трикутників Фреге; – кожний крок об’єктного аналізу визначається змінами денотату чи конце- пту одного або кількох об’єктів з об’єктної моделі; – нові об’єкти на певному кроці об’єктного аналізу визначаються відповід- ними змінами у денотатах існуючих об’єктів; – всі зміни, які відбуваються з об’єктною моделлю, відповідають умовам існування та визначення формальних рів- ней абстракції подання об’єктів; – функції об’єктного аналізу визна- чаються перетвореннями у відповідності з допустимими змінами об’єктної моделі та її окремих елементів; – на кожному кроці об’єктного ана- лізу забезпечуються умови цілісності об’єктної моделі. На основі наведених формалізмів запропонована концепція визначення та впорядкування базової термінології для об’єктно-орієнтованого програмування, суть якої полягає у послідовному визна- ченні термінів згідно з побудовою відно- шеннь між поняттями. Так, з узагальнюю- чим рівнем пов’язане визначення лише од- ного основного терміну – об’єкт. Структу- рно-впорядковуючий рівень передбачає визначення таких понять, як клас, екземп- ляр класу, абстрактний клас та ін. З харак- теристичним рівнем пов’язане визначення наступних термінів: властивiсть об'єкта, вiдношення між об'єктами, агрегація; дета- лізація, класифікація, екземпляризацiя, асоціація, характеристика об'єкта тощо. На поведінковому рівні визначаються такі те- рміни: атрибут стану, статичний атрибут стану, динамічний атрибут стану, стан, Інструментальні засоби і середовища програмування 118 простір станів, життєвий цикл об'єкта, ме- тод та ін. [5, 6]. Теоретичні аспекти компонентного проектування Компонентне програмування є різ- новидом композиційного програмування, де роль елемента композиції відіграє про- грамний компонент. Сутність такого про- грамування визначається як процес ство- рення програмних систем з базових об’єктів, цільових програмних компонен- тів та компонентів повторного викорис- тання (ПВК). Згідно з життєвим циклом побудови таких систем та комплексному методу проектування сама система пода- ється як сукупність взаємодіючих об’єктів, компонентів та ПВК у рамках певного компонентного середовища. Відповідно до цього фаза компо- нентного проектування пов’язана з побу- довою компонентного подання програми, що створюється у рамках певної ПрО. Для забезпечення переходу від ОМ до компо- нентного подання встановлено зв’язок між об'єктно-орієнтованим аналізом та компо- нентним проектуванням програмних сис- тем. Для формалізації процесу компонент- ного проектування у роботі пропонується відповідний формальний апарат у складі базової термінології (компонент, каркас, компонентна модель, компонентне середо- вище тощо), моделей основних елементів компонентного програмування, а також зовнішньої та внутрішньої компонентних алгебр. Для встановлення зв’язків між об’єктно-орієнтованим і компонентним проектуванням розглядаються об’єктне та компонентне подання програми [7], які формуються як об’єктна та інтерфейсна моделі. Об’єктна модель має наступний вираз: OSyst = (OClass, G), де OClass = {OClassi} – множина класів, G – об’єктний граф, у якому вершинами є класи, а дуги визначають об’єктні відно- шення. Кожен клас з OClass подається як модель OClassi = (ClassNamei, Methodi, Fieldi}, де ClassNamei – ім’я класу; Methodi = {Methodj i} – множина методів класу; Fieldi = {Fieldn i} – множина змінних, які визна- чають стан екземплярів класу. Нехай PFieldi ⊂ Fieldi – множина зовнішніх змін- них (public) класу. Кожному PFieldn i ∈ PFieldi поставимо у відповідність методи get<PFieldn i> и set<PFieldn i> для доступу та модифікації значень змінних, тобто ці змінні подаються як атрибути. Сформуємо нову множину методів IMethodi = Methodi ∪ {get<PFieldn i>} ∪ ∪ {set<PFieldn i>}. Кожній множині IMethodi ставиться у відповідність певний інтерфейс IFunci, який складається з прототипів методів з IMethodi та реалізація якого забезпечується функціональністю методів класу та його атрибутів. Розглянемо наступну інтерфей- сну модель ISyst = (IFunc, IG) , де IFunc = {IFunci} – множина інтерфейсів, які побудовані для класів з OClass; IG – інтерфейсний граф, що еквівалентний графу G. Тобто IG – граф, у якому верши- нами є інтерфейси, а дуги визначають від- ношення між компонентами відповідно до відношень між їх інтерфейсами. Таким чином, між графами G та IG існує ізоморфне відображення, а функціо- нальність реалізацій для інтерфейсів IFunci еквівалентна функціональності класу OClassi. Для класів з OClass визначаються умови, коли вони дозволяють сформувати їх подання як елементів множини інтер- фейсів в інтерфейсному графі. Введемо наступне визначення. Визначення 1. Декларована в класі змінна називається керованою щодо дос- тупу до її значення з боку інших класів, якщо вона є public-змінна або для неї реа- лізований доступ за допомогою public-ме- тодів класу. Якщо зовнішня взаємодія з класом відбувається лише за допомогою public- методів та керованих змінних, то для нього реалізується інтерфейсний принцип дос- тупу, тотбо не існує інших можливостей зовнішнього доступу до функціональності класу або його змінних. Інструментальні засоби і середовища програмування 119 Цим розглядом доводиться на- ступна теорема. Теорема 2. Для кожної об’єктної моделі OSyst, зовнішня взаємодія з кла- сами якої відбувається на основі public-ме- тодів та керованих змінних, існує єдине інтерфейсне подання ISyst з еквівалентною функціональністю. Необхідно зауважити, що ця тео- рема визначає умови існування єдиного еквівалентного відображення між об’єктним та інтерфейсним поданнями програми. Між об’єктним та компонент- ним поданнями відображення існує, але воно не єдине. Ця неоднозначність поро- джується тим, що певний компонент може мати реалізації для кількох інтерфейсів з ISyst. В частковому випадку, коли кожен з інтерфейсів реалізується у окремому ком- поненті, буде існувати єдине еквівалентне відображення між об’єктним та компонен- тним поданнями. На рис. 2 показано приклад об’єктного та компонентного подання про- грами. Об’єктна модель OSyst складається з чотирьох класів: E1, E2, E3, E4. Для кла- сів E2, E3, E4 сукупності public-методів та керованих змінних означені як вхідні об’єктні інтерфейси IE2, IE3, IE4 відпові- дно. У інтерфейсному поданні ISyst їм від- повідають компонентні інтерфейси IC2, IC3, IC4 (пунктирні лінії). OC11, OC12, OC2, OC3 – вихідні інтерфейси в компоне- нтній моделі. Між об’єктними та компоне- нтними інтерфейсами встановлено одноз- начне відображення, але для об’єктної та компонентної моделі такого відображення не існує, бо компонент Comp3 має два вхі- дних інтерфейси, тобто функціональність класів E3 та E4 реалізована в одному ком- поненті. Наведемо основні визначення та моделі для фази компонентного проекту- вання об’єктно-компонентного методу. Визначення 2. Програмний компо- нент чи просто компонент – це незалеж- ний від мови програмування, самостійно реалізований програмний об'єкт, який за- безпечує виконання певної сукупності прикладних сервісів, доступ до яких мож- ливий тільки за допомогою інтерфейсів, що визначають функціональні можливості компонента і порядок звертання до його операцій. Компонент є відображенням типо- вого рішення щодо певного фрагменту ПрО, має типову архітектуру, структуру, характеристики і атрибути в його інтерфейсній частині для обміну даними в компонентному середовищі. Тобто компо- нент, поданий таким чином, стає неподільним та інкапсульованим програм- ним елементом, який задовольняє функціональним вимогам, а також вимо- гам щодо архітектури системи і компо- нентного середовища. Рис. 2. Об’єктне та компонентне подання програми Comp1 Comp3 Comp2 OC11 OC12 IC2 OC2 IC4 IC3 OC3 E1 E2 E3 E4 IE2 IE3 IE4 Інструментальні засоби і середовища програмування 120 Визначення 3. Компонентна про- грама – це сукупність компонентів, що не- обхідні для забезпечення функціональних та нефункціональних вимог, і яка побудо- вана та функціонує у відповідності до пра- вил створення компонентних конфігурацій і компонентної взаємодії у рамках об’єктних і компонентних моделей. Модель компонента є наслідком узагальнених типових рішень щодо сутно- сті об’єкта, їх архітектури, структури, властивостей, характеристик, що посту- пово переходять або відображаються у компонент. Формально модель компонента має вигляд Comp = (CName, CInt, CFact, CImp, CServ), (3) де CName – унікальне ім'я компонента; CInt = {CInti} – множина інтерфейсів, зв'я- заних з компонентом; CFact – інтерфейс керування екземплярами компонента; CImp = {CImpj} – множина реалізацій компонента; CServ = {CServr} – множина системних сервісів. Множина CInt = CIntI ∪ CIntO складається з вхідних CIntI та вихідних CIntO інтерфейсів. Відмінність між ними полягає у тому, що для вхідних інтерфей- сів компонент має власні реалізації, а для вихідних інтерфейсів реалізації знахо- дяться в інших компонентах. Інтерфейс CFact визначає методи, які необхідні для керування екземплярами компонента (по- шук, створення, знищення, тощо). Модель інтерфейсу має вигляд CInti = ( IntNamei , IntFunci , IntSpeci ), де IntNamei – ім'я інтерфейсу; IntFunci – функціональність (сукупність методів); IntSpeci – специфікація інтерфейсу (опису типів, констант, інших елементів даних, сигнатур методів тощо). Необхідною вимогою існування компонента є умова його цілісності: ∀CInti∈ CIntI ∃CImpj∈ ∈ CImp [Provide(CInti) ⊆CImpj], де Provide(CInti) означає функціональність, що забезпечує реалізацію методів інтер- фейсу CInti. Для взаємодії двох компонен- тів Comp1 та Comp2 існує наступна необ- хідна умова: якщо CInti 1∈CIntO1, то пови- нен існувати CIntk 2∈CIntI2 такий, що: Sign(CInti 1)=Sign(CIntk 2)& & Provide(CInti 1) ⊆CImpj 2, де Sign(…) означає сигнатуру відповідного інтерфейсу. Для компонентної моделі певного типу (CFact та CServ є фіксованими) вве- демо наступні визначення. Визначення 4. Два компоненти Comp1 та Comp2 є тотожніми (рівними), якщо тотожніми є їх відповідні складові. Як наслідок, заміна Comp1 на Comp2 не впливає на компонентну програму, до якої належить Comp1. Визначення 5. Два компоненти Comp1 та Comp2 є еквівалентними, якщо тотожніми є їх множини інтерфейсів та ре- алізацій. Заміна Comp1 на Comp2 не міняє функціональності компонентної програми за умови встановлення відповідності між іменами існуючих та нових компонентів. Визначення 6. Два компоненти Comp1 та Comp2 є подібними, якщо тотож- німи є їх множини інтерфейсів. Заміна Comp1 на Comp2 зберігає взаємозв’язки компонентів, але функціональність компо- нентної програми може змінитись. Основні типи відношень між компонентами. Відношення успадковування двох компонентів визначається встановленням відношення успадковування для їх вхідних інтерфейсів (аналогічно відношенню успа- дковування в об’єктно-орієнтованому про- грамуванні). Відношення екземпляризації. Екзе- мпляти компонента створюються у відпо- відності до його певного вхідного інтер- фейса CIntIi. Вираз CInsk ij = (IInsk ij, In- tFunci, ImpFuncj) описує екземпляр компо- нента Comp, де: IInsk ij – унікальний іден- тифікатор екземпляра, IntFunci – функціо- нальність інтерфейса CIntIi ∈ CInt, Im- pFuncj – програмний елемент, що забезпе- чує виконання реалізації CImpi ∈ CImp. Відношення контракту. Відно- шення контракту між компонентами Comp1 і Comp2 описується виразом: Cont12 im = (CIntO1 i, CIntI2 m, IMap12 im), Інструментальні засоби і середовища програмування 121 де CIntO1 i ∈ CInt1 – вихідний інтерфейс першого компонента, CIntI2 m ∈ CInt2 – вхідний інтерфейс другого компонента; IMap12 im – відображення відповідності між методами, які входять до складу обох інтерфейсів з урахуванням сигнатур та типів даних, що передаються. Відношення контракту існує, якщо компонент Comp2 має реалізацію для інтерфейса CIntI2 m, яка забезпечує виконання функціональності IntFunc1 i інтерфейса CIntO1 i. Відношення зв’язування. Якщо між компонентами Comp1 і Comp2 існує відно- шення контракту Cont12 im, то між їх екзем- плярами CIns1k ij = (IIns1k ij, IntFunci, Im- pFuncj) та CIns2p mq = (IIns2p mq, IntFuncm, ImpFuncq) існує відношення зв’язування щодо контракту Cont12 im, яке описується виразом Bind(IIns1k ij, IIns2p mq, Cont12 im). Модель компонентного середо- вища має вигляд CE = (NameSpace, IntRep, ImpRep, CServ, CServImp), (4) де NameSpace = {CNamem} – множина імен компонентів середовища; IntRep = {IntRepi} – репозитарій інтерфейсів ком- понентів середовища; ImpRep = {ImpRepj} – репозитарій реалізацій; CServ = {CServr} – інтерфейс множини системних сервісів; CServImp = {CServImpr} – множина реалі- зацій для системних сервісів. Компонентне середовище на рівні моделі розглядається як множина серверів застосувань, де розгортаються компоне- нти-контейнери, екземпляри яких забезпе- чують реалізацію функціональності ком- понента. Взаємозв’язок контейнера з сер- вером забезпечується через стандартизо- вані інтерфейси (CFact). Зв’язок між ком- понентами, які розгорнуті у різних серве- рах забезпечується реалізаціями інтерфесу CServ. Визначення 7. Каркасом компоне- нтного середовища називається середо- вище, для якого сукупності імен компоне- нтів, інтерфейсів та реалізацій – суть по- рожні множини, тобто FW = (∅, ∅, ∅, CServ, CServImp). Нехай FW1= (∅, ∅, ∅, CServ1, CServImp1) і FW2 = (∅, ∅, ∅, CServ2, CServImp2) – два каркаси. Визначення 8. Каркас FW1 суміс- ний з каркасом FW2, якщо існує відобра- ження SMap: CServ1 –> CServ2 таке, що SMap(CServ1) ⊆ CServ2. Зовнішня компонентна алгебра. Моделі подання компонентів та компонен- тних середовищ є основою формування зовнішньої компонентної алгебри, яка ви- значає множину операцій над відповід- ними елементами і має такий вираз: Ψ = { CSet, CESet, Ω }, (5) де CSet – множина компонентів, кожен з яких має модель (3); CESet – множина компонентних середовищ, кожне з яких описується виразом (4); Ω – множина опе- рацій. До складу множини Ω входять такі операції (Comp – компонент, CE1, CE2, CE3 – компонентні середовища): – інсталяція (розгортання компоне- нта) CE2 = Comp ⊕ CE1; – об'єднання компонентних середо- вищ CE3 = CE1 ∪ CE2; – видалення компонента з компоне- нтного середовища CE2 = CE1 \ Comp. Для операцій зовнішньої компонен- тної алгебри сформовані та доведені такі теореми. Теорема 3. Кожне компонентне се- редовище CE є результатом виконання по- слідовності операцій розгортання компо- нентів, які входять до його складу, в ком- понентному каркасі: CE = Comp1 ⊕ Comp2 ⊕ . . . ⊕ ⊕ Compn ⊕ FW. Теорема 4. Побудова компонент- ного середовища не залежить від порядка інсталяції компонентів, які входять до складу цього середовища, тобто: Comp1 ⊕ (Comp2 ⊕ CE) = = Comp2 ⊕ (Comp1 ⊕ CE). Теорема 5. Операція об'єднання компонентних середовищ асоціативна: (CE1 ∪ CE2) ∪ CE3 = CE1 ∪ (CE2 ∪ CE3). Інструментальні засоби і середовища програмування 122 Теорема 6. Операція об'єднання компонентних середовищ комутативна: CE1 ∪ CE2 = CE2 ∪ CE1. Теорема 7. Для будь-якого компо- нентного середовища CE ∪ FW = FW ∪ CE = CE. Теорема 8. Для довільних компо- нентних середовищ CE1 і CE2 та компоне- нта Comp завжди виконується: Comp ⊕ (CE1 ∪ CE2) = (Comp ⊕ CE1) ∪ ∪ CE2 = (Comp ⊕ CE2) ∪ CE1. Теорема 9. Для будь-якого компо- нента Comp та компонентного середовища CE завжди виконується: (Comp ⊕ CE) \ Comp = CE. Модель компонентної програми для певного компонентного середовища описується виразом: CP = (CE, Cont, CompO), де CE – компонентне середовище; Cont – множина контрактів для компонентів, що входять до складу CE; CompO – підмно- жина компонентів з CE, що включають ре- алізації, для яких відсутні вхідні інтер- фейси і які звертаються до інших компо- нентів за допомогою своїх вихідних інтер- фейсів. Компоненти з CompO є вхідними, тобто з них починається виконання про- грами. Умова цілісності компонентної програми полягає в існуванні для кожного компонента Comp1 з CE, що має вихідний інтерфейс CIntO1 i, компонента Comp2 з ві- дповідним вхідним інтерфейсом CIntI2 m і контракт Cont12 im = (CIntO1 i, CIntI2 m, IMap12 im) входить до складу множини Cont. Процес побудови компонентної програми включає: розгортання компонен- тів і створення компонентного середо- вища, визначення початкових компонентів та формування множини контрактів згідно з функціональними вимогами до програми. Внутрішня алгебра компонентного програмування складається з операцій пе- ребудови (трансформації) компонентів се- редовищі за допомогою функцій рефакто- рінгу з виконанням умови незмінності ін- терфейсів і компонентної моделі, функцій реінжинірингу з незмінністю компонент- ної моделі та функцій реверсної інженерії (дозволяються довільні трансформації) [8]. На основі семантики, умов та вимог виконання функцій рефакторінгу побудо- вана алгебра рефакторінгу компонентів [9]: ∑ rf = (CSet, Refac), де CSet = {Compn} - множина компонентів; Refac = {AddOImp, AddNImp, ReplImp, AddInt} – сукупність операцій рефакторі- нгу компонентів. Розглянемо операції рефакторінгу. Операція AddOImp – додавання но- вої реалізації для існуючого інтерфейсу: NewComp = AddOImp(OldComp, NewCImps, NewCIntOs) і має семантику: - NewCInt = OldCInt∪NewCIntOs (додаються нові вихідні інтерфейси для нової реалізації); - NewCImp = OldCImp∪ ∪ {NewCImps} (додається нова реалізація); - ∃OldCIntt ∈ OldCIntI [Provide(OldCIntt) ⊆ NewCImps] (для реалі- зації, що додається, існує вхідний інтер- фейс з відповідною функціональністю). Операція є асоціативною та комута- тивною. Умова цілісності компонента збе- рігається. Операція AddNImp – додавання но- вої реалізації, вхідний інтерфейс для якої не входить до складу множини інтерфейсів компонента: NewComp = AddNImp(OldComp, NewCImps,NewCIntOs) і має семантику: - NewCInt = OldCInt∪NewCIntOs (додаються нові вихідні інтерфейси для нової реалізації); - NewCImp = OldCImp ∪ {NewCImps} (додається нова реалізація). Операція є асоціативною та комута- тивною. Умова цілісності компонента збе- рігається. Операція ReplImp – заміщення іс- нуючої реалізації новою без зміни вхід- ного інтерфейсу: Інструментальні засоби і середовища програмування 123 NewComp=ReplImp(OldComp,NewCImps, NewCIntOs,OldCImpr,OldCIntOr) і має семантику: - NewCInt=OldCInt ∪ {NewCIntOs}\ \{OldCIntOr} (додаються вихідні інтер- фейси для нової реалізації і видаляються вихідні інтерфейси старої реалізації); - NewImp = OldImpl ∪ {NewCImps}\ \{OldCImpr} (додається нова реалізація і видаляється стара). Умовою виконання операції є не- змінність функціональності усіх інтерфей- сів, що пов’язані зі старою реалізацією, після заміщення її новою: ∀OldCIntt∈OldCIntI [(Provide(OldCIntt)⊆OldCImpr)=> (Provide(OldCIntt)⊆NewCImps)] ∨ ∃OldCImpj∈(OldCImp\{OldCImpr}) [Provide(OldCIntt) ⊆OldCImpj]. Лема 1. Операція заміщення існую- чої реалізації новою з вищевизначеними умовою та семантикою зберігає цілісність компонента. Операція AddInt – додавання но- вого вхідного інтерфейсу для існуючої ре- алізації: NewComp = AddInt(OldComp, NewCIntIq) і має семантику: - NewCInt = OldCInt ∪ {NewCIntIq} (додається новий вхідний інтерфейс); - ∃OldCImps∈ OldCImp [Provide(NewCIntIq)⊆OldCImps] (для но- вого інтерфейса існує реалізація з відпові- дною функціональністю). Лема 2. Операція додаванням но- вого вхідного інтерфейсу для існуючої ре- алізації з вище визначеними умовою та се- мантикою зберігає цілісність компонента. Наведені операції є базовими для більш складних. Наприклад, додавання ре- алізації разом з новим вхідним інтерфей- сом визначаються наступною суперпози- цією операцій рефакторингу: NewComp = = AddInt(AddNImp(OldComp,NewCImps, NewCIntOs), NewCIntIq). Розгляд семантики операцій та умов виконання доводить наступну теорему. Теорема 10. Алгебра рефакторингу компонентів ∑rf = (CSet, Refac) є повною та незаперечною. Зв’язок зовнішньої та внутріш- ньої компонентних алгебр. Згідно з тео- ремою 10 результатом операцій рефакто- рингу або суперпозицій операцій є певний компонент Це свідчить про можливість зв’язку зовнішньої компонентної алгебри з алгеброю рефакторингу. Множина CSet складається з компонентів репозитарію і різних модифікацій компонентів як ре- зультатів виконання операцій рефактори- нгу, тобто у операціях зовнішньої компо- нентної алгебри замість компонентів мо- жуть застосовуватись їх модифікації. На- приклад, для певної компонентної моделі компонентна конфігурація, яка склада- ється з двох компонентів і для другого компонента додаються реалізація та вхід- ний інтерфейс, описується таким виразом: CE = Comp1⊕ ⊕ AddInt(AddNImp(Comp2, NewCImps, NewCIntOs), NewCIntIq) ⊕ FW. Моделі реінжинірингу та реверс- ної інженерії. Внутрішня компонентна ал- гебра реінжинірингу компонентів ∑re = (CSet, Reeng) може бути побудована лише за умови порушення цілісності подання компонентів. Крім операцій рефакторингу (Refac) до множини Reeng входять опера- ції, які видаляють з компонента існуючий інтерфейс або змінюють його сигнатуру. Це порушує умову цілісності, бо інші ком- поненти, які звертаються до нього, не зможуть мати доступу до необхідної фун- кціональності. Виходячи з таких умов, до- цільно замість алгебри реінжинірингу до складу формальних методів компонент- ного програмування включити модель реі- нжинірингу. Модель реінжинірингу компонентів має вигляд МReeng = (CSet, Reeng). Семан- тика операцій з Reeng може полягати у од- ночасній трансформації не тільки цільо- вого компонента, а й інших. Наприклад, Інструментальні засоби і середовища програмування 124 при зміні сигнатури вхідного інтерфейсу необхідна одночасна зміна інших компо- нентів, в яких існують звернення до мето- дів цього інтерфейсу. Аналогічним чином, формується ві- дповідна модель реверсної інженерії МRevers = (CSet, Revers), при цьому Reeng ⊂ Revers. Особливість множини Revers по- лягає у тому, що вона не визначена повні- стю (кількість операцій є необмеженою), а дозволяє лише класифікацію операцій. На- приклад, зміни якісних характеристик компонентів можуть виконуватись довіль- ним способом і відповідні операції скла- дають сукупність операцій для зміни пев- ного показника якості (сам показник є кла- сифікаційною ознакою у системі класифі- кації множини Revers). Таким чином, алгебра Σrf та моделі МReeng і МRevers складають формальний апа- рат аналізу внутрішніх методів еволюції компонентів. Висновок У роботі запропоновано комплекс- ний метод аналізу і проектування компо- нентних програмних систем. Цей метод заснований на концепції двохфазового аналізу та проектування відповідно до го- ловних завдань, що виникають на початко- вих етапах життєвого циклу компонентних систем. Завдання першої фази полягає в аналізі предметної області з метою побу- дови моделі, яка адекватно відображає структуру ПрО, її об’єкти та відношення між ними тощо. Головне завдання другої – проектування конкретних компонентів та компонентних систем за результатами аналізу ПрО. Метод узагальнює поняття об’єктів, як елементів дійсної реальності шляхом концептуального моделювання та об’єктно-орієнтованого аналізу предметної області із застосуванням математичних формалізмів на різних рівнях подання об’єктів та об’єктної моделі в цілому, а та- кож послідовно визначає кроки у проекту- ванні об’єктів, починаючи з їх розгляду як окремих сутностей ПрО і закінчуючи пов- ним поданням з урахуванням характерис- тик і поведінки. На основі результатів аналізу предметної області будується ві- дображення ОМ у компонентні моделі шляхом формування функціональних інте- рфейсів та розподілом їх між конкретними компонентами. Наведені визначення по- нять об’єкта та компонента, сформовані компонентні моделі, побудована алгебра об’єктного аналізу, а також зовнішня і внутрішня компонентні алгебри складають теорію методу об’єктно-компонентного аналізу та проектування програмних сис- тем. 1. Грищенко В.Н., Лаврищева Е.М. Методы и средства компонентного программирова- ния // Кибернетика и системный анализ.– 2003.– № 1.– С. 39–55. 2. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложе- ний на С++. - М.: "Издательство Бином", СПб.: "Невский диалект", 2001. – 560 с. 3. Мейер Б. Объектно-ориентированное конструирование программных систем. – “Русская Редакция”, 2005. – 1232 с. 4. Фреге Г. Логика и логическая семантика. – М.: Аспект-пресс, 2000. – 512 с. 5. Грищенко В.Н. Подход к формализации объектно-ориентированной методологии // Проблемы программирования. – 1997. – № 1.– С. 33–39. 6. Грищенко В.М. Підхід до аналізу поведінки об`єктних систем при моделюванні пред- метних областей // Проблеми програму- вання. – 1998. – № 4. – С. 67–75. 7. Грищенко В.Н. Формальные модели компонентного программирования // Про- блемы программирования. – 2003. – № 2.– С. 42–57. 8. Грищенко В.Н. Методи еволюції програм- них компонентів для їх повторного засто- сування// Проблеми програмування. – 2004. – № 2–3. – С. 215–222. 9. Грищенко В.Н. Алгебраїчна модель рефакторінгу компонентів // Проблеми програмування. – 2003. – № 4.– С. 43–53. Отримано 19.04.2007 Інструментальні засоби і середовища програмування 125 Про автора: Грищенко Володимир Миколайович, кандидат фізико-математичних наук. Місце роботи автора: Інститут програмних систем НАН України, 03187, Київ-187, проспект Академіка Глушкова, 40. Тел. (044) 522 4656.
id	nasplib_isofts_kiev_ua-123456789-292
institution	Digital Library of Periodicals of National Academy of Sciences of Ukraine
issn	1727-4907
language	Ukrainian
last_indexed	2025-11-27T08:59:43Z
publishDate	2007
publisher	Інститут програмних систем НАН України
record_format	dspace
spelling	Грищенко, В.М. 2008-02-22T18:57:55Z 2008-02-22T18:57:55Z 2007 Метод об'єктно-компонентного проектування програмних систем / В.М. Грищенко // Пробл. програмув. — 2007. — N 2. — С. 113-125. — Бібліогр.: 9 назв. — укp. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/292 Запропоновано комплексний метод проектування компонентних програмних систем, який засновано на концепції двофазового аналізу та проектування. Завдання першої фази полягає в аналізі предметної області (ПрО) з метою побудови моделі, яка адекватно відображає структуру ПрО та її властивості. До складу задач другої фази входить проектування конкретних компонентів і компонентних систем на базі результатів аналізу ПрО. Наведено необхідну термінологію, формальні моделі, математичний апарат, які визначають концепції та зміст запропонованого методу. uk Інститут програмних систем НАН України Інструментальні засоби і середовища програмування Метод об'єктно-компонентного проектування програмних систем Article published earlier
spellingShingle	Метод об'єктно-компонентного проектування програмних систем Грищенко, В.М. Інструментальні засоби і середовища програмування
title	Метод об'єктно-компонентного проектування програмних систем
title_full	Метод об'єктно-компонентного проектування програмних систем
title_fullStr	Метод об'єктно-компонентного проектування програмних систем
title_full_unstemmed	Метод об'єктно-компонентного проектування програмних систем
title_short	Метод об'єктно-компонентного проектування програмних систем
title_sort	метод об'єктно-компонентного проектування програмних систем
topic	Інструментальні засоби і середовища програмування
topic_facet	Інструментальні засоби і середовища програмування
url	https://nasplib.isofts.kiev.ua/handle/123456789/292
work_keys_str_mv	AT griŝenkovm metodobêktnokomponentnogoproektuvannâprogramnihsistem

Метод об'єктно-компонентного проектування програмних систем

Репозитарії

Схожі ресурси