Алгебраїчна модель рефакторінгу компонентів

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

Повний опис

Збережено в:

Бібліографічні деталі
Дата:	2003
Автор:	Грищенко, В.М.
Формат:	Стаття
Мова:	Ukrainian
Опубліковано:	Інститут програмних систем НАН України 2003
Теми:	Методы и средства программной инженерии
Онлайн доступ:	http://dspace.nbuv.gov.ua/handle/123456789/1361
Теги:	Додати тег Немає тегів, Будьте першим, хто поставить тег для цього запису!
Назва журналу:	Digital Library of Periodicals of National Academy of Sciences of Ukraine
Цитувати:	Алгебраїчна модель рефакторінгу компонентів / В.М. Грищенко // Проблеми програмування. — 2003. — N 4. — С. 43—53. — Бібліогр.: 12 назв. — укр.

Репозитарії

Digital Library of Periodicals of National Academy of Sciences of Ukraine

id	irk-123456789-1361
record_format	dspace
spelling	irk-123456789-13612008-07-30T12:00:32Z Алгебраїчна модель рефакторінгу компонентів Грищенко, В.М. Методы и средства программной инженерии Наведено алгебраїчний підхід до формалізації рефакторінгу компонентів. На базі моделі компонента разглянуті методи рефакторінгу, припустимі операції та умови цілісності компонентів. Визначені концепції побудови алгебраїчної моделі рефакторінгу компонентів та описана внутрішня компонентна алгебра. Приведен алгебраический подход к формализации рефакторинга компонентов. На базе модели компонента рассмотрены методы рефакторинга, допустимые операции и условия целостности компонентов. Определены концепции построения алгебраической модели рефакторинга компонентов и описана внутренняя компонентная алгебра. The algebraic approach to formalization of component refactoring is described. On the base of component model the methods of refactoring, possible operations and integrity conditions of components are cosidered. The concepts for building of algebraic model of component refactoring are defined and internal component algebra is described. 2003 Article Алгебраїчна модель рефакторінгу компонентів / В.М. Грищенко // Проблеми програмування. — 2003. — N 4. — С. 43—53. — Бібліогр.: 12 назв. — укр. 1727-4907 http://dspace.nbuv.gov.ua/handle/123456789/1361 681.03 uk Інститут програмних систем НАН України
institution	Digital Library of Periodicals of National Academy of Sciences of Ukraine
collection	DSpace DC
language	Ukrainian
topic	Методы и средства программной инженерии Методы и средства программной инженерии
spellingShingle	Методы и средства программной инженерии Методы и средства программной инженерии Грищенко, В.М. Алгебраїчна модель рефакторінгу компонентів
description	Наведено алгебраїчний підхід до формалізації рефакторінгу компонентів. На базі моделі компонента разглянуті методи рефакторінгу, припустимі операції та умови цілісності компонентів. Визначені концепції побудови алгебраїчної моделі рефакторінгу компонентів та описана внутрішня компонентна алгебра.
format	Article
author	Грищенко, В.М.
author_facet	Грищенко, В.М.
author_sort	Грищенко, В.М.
title	Алгебраїчна модель рефакторінгу компонентів
title_short	Алгебраїчна модель рефакторінгу компонентів
title_full	Алгебраїчна модель рефакторінгу компонентів
title_fullStr	Алгебраїчна модель рефакторінгу компонентів
title_full_unstemmed	Алгебраїчна модель рефакторінгу компонентів
title_sort	алгебраїчна модель рефакторінгу компонентів
publisher	Інститут програмних систем НАН України
publishDate	2003
topic_facet	Методы и средства программной инженерии
url	http://dspace.nbuv.gov.ua/handle/123456789/1361
citation_txt	Алгебраїчна модель рефакторінгу компонентів / В.М. Грищенко // Проблеми програмування. — 2003. — N 4. — С. 43—53. — Бібліогр.: 12 назв. — укр.
work_keys_str_mv	AT griŝenkovm algebraíčnamodelʹrefaktoríngukomponentív
first_indexed	2025-07-02T04:50:30Z
last_indexed	2025-07-02T04:50:30Z
_version_	1836509383089979392
fulltext	Методы и средства программной инженерии © В.М. Грищенко, 2003 ISSN 1727-4907. Проблемы программирования. 2003. № 4 43 УДК 681.03 В.М. Грищенко АЛГЕБРАЇЧНА МОДЕЛЬ РЕФАКТОРІНГУ КОМПОНЕНТІВ Наведено алгебраїчний підхід до формалізації рефакторінгу компонентів. На базі моделі компонента разглянуті методи рефакторінгу, припустимі операції та умови ці- лісності компонентів. Визначені концепції побудови алгебраїчної моделі рефакторінгу компонентів та описана внутрішня компонентна алгебра. Вступ Формальні, у тому числі й алгеб- раїчні, методи широко застосовуються в сучасних дослідженнях із проблем компонентного програмування. Як від- значено в [1], компонентний підхід – це нова реалізація концептуальної ідеї композиційного програмування на су- часному етапі і тому значний обсяг те- оретичних результатів із проблем ком- позиції став основою для побудови тео- рії компонентного програмування. Серед таких результатів можна ви- ділити наступні класи моделей, методів, підходів, що призначені для аналізу різ- них аспектів компонентної теорії [1, 2]: — мови і моделі опису інтер- фейсів; — мови опису взаємодії модулів та об’єктів; — шаблони проектування; — мови опису компонентних ар- хітектур; — компонентні моделі. Їх особливість полягає у тому, що вони орієнтовані на розгляд компонен- та як цільного, формально поданого об’єкта, що має визначені характерис- тики і типову структуру. Це відобра- жає ідеалізовану точку зору у компо- нентному програмуванні, суть якої по- лягає в тому, що компоненти є базови- ми елементами (блоками, модулями і т.д.), на основі яких будується компо- нентна програма. При цьому такі еле- менти мають атомарну структуру і ціл- ком визначені і наперед задані власти- вості та характеристики. Практика компонентного про- грамування показала, що така точка зо- ру дуже обмежена й у багатьох випад- ках базові компоненти піддаються де- якій попередній обробці – зміні ін- терфейсів і деяких аспектів реалізації, зміні параметрів конфігурації і розгор- тання (процедури інсталяції та прив’яз- ки компонента до середовища) і т.д. При цьому отримані об'єкти розгляда- ються у якості нових компонентів, які входять до складу компонентних про- грам. Проте операції над базовими компонентами носять не довільний ха- рактер, а задовольняють визначеним правилам та умовам. Суть їх полягає у тому, що отриманий у результаті вико- нання певної операції об'єкт теж пови- нен бути компонентом із усіма необ- хідними атрибутами і властивостями. Це викликано існуванням умов, що на- кладаються компонентними моделями та правилами побудови компонентних структур і програм у сучасних середо- вищах. Таким чином, поступово форму- ється окрема галузь досліджень у ком- понентному програмуванні – рефак- торінг компонентів, що включає сукуп- ність моделей, методів і засобів пере- творення, а також зміни структурних і якісних характеристик базових об’єк- тів для одержання нових компонентів, найбільш придатних для побудови ці- льової компонентної програми. У цій статті мова йде про форма- льне подання методів рефакторінгу ком- понентів, кінцева мета якого складаєть- ся у побудові відповідної алгебраїчної моделі або внутрішньої алгебри компо- нентів (зовнішні компонентні алгебри, як було відзначено вище, розглядають компоненти як цільні об’єкти компо- нентних конфігурацій і структур [3]). Визначення базових понять і термінів Базова термінологія для компо- нентного програмування і компонент- них програм, що концептуально зв'яза- Методы и средства программной инженерии 44 на з даною роботою, наведена у [3]. Основні терміни для визначення компо- нента, його властивостей, характерис- тик, структури приведені у багатьох пу- блікаціях, наприклад у [4, 5]. Введемо основні поняття і терміни, безпосеред- ньо пов'язані з рефакторінгом компонен- тів. До них, зокрема, відносяться понят- тя компонента і саме рефакторінгу. Програмний компонент чи прос- то компонент – це незалежний від мови програмування, самостійно реалі- зований програмний об'єкт, що забез- печує виконання певної множини про- грамних сервісів і поданий як взаємо- замінний контейнер, доступ до якого можливий тільки за допомогою інтер- фейсів, що визначають його функціо- нальні можливості і порядок звертання до його операцій. Як вже відзначалося вище, у компонентному програмуванні компо- нент є неподільною і інкапсульованою сутністю, що задовольняє визначеним функціональним вимогам, а також вимогам архітектури, структури й ор- ганізації взаємодії в компонентній програмі. Рефакторінг – це сукупність моделей, методів, процесів, які засто- совуються до визначених класів об'єк- тів з метою одержання нових або змі- ни існуючих структурних і функціона- льних показників об'єктів, що забезпе- чує їм нові якісні характеристики та поведінку. Найбільший розвиток напрямок рефакторінгу здобув у об’єктно-орієн- тованому програмуванні [6], зокрема, у зв'язку із застосуванням шаблонів про- ектування [7] та іншими методами по- ліпшення коду і структури об’єктно- орієнтованих програм. Розроблено ці- лі бібліотеки типових трансформацій об'єктів (класів), що поліпшують ті чи інші характеристики [6]. На противагу цьому рефакторінг компонентів – порівняно нова галузь дослідження і говорити про значні ре- зультати в ній поки що рано. Найбільш часто зустрічаються публікації з прак- тичної тематики, наприклад практичні методики змін характеристик компо- нентів у рамках конкретних компонент- них моделей. Почасти це викликано тим, що компоненти, як структурні утворення, значно складніше і багато- гранніші, ніж об'єкти і класи в об’єктно-орієнтованому програмуванні. Тому рефакторінг компонентів як са- мостійний напрямок досліджень знахо- диться ще в стадії становлення. Рефакторінг компонента – це процес зміни існуючого компонента з метою надання йому нових функціо- нальних і структурних характеристик, що найбільш повно задовольняють ви- могам компонентної конфігурації, до складу якої шуканий компонент пови- нен увійти. Фактично це означає таку зміну існуючого компонента, за якої він найбільше повно відповідає резуль- татам проектування компонентної про- грами. Метод рефакторінгу компонен- та – це цільовий спосіб одержання нового компонента на базі існуючого, що визначає операції модифікації (змі- ни, заміщення, розширення) елементів, які входять до його складу. Кожен ме- тод характеризується метою (яким ви- могам повинен задовольняти отрима- ний компонент) і можливими послідов- ностями операцій перетворення скла- дових компонента. Операція рефакторінгу – базо- ва, атомарна функція перетворення, що зберігає цілісність компонента. Цілісність компонента – сукуп- ність правил, обмежень і залежностей між його складовими елементами, що дозволяє розглядати компонент як єдину й цільну структуру з властивос- тями та характеристиками, які відпові- дають визначенню класу компонентів для компонентного програмування. Наведені вище визначення є базо- вими для формального подання рефакто- рінгу компонентів. Визначення допоміж- них термінів і понять буде вводитись у процесі подання матеріалу відповідно до контексту викладу. Модель компонента Під моделлю компонента розумі- ється абстрактне подання, що відобра- Методы и средства программной инженерии 45 жає його основні властивості, харак- теристики, типову структуру, а також здатність до взаємодії з іншими еле- ментами компонентного середовища. За основу узятий опис та подання мо- делі з [3]. Модель довільного компонента у загальному випадку представляється наступною сукупністю: Comp = (CName, CInt, CFact, CImp, CServ), (1) де CName – унікальне ім'я компонен- та; CInt = {CInti} – множина інтер- фейсів, пов'язаних з компонентом; CFact – інтерфейс керування екземплярами компонента; CImp = {CImpj} – множина реа- лізацій компонента; CServ = {CServr} – інтерфейс, що визначає множину системних сервісів, які необхідні для підтримки функціо- нування компонента і взаємодії з ком- понентним середовищем. Ім'я компонента унікальне у будь-якому просторі імен для компо- нентного середовища. Для вирішення можливих колізій застосовується метод кваліфікованих імен. Фактично це означає, що кожне ім'я входить у де- який окремий простір імен, сукупність яких визначає простір імен компонент- ного середовища. Керування такими просторами забезпечується спеціаль- ними алгоритмами побудови просторів імен у вигляді ієрархічного дерева, де кожна вершина однозначно визнача- ється маршрутом (послідовністю вер- шин) від кореня дерева. Множина CInt = CIntI ∪ CIntO складається з інтерфейсів двох типів. До першого типу (множина CIntI) від- носяться інтерфейси, які реалізуються в середовищі цього компонента, тобто мають відповідні реалізації методів. До другого типу (множина CIntO) відно- сяться інтерфейси, реалізовані в інших компонентах, але функціональність яких потрібна для виконання методів цього компонента. Кожен інтерфейс компонента по- даний у такому вигляді: CInti = (IntNamei , IntFunci , IntSpeci), (2) де IntNamei – ім'я інтерфейсу; IntFunci – функціональність, яку визначає цей інтерфейс (сукупність методів); IntSpeci – специфікація інтер- фейса (описи типів даних, констант, інших елементів даних, сигнатур мето- дів і т.д.). Provide(CInti) позначається реалі- зація методів, визначених інтерфей- сом CInti, яка надається деякою ком- понентною реалізацією (програмний елемент, що безпосередньо забезпечує виконання методів інтерфейсів). Функ- ціональне позначення для цієї залеж- ності обрано у зв'язку з тим, що в компонентному програмуванні інтер- фейс компонента може визначатись окремо від його реалізації. Тобто на певних етапах розробки (проектуван- ня) компонентної програми для обра- них інтерфейсів застосовуються існу- ючі компоненти, які надають свої функціональні сервіси для реалізації цього інтерфейса [8]. Інтерфейс CFact визначає мето- ди, необхідні для керування екземпля- рами компонента. Зокрема, до них відносяться: — пошук та визначення місця знаходження необхідного екземпляра компонента Locate; — створення нового екземпляра компонента Create; — завершення функціонування та видалення екземпляра компонента Remove. Ці методи складають основу для будь-яких інтерфейсів керування екзем- плярами у рамках будь-яких компонен- тних моделей. Тому в найбільш загаль- ному випадку маємо CFact = {Locate, Create, Remove}. (3) Кожна реалізація компонента описується наступним чином: CImpj = (ImpNamej, ImpFuncj, ImpSpecj), (4) де ImpNamej – ідентифікатор чи ім'я реалізації компонента; Методы и средства программной инженерии 46 ImpFuncj – функціональність, задіяна даною реалізацією (сукупність реалізацій методів); ImpSpecj – специфікація реаліза- ції (опис умов виконання, опис пара- метрів настроювання реалізації і т.д.). Реалізація являє собою сукуп- ність методів визначеної сигнатури і типів даних для вхідних та вихідних параметрів. Відповідно до цих сигнатур і типів даних відбувається процес зі- ставлення реалізацій і інтерфейсів, що містять опис методів, які входять до їх складу. Цей процес називається проце- сом зв'язування. На відміну від об’єктно-орієнтованого й інших підходів до програмування зв'язування в ком- понентному програмуванні виконуєть- ся на більш пізніших стадіях, тобто на заключних етапах побудови компонент- ної програми, а іноді й під час вико- нання, як, наприклад, для динамічних інтерфейсів CORBA [9]. Множину системних сервісів CServ = {CServr} складають сервіси, необхідні для організації побудови та функціонування компонентних сере- довищ, а також керування компонент- ними конфігураціями. Зокрема, міні- мально необхідний набір сервісів включає: 1. Сервіс найменування Naming. Забезпечує можливість пошуку компо- нентів у розподіленому середовищі відповідно до визначених просторів імен та їх місця знаходження. 2. Сервіс зв'язування Binding. Необхідний для визначення (зв'язуван- ня) відповідності “ім'я—об'єкт” і засто- совується до компонентів, знайдених у компонентному середовищі. 3. Сервіс транзакцій Transaction. Забезпечує організацію і керування функціонуванням сукупності компонен- тів, що розглядається як окрема тран- закція. 4. Сервіс повідомлень Messaging. Необхідний для організації спілкуван- ня між компонентами і є складовим елементом у моделі асинхронних тран- закцій. У реальних компонентних сере- довищах можуть бути реалізовані й інші системні сервіси, наприклад керу- вання подіями, служба каталогів тощо. Але часто такі сервіси визначаються умовами спрощення організації компо- нентних середовищ і можуть бути утворені на базі інших сервісів. Надалі будемо вважати, що перераховані ви- ще чотири сервіси є обов'язковими для будь-якої компонентної моделі і її реа- лізації. Вони відображають реалізацію базових функцій керування компонент- ними середовищами: — пошук компонентів; — доступ до їх ресурсів; — організація обміну інформа- цією між компонентами; — керування функціонуванням динамічно визначеної сукупності компонентів. Необхідною вимогою щодо при- пустимого подання компонента є умова цілісності: (∀CInti ∈CIntI) (∃CImpj ∈ CImp) Provide(CInti) ⊆ CImpj . (5) Слід уточнити наявність знака включення в даній формулі. Це озна- чає, що обрана реалізація може забез- печити підтримку не тільки необхідно- го інтерфейсу, але й інших. Практичні технології і мови програмування (CORBA, Java, C++ і ін.) дозволяють створювати такі реалізації та містять для цього необхідні засоби. Також від- значимо, що для кожного з таких ін- терфейсів може існувати кілька реалі- зацій, які відрізняються особливостями функціонування (наприклад, операцій- ним середовищем, засобами збережен- ня даних тощо). Загальна класифікація методів рефакторінгу у компонентному програмуванні Для проведення класифікації пев- ної множині об'єктів можуть бути об- рані різні класифікаційні ознаки, які відображають різні аспекти і точки зо- ру на множину, що піддається класи- фікації. Для компонентного програму- вання існують дві наперед визначені класифікації методів рефакторінгу. Методы и средства программной инженерии 47 1. Відповідно до життєвого ци- клу у компонентному програмуванні (рефакторінг у більш широкому ро- зумінні). У [3] наводиться загальна характеристика життєвого циклу для компонентного програмування з опи- сом окремих етапів і об'єктів компо- нентного середовища. Рефакторінг у такому контексті означає, що для за- стосування деякого компонента більш доцільним може бути шлях зміни елементів середовища, ніж модифіка- ція самого компонента. Наприклад, більш простим методом може бути включення нового сервера для обра- ного компонента з наступною інте- грацією до складу середовища, ніж його переробка під існуючі сервери. Ця класифікація визначає методи, які пов'язані: — зі зміною серверної складової компонентного середовища (додавання нового сервера, заміна існуючого, змі- на параметрів конфігурації і т.д.); — зі зміною контейнерної скла- дової компонентного середовища (до- давання нового контейнера, заміна іс- нуючого, зміна параметрів конфігура- ції, розміщення в різних серверах з різними конфігураціями і т.д.); — з рефакторінгом компонента (зміна інтерфейсів, реалізацій і т.д.); — з процесом настроювання компонентів на параметри компонент- ного середовища (розгортання, зміна параметрів конфігурації); — з процесом настроювання клієнтської частини для взаємодії з компонентами (заміна клієнтської час- тини, зміна протоколу взаємодії з ком- понентом і т.д.); — з керуванням компонентним середовищем і компонентними конфі- гураціями (зміна складу чи конфігура- ції середовища залежно від сумісності та можливостей спільного функціону- вання окремих компонентів). 2. Класифікація, що безпосере- дньо пов’язана з рефакторінгом ком- понентів, базується на типовій струк- турі та моделі компонента, яка подана вище, і поділяється: — на рефакторінг інтерфейсів (додавання, розширення і т.д.) або реа- лізацій (додавання, розширення і т.д.); — зміну інтерфейса керування екземплярами компонентів (додавання нових функцій) або системними серві- сами (додавання нових функцій). Надалі під методами рефакторін- гу будуть розумітися тільки методи з другої класифікації. Припустимі операції рефакторінгу компонентів Не всі операції над компонента- ми припустимі у процесі формалізації моделі рефакторінгу. Серед множини операцій необхідно виділити тільки ті, які задовольняють наступним умовам: — об'єкт, отриманий у результа- ті рефакторінгу, повинен бути компо- нентом, тобто мати властивості, харак- теристики, а також типову структуру, що є основою визначення множини компонентів; — у процесі рефакторінгу ком- понент не повинен утрачати свою функ- ціональність, тобто зберігати можли- вість застосування в раніше побудова- них компонентних конфігураціях і програмах; — компонент, отриманий у ре- зультаті рефакторінгу, повинен відпо- відати вимогам і обмеженням компо- нентної моделі, у якій застосовувався базовий компонент. З приведених умов випливають наступні висновки: — операції видалення складових елементів компонента неприпустимі; — операції зміни складових еле- ментів компонента припустимі за умови збереження існуючої функціо- нальності і порядку звертання до неї; — компонент, отриманий у ре- зультаті рефакторінга, повинен засто- совуватись у тій ж компонентній моде- лі, що й базовий. Існує досить складна і важлива проблема, пов'язана з іменуванням і ідентифікацією нових компонентів. Методи рефакторінгу можуть бути різ- ними, і, відповідно до визначення, нові компоненти повинні однозначно іден- тифікуватися. З огляду на те, що таких Методы и средства программной инженерии 48 компонентів може бути декілька, необ- хідно визначити правила іменування нових компонентів і дисципліну їхньо- го застосування в компонентних кон- фігураціях (як нових, так і існуючих). Розв’язок цієї проблеми торкається за- дачі керування компонентними конфі- гураціями, яка вирішується на основі використання зовнішньої компонентної алгебри [3]. З метою спрощення викла- ду у цій статті для визначеності при- ймається обмеження (яке не впливає на сутність викладених результатів), що в результаті застосування операцій рефакторінгу отримується компонент з іншим ім'ям. На основі наведеного вище ви- значаються наступні припустимі опе- рації рефакторінгу компонентів: — додавання нової реалізації для існуючого інтерфейсу; — додавання нової реалізації для нового інтерфейсу; — розширення існуючої реалі- зації; — заміна існуючої реалізації новою з еквівалентною функціональністю; — додавання нового інтерфейсу (за умови наявності відповідної реалі- зації); — розширення існуючого ін- терфейсу (за умови наявності відповід- ної реалізації); — розширення інтерфейсу CFact (за умови існуванні реалізації для но- вих методів керування екземплярами компонентів); — розширення інтерфейсу CServ (за умови існуванні реалізації для но- вих системних сервісів у компонент- ному середовищі). Основні концепції внутрішньої компонентної алгебри Концептуальну основу внутріш- ньої компонентної алгебри складають: 1. Модель компонента, що ви- значається виразом (1) і є формальною основою алгебри. Сутність даної кон- цепції зводиться до наступних аксіом: — операції алгебри визначають- ся на елементах цієї моделі і тільки на них; — у результаті застосування опе- рацій алгебри завжди виконуються не- обхідні умови цілісності компонента (5). Фактично це означає, що складо- ві моделі (1) визначають основу мно- жини елементів для алгебри, а умова (5) – частковий характер окремих опе- рацій над цією множиною. 2. Операції внутрішньої компо- нентної алгебри є формалізацією мето- дів та операцій рефакторінгу компонен- тів на певному рівні абстракції без урахування аспектів реалізацій цих ме- тодів і їхньої специфіки в алгебрі. Зок- рема, це стосується умови цілісності компонентів. При побудові алгебри важливою є умова самої цілісності, а не методи її встановлення. 3. Розглядаються тільки ті опе- рації, котрі пов'язані з припустимими методами рефакторінгу. При цьому обов'язковою умовою є забезпечення цілісності компонента. 4. Структура і визначення вну- трішньої компонентної алгебри узго- джена з іншими формальними моделя- ми компонентного програмування. Суть концепції складається у побудові єдиного формального апарата компо- нентної теорії. Зокрема, у [3] описуєть- ся зовнішня компонентна алгебра, що складає основу формального апарата для компонентних конфігурацій, сере- довищ і програм. Внутрішня компонен- тна алгебра узгоджена з нею на кон- цептуальному та модельному рівнях. Структура внутрішньої компонентної алгебри Розглянемо важливе зауваження щодо внутрішньої структури компо- нента. Сучасні мови і моделі для практичного застосування компонент- ного підходу (наприклад, Java [10, 11], CORBA [11, 12]), як правило, вимага- ють, щоб кожна реалізація явно вказу- вала інтерфейс, для якого вона створе- на. Необхідність такої схеми обумов- лена, в основному, практичними роз- рахунками – перевірка сигнатур мето- дів і відповідності типів даних, підтрим- ка моделі безпеки щодо виключення можливих побічних ефектів і т.д. Теоретично не існує принципових об- Методы и средства программной инженерии 49 межень, які заважали б встановлювати відповідність між інтерфейсом і реалі- зацією динамічно (деякі моделі, напри- клад CORBA, підтримують концепцію динамічних інтерфейсів, але вона не- достатньо формалізована). Більш того, довільна сукупність методів реалізації формально може визначити деякий ін- терфейс, якщо йому надати унікальне ім'я. Це зауваження показує, що в найбільш загальному випадку компо- нент може містити реалізації з біль- шою функціональністю, ніж того вима- гають явно визначені та описані ін- терфейси. А це, у свою чергу, означає, що реалізації компонента можуть но- сити надлишковий характер, тобто до нього може додаватися нова функціо- нальність з наступним визначенням для неї інтерфейсу. Зворотне зауваження не вірне. Якщо до компонента додаєть- ся новий інтерфейс, то для нього обо- в'язково повинна існувати реалізація. У цьому й полягає один з наслідків об- меження цілісності (5). Серед множини компонентів іс- нує особливий компонент, для якого CInt = ∅ і CImp = ∅, тобто множини ін- терфейсів і реалізацій порожні. Назве- мо його нульовим компонентом, або шаблоном компонента, і позначимо TComp = (Template, ∅, CFact, ∅, CServ). (6) Умова цілісності компонента (5) для шаблона виконується. Множина вхідних інтерфейсів є порожньою і не- залежно від наявності чи відсутності реалізацій вираження (5) має істинне значення. Варто відзначити, що подання цього компонента фактично є основою засобів автоматизації створення ком- понентів, при застосуванні яких роз- робник може зосередитися на інтер- фейсах і функціональності майбутньо- го компонента, а функції керування екземплярами, взаємодії із системними сервісами, оформлення компонента як цілісної структури включаються авто- матично за допомогою інструменталь- них засобів. Нехай OldComp визначає базо- вий компонент до застосування опера- цій, а NewComp відповідає отриманому компоненту після виконання операцій і OldComp = (OldCName, OldCInt, CFact, OldCImp, CServ), NewComp = (NewCName, NewCInt, CFact, NewCImp, CServ). Визначимо операцію додавання нової реалізації. Особливість цієї опе- рації полягає в тому, що в результаті множина інтерфейсів компонента мо- же розширитися за рахунок додавання нових вихідних інтерфейсів, якщо реа- лізація, що додається, вимагає додатко- вої функціональності, що надається іншими компонентами. Позначимо до- даткову множину вихідних інтерфейсів NewCIntOs = {NewCIntOsq}. В окремому випадку NewCIntOs = ∅, якщо додаткова функціональність для реалізації, що до- дається, не потрібна. Вище відзначалося, що існують два різновиди цієї операції: додавання операції для існуючого інтерфейсу і нового, який ще формально не визна- чений. Позначимо першу як AddOImp з формою запису NewComp = AddOImp(OldComp, NewCImps, NewCIntOs) (7) і семантикою NewCInt = OldCInt ∪ NewCIntOs, NewCImp = OldCImp ∪ {NewCImps}, (∃OldCIntt ∈ OldCIntI) Provide(OldCIntt) ⊆ ⊆ NewCImps, де NewCImps – реалізація, що додається; OldCIntI – множина вхідних інтерфейсів з OldCInt. Умова цілісності компонента (5) виконується автоматично, тому що множина вхідних інтерфейсів залиша- ється незмінною і з цілісності старого компонента випливає цілісність нового. За визначенням семантики опе- рація AddOImp є асоціативною і комутативною операцією. Доказ цих фактів є наслідком з аналізу множин інтерфейсів і реалізацій, що входять до Методы и средства программной инженерии 50 складу відповідних компонентів. Вико- ристовуються асоціативні і комутативні властивості операцій над множинами. Другий різновид операції дода- вання реалізації позначимо як AddNImp з формою запису NewComp = AddNImp(OldComp, NewCImps, NewCIntOs) (8) і семантикою NewCInt = OldCInt ∪ NewCIntOs, NewCImp = OldCImp ∪ { NewCImps}, де NewCImps – реалізація, що додається. Як і для попередньої операції, ці- лісність компонента виконується. Та- кож аналогічно доводиться й асоціати- вність і комутативність цієї операції. Визначимо операцію заміщення існуючої реалізації новою ReplImp як NewComp = ReplImp(OldComp, NewCImps, NewCIntOs, OldCImpr, OldCIntOr) (9) з наступною семантикою. Якщо спра- ведливо, що (∀OldCIntt ∈ OldCIntI) & & (Provide(OldCIntt) ⊆ OldCImpr) => => (Provide(OldCIntt) ⊆ NewCImps) V V ((∃OldCImpj ∈ (OldCImp \ {OldCImpr})) & & Provide(OldCIntt) ⊆ OldCImpj), то NewCInt = OldCInt ∪ NewCIntOs \ \ OldCIntOr, (10) NewCImp = OldCImp ∪ {NewCImps} \ \ {OldCImpr}, де NewCImps – реалізація, що додається; NewCIntOs – множина додатко- вих вихідних інтерфейсів для реаліза- ції, що додається; OldCImpr – реалізація, що заміщується; OldCIntOr – множина вихідних інтерфейсів, пов'язаних з реалізацією, що заміщується. Доведемо наступну лему. Лема 1. Операція заміщення реа- лізації (9) із семантикою (10) зберігає умову цілісності компонента. Для будь-якого вхідного інтер- фейсу отриманого компонента, крім інтерфейсів, які відповідають реалізації OldCImpr, що заміщується, умова ціліс- ності виконується. Для інтерфейсів, що відповідають реалізації OldCImpr, згідно передумови операції справедливо, що або Provide(OldCIntt) ⊆ NewCImps, або існує інша відповідна реалізація базо- вого компонента. Об’єднуючи ці два випадки, отримуємо, що для будь-якого вхідного інтерфейсу нового компонен- та умова цілісності виконується. Операція розширення існуючої реалізації семантично еквівалентна операції заміщення, де видаляється стара реалізація, а нова, що є розши- ренням старої, додається. Тому немає необхідності вводити окрему операцію. Розглянемо операції додавання інтерфейсів. Як вже було відзначено, вихідний інтерфейс може додаватися, тільки якщо заміщається існуюча або додається нова реалізація. У противно- му випадку поняття додавання нового вихідного інтерфейсу не має сенсу (нема тієї реалізації, у якій міститься звертання до нових додаткових компо- нентів). Отже операція додавання вихід- ного інтерфейсу завжди є складовою операції додавання реалізації і як са- мостійна операція не визначається. Визначимо операцію додавання нового вхідного інтерфейсу AddInt з формою запису NewComp = AddInt(OldComp, NewCIntIq) (11) і з наступною семантикою. Якщо спра- ведлива умова, що (∃OldCImps ∈ OldCImp) & & (Provide(NewCIntIq) ⊆ OldCImps), то NewCInt = OldCInt ∪ {NewCIntIq}, (13) NewCImp = OldCImp, де NewCIntIq – новий інтерфейс. Методы и средства программной инженерии 51 Як видно із семантики, операція має умовний характер, тобто є частко- вою операцією. Доведемо наступну лему. Лема 2. Операція додавання ін- терфейсу (11) із семантикою (12) збері- гає умову цілісності компонента. Нехай виконується умова (5) для базового компонента, тобто для кожно- го з вхідних інтерфейсів існує відповід- на реалізація. Передумова (12) вимагає існування реалізації і для нового ін- терфейсу. Тому в результаті розши- рення множини вхідних інтерфейсів вираження (5) теж істинно для нового компонента і цілісність зберігається. Розглянемо операцію розширен- ня існуючого інтерфейсу. На відміну від операції розширення існуючої реа- лізації, для якої немає обов'язкової ви- моги її збереження у структурі компо- нента, всі існуючі вхідні інтерфейси повинні зберігатися. Ця вимога випли- ває з умов допустимості методів рефак- торінгу, що розглянуті вище. Тому суть операції зводиться до додавання роз- ширеного інтерфейсу як нового із се- мантикою, аналогічною попередній операції. Розглянемо операцію розширен- ня інтерфейсу CFact. Ця операція но- сить комплексний характер, оскільки додаткові методи, що входять у цей ін- терфейс, вимагають реалізації з боку контейнера. Тому реалізація цієї опе- рації пов'язана з існуванням нового типу контейнера. Отже, відповідно до класифікації методів рефакторінгу, на- ведених вище, операція розширення інтерфейсу керування екземплярами компонентів відноситься до розшире- ної класифікації і її розгляд виходить за рамки цієї статті. Аналогічні судження справедливі і для аналізу операції розширення ін- терфейсу системних сервісів. У цьому випадку необхідною умовою є реаліза- ція додаткових методів з боку компо- нентного середовища, а сама операція відноситься до розширеної класифіка- ції методів рефакторінгу. Таким чином, наведений вище аналіз дозволяє визначити внутрішню компонентну алгебру. Нехай CSet = {Compn} – множина компонентів, кожен з яких описується моделлю (1). Множина операцій Refac = { AddOImp, AddNImp, ReplImp, AddInt}, (13) визначається виразами (7)—(12). Тоді пара (CSet, Refac) визначає внутрішню компонентну алгебру, що відповідає припустимим методам рефакторінгу. Порівняльний аналіз рефакторінгу об’єктно-орієнтованого і компонентного програмування Розглянувши сутність рефакторі- нгу треба зауважити, що він має багато спільного з реінженерією програмних систем. Під реінженерією розуміється сукупність процесів, націлених на мо- дифікацію функціональних, структур- них, якісних та інших показників іс- нуючих програмних систем з метою забезпечення відповідності новим умо- вам і вимогам функціонування. Головні відмінності між двома напрямками полягають у цілях та умовах застосування цих процесів. Об’єктами реінженерії є вже іс- нуючі та деякий час функціонуючі сис- теми, які перестали відповідати певним умовам та вимогам на сучасному етапі. Це, наприклад, може бути необхідність у реалізації нової архітектури, у пере- ході на нову платформу чи операційну систему та ін. Тобто реінженерія має справу з об’єктами, які треба замінити. Для них, зокрема, існують якісні або кількісні оцінки деяких показників, не- обхідні зміни значень яких і визнача- ють напрямки процесів реінженерії. На противагу цьому рефакторінг націлений на створення нових об’єктів на базі існуючих. І старі і нові об’єкти продовжують своє застосування. На- приклад, компоненти, які входять до складу певного програмного продукту, підтримують реалізацію функціональ- ності для кількох версій цього продук- ту. Тому рефакторінг частіше застосо- вується як процес зміни значень показ- ників деякого об’єкта без заміни умов функціонування самого об’єкта. Методы и средства программной инженерии 52 З таких позицій проведемо порів- няльний аналіз рефакторінгу компо- нентів і рефакторінгу для об’єктно- орієнтованого програмування (ООП). Проте ще раз відмітимо, що процес заміни однієї мови ООП на іншу не є рефакторінгом, а відноситься до реін- женерії. Аналогічно заміна однієї ком- понентної моделі іншою також є про- цесом реінженерії. Нижче наведені основні результа- ти відповідного порівняльного аналізу. 1. Мета рефакторінгу. Ціль ООП-рефакторінгу – поліпшення структурних характеристик і якісних показників об’єктно-орієнтованих (ОО) програм. Ціль компонентного рефакто- рінгу – розширення функціональних та інших характеристик компонентів, що найбільш повно задовольняють ви- могам результатів проектування ком- понентної програми. 2. Об'єкти рефакторінгу. Об'єк- тами ООП-рефакторінгу є ОО-класи, а для компонентного програмування – готові компоненти. У зв'язку з цим ООП-рефакторінг має великі можливо- сті і більш різноманітний, тому що операції проводяться над вхідними те- кстами класів, з яких надалі будується ОО-програма. На противагу цьому компонентний рефакторінг більш об- межений у своєму розмаїтті і носить більш формальний та залежний від пев- них умов характер. 3. Етапи застосування рефакто- рінгу. ООП-рефакторінг використовує вхідні тексти класів і тому застосову- ється на більш ранніх етапах життєво- го циклу, ніж компонентний рефакто- рінг. Це дозволяє використовувати йо- го на етапі розробки самих компонен- тів, якщо їхні реалізації будуються від- повідно до ОО-підходу. 4. Середовище рефакторінгу. ООП-рефакторінг проводиться для се- редовища конкретної мови програму- вання та системи програмування. Ком- понентний рефакторінг не прив'язаний до конкретного середовища програму- вання, тому що самі компоненти мо- жуть розроблятися на різних мовах програмування. 5. Класифікація методів рефак- торінгу. Методи ООП-рефакторінгу класифікуються відповідно до елемен- тів ООП (змінні, атрибути, методи і т.д.) і шаблонів проектування. Методи компонентного рефакторінгу класифі- куються відповідно до структурних об'єктів компонентного програмування і, зокрема, структурних елементів са- мого компонента. 6. Інструментальні засоби ре- факторінгу. Базові інструментальні за- соби ООП-рефакторінгу – це засоби обробки вхідних текстів. Існують фор- мальні методи рефакторінгу, які засто- совуються для моделей ОО-класів. Ба- зовими інструментальними засобами компонентного рефакторінгу є ті ж самі засоби, які застосовуються для створення компонентів. Висновки У статті описаний процес побу- дови алгебраїчної моделі рефакторінгу компонентів. Послідовно розглянуті основні поняття рефакторінгу компо- нентів, класифікація методів, припус- тимі операції рефакторінгу, принципи побудови внутрішньої компонентної алгебри. Основним результатом є алге- браїчна модель рефакторінгу компонен- тів, формальне визначення базових операцій, умови цілісності компонен- тів, що отримані із застосуванням ви- значених операцій. Відмінною рисою пропонованого підходу є його цілісність і взаємозв'я- зок з іншими методами і моделями компонентного програмування. Усі концепції, термінологія, математичні методи ув'язані в єдину схему з викла- дом причинно-наслідкових зв'язків. Отримані результати створюють необ- хідний базис для формування практич- них методик і методологій рефакторін- гу компонентів, а також розробки від- повідних інструментальних засобів. Наведено короткий порівняльний аналіз основних характеристик рефак- торінгу для компонентного й об’єктно- орієнтованого програмування. Методы и средства программной инженерии 53 1. Грищенко В.Н., Лаврищева Е.М. Компо- нентно-орентированное программирование. Состояние, направления и перспективы развития. // Пробл. программирования. – 2002. – № 1—2. – С. 80—90. 2. Грищенко В.Н., Лаврищева Е.М. Методы и средства компонентного программирования // Кибернетика и системный анализ. – 2003. – № 1. – C. 39—55. 3. Грищенко В.Н. Формальные модели ком- понентного программирования // Пробл. программирования. – 2003. – № 2. – С. 42—57. 4. Грищенко В.Н. Систематизований підхід до визначення програмних компонентів // Там же. – 2001. – № 3—4. – С. 23—30. 5. Crnkovic I., Hnich B., Jonsson T., Kiziltan Z. Specification, Implementation and Deploy- ment of COMPONENTS // Comm. ACM. – 2002. – Oct. – P.35—40. 6. Фаулер М. Рефакторинг: улучшение соот- ветствующего кода. – СПб.: Символ-Плюс, 2003. – 432 с. 7. Приемы объектно-ориентированного про- ектирования. Патерны проектирования / Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влис- сидес. – СПб: Питер, 2001. – 368 с. 8. Грищенко В.Н. Особливості компонентно- оріентированної розробки програмного за- безпечення // Пробл. программирования. – 2001. – № 3—4. – С.75—92. 9. Сигел Дж. CORBA 3. – Москва: Малип, 2002. – 412 c. 10. Roman E., Ambler S., Jewell T. Mastering En- terprise JavaBeans. – New York: Wiley Comp. Publish., 2002. – 670 c. 11. Цимбал А.А, Аншина М.Л. Технологии соз- дания распределенных систем: Для профес- сионалов. – СПб.: Питер, 2003. – 576 с. 12. Эммерих В. Конструирование распределен- ных объектов. Методы и средства про- граммирования интероперабельных объек- тов в архитектурах OMG/CORBA, Micro- soft/COM и Java/RMI. – М.: Мир, 2002. – 510 с. Отримано 23.10.03 Про автора Грищенко Володимир Миколайович, старший науковий співробітник Місце роботи автора: Інститут програмних систем НАН України просп. Академіка Глушкова, 40, Київ-187, 03680, Україна Тел. (044) 266 3470, 266 4286

Алгебраїчна модель рефакторінгу компонентів

Репозитарії

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