Technological Model for the Process of Software Automated Production
Home software industry’s needs are analyzed for unified process of applied software automated production. The process forming is grounded under the paradigms of generative development and software variability – its ability to be changed, customized or configured for use in particular context – manag...
Gespeichert in:
| Datum: | 2025 |
|---|---|
| 1. Verfasser: | |
| Format: | Artikel |
| Sprache: | Ukrainian |
| Veröffentlicht: |
PROBLEMS IN PROGRAMMING
2025
|
| Schlagworte: | |
| Online Zugang: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/796 |
| Tags: |
Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
|
| Назва журналу: | Problems in programming |
| Завантажити файл: |  |
Institution
Problems in programming| id |
pp_isofts_kiev_ua-article-796 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/c0/5edf5f549a940c065a23a08df28cbcc0.pdf |
| spelling |
pp_isofts_kiev_ua-article-7962025-09-02T15:47:58Z Technological Model for the Process of Software Automated Production Технологічна модель процесу автоматизованого виробництва сімейств програмних систем Slabospitska, O.O. UDC 681.3 УДК 681.3 Home software industry’s needs are analyzed for unified process of applied software automated production. The process forming is grounded under the paradigms of generative development and software variability – its ability to be changed, customized or configured for use in particular context – management, causing Software Family development. The process is composed with the special functions of consistent variability management over proper model environment accordingly to generative domain model constituted with the environment elements (from problem and solution spaces). Technological Model for the Process is constructed in accordance with its representation proposed.Problems in programming 2011; 1: 39-48 Проаналізовано потреби вітчизняної програмної індустрії в уніфікованому процесі автоматизованого виробництва прикладних програмних систем (ПС). Обґрунтовано його побудову на засадах генеруваль-ного програмування і керування варіабельністю – здатністю ПС до зміни, налаштування чи конфігурування для застосування в певному контексті, яка обумовлює створення сімейства ПС. Процес подано композицією спеціальних функцій обґрунтованого керування варіабельністю в адекватному модельному середовищі згідно з генерувальною моделлю, визначеною у термінах його елементів (з просторів проблеми й рішень). Побудовано технологічну модель процесу, відповідну запропонованому поданню.Problems in programming 2011; 1: 39-48 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2025-08-28 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/796 PROBLEMS IN PROGRAMMING; No 1 (2011); 39-48 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 1 (2011); 39-48 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 1 (2011); 39-48 1727-4907 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/796/848 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:47:58Z |
| collection |
OJS |
| language |
Ukrainian |
| topic |
UDC 681.3 |
| spellingShingle |
UDC 681.3 Slabospitska, O.O. Technological Model for the Process of Software Automated Production |
| topic_facet |
UDC 681.3 УДК 681.3 |
| format |
Article |
| author |
Slabospitska, O.O. |
| author_facet |
Slabospitska, O.O. |
| author_sort |
Slabospitska, O.O. |
| title |
Technological Model for the Process of Software Automated Production |
| title_short |
Technological Model for the Process of Software Automated Production |
| title_full |
Technological Model for the Process of Software Automated Production |
| title_fullStr |
Technological Model for the Process of Software Automated Production |
| title_full_unstemmed |
Technological Model for the Process of Software Automated Production |
| title_sort |
technological model for the process of software automated production |
| title_alt |
Технологічна модель процесу автоматизованого виробництва сімейств програмних систем |
| description |
Home software industry’s needs are analyzed for unified process of applied software automated production. The process forming is grounded under the paradigms of generative development and software variability – its ability to be changed, customized or configured for use in particular context – management, causing Software Family development. The process is composed with the special functions of consistent variability management over proper model environment accordingly to generative domain model constituted with the environment elements (from problem and solution spaces). Technological Model for the Process is constructed in accordance with its representation proposed.Problems in programming 2011; 1: 39-48 |
| publisher |
PROBLEMS IN PROGRAMMING |
| publishDate |
2025 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/796 |
| work_keys_str_mv |
AT slabospitskaoo technologicalmodelfortheprocessofsoftwareautomatedproduction AT slabospitskaoo tehnologíčnamodelʹprocesuavtomatizovanogovirobnictvasímejstvprogramnihsistem |
| first_indexed |
2025-09-17T09:23:06Z |
| last_indexed |
2025-09-17T09:23:06Z |
| _version_ |
1843502499727671296 |
| fulltext |
Методи та засоби програмної інженерії
УДК 681.3.06
О.О. Слабоспицька
ТЕХНОЛОГІЧНА МОДЕЛЬ ПРОЦЕСУ АВТОМАТИЗОВАНОГО
ВИРОБНИЦТВА СІМЕЙСТВ ПРОГРАМНИХ СИСТЕМ
Проаналізовано потреби вітчизняної програмної індустрії в уніфікованому процесі автоматизованого
виробництва прикладних програмних систем (ПС). Обґрунтовано його побудову на засадах генеруваль-
ного програмування і керування варіабельністю – здатністю ПС до зміни, налаштування чи конфігу-
рування для застосування в певному контексті, яка обумовлює створення сімейства ПС. Процес подано
композицією спеціальних функцій обґрунтованого керування варіабельністю в адекватному модельно-
му середовищі згідно з генерувальною моделлю, визначеною у термінах його елементів (з просторів
проблеми й рішень). Побудовано технологічну модель процесу, відповідну запропонованому поданню.
Вступ
Розбудова індустрії конкуренто-
спроможних програмних продуктів є нара-
зі одним з пріоритетів інноваційного роз-
витку держави [1]. Директивні документи
[1, 2] фіксують шляхи розбудови:
а) розвиток двох складових інду-
стрії – для зовнішніх та внутрішніх ринків;
б) перехід від продажу інтелекту-
альних послуг або компонентів – до про-
дажу прикладних програмних застосунків;
в) сприяння виходу на зовнішні ри-
нки малих і середніх фірм-експортерів;
г) гнучке врахування динаміки рин-
кового попиту і пропозицій;
д) створення організаційних засад
управління програмною індустрією.
Аналіз досвіду організації програм-
ної індустрії [3–5] висвітлює потребу в
розгортанні процесу автоматизованого ви-
робництва сімейств (АВС) програмних си-
стем (ПС) для реалізації цих шляхів. Сі-
мейство – це низка ПС з однаковими
функціями, але різними деталями реаліза-
ції (мовою, інтерфейсом, методами тощо)
для споживачів у різних функціональних
сегментах предметної області (ПрО).
Зазначений аналіз демонструє два
механізми інженерії сімейств ПС (СПС).
Перший – це обґрунтоване кількісне керу-
вання варіабельністю у СПС [6–8]. Дру-
гим є генерувальне програмування: авто-
матизоване створення ПС – членів СПС з
інформаційних ресурсів повторного вико-
ристання (РПВ), накопичуваних у репози-
торії інтегрованого середовища розроблен-
ня (ІСР), за генерувальною моделлю СПС
[9, 10] і описом підтримуваних потреб спо-
живачів у ПрО.
Однак зіставлення підходів до роз-
витку механізмів [6–10] засвідчує їх роз-
межування: технологічні й реалізаційні за-
соби забезпечення варіабельності – для
першого; мови опису ПрО в генерувальній
моделі – для другого. Проблема узгодже-
ної реалізації механізмів на єдиних теоре-
тичних засадах залишається поза увагою.
На підтримку вирішення цієї проб-
леми для розбудови програмної індустрії,
пропонується технологічна модель проце-
су АВС. Він поданий композицією спеці-
альних функцій обґрунтованого керування
варіабельністю в адекватному модельному
середовищі [7] за генерувальною моделлю,
визначеною елементами середовища.
Проблему досліджено в рамках про-
екту «Розробка теоретичного фундаменту
генеруючого програмування та інструмен-
тальних засобів його підтримки», що вико-
нується в Інституті програмних систем
НАН України під керівництвом д-ра фіз.-
мат. наук, проф. К.М. Лавріщевої [9].
Кількісне керування
варіабельністю
Функції керування варіабель-
ністю. Визначальною особливістю проце-
су розроблення СПС для певної ПрО є
взаємодія двох складових – процесів ін-
женерії ПрО та інженерії програмних за-
39
© О.О. Слабоспицька, 2011
ISSN 1727-4907. Проблеми програмування. 2011. № 1
Методи та засоби програмної інженерії
40
стосунків. Вона показана на рис. 1 (згідно з
відомою моделлю К. Похла [6]).
Рис.1. Модель процесу розроблення СПС
У процесі інженерії ПрО реалізуєть-
ся варіабельність структури СПС – її здат-
ність до визначення спільних і потенційно
розбіжних характеристик ПС – та припу-
стимого діапазону розбіжності (з позицій
функціональних і нефункціональних вимог
до якості, архітектури, середовища експлу-
атації тощо). Створюються також арте-
факти, які є реалізаціями спільних характе-
ристик ПС і забезпечують варіабельність
СПС, необхідну для породження множини
ПС за потребами споживачів у ПрО. Арте-
факти, що є РПВ, піддаються тестуванню і
утворюють платформу СПС. Ця платфор-
ма поряд з програмними РПВ включає мо-
делі вимог, архітектури, тестів тощо. Для
систем оброблення даних, яким властиві
складні структури даних у ПрО і ведення
великих обсягів інформації, платформа та-
кож охоплює моделі даних для ПС з СПС.
Процес інженерії застосунків при-
значений для створення ПС (за певною ге-
нерувальною моделлю) з множини РПВ
шляхом часткового зв’язування (знижен-
ня) структурно закладеної варіабельності
згідно з вимогами до ПС. Результатом
зв’язування є варіабельність артефактів –
їх здатність до розширення, змінювання,
пристосування або конфігурування з ме-
тою використання у певній ПС [8].
Процеси організаційного керування
(див. рис. 1) необхідні для координації ро-
біт у процесах інженерії ПрО та застосун-
ків. У процесах технічного керування здій-
нюється планування й контроль робіт зі
створення РПВ, з одного боку, та їх вико-
ристання для побудови ПС, з іншого боку.
Отже, межі СПС визначаються в
термінах множин підтримуваних потреб і
технічних вимог до ПС, а також артефактів
процесів їх розроблення на підтримку ви-
мог і потреб (названих у [10] просторами
проблеми та рішень). У процесі інженерії
ПрО в просторі проблеми формуються
описи підтримуваних потреб і технічних
вимог, а в просторі рішень – програмні
РПВ. Процес інженерії застосунків
доповнює їх описами потреб і вимог для
окремої ПС (у просторі проблеми) та
готовими ПС на підтримку потреб (у
просторі рішень).
Механізм керування варіабельністю
передбачає ідентифікацію та опис об’єктів
керування – точок варіантності, варіантів,
а також обмежень і залежностей між ними
(детально розглянутих у роботі [7]).
Аналіз внутрішньої структури про-
цесу розроблення СПС за моделлю К. Пох-
ла [6, 11] висвітлює чотири типи (t) арте-
фактів, що можуть бути точками варіант-
ності і варіантами. Це: характеристика ПС,
прийнята до реалізації (t = 1); компонент
архітектури ПС (t = 2); програмний арте-
факт (компонент, аспект тощо) (t = 3); таб-
лиця бази даних (t = 4). Зазначимо, що ар-
тефакти типу t=1 поділяються на дві гру-
пи: враховані потреби ділових процесів
ПрО; вимоги до ПС з боку аналітиків СПС.
Для формування процесу АВС зруч-
но скористатися функціями кількісного ке-
рування варіабельністю, запропонованими
в [7]1 на підставі відомого циклу
керування Е. Дьомінга. До їх числа
належить:
1) планування реалізації варіабель-
ності в структурі й артефактах СПС (F1);
2) реалізація варіабельності в
структурі й артефактах СПС [12] (F2);
3) системний моніторинг стану
СПС в аспекті варіабельності (F3);
4) актуалізація СПС за результата-
ми моніторингу (F4).
На підтримку розбудови програмної
індустрії за допомогою процесу АВС,
доцільно прийняти вимоги до виконання
функцій F1 – F4, висунуті в [7]:
1 Функції визначив аспірант ІПС НАН України А.Л. Ко-
лесник
Методи та засоби програмної інженерії
1) обґрунтованість – надання під-
став прийняття рішень щодо функцій (D1);
2) узгодженість – однаковість
способів вироблення й реалізації цих
рішень на всіх рівнях абстракції і на всіх
етапах процесу розроблення СПС (D2);
3) масштабовність – незалежність
способу вироблення й реалізації зазначе-
них рішень від обсягу функціональних
можливостей, охоплених СПС (D3);
4) трасовність – можливість про-
стеження зв’язків між проявами варіа-
бельності на всіх рівнях абстракції і на всіх
етапах процесу розроблення СПС (D4).
Композування функцій F1 – F4 з до-
триманням вимог D1 – D4 потребує адек-
ватного середовища їх виконання.
Модельне середовище керування
варіабельністю. Доцільну структуру сере-
довища обґрунтовано в [7]. Воно поєднує
узгоджені моделі варіабельності в струк-
турі та в артефактах СПС, а також інтегро-
вану модель варіабельності. Остання до-
повнює традиційні виміри у просторі
об’єктів керування варіабельністю – точки
варіантності й варіанти – оціночною мо-
деллю для інтегрального рівня варіабель-
ності та ступеня її відповідності потребам
ПрО (за шкалою відношень).
Сутність зазначених моделей роз-
кривають їхні означення, які наведені далі.
Означення 1. Модель варіабельності
в структурі СПС – це кортеж
SV = 〈〈 CF; 〈DR,TC〉; 〈AR,TD〉;
〈CM,FR,TS,TA〉; 〈ER,TF〉〉; Constr; Dep 〉, (1)
де CF = 〈SF, LF〉 – діаграма характеристик
(у нотації [8]), яка подає множину сталих і
змінних властивостей ПС (SF), пропо-
нованих їх потенційним споживачам, та
обмеження (Constr) й залежності (Dep) між
ними за допомогою зв’язків обов’язкового
й варіантного підпорядкування (LF);
DR = 〈SF∪SR, LF∪LR〉 – аналогічна
діаграма, де характеристики f∈SF деталізо-
вано і/або доповнено характеристиками
r∈SR, що подають сталі та змінні ”техніч-
ні” вимоги до ПС з боку аналітиків СПС,
обмеження й залежності яких відобража-
ються зв’язками LR;
TC={(r,f),r∈SR,f∈SF)} – двосторон-
ні зв’язки трасовності між ”технічними”
вимогами до ПС та їх властивостями для
споживача, що деталізуються вимогами;
AR = 〈AC, LC〉 – еталонна
архітектура СПС [6], тобто опис взаємо-
зв’язків (LC) між формальними поданнями
програмних РПВ (AC) для реалізації харак-
теристик f∈DR у певній нотації для прог-
рамної архітектури (UML, xADL тощо);
TD ={(ac,f), ac∈AC, f∈SF∪SR)} –
двосторонні зв’язки трасовності між по-
даннями компонентів архітектури ac∈AC
(для реалізації характеристик f∈DR) та
цими характеристиками;
CM – описи базових програмних
РПВ для реалізації компонентів архі-
тектури при складанні за каркасом (FR);
TS = {(ts,cm), cm∈CM} – формальні
описи тестів (ts) для РПВ з описами cm;
TA = {(cm,ac), cm∈CM,ac∈AC)} –
двосторонні зв’язки трасовності між
програмними РПВ та компонентами
архітектури AR;
TL = {(fr,lc), fr∈FR, lc∈LC)} –
двосторонні зв’язки трасовності між
елементами каркаса для складання РПВ та
взаємозв’язками компонентів архітектури;
ER і TF – відповідно, ER-модель
бази даних (БД) для ПС з СПС та двосто-
ронні зв’язки трасовності її елементів з
РПВ cm∈CM.
Кожний з вкладених кортежів у ви-
разі (1) відображає опис потреб потенцій-
них споживачів, формований у підпроце-
сах розроблення СПС (див. рис. 1) в арте-
фактах відповідного типу – від характе-
ристик до підмножин полів таблиць БД.
Співвідношення між варіабельністю
у структурі СПС та в його артефактах,
зокрема, в ресурсах, висвітлює
Означення 2. Модель варіабельності
в артефактах СПС – це четвірка
AS = 〈 AF1, AF2, AF3, AF4 〉, (2)
де AFt={f(aft)} – множина формальних по-
дань артефактів СПС типу t = 1,…,4 (aft).
Для узгодженого відображення
варіабельності в артефактах СПС та в
структурі СПС за моделлю (1) пропонуєть-
ся уніфікований розгляд довільного арте-
факту типу t (aft) як наскрізного фрагмента
моделі (1), виділеного неперервними зв’яз-
ками трасовності τ∈TD∪TA∪TF вершин
41
Методи та засоби програмної інженерії
42
певного “цільового” підграфа rt графа DR –
тобто тих характеристик ПС, для реалізації
яких призначено aft. Прийнятий розгляд
артефактів фіксує
Означення 3. Формальне подання
артефакту СПС типу t (aft) – це кортеж
f(aft) = 〈rt;〈art,tdt〉; 〈frt,cmt,tst,tat〉;〈ert, tft〉〉, (3)
де складниками є підграфи “горизон-
тальних” графів моделі (1) на всіх її рівнях
та “вертикальні” зв’язки трасовності між
вершинами цих підграфів суміжних рівнів.
Зокрема, у виразі (3):
rt – підграф графа DR, що подає
характеристики, які реалізує артефакт aft;
art – підграф графа AR, де вершини
пов’язані неперервними зв’язками трасов-
ності: td2 ⊆ TD – з вершинами графа r2 або
з вершинами підграфа grt рівня t з моделі
(1), який безпосередньо реалізується ар-
тефактом aft у процесі розроблення СПС;
grt=r1, gr2 =ar2; gr3 = 〈fr3,cm3〉; gr4 = er4;
tdt ⊆ TD – зв’язки трасовності між
вершинами підграфів art і rt;
cmt ⊆CM, frt ⊆FR – формальні
подання програмних артефактів та елемен-
тів каркаса, пов’язаних неперервними зв’я-
зками трасовності з вершинами підграфа
ar3 або grt;
tst ⊆ TS – формальні описи тестів
для компонентів, описаних у cmt;
tat ⊆ TA – зв’язки трасовності між
вершинами підграфів 〈frt,cmt〉 і art;
ert – фрагмент ER-моделі БД для
оброблення ПС з СПС, де вершини пов’я-
зані висхідними неперервними зв’язками
трасовності: tf4⊆TF – з вершинами
підграфа 〈cm3, fr3〉; tr ⊆TF∪TA∪TD – з
вершинами підграфа grt (t ≠4);
tft ⊆TF – зв’язки трасовності між
вершинами підграфів ert і 〈frt,cmt〉.
Для постійного відстеження позиції
aft на підтримку функцій F1 – F4 доцільно
зберігати його у репозиторії RE разом з
уніфікованим паспортом [7].
Означення 4. Паспорт артефакту
as∈AS (2) – це структурований кортеж
CT(as) = 〈wc; {〈wuτ, usτ, vbτ, rτ〉}; id〉, (4)
де wc, wuτ – відповідно, трудовитрати на
створення аs та середні трудовитрати на
його повторне використання впродовж
чергового періоду τ розроблення СПС;
usτ = 〈fc,fh,ph〉 – використовність rs
протягом періоду τ, складена частотами:
безпосереднього надання rs замовнику
/споживачу (fc), повторного застосування в
проактивному розробленні ПС ринкового
призначення (fh) та для вдосконалення
самого процесу розроблення СПС (ph);
vbl = 〈fvp,fvr〉 – варіабельність as у
період τ, складена частотою точок
варіантності (fvp) і середньою частотою
варіантів для них (fvr) згідно з f(rs) (3);
rl – рейтинг корисності as у період
τ, коригований аналітиками СПС на під-
ставі апріорного значення у впорядкуванні
артефактів того ж типу, що й as, за
спаданням величин (fc+fh+ph)/(wc+wul);
id – реєстраційні реквізити (іденти-
фікатор, призначення, дата реєстрації в
репозиторії, персоналії й роль її суб’єкта).
Сформульовані вимоги D1 – D5
стосовно функцій F1 – F4 у середовищі
керування варіабельністю забезпечує
інтегрована модель варіабельності.
Означення 5. Інтегрована модель
варіабельності – це структурований кор-
теж
VM = 〈EVM; VP; VAR〉; EVM = 〈VL, VR〉; (5)
VP = 〈VpR, VpA, VpE, VpB〉;
VAR=〈VR, VA, VE, VB〉;
VL=〈vrl,val,vel,vbl〉, VR=〈vrr,var,ver,vbr〉, (6)
де VpR, VpA, VpE, VpB – множини точок
варіантності в структурі СПС, які відобра-
жають, відповідно, характеристики ПС,
компоненти архітектури, елементи каркаса
і поля таблиць БД, із зв’язками трасовно-
сті, обмеження й залежності з SV (1);
VR, VA, VE, VB – множини варіантів
для точок варіантності з множин, відповід-
них їм за номером у кортежі (5), із збере-
женими зв’язками трасовності, обмеження
(Сonstr) й залежності (Dep) з SV (1);
VL – вкладена оціночна модель
рівня варіабельності, деталізована за типа-
ми її проявів – відповідно, у вимогах (vrl),
компонентах архітектури (val), програмних
артефактах (vel), даних з БД (vbl);
VR – аналогічна модель рівня від-
Методи та засоби програмної інженерії
повідності варіабельності в СПС потребам
цільової ПрО, деталізована відповідно для
вимог (vrr), компонентів архітектури (var),
програмних артефактів (ver), даних (vbr).
Оцінки рівнів варіабельності за про-
понованими моделями VL і VR (6) зручно
накопичувати у спеціальному профілі ва-
ріабельності СПС. Його структуру фіксує
Означення 6. Профіль варіабель-
ності СПС – це структурований кортеж
VPR = {〈WUτ, USτ, VBτ, Rτ〉}, vlτ, vrτ〉, (7)
де компоненти мають зміст, аналогічний
компонентам паспорта CT(rs) (5), а саме:
WC і WUτ – відповідно, трудови-
трати на створення СПС та середні трудо-
витрати на створення ПС для споживачів у
черговому періоді τ розроблення СПС;
USτ – середня використовність
артефактів СПС в період τ, складена усе-
редненими частотами їх безпосереднього
надання замовнику /споживачу, повтор-
ного застосування в проактивному розроб-
ленні ПС ринкового призначення та для
вдосконалення процесу розроблення СПС;
VBτ – показник варіабельності СПС
у період τ, складений усередненими відпо-
відними показниками з паспортів (4);
Rτ – п’ятірки артефактів з
найвищим та найнижчим рейтингом у
період τ згідно з їхніми паспортами (4);
vlτ, vrτ – оцінки поточного стану
СПС за моделями VL і VR (6).
Генерувальна модель як засіб
реалізації варіабельності в СПС
Розглянуте середовище керування
варіабельністю (1) – (7) дозволяє подати
генерувальну модель (ГМ) у процесі АВС
композицією відображень, що здійснюють-
ся певними операціями функції реалізації
варіабельності в СПС (F2).
Потреба внесення до меж СПС
нових характеристик ПС, не підтриманих
РПВ, обумовлює недостатність канонічних
ГМ – конфігураційної (CM) й трансформа-
ційної (TM). У загальному випадку, коли
не всі цільові характеристики ПС реалізу-
ються РПВ, необхідна композиція CM і
TM, названа гібридною ГМ (HM).
Вигляд CM, TM, HM встановлюють
наведені далі означення (цільові вимоги dr
вважаються поданими діаграмою харак-
теристик у нотації [8] з деякої множини
RQ подань припустимих вимог у ПрО).
Нехай:
e.aft, e∈{r, ar, fr, cm, ts, er}– елемент
e у поданні f(aft) (3) для артефакту aft;
RC(dr) = {af3 ∈ RE| r.af3 = dr} –
множина РПВ на підтримку dr;
PC(dr) = {af3 ∉ RE| r.af3=dr, cm.af3, (8)
ts.af3⊆RE, er.af3∈DB}
– множина програмних артефактів на під-
тримку dr, які конфігуруються з РПВ, опи-
саних елементами cm.af3, ts.af3, er.af3 у ви-
разі f(af3) (3), за допомогою каркасів fr.af3;
q(af3)∈Q – поточна модель віднос-
ної якості af3, що враховує витрати на af3;
DC – операція розкладу вимог
dr = {dr1; dr2i, i≥1), (9)
де dr1 – підграф графа DR у SV (1), підтри-
маний РПВ з репозиторію RE і найбільш
подібний до dr, а dr2i – незалежні цільові
характеристики ПС, не підтримані РПВ;
DB – фізичне подання БД для ПС.
Означення 7. Конфігураційна ГМ
для реалізації варіабельності (ВГМ) зі-
ставляє цільовим вимогам такий РПВ або
програмний артефакт, конфігурований з
РПВ (CM(dr)), який підтримує цільові ви-
моги з найвищою відносною якістю, за
його наявності в СПС:
CM: REQ → SW × ST × DB; SW,ST ⊂ RE;
CM(dr) = argmax{q(af3), (10)
af3∈RC(dr)∪PC(dr)}, якщо
dr=dr1, RC(dr)∪PC(dr)≠∅,
де SW, ST – тимчасові області репозиторію
RE для кодів і тестів, описані далі.
Для прототипу моделі q пропону-
ється відношення якості af3 (за еталонною
моделлю ISO/IEC 9126) і витрат на нього.
Зіставлення виразів (9) і (3) надає
конфігураційній ВГМ (10) пошукуваної
форми, конструктивної для композування
операцій функції F2 у процесах інженерії
ПрО та застосунків згідно з нею:
CM =C ° (CF ° AS )° FA° DC , (11)
де C=С(q) – вибір артефакту(ів) з
максимальним значенням q;
43
Методи та засоби програмної інженерії
44
CF, AS – формування множин
PC(dr), RC(dr) за поданнями (3) для їхніх
елементів та для цільових вимог dr;
FA – зіставлення вимогам їхнього
подання f(dr) (3) на підставі їхніх зв’язків
трасовності в моделі SV (1).
Означення 8. Трансформаційна ВГМ
реалізує операцію зіставлення цільовим
вимогам dr РПВ TM(dr), в який трансфор-
мується його опис cm.f(dr) у поданні f(dr)
(3) для вимог:
TM: REQ → RE × RE × DB;
TM = EG °FA °τ °α °δ°DC, (12)
TM(dr)=EG(cm.dr,ts.dr,er.dr),
де EG – операція трансформації опису
РПВ TM(dr) з f(dr) (3) у виконуваний код;
ϕ,α,δ – операції встановлення або,
за наявності, простеження неперервних
низхідних зв’язків трасовності описів,
відповідно, коду (TF), архітектури (TA) та
вимог (TD) у моделі SV (1).
Операції EG,ϕ,α,δ реалізуються за
допомогою низки проміжних мов опису
ПрО (їх приклади для ϕ, EG надано в [12]).
За необхідності, при створенні ПС операці-
ям ϕ,α,δ можна зіставити індуковані опе-
рації породження артефактів типів t = 4,2,1
(документи вимог до ПС, подання архітек-
тур і структур даних) у міру формування
їхніх описів у f(dr) (3).
З означень 7 і 8 випливає, що для
вимог dr, повністю підтриманих РПВ,
застосовні обидві моделі CM і TM. Отже, у
процесі інженерії застосунків необхідне
правило вибору між ними. Природно роз-
глядати його як предикат tg на множині
характеристик якості й витрат артефактів
CM(dr) і TM(dr), актуалізовний для черго-
вої ПС у межах певної множини TG. До
цієї множини пропонується первинно вне-
сти правила ”м’якого” й “жорсткого” вибо-
ру, доцільні за достатніх (відповідно, об-
межених) ресурсів фірми-розробника СПС.
”М’яким” є вибір між CM(dr), TM(dr)
артефакту з вищою відносною якістю Q. За
”жорстким” правилом обирається артефакт
з меншими витратами на отримання.
Означення 9. Гібридна ВГМ є
композицією відображень:
HM = CM °(°i ≥ 1TM) °DC; (13)
HM(dr) = argmax{Q(af3), af3=
= fr.af3(cm3.af3, ts.af3, er3.af3), r.af3∈DC(dr)}.
Наведені подання ВГМ (10), (12),
(13) підвищують повторну використов-
ність РПВ й артефактів у процесі інженерії
застосунків. Вони також сприяють уніфіка-
ції дій з розроблення цільових ПС (пода-
них операціями функції F2 у виразах для
ВГМ) та підвищенню їх чутливості до змін
умов розроблення (за допомогою моделі Q,
правил TG, тимчасових областей SW, ST).
Крім того, описи (3) для результатів
застосування ВГМ дозволяють формуван-
ня й актуалізацію у процесі ABC постано-
вок задач для операцій функцій F1,F3,F4.
Це, по перше, оптимізаційні постановки:
− добору характеристик для СПС
(FCF) і для окремих ПС (FCA);
− розподілу коштів і термінів на
ведення структури СПС (RF) та створення
ПС (RA);
− актуалізації пріоритетів реаліза-
ції (характеристик і наслідків їх трасуван-
ня) і видалення з репозиторію (РПВ) (EA).
Другу групу складають задачі об-
ґрунтованого експертно-аналітичного оці-
нювання [13] керованих об’єктів у проце-
сах інженерії ПрО і застосунків. Третя гру-
па – постановки задач виявлення
неадекватності ІСР СПС потребам Про та
дій з її подолання (AI).
Технологічна модель процесу АВС
Аналіз застосовності практики інду-
стріального виробництва програм [3–5] у
вітчизняній програмній індустрії надає
вимоги до процесу АВС, конструктивні
для побудови його технологічної моделі:
− циклічне чергування цільових
етапів автоматизованого створення ПС у
межах СПС та сервісних – перегляду меж;
− несуперечне врахування поглядів
на межі СПС і характеристики ПС,
властивих усім учасникам процесу АВС;
− доступність кращих практик ін-
женерії СПС – для їх учасників, а даних
про стан СПС – для всіх зацікавлених
сторін згідно з їх ролями у процесі АВС.
− незалежність технологічної
моделі від цільової ПрО та організаційної
структури фірми-розробника СПС;
Методи та засоби програмної інженерії
− постійна вдосконалюваність;
− обґрунтованість та інформаційна
спадкоємність управлінських рішень з
організації процесу АВС.
Для побудови технологічної моделі
за цими вимогами, середовище керування
варіабельністю (1) – (7) поповнено банка-
ми даних щодо вищеописаних постановок
задач (FCF і FCA, RF і RA, AIEA); пре-
дикатів TG і моделей Q; моделей експерт-
но-аналітичного оцінювання (ЕM) [13].
Процес АВС визначено як компози-
цію операцій функцій керування варіа-
бельністю (F1 – F4), виконувану у попов-
неному модельному середовищі згідно з
поданнями ВГМ (10), (12), (13). Ці операції
доповнюють дії з використання ВГМ (опе-
рації F2): формуванням для ВГМ простору
проблеми та описом у ньому цільових ПС
(операції F1); аналізом отриманих арте-
фактів і РПВ для вчасного виявлення не-
адекватності СПС потребам ПрО (опера-
ції F3); актуалізацією СПС (операції F4).
Структуру отриманої технологічної
моделі процесу АВС показано на рис. 2.
Рис. 2. Склад та структура технологічної моделі процесу АВС
Рис. 2, а висвітлює внутрішню
структуру процесу АВС у цілому. Він де-
монструє подання процесу послідовністю
уніфікованих періодів автоматизованого
виробництва ПС зі складу СПС (обмеже-
них на рис. 2, а вертикальними штрихови-
ми лініями). У кожному періоді дії з ви-
робництва ПС виконуються учасниками
процесу АВС (AG) згідно з вкладеною
технологічною моделлю періоду (RM) у
спільному інформаційному середовищі
(EN). Пропоновані модель RM, середовище
EN та математичний апарат підтримки
функцій F1 – F4 (МА) забезпечують дотри-
мання вимог до них. Завдяки цьому, в
послідовних періодах постійно спадкують-
45
Методи та засоби програмної інженерії
46
ся кращі практики розроблення СПС і
керування ним, збережувані в репозиторії
RE і структурах знань середовища.
Період створення ПС починається з
одиничного цільового раунду визначення
меж СПС (поданого квадратом на рис. 2, а
і верхнім прямокутником – на рис. 2, б)
згідно з його моделлю (SM), вкладеною до
моделі періоду. Надалі виконується низка
цільових раундів автоматичного виробниц-
тва ПС у встановлених межах СПС згідно з
вкладеною моделлю (GM) (ці раунди пока-
зано ромбами на рис. 2, і нижнім прямо-
кутником – на рис. 2, б).
“На тлі” цих раундів здійснюються
сервісні раунди моніторингу стану СПС в
аспекті варіабельності згідно з вкладеною
моделлю MM (їм відповідають кільця спі-
ралі на рис. 2, а). Періодичність
моніторингу визначається поточно прий-
нятими умовами (MC). Якщо у такому ра-
унді виявлено виконання прийнятих умов
неадекватності стану СПС потребам ПрО
(AC), поточний період автоматизованого
виробництва ПС завершується сервісним
раундом актуалізації СПС за даними моні-
торингу (заокруглений квадрат на рис. 2, а)
згідно з вкладеною моделлю (AM).
На рис. 2, а показано функції керу-
вання варіабельністю, операції яких скла-
дають описані раунди. Для цільових раун-
дів ці операції деталізовано на рис. 2, б.
Внутрішню структуру описаної
технологічної моделі формалізує
Означення 10. Технологічна модель
процесу АВС є кортежем
TM = 〈 AG; EN; RM; MA; 〈MC, AC 〉〉,
RM = 〈 SM, GM, MM, AM 〉, (14)
MA = 〈〈 FCF∪FCA∪RF∪RA∪EA, μo〉;
〈AI; μI〉; 〈EM, μE〉; TG, Q 〉,
де μo – методи оптимізації; μI – аналізу
багатовимірних нечислових даних, μE –
експертно-аналітичного оцінювання [13]
для розв’язання задач, постановки й моделі
яких описано в попередньому розділі, в
складі математичного апарата МА.
Коло учасників процесу АВС (AG)
охоплює його безпосередніх виконавців –
фахівців фірми-розробника та зацікавлені
сторони – суб’єктів ПрО, на діяльність
яких впливають результати процесу.
Останні поєднують фахівців і підрозділи
фірми-розробника та суб’єктів функціо-
нально-цільових сегментів ПрО і ділового
середовища опосередкованого впливу про-
цесу АВС (див. рис. 2, а).
Розподіл складників середовища EN
(14) у просторах проблеми й рішень, а та-
кож поза ними висвітлює рис. 2, б. Згідно з
ним, середовище містить актуальний Звіт
про стан СПС в аспекті варіабельності та
чотири групи БД:
а) сховище артефактів і РПВ типів
t = 1,…,4 з їх паспортами (4) в репозиторії
RE та у поданні БД для ПС;
б) вкладене модельне середовище
керування варіабельністю у складі SV (1),
AS (2), (3), VM (5), (6);
в) поповнювані БД вищеописаних
постановок задач і моделей (FCF і FCA, RF
і RA, AI, EA, EM, Q, TG) на підтримку
операцій функцій F1 – F4;
г) ретроспективу перебігу процесу
АВС у складі БД протоколів цільових ра-
ундів (що фіксують обраний тип ВГМ і ре-
зультати розв’язання необхідних задач) та
протоколів моніторингу (які містять про-
філь варіабельності та результати розв’я-
зання задачі AI – дії з подолання виявленої
неадекватності ІСР потребам ПрО).
Звіт про стан СПС включає поточ-
ний профіль варіабельності (7), доцільні дії
з його актуалізації (обов’язкові й рекомен-
довані) та відомості про стан реалізації не-
завершених дій. Ці складники постійно ак-
туалізуються за поточними протоколами –
цільових раундів і моніторингу.
У міру виконання цільових і сервіс-
них раундів згідно з рис. 2, а формуються
їх динамічні локальні середовища, подані
на рис. 2, б. Відповідні БД в EN поповню-
ються уніфікованими результатами раун-
дів: виробленими РПВ, цільовими ПС і ар-
тефактами; формальними описами вимог
до ПС на всіх рівнях моделі SV (1); подан-
нями артефактів в AS (2); новими моделя-
ми й постановками; протоколами.
Ретроспектива результатів раундів,
структурована згідно з рис. 2, б та рольо-
вими повноваженнями виконавців поточ-
ного раунду певного типу, надається їм як
Методи та засоби програмної інженерії
джерело кращих практик виробництва ПС
(для цільових раундів) та підстав прийнят-
тя управлінських рішень з його організації.
Вкладені моделі SM і GM цільових
раундів утворені операціями функцій F1 і
F2 у процесах інженерії ПрО та, відповід-
но, застосунків, а також стратегіями їх за-
стосування. У моделі SM стратегія ϕ ∈ {h,
s, m} визначає можливості функції F1 з
поповнення меж СПС новими характери-
стиками в раунді визначення структури
СПС. Пропонуються три базові стратегії:
h – жорстка, за якої нові характе-
ристики не долучаються, але накопичують-
ся в проміжному ”портфелі” (аналогу back-
log у методології Scrum), щодо якого зада-
ча оптимального добору (у певній поста-
новці fc∈FCF) розв’язується в раунді акту-
алізації СПС, а отриманий перелік долуча-
ється до СПС у черговому раунді визна-
чення структури;
m – пом’якшена, за якої рішення
приймаються окремо для кожної харак-
теристики (неподільної групи характери-
стик) на підставі співвідношення витрат на
реалізацію за поточного стану СПС та від-
дачі від неї;
s – м’яка, за якої долучаються всі
характеристики, запитані споживачами.
У моделі GM стратегія ρ ∈ {h, s, m}
задає спосіб збереження конфігурованих
ПС та непрограмних артефактів (за вико-
ристання трансформаційної ВГМ) у репо-
зиторії RE:
h – жорстка стратегія, за якої ПС і
артефакти (розміщені в SW і ST відповідно,
див. (10)) не зберігаються у нових раундах;
m – пом’якшена, за якої до початку
раунду актуалізації зберігаються артефакт-
ти й ПС, достатньо цінні для повторного
використання у наступних раундах
виробництва ПС;
s – м’яка, за якої до раунду актуалі-
зації зберігаються всі артефакти й ПС.
Взаємозв’язки операцій з елемента-
ми середовища EN у просторах проблеми й
рішень та їхні результати висвітлено на
рис. 2, б. Модель SM подано темним
прямокутником вгорі (йому відповідають
квадрати на рис. 2, а; модель GM – світлим
прямокутником знизу (йому відповідають
ромби на рис. 2, а). Відображено також
аналогічну взаємодію для вкладених моде-
лей сервісних раундів (MM і AM), утворе-
них операціями функцій F3 й F4, які для
обох функцій виконуються у процесах ін-
женерії ПрО та застосунків поза цільовими
раундами.
Висновки
1. Запропоноване в роботі подання
процесу автоматизованого виробництва
сімейств програмних систем композицією
уніфікованих дій із забезпечення належної
варіабельності структури й артефактів сі-
мейства ПС – є перспективним насамперед
у предметних областях, суб’єктам яких
притаманні однакові базові потреби, але
різні вимоги до їх реалізації. Оскільки
вітчизняний ринок програмних продуктів є
наразі саме таким, побудована технологіч-
на модель може бути використана для
формування технологічного оснащення
вітчизняної програмної індустрії.
2. Побудована технологічна модель
є конструктивною для створення
технологічних модулів автоматизованого
виробництва програмних застосунків.
3. Реалізована описаним процесом
варіабельність програмних артефактів
(зокрема, готових продуктів) забезпечує їх
адаптовність до передбаченого спектра
змін умов експлуатації та повторного ви-
користання. У свою чергу, варіабельність
структури та ресурсів СПС підтримує його
еволюційність.
4. Відкритість пропонованого про-
цесу до ітеративного розширення меж
СПС і наявність єдиного інформаційного
середовища його формування сприяє залу-
ченню сучасних практик гнучкого розроб-
лення та інженерії співпраці.
5. Запропонована генерувальна мо-
дель дозволяє узгодити погляди учасників
процесу розроблення з різними ролями на
межі СПС та характеристики ПС. Вона та-
кож надає підґрунтя для розв’язання опти-
мізаційних задач ресурсно ефективного ке-
рування варіабельністю із залученням
методів теорії графів.
6. Запропонована технологічна мо-
дель сприяє запровадженню системи ме-
неджменту якості у фірмі-розробнику.
47
Методи та засоби програмної інженерії
48
1. Проект Стратегії інноваційного розвитку
України на 2010–2020 роки в умовах
глобалізаційних викликів. Офіційний сайт
Комітету Верховної Ради України з питань
науки і освіти. – Available at
http://kno.rada.gov.ua – 86 с.
2. Концепція державної цільової науково-
технічної та економічної програми
розвитку індустрії програмної продукції
України на 2012–2014 роки. Офіційний
сайт УкрНЦ РІТ – Available at
http://www.itdev.org.ua/.
3. Андон П.І., Лавріщева К.М. Розвиток
фабрик програм в інформаційному світі //
Вісник НАН України. – 2010. – № 10. –
C. 15–41.
4. Гринфилд Д., Шорт К. Фабрики разработ-
ки программ. Потоковая сборка типовых
приложений, моделирование, структуры и
инструменты. – Киев: Диалектика, Виль-
ямс, 2007. – 592 с.
5. Lenz G., Wienands C. Practical Software
Factories in .NET – Apress, 2006. – 214 p.
6. Pohl K., Böckle G., Linden F.J. Software
Product Line Engineering: Foundations,
Principles and Techniques. – New York:
Springer-Verlag. – 2005. – 437 p.
7. Лавріщева К.М., Слабоспицька О.О.,
Колесник А.Л., Коваль Г.І. Теоретичні
аспекти керування варіабельністю в
сімействах програмних систем // Вісник
КНУ ім. Т. Шевченка. Сер.фіз.-мат. науки.
– 2011. – № 1.
8. Asikainen T., Männistö T., Soininen T. A
Unified Conceptual Foundation for Feature
Modelling // in Proc. of the 10th Int. Software
Product Line Conf. (SPLC 2006). – 2006. –
P. 31 – 40.
9. Лавріщева К.М. Генерувальне програмуван-
ня програмних систем і сімейств // Проб-
леми програмування. – 2009.– № 1. –
С. 3–16.
10. Чернецки К., Айзенекер У. Порождающее
программирование. Методы, инструменты,
применение.– Издательский дом Питер. –
М. – СПб. – Харьков. – Минск. – 2005. –
730 с.
11. Лавріщева К.М., Коваль Г.І., Слабоспицька
О.O., Колесник А.Л. Особливості процесів
керування при створенні сімейств
програмних систем // Проблеми
програмування. – 2009. – № 3. – С. 40–49.
12. Колесник А.Л. Механізми забезпечення ва-
ріабельності в сімействах програмних си-
стем // Проблеми програмування. – 2010. –
№ 1. – C. 35–44.
13. Лаврищева Е.М., Слабоспицкая О.А. Подход
к экспертному оцениванию в программной
инженерии // Кибернетика и системный
анализ. – 2009. – № 4. – С. 151–168.
Отримано 17.01.2011
Про авторa:
Слабоспицька Ольга Олександрівна,
кандидат фізико-математичних наук,
старший науковий співробітник.
Місце роботи автора:
Інститут програмних систем
НАН України,
03187, Київ-187,
Проспект Академіка Глушкова, 40.
Тел.: (044) 526 4579.
e-mail: ols.07@mail.ru
http://www.ozon.ru/context/detail/id/856497/
http://www.ozon.ru/context/detail/id/856490/
http://www.ozon.ru/context/detail/id/856490/
http://www.amazon.com/Practical-Software-Factories-Books-Professionals/dp/159059665X##
http://www.amazon.com/s/ref=ntt_athr_dp_sr_2?_encoding=UTF8&sort=relevancerank&search-alias=books&field-author=Christoph%20Wienands
http://www.amazon.com/s/ref=ntt_athr_dp_sr_2?_encoding=UTF8&sort=relevancerank&search-alias=books&field-author=Christoph%20Wienands
|