Approaches to configuring reusable assets

Approaches to configuring reusable assets

Problems and goals of the reusable assets configuration methods where identified. Proposed to use Domain Specific Language (DSL) for developing configuration tool and offered software product which extend software product line (SPL) development environment.Prombles in programming 2011; 4: 63-71

Збережено в:
Бібліографічні деталі
Дата:2025
Автор: Kolesnik, A.L.
Формат: Стаття
Мова:Ukrainian
Опубліковано: PROBLEMS IN PROGRAMMING 2025
Теми:
UDC 681.3.06
Онлайн доступ:https://pp.isofts.kiev.ua/index.php/ojs1/article/view/827
Теги: Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
Назва журналу:Problems in programming
Завантажити файл: Pdf

Репозитарії

Problems in programming
id pp_isofts_kiev_ua-article-827
record_format ojs
resource_txt_mv ppisoftskievua/4c/c077a9adf2e3c41437311ead80a5964c.pdf
spelling pp_isofts_kiev_ua-article-8272025-09-02T15:42:07Z Approaches to configuring reusable assets Підхід до конфігурування компонентів повторного використання Kolesnik, A.L. UDC 681.3.06 УДК 681.3.06 Problems and goals of the reusable assets configuration methods where identified. Proposed to use Domain Specific Language (DSL) for developing configuration tool and offered software product which extend software product line (SPL) development environment.Prombles in programming 2011; 4: 63-71 Визначено проблеми та цілі метода конфігурування компонентів повторного використання (ПВК). Запропоновано використовувати предметно-орієнтовану мову для створення програми конфігуратора та представлено діючий програмний продукт, який доповнює середовище розробки сімейства програмних систем (СПС).Prombles in programming 2011; 4: 63-71 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2025-09-02 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/827 PROBLEMS IN PROGRAMMING; No 4 (2011); 63-71 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 4 (2011); 63-71 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 4 (2011); 63-71 1727-4907 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/827/879 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-02T15:42:07Z
collection OJS
language Ukrainian
topic
UDC 681.3.06
spellingShingle
UDC 681.3.06
Kolesnik, A.L.
Approaches to configuring reusable assets
topic_facet
UDC 681.3.06

УДК 681.3.06
format Article
author Kolesnik, A.L.
author_facet Kolesnik, A.L.
author_sort Kolesnik, A.L.
title Approaches to configuring reusable assets
title_short Approaches to configuring reusable assets
title_full Approaches to configuring reusable assets
title_fullStr Approaches to configuring reusable assets
title_full_unstemmed Approaches to configuring reusable assets
title_sort approaches to configuring reusable assets
title_alt Підхід до конфігурування компонентів повторного використання
description Problems and goals of the reusable assets configuration methods where identified. Proposed to use Domain Specific Language (DSL) for developing configuration tool and offered software product which extend software product line (SPL) development environment.Prombles in programming 2011; 4: 63-71
publisher PROBLEMS IN PROGRAMMING
publishDate 2025
url https://pp.isofts.kiev.ua/index.php/ojs1/article/view/827
work_keys_str_mv AT kolesnikal approachestoconfiguringreusableassets
AT kolesnikal pídhíddokonfíguruvannâkomponentívpovtornogovikoristannâ
first_indexed 2025-09-17T09:24:39Z
last_indexed 2025-09-17T09:24:39Z
_version_ 1850409908820770816
fulltext Методи та засоби програмної інженерії 63 УДК 681.3.06 А.Л. Колесник ПІДХІД ДО КОНФІГУРОВАННЯ КОМПОНЕНТІВ ПОВТОРНОГО ВИКОРИСТАННЯ Визначено проблеми та цілі метода конфігурування компонентів повторного використання (ПВК). За- пропоновано використовувати предметно-орієнтовану мову для створення програми конфігуратора та представлено діючий програмний продукт, який доповнює середовище розробки сімейства програмних систем (СПС). Вступ Одним із сучасних підходів до роз- робки функціонально подібних Програм- них Систем (ПС) для різних Предметних Областей (ПрО) є їх розробка, як сімейства ПС з набору компонентів повторного ви- користання (КПВ). СПС – це сукупність ПС, які мають спільну множину характе- ристик, відповідних потребам певних фун- кціональних елементів ПрО, розрізняються способами застосування цих характерис- тик в окремих ПС і розробляються з вико- ристанням готових КПВ. Програмні сис- теми, члени СПС, створюються на основі загальної моделі СПС, яка реалізується згідно специфікацій вимог до члена ПС [1– 3]. КПВ СПС накопичуються в репозито- ріях інтегрованого середовища його роз- роблення, відбираються й адаптуються та складаються разом під час розроблення ПС. Спосіб функціонування та розвитку СПС полягає у безперервному поповненні репозиторію (бази) компонентів та їх адап- тації до потреб кожної нової ПС. Важливу роль у збиранні КПВ у СПС відігріває ва- ріабельність, тобто забезпечення здатності СПС до розширення, змінювання й налаш- тування або конфігурування нових ПС, що відповідають потребам ПрО. Варіабель- ність є ключовою властивістю розробле- них СПС і на всіх рівнях подання взаємо- пов'язаних ресурсів вона має утримуватися в необхідних і достатніх межах для забез- печення цілісності СПС, тобто має підля- гати керуванню. Аналіз теоретичних і практичних напрацювань у галузі розробки СПС (мов, методів та інструментів) показав, що увага більшою мірою приділяється забезпечен- ню варіантності в компонентах на окремих рівнях, а не підтримки прийняття рішень менеджерами при керуванні варіабельності СПС у процесі вибору наборів ПВК для створення з них ПС. Тобто, розробки но- вих моделей і методів, придатних для ке- рування варіабельністю ПС шляхом ство- рення конфігуратору для підтримки проце- су керування виконанням компонентів СПС у деякому діючому середовищі, а також для забезпечення змінюваності ком- понентів за точками варіантів. Ними мо- жуть бути вхідні описи КПВ або точки в середині компонента. Далі будуть розгля- датися поняття конфігуратору, підходи до їх побудови на множині готових КПВ та засоби використання. Загальні відомості про КПВ Моделі варіабельності включають в себе декілька типів ПВК, а саме: обов’язкові КПВ, тобто ті що присутні у всіх ПС даної СПС, необов’язкові КПВ, тобто ті що присутні лише в деяких ПС або існують в декількох варіантах, а також індивідуальні компоненти, ті що були створені на замовлення одного замовника і не плануються використовуватись в інших ПС. У продовж життєвого циклу тип КПВ може змінюватися. Наприклад, індивідуа- льні можуть отримати статус необ- ов’язкових, а необов’язкові статус обов’язкових. Будемо називати точками варіант- ності, точки в описі КПВ або ПС, де може існувати відмінність функціональності щодо іншої ПС, та точки, які прогнозуєть- ся для можливості зміни деяких функцій КПВ або ПС. Варіант – це окрема функці- ональність, яка відповідає точкам варіант- ності. В конкретному випадку варіантами є © А.Л. Колесник, 2011 ISSN 1727-4907. Проблеми програмування. 2011. № 4 Методи та засоби програмної інженерії 64 КПВ обов’язкового та не обов’язкового типів. Для конкретної точки варіантності задається залежність у вигляді ідентифіка- тора можливого асортименту або альтер- нативи варіанта. Обмеження – взаємовиключне або взаємодоповнююче використання одного варіанта з іншим. Тобто закладається пере- вірка на взаємовиключне використання КПВ в одній ПС або їх залежність одне від одного. Інженерія СПС складається з двох основних платформ: • Інженерія Домену – процес визна- чення та реалізації обов’язкових та необ- ов’язкових ПВК; • Інженерія Прикладень – процес створення ПС із КПВ. Саме тут окрім обов’язкових та необов’язкових знахо- дяться індивідуальні для кожної ПС ком- поненти. Існує багато різних підходів до представлення варіабельності. Вони відрі- зняються концепціями які характеризують інтеграцією варіабельності в ПВК. Конфігурування програмних об’єктів Керування конфігурацією ПС в СПС є багатогранною проблемою. У допо- внення до звичайних проблем керування розвитком програмної системи в період її життєвого циклу, СПС додає проблеми керування варіантністю КПВ у різних ПС в ПрО СПС. Розглянемо наступні цілі керу- вання конфігурацією ПС в СПС: • ідентифікація конфігурації, елемен- тів конфігурації та вихідних даних; • керування конфігурацією – реаліза- ція керованого процесу змін. Зазвичай це досягається шляхом створення так званого комітету керування змінами, основна фун- кція якого полягає в схваленні або відхи- ленні всіх запитів на зміни, які не були включені до початкового плану; • звітність конфігурації – облік і звіт- ність всієї необхідної інформації про стан процесу розробки ПС; • аудит конфігурація – гарантування того що ПС містить всю заплановану фун- кціональність у відповідності до докумен- тів специфікації, у тому числі вимог, архі- тектурних специфікацій та документації для користувача; • керування збіркою – процес керу- вання інструментами для побудови ПС; • керування процесами – гарантуван- ня дотримання запланованого процесу ро- звитку ПС; • керування навколишнім середови- щем – керування програмним та апаратним забезпеченням, на яких розміщена СПС; • робота в команді – полегшення вза- ємодії членів команди, яка працює над СПС; • відстеження дефектів – простежен- ня дефектів назад до вихідного коду. У галузі комп'ютерного програмно- го забезпечення, термін «збирання» відно- ситься до процесу перетворення вихідного коду в артефакти, іншими словами КПВ у випадку СПС, які можуть бути запущені на комп'ютері, або перетворені у код який виконується. Одним з кроків створення збірки є процес компіляції вихідного коду, де файли перетворюються в проміжний код або навіть у код що виконується – для простих програм. Для складних програм після компі- ляції (що виконується спеціальною про- грамою – компілятором) відбувається про- цес зв'язування (знаходження реального положення всіх функцій, позначених як зовнішні), що виконується спеціальною програмою – лінкером. Процес зв'язування являє собою заміну відносних адрес функ- цій зовнішніх бібліотек на реальні адреси, що будуть використовуватися програмою у процесі виконання. Для автоматизації цих процесів де- які компанії створюють програмні продук- ти конфігуратори. Конфігуратор – програ- мна система автоматизації та надання ко- ристувацького інтерфейсу для збирання ПС з набору існуючих КПВ у середовищі СПС. Але існує проблема загального пред- ставлення та формалізації конфігураторів. Розглянемо можливі теоретичні підходи для створення таких програм. Конфігуратор на основі діаг- рами характеристик. Автори [4, 5] пропонують діаграму характеристик як теоретичного базису для Методи та засоби програмної інженерії 65 конфігуратора. Розглянемо спочатку тео- ретичні аспекти а потім програмні засоби. Діаграми характеристик може бути представлена інструментами MS Visual Studio [6]. На рис. 1 показана діаграма ха- рактеристик СПС «браузер», яка відобра- жає її складові частини та залежності між ними. Розглянемо термінологію моделі характеристик у контексті СПС. Модель характеристик – компактне представлення всіх продуктів СПС з точки зору характеристик (функціональності). Модель характеристик візуально представ- ляється за допомогою діаграми характери- стик. Вона широко використовується в продовж всього процесу розробки ПС в СПС зазвичай як вхідні дані для виробниц- тва інших КПВ, таких як документи, архі- тектурні моделі, або фрагменти коду. Мо- дель характеристик це модель, яка визна- чає характеристики ПС їх залежностей та обмежень, як правило, у вигляді (дерев) діаграм характеристик або у вигляді таб- лиці можливих комбінацій. Діаграма характеристик – візуальне представлення моделі характеристик у ви- гляді дерева. Подання моделей характери- стик і варіабельності СПС демонструється на прикладі таблиці позначень їх елементів. Наприклад, предметна область бра- узеру має графічну нотацію діаграми хара- ктеристик з використанням наведених позначень елементів рис. 1. Але одна тільки діаграма характе- ристик не може підтримати цілий процес керування варіабельністю в СПС. Для цьо- го ще потрібно налагодити зв'язок діагра- ми із вихідним кодом, а також програмний інструмент, що дозволить підтримувати процес збору ПС з ПВК. У роботі [7] описано конфігуратор, принцип роботи якого засновано на діаг- рамах характеристик, рис. 2. Його метою є автоматизація та надання користувацького інтерфейсу для створення ПС. Аналоги роботи подібної системи можна зустріти на веб-сторінках виробників автомобілів або комп’ютерів, де користувачу надається можливість створити продукт з необхід- ною для нього функціональністю.   Рис. 1. Діаграма характеристик СПС браузера Методи та засоби програмної інженерії 66 Таблиця. Позначення діаграми характеристик Точка варіантності Варіант або КПВ обов’язкового типу. Варіант або КПВ необов’язкового типу або позначення індивіду- ального компонента. ––––––– Залежність варіантів від точки варіантності. Альтернативність варіантності відповідає декільком варіантам, лише один з них вноситься в ПС. Обмеження на використання варіантів. Рис. 2. Конфігуратор на основі діаграм характеристик Конфігуратор на основі DSL у середовищі VS.Net У продовж всієї історії розробки програмного забезпечення намагаються заповнити прогалину між вимогами та ре- алізацією рис. 3, а. Тобто, якимось чином автоматизувати розробку програмних сис- тем. Починаючи з 80-х років розробники використовують моделі для створення ПС рис. 3, б. Але через значну прогалину ін- струменти мають генерувати велику кіль- кість коду який важко читати і тестувати. Тоді з’являється ідея фроеймворку – абст- рагуватися від операційної системи і пред- ставити певну предметну область (домен). Для моделювання і керування доменами почали використовувати специфічні мови моделювання, наприклад, такі як регулярні вирази XML, XSLT, SQL. І все ж таки не можна сказати, що прогалина між вимога- ми та мовою моделювання значно змен- шилась рис. 3, в. Але використання взаємно пов’яза- них моделей доменів на різних рівнях абс- тракції у поєднанні з фреймворками збіль- шують рівень абстракції рис. 3, г, та при- бирають прогалину [4]. У рамках проекту ІІІ 1-07 створено програму конфігуратор, мета якої підтри- мати та спростити процес створення про- грамних компонентів та багаторазового їх використання для збору ПС. Методи та засоби програмної інженерії 67 Рис. 3. Еволюція використання моделей у розробці ПС У ролі DSL виступає технологія компанії Microsoft – Windows Workflow Foundation. Словником термінів даної мо- ви є звичайні інструкції технології WF та компоненти породжені цими інструкціями, рис. 4. На рис. 5 показана модель роботи конфігуратора. Літерами А та В позначені AppFabric (фабрика програмних систем) та Eclipce / TFS (репозиторії даних) відповід- но. Рис. 4. Інтерфейс конфігуратора Методи та засоби програмної інженерії 68 AppFabric *.exe*.dll Eclipce  /  TFS Web Interface *.cs/*.xoml *.jre *.dll/*.exe/*.jre*.doc/ *.xls Configurator Розробник ПС Рис. 5. Загальна модель роботи конфігуратора Репозиторій зберігає компоненти повторного використання КПВ, які є робо- чим матеріалом для конфігуратора. Фаб- рика програмних систем є програмою сер- вером, яка надає середовище для розмі- щення сервісів – ПС або інших КПВ. Процес заповнення репозиторію відбувається послідовно. Розробник (рис. 5, стрілка 1) отримує завдання на до- опрацювання або створення нового КПВ за допомогою Visual Studio і вносить їх до репозиторію. У загальному випадку КПВ складається з двох типів файлів: *.cs, які несуть у собі бізнес логіку процесу та *.xoml, які представляють собою атомарні або більш абстрактні об’єкти прикладної області (домену) та описують алгоритм виконання бізнес логіки із *.cs файлів. На рис. 4 показано інтерфейс конфі- гуратора, який сполучається з репозиторі- єм (рис. 5, стрілка 2) і отримує список усіх доступних у системі КПВ. Вони відобра- жаються у правому верхньому кутку кон- фігуратора. Далі, під списком розташована детальна інформація про кожен КПВ. Його назва, клас від якого він успадкований, опис, статус, та прив’язка до конкретного метода в файлі типу *.cs. Користуючись графічним дизайне- ром розробник або бізнес консультант мо- же модифікувати або побудувати нову біз- нес модель, а разом із нею програмну сис- Методи та засоби програмної інженерії 69 тему, із доступних КПВ даного прикладно- го домену. Та розмістити її у програмі сер- вері (рис. 5, стрілка 4) або зберегти зміни і розмістити модель у репозиторії, як КПВ, для подальшого використання. Кожен еле- мент у вікні дизайнера конфігуратора є атомарним КПВ, заздалегідь розроблений і доданий до репозиторію розробником (рис. 5, стрілка 2). Далі наведено код *.xoml файлу діа- грами показаної на рис. 4. У даному випа- дку описано простий приклад вирішення задачі знаходження коренів квадратного рівняння. xoml код є не що інше як зви- чайний розширений xml, який описує по- слідовність викликів команд бізнес логіки (ExecuteCode="codeActivity1_ExecuteCode_1", ExecuteCode="CA2_ExecuteCode", ExecuteCode=  "CA3_ExecuteCode") у залежності від резуль- тату виконання попередніх частин коду (наприклад, таких як <IfElseActivity  x:Name=  "ifElseActivity1"> або <IfElseBranchActivity x:Name= "D_less_0">). <SequentialWorkflowActivity x:Class="WF05.Workflow2" x:Name="Workflow2">    <CodeActivity x:Name="Start" ExecuteCode="codeActivity1_ExecuteCode" />    <CodeActivity x:Name="Discriminant" ExecuteCode="codeActivity1_ExecuteCode_1" />    <IfElseActivity x:Name="ifElseActivity1">      <IfElseBranchActivity x:Name="D_more_0">        <IfElseBranchActivity.Condition>          <CodeCondition Condition="WorkMeth1" />        </IfElseBranchActivity.Condition>        <CodeActivity x:Name="TwoRoots"ExecuteCode="CA1_ExecuteCode_2"/>      </IfElseBranchActivity>      <IfElseBranchActivity x:Name="D_equal_0">        <IfElseBranchActivity.Condition>          <CodeCondition Condition="WorkMeth2" />        </IfElseBranchActivity.Condition>        <CodeActivity x:Name="ExactlyOneRoot" ExecuteCode="CA2_ExecuteCode" />      </IfElseBranchActivity>      <IfElseBranchActivity x:Name="D_less_0">        <IfElseBranchActivity.Condition>          <CodeCondition Condition="WorkMeth3" />        </IfElseBranchActivity.Condition>        <CodeActivity x:Name="NoRoots" ExecuteCode="CA3_ExecuteCode" />      </IfElseBranchActivity>    </IfElseActivity>    <DelayActivity TimeoutDuration="00:00:05" x:Name="delayActivity1" />  </SequentialWorkflowActivity> Далі приведено код файлу .cs КПВ з рис. 4. public partial class Workflow2 : SequentialWorkflowActivity{      SomeCustomForm myForm = new SomeCustomForm();      private int a, b, c, D;      private void codeActivity1_ExecuteCode(object sender, EventArgs e) {         myForm.label1.Text = "Введите коефициент: a для ax2 + bx + c = 0";         myForm.ShowDialog(new Form());         if (myForm.DialogResult == DialogResult.OK) {             a = int.Parse(myForm.Message);         }         myForm.label1.Text = "Введите коефициент: b для ax2 + bx + c = 0";         myForm.ShowDialog(new Form());         if (myForm.DialogResult == DialogResult.OK){             b = int.Parse(myForm.Message);         }         myForm.label1.Text = "Введите коефициент: c для ax2 + bx + c = 0";         myForm.ShowDialog(new Form());         if (myForm.DialogResult == DialogResult.OK) {             c = int.Parse(myForm.Message);         }      }      private void codeActivity1_ExecuteCode_1(object sender, EventArgs e) {  Методи та засоби програмної інженерії 70        Uri address =new Uri("http://localhost:63632/CountDiscriminant.svc");//ADDRESS.(A)         WSHttpBinding binding = new WSHttpBinding();     // BINDING.   (B)         EndpointAddress endpoint = new EndpointAddress(address);         ChannelFactory<ICountDiscriminant> factory = new  ChannelFactory<ICountDiscriminant>(binding, endpoint);  // CONTRACT.  (C)          ICountDiscriminant channel = factory.CreateChannel();         D = channel.GetDiscriminant(a, b, c);    //D = (b * b) ‐ (4 * a * c);      }      private void WorkMeth1(object sender, ConditionalEventArgs e) {e.Result = D > 0;}      private void WorkMeth2(object sender, ConditionalEventArgs e) {e.Result = D == 0;}      private void WorkMeth3(object sender, ConditionalEventArgs e){e.Result = D < 0;}      private void codeActivity1_ExecuteCode_2(object sender, EventArgs e){…}      private void codeActivity2_ExecuteCode(object sender, EventArgs e){         myForm.label1.Text = "Result is: " + "‐" + (b / (2 * a));         myForm.ShowDialog(new Form());      }      private void codeActivity3_ExecuteCode(object sender, EventArgs e){         myForm.label1.Text = "no roots.";         myForm.ShowDialog(new Form());      }      private void codeActivity4_ExecuteCode(object sender, EventArgs e){}  } Бачимо, що клас КПВ представляє собою лише набір методів, які будуть ви- конуватись послідовно або паралельно в порядку заданому xoml нотацією. Дана концепція конфігуратора та КПВ дозволяє маніпулювати навіть КПВ написаними на мовах, що не підтримуються CLR, та КПВ представлених у вигляді сервісів. Розгля- немо виклики до КПВ у вигляді сервісів. Для запуску програми AppFabric (рис. 5, блок А) потрібно запустити Пуск Програми Internet Information Server (IIS), далі в лівій панелі рис. 6 обираємо потрібний нам сервіс, отримуємо необхід- ну інформацію (адресу, прив’язку, конт- ракт) та заносимо дані у вигляді коду в один з методів файлу .cs Методи та засоби програмної інженерії 71 Рис. 6. Центр керування Internet Information Server (IIS) та AppFabric Результатом є наступний код: 1: private void codeActivity1_ExecuteCode_1(object sender, EventArgs e)  2: {  3:     Uri address = new Uri("http://localhost:63632/CountDiscriminant.svc");//адреса  4:     WSHttpBinding binding = new WSHttpBinding();         //прив’язка  5:     EndpointAddress endpoint = new EndpointAddress(address);  6:     ChannelFactory<ICountDiscriminant> factory = new                          ChannelFactory<ICountDiscriminant>(binding, endpoint);  //контракт  7:     ICountDiscriminant channel = factory.CreateChannel();  8:     D = channel.GetDiscriminant(a, b, c);     //D = b2 − 4ac:  9: }  Рядки з 3-го по 7-ий створюють та конфігурують спеціальний об’єкт  channel для віддаленого виклику. А 8-ий рядок виконує цей виклик (рис. 5, стрілка 6). Під час роботи з конфігуратором, можна запускати на виконання алгоритм завантажений у редактор. Для цього потрі- бно викликати Workflow CompileWork- flow. Конфігуратор проаналізує та скомпі- лює *.cs та *.xoml файли, сформує бібліо- теку (*.dll) та виведе повідомлення рис. 7. Потім завантажить щойно створену бібліотеку в оперативну пам'ять знайде потрібний КПВ та запустить його на вико- нання. Рис. 7. Приклад успішної компіляції КПВ Висновок У даній роботі розглянуто проблеми та цілі керування конфігурацією КПВ, представлено два підходи до створення програм конфігураторів метою яких є ав- томатизація та надання користувацького інтерфейсу для збирання ПС з набору ПВК у середовищі СПС. Перший підхід засно- ваний на фундаменті діаграм характерис- тик, його прототип розроблено в [4]. Дру- гий використовує одну з багатьох мов DSL Windows Workflow Foundation, приклад створення та роботи такого конфігуратора представлено в даній роботі. 1. Бабенко Л.П., Лавріщева К.М. Основи про- грамної інженерії. Посібник,- Знання, 2001. – 269 с. 2. Колесник А.Л. Механізми забезпечення варіабельності в сімействах програмних систем // Проблеми програмування. – 2010. – № 1. – C. 35 – 44. 3. Лавріщева К.М., Слабоспицька О.О., Ко- валь Г.І., Колесник А.О. Теоретичні аспек- ти керування варіабельністю в сімействах програмних систем. Вісник КГУ, серія фіз.- мат.наук. – 2011. – № 1. – С. 151 – 158. 4. Pohl K., B¨ockle G., and Van der Linden F. Software Product Line Engineering: Foundations, Principles, and Techniques. Springer, 2005. 5. http://featuremodeldsl.codeplex.com 6. Lenz G., Wienands C. Practical Software Factories in .NET, 2006. 7. Muthig D. A Light-Weight Approach Facilitating an Evolutionary Transition Towards Software Product Lines. PhD thesis, University of Kaiserslautern, IRB Verlag, 2002. Отримано 15.06.2011 Про автора: Колесник Андрій Леонідович, аспірант. Місце роботи автора: Інститут програмних систем НАН України 03187, Київ-187, проспект Академіка Глушкова, 40. Тел.: +380 (50) 444 2299. e-mail: swabber@gmail.com

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