Variability assurance mechanisms in Software Product Line
The main steps and problems of variability assurance process in Software Product Line (SPL) have been defined. The general model of internal structure of reusable asset has been offered which helps to distinguish base components of variability mechanisms. The set of internal and external variability...
Saved in:
| Date: | 2025 |
|---|---|
| Main Author: | |
| Format: | Article |
| Language: | Ukrainian |
| Published: |
PROBLEMS IN PROGRAMMING
2025
|
| Subjects: | |
| Online Access: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/846 |
| Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
| Journal Title: | Problems in programming |
| Download file: |  |
Institution
Problems in programming| id |
pp_isofts_kiev_ua-article-846 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/c7/4fb31c4690a12e2f3c96449c583ea2c7.pdf |
| spelling |
pp_isofts_kiev_ua-article-8462025-09-08T13:41:18Z Variability assurance mechanisms in Software Product Line Механизмы обеспечения вариабельности в семействах программных систем Механізми забезпечення варіабельності в сімействах програмних систем Kolesnik, A.L. UDC 681.3.06 УДК 681.3.06 УДК 681.3.06 The main steps and problems of variability assurance process in Software Product Line (SPL) have been defined. The general model of internal structure of reusable asset has been offered which helps to distinguish base components of variability mechanisms. The set of internal and external variability mechanisms have been analyzed and it has been proposed the recommendation of their exploitation by assets’ SPL developers.Prombles in programming 2011; 1: 56-65 Определено основные шаги и проблемы процесса обеспечения вариабельности семейств программных систем (СПС). Предложено общую модель внутренней структуры готового повторно используемого ресурса (ГОР), с помощью которой выделяются базовые компоненты механизмов вариации. Проанализировано множество внешних и внутренних механизмов вариации и представлены рекомендации их использования разработчиками ГОР СПС.Prombles in programming 2011; 1: 56-65 Визначено основні кроки та проблеми процесу забезпечення варіабельності сімейств програмних систем. Запропоновано загальну модель внутрішньої структури готового ресурсу повторного використання, за допомогою якої виділяються базові компоненти механізмів варіації. Проаналізовано множину зовнішніх і внутрішніх механізмів варіації та надано рекомендації щодо їхнього застосування розробниками готових ресурсів повторного використання в сімействах програмних систем.Prombles in programming 2011; 1: 56-65 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2025-09-08 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/846 PROBLEMS IN PROGRAMMING; No 1 (2010); 56-65 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 1 (2010); 56-65 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 1 (2010); 56-65 1727-4907 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/846/897 Copyright (c) 2025 PROBLEMS IN PROGRAMMING |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2025-09-08T13:41:18Z |
| collection |
OJS |
| language |
Ukrainian |
| topic |
UDC 681.3.06 |
| spellingShingle |
UDC 681.3.06 Kolesnik, A.L. Variability assurance mechanisms in Software Product Line |
| topic_facet |
UDC 681.3.06 УДК 681.3.06 УДК 681.3.06 |
| format |
Article |
| author |
Kolesnik, A.L. |
| author_facet |
Kolesnik, A.L. |
| author_sort |
Kolesnik, A.L. |
| title |
Variability assurance mechanisms in Software Product Line |
| title_short |
Variability assurance mechanisms in Software Product Line |
| title_full |
Variability assurance mechanisms in Software Product Line |
| title_fullStr |
Variability assurance mechanisms in Software Product Line |
| title_full_unstemmed |
Variability assurance mechanisms in Software Product Line |
| title_sort |
variability assurance mechanisms in software product line |
| title_alt |
Механизмы обеспечения вариабельности в семействах программных систем Механізми забезпечення варіабельності в сімействах програмних систем |
| description |
The main steps and problems of variability assurance process in Software Product Line (SPL) have been defined. The general model of internal structure of reusable asset has been offered which helps to distinguish base components of variability mechanisms. The set of internal and external variability mechanisms have been analyzed and it has been proposed the recommendation of their exploitation by assets’ SPL developers.Prombles in programming 2011; 1: 56-65 |
| publisher |
PROBLEMS IN PROGRAMMING |
| publishDate |
2025 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/846 |
| work_keys_str_mv |
AT kolesnikal variabilityassurancemechanismsinsoftwareproductline AT kolesnikal mehanizmyobespečeniâvariabelʹnostivsemejstvahprogrammnyhsistem AT kolesnikal mehanízmizabezpečennâvaríabelʹnostívsímejstvahprogramnihsistem |
| first_indexed |
2025-09-17T09:25:31Z |
| last_indexed |
2025-09-17T09:25:31Z |
| _version_ |
1850410166553411584 |
| fulltext |
Методи програмної інженерії
56
УДК 681.3.06
А.Л. Колесник
МЕХАНІЗМИ ЗАБЕЗПЕЧЕННЯ ВАРІАБЕЛЬНОСТІ В
СІМЕЙСТВАХ ПРОГРАМНИХ СИСТЕМ
Визначено основні кроки та проблеми процесу забезпечення варіабельності сімейств програмних сис-
тем. Запропоновано загальну модель внутрішньої структури готового ресурсу повторного використан-
ня, за допомогою якої виділяються базові компоненти механізмів варіації. Проаналізовано множину зо-
внішніх і внутрішніх механізмів варіації та надано рекомендації щодо їхнього застосування розробни-
ками готових ресурсів повторного використання в сімействах програмних систем.
Вступ
Інженерія сімейств програмних сис-
тем (СПС) є наразі важливим і широко ви-
користовуваним підходом до розробки
програмних продуктів. Основна ідея дано-
го підходу полягає у створенні програмно-
го продукту з базових елементів, які є го-
товими ресурсами (ГОР) СПС і можуть
використовуватися багаторазово при ство-
ренні програмних систем (ПС). Підхід
спрямований на покращення якості, при-
скорення випуску програмної продукції,
зниження вартості і збільшення продукти-
вності праці розробників ПС (у порівнянні
з послідовною розробкою ПС) за рахунок
використання базових елементів.
Витоки парадигми СПС – у сфері
промисловості, де вперше з’явилися ліній-
ки продуктів, орієнтовані на конкретні
ринкові сегменти або призначені для ви-
рішення конкретних задач виробництва.
Прикладом лінійки продукту може служи-
ти літак Боїнг, список деталей моделі 767
якого на 60% складається з деталей моделі
757, що дозволяє значно економити на йо-
го виробництві та супроводженні [1].
В такій сфері діяльності, як програ-
мування, побудова ПС з множини базових
елементів у парадигмі СПС стала чи не
найефективнішим засобом для забезпечен-
ня еволюційності ПС, в основі якого ле-
жить варіабельність базових елементів.
Варіабельність, у загальному випа-
дку, це властивість об’єкта до розширен-
ня, змінювання, пристосування або конфі-
гурування з метою використання у визна-
ченому контексті та забезпечення подаль-
шого його еволюціонування.
В програмній інженерії питання за-
безпечення варіабельності ПС належать до
області досліджень методів конфігуруван-
ня продукту (product configuration) та про-
цесів керування конфігурацією (configura-
tion management), спрямованих на визна-
чення і впровадження ефективних проце-
дур його зміни або налаштування з метою
отримання програмного продукту з пев-
ною функціональністю і характеристиками
якості [2].
Зазвичай розглядають три аспекти
забезпечення варіабельності:
– моделювання варіабельності на най-
вищому рівні характеристик об’єктів, які
мають варіанти (варіантні характеристи-
ки). Метою підходів моделювання є по-
дання варіабельності у такий спосіб, який
покращує розуміння проблем забезпечення
варіабельності та керування нею;
– реалізацію варіабельності на насту-
пних рівнях архітектури об’єктів за допо-
могою механізмів варіації. Проблемою за-
безпечення варіабельності є місце (рівень)
її реалізації: чи буде вона реалізована в
момент визначення архітектури СПС, чи
це буде зроблено під час фази розробки
індивідуального продукту ПС. Відповідне
рішення приймається розробником СПС з
урахуванням власного досвіду створення
ефективних механізмів варіації;
– керування варіабельністю, пов’язане
з її плануванням, контролюванням та регу-
люванням у ході життєвого циклу (ЖЦ)
об’єктів, яким властива варіабельність.
Базовими елементами або готовими
ресурсами СПС, які можуть варіюватися, є
складові архітектури, документація, спе-
© А.Л. Колесник, 2010
ISSN 1727-4907. Проблеми програмування. 2010. № 1
Методи програмної інженерії
57
цифікація, програмні компоненти, моделі
виконання, графіки розробки, описи про-
цесів, плани тестування і робіт тощо. При
побудові кожного базового елемента треба
визначати, яка частина базового елемента
буде однакова для всіх систем, в які вона
буде включена, а яка змінюватиметься; ви-
бирати механізм варіації; надавати відпо-
відні інструкції для розробників щодо
конфігурування ПС з базових елементів
або побудови її засобами генерувального
програмування [3].
Переваги застосування базових
елементів у СПС полягають у тому, що во-
ни можуть бути приєднані до розроблюва-
ної системи без попередньої адаптації, що
досягається саме завдяки використанню
механізмів варіації у ГОР. Це, в свою чер-
гу, дає можливість «дешево» долучати но-
ву функціональність до ПС у відповідності
з вимогами.
У даній роботі стисло охарактери-
зовано основні кроки та проблеми процесу
забезпечення варіабельності СПС, деталь-
ніше розглянуто аспект реалізації варіабе-
льності та запропоновано підходи до за-
безпечення варіабельності базових елемен-
тів, які є програмними артефактами СПС,
розробленими в парадигмі об’єктно-
орієнтованого програмування.
Кроки процесу забезпечення
варіабельності СПС
Варіабельність – здатність сімейст-
ва ПС, окремої системи або артефакту до
розширення, змінювання, пристосування
або конфігурування з метою використання
у конкретній предметній області.
Варіабельність має забезпечуватися
на рівнях вимог до ПС, моделі характерис-
тик СПС, архітектури, коду, документації,
тестів тощо. Загалом, вона може бути реа-
лізована як у СПС, так і в конкретних ПС.
У першому випадку забезпечується варіа-
бельність виробничої лінії, яка підтримує
існування сімейства як множини ПС. Вона
стосується множини базових елементів
будь-якої природи (програмних і не про-
грамних), які містяться у репозитарії виро-
бничої лінії. У другому випадку забезпечу-
ється варіабельність складових ПС (вклю-
чаючи документацію), що обумовлює ево-
люційність ПС після «відлучення» від
СПС. В обох випадках реалізація варіабе-
льності спрямована на забезпечення жит-
тєздатності СПС і ПС [4].
Для того щоб забезпечити бажану
варіабельність СПС, треба виконати
наступну послідовність кроків [5].
Крок 1. Ідентифікація варіабель-
ності СПС. Найпростіше ідентифікувати
варіабельність через моделювання систем
в термінах характеристик і визначення ха-
рактеристик, які матимуть варіанти, так
званих варіантних характеристик (ВХ).
Тобто варіантна характеристика – абстрак-
ція, що передбачає наявність сукупності
варіантів і точок варіації. Для моделюван-
ня можуть застосовуватися методології
FODA, FORM, RSEB, FAST тощо [6].
Ідентифікована варіантна характе-
ристика має статус неявної, не реалізованої
у СПС, існуючої лише як концепт у моделі
характеристик. Впродовж свого життєвого
циклу вона багаторазово трансформується
до тих пір, поки не буде реалізована про-
грамно у ПС.
Крок 2. Обмеження варіабельнос-
ті СПС. Спрямоване на забезпечення до-
статньої гнучкості СПС з урахуванням по-
точних потреб і перспектив еволюції у
найбільш ефективний за витратами спосіб.
На цьому кроці ВХ проходить процедуру
введення в СПС і перестає бути неявною.
Введена в СПС характеристика має подан-
ня в архітектурі і реалізації СПС у формі
множини точок варіації – місць в архітек-
турі і реалізації ГОР, які разом надають
механізми, необхідні для забезпечення ва-
ріабельності характеристики. На момент
введення у СПС конкретні варіанти харак-
теристики можуть бути відсутніми.
Обмеження варіабельності стосу-
ється прийняття рішень з таких питань:
– час введення варіантної характерис-
тики в архітектуру і реалізацію СПС,
– час і спосіб приєднання варіантів
до ПС,
– вибір моменту зв’язування варіанта
для кожної точки варіації, тобто моменту,
коли точка варіації конкретизується пев-
ним варіантом ВХ (і перестає існувати як
така у ПС).
Методи програмної інженерії
58
Таким чином, на цьому кроці ви-
значаються всі особливості варіантних ха-
рактеристик, які впливають на спосіб їх-
ньої реалізації.
Крок 3. Реалізація варіабельності.
Залежно від прийнятих обмежень щодо
варіабельності може бути вибрана відпові-
дна (найбільш ефективна) технологія реа-
лізації точок варіації, пов’язаних з певною
варіантною характеристикою. На цьому
кроці для введеної ВХ визначаються долу-
чені варіанти, для кожного з яких реалізу-
ються програмні сутності, які разом здатні
«закрити» всі точки варіації. Залежно від
того, як реалізована точка варіації, вона
буде відкритою для долучення варіантів на
різних стадіях розроблення ПС, або закри-
тою. Тобто, нові варіанти вводитимуться
лише на певних етапах розроблення ПС.
На наступній стадії приймається
рішення стосовно того, який варіант ВХ
буде використовуватися, і ПС конкретизу-
ється до вибраного варіанта через поси-
лання на конкретні програмні сутності.
Таким чином, ЖЦ варіантної харак-
теристики, як об’єкта СПС, включає на-
ступний перехід її станів (рис. 1): концеп-
туальне подання (неявна ВХ), множина
точок варіації у СПС (введена ВХ), мно-
жина варіантів програмних сутностей (ВХ
як множина варіантів реалізації), конкрет-
ний фрагмент ПС, який реалізує задану
характеристику (зв’язана ВХ).
Рис. 1. Процес забезпечення варіабельності
Крок 4. Керування варіабельніс-
тю. В результаті виконання кроків 1 – 3 із
забезпечення варіабельності у середовищі
СПС накопичуються артефакти, створюва-
ні впродовж ЖЦ ВХ для всіх розроблюва-
них ПС. Щодо них мають застосовуватися
супроводжувальні дії, як-от поповнення
варіантних характеристик новими варіан-
тами, видалення не використовуваних ва-
ріантів тощо, а також, видалення ВХ разом
з усіма варіантами при зміні вимог, вида-
лення «слідів» старих ПС у СПС тощо. Ра-
зом ці дії стосуються регулювання рівня
варіабельності СПС і пов’язані з іншими
діями з керування варіабельністю – пла-
нуванням, обліком і контролем варіа-
бельності.
Проблеми забезпечення
варіабельності
Введення варіантної характерис-
тики в архітектуру. Варіантні характери-
стики можуть бути введені на всіх етапах
ЖЦ системи, від архітектурного та деталь-
ного проекту, до реалізації, компіляції і
компонування (лінкінгу, від linking) [5].
Одна ВХ може відбиватися на множину
різнотипних програмних сутностей, які
разом забезпечують бажану функціональ-
ність. Вона проявляє себе у СПС множи-
ною точок варіації на різних рівнях абст-
ракції. Рішення щодо введення ВХ, при-
ймаються з огляду на таке:
– доступність (готовність) технології
реалізації, яка задовольняє потребам щодо
моментів зв’язування та долучення варіан-
тів;
– розміри програмних сутностей,
яких стосується введення ВХ;
– кількість точок варіації;
– вартість супроводження введених
точок варіації.
Якщо точка варіації введена на ран-
ніх стадіях ЖЦ ВХ, вона потрапляє під
контроль на всіх наступних етапах розроб-
лення, в іншому випадку – вона контролю-
ється лише протягом нетривалого часу.
Якщо точка варіації відкрита для
долучення нових варіантів до їх колекції у
цій точці, в будь-який момент часу варіан-
ти можуть бути долучені або вилучені.
Якщо точка варіації закрита, колекція варі-
антів зафіксована і не може змінюватися.
Методи програмної інженерії
59
Долучення варіантів у точках ва-
ріації. Рішення щодо того, коли і як долу-
чати варіанти, приймається з огляду на бі-
знес стратегію і модель виробництва ПС
на лінії. Якщо бізнес стратегія передбачає
можливість пізнього долучення варіантів,
наприклад, сторонніми постачальниками,
це обмежує вибір технологій реалізації
точок варіації, оскільки може виникнути
потреба залишати їх (точки) відкритими
для долучення нових варіантів після ком-
піляції або навіть у період виконання ПС.
На те, як і коли долучати варіанти,
впливає також процес розроблення ПС і
інструменти, використовувані для розроб-
лення [2].
Долучення варіантів може викону-
ватися двома шляхами, залежно від того,
як реалізовано точку варіації. Варіанти
можуть бути долучені неявно, і це означає,
що не існує подання колекції варіантів у
ПС. Колекцією керують за межами систе-
ми з використанням, наприклад, простих
переліків наявних варіантів. У цьому випа-
дку забезпечення належного варіанта з ко-
лекції неявних варіантів покладається на
розробників або користувачів. При явному
долученні варіантів колекція варіантів
присутня у складі початкового коду ПС, і
це означає, що в системі достатньо інфор-
мації для того, щоб за потреби самостійно
знайти необхідний варіант.
Зв’язування варіанта в точці ва-
ріації. Головна мета введення варіантних
характеристик – відкладення на подальші
стадії розроблення ПС рішення щодо кон-
кретної характеристики, яку треба реалізу-
вати. Конкретизація СПС до необхідного
варіанта асоціюється зі зв’язуванням варі-
анта з незмінною складовою ПС у точці
варіації.
Розрізняють внутрішнє і зовнішнє
зв’язування. При внутрішньому зв’язуван-
ні програмна система включає функціона-
льність, асоційовану із зв’язуваним варіан-
том. Таке зв’язування відбувається у пері-
од виконання. Зовнішнє зв’язування пе-
редбачає, що існує особа або інструмент,
які фактично виконують зв’язування.
Рішення щодо того, яким має бути
зв’язування – внутрішнім або зовнішнім,
обумовлюється тим, виконують його роз-
робники ПС чи кінцеві користувачі, а та-
кож тим, чи має воно бути прозорим для
користувачів.
Як і з долученням варіантів, час,
коли потрібне зв’язування, обмежує вибір
можливих шляхів реалізації точки варіації.
Якщо варіантна характеристика вводиться
через багато точок варіації, можуть виник-
нути проблеми, оскільки точки варіації
мають зв’язуватися або одночасно (як у
випадку зв’язування в період виконання),
або синхронізовано (коли, наприклад, точ-
ка варіації, зв’язувана при компіляції, асо-
ціюється з варіантом, який був зв’язаний у
точках варіації на рівні архітектури).
При прийманні рішень щодо часу
зв’язування слід керуватися правилом: чим
пізніше виконується зв’язування, тим воно
витратніше. Відкладання зв’язування з ча-
су побудови архітектури на час компіляції
зумовлює необхідність для розробників
керування всіма варіантами під час реалі-
зації, а відкладання зв’язування з часу
компіляції на час виконання зумовлює не-
обхідність включати функціональність
зв’язування і це коштує дорожче в термі-
нах ефективності виконання зв’язування.
Внутрішня структура повторно
використовуваного ресурсу
Рекомендації щодо побудови зов-
нішніх специфікацій повторно використо-
вуваних інформаційних ресурсів надає
OMG у документі «Reusable Asset
Specification (RAS)» [7]. Призначення цих
специфікацій – спрощення процедури
об’єднання (пакетування) інформації щодо
ГОР для її розповсюдження і пошуку через
уніфікацію структури, вмісту і опису ГОР
різних категорій.
Для усвідомленого вибору і впрова-
дження механізмів реалізації варіабельнос-
ті у програмних ГОР СПС, виконуваного
розробниками цих ГОР, пропонується ви-
користовувати іншу модель (рис. 2).
Модель внутрішньої структури ГОР
показана на рис. 2 діаграмою класів в
об’єктно-орієнтованому стилі, але це не
означає, що ГОР має бути написаний
об’єктно-орієнтованою мовою. На цій діа-
грамі базовий елемент є основним класом,
який представляє ГОР і взаємодіє з ПС.
Методи програмної інженерії
60
Рис. 2. Внутрішня структура ГОР
Іншими словами, об’єкт класу базо-
вий елемент і є ГОР. Базовий елемент
включає в себе загальну частину і (необ-
ов’язково) змінну частину. Якщо базовий
елемент не має змінної частини, його ви-
користовують безпосередньо шляхом
включення до конкретної ПС. Призначен-
ням змінної частини є локалізація змін у
конкретному місці ГОР. Відсутність зага-
льної частини означає, що всі ГОР мають
бути розроблені для кожної ПС індивідуа-
льно, що суперечить концепції ГОР.
Подальші пояснення щодо внутрі-
шньої структури ГОР, а також механізмів
забезпечення його варіабельності, супро-
воджуватимемо прикладом, в якому як
ГОР виступатимуть елементи управління
(ЕУ) графічного інтерфейсу користувача
(GUI), які за зовнішнім виглядом і змістом
виконуваних дій можуть адаптуватися до
вимог користувача. Отже, для ЕУ загаль-
ною частиною може виступати механізм
графічного виводу ЕУ на екран, оскільки
для всіх варіантів ЕУ він буде однаковим.
Змінну частину представлятиме набір па-
раметрів, які модифікують поведінку і ви-
гляд ЕУ.
Кожна змінна частина може містити
декілька механізмів варіації, які підтриму-
ють створення або вибір варіантів. Меха-
нізм варіації може бути інтегрований без-
посередньо в базовий елемент. Прикладом
такої інтеграції є спосіб зміни параметрів
ЕУ, його розміру, кольору тощо. Змінна
частина представляє точку варіації, а ме-
ханізми варіації виступають засобом конк-
ретизації ГОР.
У багатьох випадках змінна частина
включає два механізми: один для створен-
ня нового варіанта, а інший – для підтрим-
ки вибору існуючого.
Механізм варіації включає все
необхідне розробникам ПС для внесення
будь-яких важливих змін. У разі його від-
сутності, відповідні ГОР не будуть широко
використовуватися в СПС, а це свідчитиме
про не координованість дій процесу розро-
блення ГОР і процесу розроблення ПС з
використанням ГОР [2]. У прикладі з ЕУ
механізм варіації надає можливість для
розробників ПС змінювати його властиво-
сті, а для розробників ГОР – долучати нові.
Результатом застосування механіз-
му варіації до змінної частини ГОР є варі-
ант, який міститься в загальній частині і
може бути включений до змінної частини.
Зазвичай, поява нового варіанта зумовлю-
ється застосуванням нового механізму
варіації. Наприклад, додаючи новий меха-
нізм заповнення даними (binding – меха-
нізм зв’язування) ЕУ типу список, отриму-
ємо новий варіант поведінки базового еле-
мента. В подальшому ЕУ здатен працюва-
ти у всіх ПС, які використовують цей
механізм.
Щойно створений варіант для однієї
ПС може бути використаний в інших про-
дуктах через застосування процедури
вибору механізму варіації.
Для підтримки використання меха-
нізмів варіації при побудові ПС на основі
СПС пропонується в опис змінної частини
включати інформацію щодо процесу вико-
ристання та умов її адаптації до потреб
ПС. Процес використання пояснюватиме,
як використовувати механізми варіації для
створення або вибору варіанта для розроб-
люваної ПС. Опис процесу може містити
умови використання. Якщо умов немає, то
він є безумовним і виконується кожного
разу, коли створюється нова ПС із базових
елементів. Умови використання змінної
частини визначають залежність від колек-
ції варіантів, які впливають на конкретний
продукт. Колекція може бути доповнена
варіантами з іншої змінної частини або
задана розробниками ПС і відображатиме,
Методи програмної інженерії
61
яку альтернативу було обрано для вирі-
шення проблеми в конкретній ПС.
Можливі різні види залежності
змінних частин, а саме: внутрішня залеж-
ність – це залежність однієї змінної части-
ни ГОР від його іншої змінної частини,
якщо така є, і зовнішня залежність – це за-
лежність від змінної частини іншого ГОР.
Основні підходи до реалізації
варіабельності програмних ГОР
З точки зору розробника ПС підхід
до реалізації варіабельності вибирається
виходячи з потреб зовнішнього або внут-
рішнього зв’язування варіантів, а спосіб
впровадження конкретного механізму ва-
ріації – з огляду на застосовні парадигми,
стилі і навіть мови програмування.
1. Підходи і механізми зовнішньо-
го зв’язування варіантів. Для зовнішньо-
го зв’язування варіантів можуть викорис-
товуватися такі механізми варіації, як мак-
роси, умовна компіляція коду, конфігуру-
вання та генерування коду, організація
статичних бібліотек та динамічне приєд-
нання бібліотек. Розглянемо їх детальніше.
Макрос – це програмний об'єкт,
який при обробці «розгортається» в послі-
довність дій або команд. Макроси повніс-
тю або частково підтримуються в Ada, C,
C++, D, Erlang, Haskell, Common, Lisp,
Nemerle, Ruby, Ocaml. Функціональність
макросу розділена на дві частини. Загальна
знаходиться в тілі визначення макросу, а
варійовані частини можуть перебувати в
різних частинах коду та містити варійовані
параметри, як у наступному прикладі:
// Macros.h Macros попередження
#define РеєстрПопереджень( повідомлення)
cout << “ Попередження у строчці: “ <<
__LINE__ << “: “ << ( повідомлення) << endl;
// Будь який клас в ПС. *.cpp
#include “Macros.h” // Включаємо макрос.
БудьЯкийКлас:: Метод() {
РеєстрПопереджень(“ Повідомлення”);};
Умовна компіляція коду. Цей ме-
ханізм варіації забезпечує можливість кон-
тролю за включенням або виключенням
сегмента коду із збірки, використовуючи
параметри компіляції. Приклад:
string s;
#ifdef WIN32
s = …;
#ifdef VXWORKS
s = …;
#endif
return s;
Тут представлена змінна частина і
варіаційний механізм. Варіант, результат
варіації, зберігається у змінній «s».
Конфігурування. Вихідний код
кожного варіанта знаходиться в окремому
файлі, а для вибору альтернатив викорис-
товується інструмент керування конфігу-
рацією.
Генерування. Генератор конвертує
задану специфікацію, написану мовою
предметної області або компонентною мо-
вою, у вихідний код, а вихідний код, у
свою чергу, може бути використаний як
частина продукту. Приміром, графічний
інтерфейс користувача може бути згенеро-
ваний з графічної (Silverlight) або текстової
специфікації.
Організація статичних бібліотек.
Статичні бібліотеки містять набір зовніш-
ніх функцій, які можна використовувати в
програмному застосуванні після його ком-
піляції. При цьому код з бібліотеки інтег-
рується в виконуваний файл. Варіабель-
ність досягається шляхом вибору відпові-
дної бібліотеки перед її приєднанням. У
Unix-системах, наприклад, бібліотеки в
основному розташовуються в директоріях
/lib, /usr/lib, /usr/local/lib, а у Windows-
системах – в \System32, і мають тип файлу
“ocx” або “lib”.
Динамічно приєднувані бібліоте-
ки. Даний механізм варіації заснований на
використанні DLL-бібліотек, які можна
помістити в адресний простір програми під
час її роботи. Керування варіабельністю
досягається шляхом реалізації різних варі-
антів коду в окремих бібліотеках та напи-
сання вихідного коду, який завантажує пе-
вні варіанти в програмне застосування під
час його роботи. Отже, немає необхідності
знати всі можливі варіанти під час розроб-
ки програми. У Unix-системах, наприклад,
вони називаються спільно використовува-
ними об’єктами (shared objects) і мають
тип файлу “so”. Mac OS X також успадку-
вали від BSD роботу з бібліотеками. Вони
знаходяться в директоріях “bundles” і ма-
ють тип “dylib”.
2. Підходи і механізми внутріш-
нього зв’язування варіантів. При описі
механізмів, призначених для внутрішнього
зв’язування, вважатимемо, що ПС розроб-
Методи програмної інженерії
62
ляється в парадигмі об’єктно-орієнтова-
ного програмування, де кожний компонент
ПС представлений класом із власними да-
ними і методами їх обробки, а отже, всі
варіації, з якими користувач має справу,
при реалізації являють собою маніпуляції
класами або іншими конструкціями вико-
ристовуваної мови програмування.
Пропонуються наступні підходи до
реалізації варіабельності: композиція, ус-
падкування, параметризація, переванта-
ження операторів і методів, динамічне за-
вантаження класів, рефлексія, шаблони
(паттерни) архітектури і проектування.
Стисло охарактеризуємо кожний з них.
Композиція. Механізм варіабель-
ності засновується на встановленні зв’язку
між об’єктами типу «part of» і розміщенні
загальної частини в делегуючому класі, а
змінної – в делегованому. На рис. 3 пока-
зана UML схема та відповідний фрагмент
коду, що описує поведінку системи у ви-
падку зміни розташування панелі з елеме-
нтами управління у вікні.
class Вікно {
List< Панель> панелі = new List< Панель>();
public Вікно() {
foreach ( Панель панель in панелі) {
панель. Горизонтально = true;}}}
class Панель {
List< ЕлементУправління> ЕлементиУправління
= new List< ЕлементУправління>();
public bool Горизонтально {
get { return горизонтально; }
set { горизонтально = value;
ПеремалюватиЕУ();}}
private bool горизонтально;
private void ПеремалюватиЕУ(){/*...*/}}
class ЕлементУправління {/*...*/}
Рис. 3. Композиція
Вікно не містить запрограмованої
логіки щодо відображення і групування
різних ЕУ. Вікно делегує цю функцію па-
нелі. Команда панель. Горизонтально =
true; є загальною частиною, яка викону-
ється однаково не залежно від типу панелі
й ЕУ. Змінна частина знаходиться у методі
ПеремалюватиЕУ() , який містить відповід-
ну логіку розташування і відображення для
різних ЕУ.
У даному прикладі загальною час-
тиною є інтерфейс роботи з властивістю
Панель. Горизонтально і методом
ПеремалюватиЕУ() , які містять механізм
варіації. Ці компоненти реалізовані в усіх
інших породжених типах панелей і ЕУ
відповідно, а отже змінною частиною є
вміст кожного з цих методів і властивос-
тей. Варіантами є об’єкти, що зберігаються
в змінних: List< ЕлементУправління> Еле-
ментиУправління і List< Панель> панелі.
На рис. 3 зв'язок між класами па-
нель і ЕУ є прикладом агрегації об’єктів –
панель може містити декілька ЕУ; зв'язок
між класами вікно і панель – прикладом
композиції об’єктів, де до відношення
«part-of» додається умова, що панель на-
лежить тільки одному вікну і знищується
разом з ним. Узагальненням обох відно-
шень (агрегації і композиції) є асоціація.
Успадкування. Механізм базується
на такому принципі об’єктно-орієнтованої
парадигми, як успадкування через встано-
влення відношень «нащадок-предок» з
можливістю породжувати один клас
об’єктів від іншого із збереженням всіх
властивостей і методів класу-предка, а,
отже, і керувати об’єктами, не маючи по-
вної інформації про них.
Цей механізм розділяє загальну
функціональність у базовому класі і допо-
внену в класі спадкоємця. Як мінімум
успадкування поділяють на наступні
категорії:
– Стандартне успадкування. Пе-
редбачає створення ієрархічної структури
коду, що містить більш загальну функціо-
нальність на верхньому рівні (у базовому
класі) для подальшого використання її на
нижньому рівні, доповненому варійованою
функціональністю (класи спадкоємці). Та-
ким чином, класи стають більш спеціалізо-
ваними. Приклад стандартного успадку-
вання класів показано на рис. 4.
Рис. 4. Приклад успадкування класів в GUI
Методи програмної інженерії
63
– Успадкування з віртуальними
методами. Механізм, подібний до станда-
ртного успадкування, але методи базового
класу можуть бути перевантажені класом
спадкоємцем.
– Множинне успадкування. При та-
кому механізмі реалізації варіабельності
новий клас успадковується від декількох
базових.
У прикладі на рис. 5 клас керування
містить алгоритми сортування та пошуку і
не залежить від елементів, над якими ви-
конується операція. Такий тип успадку-
вання підтримується в мовах програму-
вання: Eiffel, C, Dylan, Python, Perl, Curl,
Common Lisp (через CLOS), OCaml.
Рис. 5. Множинне успадкування
– Успадкування, засноване на доміш-
ках. Домішка (mix) – елемент мови про-
грамування (абстрактний підклас або мо-
дуль), який реалізує варіант поведінки ба-
тьківського класу або модуля. При реалі-
зації варіабельності він використовується
для уточнення поведінки інших класів і не
призначений для породження самостійно
використовуваних об'єктів. Мови програ-
мування, які підтримують домішки:
Flavors, Smalltalk, Beta, CLOS, Ruby, D,
Python, Scala.
На рис. 6 показана UML-схема реа-
лізації успадкування з домішкою та відпо-
відний фрагмент коду. На схемі інтерфейс
потреби описує, через які методи домішка
отримує інформацію від предка. Будь який
клас, в якому буде використовуватись до-
мішка, має реалізовувати методи інтер-
фейсу послуги. Класи Алгоритми1 і Алго-
ритми2 у даному випадку є домішками. У
класі впорядкований список змішуються
обидва класи.
В цьому фрагменті точка варіації
представлена в коді командою this.mixin
= new Алгоритми1(this); . Якщо виникне
необхідність змінити алгоритм сортування
або пошуку, який реалізовано в класі Ал-
горитми1, достатньо змінити Алгоритми1
на інший клас, успадкований від інтерфей-
су послуги.
interface Послуги {
void Впорядкувати();
object Знайти(/* елемент*/);}
interface Потреби {
object ОтриматиЕлемент(int номер);}
class Алгоритми1 : Послуги {
private readonly Потреби список;
public Алгоритми1( Потреби список) {
this. список = список;}
public void Впорядкувати() {
/* Алгоритм впорядкування списку який
знахо- диться в parent*/}
public object Знайти(/* елемент*/) {
/* Алгоритм пошуку в
список. ОтриматиЕлементи();*/}}
class Алгоритми2 : Послуги {
private readonly Потреби список;
public Алгоритми2( Потреби список) {
this. список = список;}
public void Впорядкувати() {}
public object Знайти(/* елемент*/){/*...*/}
}
class СписокЕлементів {
private object[] елементи;
public СписокЕлементів() {
елементи = new object[10]; }
public object ОтриматиЕлемент(int номер) {
return елементи[ номер]; }
public void ДодатиЕлемент(object елемент){
/* Додаємо елемент */ }}
class ВпорядкованийСписок:
СписокЕлементів, Потреби, Послуги {
private readonly Послуги mixin;
public ВпорядкованийСписок(): base() {
if(/* обмежена пам' ять*/){
this.mixin = new Алгоритми1(this);
} else if (/* повільний процесор*/) {
this.mixin = new Алгоритми2(this);
}}
public void Впорядкувати() {
mixin. Впорядкувати();}
public object Знайти(/* елемент*/) {
object елемент =
mixin. Знайти(/* елемент*/);}}
Рис. 6. Імітація множинного успадкування
Змінна частина представлена кла-
сами Алгоритми1 і Алгоритми2, загальна –
інтерфейсами потреби і послуги та класа-
ми Список елементів і Впорядкований-
Список. Вибраний варіант зберігається у
змінній private readonly Послуги
mixin, а механізмом варіації є оператор if
Методи програмної інженерії
64
в конструкторі public Впорядкований
Список() .
– Ууспадкування, засноване на об'єк-
тах, або шаблон делегування (delegation
pattern). Це механізм варіації, який, на від-
міну від інших, застосовується на рівні
об’єктів, а не класів. Це спосіб, яким об'єкт
зовні демонструє деяку поведінку, але
фактично передає відповідальність за
виконання відповідної дії іншому об'єкту,
як у наступному прикладі, де Принтер деле-
гує її об’єкт типу СправжнійПринтер.
class СправжнійПринтер { // делегований
void друкувати() {/*..*/}}
class Принтер { // делегуючий
СправжнійПринтер принтер =
new СправжнійПринтер();
void print() {
принтер. друкувати();}}
Параметризація. В об’єктно-
орієнтованому програмуванні параметри-
зованим може бути клас, структура, інтер-
фейс або метод, у якому є посилання на
місце конкретизації параметрів одного або
декількох типів, якими він оперує або які
зберігає (конструкція на зразок
placeholders (type parameters)). Цей меха-
нізм варіації передбачає наявність загаль-
ного коду для роботи з різними типами
даних. Яскравими представниками є шаб-
лони та універсальні шаблони. Вони є син-
таксично і функціонально подібними, але
відрізняються внутрішнім механізмом реа-
лізації. Приклад використання можна
знайти на рис. 3, це змінні: List< Панель> і
List< ЕлементУправління>. Вони можуть
зберігати масиви об’єктів будь-яких типів,
породжених від типів панелі і ЕУ відпові-
дно. При цьому алгоритм роботи залиша-
ється не змінним.
Перевантаження. Сутність цього
механізму полягає у варіації типів, над
якими виконується оператор, або за якими
викликається функція. Тобто мовою про-
грамування надається можливість повтор-
ного використання імені для оперування
іншими типами. Вибір варіанта здійснює
програмне середовище мови програмуван-
ня. Застосовується до процедур, функцій
або операторів. Мови, що підтримують пе-
ревантаження: Ada ,C++, C#, D, Erlang, F#,
Groovy, Java, JavaScript, Haskell, Common
Lisp, Nemerle, Scala, VB.NET, Delphi,
Ocaml. Мова Java не підтримує переванта-
ження операторів, але виконує внутрішнє
перевантаження оператора “+” для поєд-
нання рядків. В C#, наприклад, можна
перевантажувати методи, унарні і бінарні
оператори.
Використання цього механізму мо-
жна розглянути на прикладі методу public
object Знайти(/* елемент*/)( рис. 6) .
Система сама вирішить, що повертати як
результат: знайдений елемент чи його
позицію у списку, якщо розробник додасть
ще один метод з такою ж назвою але
іншим вихідним параметром, public int
Знайти(/* еле- мент*/).
Динамічне завантаження класів.
Сутність механізму полягає у тому, що
клас завантажується в пам'ять лише тоді,
коли він дійсно починає використовувати-
ся, як реалізовано, наприклад, у віртуаль-
ній машині мови Java. Для керування цією
функціональністю використовується
(MainClass.class.getClass Loader ();)
Відображення. Механізм заснова-
ний на здатності програми модифікувати
власну поведінку. Такі маніпуляції дося-
гаються завдяки поділу ПС на базовий і
мета рівні. Мета рівень надає інформацію
про обрані системні властивості. Оскільки
базовий рівень, що включає логіку про-
грами, будується на мета рівні, зміни мета
рівня впливають на поведінку базового рі-
вня. У СПС загальна функціональність ро-
зташована на базовому рівні і може міня-
тися під час роботи залежно від конфігу-
раційної інформації, яка використовується
на мета рівні.
Приклад реалізації відображення
мовою C#:
// Без відображення
Університет унів = new Університет ();
унів. СписокФакультетів();
// Відображення
Type type = Type.GetType(
"UnivercityNamespace. Університет ");
object univ = Activator.CreateInstance(t);
type.InvokeMember(" СписокФакультетів ",
BindingFlags.InvokeMethod, null, univ, null);
Шаблони ( або Паттерни) архітек-
тури і проектування (patterns) можуть ви-
користовуватися в СПС, оскільки біль-
шість з них надають готові рішення для
управління варіабельністю. Застосування
шаблонів покриває деякі попередні механі-
зми, такі як: агрегація, успадкування,
Методи програмної інженерії
65
параметризація. У прикладі на рис. 7 пока-
зано шаблон міст (bridge).
Рис. 7. Шаблон
Клас абстракція визначає абстракт-
ний інтерфейс для клієнта і містить змінну
виконавець типу виконавець. Конкретиза-
ція абстракції розширює інтерфейс, визна-
чений абстракцією. Виконавець визначає
інтерфейс для певного виконавця. Він не
повинен повністю відповідати інтерфейсу
абстракції, тобто він може бути повністю
відмінним. Типовою є ситуація, коли ви-
конавець надає тільки примітивні операції,
а абстракція визначає операції високого
рівня, що базуються на примітивних. Пев-
ний виконавець визначає певні (конкретні)
реалізації простих операцій. Накладаючи
цей шаблон на вищепредставлену схему
ГОР, можемо побачити, що абстракція є
загальною частиною, змінна виконавець
зберігає варіант, у функції операція() зна-
ходиться механізм варіації, а клієнт є ін-
шим ГОР, залежним від загальної частини,
і не залежить від інтерфейсу певних вико-
навців.
Розглянуті механізми варіації хоча і
не покривають всю проблемну область за-
безпечення варіабельності, але є найбільш
використовуваними у парадигмі об’єктно-
орієнтованого програмування. Частково
вони можуть бути використані в інших па-
радигмах, а деякі з них навіть концептуа-
льно закладені в ці парадигми.
Висновки
Розглянуто кроки процесу забезпе-
чення варіабельності, сформульовано про-
блеми щодо введення варіантних характе-
ристик в архітектуру СПС, долучення ва-
ріантів та їх зв’язування у точках варіації.
Запропоновано загальну модель внутрі-
шньої структури ГОР, за допомогою якої
виділяються базові компоненти механізмів
варіації. Проаналізовано 6 зовнішніх і 7
внутрішніх найбільш поширених механіз-
мів варіації та надано рекомендації щодо
їхнього застосування розробниками ГОР
СПС. Результати дослідження використо-
вуватимуться при побудові системи під-
тримки прийняття рішень щодо вибору
можливих механізмів варіації у контексті
парадигм програмування, операційних
систем та мов програмування, а також для
автоматизованого аналізу ГОР і оцінюван-
ня варіантних характеристик СПС з точки
зору наявності реалізованих варіантів,
повноти охоплення проблем еволюції ГОР,
а також можливості долучення нових
варіантів.
1. Northrop L.M., Clements P.C. A Framework
for Software Product Line Practice, version
5.0 – http://www.sei.cmu.edu/productlines/
index.html
2. Лавріщева К.М., Коваль Г.І., Слабоспицька
О.О., Колесник А.Л. Особливості процесів
керування при створенні сімейств програ-
мних систем // Проблеми програмування. –
2009. – № 3 – С. 40 – 49.
3. Лавріщева К.М. Генерувальне програму-
вання програмних систем і їх сімейств //
Проблеми програмування. – 2009.– № 1. –
С. 3 – 16.
4. Ігнатенко П.П., Бистров В.М. Особливості
забезпечення життєздатності програмних
систем в умовах генеруючого програму-
вання // Проблеми програмування. – 2008.
– № 2-3. – С. 270 – 278.
5. Svanberg M., van Gurp J. A Taxonomy of
Variability Realization Techniques // Practice
and Experience . – 2006. – N 8. – P. 705–754.
6. Domain engineering methodologies survey –
http://www.pnp-
software.com/cordet/download/ pdf/GMV-
CORDET-RP-001_Iss1.pdf
7. Reusable Asset Specification (RAS) –
http://www.omg.org/cgi-bin/doc?formal/05-
11-02.pdf
Отримано 04.01.2010
Про автора:
Колесник Андрій Леонідович,
аспірант Інституту програмних систем
НАН України.
Місце роботи автора:
Інститут програмних систем НАН України
03187, Київ-187,
Проспект Академіка Глушкова, 40.
Тел.: +380 (50) 444 2299
e-mail: swabber@gmail.com
|