Conception of industry scientific software to decision scientific tasks
The analysis state and using factories in industrial developing software are done. Basics of fabric scientific software and ground them to decision task are proposed. Industrial approach to computing of different scientific tasks e–science is elaborated. New disciplines for production program artif...
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/793 |
| 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-793 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/f6/b577c9425ba70b18ac0c900fc6bacff6.pdf |
| spelling |
pp_isofts_kiev_ua-article-7932025-09-02T15:47:58Z Conception of industry scientific software to decision scientific tasks Концепція індустрії наукового софтвера і підхід до обчислення наукових задач Lavrischeva, K.M. UDC 681.3 УДК 681.3 The analysis state and using factories in industrial developing software are done. Basics of fabric scientific software and ground them to decision task are proposed. Industrial approach to computing of different scientific tasks e–science is elaborated. New disciplines for production program artifacts, reuses and training those students on specialties of informatics and Computer Sciences are development.Prombles in programming 2011; 1: 3-16 Дано аналіз сучасного стану і застосування фабрик в індустріальному виробництві програмної проду кції. Запропоновані базові складові фабрики наукового софтвера, обґрунтовано їх зміст і призначення у рішенні наукових завдань. Розглянуто підхід до індустрії обчислень різних наукових задач. Сформу льовані нові дисципліни з індустріального виробництва програмних артефактів і reuses та навчання цим дисциплінам студентів за відповідними спеціальностями з інформатики і Computer Sciences.Prombles in programming 2011; 1: 3-16 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2025-08-28 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/793 PROBLEMS IN PROGRAMMING; No 1 (2011); 3-16 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 1 (2011); 3-16 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 1 (2011); 3-16 1727-4907 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/793/845 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 Lavrischeva, K.M. Conception of industry scientific software to decision scientific tasks |
| topic_facet |
UDC 681.3 УДК 681.3 |
| format |
Article |
| author |
Lavrischeva, K.M. |
| author_facet |
Lavrischeva, K.M. |
| author_sort |
Lavrischeva, K.M. |
| title |
Conception of industry scientific software to decision scientific tasks |
| title_short |
Conception of industry scientific software to decision scientific tasks |
| title_full |
Conception of industry scientific software to decision scientific tasks |
| title_fullStr |
Conception of industry scientific software to decision scientific tasks |
| title_full_unstemmed |
Conception of industry scientific software to decision scientific tasks |
| title_sort |
conception of industry scientific software to decision scientific tasks |
| title_alt |
Концепція індустрії наукового софтвера і підхід до обчислення наукових задач |
| description |
The analysis state and using factories in industrial developing software are done. Basics of fabric scientific software and ground them to decision task are proposed. Industrial approach to computing of different scientific tasks e–science is elaborated. New disciplines for production program artifacts, reuses and training those students on specialties of informatics and Computer Sciences are development.Prombles in programming 2011; 1: 3-16 |
| publisher |
PROBLEMS IN PROGRAMMING |
| publishDate |
2025 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/793 |
| work_keys_str_mv |
AT lavrischevakm conceptionofindustryscientificsoftwaretodecisionscientifictasks AT lavrischevakm koncepcíâíndustríínaukovogosoftveraípídhíddoobčislennânaukovihzadač |
| first_indexed |
2025-09-17T09:22:58Z |
| last_indexed |
2025-09-17T09:22:58Z |
| _version_ |
1850412000867254272 |
| fulltext |
Теоретичні та методологічні основи програмування
3
УДК 681.03
К.М. Лавріщева
КОНЦЕПЦІЯ ІНДУСТРІЇ НАУКОВОГО СОФТВЕРА
І ПІДХІД ДО ОБЧИСЛЕННЯ НАУКОВИХ ЗАДАЧ
Дано аналіз сучасного стану і застосування фабрик в індустріальному виробництві програмної проду-
кції. Запропоновані базові складові фабрики наукового софтвера, обґрунтовано їх зміст і призначення
у рішенні наукових завдань. Розглянуто підхід до індустрії обчислень різних наукових задач. Сформу-
льовані нові дисципліни з індустріального виробництва програмних артефактів і reuses та навчання цим
дисциплінам студентів за відповідними спеціальностями з інформатики і Computer Sciences.
Вступ
Виходячи з матеріалів державної
цільової науково-технічної та економічної
програми розвитку індустрії програмної
продукції (ПП) України на 2012–2014 рр.
(www.itdev.org.ua), внесок індустрії ПП у
світовому виміру перевищує 100 млрд.
дол. Але в Україні він містить десь 1.0 %
за рахунок ринку програмістських послуг
закордонним фірмам, обсяг експорту якого
становить значно більший процент. Дана
програма ставить задачу економічного та
соціального розвитку суспільства за раху-
нок підвищення індустрії ПП шляхом кон-
солідації наукових та підготовлених у ву-
зах спеціалістів до потреб держави в інду-
стрії національної ПП шляхом інвестицій.
Це відкриє шлях до накопичення і продажу
виготовлених цими спеціалістами різних
видів наукових артефактів і ПП, починаю-
чи з Вузів, аспірантур і завершаючи науко-
во-дослідним інститутом.
Ідею індустрії комп’ютерів і ПП
сформулював академік В.М. Глушков в
Інституті кібернетики (1975 р.). За його
ініціативою розвиток індустрії у СРСР
ознаменувався побудовою низки комп’ю-
терів (Днепр–1, Днепр–2, серії машин
«Мир» тощо), створенням фондів алгорит-
мів і програм (1978 р.), постановою про
ПП як продукції промислово-технічного
призначення (1984 р.) та про державне ін-
вестування науково-дослідних інститутів
усіх союзних республік ГКНТ СРСР,
спрямоване на автоматизацію засобів ви-
робництва ПП (1980–1990) та на обгово-
рення різних шляхів організації індустрії
ПП на всесоюзних конференціях (1980–
1991) тощо.
В результаті були розроблені не
тільки засоби автоматизації ПП, але і кон-
кретні системи АСУ, АСУ ТП для різних
галузей промисловості за методом збірки
готових програм із фондів [1–3]. Перша
фабрика (або програмно-будівельний ін-
ститут у Калініні – 1982 р.) проіснувала
біля двох років. На той час не було визна-
чено формального базису такого підприє-
мства, готові програмні ресурси з фондів
були частково незавершені, як програми
повторного використання або невдоскона-
лені для автоматизованої збірки. Поняття
інтерфейсу різних програм ще не було ви-
значено, а тільки сформувалося як необ-
хідний елемент збірки.
Нині склалися усі необхідні умови,
а саме, накопичено велику кількість різно-
манітних програмних ресурсів у електро-
нних бібліотеках, зокрема, і наукових, як
елементів індустрії наукового софтвера,
дуже потрібних Європейському проекту
Grid, почали діяти конкретні фабрики про-
грам різного призначення та сформовані
базові складові індустріального виробниц-
тва ПП з компонентів повторного викорис-
тання (КПВ) [4, 5].
У роботі дається визначення основ
фабрики – понять, змісту і сутності індуст-
рії наукового софтвера (e–science – фізика,
математика, біологія тощо), який створю-
ється на різних математичних артефактах,
розроблених на відповідних кафедрах уні-
верситетів та науково-дослідних інститутів
України з метою обчислювання наукових
завдань з різних напрямів e–science глоба-
льного характеру. Для накопичення гото-
вих програмних ресурсів і артефактів для
їх повторного використання розроблені
© К.М. Лавріщева, 2011
ISSN 1727-4907. Проблеми програмування. 2011. № 1
Теоретичні та методологічні основи програмування
4
міжнародні стандарти з сертифікації про-
грам, ПП та їх інтерфейсів. Вони розмі-
щуються в бібліотеках, репозиторіях ін-
ститутів або Інтернету, як сховищ загото-
вок наукової продукції у галузі інформати-
ки та Computer Science [5] для застосуван-
ня їх як об’єктів індустрії ПП і обчислень.
1. Головні складові сучасних фа-
брик програм
Сутність виробництва продукції.
Виробництво – це процес автомати-
зованого створення матеріальних благ, не-
обхідних для задоволення індивідуальних і
соціальних потреб деяких прошарків сус-
пільства. Виробництво ПП орієнтоване на
виготовлення продукції, потрібної науко-
вцям, фахівцям комп’ютерних галузей під-
приємств тощо. Це виробництво ґрунту-
ється на готових технічних і людських ре-
сурсах. Одним з найважливіших технічних
ресурсів фабрики програм є готові програ-
мні артефакти, алгоритми і програми бага-
торазового використання (компоненти,
сервіси, КПВ, reuses, assets і т. п.).
Рівень виробництва деякої продук-
ції залежить від обсягу використаних ре-
сурсів і обчислюється за функцією вигля-
ду: v = F (z , u),
де v = (vi) – вектор випуску продукції,
z = (zi) – вектор витрат ресурсів, u = (ui) –
матриця параметрів залежності функції
витрат z = F(wj, u), j = 1, 2, .., n. Показники
функції wj відповідають обсягові виробни-
цтва, структурі виробничих фондів та рів-
ню спеціалізації фабрики, їх значення для
рівня спеціалізації фабрики формуються,
як правило, статистично.
Загальна виробнича статечна фун-
кція випуску продукції Кобба–Дугласа
v = ne rt Lα K β ,
де v – узагальнений випуск; n – норма-
тивний множник; e – основа натурального
алгоритму; t – показник рівня науково-
технічного прогресу; L – витрати людської
праці; Κ – величина капіталу; α, β – коефі-
цієнти еластичності [6].
Розрахунки цих функцій дають оці-
нки доходної частини, зокрема і саме фаб-
рики програм. Економічність, системність
та пропорційність випуску ПП залежить
від принципів організації і керування ре-
сурсами, визначення номен-клатури про-
дукції, застосування комп'ютерів, людсь-
ких ресурсів та персоналу з обслуговуван-
ня фабрики (контролю вимог, специфіка-
цій, процесів тестування, оцінювання ПП й
ін.).
В Україні нині діють окремі неве-
ликі організації і фірми з розроблення ПП,
які орієнтовані на випуск в основному
одиночних продуктів для окремих замов-
ників, як правило, закордонних. Фірми з
успадкування ПП, що покривають значний
фрагмент ринку ПП, теж працюють в ос-
новному для закордонних держав, а не для
потреб різних підприємств.
Для першого попиту концепції ін-
дустрії ПП запропоновано створити студе-
нтську фабрику програм на факультеті кі-
бернетики в КНУ імені Тараса Шевченка.
Ставиться мета залучити студентів для по-
стачання на фабрику наукових артефактів і
готових ресурсів відповідних кафедр, їх
апробації на продуктовій лінії та розпо-
всюдження не тільки на вітчизняному рин-
ку, але з часом і закордонному.
Під фабрикою програм розуміється
інтегрована інфраструктура зі зборкою го-
тових ресурсів у ПП, потрібних держав-
ним, науковим, комерційним та іншим за-
мовникам. Фабрика обладнується продук-
товими лініями, набором засобів, інстру-
ментів і сервісів для автоматизованого ви-
конання процесів на цих лініях у опера-
ційному середовищі. Дане у [7] визначення
фабрики таке: фабрика програмного забез-
печення – це погоджений набір процесів,
засобів і інших ресурсів для прискорення
усього циклу створення тих чи інших про-
грамних компонентів, застосувань і сис-
тем.
Фабрика надає середовище, орієн-
товане на автоматизацію виробництва
продукту. З погляду інформаційних техно-
логій фабрика дає набір інструментів для
переходу до індустрії ПП із метою збіль-
шення продуктивності розробки продукту
на кожному етапі життєвого циклу із зада-
ними функціями, архітектурою і якістю.
Фабрики повинні мати продуктові лінії й
відповідний набір засобів розробки, виро-
бництва простих і складних ПП. Лінія ро-
Теоретичні та методологічні основи програмування
5
зробки простих продуктів, як правило, від-
повідає ЖЦ, наприклад, реалізованому в
середовищі MS.Net з використанням реко-
мендацій, каркасів (framework), DSL–мов
(Domain Specific Language) та інших ін-
струментів. Лінія виготовлення складних
ПП фактично є збіркою готових програм-
них ресурсів, що знаходяться в різних біб-
ліотеках і репозиторіях та відповідають
критеріям їх відбору.
Виходячи з отриманої практики ав-
томатизованого збирання різнорідних про-
грам у мовах програмування (МП) в сере-
довищі ОС ЄС [1–3] і досвіду сучасних за-
кордонних фабрик програм з індустрії ПП
(IBM, OMG, Microsoft, Oberon тощо) [4, 5,
7] сформувалися загальні складові зборки,
що характеризують в основному всі відомі
й майбутні фабрики програм:
– готові програмні ресурси (артефак-
ти, програми, компоненти, системи, reuses,
assets, КПВ) тощо;
– інтерфейс, специфікований паспор-
тними даними готових різнорідних ресур-
сів, незалежно від МП, особливою мовою
специфікації інтерфейсу (наприклад, IDL,
API, SIDL, WSDL, RAS тощо) [8, 9];
– операційне середовище, насичене
системними програмними засобами і ін-
струментами для підтримки індустріальної
збірки різнорідних ресурсів [4];
– технологічні лінії (ТЛ) або продук-
тові лінії (Product Lines) [10, 11] з вироб-
ництва ПП.
Ці складові були визначені нами і
розвинуті в рамках фундаментальних про-
ектів Інституту кібернетики (1980–1991) і
ІПС НАН України (1992–2010). В них упе-
рше визначено концепцію інтерфейсу
(1982, [3, 8]), метод збірки різномовних
компонентів попередили появу індустріа-
льних складових програм, ТЛ (1987–1991,
[1, 10]) та засоби автоматизації випуску
ПП [2, 3]. Вони попередили появу складо-
вих з виробництва ПП закордонними фір-
мами, наприклад, IBM, Microsoft, Oberon
та ін.
Далі дається формальне тлумачення
наведених складових індустрії ПП, підхо-
дів до навчання IT–спеціалістів усім про-
блемам індустрії у цілях застосування сту-
дентів у сфері наукового софтвера.
1.1. Готові компоненти і їх інтер-
фейси. Програмні ресурси, які можуть ви-
користовуватися багаторазово, називають
reuse, assets, КПВ, програми тощо. Вони
відображають реалізацію різних приклад-
них або математичних функцій деякої нау-
кової (фізика, математика, біологія тощо)
або прикладної предметної області. Голо-
вна парадигма КПВ – «писати один раз,
виконувати багато разів, де завгодно». Ар-
хітектура, в яку вбудовується готовий ре-
сурс, використовує стандартні механізми
роботи з ним, як із будівельними блоками.
Щоб забезпечити високу ефективність по-
вторного використання, вони мають бути
якісними і надійними при виконанні.
Як готові ресурси можуть викорис-
товуватися формалізовані артефакти дія-
льності розробників програм, які відобра-
жають певну функціональність. Під арте-
фактом розуміється реальна порція інфо-
рмації з програмування, яка може створю-
ватися, змінюватися і використовуватися у
діяльності, пов’язаної з виготовленням ПП
різного призначення. Артефактами можуть
бути:
– модель предметної області (ПрО) зі
своїми термінами, поняттями та лексикою;
– готові КПВ або окремі частини
(фрагменти) систем;
– проміжні продукти процесу розроб-
лення (вимоги, завдання, моделі та ін.);
– специфікації (ресурсу, інтерфейсу,
моделі і т.п.) окремих елементів, діаграм,
паспортних даних і т. п.
Артефакти незалежні від платформ
комп’ютерів, мають опис інтерфейсів і різ-
них параметрів для взаємодії з іншими ре-
сурсами.
Усі ресурси та їхні інтерфейси збе-
рігаються у сховищах (бібліотеках, репо-
зиторіях) для подальшого пошуку іншими
фахівцями з метою подальшого застосу-
вання. Тобто, повторне використання стає
капіталомістким видом діяльності на фаб-
рики ПП.
Студентська фабрика, на наш по-
гляд, повинна мати три базові лінії.
Перша лінія як схема процесів ста-
ндартного ЖЦ з побудови деякого програ-
много ресурсу шляхом:
Теоретичні та методологічні основи програмування
6
– вивчення завдань ПрО, виявлення
серед них загальних властивостей і функ-
цій та методів породження з них програм-
них елементів;
– специфікація цих елементів МП і
паспортних даних їх інтерфейсів;
– зберігання ресурсу в репозиторію.
Реалізація процесів такої лінії за-
кінчується визначенням сформованих ар-
тефактів або ресурсів у класі задач ПрО,
специфікацією паспортних даних та роз-
міщенням описів ресурсів у репозиторії
для подальшого застосування. Ця лінія по-
требує вкладення капіталу в розробку нау-
кових артефактів. Такого типу лінії розро-
бляється на студентській фабриці у вигляді
життєвого циклу створення програм у се-
редовищі Visual Studio .Net (рис. 1).
Друга лінія – це механізми підбору
готових ресурсів із репозиторію за їхніми
функціями і відповідними критеріями з
метою оцінки можливості їх застосування
у деякої предметної області як готових
елементів.
Третя лінія – збіркова лінія, що за-
безпечує конструювання нових ПП мето-
дом збірки з застосуванням розроблених і
підібраних ресурсів за шляхами:
– визначення цілей і вимог до майбу-
тньої ПП та до окремих елементів збірки;
– аналіз готових ресурсів, перевірка
їх життєздатності і результату для оцінки
їх потреби у нової системи;
– прийняття рішень про доцільність
застосування ресурсу та його збереження
у репозиторію;
– зборка ресурсів за їхніми інтерфей-
сами у ПП, тестування зв’язків та систе-
ми.
Ця лінія буде давати прибуток за
рахунок заощадження трудовитрат від за-
стосування готових артефактів та КПВ за
оцінкою ефективності їх використання і
обсягів повернення цього вкладення в но-
вий ПП. Ресурс може бути науковим, при-
кладним і загальносистемним. Перший ре-
сурс – це метод або науковий алгоритм (з
математики, фізики, біології тощо), що
описаний загальною МП; другий ресурс –
реалізація окремої задачі або функції ПрО
(бізнесу, комерції, економіки і т. п.); зага-
льносистемний ресурс – це готові засоби,
потрібні всім – транслятор, редактор текс-
тів, генератор, інтегратор, завантажувач,
сервіс з обміну даних, передач повідом-
лень тощо. Зміст даної лінії в основному
відповідає лінії збірки (рис.1).
Інтерфейс програмних ресурсів.
Під інтерфейсом розуміється зв’язок двох
окремих сутностей. Інтерфейси є програм-
ні, апаратні, мовні, користувальницькі,
цифрові й т.п. Програмний (API) і/або апа-
ратний інтерфейс (port) є способом пере-
творення вхідних/вихідних даних під час
зв’язку комп'ютера з периферійним устат-
куванням. У програмуванні інтерфейсом є
програма або її частина, в якій визнача-
ються дані (константи, змінні, параметри й
структурні типи даних тощо) для передачі
їх іншим програмам зі значеннями їхніх
параметрів [8].
У ролі операцій інтерфейсу висту-
пає виклик процедур і функцій у МП з за-
вданням їх імен і списку формальних па-
раметрів для передачі фактичних значень
для виконання. Послідовність і число фор-
мальних параметрів мають відповідати фа-
ктичним параметрам. Коли програма, про-
цедура або функція специфіковані різними
МП і вони розташовані на різних комп'ю-
терах, то вирішується проблема неоднорі-
дності поданих їх типів даних, відмінності
архітектур комп’ютерів або операційних
середовищ та несумісності параметрів за їх
кількістю та порядком розташування.
Теоретичні та методологічні основи програмування
7
Розробка
вим ог П роектування Тестуванн я Істаляц ія З апис
продук ту
В им оги П рогр ам а В ідм ови ,
помилки Н а даних
П ідб ір го тових
ком понент ів
Зб ірник
го тових
ком понент і
М оделю -
вання звязк ів
Т естування
СПС
О ц інка яко ст і
ін струм ент ів та
п ід си стем
продукту
КПВ 1 , КПВ 2 ... Зб ір ковий
продукт Ін терф ейс
К іл ьк ість Н ад ійн ість
Я к ість
С ер тиф ікат
п родукту
П ерев ір ка план ів і строк ів
БП
проек та
1 . Л ін ія виробництва окр ем их ПП в M S .N et
3 . Л ін ія зб ірки програм , КПВ у с ім ей ство ПП
2 . Л ін ія запи су ком пон ент ів і сп ециф ікатор ів у БП .
Виб ір готових КПВ з БП
Рис. 1. Структура загальних ліній фабрики програм
Інтерфейс – фактично посередник
або “перехідний мостік” між двома моду-
лями. Він передає дані і виконує необхідне
пряме й зворотне перетворення даних у
випадку їх неоднорідності та невідповід-
ності.
Кожний програмний ресурс має
специфікуватися паспортними даними за
деякими стандартами [12–14]:
– назва ресурсу;
– ID – ідентифікатор ресурсу;
– зміст програми (функції);
– параметри виклику інших ресурсів;
– інструменти підтримки виконання
програмного ресурсу тощо.
Необов'язкові атрибути паспорту: дата,
стан, версія, автор, дата створення, термін
придатності і тому подібно. Інтерфейс
може містити опис точок зі зв'язками з де-
якими послугами, точками для внесення
змін і взаємодії ресурсів у середовищі та
додавання деяких аспектів (наприклад, си-
нхронізації, захисту) тощо. Специфікації
інтерфейсів зберігаються у бібліотеці або
репозитарію інтерфейсів для майбутньої
збірки з них програм.
Для включення студентських про-
грамних артефактів у репозитарій розроб-
лено спеціальний шаблон специфікації ін-
терфейсів, позиції якого заповнюються
студентами при запису кожного артефакту
в деякий його розділ.
1.2. Операційне середовище з засо-
бами і інструментами для збірки ПП.
Виходячи з аналізу діючих фабрик про-
грам [4], дамо класифікацію середовищ з
залежності від типу взаємодії, що обирає-
ться для фабрики, як базове:
1) через брокер запитів між клієнтом
і сервером, щодо отримання даних від stub
клієнта, їх обробку під формати комп’ю-
тера, передачу їх серверу і зворотно від
skeleton сервера, що обробляє результати
обчислювань до форматів даних клієнта;
Теоретичні та методологічні основи програмування
8
2) через проміжний прошарок зага-
льносистемних засобів, сучасних середо-
вищ або віртуальних серверів хмарних об-
числень [15, 16];
3) через пряму зборку трансльова-
них програм за різними МП і їх інтерфей-
сами у бібліотеках, наприклад, MS.Net.
Перший тип взаємодії практично
забезпечується брокером ORB для класу
МП у середовищі CORBA. Зборка компо-
нентів базується на Client class з виклика-
ми інших, Stub class з конвертування да-
них, ORB class з передачі даних; Server
class зі створення сервентів та посилання
даних ORB; Skeleton class з конвертування
форматів даних та породження різних ви-
дів серверів.
Другий тип забезпечує взаємодію
між компонентами, розміщеними на різних
комп’ютерах через проміжний прошарок
(middleware) шляхом повідомлень (напри-
клад, Java Message Queue), віддаленого ви-
клику процедур RPC в MS Windows, ONS
IBM, CORBA та виклику методів RMI у
Java. Модель ISO/OSI також забезпечує
проміжну взаємодію на рівнях (фізичному,
канальному, мережному і транспортному)
мережної ОС. Верхній рівень моделі (при-
кладний) забезпечує перетворення даних
до транспортного рівня шляхом їх марша-
лінгу й демаршалінгу за інтерфейсним
stub. Сеансовий рівень моделі передає дані
іншим рівням через транспортний канал за
механізмами посилань. Технологія розпо-
діленої обробки отримала новий віртуаль-
ний прошарок між Internet і засобами
Cloud Computing [16], що подає сервіс з
обробки даних великих розмірів у режимі
online з віртуальних серверів Google Apps,
Windows Cloud, Amazon Web–services,
Sky–driven, Azure (www.cmswire.com).
Третій тип реалізований в MS.Net
за допомогою таких бібліотек системи:
CLR (Common Language Runtime),
CTS (Common Type System) і CLS (Com-
mon Language Specification). CLR забезпе-
чує виявлення і завантаження даних, керу-
вання ними у відповідності до завдань ро-
зробника програми. CTS визначає принци-
пи взаємодії із іншими, відповідно пред-
ставлення форматів мета-даних. Збірка рі-
зномовних програм виконується засобами
CLS бібліотеки. Усі компілятори з МП
створюють модулі DLL або EXE у промі-
жній мові MSIL (Microsoft Intermediate
Language) як механізм збірки програми
незалежно від платформи, на якій вона бу-
де виконуватися. При її запуску вона кон-
вертується в специфічний код CPU, що ви-
конується на різних архітектурах
комп’ютерів.
Для побудови програм на студент-
ській фабриці програм обрано Visual Stu-
dioMS.Net. У цієї системи є багато різних
інструментів, зокрема, Веб-сервіси різного
призначення, пакет VSTS для збірки і ке-
рування конвеєрним методом розробки
програм, вимірювання й оцінювання їх
якості.
Таким чином, у залежності від ці-
лей фабрики програм як середовище виби-
рається те середовище, що найбільш під-
ходить для організації процесу побудови і
зборки відповідних програмних ресурсів у
межах деякої ПрО. Коло проблем звужу-
ється, коли різні середовища можуть взає-
модіяти між собою, створюючи одне вели-
ке, гнучне середовище з поширеними мо-
жливостями щодо виробництва кінцевого
ПП.
1.3. Структура і зміст ліній виро-
бництва ПП. Підхід до побудови ТЛ. Пі-
сля аналізу ПрО й виявлення її основних
функцій будується деяка загальна ТЛ за
процесами ЖЦ. Для ній підбираються го-
тові програмні ресурси, засоби й інструме-
нти породження із функцій програм та
планування і контролю процесами щодо
формування шаблонів фіксації проектних
рішень, зміни станів і оцінювання якості
ПП [3, 7, 10].
Процеси ТЛ будуються з урахуван-
ням міжнародного стандарту ISO/IEC
12207–96, 2007 і ДСТУ 3918–99, підкріп-
люються відібраними методами, засобами
й інструментами для здійснення змін ста-
нів об’єктів на процесах. Цей підхід до по-
будови ТЛ апробований в АІС «Юпітер»
(1987–1991). На новому витку історії роз-
витку індустрії виникли продуктові лінії
[11], принципи побудови й виконання яких
аналогічні ТЛ, що слугують індустрії ви-
робництва студентських програмних арте-
фактів за лініями, наведеними на рис. 1.
http://www.cmswire.com/
Теоретичні та методологічні основи програмування
9
На ньому лінія 1 ініціює первинний процес
з виробництва ПП із готових ресурсів з
метою задоволення потреб деякого фраг-
менту ринка ПП. Лінія 2 призначена для
накопичення КПВ з паспортними даними
(специфікаторами) у бібліотеки і спрощен-
ня їх пошуку з метою використання на лі-
нії 3 зборки з них ПП.
На кожної лінії враховуються:
– умови та обмеження ресурсів;
– шаблони та набір готових ресурсів
(КПВ, reuses, assets тощо);
– стратегії та МП;
– необхідні засоби і інструменти;
– плани робіт з використання техніч-
них ресурсів;
– методики виміру та оцінювання по-
казників ПП якості;
– сертифікат ПП.
Наведені на рис. 1 типи ліній вироб-
ництва ПП для фабрики не обмежені. Де-
яка фабрика може бути зорієнтована на
спеціальні лінії функціонального типу, на-
приклад, на створення програм із класу
задач статистичної обробки, деяких чисе-
льних методів, принципи розробки яких
було подано в [2, 4, 10].
1.4. Обслуговування фабрики. До
складу фабрики входять групи розробни-
ків і спеціалістів сервісного обслугову-
вання, що наведені в таблиці. Крім цих
спеціалістів можуть бути й інші, а також
технічний персонал, що запускає інстру-
менти і засоби підтримки ТЛ. Керівництво
програмними проектами і ресурсами на
фабрики виконує менеджер або директор.
Таблиця. Персоналу фабрики
Розробники Обслуговуючий
персонал
Аналітики,
програмісти,
тестери,
верифікатори,
експерти,
вимірники якості
Плановики,
економісти,
бухгалтери,
контролери,
оцінювачі процесів і
ПП,
сертифікатори,
пакувальники ПП
2. Нові індустріальні підходи щодо
обчислення наукових задач
Нові індустріальні підходи з’яви-
лися у зв’язку з бурним розвитком високо-
ефективної елементної бази, нової багато-
ядерної, процесорної конфігурації комп’ю-
терів. Це сприяє великомасштабним обчи-
сленням дуже складних задач сучасності в
e-sciences (геології, біології, фізики, мате-
матики і др.), АСУ і інших галузях проми-
словості. Комп’ютерна індустрія більш
ніж на порядок опереджає розвиток як з
теоретичної, так і з практичної точки зору
інші види індустрії, а саме, індустрія об-
числень, систем і програм.
Індустрія обчислень у теоретич-
ному плані іде за шляхом застосування но-
вих комп’ютерних можливостей щодо
швидкості дій і розподілення пам’яті для
обчислення задач з великими обсягами да-
них. Вона отримала також новітні базові
засоби з організації прозорих обчислень
різного роду складних задач за рахунок
розвитку нових моделей: взаємодії OSI,
генерації GDM, архітектури SOA,MDA,
розробки DDM тощо, так званих, хмарних
обчислень (Cloud Computing, SkyDriven),
що підтримуються Веб-стандартом
HTML5 з високо пропускними протоко-
лами доступу до загальних on-line сховищ
даних з деякого місця нашої планети. Ар-
хітектура системи за моделлю MDD
(Model Driven Development) моделюється
на двох рівнях – платформи незалежного
рівня PIM (Platform Independent Model) і
платформи залежного рівня PSM (Platform
Specific Models). Концепція дворівневого
моделювання архітектури MDA (Model
Driven Architecture) і відображення
PIM→PSM відповідає ідеології побудови
сімейства систем СПС мовою DSL для
опису понять і задач з простору проблем
предметної області [4, 9].
Одним з практичних рішень забез-
печення індустрії обчислень є поява сис-
теми Grid у 2006 р. в межах Європейсь-
кого проекту. Цю систему було розроб-
лено як інфраструктуру для глобальних
обчислень суперскладних задач з області
e-science. Для обчислень таких задач за-
стосовуються знов розроблені або готові
програмні й системні ресурси виду: роз-
поділені процесорні потужності; системи
сховищ даних; новітні засоби комунікації;
фонди reuses з багатьох доменів; нові тех-
нічні устаткування і загальні «тули» (кон-
Теоретичні та методологічні основи програмування
10
вертори, генератори, трансформатори, ве-
рифікатори тощо); моделі та схеми взає-
модії програм у середовищі гетерогенних
платформ, географічно розташованих у
віддалених адміністративних доменах то-
що. Середовище Grid як інфраструктура
обчислень різних наукових задач пропонує
підсистему ETICS для організації зборки
різнорідних і різноплатформених програм
рішення задач за їх описом МП або мовою
DSL (рис. 2).
Модель конфігурації СПС
Простір проблем задачі
- Поняття ПрО і їх властивості
- Зв’язування властивостей
- Залежності з умовчування
Опис члена сімейства у
DSL,
вибір властивостей
і їх конфігурування
Простір рішень задачі
- Множина компонентів, reuses
реалізації
- Схема зборки готових компонентів
- Варіанти архітектури
членів сімейства СПС
Опис конфігурації
компонентів членів
сімейства
Відобра-
ження
Правила
конфігурування і
оптимізації
структури
ПП
Перебудова
конфігурації
властивостей у
конфігурації
компонентів
Оптимізація конфігурації
компонентів реалізації за
нефункціональними
вимогами
Рис. 2. Модель завдання опису і рішення
задач
Завдання з обчислення задач вико-
нуються із застосуванням різних систем-
них і прикладних сервісів Інтернету і дося-
гнення максимальної продуктивності рі-
шення задач глобального масштабу
[15, 16].
Іншим напрямом практичного об-
числення задач глобального типу є хмарні
обчислення, які підтримуються новими за-
собами Cloud Computing системами IBM-
VSphere та системами Microsoft – WCloud,
Azure, Amazon, Mech, WАpps, SkyDriven
(Http://lenta.ru/articles/2010).
Вони зорієнтовані на збереження
даних, доступ до глобальних сховищ да-
них on-line, синхронізацію даних великих
розмірів і викладання їх на віддалені сер-
вери тощо. Тут головна проблема органі-
зації обчислень потребує визначення но-
вих методів, таких як координація, коопе-
рація та взаємодія різних сервісів і інших
готових ресурсів через конфігураційний
файл для виконання обчислень відповід-
них задач.
Накопичення готових ресурсів у рі-
зних глобальних сховищах для доступу до
них різних наукових користувачів потре-
бує розвитку індустріальних методів і мо-
делей з урахуванням особливостей і спе-
цифіки наукових задач. Індустрія ПП,
концепція якої подано у попередніх розді-
лах роботи, теж базується на готових зви-
чайних компонентах (артефактах, reuses,
assets і даних) багаторазового використан-
ня, що знаходяться у різних бібліотеках,
репозиторіях та нових «хмарних» схо-
вищах Інтернету. Головним методом інду-
стрії наукових продуктів буде удоскона-
лений метод зборки наукових різнорід-
них ресурсів, що належить до напрямів
e-science, в структури ПП, котрі після їх-
нього виготовлення можуть бути подані
на різні глобальні сервери для їх застосу-
вання при рішенні відповідних наукових
задач.
Іншим індустріальним підходом є
модельний підхід, якій широко використо-
вується нині в програмної інженерії. Нами
запропоновано набор моделей в межах
фундаментального проекту ІПС НАН
України (III–1–07 “Розробка теоретичних
основ генеруючого програмування (ГП) та
інструментальних засобів його підтримки”
(2007–2011) [17] для організації процесів з
виробництва і виконання ПП. Цей набір
включає: модель взаємодії, модель варіа-
бельності і модель життєздатності.
У межах проекту розроблено їх
зміст і місце в СПС, а також методи і засо-
би для їх використання на сучасних фаб-
риках програм.
Розглянемо сутність цих моделей у
просторі індустріальних проблем сучас-
ного наукового софтвера.
Модель взаємодії або інтеропе-
рабельності призначена для обміну інфор-
мацією між різними компонентами при
організації по них обчислень [4, 9]. Взає-
модія це інтерфейс зв'язків різномовних і
різноплатформних програм, а саме посе-
редник у мові MIL (Module Interconnection
Language) або IDL (Inter-face Definition
Language). Нині він реалізований різними
способами у системах Windows Server,
http://lenta.ru/articles/2010
Теоретичні та методологічні основи програмування
11
Microsoft.Net, IBM Web Sphere і т.п. Голо-
вні поняття інтерфейсу – фундаментальні
типи даних, що специфікуються при описі
простих і структурних даних компонентів,
що об’єднаються. Модель взаємодії най-
більш пов'язана з використанням у проце-
сі розробки на фабриках нових програмних
систем з готових програм, за допомогою
яких вирішуються різного роду задачі
зборки. Організація обчислень з зібраних
програм буде більш ефективною, якщо
реалізований інтерфейс враховує формати
даних платформ сучасних комп’ютерів.
Реально існуючі розходження в апаратній
частині платформ відображаються у вихі-
дному коді систем програмування з МП,
у конфігураційному файлі готових ПС,
а також у принципах забезпечення меха-
нізмів взаємодії програм у сучасних обчи-
слювальних або гетерогенних середови-
щах.
Розвиток нових технічних засобів
(майнфреймів, кластерів, суперкомп’ю-
терів й ін.) породжує нові структури даних
(графи, контейнери, портфелі й ін.) та від-
повідні формалізми генерації загальних
типів даних (стандарт ISO/IEC 11404–2007
General Data Types) до фундаментальних.
Деякі питання їх перебудови підтриму-
ються спеціальними засобами середовищ
(Sun IBM, Microsofts, CORBA, СОМ,
JAVA і ін.) шляхом побудови проміжного
прошарку (stub, skeleton) брокерного типу
або інтеграції вихідного коду програм у
системах Linux, Windows Server, MS.Net,
IBM Web Sphere і т. п.
Модель варіабельності подається
у проекті ІІІ–1–07 як поточна або прогно-
зована структура СПС, що забезпечує не-
обхідні зміни та додавання нових можли-
востей у складну СПС. Тобто варіабель-
ність визначає здатність сімейства ПС, чи
окремої її підсистеми або артефакту до ро-
зширення, змінювання, пристосування до
інших умов конфігурування її компонен-
тів у моделі обчислень конкретній ПрО
[18, 19]. Варіабельність забезпечується на
рівні подання вимог, побудови моделі ха-
рактеристик СПС, архітектури, коду, тес-
тів тощо. Варіабельність може бути побу-
дована засобами продуктової лінії, за
якою будується сімейство, як множина
ПС або інших готових ресурсів, що міс-
тяться у репозиторії системи або Інтерне-
ту. Варіабельність складових ПС забезпе-
чує не тільки здатність окремої ПС до ево-
люції після її породження і відділення від
складу СПС, але і життєздатність ПС та
СПС у цілому.
Основні об’єкти цієї моделі такі:
– точки варіантності у формально-
му поданні для деяких ПС сімейств;
– варіант як елементарний артефакт
СПС деякого типу;
– предикат, що визначає множину
точок варіантності та їх варіантів для СПС;
– предикат припустимості взаємо-
зв’язків між точками варіантності і мно-
жиною варіантів.
Модель варіабельності моделю-
ється за допомогою діаграм UML або ін-
шими засобами продуктової лінії, до якої
додається наступне:
– план її реалізації за допомогою ар-
тефактах СПС;
– опис та її реалізація для СПС з фі-
ксацією у файлі конфігурації;
– відповідність моделі в структурі
СПС, файлі конфігурації СПС та парамет-
рах її настроювання на виконання деяких
функцій СПС.
Концепція варіабельності щодо
СПС у системі генерувального програму-
вання проекту ІІІ–1–07 розроблено фахів-
цями відділу Коваль Г.І, Слабоспицької
О.О. та аспірантом Колесник А.П. [18, 19].
Модель життєздатності [20, 21]
розробляється для забезпечення змін й ко-
регування проектних характеристик архі-
тектури системи з використанням теорії
живучості систем LST (Living System
Theory) [22] з моделюванням архітектури
СПС засобами MDA. Сутність теорії LST
міститься у інтегрованому концептуаль-
ному процесі аналізу системи LSPA
(Living Systems Process Analysis) для за-
безпечення життєздатності майбутній СПС
в процесі її супроводу. Основні положен-
ня цієї теорії застосовані у модель життє-
здатності для сімейства систем. Модель
VSM (Viable System Model) удосконалю-
ється додаванням параметрів функціону-
вання СПС та деякими показниками стан-
дартної моделі якості – адаптивність, змін-
Теоретичні та методологічні основи програмування
12
ність, реактивність тощо, які ініціюють
коригування діючій системи у випадку
виникнення нерегулярних ситуацій при
функціонуванні системи. Тобто вхідні па-
раметри та відповідні характеристики мо-
делі життєздатності адаптуються для
продовження роботи системи. Для цього
модель має бути відображена у конфігу-
раційному файлі СПС, яка керує розгор-
танням і виконанням окремих її членів.
Запропоновані у роботі моделі взаємодії,
варіабельності і життєздатності мають ре-
алізуватися в рамках фундамент-тального
проекту з ГП. Вони є спробою вперше за-
безпечити моделювання програм СПС в
процесі динаміки їх виконання у середо-
вищі Eclipce. Головним механізмом пере-
ходу від опису моделей до вихідного ре-
зультату є трансформація понять ПрО до
проміжних мов простору рішень (рис. 3),
та відображення їх характеристик у наве-
дених моделях та конфігураційному файлі
СПС.
Модель трансформації
Простір ПрО 1
Мова опису ПрО1 у DSL
Специфікація члена
сімейства на мові
опису ПрО
Простір рішень 1 =
простір проблеми 2 (ПрО2)
- проміжна мова реалізації рішень
Відобра-
ження 1
Правила
трансляції
Перетворення опису
однією мовою в опис
проміжною
мовою для іншої ПрО
...
Відобра-
ження n
Правила
трансляції
Простір рішень n
- мова реалізації рішень
(мова програмування)
Перетворення опису
проміжною мовою
в опис мовою
програмування
Рис. 3. Схема трансформації опису домену
Основною вимогою до нових мо-
делей варіабельності і життєздатності є
створення їх такими, щоб їх можливо було
використати при супроводі СПС під час їх
виконання, проведення необхідних змін у
різні частини системи, корегування пара-
метрів цих моделей у зв’язку з різними ві-
дмовами та продовження функціо-нування
системи з зафіксованого варіанта або з де-
якої іншої точки моделі варіабельності
СПС.
3. Концепція навчання
студентів з метою їх участі в інду-
стрії софтвера
Більше трьох років автор викладає
курс лекцій в КНУ ім. Тараса Шевченка по
курсу “програмна інженерія” відповідно
до міжнародної програми Curricula-2004.
Ця програма не містить дисциплін,
пов’язаних з виробництвом програмної
продукції на фабриках програм, принци-
пами комплектації фабрики технічними і
людськими ресурсами, методами створен-
ня продуктових ліній та служб підтримки
засобів виготовлення та керування фахів-
цями на фабрики ПП.
3.1. Дисципліни для навчання ін-
дустрії виробництва програм. Індустрія
ПП за продуктовими лініями має ґрунтува-
тися на дисциплінах, які забезпечують но-
рмативне і регламентоване виконання різ-
них робіт з розробки, зборки та керування
роботами щодо експертиз, вимірів і оцінки
різних артефактів.
До дисциплін навчання віднесені
такі науково-технічні дисципліни (Di) про-
грамної інженерії (ПІ) [7, 23–25]:
ПІ = {DiSc, DiEn, DiEc, DsMa},
де DiSс – наукова, DiEn – інженерна, DiEc
– економічна, DiMa – менеджерська
(управлінська) дисципліни.
Сутність цих дисциплін ПІ наведе-
но у [24, 25], а короткий їх огляд дивитися
далі.
Наукова дисципліна є теоретичним
фундаментом ПІ і навчати їй необхідно не
тільки для підвищення рівня кваліфікації
майбутніх фахівців з програмної інженерії,
але і для підтримки та розвитку нових мо-
жливостей і засобів програмування, які
удосконалюють відповідні напрямки інду-
стрії ПІ. Однією з важливих наукових про-
блем індустріального виробництва ПП є
інтеграція (композиція, інтеграція) складо-
вих елементів майбутнього продукту за їх
інтерфейсами. З урахуванням новітніх мо-
жливостей сучасних середовищ необхідно
удосконалити теорію композиції різнорід-
них програм [2, 7].
Головним напрямом навчання у
вищих навчальних закладах має стати саме
наукова дисципліна, як теоретичний курс з
Теоретичні та методологічні основи програмування
13
програмування (об’єктно-орієнтованого,
компонентного, сервісного тощо) поряд з
діючими класичними курсами та додатко-
вими курсами, наприклад, з теорії моде-
лей.
Інженерна дисципліна – це сукуп-
ність інженерних прийомів, засобів і стан-
дартів, орієнтованих на інженерне вигото-
влення ПП із застосуванням наукової дис-
ципліни ПІ. До них належить:
– ядро знань SWEBOK
(www.swebok.org) з розділами побудови та
керування програмними проектами;
– базовий процес з організації проце-
сної діяльності на фабрики ПП;
– стандарти з регламентованими пра-
вилами конструювання артефактів на
процесах ЖЦ;
– умови середовища з забезпечення
базового процесу і підтримки дій вико-
навців з вироблення ПП на ЖЦ;
– загальні засоби і інструментальні
середовища підтримки виготовлення ПП.
Склалися різновиди інженерної ди-
сципліни: інженерія КПВ, застосувань
(Application Engineering), доменів (Domain
Engineering), сімейств систем (Family
Engineering) [2, 7]. Усі ці інженерії ґрун-
туються на багаторазовому використанні
різнотипних КПВ. Побудова СПС
пов’язана з розв’язанням задач домену,
загальними і змінюваними характеристи-
ками програм сімейства. Технологія авто-
матизації СПС набуває конвеєрного виро-
бництва із КПВ, в основі якого лежить
опис моделі домену в DSL, специфікація
членів сімейства МП, керування планами
робіт, контролю результатів та оцінювання
рівня застосування готових ресурсів при
реалізації різних задач. Тобто, без інжене-
рії не мислиться побудова жодного проми-
слового продукту.
Дисципліна керування. Базисом
цієї дисципліни є класична теорія керуван-
ня складними системами, сучасний мене-
джмент проекту та відповідний стандарт
IEEE Std.1490 – настанова до ядра знань
менеджменту PMBOK (Project Management
Body of Knowledge). Ця теорія отримала
розвиток у нас і закордоном, особливо в
частині планування виробництвом. За те-
орією планування Глушкова побудова те-
левізорів на Львівському заводі значно
було підвищено протягом декілька років.
Метод CRM (Critical Path Method) з графі-
чним поданням робіт, різних видів опера-
цій та часу їхнього виконання (на фірмі
«Dupon») та техніка планування PERT
(Program Evaluation and Review Technique),
що розроблені у надрах промислового ви-
робництва, на даний час адаптовані до
менеджменту ПП [7].
Стандарт з менеджменту – PMBOK
відображає задачі планування, моніторин-
гу і керування програмними проектами. В
ньому концепція керування організацій-
ною діяльністю виконавців проекту забез-
печується методами прийняття рішень, ко-
нтролем правильності проекту та оцінки
ризиків [2].
Базові теорії керування, стандартні
положення PMBOK, серія стандартів ISO–
9001 з якості та відповідне методичне за-
безпечення мають стати основою дисцип-
ліни керування ПІ. Створений з цих пи-
тань курс навчання буде слугувати підго-
товки у Вузах майбутніх високо-
кваліфікованих менеджерів проектів та
інших фахівців з організаційного керуван-
ня ПП.
Економічна дисципліна має стати
самостійною дисципліною ПІ зі своєю те-
орією і практикою оцінювання вартісних,
часових і експертних показників щодо
зборки ПП з готових ресурсів, прийняття
проектних рішень, подання вимог, розроб-
лення архітектури, визначення ризиків
проектування за наявними ресурсами, про-
ведення розрахунків за роботи виконавців
та отриману ними якість ПП. Ця дисциплі-
на є найбільш розвинутою з точки зору на-
явності методів економічних розрахунків у
ПІ, а саме методологій прогнозування роз-
міру ПП (FРA – Function Points Analyses,
Feature Points, Mark–H Function Points, 3D
Function Points тощо), оцінювання витрат
на ПП за допомогою сімейства моделей
COCOMO або інших математичних моде-
лей (Angel, Slim, Seer тощо) [5, 26].
При визначенні цієї дисципліни не-
обхідно використати фундаментальні еко-
номічні методи, пов’язані з принципами
розподілу робіт у складних системах, ме-
тоди розрахунків вартості окремих частин
Теоретичні та методологічні основи програмування
14
систем залежно від розміру і системи у ці-
лому, існуючі стандарти щодо оцінювання
ПП тощо. Систематизований і науково об-
ґрунтований курс економічної дисципліни
ПІ закриє економічну прогалину, яка нині
існує в індустрії ПП.
Виробнича дисципліна включає
методи побудови ТЛ, продуктових ліній,
технологію виготовлення продукту на цих
лініях з застосуванням відповідних теорій
проектування та інструментів операційно-
го середовища побудови ПП масового
використання. За останні роки у нас в ос-
новному не розробляються такі лінії і віт-
чизняні інструменти для виготовлення різ-
них видів ПП. Найбільш апробований в
Україні аутсорсинг готових систем і засо-
бів становить більше 35 % від загального
обсягу робіт з індустрії ПП. Але виника-
ють труднощі при супроводженні готових
програм, які вирішуються за допомогою
новітніх методів реінженерії і реверсної
інженерії [7, 23]. При цьому залишаються
деякі проблеми оцінювання складності
об’єктів і процесів виготовлених ПП для
їхній зміни і перебудови.
Ця дисципліна, як предмет навчан-
ня, включає класичні методи і технології
виготовлення ліній та виробництва за ни-
ми різних ПП, методи аналізу особливос-
тей вибору готових ресурсів, стандартів
виробництва та документування продукту.
Наведеними дисциплінами ПІ ма-
ють володіти учасники процесів виробни-
цтва ПП (аналітики – Scientists, інженери –
Engineers, економісти – Economists, керів-
ники – Managers тощо ) [2, 7].
Виробнича діяльність (РА – produc-
tion activity) цих спеціалістів на процесах
лінії задається кортежем:
PA = < ТЛ, Ap, Rp >,
де ТЛ = {Tp ∪ CP}, Tp – навчальний і
управлінський процес СP (Control process);
Ap = {DiSi ∪ DiEn ∪ DiEc ∪ DiMa} – дис-
ципліни програмної інженерії; Rp – квалі-
фікаційні вимоги до фахівців ліній з виро-
бництва ПП.
Усі вищерозглянуті базові теорії і
дисципліни ПІ, а також методи і техноло-
гії побудови ліній і ПП, оброблення даних
і організації обчислювань в сучасних сере-
довищах є базові для навчання студентів
Вузів з інформатики для майбутнього роз-
витку індустрії ПП.
3.2. Про навчання студентів про-
блемам генерації типів даних для on-
line сховищ. Основним видом практичної
діяльності студентів при навчанні дисцип-
лінам, орієнтованим на індустрію ПІ є ла-
бораторні і дипломні роботи по створенню
деяких «тулів» (конструкторів, збиральни-
ків, конвекторів програм і даних, генера-
торів тощо), бібліотек примітивів з пере-
будови типів даних, що подаються у ін-
терфейсах ресурсів, які можуть не відпо-
відати форматам платформ комп’ютерів
або бути відсутніми серед фундаменталь-
них (FDT) типів МП. У роботі [4] запропо-
новано нове вирішення задачі перетворен-
ня типів даних різних ресурсів Інтернету
у вигляді оригінальної системи генерації
загальних типів даних (ТД) GDT до FDT,
що є у сучасних МП, на яких специфіку-
ються програми для фізичних, біологічних
та інших наукових завдань і експеримен-
тів. Базовим фундаментом цього рішення є
стандарт ISO/IEC 11404–2007 – General
Data Types, який визначає генерацію зага-
льних типів даних до фундаментальних.
Студентам 4 курсу кафедри ІС фа-
культету кібернетики викладалась лекція
щодо ТД GDT і FDT поза програмою дис-
ципліни. Зокрема, декілька студентів пере-
клали цей стандарт, як лабораторні роботи,
зробили наукові доповіді про ТД, сутність
ідеї генерації загальних ТД до більш прос-
тих, що є в МП. Студенти Є. Забєлін і
І. Чорний захистили бакалаврські роботи
щодо завдань з перетворення деяких ТД
вказаного стандарту (2010 р.).
Основні задачі і підхід до генерації
GDT<=>FDT запропоновані в [4] і реко-
мендуються для реалізації у системі Grid.
Значимість задач генерації даних під нові
платформи, гетерогенні середовища, Cloud
Computing зростає у зв’язку зі створенням
Інтернет on-line сховищ даних і їх застосу-
вання при обчисленні складних наукових
задач глобального типу. При цьому пере-
будова даних є дуже важливою і потребує
розроблення спеціального набору примі-
тивів (функцій), які будуть використовува-
тися як в індустрії розроблення ПП, так і в
глобальних обчисленнях.
Теоретичні та методологічні основи програмування
15
Вирішення деяких задач генерації
ТД виконується в межах фундаментально-
го проекту з генерувального програмуван-
ня [17] і орієнтовані на включення при-
мітивів щодо оброблення сховищ даних.
Висновок
Запропонована в роботі концепція
побудови фабрики софтвера є загальною.
Вона містить базові складові за конвеєр-
ною зборкою – лінії, бібліотеки програм-
них ресурсів і інтерфейсів, операційне се-
редовище. Розглянуті основні питання ін-
дустрії комп’ютерів і пов’язаної з ними
індустрії ПП і обчислень, а саме модель-
ний підхід, включаючи моделі взаємодії,
варіабельності та життєздатності, які ви-
значені в межах фундаментального проек-
ту ІІІ–1–07.
Підкреслимо, що концепція фабри-
ки програм почала реалізуватися в КНУ
ім. Тараса Шевченка на факультеті кібер-
нетики. Базовими артефактами фабрики є
дипломні і аспірантські роботи з методів і
алгоритмів наукових кафедр цього факу-
льтету. Прикладом побудови студентсь-
кої фабрики є створення сайту
(http://www.programfactory.unv.kiev.ua), що
демонструє декілька технологій розроб-
лення програмних артефактів за ЖЦ засо-
бами Visual Studio.Net, додавання нових
КПВ, інших готових програмних ресурсів
в бібліотеку сайту з описом стандартно
прийнятих специфікацій та паспортів ін-
терфейсів.
1. Лаврищева Е.М. Сборочное программиро-
вание. Теория и практика // Кибернетика и
системный анализ.– 2009.– № 6. – C. 3–12.
2. Лаврищева Е.М., Грищенко В.Н. Сбороч-
ное программирование. Основы индуст-
рии программных продуктов.– Киев.: На-
ук. думка, 2009. – 371 с.
3. Лаврищева Е.М. Становление и развитие
модульно-компонентной инженерии про-
граммирования в Украине // Препринт
2008. – 1.– Институт кибернетики имени
В.М. Глушкова, 33 с.
4. Андон П.І., Лавріщева К.М. Розвиток фаб-
рик програм в інформаційному світі //
Вісник НАН України. – 2010. – № 10. –
C. 15–41.
5. Гринфильд Дж. Фабрики разработки про-
грамм. – М., СПб., К.: Изд. дом «Виль-
ямс», 2007. – 591 с.
6. Словарь по кибернетике. – Под ред. ака-
демика Глушкова, Украинская энцикло-
педия, Киев.– 1979. – 620 с.
7. Лавріщева К.М. Програмна інженерія.–
Академперіодика. – 2008. – 319 с.
8. Лаврищева Е.М. Интерфейс в программи-
ровании // Проблеми програмування.–
2007. – № 2. – С. 126–139.
9. Лаврищева Е.М. Проблема интеропера-
бельности разнородных объектов, компо-
нентов и систем. Подходы к ее решению //
Матер. 7 Міжнар. конф. з програмування
“УкрПрог–2008”. – С. 28–41.
10. Лаврищева Е.М. Основы технологической
подготовки разработки прикладных про-
грамм СОД // Препринт 1987. –АН УССР,
Институт кибернетики им. В.М. Глушко-
ва. – 30 с.
11. Norhrop L.M. Software SEI’s Рroduct line
Tenets // IEEE Software. – 2002. – V. 19. –
N 4.– P. 32–39.
12. http://www.w3.org/
13. Reusable Asset Specifications (RAS) OMG
Available Specifications Version 2.2., Date:
November 2005: http://www.omg.org
14. Semantic Annotations for WSDL and XML
Schema. W3C Recommendation. http://www.
w3.org/TR/sawsdl/
15. Таковицкий О. Технология Grid computing
// Byte. – 2003. – № 7(59). – P. 1 – 9.
Available at http://www.bytemag.ru/articles/
16. Ильин В.А. Сетка с облаками для интерне-
та.– В мире науки.– 2010.– C. 83–85.
17. Лавріщева К.М. Генерувальне програму-
вання програмних систем і сімейств //
Проблеми програмування. – 2009.– № 1. –
С. 3–16.
18. Коваль Г.І., Колесник А.Л., Лавріщева
К.М., Слабоспицька О.О. Удосконалення
процесу розроблення сімейств програмних
систем елементами гнучких методологій //
Проблеми програмування (Спецвипуск
конф. УкрПрог–2010). – 2010. – № 2-3. –
C. 261 – 270.
19. Колесник А.Л. Механізми забезпечення
варіабельності в сімействах програмних
систем // Проблеми програмування. –
2010. – № 1. – C. 35 – 44.
20. Ігнатенко П.П. Життєздатні програмні
системи. Концептуалізація підходу до ав-
томатизації систем організаційного керу-
вання // Проблеми програмування. – 2006.
– № 3. – С. 33–44.
http://www.programfactory.unv.kiev.ua/
http://www.omg.org/
Теоретичні та методологічні основи програмування
16
21. Ігнатенко П.П., Бистров В.М.
Особливості забезпечення життєздатності
програмних систем в умовах генеруючого
програмування // Проблеми програмуван-
ня. – 2008. – № 2–3. – С. 270–278.
22. Miller J.G. Living Systems.–1995, Niwot,
Colorado: University Press of Colorado. –
1102 p.
23. Основы инженерии качества программных
систем / Ф.И. Андон, Г.И. Коваль,
Т.М. Коротун, Е.М. Лаврищева,
В.Ю. Суслов. 2–е изд. – Киев: Академпе-
риодика, 2007. – 672 с.
24. Лавріщева К.М. Перспективні дисципліни
програмної інженерії // Вісник НАН
України. – 2008. – № 9. – С. 12–17.
25. Лаврищева Е.М. Классификация дисцип-
лин программной инженерии // Киберне-
тика и системный анализ. – 2008. – № 6. –
С. 3–9.
26. Лаврищева Е.М., Слабоспицькая О.А. Под-
ход к экспертному оцениванию в про-
граммной инженерии // Кибернетика и
системный анализ. – 2009. – № 4. –
С. 151–168.
Отримано 18.12.2010
Про автора:
Лавріщева Катерина Михайлівна,
доктор фізико-математичних наук,
професор, завідуюча відділом.
Місце роботи автора:
Институт программных систем
НАН Украины,
03680, Киев-187,
Проспект Академика Глушкова, 40.
Тел.: (044) 526 3470.
|