Підхід до побудови об’єктно-компонентної моделі сімейства програмних продуктів
Модель властивостей Сімейства програмних продуктів (СПП) розвинуто об’єктно-компонентним методом проектування ПС (К.М. Лавріщева, В.М. Грищенко). Для опрацювання виявлених обмежень моделі її подано графом складних об’єктів, що відображають функції програмних продуктів (ПП) з СПП разом з їх даними та...
Збережено в:
| Дата: | 2013 |
|---|---|
| Автори: | , |
| Мова: | Ukrainian |
| Опубліковано: |
Інститут програмних систем НАН України
2013
|
| Назва видання: | Проблеми програмування |
| Теми: | |
| Онлайн доступ: | http://dspace.nbuv.gov.ua/handle/123456789/86689 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Цитувати: | Підхід до побудови об’єктно-компонентної моделі сімейства програмних продуктів / К.М. Лавріщева, О.О. Слабоспицька // Проблеми програмування. — 2013. — № 4. — С. 14-24. — Бібліогр.: 13 назв. — укр. |
Репозитарії
Digital Library of Periodicals of National Academy of Sciences of Ukraine| id |
irk-123456789-86689 |
|---|---|
| record_format |
dspace |
| spelling |
irk-123456789-866892015-09-27T03:02:08Z Підхід до побудови об’єктно-компонентної моделі сімейства програмних продуктів Лавріщева, К.М. Слабоспицька, О.О. Методи та засоби програмної інженерії Модель властивостей Сімейства програмних продуктів (СПП) розвинуто об’єктно-компонентним методом проектування ПС (К.М. Лавріщева, В.М. Грищенко). Для опрацювання виявлених обмежень моделі її подано графом складних об’єктів, що відображають функції програмних продуктів (ПП) з СПП разом з їх даними та відношеннями варіантного підпорядкування й залежності. Його конкретизовано графами: інтерфейсних об’єктів (для формалізації взаємодії функцій), інтерфейсів та компонентів повторного використання (КПВ), що реалізують інтерфейси. Показано, що відображення між графами – ізоморфізми алгебраїчних моделей, які зіставляють властивостям ПП його реалізацію збіркою КПВ – образів властивостей. Графи й відображення поєднано в інтегрованій об’єктно-компонентній моделі СПП. Надано її переваги для виведення варіантів ПП, відстеження варіабельності й підтримки еволюції СПП. 2013 Підхід до побудови об’єктно-компонентної моделі сімейства програмних продуктів / К.М. Лавріщева, О.О. Слабоспицька // Проблеми програмування. — 2013. — № 4. — С. 14-24. — Бібліогр.: 13 назв. — укр. 1727-4907 http://dspace.nbuv.gov.ua/handle/123456789/86689 004.4 uk Проблеми програмування Інститут програмних систем НАН України |
| institution |
Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| collection |
DSpace DC |
| language |
Ukrainian |
| topic |
Методи та засоби програмної інженерії Методи та засоби програмної інженерії |
| spellingShingle |
Методи та засоби програмної інженерії Методи та засоби програмної інженерії Лавріщева, К.М. Слабоспицька, О.О. Підхід до побудови об’єктно-компонентної моделі сімейства програмних продуктів Проблеми програмування |
| description |
Модель властивостей Сімейства програмних продуктів (СПП) розвинуто об’єктно-компонентним методом проектування ПС (К.М. Лавріщева, В.М. Грищенко). Для опрацювання виявлених обмежень моделі її подано графом складних об’єктів, що відображають функції програмних продуктів (ПП) з СПП разом з їх даними та відношеннями варіантного підпорядкування й залежності. Його конкретизовано графами: інтерфейсних об’єктів (для формалізації взаємодії функцій), інтерфейсів та компонентів повторного використання (КПВ), що реалізують інтерфейси. Показано, що відображення між графами – ізоморфізми алгебраїчних моделей, які зіставляють властивостям ПП його реалізацію збіркою КПВ – образів властивостей. Графи й відображення поєднано в інтегрованій об’єктно-компонентній моделі СПП. Надано її переваги для виведення варіантів ПП, відстеження варіабельності й підтримки еволюції СПП. |
| author |
Лавріщева, К.М. Слабоспицька, О.О. |
| author_facet |
Лавріщева, К.М. Слабоспицька, О.О. |
| author_sort |
Лавріщева, К.М. |
| title |
Підхід до побудови об’єктно-компонентної моделі сімейства програмних продуктів |
| title_short |
Підхід до побудови об’єктно-компонентної моделі сімейства програмних продуктів |
| title_full |
Підхід до побудови об’єктно-компонентної моделі сімейства програмних продуктів |
| title_fullStr |
Підхід до побудови об’єктно-компонентної моделі сімейства програмних продуктів |
| title_full_unstemmed |
Підхід до побудови об’єктно-компонентної моделі сімейства програмних продуктів |
| title_sort |
підхід до побудови об’єктно-компонентної моделі сімейства програмних продуктів |
| publisher |
Інститут програмних систем НАН України |
| publishDate |
2013 |
| topic_facet |
Методи та засоби програмної інженерії |
| url |
http://dspace.nbuv.gov.ua/handle/123456789/86689 |
| citation_txt |
Підхід до побудови об’єктно-компонентної моделі сімейства програмних продуктів / К.М. Лавріщева, О.О. Слабоспицька // Проблеми програмування. — 2013. — № 4. — С. 14-24. — Бібліогр.: 13 назв. — укр. |
| series |
Проблеми програмування |
| work_keys_str_mv |
AT lavríŝevakm pídhíddopobudoviobêktnokomponentnoímodelísímejstvaprogramnihproduktív AT slabospicʹkaoo pídhíddopobudoviobêktnokomponentnoímodelísímejstvaprogramnihproduktív |
| first_indexed |
2025-07-06T14:13:34Z |
| last_indexed |
2025-07-06T14:13:34Z |
| _version_ |
1836907199654264832 |
| fulltext |
Методи та засоби програмної інженерії
© К.М. Лавріщева, О.О. Слабоспицька, 2013
14 ISSN 1727-4907. Проблеми програмування. 2013. № 4
УДК 004.4
К.М. Лавріщева, О.О. Слабоспицька
ПІДХІД ДО ПОБУДОВИ ОБ’ЄКТНО-КОМПОНЕНТНОЇ
МОДЕЛІ СІМЕЙСТВА ПРОГРАМНИХ ПРОДУКТІВ
Модель властивостей Сімейства програмних продуктів (СПП) розвинуто об’єктно-компонентним мето-
дом проектування ПС (К.М. Лавріщева, В.М. Грищенко). Для опрацювання виявлених обмежень моделі
її подано графом складних об’єктів, що відображають функції програмних продуктів (ПП) з СПП разом
з їх даними та відношеннями варіантного підпорядкування й залежності. Його конкретизовано графа-
ми: інтерфейсних об’єктів (для формалізації взаємодії функцій), інтерфейсів та компонентів повторного
використання (КПВ), що реалізують інтерфейси. Показано, що відображення між графами – ізомор-
фізми алгебраїчних моделей, які зіставляють властивостям ПП його реалізацію збіркою КПВ – образів
властивостей. Графи й відображення поєднано в інтегрованій об’єктно-компонентній моделі СПП.
Надано її переваги для виведення варіантів ПП, відстеження варіабельності й підтримки еволюції СПП.
Вступ
Стрімкий розвиток індустрії про-
грамного забезпечення в світі й Україні
наразі вимагає створення методологій ін-
дустріального виробництва ПП з гаранто-
вано високою якістю, низькою вартістю і
стислими термінами випуску, адаптовних
до змінних умов використання. Серед чис-
ленних концепцій, що опрацьовують цей
виклик, важливе місце займає інженерія
Сімейств ПП (Software Product Lines). Її
сутність – заміна автономних ПП (зазвичай
для конкретних замовників) СПП ринково-
го призначення для підтримки ділових
процесів певного цільового домену.
Сімейство – набір ПП з керованою
множиною спільних властивостей, відпо-
відних потребам кінцевих споживачів у
домені, які розробляються попередньо ви-
значеним способом із спільної множини
ресурсів повторного використання (РПВ)
[1]. Формальне подання складу і взає-
мозв’язків спільних і розбіжних властиво-
стей ПП традиційно зветься моделлю СПП
[2]. Саме вона визначає спосіб розроблен-
ня ПП і підтримує узгодженість властиво-
стей, РПВ і артефактів під час еволюції
СПП.
Серед сучасних моделей СПП одні-
єю з найперспективніших визнано модель
властивостей (feature model) FM [1–3]. Чи-
сленні дослідження фокусуються на аспек-
тах її застосування в СПП:
– відтворенні властивостей з коду
та специфікацій наявних ПП [4, 5];
– моделюванні властивостей на
підставі потреб споживачів і розробників СПП
з усіх функціональних сегментів домену [6];
– оцінюванні рівня відповідності
цим потребам спектра спільних і розбіж-
них властивостей ПП з СПП [7];
– керуванні варіантами ПП [8].
Узагальнення їх результатів наразі
висвітлює два обмеження ефективного за-
стосування FM в СПП: труднощі повтор-
ного використання фрагментів коду по-
в’язаних із властивостями та слабку відс-
тежуваність зв’язків між властивостями,
РПВ і артефактами. Вони стають особливо
критичними за сучасних умов індустріаль-
ного виробництва ПП: поповнення тради-
ційних характеристик якості ПП їх ситуа-
тивною адаптовністю до неочікуваних змін
потреб споживачів і умов використання та
зростання інтенсивності таких змін. Отже,
нині набуває актуальності проблема до-
опрацювання цих обмежень.
Для її вирішення є перспективним
розвиток FM об’єктно-компонентним ме-
тодом (ОКМ), створеним і апробованим
К.М. Лавріщевою, В.М. Грищенком для
проектування програмних систем у пара-
дигмі збіркового програмування [9]. Вод-
ночас, такий розвиток складає актуальну
проблему парадигми. Його реалізація й до-
слідження механізмів застосування отри-
маної моделі в СПП є метою роботи.
Стаття підсумовує результати дос-
ліджень за проектом «Розробка теоретич-
Методи та засоби програмної інженерії
15
ного фундаменту генеруючого програму-
вання та інструментальних засобів його
підтримки», виконаного в ІПС НАН Укра-
їни під керівництвом доктора фізико-
математичних наук, професора К.М. Лав-
ріщевої [10].
Сутність об’єктно-компонентного
розвитку моделі властивостей
Сутність пропонованого підходу
полягає у фіксації цільових вимог до моде-
лі СПП, що сприяють доопрацюванню об-
межень FM із збереженням її відомих пе-
реваг [1–3, 6, 7], та реалізації вимог у фор-
мованій моделі.
На підставі аналізу результатів за
основними напрямками досліджень FM
[1–8] пропонується низка вимог:
а) відтворення FM з наявних ПП (їх
первинного коду або специфікацій);
б) узгодження відтвореної FM з по-
точними потребами в ПП усіх учасників
розроблення СПП в усіх функціональних
сегментах цільового домену;
в) підтримка автоматизованого ре-
факторингу наявних ПП для підвищення їх
якості та ефективності повторного викори-
стання й реверсної інженерії в СПП;
г) підтримка автоматизованого кон-
струювання ПП з СПП з оптимальним по-
вторним використанням ресурсів (РПВ);
д) забезпечення адаптовності нових
ПП до передбачених і непередбачених змін
потреб споживачів та умов використання
споживачами і розробниками СПП;
е) придатність до узгодженої автома-
тизованої актуалізації разом з усіма РПВ;
ж) відстежуваність взаємних впливів
на всі елементи моделі змін у властивос-
тях, РПВ та артефактах розроблення ПП;
з) підтримка трасовності робочих
продуктів процесу розроблення нових ПП:
від вимог до коду компонентів повторного
використання (КПВ), взаємодіючих у ПП.
Побудова й апробація моделі пе-
редбачає дев’ять послідовних кроків.
1. Зіставлення припустимим функ-
ціям ПП оброблюваних даних та форму-
вання об’єктної моделі: графа “складених”
властивостей з явно поданими точками
варіабельності, поєднаного зв’язками пере-
творюваності з графом інтерфейсних
об’єктів, що описують взаємодію
перетворюваних функцій за допомогою
зіставлених їм даних.
2. Формування інтерфейсної моделі
– виокремлення інтерфейсів взаємодії
функцій за допомогою даних та впоряд-
кування їх згідно з відношеннями між
“складеними” властивостями в об’єктній
моделі, які зіставляють точкам варіабель-
ності варіабельні інтерфейси.
3. Перетворення інтерфейсної мо-
делі в компонентну – зіставлення кожному
інтерфейсу програмного компонента пов-
торного використання (КПВ), де він є
вхідним.
4. Запровадження узгоджених базо-
вих операцій композування й декомпозиції
на об’єктах – складених властивостях – та
КПВ.
5. Поєднання об’єктної, інтерфейс-
ної, компонентної моделей в інтегрованій
об’єктно-орієнтованій моделі СПП.
6. Подання основних артефактів
процесу розроблення ПП вкладеними
підграфами інтегрованої моделі.
7. Запровадження узгоджених ком-
позицій базових операцій над об’єктами
та КПВ на підтримку формування нових
ПП як різнорідних варіантів ПП, що вже
наявні.
8. Розвиток механізмів застосуван-
ня інтегрованої моделі СПП у процесі його
розроблення.
9. Створення технології розроблен-
ня СПП, керованого інтегрованою об’єкт-
но-компонентною моделлю, та її апробація
в середовищі інструментально-технологіч-
ного комплексу ІПС НАНУ [10].
Формальний опис об’єктно-
компонентної моделі СПП
Об’єктна модель СПП. Для побу-
дови об’єктної моделі застосовується
об’єктний аналіз – перша фаза ОКМ [9].
Його мета – подання цільового домену
СПП множиною взаємодіючих об’єктів з
властивостями, достатніми для другої фази
ОКМ – апріорної ідентифікації необхідних
КПВ та способу їх композування в ПП.
Аналіз полягає у послідовному фо-
рмуванні чотирьох рівнів подання домену:
Методи та засоби програмної інженерії
16
1) узагальнюючого – як множини
об’єктів із цілком визначеною поведінкою;
2) структурного – графом об’єктів,
утвореним їх зв’язками “частина-ціле”;
3) характеристичного – графом
об’єктів, доповнених предикатами їх влас-
тивостей, істотних для проектування ПП;
4) поведінкового – індукованим
графом взаємозв’язків між станами
об’єктів.
Склад і взаємозв’язки рівнів 1)–4)
для СПП показано на рис. 1.
o11
Функції СПП
l12
l11
l13
...
(O1, E1)
Дані СПП
l22l21
...
(O2, E2)
R4
R3
...
l23
Граф FO
R5
(o11,l22)
СПП
(l12,l21)(l11,l22) (l13,l21)(l12,l22)
...o31
СПП
l32l31 l34l33
Граф IO
o11
o11
Граф функцій
l12 l1n
...
l11
o11
Граф даних
l12 l13
...
l11
o11 ...
(O1, E1) (O2, E2)
Об’єкти функцій (O1)
o11 l11 ...... l11
Об’єкти даних (O2)
o1n
l31
Зв’язки
перетворюваності TR
I.Узагальнюючий рівень
II. Структурний рівень
III. Характеристичний рівень
IV. Поведінковий рівень
Рисунок 1. Об’єктний аналіз цільового
домену для СПП
Згідно з рисунком, на узагальнюю-
чому рівні виокремлено класи об’єктів, що
подають два типи варіабельних властивос-
тей ПП з СПП – їх функції (O1) та оброб-
лювані дані (O2). На наступному рівні на
множинах O1, O2 встановлено властиві FM
синтаксичні відношення [5] безумовного
(R1) і варіантного (R2) підпорядкування та
обмеження наслідку (R3), зіставлення (R4)
й виключення (R5):
Et = i=1,…,5 Rti
2
Ot, t =1, 2. (1)
Далі, на характеристичному рівні,
на підтримку вимог конструктивності а)–е)
функцію o1O1 подано кортежем сигнатур
методів її реалізації M(o1), а об’єкт даних
o2O2 – кортежем D(o2) ознак певних типів
[2], оброблюваних M(o1). Для кожної фун-
кції o1O1 задані обмеження щодо даних
E12 = i=3,4,5Ri O1O2, (2)
розглядувані як додаткові властивості o1 і
показані на рис. 1 штрих-пунктирною,
штриховою і точковою лініями.
Нарешті, на поведінковому рівні
сформовано двобічні зв’язки перетворю-
ваності складених властивостей (o1,o2)|
o1R3R4o2 в інтерфейсні об’єкти o3O3, які
підтримують (варіантні) взаємодії між фу-
нкціями ПП з СПП за допомогою даних.
Стан o3 подається парою M(o1), D(o2). Ві-
дношення (1), (2) індукують відношення E3
на множині O3, перетворюючи її у граф
IO = (O3,E3), E3 = i=1,…,5R3i. (3)
Умовами коректності аналізу є:
1) відсутність в елементарних фун-
кцій (листків графа (O1,E1)) спільних мето-
дів, а в елементарних об’єктів даних (лист-
ків (O2,E2)) – відповідно, спільних ознак;
2) o1O1 o2O1| o1R3o2o1R4o2;
3) o1R3R4o2 (o1R5o2);
o1R3o2(o
*
1,o
*
2)| o
*
1Rio2o1Rio
*
2, i=3, 4.
Для відношень Ri (1), (2) пропону-
ється об’єктно-орієнтована конкретизація.
Означення 1. Будемо говорити, що
otiOt, otjSGOt\{oti}, t = 1, 2 пов’язані:
1) безумовним підпорядкуванням
(otiRt1otj), якщо реалізація в ПП об’єкта oti
випливає з реалізації otj:
M(o1i) = {M(o1j),o1iR11o1j}; (4)
D(o2i) = {D(o2j), o2iR21o2j};
M(o1i) = Сhm,n({M(o1j),o1iR11o1j}); (5)
D(o2i)=Сhm,n({D(o2j), o2iR21o2j});
2) (m,n)-варіантним підпорядкуван-
ням (otiRt2(m,n)otj, 0 m n < |Ot|), якщо
Методи та засоби програмної інженерії
17
реалізація в ПП об’єкта oti випливає з од-
ночасної реалізації від m до n елементів
SG, де Сhm,n(X) – операція вибору не мен-
ше m і не більше n елементів множини Х.
Об’єкт oti назвемо точкою варіабе-
льності, а otj – варіантом її реалізації в ПП;
3) обмеженням зіставлення R3
2
O1+
2
O2+O1O2, якщо пов’язані ним
об’єкти мають реалізуватися в ПП одноча-
сно. Зокрема, o1R3o2 означає, що задане
відношення RL(o1,o2) зіставлення кожній
унікальній змінній з сигнатур методів
M(o1) ознаки з D(o2), і тільки такі пари мо-
жуть реалізуватися в ПП;
4) обмеженням потреби R4
2
O1 +
+
2
O2+O1O2, якщо реалізація першого
об’єкта потребує реалізації другого, тобто
RL(o1,o2j), задані для всіх o2j, зіставляють
змінним з M(o1) всі припустимі ознаки з
D(o2);
5) обмеженням виключення R5
2
O1+
2
O2+O1O2, якщо реалізація
першого об’єкта зумовлює неможливість
реалізації другого. Зокрема, o1R5o2 означає,
що задане відношення зіставлення уніка-
льним змінним з сигнатур M(o1) ознак з
D(o2), заборонених до використання в ПП.
Зауваження 1. Базовими формами
варіантного підпорядкування є: опціональ-
не (0,1); альтернативне (1,1); опціонально-
варіантне (0;n); варіантне (1,n).
Пропонований спосіб формування
інтерфейсних об’єктів та введення індуко-
ваних відношень між ними R3i (5) фіксує
Означення 2. Нехай O
*
={(o1,o2) ||
R3o2o1R4o2} – множина складених власти-
востей ПП з СПП. Зв’язки перетворювано-
сті задаються відображенням
tr: O
*
O3, tr(o
*
) = M(o1), D(o2). (6)
Мають місце відношення:
o3iR33o3j, якщо методи M(o1j), M(o1i)
реалізуються в ПП одночасно;
o3iR34o3j, якщо реалізація методів
M(o1i) потребує реалізації M(o1j);
o3iR35ko3j, якщо реалізація методів
M(o1i) унеможливлює реалізацію M(o1j).
o3iR31o3jM(o1j)M(o1i) (M(o1j)=M(o1i)
D(o2j)D(o2i)); (7)
o3iR32(m,n,p,q)o3j Сhm,n(M(o1j))M(o1i)
(M(o1j)=M(o1i)Сhp,q(D(o2j))D(o2i)),
o3i = M(o1i),D(o2i), o3j = M(o1j),D(o2j)O3.
Зауваження 2. Послідовна декомпо-
зиція виразу (6) згідно з виразами (4) і (5)
дозволяє подати його в термінах елемента-
рних функцій і даних – листків lt Lt Ot
графів (Ot,Et), t=1,2:
tr(o1,o2) = M(l1),l1ID1o1;
Сh0,1(M(l1)),l1IV1o1;
D(l2), l2ID2o1; Сh0,1(D(l2)),l2IV2o2 ; RLL =
= l3, l3ID3o3; Сh0,1(l3), l3IV3o3,
де IDt,IVtOtLt, t=1,2,3 – відношення опо-
середкованого безумовного й варіантного
підпорядкування, що означають наявність
в (Ot,Et) гілки між rt і lt, утвореної Rt1 і, від-
повідно, хоча б однією дугою Rt2(m,n);
RLL – відношення, індуковане на
L
*
={(l1,l2)|l1R3l2l1R4l2} відношенням
RL(o1,o2).
Вигляд отриманої об’єктної підмо-
делі встановлює
Означення 3. Об’єктна підмодель –
орієнтований зв’язний граф, у якому коре-
нева вершина (r) задає ім’я СПП, а підгра-
фи об’єктів-властивостей FO (3), (4) та ін-
терфейсних об’єктів IO (5), (7) поєднані
зв’язками перетворюваності TR (6):
OМ = r; FO; TR; IO;
FO = O1O2, E1E2E12; (8)
TR = {(o
*
,tr(o
*
)), o
*
= (o1,o2)O
*
}.
У виразі (5) підграф FO відіграє
роль традиційної FM [5], надаючи об’єкт-
не подання меж СПП (scope), тобто складу
і взаємозв’язків всіх припустимих функ-
цій і даних у ПП з СПП. Однак FO деком-
позує ці функції до методів, змінних і еле-
ментів даних, необхідних для їх реалізації
у ПП методом компонентного програму-
вання, у вигляді графa складених власти-
востей (O
*
, E
*
). Підграф IO конструктиві-
зує це подання на підтримку вимог а)–е)
для подальшого відображення в інтерфей-
сній моделі. Спосіб встановлення взаємно-
однозначної відповідності між O
*
та O3 ви-
світлює
Лема 1. Нехай R
*
k
2
O
*
,
k = 1,...,5, oi
*
= (o1i,o2i), oj
*
= (o1j,o2j)O
*
та
oi
*
R
*
1oj
*
o1iR11o1j(o1i = o1jo2iR21o2j);
Методи та засоби програмної інженерії
18
oi
*
R
*
2(m,n,p,q)oj
*
(o1iR12(m,n)o1j)
(o1i=o1u o2iR22(p,q)o2j); (9)
oi
*
R
*
koj
*
o1iR1ko1j, k = 3,4,5.
Відображення tr (6) є ізоморфізмом
алгебраїчних моделей g
*
, R
*
i(g
*
), i=1,...,5
(9) і g3, R3i(g3), i=1,...,5 (7) типів
2,2,2,2,2,
де gO
*
, g3={tr(o
*
),o
*
O
*
};
R
*
i(g
*
), R3i(g3) – обмеження R
*
i і R3i
на g
*
і g3 відповідно.
Істинність леми випливає з зістав-
лення виразів (7), (4), (5) та (9).
Наслідок. Для gO
*
відображення tr
(6) – ізоморфізм моделей g
*
,E
*
(g
*
) та
g3,E3(g3) типу 2, де E3(g3) = i=1,…,5
R3i(g3); E
*
(g
*
) = i=1,…,5 R
*
i(g3).
Лема 1 уможливлює ізоморфне ві-
дображення графа складених властивостей
(O
*
,E
*
) (9) в інтерфейсну підмодель – дру-
гий складник формованої об’єктно-
компонентної моделі СПП (2).
Інтерфейсна модель. Виходячи з
визначення інтерфейсу в об’єктно-
компонентному методі [2], для побудови
інтерфейсної моделі пропонується відо-
браження , що відокремлює від інтерфей-
сних об’єктів o3O3 (3), (6) (див. рис. 1)
підтримувані ними інтерфейси int(o3)IN і
впорядковує їх згідно з відношеннями між
“батьківськими” об’єктами o3.
Опис інтерфейсної моделі надає
Означення 4. Інтерфейсна модель
СПП, об’єктною моделлю якого є OM (8),
– орієнтований зв’язний граф інтерфейсів з
інтерфейсних об’єктів o3O3:
IM = (IN,EI), EI = i=1,…,5RIk; (10)
: (O3,E3) IM, o3 = tr(o1,o2);
(o3) = in = id.in,M(o1), D(o2),RL.in; (11)
ini RIk inj
-1
(ini)R3k
-1
(inj),
де id.in – унікальне ім’я інтерфейса;
RL.in – відношення зіставлення
змінним з сигнатур M(o1) ознак з D(o2).
Зауваження 3. Вираз (11) свідчить,
що композиція відображень tr (8) та
= tr: g
*
, E
*
(g
*
) gi, EI, gi IN. (12)
є ізоморфізмом алгебраїчних моделей.
Таким чином, інтерфейсна підмо-
дель надає еквівалентне конструктивне пе-
ретворення об’єктного подання МХ у сис-
тему взаємопов’язаних інтерфейсів inIN
(10), що забезпечують взаємодію функцій
ПП. Для кінцевої реалізації методів з in у
ПП з СПП пропонується зіставлення in
єдиного програмного компонента повтор-
ного використання (КПВ), призначеного
для його підтримки в середовищі експлуа-
тації ПП. У цього КПВ єдиним вхідним
інтерфейсом має бути in, а вихідними –
інтерфейси, підпорядковані in у IM.
Зважаючи на посередницьку роль
IM у формованій моделі СПП, операції над
її елементами не запроваджуються.
Компонентна модель. Згідно з
формальним визначенням КПВ [2], вигляд
формованої моделі надає
Означення 5. Компонентна підмо-
дель СПП, інтерфейсною підмоделлю яко-
го є IM (10), – орієнтований зв’язний граф
КПВ, кожний з яких реалізує один, і тільки
один інтерфейс inIN за допомогою відо-
браження
:(IN,EI)CM=(C,EC),EC=i=1,…,5RCk; (13)
(in) =c= id.in, II.с, (S.с,Ch.c), IO.с;
II.с=in\idmch= M(o1),D(o2),mch,RL.in;
IO.с={inj\id, inRI1inj}
{inj\id,inRI2(m,n,p,q)inj};
сi RСk сj
-1
(ini)R3k
-1
(inj), (14)
де id.in – унікальне ім’я КПВ, успадкова-
не від підтримуваного інтерфейса in (11);
II.с і IO.с – вхідний інтерфейс і
множина вихідних інтерфейсів c;
mch – допоміжний метод, що забез-
печує вибір одного з припустимих варіан-
тів inj реалізації варіабельного інтерфейсу
in (inRI2(m,n,p,q)inj);
S.с – множина програмних реаліза-
цій вхідного інтерфейсу II.с.
Зазначимо, що у виразі (14) і далі
вилучено “технічні” інтерфейси керування
екземплярами КПВ та визначення систем-
них сервісів його взаємодії з компонент-
ним середовищем [2], оскільки їх дослі-
дження істотно виходить за межі роботи.
Зауваження 4. Згідно з виразом (14),
відображення також є ізоморфізмом ал-
Методи та засоби програмної інженерії
19
гебраїчних моделей. Елементарним інтер-
фейсам (листкам IM) il відповідають базові
КПВ сl=(il)LC:
II.cl=IO.cl=M(l1),D(l2),RL.il, S.lс1S.lс2=,
де S.lс – множина фрагментів предме-
тно-орієнтованого виконуваного коду пев-
ною мовою програмування, що разом реа-
лізують методи M(l1) на даних D(l2) згідно
з відношенням RL.il. На відміну від S.lс,
реалізації складних КПВ з S.с, сLC не є
предметно-орієнтованими, а тільки забез-
печують (віддалений) виклик методів з S.lс
для lс, опосередковано підпорядкованих
КПВ с у підмоделі CM (13), і надаються
компонентним середовищем розроблення
(CORBA, MS.Net, J2EE тощо).
Оскільки КПВ сC мають єдиний
вхідний інтерфейс II.с (14), виконуються
умови їх цілісності та взаємодії підпоряд-
ковуючого ci й підпорядкованого cj [2]:
ciRC1cjciRC2(m,n,p,q)cjII.сjIO.сi,
і всі реалізації з S.сj (14) підтримують II.с.
Зіставлення виразів для II.с і IO.с у
(14), підстановка виразу (10) для інтерфей-
су in та врахування зауваження 2 дозволяє
позбавитись від елементів інтерфейсної
моделі у виразі (14).
Лема 2. Вхідний інтерфейс КПВ
сC являє собою кортеж інтерфейсів, без-
умовно та варіантно підпорядкованих с на
довільному рівні в CM:
II.c =II.сj,сRC1cj; II.сj,сRC2(m,n,p,q)cj =
=…=II.сl, сRC1cl; II.сl, сRC2(0,1,0,1)cl;
II.сl,сRC2(0,1,0,0)cl; II.сl,сRC2(0,0,0,1)cl.
Отже, граф вхідних інтерфейсів II.c, упо-
рядкованих згідно з відношеннями між са-
мими сC, збігається з інтерфейсною мо-
деллю IM (10).
Інтеграція моделей. Здійснення
п’ятого й шостого кроків пропонованого
підходу на підтримку вимог а)–е) надає
Означення 6. Інтегрована об’єкт-
но-компонентна модель СПП – це пара
PL = AS; MOD; , (15)
MOD = (OM,); (IM,); CM ,
де AS – умови коректності об’єктного
аналізу 1)-4);
OM, IM, CM – відповідно, об’єктна,
інтерфейсна та компонентна моделі СПП;
(12) і (14) – спеціальні відобра-
ження між елементами OM і IM та, відпо-
відно, IM і СМ.
Запропонована інтегрована модель
MOD (15) відповідає сформульованим ви-
могам конструктивності, надаючи спосіб
уніфікованого розроблення всіх ПП з СПП
у руслі парадигми компонентного програ-
мування. Саме, вона уможливлює узго-
джене об’єктно-компонентне модельне по-
дання основних артефактів art цього про-
цесу як відповідних підграфів підмоделей
MOD, являючи собою розвиток моделі ва-
ріабельності артефактів [11]. Такими арте-
фактами є: потреби споживачів СПП у фу-
нкціях ПП (t=1); вимоги до ПП (t=2); про-
ект його компонентної архітектури (t=3);
специфікація (t=4) й програмна реалізація
(t=5) окремого КПВ у ній; власне ПП (t=6).
Послідовні перетворення артефактів art
впродовж розроблення ПП відображають-
ся в їх об’єктно-компонентних моделях
MAt і відстежуються за допомогою ізомор-
фізмів (12) і (14) з MOD.
Позицію art у MOD встановлює
Означення 7. Нехай PL (15) – мо-
дель СПП. Об’єктно-компонентна модель
артефакта СПП art має вигляд
,6,))((,))(();(
);,();,(;
;5)),(())((
,))(();();,();,(;
;4),()(
)16(,)();,();,(;
;3,)(
,)();,();,(;
;2),,(
,),();,(;
;1,);;(
***
21
*
212
**
**
21
*
215
**
*
21
*
214
*
*
21
*
212
***
21
*
212
21211
tCMggg
gggggid
tgo
oooooooid
tgo
ooooooid
tIMg
ggggggid
tEOg
gggggid
tOOggid
MAt
де idt – унікальний ідентифікатор моделі
art (збіг ідентифікаторів для t=2,3,6 пояс-
нюється тим, що модель вимог MA2 повні-
Методи та засоби програмної інженерії
20
стю визначає моделі проекту архітектури
MA3 і самого ПП MA6, тоді як модель пот-
реб MA1 може конкретизуватися різними
MA2, а моделі специфікації та реалізації
КПВ призначені для багаторазового вико-
ристання у різних ПП).
Модель (16) уніфіковано подає всі
різнотипні артефакти СПС: ресурси повто-
рного використання (РПВ); наразі створю-
вані; потенційно необхідні для реалізації
ПП з СПП та різноаспектні зв’язки між
ними. Разом із “материнською” моделлю
СПП MOD (15) вона забезпечує також тра-
совність довільного артефакта як “догори”,
до підтримуваних ним вимог і потреб, так і
“донизу”, до КПВ, що нададуть його про-
грамну реалізацію. При цьому точці варіа-
бельності в артефактах довільного типу та
її варіанту явно зіставляються їх прообрази
“згори” та образи “знизу”. Додатково ви-
никає можливість повноаспектного аналізу
“що, якщо” стосовно впливу будь-яких
змін – у репозиторії КПВ, усередині під-
моделей, у потребах споживачів – як на
модель MOD, так і на портфелі створюва-
них та запланованих ПП.
Для окремого ПП модель (16) форма-
лізує спектр змістовних рішень з конкре-
тизації моделі потреб MA1 у вигляді моделі
вимог MA2. Вона сприяє зосередженню ар-
хітекторів СПП і розробників окремих ПП
на креативному прийнятті рішень, знижу-
ючи ризики внесення дефектів під час ру-
тинного “ручного” перетворення вимог у
ПП завдяки його автоматизації (звичайно,
за наявності КПВ з необхідними моделями
MA5 у репозиторії СПП). З іншого боку,
модель специфікації КПВ MA4 надає підс-
тави для їх паспортизації.
Нарешті, модель (16) є підставою
для формального опису компонентно-
орієнтованого ПП.
Означення 8. Нехай PL (15) – мо-
дель СПП. ПП з СПП, який реалізує вимо-
ги з моделлю MA2= id2; (g1,g2);g
*
(g1, g2) –
це множина КПВ, що взаємодіють між со-
бою згідно з підграфом ((g
*
)) компонен-
тної моделі CM (13), (14) зі складу PL. Під-
граф ((g
*
)) зветься компонентною конфі-
гурацією ПП.
Якщо модель MA2 включає точку
варіантності, ПП зветься варіантним.
Корисні властивості моделі СПП.
З означень (15), (16) випливає низка твер-
джень.
Лема 3. Відношення безумовного
та варіантного підпорядкування на множи-
нах об’єктів, інтерфейсів і КПВ є лінійни-
ми порядками.
Теорема 1. Нехай PL (15) – модель
СПП. Композиція відображень (12) і (14)
= є ізоморфізмом між об’єктною та
компонентною моделями СПП як алгебра-
їчними моделями типу 2;2;2;2;2.
Отже, елементарний об’єкт – листок
графа (O
*
, R
*
) (3), (8) lO
*
реалізується
єдиним базовим КПВ (14) – листком у
графі CM, вхідний і вихідний інтерфейси
якого збігаються з елементарним інтерфей-
сом, властивим l. Для реалізації вузлів
графа (O
*
, R
*
) запровадимо необхідні опе-
рації над КПВ.
Означення 9. Результат операції
конфігурування КПВ x, y С з компонент-
ної моделі (13), (14) – складний КПВ xy
С, названий їх конфігурацією, вхідний
інтерфейс якого – покоординатне об’єд-
нання вхідних інтерфейсів КПВ x і y як ко-
ртежів, а множини вихідних інтерфейсів і
реалізацій – об’єднання однойменних
множин у складі x і y.
З означення 9 випливає
Лема 4. Кожний КПВ – вузол у
графі компонентної моделі CM (13), (14) –
являє собою конфігурацію всіх КПВ, під-
порядкованих йому в CM на довільному
рівні, жодний з яких не підпорядкований
іншому.
Наслідок. Нехай FC – множина кон-
фігурацій довільних підмножин базових
КПВ у компонентній моделі CM без по-
вторюваних елементів, VC – множина вуз-
лів з CM. Тоді |FC|<, і VC FC.
Означення 10. Результат операції пе-
ретину КПВ x, yFC – це КПВ xyFC,
вхідний інтерфейс якого – покоординатний
перетин (позначений символом ) вхідних
інтерфейсів x і y як кортежів, а множини
вихідних інтерфейсів і реалізацій – пере-
тини однойменних множин у складі x і y:
II.xy = II.x II.y;
IO.xy = IO.x IO.y; S.xy = S.x S.y. (17)
Методи та засоби програмної інженерії
21
Лема 5. Для результатів операцій
конфігурування та перетину (17) на FC ви-
конується умова цілісності згідно з ОКМ-
методом.
Теорема 2. Множина з операціями
FC; , – бульова решітка, а множина
FC; , , \, z, u – бульова алгебра типу
2,2,1, де нулем є КПВ-шаблон
z=;;, одиницею – “максимальний”
КПВ u, тобто конфігурація всіх базових
КПВ з CM, а операція \ є доповненням у
бульовій решітці:
vcFC vc (\vc) = u; vc (\vc) = z.
Зауваження 5. Визначимо на FC від-
ношення підпорядкування :
(vci, vcj)FC (vci,vcj)(vckFC |
(vci,vck)) vci = vckvcj. (18)
Означення (18) і означення 1 збіга-
ються на множині VC.
Означення 11. Варіантна компонен-
тна ПС (ВПС) з функціями, поданими до-
вільним підграфом F з об’єктної моделі
СПП (15) – реалізація КПВ id5(F),
об’єктною моделлю якого є F, а в компо-
нентній моделі базові КПВ реалізують
елементарні функції зі складу F.
Теорема 3. ВПС з функціями, пода-
ними довільним підграфом F з об’єктної
моделі СПП (15), є реалізацією одного, й
тільки одного, КПВ vcFC, що є конфігу-
рацією базових КПВ, прототипи яких –
елементарні функції зі складу F.
У термінах генеруючого програму-
вання об’єктна модель є поданням просто-
ру проблеми, компонентна – простору рі-
шень, а відображення = – генеруюча
модель ПП із заданими функціями, що об-
робляють задані дані.
Механізми використання
інтегрованої моделі СПП
Автоматизоване конструювання
продуктів у СПП. ПП із запитаними фун-
кціями створюються як нові або як варіан-
ти наявних (передбачені й довільні).
Нові ПП, що можуть бути довіль-
ними варіантами наявних, конструюються
за допомогою композиції запроваджених
операцій конфігурування та перетину на
підставі рамкових схем конфігурації: базо-
вої, видалення підкомпонентів, довільної
припустимої заміни.
Варіанти наявних продуктів ство-
рюються за допомогою операцій їх варіан-
тної та передбачувано-варіантної заміни на
підставі відповідних схем.
Для вибору способу, оптимального
за критерієм qQ = {час, витрати, якість},
розв’язуються задачі добору припустимої
множини схем відповідного типу та опти-
мізації на ній.
Композиція операцій довільної за-
міни визначає трансформаційну генеруючу
модель, решти – конфігураційну модель, а
їх композиція – гібридну модель [11].
Обґрунтоване контролювання рі-
вня варіабельності в СПП. Цей напрям
використання запропонованої моделі СПП
реалізується за допомогою трьох керова-
них нею механізмів: моделі обґрунтовано-
го оцінювання варіабельності; системи
операцій контролювання рівня варіабель-
ності; структури середовища розроблення
СПП та механізму вимог до операцій.
Вимоги до операцій включають [4]:
обґрунтованість – наявність підстав їх ви-
конання, зрозумілих для всіх учасників ро-
зроблення СПП; узгодженість – інформа-
ційну наступність і цільову непротиріч-
ність операцій (щодо всіх артефактів СПП
у всіх функціональних сегментах цільово-
го домену); трасовність – відстежуваність
зв’язків між точками варіантності й варіа-
нтами (на всіх рівнях реалізації варіабель-
ності в ПП та у всіх сегментах домену);
масштабовність – застосовність операцій
для СПП довільного призначення й обсягу;
візуалізовність точок варіантності, варіан-
тів та зв’язків між ними.
Інтегрована об’єктно-компонентна
модель СПП (15) визначає чотири наступні
складники інформаційного середовища:
репозиторій РПВ з обов’язковим включен-
ням КПВ, що підтримують елементарні
функції – листки графа OM; репозиторій
протоколів повторного використання ре-
сурсів (РПВ) (AP); множину робочих про-
дуктів наразі створюваних РПВ і ПП з
протоколами їх “локального” повторного
використання (IP); нову модель експертно-
аналітичного оцінювання варіабельності
Методи та засоби програмної інженерії
22
ПП з СПП (EV). Остання формує репози-
торій профілів варіабельності СПП – стру-
ктурованих обґрунтованих оцінок адекват-
ності стану СВС потребам всіх учасників
його розроблення у вигляді спеціальних
звітів (VP). Таким чином,
ENV = SV,AV; RP, AP, IP; EV; VP . (19)
Вираз (19) висвітлює основні типи
невідповідності наявної й запитаної варіа-
бельності:
1) “надлишковість” – наявність ар-
тефактів idtGt в SV і РПВ у RP, викорис-
тання яких під час розроблення ПП не від-
бувається або ж не окупається;
2) “неповнота” – відсутність арте-
фактів idtGt, t = 1,2,3, відображених у за-
питах до споживачів і розробників, що по-
дають істотні потреби у функціях і показ-
никах якості ПП;
3) “клони” – наявність артефактів і
РПВ, повністю взаємозамінних при ство-
ренні ПП;
4) “хибні обмеження” – наявність
артефактів idtGt в SV, які потребують
зняття/встановлення статусу точки варіан-
тності;
5) “хибні залежності” – наявність
підграфів рівня t, що потребують перепід-
порядкування і/або зміни типу залежності;
Призначенням операцій контролю-
вання варіабельності СПП є:
1) надання підстав для виконання
операцій еволюції СПП;
2) формування ретроспективи оці-
нок профілю варіабельності для її подаль-
шого опрацювання відомими методами
ідентифікації структури багатовимірних
кількісних і некількісних даних з метою
раннього прогнозування та аналізу чинни-
ків впливу.
На підтримку цього призначення
пропонується:
– динамічна актуалізація протоколів
РПВ і артефактів у момент їх використан-
ня;
– експрес-оцінювання рівня варіа-
бельності СПП, поданого структурованим
кортежем частотних оцінок термінальних
критеріїв з моделі EV;
– обґрунтоване оцінювання профі-
лю варіабельності СПП за моделлю EV;
– обґрунтоване оцінювання відпові-
дності варіабельності СПС пакету запитів
на ПП – на заданий момент і впродовж за-
даного терміну – за моделлю EV;
– відстеження динаміки профілю
варіабельності впродовж заданого терміну;
– вчасне виявлення проявів невід-
повідності варіабельності СПП поточним
потребам його розробників і споживачів
ПП та обґрунтоване оцінювання рівня її
критичності;
– вироблення рекомендацій з усу-
нення виявленої невідповідності:
– включення/вилучення/перепідпо-
рядкування графів властивостей і відпові-
дних їм артефактів;
– долучення/вилучення РПВ і базо-
вих КПВ;
– виявлення й опрацювання РПВ-
клонів.
Вимоги до EV з боку наведених
операцій обумовлюють перспективність її
формування за допомогою узгодженого
розвитку ортогональної моделі варіабель-
ності А. Мецгера [1, 4] та моделі COSVAM
[7]. Для цього з графів (15) і (16) вилуча-
ються вершини, що подають спільні влас-
тивостей всіх ПП з СПП, та їх нащадки за
відношеннями перетворюваності TR.
Отриманий тривимірний граф поділяється
на підграфи: точок варіантності (P), який
подає варіантні артефакти процесу розроб-
лення ПП з СПП; варіантів для цих точок
(V), що відображає припустимі способи
реалізації артефактів. Вершини графів P і
V пов’язуються збереженими зв’язками
варіантного підпорядкування і TR. В
“ортогональній” моделі, утвореній P і V,
виділяються двовимірні графи (Pt,Vt),
t=1,...,5, вершини яких – артефакти типу
t з P і з V. Графам (Pt,Vt) зіставляється тре-
тій вимір – структурована оцінка обумов-
леної ними варіабельності у шкалі відно-
шень або інтервалів (ESt).
Результуюча гібридна модель являє
собою п'ятирівневий трьохелементний ко-
ртеж, значення елементів якого і є де-
Методи та засоби програмної інженерії
23
кларованими підставами операцій еволю-
ції СПП:
;5,...,1),,(
;5,...,1),,(;;;
tTRVV
tTRPPESVPEV
t
tt
t
,
5,...,1,,
;5,...,1,,;;
;5,...,1,,;;
,
,
itNA
tpuparavaia
tmlplrlvlil
ES
ti
tttt
tttt
(20)
де il та ia – інтегральні рівні автономної
варіабельності в СПП та, відповідно, її
адекватності потребам всіх учасників про-
цесу розроблення СПП;
vlt і vat – проміжні рівні автономної
варіабельності в СПП та її адекватності,
обумовлені артефактами типу t (тобто
“верхні грані паралелепіпедів” (Pt,Vt));
rlt, plt і mlt – вкладені рівні передба-
ченої в моделі SV (1) і, відповідно, реалізо-
ваної в RP варіабельності, а також рівня
відповідності між ними;
rat, pat, put – вкладені рівні адекват-
ності заявленої та реалізованої варіабель-
ності потребам споживачів і розробників
ПП з СПП, а також ефективності викорис-
тання РПВ;
NAti – множини артефактів типу t, що
обумовлюють виявлену неадекватність ва-
ріабельності типу i.
Підтримка обґрунтованої автома-
тизованої еволюції СПП. Для даного на-
прямку операції контролювання рівня ва-
ріабельності замінено операціями узго-
дженої актуалізації СПП з метою усунення
невідповідностей 1)–5). Еволюція СПП ре-
алізується композицією узгоджених опе-
рацій над їх об’єктами з моделі SV і репо-
зиторію RP:
– долучення нового графа gnt до
об’єктної моделі СПП;
– вилучення підграфа idt з його на-
щадками за відношеннями перетворювано-
сті TRt і варіантного підпорядкування;
– аналогічне вилучення idt з пере-
підпорядкуванням його окремих нащадків;
– заміна заданого графа gnti іншим
графом gntj;
– підпорядкування графа gnti іншій
вершині idt в об’єктній і компонентній мо-
делях СПП;
– актуалізація відношень в
об’єктній, інтерфейсній та компонентній
моделях СПП (автономна та внаслідок
змін у репозиторії і складі підтримуваних
функцій і даних ПП).
Еволюція репозиторію RP включає:
– розроблення й долучення до RP
КПВ, який підтримує нову елементарну
функцію;
– доручення до RP КПВ, реалізація
якого є економічно виправданою;
– видалення РПВ та підтримуваних
функцій і робочих продуктів;
– видалення РПВ із збереженням
окремих функцій і/або робочих продуктів
Перспективними засобами реаліза-
ції запропонованої інтегрованої об’єктно-
компонентної моделі є спеціальні мови:
XVCL [8] та Common Variability Language,
стандартизована OMG [13].
Висновки
1. Запропоновано об’єктно-компо-
нентну конструктивізацію традиційної мо-
делі властивостей Сімейства програмних
продуктів на повноаспектну підтримку
всіх її функцій у процесі розроблення Сі-
мейства. Складні властивості програмних
продуктів з його складу – їх функції та об-
роблювані ними дані – взаємопов’язані в
об’єктній підмоделі, інтерфейси взаємодії
функцій подані в інтерфейсній, а відповід-
ні їм компоненти повторного використан-
ня – у компонентній підмоделі. Процеси
реалізації функцій і даних у продукті по-
даються ізоморфізмами між моделями.
2. Показано, що об’єктна та компо-
нентна підмоделі із запровадженими базо-
вими операціями об’єднання, перетину та
доповнення множин їх елементів є бульо-
вими решітками з одиницею – повним
об’єднанням всіх елементів та нулем – по-
рожнім елементом. Доведено, що відобра-
ження між ними є ізоморфізмом решіток з
унарним відношенням припустимості під-
множини складних властивостей (відпові-
дно, КПВ для них) в окремих продуктах.
Методи та засоби програмної інженерії
24
3. Запропоновано узгоджені об’єкт-
но-компонентні моделі основних артефак-
тів Сімейства – від вимог до коду продукту
– як підграфів моделі Сімейства,
пов’язаних відображеннями між її підмо-
делями. Надано композиції базових опера-
цій над моделями для автоматизованого
створення продуктів із заданими властиво-
стями та їх рефакторингу для врахування
передбачених і непередбачених змін вимог
та умов використання.
4. Окреслено механізми застосуван-
ня запроваджених моделей для обґрунто-
ваного моніторингу рівня варіабельності та
еволюції Сімейства.
5. Подальші дослідження включа-
ють:
– аналіз перспектив інтеграції за-
пропонованих моделей із численням змін-
ності (Choice Calculus, ) та сервісно-
компонентною архітектурою для створен-
ня розподілених продуктів, адаптовних до
передбачених і непередбачених змін;
– розроблення підходу до оптимі-
зації складу КПВ для заданих функцій та
даних;
– створення технології автомати-
зованого конфігурування таких КПВ у
продукт з подальшим розвитком макетного
зразка відповідного Конфігуратора;
– апробацію технології в середо-
вищі інструментально-технологічного ком-
плексу ІПС НАН України.
1. Clements P., Northrop L. Software Product
Lines: Practices and Patterns – Addison
Wesley, 2001.
2. Lee K., Kang K.C., Lee J. Concepts and
Guidelines of Feature Modeling for Product
Line Software Engineering // Proc.7th Int.
Conf. on Software Reuse: Methods,
Techniques, and Tools – London, Springer-
Verlag, 2002. – P. 62–77.
3. Acher M. et al. Support for Reverse
Engineering and Maintaining Feature Models
// VaMoS ’13, January 23–25, 2013, Pisa,
Italy.
4. She S. et al. Reverse Engineering Feature
Models // ICSE ’11, May 21–28, 2011,
Waikiki, Honolulu, HI, USA.
5. Berger T. et al. Feature-to-Code Mapping in
Two Large Product Lines, Software Product
Lines: Going Beyond, vol. 6287: Springer
Berlin / Heidelberg – 2010. – P. 498–499.
6. Czarnecki K. et al. Cool Features and Tough
Decisions: A Comparison of Variability
Modeling Approaches", Variability Modelling
of Software-intensive Systems (VaMoS),
Leipzig, Germany, ACM Press, 01/2012. –
P. 173–182.
7. Deelstra S., Sinnema M., Bosch J. Variability
assessment in software product families. In:
Information and Software Technology, vol. 51
Elsevier. – 2009. – P. 195–218.
8. Zhang H., Jarzabek S. An XVCL Approach to
Handling Variants: A KWIC Product Line
Example // APSEC, 2003. – P. 116–125.
9. Лаврищева Е.М., Грищенко В.Н. Сбороч-
ное программирование. Основы индустрии
программных продуктов // 2-изд. доп. и
перераб.– Киев: Наук. думка, 2009. – 372 с.
10. Лавріщева К.М. Інструментально-техноло-
гічний комплекс для розроблення й на-
вчання прийомам виробництва програмних
систем // Вісн. НАН України. – 2012. –
№ 3. – С. 67–79.
11. Лавріщева К.М. Теоретичні аспекти керу-
вання варіабельністю в сімействах програ-
мних систем // Вісн. КНУ ім. Т. Шевченка.
Сер.фіз.-мат. науки. – 2011. – № 1. – С. 45–
53.
12. Слабоспицька О.О. Підхід до підтримки
обгрунтованої еволюції сімейства програ-
мних систем TAAPSD. – 2012. – C. 45–49.
13. OMG. ad/09-12-03. Common Variability
Language RFP with ab changes, 2009.
Одержано 01.04.2013
Про авторів:
Лавріщева Катерина Михайлівна,
доктор фізико-математичних наук,
професор, завідувачка відділу
програмна інженерія,
Слабоспицька Ольга Олександрівна,
кандидат фізико-математичних наук,
старший науковий співробітник.
Місце роботи авторів:
Інститут програмних систем
НАН України,
03187, Київ-187,
проспект Академіка Глушкова, 40.
Тел.: (044) 526 4579.
Е-mail: ols.07@mail.ru
http://gsd.uwaterloo.ca/tberger
http://gsd.uwaterloo.ca/publications/view/312
http://gsd.uwaterloo.ca/publications/view/312
http://gsd.uwaterloo.ca/kczarnec
http://gsd.uwaterloo.ca/publications/view/430
http://gsd.uwaterloo.ca/publications/view/430
http://gsd.uwaterloo.ca/publications/view/430
http://www.informatik.uni-trier.de/~ley/db/conf/apsec/apsec2003.html#ZhangJ03
|