Концепція індустрії наукового софтвера і підхід до обчислення наукових задач
Дано аналіз сучасного стану і застосування фабрик в індустріальному виробництві програмної проду-кції. Запропоновані базові складові фабрики наукового софтвера, обґрунтовано їх зміст і призначення у рішенні наукових завдань. Розглянуто підхід до індустрії обчислень різних наукових задач. Сформу-льов...
Saved in:
| Date: | 2011 |
|---|---|
| Main Author: | |
| Format: | Article |
| Language: | Ukrainian |
| Published: |
Інститут програмних систем НАН України
2011
|
| Subjects: | |
| Online Access: | https://nasplib.isofts.kiev.ua/handle/123456789/50918 |
| Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
| Journal Title: | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| Cite this: | Концепція індустрії наукового софтвера і підхід до обчислення наукових задач / К.М. Лавріщева // Пробл. програмув. — 2011. — № 1. — С. 3-16. — Бібліогр.: 26 назв. — укр. |
Institution
Digital Library of Periodicals of National Academy of Sciences of Ukraine| _version_ | 1859683004191866880 |
|---|---|
| author | Лавріщева, К.М. |
| author_facet | Лавріщева, К.М. |
| citation_txt | Концепція індустрії наукового софтвера і підхід до обчислення наукових задач / К.М. Лавріщева // Пробл. програмув. — 2011. — № 1. — С. 3-16. — Бібліогр.: 26 назв. — укр. |
| collection | DSpace DC |
| description | Дано аналіз сучасного стану і застосування фабрик в індустріальному виробництві програмної проду-кції. Запропоновані базові складові фабрики наукового софтвера, обґрунтовано їх зміст і призначення у рішенні наукових завдань. Розглянуто підхід до індустрії обчислень різних наукових задач. Сформу-льовані нові дисципліни з індустріального виробництва програмних артефактів і reuses та навчання цим дисциплінам студентів за відповідними спеціальностями з інформатики і Computer Sciences.
|
| first_indexed | 2025-11-30T21:35:54Z |
| format | Article |
| 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.
|
| id | nasplib_isofts_kiev_ua-123456789-50918 |
| institution | Digital Library of Periodicals of National Academy of Sciences of Ukraine |
| issn | 1727-4907 |
| language | Ukrainian |
| last_indexed | 2025-11-30T21:35:54Z |
| publishDate | 2011 |
| publisher | Інститут програмних систем НАН України |
| record_format | dspace |
| spelling | Лавріщева, К.М. 2013-11-06T17:12:46Z 2013-11-06T17:12:46Z 2011 Концепція індустрії наукового софтвера і підхід до обчислення наукових задач / К.М. Лавріщева // Пробл. програмув. — 2011. — № 1. — С. 3-16. — Бібліогр.: 26 назв. — укр. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/50918 681.3 Дано аналіз сучасного стану і застосування фабрик в індустріальному виробництві програмної проду-кції. Запропоновані базові складові фабрики наукового софтвера, обґрунтовано їх зміст і призначення у рішенні наукових завдань. Розглянуто підхід до індустрії обчислень різних наукових задач. Сформу-льовані нові дисципліни з індустріального виробництва програмних артефактів і reuses та навчання цим дисциплінам студентів за відповідними спеціальностями з інформатики і Computer Sciences. uk Інститут програмних систем НАН України Теоретичні та методологічні основи програмування Концепція індустрії наукового софтвера і підхід до обчислення наукових задач Article published earlier |
| spellingShingle | Концепція індустрії наукового софтвера і підхід до обчислення наукових задач Лавріщева, К.М. Теоретичні та методологічні основи програмування |
| title | Концепція індустрії наукового софтвера і підхід до обчислення наукових задач |
| title_full | Концепція індустрії наукового софтвера і підхід до обчислення наукових задач |
| title_fullStr | Концепція індустрії наукового софтвера і підхід до обчислення наукових задач |
| title_full_unstemmed | Концепція індустрії наукового софтвера і підхід до обчислення наукових задач |
| title_short | Концепція індустрії наукового софтвера і підхід до обчислення наукових задач |
| title_sort | концепція індустрії наукового софтвера і підхід до обчислення наукових задач |
| topic | Теоретичні та методологічні основи програмування |
| topic_facet | Теоретичні та методологічні основи програмування |
| url | https://nasplib.isofts.kiev.ua/handle/123456789/50918 |
| work_keys_str_mv | AT lavríŝevakm koncepcíâíndustríínaukovogosoftveraípídhíddoobčislennânaukovihzadač |