Розвиток фабрик програм в інформаційному світі

У 1975 р. академік Глушков запропонував концепцію конвеєрного способу виробництва ПП з готових програм. У статті проаналізовано розвиток цієї концепції на прикладі попередніх і сучасних фабрик програм; засвідчено появу двох основних понять виробництва: інтерфейс як стиковочний елемент із передачі і...

Ausführliche Beschreibung

Gespeichert in:

Bibliographische Detailangaben
Datum:	2010
Hauptverfasser:	Андон, П., Лавріщева, К.
Format:	Artikel
Sprache:	Ukrainian
Veröffentlicht:	Видавничий дім "Академперіодика" НАН України 2010
Schriftenreihe:	Вісник НАН України
Schlagworte:	Статті та огляди
Online Zugang:	http://dspace.nbuv.gov.ua/handle/123456789/27635
Tags:	Tag hinzufügen Keine Tags, Fügen Sie den ersten Tag hinzu!
Назва журналу:	Digital Library of Periodicals of National Academy of Sciences of Ukraine
Zitieren:	Розвиток фабрик програм в інформаційному світі / П. Андон, К. Лавріщева // Вісн. НАН України. — 2010. — № 10. — С. 15-41. — Бібліогр.: 60 назв. — укр.

Institution

Digital Library of Periodicals of National Academy of Sciences of Ukraine

id	irk-123456789-27635
record_format	dspace
spelling	irk-123456789-276352011-10-11T12:05:46Z Розвиток фабрик програм в інформаційному світі Андон, П. Лавріщева, К. Статті та огляди У 1975 р. академік Глушков запропонував концепцію конвеєрного способу виробництва ПП з готових програм. У статті проаналізовано розвиток цієї концепції на прикладі попередніх і сучасних фабрик програм; засвідчено появу двох основних понять виробництва: інтерфейс як стиковочний елемент із передачі і трансформації програм, що збираються, та інтегроване середовище збірки готових різнорідних програм із деяких МП. Упродовж останніх 35 років вони постійно вдосконалювались і стали базисом сучасної фабрики програм, наприклад, в інфраструктурі Європейського проекту Grid, призначеного для обчислювання наукових завдань. Автори оприлюднюють результати наукових досліджень Інституту програмних систем НАН України, дають визначення фабрики програм за збіркою ПП із різнорідних і різноплатформених програм з використанням людських, технологічних та інструментальних ресурсів. Інститут планує упроваджувати ці результати в систему Grid і в інститутах НАН України. В межах системи будуть розроблені нові засоби інтерфейсу різнорідних програм із перетворення стандартних ISO/IEC 11404–2007 типів даних до тих, що є в багатьох мовах програмування, процедури генерації яких збагатять майбутні гетерогенні середовища сучасними засобами збірки програм. In 1975, academician Hluskov proposed assembly line way in program products (PP) from ready programs manufacturing concept. The article analyzes that concept development on previous and modern program factories example; demonstrates the appearance of two main notions in production — 1) interface as butt-joint element in assembling programs assignation and transformation; 2) integrated medium for ready various programs of certain program languages assembling. During last 35 years they are being constantly improved and become a modern program factory basis, exempli gratia in the intended for scientific tasks calculation European Project Grid infrastructure. Authors expose the results of Program Systems Institute of Ukrainian NAS scientific explorings; give definition for the program factory assembling PP of various programs having different platforms with the usage of human, technology and instrument resources. Institute plans to instill those results into Grid system and Ukrainian NAS institutes. Within system creases, new interface means will be treated. They belong to various programs transforming data types of ISO/IEC 11404–2007 standard to ones existing in the large number of program languages whose generation procedures enrich future heterogenous environments with modern program assembling means. 2010 Article Розвиток фабрик програм в інформаційному світі / П. Андон, К. Лавріщева // Вісн. НАН України. — 2010. — № 10. — С. 15-41. — Бібліогр.: 60 назв. — укр. 0372-6436 http://dspace.nbuv.gov.ua/handle/123456789/27635 uk Вісник НАН України Видавничий дім "Академперіодика" НАН України
institution	Digital Library of Periodicals of National Academy of Sciences of Ukraine
collection	DSpace DC
language	Ukrainian
topic	Статті та огляди Статті та огляди
spellingShingle	Статті та огляди Статті та огляди Андон, П. Лавріщева, К. Розвиток фабрик програм в інформаційному світі Вісник НАН України
description	У 1975 р. академік Глушков запропонував концепцію конвеєрного способу виробництва ПП з готових програм. У статті проаналізовано розвиток цієї концепції на прикладі попередніх і сучасних фабрик програм; засвідчено появу двох основних понять виробництва: інтерфейс як стиковочний елемент із передачі і трансформації програм, що збираються, та інтегроване середовище збірки готових різнорідних програм із деяких МП. Упродовж останніх 35 років вони постійно вдосконалювались і стали базисом сучасної фабрики програм, наприклад, в інфраструктурі Європейського проекту Grid, призначеного для обчислювання наукових завдань. Автори оприлюднюють результати наукових досліджень Інституту програмних систем НАН України, дають визначення фабрики програм за збіркою ПП із різнорідних і різноплатформених програм з використанням людських, технологічних та інструментальних ресурсів. Інститут планує упроваджувати ці результати в систему Grid і в інститутах НАН України. В межах системи будуть розроблені нові засоби інтерфейсу різнорідних програм із перетворення стандартних ISO/IEC 11404–2007 типів даних до тих, що є в багатьох мовах програмування, процедури генерації яких збагатять майбутні гетерогенні середовища сучасними засобами збірки програм.
format	Article
author	Андон, П. Лавріщева, К.
author_facet	Андон, П. Лавріщева, К.
author_sort	Андон, П.
title	Розвиток фабрик програм в інформаційному світі
title_short	Розвиток фабрик програм в інформаційному світі
title_full	Розвиток фабрик програм в інформаційному світі
title_fullStr	Розвиток фабрик програм в інформаційному світі
title_full_unstemmed	Розвиток фабрик програм в інформаційному світі
title_sort	розвиток фабрик програм в інформаційному світі
publisher	Видавничий дім "Академперіодика" НАН України
publishDate	2010
topic_facet	Статті та огляди
url	http://dspace.nbuv.gov.ua/handle/123456789/27635
citation_txt	Розвиток фабрик програм в інформаційному світі / П. Андон, К. Лавріщева // Вісн. НАН України. — 2010. — № 10. — С. 15-41. — Бібліогр.: 60 назв. — укр.
series	Вісник НАН України
work_keys_str_mv	AT andonp rozvitokfabrikprogramvínformacíjnomusvítí AT lavríŝevak rozvitokfabrikprogramvínformacíjnomusvítí
first_indexed	2025-07-03T07:22:11Z
last_indexed	2025-07-03T07:22:11Z
_version_	1836609523679232000
fulltext	ISSN 0372-6436. Вісн. НАН України, 2010, № 10 15 П. Андон, К. Лавріщева РОЗВИТОК ФАБРИК ПРОГРАМ В ІНФОРМАЦІЙНОМУ СВІТІ © АНДОН Пилип Іларіонович. Академік НАН України. Директор Інституту програмних систем НАН України. ЛАВРІЩЕВА Катерина Михайлівна. Доктор фізико-математичних наук. Завідувач відділу програмної інженерії цієї ж установи (Київ). 2010. К онцепцію фабрик програм уперше сформулював академік В.М. Глушков на науковому семінарі 5 березня 1975 р. в Інституті кібернетики (ІК) у присутності К.Л. Ющенко, І.М. Молчанова, І.В. Сергі- єнка, Ю.В. Капітонової, О.А. Летичевського, А.І. Нікітіна, К.М. Лавріщевої, І.В. Вель- біцького та інших [1]. Суть нової парадиг- ми Глушкова — прискорити перехід від мистецтва програмування до промислових методів виробництва програмних продук- тів (ПП) для розв’язання різних господар- ських задач у межах нової системи ОГАС, що охоплювала всі республіки СРСР. Основ- ними аргументами академіка Глушкова на користь переходу до промислового програ- мування були: — обчислювальні, керівні й матема- тичні машини, виготовлені самостійно в Україні; — готові програми у мовах програмуван- ня (МП) 4GL (Алгол, ПЛ-1, Кобол, Форт- ран, Модула-2 та ін.) й алгоритми, накопи- чені в республіканських фондах алгоритмів і програм для повторного використання у нових розробках за конвеєрною збіркою; — побудовано важливі автоматизовані системи, деякі АСУ керування підприєм- ствами господарського та військово-про- мис лового комплексу, АСУТП тощо. Для реалізації цієї концепції ГКНТ СРСР відкрив державні наукові програми для академічних інститутів, аби створити засоби автоматизації (наприклад, Проект, Дельтастат, АПРОП, Альфа, Симп, Приз, Прометей та ін.) [2–12] різних комплексів програм, необхідних для виконання важли- вих науково-технічних завдань у різних га- лузях промисловості й господарства СРСР за допомогою комп’ютерів. Одночасно ідея індустріалізації складних програмних сис- тем (ПС) із готових простіших модулів і програм у МП 4GL виникла і в крупних західних фірмах (SUN ONC IBM, CDC, SDS, UCSD, General Electric, Oberon тощо) [10–21]. Тобто зусиллями багатьох праців- ників ІК і закордонних спеціалістів до 1990 р. було розроблено цільові засоби, необхідні для виробництва ПП на перших «фабриках»: — системи автоматизованого виробни- цтва програм із модулів повторного вико- ристання (МПВ) за принципом збирання частин ПП або в цілому, подібно до того, як це робили на той момент в автомобільній чи авіаційній промисловості; — лінії виробництва окремих ПП або їх- ніх сукупностей, що регламентують випуск деякого виду продукту [9]; — окремі технічні, програмні інстру- менти, засоби й механізми для підтримки збірки, а саме: паспорти модулів із описом зовнішніх даних у мовах інтерфейсу MIL, MESA, АЛМО тощо, необхідних у «сти- ковці» (збірці) різномовних програм між собою із використанням бібліотек програм і функцій перетворення нерелевантних у МП і модулях типів даних тощо; 16 ISSN 0372-6436. Вісн. НАН України, 2010, № 10 — середовища підбору з бібліотек або фондів готових МПВ, їх автоматизоване збирання чи інтеграція у нові програмні конструкції (комплекси, агрегати, сис- теми тощо) спеціального призначення для виконання деяких задач підпри- ємств. Прикладом апробації ідеї ліній вироб- ництва як фабрики програм (уводу, виво ду даних, пакетів прикладних програм, роз в’я- зання наукових задач статистики, числен- ня тощо) була АІС «Юпітер» із чотирьох технічних об’єктів Морського флоту СРСР, розроблення якої очолював П.І. Андон. На основі спроектованих ліній виробництва для цієї системи побудовані за методом збірки багато програм обробки даних. Але у зв’язку із розвалом СРСР роботи з удо- сконалення ліній виробництва для інших галузей з 1991 р. були зупинені, але продо- вжувались теоретичні дослідження [13– 21]. При розробленні цих засобів чимало спеціалістів дійшли висновку, що загаль- ною ще слабко розв’язаною проблемою збірки різнорідних програмних об’єктів у МП є інтерфейс (системний, прикладний, теоретичний), який повинен забезпечува- ти обмін даних між різнорідними програ- мами й комп’ютерами. Тоді зміст інтер- фейсу складали практично в кожній сис- темі по-різному. Нині триває його розви- ток і вдосконалення, вчені створюють нові мови інтерфейсу (IDL, API, SIDL, DII), стандарти фундаментальних (Fundamental Data Types — FDT [20–25]), загальних (General Data Types — GDT стандарту ISO/IEEC 11404 [26]) типів даних (ТД) МП і форматів даних (OSI, RDF, XML, OSWL тощо [27]). Період 1992–2010 рр. характеризується розвитком не лише мов опису інтерфейсів, але й засобів їхньої підтримки для забезпе- чення обміну даних між модулями в різних середовищах шляхом узагальнення раніше сформульованого інтерфейсного посеред- ника новими його видами (Р-код, stub, skeleton, adaptor, glue, slim, DSI), а також через конфігураційні, спискові файли, ін- терфейсні карти й т.п. Удосконалено розпо- ділені середовища (COM, CORBA, MS. VSTS, JAVA-машина, Grid, Babel) [21], від- новлено лінії виробництва (Product Li nes, Programs Factories), розроблено нові про- грамні ресурси (reuses, assets, Domains, Ap- plications) й інформаційні ресурси в Інтер- неті, чимало інструментів їхньої підтримки [20, 21, 27, 28]. Усе це сприяє переходу до індустріаль- ного виробництва різноманітних видів ПП конвеєрним методом, появу якого прогно- зував акад. В.М. Глушков. Таким чином, загальними практичними зусиллями багатьох програмістів було ви- знано, що головне місце в індустрії ПП зай- має операційне середовище, яке устаткова- не сучасними комп’ютерами, МП, інтерфей- сами, типами даних FDT і GDT; інструмен- тами трансформації і взаємодії різ норідних програм. 1. АНАЛІЗ ДИНАМІКИ РОЗВИТКУ ФАБРИК ПРОГРАМ У СВІТІ Аналіз фабрик програм проведено, по- чинаючи з того часу, коли цю ідею висловив акад. В.М. Глушков. Особливу увагу було приділено розробленим се ре- довищам і системам з автоматизованим виробництвом різного роду ПП із різ- них еле ментів збірки, створених «руч- ними», автоматизованими або частково автоматизованими засобами. Це насам- перед: 1. Система АПРОП в ІК, що працюва- ла в середовищі ОС ЄС і об’єднувала за ме- тодом збірки різномовні модулі в МП 4GL через інтерфейсні міжмовні й міжмодульні посередники [2, 6, 9, 10, 19–21]; 2. Інтегроване середовище Sun Mic ro- systems IBM зі збіркою різномовних про- ISSN 0372-6436. Вісн. НАН України, 2010, № 10 17 грам у 90-х рр. ХХ ст. і подальшим роз- вит ком нових напрямів виробництва ПП, зокрема, моделлю архітектури SOA, Web- сервісами, новими мовами Ruby, Script [29]; 3. Клієнт-серверне розподілене середо- вище CORBA OMG із віддаленою взає- модією клієнта й сервера у мережі через модулі-посередники, які отримали назву «заглушок» — stub (для клієнта); skeleton, adaptor, dynamic interface Dill (для серве- ра) і передають зовнішні дані із запитом брокеру від клієнта до сервера і зворотнім [30]; 4. Фабрика «ручної» збірки різномов- них програм Інг Бей із використанням кількох засобів взаємодії різнорідних програм (інтерфейсні посередники, ко- мандні рядки, конфігураційні файли, ін- тер фейс ні карти) у середовищах (VC++, VBasic, Matlab, Java, Visual Works Small- talk тощо) [30]; 5. Фабрики програм Дж. Грінфільда з технологією побудови складних бізнесних програм із використанням методології use case (UML), ліній виробництва й модель- ного підходу SOA [32, 36]; 6. Колективне міжнародне середовище MS.VSTS для виробництва ПП широкого призначення за участю виконавців, що мо- жуть звертатись через Інтернет до цього се- редовища із різних місць [33]; 7. Інфраструктура розроблення, тесту- вання, збірки наукових програм, систем і пакетів для подальшого обчислення у між- народній мережі Європейського проекту Grid [35, 36] тощо. Проаналізовано ці фабрики програм із визначенням різних технологічних джерел, інструментів і важливих атрибутів у таб- личному поданні середовищ (платформа, МП, зв’язки, засоби, FDT, трансформація, інтерфейс тощо). 1.1. Аналіз автоматизованої збірки ПП у вітчизняній системі АПРОП Перші системи автоматизованої побудови ПП в Україні були системи [1–10], зокрема АПРОП [2, 6], яка забезпечувала збірку різ- номовних програм у агрегатну монолітну структуру з інтерфейсними посередниками в мові типу MIL для кожної пари таких про- грам, призначених для розв’язання різних наукових, прикладних і господарчих задач. Табл. 1. Основні засоби середовища АПРОП 1980 –1991 Середовище ОС ЄС Платформа ЄС ЕОМ Мови Алгол, ПЛ/1, Кобол, Фортран, Асемблер Зв’язки CALL, ММК Засоби АПРОП, Банк модулів, збірка Типи даних FDT і ТД МП Трансформація Бібліотека функцій міжмодульного і міжмовного інтерфейсу, Банк готових модулів Інтерфейс Посередники із зовнішніми ТД у ММК АПРОП 18 ISSN 0372-6436. Вісн. НАН України, 2010, № 10 Генерацію посередників виконував тех- нологічний модуль за допомогою спеці- ально розробленої бібліотеки інтерфейс- них функцій (64) та перебудови нереле- вантних FDT типів даних, що передають- ся через CALL-виклик в усіх МП 4GPL [2, 6, 9, 10]. Було вироблено зміст поняття ін тер- фейсу: міжмовного й міжмодульного для FDT МП і паспорта готових модулів, опис яких був надалі вдосконалений у мовах ІDL і API. Як фабрика система базувалась на готових модулях, які були розроблені для методів чисельного аналізу і збе рі- галися в Банку модулів. Крім того, анало- гічні рішення відносно концепції інтер- фейсного посередника були отримані і в інших системах, що були створені в ІК. Але розроблені в межах системи АПРОП функції відображення нерелевантних ти- пів даних різномовних модулів в обрано- му класі МП ОС ЄС були практично ви- користані в 52 організаціях СРСР [2, 6, 20], а метод збірки, розробленої в системі АПРОП, став основою збіркового програ- мування, застосованого в сучасному ви- робництві ПП на фабриках програм [10, 9–21]. 1.2. Аналіз середовища збірки ПП у Sun Microsystems IBM IBM-середовище забезпечує взаємодію тих самих МП, що АПРОП. Воно викорис- товує ОС: MVS, VM, OS/2, AIX. У ньому механізм виклику і принципи об’єднання різномовних програм аналогічні. Опис зо- внішніх інтерфейсних FDT різномовних програм виконано мовою MIL та Асембле- ра як проміжного для багатьох ПП [29]. Інтеграцію (збірку) різних програм вико- нано на загальній платформі IBM. Для ро- боти з даними різної структури застосова- но системи БД (IMS, CICS) з ієрархічною і мережною структурою. Багато питань су- місності типів даних розв’язано транзакці- ями з БД. Нині середовище IBM поповне- но новими засобами, зокрема мовою Ruby й Web-сервісами. Основу технології збір- ки становить механізм заглушок, подібно до системи CORBA. Ці системні можли- вості адаптовані на платформах процесорів Intel, Linux з мовою Scilab і пакетом відпо- відних розширень (Toolbox). До середови- ща IBM додано новий засіб — WebSphere Application Server Compunity Edition, який забезпечує сервісні застосування на сучас- них компонентах для виконання різних Табл. 2. Основні засоби IBM-середовища 1980–1991 Середовище ОС 360-390, ONC (Sun Microsystems) Платформа IBM Solaris Sparc, Intel, Linux Itanium Мови Алгол, ПЛ/1, Кобол, Фортран, Асемблер Зв’язки CALL, САLLP, MIL-генератор, SAG Засоби MVS, VM, OS/2, AIX, Open source Типи даних FDT і ТД МП Трансформація XDR-бібліотеки, бібліотека готових модулів, Sun Workshop, Toolbox Інтерфейс Посередники в MIL, Асемблері ISSN 0372-6436. Вісн. НАН України, 2010, № 10 19 зав дань і сервісів. Ураховуючи популяр- ність програм з Windows, у системі Unix адаптували програми у мовах С, С++ з пор- туванням їхніх даних через AIX. Зараз сис- тема IBM постачає новітні технології та за- соби IBM Factories для індустріального ви- робництва програм більш ніж у 100 країн, зокрема в Росію. 1.3. Аналіз механізму збірки у клієнт- серверному середовищі CORBA OMA-архітектура посилила можливості зв’язків у звичайних програмних об’єктах у МП і в об’єктно-орієнтованому програ- муванні. В межах цієї архітектури виник ширший клас інтерфейсних посередників (stub, skeleton, adaptor, dill, service, client- interface, server-interface), опис яких пода- но за сучасними мовами інтерфейсу — ІDL, API, DII для різних МП, програми з яких можуть виконуватись у клієнт-серверній архітектурі системи з передачею даних че- рез протокол IIOP об’єктному брокерові ORB, який забезпечує обмін інформацією між клієнтом і сервером, а також подання різних видів сервісів цим програмам із го- ризонтальним і вертикальним призначен- ням (табл. 3). Принципи конструювання розподілених об’єктів із забезпеченням ме- ханізмів взаємодії в середовищах OMG/ CORBA, Microsoft/COM і Java/RMI по- дано в [29] з обґрунтуванням проміжного прошарку брокера ORB як інструмента ке- рування розподіленими об’єктами і завдан- нями з усунення неоднорідності різнорід- них платформ при вирішенні на них інтер- фейсів програм між клієнтом і сервером за- собами брокера ORB. 1.4. Фабрика напівавтоматизованої збірки програм за Інг Бей На цій фабриці використано різні сере- довища (VC++, VBasic, Matlab, Java, Visual Works тощо) з відповідною взаємодією різ- номовних компонентів, частково автомати- зованими інструментами й засобами (Do- main and Application Models, Model Inter- connection, Microsoft Foundation, асемблу- вання) виготовлення ПП (табл. 4) [31]. Роз глянуто різні варіанти зв’язків і конкрет- ні приклади для кожної пари програм у МП з відповідними функціями перетворення об- мінних типів даних шляхом звернення до них операторами на різних МП як механіз- мах прямої та оберненої взаємодії різно- мовних і різноплатформених програм. Для кожної пари компонентів у МП викладено техніку передачі даних через віддалений Табл. 3. Основні засоби CORBA-середовища 1991–2010 Середовище ORB, COSS, DCE/RPC, PCTE, ToolTalk, Java2 SDK, NetPilot CCS Платформа OMA-архітектура (Apple, IBM, Win-NT, x-Open, Dec) Мови С, VC++, VC#, Smalltalk, Java, Кобол, Visual Basic, Ada-96 Зв’язки IDL, API, DII, Client-interface, Server-interface, TCP/IP Засоби CORBA, OLE/ DCOM, SOM/ DSOM (IBM), OSF DCE Типи даних FDT, ТД сучасних МП Трансформація МIL, IDL, DLL, ORB, Borland Jbuilder Інтерфейс Посередники — stub, skeleton, service, adaptor 20 ISSN 0372-6436. Вісн. НАН України, 2010, № 10 виклик і з можливим перетворенням не- сумісних переданих типів даних за відпо- відними фактичними параметрами і прин- ципами розгортання цих компонентів. На відміну від загальної схеми взаємо- дії різномовних програм за інтерфейсними посередниками в даному керівництві по- дано нові технологічні засоби перетворен- ня типів даних за допомогою користуваль- них панелей, сценаріїв, іконок, зразків ін- терфейсних програм тощо. Особливості зв’язків пар різнорідних програм у різних МП наведено далі. Інтерфейс між Visual Basic та іншими МП реалізовано операторами звернення з таки- ми параметрами, як текстові рядки, значен- ня, масиви тощо. Їх обробку виконано спе- ціальними функціями Windows API, DLL і функціями відтворення нерелевантних ти- пів даних, що передаються різним програ- мам у цих мовах. Matlab як середовище розв’язання задач лінійної та нелінійної алгебри, матричних операцій, різних математичних методів об- числень містить такі інструменти: Matlab Compiler, Matlab C++, Matlab Library, Mat- lab Graphic Library. Інтерфейс за звернен- ням реалізовано MatlabCompiler шляхом відображення типів даних у відповідні фор- мати мови С — М-файли чи М-функції, які перетворюються до формату даних архітек- тури інших комп’ютерів. Smalltalk — інтегрована система програ- мування, що забезпечує створення різних застосувань у середовищі VisualWorks за допомогою моделей застосувань із функ- ціями DLL із класу зовнішнього інтер- фейсу бібліотеки С++, методів об’єктів і різних повідомлень, що містять фактичні значення параметрів для передачі іншим об’єктам. Система LabView — набір виробничих процесів розроблення, тестування, збиран- ня даних із вимірюванням та оцінкою вза- ємодіючих даних з апаратурою платформи за допомогою інструментів ANS C, Visual Basic, Visual C++, Lab Windows/CV, а та- кож вимірювання параметрів термометрів і перемикачів у реальному часі для їх пере- дачі через мережу. Табл. 4. Основні механізми «ручної» збірки програм 1996–2005 Середовище VC++, Vbasic, Matlab, Java, Visual Works Платформа MS.Net, HP, Apple, IBM… Мови C, C++, Visual C++, Visual Basic, Matlab, Smalltalk, Java, LabView, Perl Зв’язки RPC, Active, рядковий формат, dll, External interface class Засоби Domain and Application Models, Model Interconnec- tion, Microsoft Foundation, інструкції збірки для різних середовищ Типи даних FDT, нові ТД, Setup, Start, Exit Трансформація Збірка (лінковка), інтеграція кодів Інтерфейс RMI, JNI, exe-файл, інтерфейсна карта ISSN 0372-6436. Вісн. НАН України, 2010, № 10 21 Система Java містить набір інструментів зв’язку з мовами JAVA, C, C++ і засобами Java Native Interface на віртуальній машині VM з використанням інтерфейсних функ- цій і бібліотек класів С і С++. У межах цьо- го середовища наведено приклади взаємо- дії різномовних компонентів у цих МП. Мова Perl включає засоби опису сценаріїв для взаємодії з Інтернетом, керування зав- даннями, створення CGI-сценаріїв для сер- вера системи Unix, інтерфейс із мовами С, С++, Visual Basic, Java, а також з іншими мо- вами за процедурами, операторами виклику в С або С++ і функціями з динамічної бібліо- теки. Перетворені дані у спеціальному коді зберігають у бібліотеці інтерпретатора Perl. На цій фабриці використано найсучасні- ші засоби й інструменти різних середовищ підтримки взаємодії різномовних програм у МП, надано рекомендації щодо прямої та оберненої передачі даних через параметри звернення до інших готових програм. 1.5. Фабрики бізнесних програм Дж. Грінфільда Для майбутньої фабрики автор сформулю- вав методологічні й технологічні аспекти ви- робництва ПП за методом UML, моделями архітектури систем і комп’ютерів, механізма- ми інтеграції різнорідних компонентів з вико- ристанням багатьох типів даних FDT і мов взаємодії IDL, XML, RDF тощо [32]. Головні концептуальні ідеї цієї фабрики такі (табл. 5): — еволюція, змінювання готових reuses, активів, програм і систем під цілі замовни- ка ПП; — програми із класифікаційними озна- ками категорій ПП, які накопичують на фаб риці в загальноприйнятих сховищах (біб ліотеках, репозитаріях); — економіка систематичного повторного використання; — моделі, шаблони, інструменти, принци- пи побудови ПП з використанням методу UML; — лінії ПП за технологічними діями (ана- ліз проблеми, вимоги, специфікації, дизайн, реалізація, тестування, інсталяція, сертифі- кація ПП), сервісне обслуговування фабрик (веб-сервіси, служби якості, контролю ро- біт і планів); — демонстрація результатів фабрики роз- роблення ПП за Product line на прикладі бізнес-магазину. Табл. 5. Основні засоби фабрики програм за методом UML 2004–2010 Середовище Web-сайти, MS VS, IBM Web Sphere, MS Busi- ness Framework, Product Lines, Web-служби й сервіси Платформа Класи, каркаси, шаблони різних комп’ютерів Мови UML, DSL, GSS, ООP, OSL, XML, RDF Зв’язки IBM Rarional Rose XDE, MDD, MDA, класи, Core J2EE Design Засоби Генерації, збірки, розгортання, тестування інструментами фабрики, Java-VM Типи даних FDT Трансформація Збірка, генерація ПП на ТЛ Інтерфейс RMI, RPC, IDL, API 22 ISSN 0372-6436. Вісн. НАН України, 2010, № 10 Результати практичного моделювання UML для бізнес-застосувань дозволили ав- торові зробити такі висновки: — мова UML — це мова ескізу ПП за різ- ними сценаріями; — відсутність можливості використання в UML компонентів повторного викорис- тання (КПВ) і сценаріїв із програм на ін- ших МП; — неможливість застосовувати нові мо- делі MDA, SOA, посилання до типів даних FDT, прийнятих у сучасних МП, і звернен- ня до новітніх загальних типів даних GDT [21—26]; — UML важкий для модифікування ПП фабричними засобами через відсут- ність механізмів забезпечення їх зміню- ваності. Отже, запропоновано макет фабрики програм із використанням сучасних Pro- duct lines, які повинні мати: — мови, шаблони, каркаси, моделі; — інструменти, автоматизовані засоби наповнення каркасів; — збірку програм незалежно від плат- форм комп’ютерів із використанням МП і ТД (XML, WSDL, RDF тощо); — сертифікацію залежностей, перевірку функціональних і нефункціональних вимог до ПП; — використання аспектів безпеки, захис- ту, синхронізації задля їх додавання до по- будованого ПП; — можливість зміни окремих компонен- тів, архітектури, даних, що використову- ють різні ТД або БД. Фактично меморандум сучасної фабри- ки ПП Дж. Грінфільда такий: — архів МПВ чи бібліотек повинен бути великим для відбору потрібних артефактів на фабрики програм; — збірка за виробничими лініями повин- на бути як у Чернецкі [37, 44] стосовно сі- мейств систем, простору проблем, рішень і забезпечення їхньої якості; — застосування нових моделей систем, каркасів процесів і ПП відповідають новим рисам проектування й виробництва про- дуктів на сучасних фабриках програм. Головний висновок автора — фабрика програм за методом UML має багато проб- лем при індустріальному виробництві ПП та їхньому супроводі, особливо це торка- ється забезпечення механізмів змінювання й еволюції створених за UML продуктів. 1.6. Фабрика програм фірми Microsoft Середовище МS.NET — сучасна фабрика програм з усіма атрибутами збіркового виробництва ПП. Насамперед, середо вище найліпше оснащено, в ньому забагато го- тових системних і прикладних ресурсів (компонентів, сервісів, Domains, Appli ca- tions тощо); МП (JAVA, C++, Basic, Java, Pascal, C#, SpecC#); механізмів RMI, RPC виклику компонентів із загальними біблі- отеками CLR (Common Language Routine) і FCL (Framework class Language); інстру- ментів збірки проміжного чи вихідного ко- дів (exe, dill) у готовий ПП; Веб-сервісів різного призначення для виробництва про- грамних проектів; пакетів VSTS з керуван- ня конвеєрним методом командами роз- робників, члени яких можуть бути в різ- них місцях інформаційного світу (табл. 6) [33]. Головні засоби середовища МS.NET для автоматизованого виробництва ПП: — пакет інструментів VSTS (Visual Stu- dio Teams System), орієнтований на розроб- лення великих проектів за участю різних спеціалістів (аналітиків, менеджерів, тесту- вальників, програмістів, кодувальників тощо) із різних організацій; — методологія MSA (Microsoft Solution Architecture), призначена для побудови ви- робничої архітектури підприємства за допо- могою ЖЦ розроблення ПП (Software De- ve lopment Life Cycle), стандарту PMBOK, моделей перспектив і процесів; ISSN 0372-6436. Вісн. НАН України, 2010, № 10 23 — системи Professional Studio, Foundation Server для підтримки процесів проектуван- ня, кодування, тестування, формування версій ПП тощо; — CMMI Process Improvement для регу- лювання термінів розроблення за техноло- гією Agile тощо [58]. Пакет VSTS — це сімейство системних засобів проектування ПП, забезпечення взаємодії виконавців різних частин ПП і продукту в цілому, а також підбору КПВ, розподілу й виконання окремих робіт із виготовлення ПП. Виконавці проектів по- ділені за чотирма категоріями з урахуван- ням рівня знань, здібностей у програму- ванні, проектуванні, вимірюванні, оціню- ванні ПП тощо. Перехід із нижчої катего- рії на вищу можливий при якісному виконанні завдань або додатковому на- вчанні. Спеціалісти четвертої групи — го- ловні в команді, відповідають за функціо- нальну правильність виконання вимог і ПП. До основних компонентів продукування ПП у середовищі VSTS належать: — Microsoft SQL, Server зберігають усі робочі результати, вихідний код і дані інте- грації Team команди за допомогою засобів Веб-порталу з сервісами, а також інстру- ментів Analysis, Reporting Services і Share- Point Portal Services; — Microsoft Project, Excel використовують як альтернативні засоби для керівників про- екту ПП. Засобом підтримки процесу розроблення окремих елементів ПП є IDE (Integrated Development Environment), Microsoft Office Project, Microsoft Office Excel, що перевіря- ють вимоги, відстежують проміжні проце- си вироблення й кінцеві результати з оці- нюванням ступеня готовності. Тестування окремих елементів ПП здійснюють засоба- ми, що інтегрує Visual Studio. Таким чином, середовище VSTS виступає прикладом колективної фабрики вироб лен- ня ПП. Для цього є багатий набір інстру- ментів керованої підтримки процесів ЖЦ за графіком робіт, а також його відстежен- ня, оцінювання результатів на якість, вар- тість і терміни виготовлення ПП. Табл. 6. Оргструктура середовища конвеєрного розроблення ПП у MS.VSTS 2003–2010 Середовище ОS 2000 ХР/ME, MS.NET-server, SQL- server, Visual Studio Teams System.NET, MCSD, MSF Платформа МS.NET (8, 16, 32, …, 128 байт) Мови C, C++, VBasic, Java, Pascal, C#, SpecC# Зв’язки SQL-request, Web-Forms, Web-services, EXE-файли, dll Засоби SDLC, IDE, MS Office, MS SQL server, MS VS Типи даних FTD, GDT, CTS (Common Type Systems) Лінкування Збірка CLR-бібліотеки, класи, FCL-типи, трансформатори Інтерфейс General code (EXE), Portable Executable code 24 ISSN 0372-6436. Вісн. НАН України, 2010, № 10 1.7. Інфраструктура збірки й обчислень у системі Grid Європейський проект Grid — мережна інфраструктура для організації розподіле- них обчислень задач із різних наукових на- прямів (фізика, математика, медицина, бі- ологія) [34, 35]. До його складу входить GCube — операційне середовище, ETICS — збіркове середовище тощо. ETICS за функціями найближчий до су- часної фабрики програм, базується на на- борах характеристик, послуг і процедур ви- готовлення пакетів. Вони можуть об’єд ну- ватись плагінами (plugins) [34] з описом послуг для споживачів або постачальників, засобами керування завданнями з робочих місць, а також доступу до ОС, архітектури CPU, компіляторів з МП і засобами специ- фікації залежностей між різними пакетами та їхніми тестами при збірці й розгортанні. Множина функціональних плагінів забез- печує перевірку контрактів, тестів вико- нання різних елементів систем, генерацію документації, ведення готових програм в оперативному або постійному репозитарії ETICS. Технологію створення великих наборів пакетів із вихідних або сукупностей пере- компільованих програм забезпечено проце- сами доступу до репозитаріїв, формування розподілених версій та їх репродукцій. Го- ловним гальмом є перебудова деяких ком- понентів систем для альтернативної плат- форми гетерогенного середовища ком п’ю- терів шляхом посилань з 16-, 32-розрядної платформи на 64-розрядну платформу се- редовища Grid. Головна проблема споруджених у систе- мі ETICS об’єктів (Проект, Підсистема й Компонент) у стандартизації опису типів даних. Модель даних із типовим форма- том CIM для взаємин між цими об’єктами Табл. 7. Система збірки й обчислення — Grid 2003–2010 Середовище Grid (Collection Instuments and Tools) Платформа Intell, Sun, IBM, Apple, MS.Net, Кластери Мови 4-5 GPL C, C++, Visual C++, Visual Basic, Small- talk, Java, LabView, Perl, Java, Pyton Зв’язки RPC, Active, RMI, CRL, SiDL, API, інтерфейсний, конфігураційний файли, dll-data Засоби OGSA, SDK, Protocol NFS, User Domain and Application, HTTP, Model Interconnection, MS Foundation, репозитарії ресурсів, OSI Типи даних FDT, GDT (стандарт ISO/IEC 11404) Збірка Взаємодія комп’ютерів, мережні ресурси, протоколи, МПВ і збірка вихідних кодів систем, підсистем, компонентів і пакетів Інтерфейс RMI, JNI, exe й конфігураційні файли, інтерфейсні карти, SIDL (Babel), FDT, GDT ISSN 0372-6436. Вісн. НАН України, 2010, № 10 25 включає їхній опис зі зверненнями між ними за таких умов: — кожен компонент має властивості (ім’я, ліцензію, URL, репозитарії), глобаль- ний унікальний ідентифікатор — GUID, команди перевірки скомпільованого ком- понента, тестові команди, зв’язки з конфі- гураційним файлом версії системи; — конфігураційний файл окремого ком- понента чи системи містить інформацію про версію, зв’язки з репозитарієм, GUID, про види платформ і зв’язків із глобаль- ними компонентами і пакетами для обчис- лень; — між двома різними конфігураціями встановлено статичну й динамічну залеж- ність даних і компонентів. У середовищі Grid на першому плані ре- сурси в широкому розумінні, а саме: дина- мічне керування застосуваннями й сервіса- ми в кожний момент часу при глобально- му обчислюванні наукових завдань. Ресур- си — це різні програмні артефакти, засоби комунікації, інформаційні системи, СПС, системи збереження даних, СКБД, про- грамні фонди із різних доменів, технічні, комп’ютерні, людські ресурси тощо. Ресурс подає логічний файл або фізичний об’єкт (кластер, комп’ютер, суперкомп’ютер то- що). Їхні протоколи (NFS) завантажуються системою Grid і забезпечують моніторинг, керування, доступ до локальних ресурсів фабрики програм з метою отримання ін- формації про безпеку, захист, взаємозв’язки тощо. Глобальні задачі в Grid взаємодіють між обчислювальними вузлами мережі через протоколи (Resource, Connectivity) при ви- конанні пакетів завдань, якими керує служ- ба диспетчеризації системи. На основі стан- дартних протоколів будують сервіси, інтер- фейси в API, засоби розроблення систем SDK (Software Development Kits). Збірку програм на канальному рівні з різних фа- брик, а також виконання компонентів, під- систем і систем наукового призначення в різних МП реалізують глобальні протоко- ли (Global Protocols). Тобто ця мережа зо- рієнтована на майбутні обчислення з побу- дованих різними науковцями ПП. Крім розглянутих видів фабрик є й інші: інтегроване середовище Eclipse [45]; систе- ма Oberon [46], яка з 90-х рр. виконує збір- ку різнорідних програм і підключила на цей час нові МП для опису й виготовлен- ня ПП на комерційній основі; а також по- повнення цього середовища новою мовою наукового інтерфейсу SIDL (Scientifically IDL) для забезпечення взаємодії наукових програм у мовах C, C++, Pyton, Java через прошарок типу glue для платформ Linux, AIX, Solaris, IBM з орієнтацією названої мови на майбутнє використання в інфра- структурі проекту Grid. Підсумком виконаного аналізу фабрик програм є опис фундаментальних робіт із теорії і практики виробництва ПП за учас- тю співробітників ІПС НАН України про- тягом багатьох років, визначення структу- ри, змісту й організації керування сучас- ною фабрикою програм, а також упрова- дження глобального проекту фабрики в Grid для перспективного її застосування у наукових підрозділах НАН України. 2. РОЗВИТОК ТЕОРЕТИЧНИХ ОСНОВ ВИРОБНИЦТВА ПРОГРАМ В ІПС НАН УКРАЇНИ К онцепція виробництва програм про- тягом останніх десятиріч отримала те- оретичний розвиток у дисертаційних і фундаментальних дослідженнях проектів ДКНТ (1992–1996) і наукових проектах ІПС НАН України (1997–2011). Дослі- дження й розробки забезпечили розвиток теоретичних методів проектування, зби- рання різнорідних компонентів, проведен- ня експертиз, тестування й оцінювання якості кінцевого продукту. Саме тут спе- ціалісти інституту отримали оригінальні 26 ISSN 0372-6436. Вісн. НАН України, 2010, № 10 результати, поповнили теорію виробництва ПП новими формальними засобами й ме- ханізмами, яких бракує зарубіжним публі- каціям. Створення теорії об’єктного й ком- понентного програмування. У межах на- укових проектів інституту [10, 21, 48, 49] і збіркового програмування побудова- но об’єктно-компонентний метод (ОКМ) із використанням теорії Фреге як апара- ту узагальнення поняття об’єкта формаль- ними властивостями, характеристиками і з математичними формалізмами для уточ- нення окремих і загальних рис об’єктів та їх відмінностей. Основу об’єктної теорії становить алге- бра аналізу Σ=(E', Ψ, P) з E'=(E1, E2,, En) — множини об’єктів, операції Ψ={decds, decdn, comds, comdn, conexp, connar} над елемента- ми E' і множина предикатів P=(P1, P2, ..., Pr ) завдання концептів об’єктів. Алгебра Σ — система операцій аналізу, функцій деталі- зації, екземпляризації, агрегації об’єктів. Розроблено формальний механізм перехо- ду від об’єктів до їхньої програмної реалі- зації, тобто до компонентів та інтерфейсів. У результаті компонентне програмування розширено формальними моделями (ком- понент, інтерфейс, компонентне середови- ще), операціями зовнішньої та внутрішньої компонентної алгебри із засобами перетво- рення нерелевантних типів даних різно- мовних компонентів [14, 20, 21]. Зовнішня алгебра Ψ={CSet, CESet, Ω1} ви- значена на множині компонентів Cset, се- редовищі CESet, операціях Ω1={CE1, CE2, CE3, CE4} розгортання, об’єднання компо- нентних середовищ, видалення компонента із середовища, заміщення компонентів. Внутрішня алгебра φ={CSet, CESet, Ω2} визначена на операціях еволюції (рефак- торингу, реінженерії, реверсної інженерії) компонентів Ω2={Оrefac, OReing, ORever}. Компонентна алгебра Ξ={Ψ∩φ}={CSet, CESet, Ω1}∩{CSet, CESet, Ω2}={CSet, CESet, Ω1, Ω2} — необхідний інструмент взаємо- дії, еволюції різнорідних компонентів для сучасних середовищ. Взаємодію забезпе- чено оригінальною теорією перебудови ти- пів даних різномовних програм, створеною в рамках системи АПРОП [10] і розвинутої стосовно індустрії виробництва ПП на фа- бриках програм [21]. Формально модель збірки різномовних компонентів, заданих на множині компо- нентів CSet={Compi}, забезпечує взаємо- дію компонентів через обмін даних, кож- не з яких є трійкою з: ім’ям змінної, типом даного, значенням. При обміні дані кожної пари компонентів можуть бути еквівалент- ними, коли вони мають однакову семан- тичну структуру й тип даних, або нееквіва- лентними, тоді необхідне їх перетворення за наступними функціями відображень: FNij: Nи→Nj , FTij: Ti→Tj , FVij: Vi→Vj, де FNij — задає відповідність між іменами змінних на множині формальних і фактич- них параметрів, FTij — це опис еквівалент- них відображень типів даних, FVij реалізує необхідні перетворення значень даних не- еквівалентних типів. Задачу побудови перетворень FNij вирі- шують шляхом упорядкування імен змін- них. Відображення між типами даних FTij подано як абстрактна алгебраїчна система T=(X, ΩW), де X — множина значень для цього типу, а ΩW — множина операцій над цими змінними. Відображення FVij вико- ристовують у випадку нееквівалентності типів Ti і Tj . У випадку багаторазового виклику ком- понентів виконують пряме і зворотне пере- творення формальних і фактичних параме- трів за умови ізоморфізму відображень між алгебраїчними системами опису типів да- них. Під перетворенням типу Ti=(Xi, ΩWi) у тип Tj=(Xj , ΩWj) розуміють таке перетво- рення, при якому семантичний зміст опе- рацій із ΩWj еквівалентний змістові опера- ISSN 0372-6436. Вісн. НАН України, 2010, № 10 27 ції із ΩWj. У випадку односторонньої пе- ребудови типу Ti у тип Tj еквівалентність перетворення не існує. Задача забезпечення взаємозв’язку пари компонентів, розроблення котрих викона- не на різних МП, полягає у побудові сукуп- ностей відображень для всіх викликів з ме- тою встановлення однозначної відповіднос- ті між множиною фактичних параметрів V={ v1, v2 ,..., vk} і множиною формальних параметрів F={f1, f2 ,..., fl } компонентів. Для типів даних FDT МП у роботах [14, 20, 21] визначені алгебраїчні системи для FDT даних, доведені ізоморфні відобра- ження між ними і сформульовані нові умо- ви генерування деяких типів даних GDT. Нові засоби перевірки правильності компонентів. Тестування компонентів і ПП як метод виявлення помилок, дефек- тів, відмов і збоїв, викликаних різними не- регулярними ситуаціями, аварійним при- пиненням роботи деяких компонентів чи всієї компонентної системи, стало наступ- ним головним напрямом досліджень. Так, у ди сертаційній роботі Т.М. Коротун [50, 16] запропоновано (рис.1): — математичну модель визначення опти- мального часу тестування компонентів te * з максимальним прибутком K(t0\|te)= ΔR(t0\|te) – – С(te)=См(μ(t0) — μ(t0+te)+μ(te)) — c1te — – c2μ(te), з похідною K(t0\|te), яка дорівнює K′(t0\|te)=См(λ(te) — λ(t0+te)) — c1 — c2λ(te) в залежності від функції зростання надійнос- ті, інтенсивності λ(t), ризику См; — метод оцінювання ризиків відмов ком- понентів під час експлуатації системи; — технологічний модуль тестування ПП і збору інформації про всі помилки для по- силення надійності програм СОД. Рис. 1. Інженерія тестування, якості й оцінки процесів ПП 28 ISSN 0372-6436. Вісн. НАН України, 2010, № 10 Дослідження перевірено у проектах СОД МО України й удосконалено щодо СПС у проекті генерувального програмування (2007–2011). Методи оцінювання якості ПП. Упер- ше про забезпечення якості заговорили в 1968 р. на конференції НАТО з програмної інженерії. Відтоді дослідження отриман- ня ПП із гарантованою якістю виконували за кордоном і в Україні в межах науково- дослідних проектів ДКНТ, Міністерства науки, НАН. Одночасно створювали стан- дарти з якості в рамках інформаційних тех- нологій та програмної інженерії, зокрема, в ІПС гармонізовано стандарти ISO/IEC 12207, серія ISO/IEC 14598 «Оцінювання програмного продукту», ДСТУ ISO 15939 «Процес вимірювання», серія ISO/IEC 15504 «Оцінювання процесів ЖЦ ПЗ», ба- зові стандарти з якості — ISO 9001 «Сис- теми управління якістю. Вимоги», ДСТУ 2844–94, ДСТУ 9126 «Якість ПП», ДСТУ 2850–94 і стандарти, що регламентують різні аспекти забезпечення якості ПП. Ба- гаторічні дослідження в галузі якості до- зволили спеціалістам [13, 16, 51], зокрема Г.І. Коваль [51], розробити в межах дисер- тації нові формальні методики вимірюван- ня й оцінювання показників якості ПП у класі задач СОД для МО України, отрима- ти такі оригінальні результати: — модель якості з орієнтацією на оцінку надійності ПП; — модель розподілу надійності системи з компонентів за функцією корисності ПП l m Qnc = � νj · qj = �ws * · rs j =1 s=1 залежно від вагомих коефіцієнтів ws і надійності qj = � rn n � E j ок ре- мих компонентів; — концептуальну модель прийняття рі- шень із керування якістю, включаючи ба- йесівські методи, методи систематичного контролю надійності на ранніх стадіях ЖЦ, вимірювання кількісних вимог до надій- ності, прогнозування дефектів. Результати досліджень із проблеми за- безпечення якості ПП систематизовано ко- лективом авторів у монографії «Основы инженерии качества программных систем» [16], яка є бестселером у СНГ. Підхід до експертного оцінювання. За- безпечує розв’язання формалізованих за- дач оцінювання об’єктів виробництва й експлуатації ПП шляхом експертиз. Базу- ється на теоретичному обґрунтуванні ме- тоду експертного оцінювання об’єктів ЖЦ ПС, а саме: T=<G, et, ch(et)>; �≠G�GТ; et�ET; ch(et)�CHet; CH=�et�ET CHet; ES(T)=<A, d(ca1, cn1,…, can, cnn), mg, vf>, d�Δet,ch, де G — цілі розроблення ПС; et — тип оці- нюваних об’єктів ЖЦ; ch(et) — цільова характеристика; A={a=(ud, t)}, \|A\|≥1 — альтернативи; d — аналітична залежність ch(et) від її оцінюваних підхарактеристик; cal�CHet, l=1,…, n з множини Δet,ch; � cnl — джерела контексту оцінювання cal; mg — модель експертної групи; �vf — підстави верифікації оцінок {ch(a), a�A}. Метод оцінювання створює новий про- цес ЖЦ зі спільним інформаційним сере- довищем, адекватним потребам і специфіці виробничої діяльності з виготовлення ПП. Розроблений Слабоспицькою О.О. [52] ма- тематичний апарат експертиз містить: ме- тодичний каркас (цільові функції, механіз- ми реалізації); модель і методи процесу оці- нювання (формалізми підвищення якості результатів та їхнього повторного викорис- тання); засоби збірки процесів керування розробленням ПП [58–60]. Методи керування проектом. Менедж- мент проекту протягом багатьох років був однією з головних проблем індустрії ПП у закордонних роботах, у тому числі стандар- ті PMBOK (Project Management Body of Knowledge, 2005), який регламентує ке- рівництво командою виконавців програм- ного проекту як продукту з використанням ISSN 0372-6436. Вісн. НАН України, 2010, № 10 29 загальних методів управління, планування й контролю робіт (стартові операції, плану- вання ітерацій, моніторинг і звітність), ке- рування менеджером проекту ризиками й конфігурацією ПП. Дослідження в цьому напрямі Задорожної Н.Т. дали нові наукові результати [53, 54], а саме: — формальну модель керування проекту- ванням інформаційних систем, що врахо- вує матеріальні, фінансові, трудові ресур- си, необхідні для розроблення ПП; — метод формування варіанта плану Х робіт проекту за сітковим графіком В, що включає: послідовність робіт (li � L), їхній обсяг qi і вид Wi, ресурси R=<RL, RS> і нор- ми їхнього використання (NRi � NR), закон розподілу випадкових величин F={F1,..., Fr }, часу t у плановому періоді [t0,T], ймо- вірність закінчення робіт з урахуванням критерію оптимального плану K(X*) = = min K(X). Ці результати апробували в системах ав- томатизації освітніх процесів («Документо- обіг в освіті України», портали «Діти Укра- їни», «Вчитель новатор», 2004–2009), а та- кож викладають у вищих навчальних закла- дах Академії педагогічних наук України. Розвиток ліній ПП. Технологічні прийо- ми виробництва ПП із готових компонен- тів (КПВ, reuses, assets тощо) розроблено ст. науковими співробітниками відділу Ко- валь Г.І., Моренцовим Є.І., Коротун Т.М. під керівництвом авторів у 80-х рр. ХХ ст. у проекті «Юпітер» [9, 16, 17, 19], удоскона- лено в сучасному представленні лінії про- дуктів (Product Lines Practice) [36]. Нині вони наближають до конвеєрного вироб- ництва ПП на задоволення потреб деяко- го ринку за такими головними вимогами їх побудови: — завдання обмежень властивостей і ха- рактеристик параметрів збірки ПП; — підбір каркасів, заготовок, засобів, ін- струментів підтримки технологічного про- цесу лінії; — створення онтологій ПрО для об’єктів репозитаріїв КПВ у мовах OSWL, RDF, IDL, адаптованих для збірки готових спе- цифікованих для фабрики компонентів у нові ПП [55, 56] тощо. Новий підхід до виробництва звичай- них ПП на лінії — це використання сис- теми Protégé [57] для подання онтологій нових компонентів і КПВ, а також необ- хідних плагінів зв’язку із сучасним сере- довищем Eclipse при їх збірці у складні ПП з контролем робіт і відстеженням ходу побудови продукту; виявлення ри- зиків, прогнозування вартісних і техніч- них ресурсів; керування конфігурацією ПП; вимірювання, оцінки якості і серти- фікації ПП. Поповнення середовища Eclipse новими можливостями виробництва СПС. Інте- гроване середовище Eclipse базове для фун- даментального проекту ІПС (2007–2011) «Розробка теоретичного фундаменту гене- руючого програмування та інструменталь- них засобів його підтримки» [44, 45] й орі- єнтоване на виробництво застосувань і сі- мейств програмних систем (СПС з компо- нентів повторного використання — КПВ) із забезпеченням їхньої інтероперабель- ності шляхом генерації інтерфейсних посе- редників при збірці різномовних програм у СПС або ПП (рис. 2). Основні завдання проекту цієї системи як фабрики програм: — використання готових компонентів, інформаційних ресурсів Інтернету, моду- лів, сервісів, аспектів, Legacy-systems і т.п.; — створення нової концепції генерації КПВ за моделлю GDM [37, 44], збірка ПП за описом специфіки ПрО у мовах окремих доменів DSL СПС; — представлення онтологічними моделя- ми процесів тестування, експертизи, оцінки якості компонентів і КПВ [57–59]; — орієнтація на МП (C/C++, C#, JAVA, Pascal, Basic, Clear, Ruby), мови опису даних 30 ISSN 0372-6436. Вісн. НАН України, 2010, № 10 (XML, UML, RDF, FDT, GDT), мови взає- модії (IDL, APL, SIDL, протоколи, ін.), за- стосування сучасних моделей систем (MDA, MDD, PIM, PSM, GDM, DSML, Feature); — розширення інструментального середо- вища генерувального програмування репо- зитарієм із онтологій ПрО, системними за- собами (Protégé, Eclipse, Aspectj, Java), при- кладними інструментами (ТМ тестування, надійності, експертизи, збірки, конфігурації тощо); — дороблення теорії експертного та байе- сівського оцінювання КПВ, процесів ЖЦ, окремих об’єктів і членів СПС. На рисунку 2 наведено основні про- цеси створення ПП (трансформаційний, конфігураційний, або збірковий). Вони базуються на відповідних методах ОКМ перебудови компонентів та їх збірки в СПС. У цьому середовищі головні технологічні модулі (ТМ) ліній виробництва ПП такі: ТМ тестування КПВ і різних програм; Рис. 2. Інтегроване середовище ГП ISSN 0372-6436. Вісн. НАН України, 2010, № 10 31 ТМ збірки різнорідних програм із за- безпеченням відображення несумісних за типом даних; ТМ експертизи і вимірювання компонен- тів і членів СПС; ТМ оцінки надійності за результатами тестування окремих програм і СПС; ТМ оцінки якісних і кількісних показни- ків компонентів і систем у сімействі СПС; ТМ сертифікації компонентів і СПС для розміщення їх у глобальному середовищі Grid; ТМ керування різними ресурсами (тех- нічними, програмними, людськими тощо) середовища. Цей проект побудови сучасної фабрики програм має загальні риси з інфраструкту- рою системи Grid і в майбутньому може стати її складовою. 3. ЗАГАЛЬНЕ ВИЗНАЧЕННЯ ФАБРИКИ ЗБІРКИ ПРОГРАМ З урахуванням досвіду роботи, виконання наукових і прикладних програмних про- ектів, експериментальних і виробничих фа- брик індустріального виробництва ПП з аналізом концепцій збірки ПП у низці мо- нографій [2, 5–21, 28–35] дано визначення фабриці збірки програм. Це інтегрована інфраструктура збіркового виробництва окремих ПП (компонентів, підсистем, сис- тем, модулів, блоків, сімейств систем, АСУ, АСУТП та ін.) із застосуванням: — ресурсів (програмних, наукових, інже- нерних, технічних, технологічних, еконо- мічних, фінансових, людських); — середовищ збірки типу SUN ONC, MS.Net, Oberon, Grid, Eclipse. Охарактеризуємо базові елементи інфра- структури сучасної фабрики програм. 3.1. Ресурси для виробництва ПП на фабриці Цих ресурсів та їх типів багато, і вони необ- хідні для побудови й функціонування різних фабрик виробництва програм. Розглянемо їх. Програмні ресурси. Програма — це по- слідовність команд (операторів) у будь- якій МП або опис алгоритму вирішення завдання для виконання на комп’ютері. Програма для використання на фабриці може бути: — модульною (в деякій МП, як частина ОС або ПС); — монолітною (кілька модулів або про- грам як одна програма); — локальною (частина деякої програми); — резидентною (перебуває в основній пам’яті ОС або ПС, готова до запуску чи постійно працює); — розподіленою (розміщена і працює на кількох комп’ютерах або платформах із об- міном даними через мережу); — функціональною/прикладною (реалі- зує задачі предметної області — ПрО); — сервісною (виконує послугу чи сервіс для користувача); — інтероперабельною (взаємодіє з інши- ми програмами); — реентерабельною (паралельне вико- нання з іншими програмами); — заготовкою (шаблон, каркас, патерн, макрос, контейнер, контракт, assets, reuses, artifact тощо). Наведені типи програм повинні мати паспортні дані з описом зовнішніх характе- ристик (у мовах IDL, API, SIDL тощо) чи специфікацією у стандартній мові OSWL для подальшого застосування у збірці різ- номовних програм і перетворення нереле- вантних типів даних. Цільові програми для виготовлення ПП на фабриці: — програмна (прикладна) система (Ap- plication) — комплекс інтегрованих про- грам і засобів, що реалізують набір функ- цій деякої ПрО в заданому середовищі; — програмне забезпечення (Software) — сукупність програмних засобів, які реалізу- ють функції комп’ютерної чи технічної апаратно-програмної системи, включаючи 32 ISSN 0372-6436. Вісн. НАН України, 2010, № 10 загальносистемні засоби (ОС, СКБД, кон т- роль технологічних процесів, обробку сиг- налів тощо) і прикладні програмні сис- теми; — сімейство систем (Systems family) — сукупність програмних систем із загальним і керованим (змінним) набором характе- ристик, що задовольняють потреби ПрО чи домену; — програмний проект (Program Project) — унікальний інтегрований комплекс взаємо- залежних заходів, орієнтованих на досяг- нення цілей і задач конкретного ПП за ви- значеними вимогами до термінів, бюджету, результатів його функціювання; — складні програмні об’єкти — сукуп- ність взаємопов’язаних цільових об’єктів різних типів (bissnes, web-services applica- tions), які виконують необхідні функції, послуги, сервіси, виготовлені самостійно як прості цільові об’єкти з використанням інших готових компонентів з бібліотек або репозитаріїв. Великий клас становлять сер- віси, Веб-сервіси, прикладні сервісні засто- сування. Для виготовлення з них застосу- вань мають специфічні особливості як дея- кі готові послуги, що обираються й викону- ються за запитом різних користувачів. Цей клас засобів у майбутньому матиме також індустріальні риси виробництва з них ПП. Наукові й інженерні ресурси фабрики У межах досліджень розвитку програмної інженерії запропоновано класифікацію но- вих дисциплін, спрямованих на індустріаль- не виробництво ПП [28, 38–40] (рис. 3). Сутність цих ресурсів як дисциплін збір- кового виробництва ПП у наступному: — наука базується на класичних дисци- плінах (теорія алгоритмів, множин, дока- зу, математична логіка, теорія програму- вання) і відповідних загальних мовних за- собах проектування абстрактних моделей і архітектур цільових програмних об’єктів, стандартизованих методів програмування Рис. 3. Дисципліни виробництва ПП ISSN 0372-6436. Вісн. НАН України, 2010, № 10 33 із процесами збірки ПП з готових програм та їхніх інтерфейсів; — інженерія поєднує сукупність тех- нологічних засобів і методів проектування ПП із фундаментальних і стандартних мо- делей ЖЦ, техніку аналізу ПрО, формулю- вання вимог, моделей системи, розроблен- ня вихідного коду, його вимірювання, су- провід і змінювання (реінженерія, реверсна інженерія, рефакторинг), адаптування ПП до інших комп’ютерних платформ і різних середовищ; — керування ПП застосовує загальну теорію керування, містить базові методи керування програмним проектом за допо- могою графіків робіт, спостережень за їх- нім виконанням, а також ризиками, версія- ми (конфігураційний файл) ПП і супрово- дженням; — економіка складається із сукупності методів експертного, якісного, кількісного оцінювання проміжних артефактів і кінце- вого результату процесів ЖЦ, економічних методів розрахунку часу, обсягу, трудоміст- кості, вартості виготовлення ПП для поста- чання замовникові чи на ринок; — виробництво базується на лініях ви- робництва комп’ютерних і прикладних сис- тем, сімейств систем із застосуванням гото- вих програм (КПВ, сервісів, аспектів, аген- тів і т.п.), що накопичені в інформаційних сховищах, бібліотеках і репозитаріях, а та- кож одиночних готових програм, які переві- ряють і сертифікують на якість і надійність. Ці дисципліни призначені для система- тизації процесів виготовлення ПП на дея- кій фабриці програм. У майбутньому вони стануть предметом підготовки студентів для участі в індустріальному виробництві ПП. Технічні, технологічні й загальносис- темні ресурси фабрики Набір технічних, технологічних і загаль- них ресурсів організації-розробника чи фа- брики ПП необхідний для виконання під- процесів базового процесу програмної ін- женерії, спрямований на виконання дого- ворів із замовником на ПП. Технічні ресурси — платформи, процесо- ри (Intel, IBM, Apple, MS тощо); комуніка- ції (OSI, TCP/IP; комп’ютери; файли, сер- вери; локальні, глобальні мережі; електрон- на пошта; техніка налагодження тощо). Технологічні ресурси — бібліотеки, ре- позитарії готових ПП (КПВ, reuses, аssеts, applications, domains, systems); методики програмування збіркового типу (модуль- ного, компонентного, сервісного, UML); керівництва й методики з мов інтерфейсів (IDL, API, DII, SIDL, XML, RDF); стан- дартний опис (каркасів, шаблонів, контей- нерів, процесів, проектів, систем, СПС). Загальносистемні ресурси — ОС, клі- єнт-серверні технології, інструменти; офіс- ні системи (рідери/райтери форматів pdf, ps, html); системи документообігу; утиліти (архіватори, записувачі інформації); засо- би захисту (антивірусні, парольні); CASE- інструменти, транслятори; графічні інстру- менти; СКБД тощо. Людські ресурси фабрики Це групи розробників і служб керуван- ня/виконання проектних робіт за планами, контролю якості, ризиків, правильності ре- алізації проекту тощо. В інфраструктурі людських ресурсів згід- но зі стандартом ISO/IEC 12207 поєднано групи за таким призначенням (рис. 4): — техніко-технологічної підтримки (ви- вчення ринку, придбання Case, ПП, кон- сультації, навчання тощо); — захисту інформації (паролі, ключі за- хисту, перевірки); — технологічної служби (супроводу, під- тримки ЖЦ, контролю дій/ удосконалення ТЛ тощо); — якості (SQA-група) із функціями плану- вання і виконання ЖЦ, перевірки робіт, контро- лю якості робочих продуктів і документів ПП; — верифікації, валідації (V&V), тесту- вання ком понентів чи ПП на правильність 34 ISSN 0372-6436. Вісн. НАН України, 2010, № 10 виконання вимог, координування планів ро- біт із менеджером, перевірки правильності ПП у тестовому середовищі системи; — керівників проекту, що відповідають за фінансові й технічні ресурси проекту, а також за виконання проектних угод замов- ника й керування розробленням ПП; — менеджера проекту, відповідального за розроблення програмного проекту фабри- ки відповідно до вимог, проектних рішень і планів робіт; — проектувальників і програмістів, що відповідають за розроблення проектних рі- шень, їхню реалізацію у вигляді програм, документів, інших вихідних результатів; — керівника конфігурації, який реєструє версії ПП, зберігає тверді копії та конфігу- рацію з розмежуванням доступу до них. Наведені ресурси необхідні для будь- якого індустріального колективу виробни- ків ПП. Роль і призначення різних фахів- ців наведено в низці стандартів із завдань програмної інженерії. Стандартні ресурси Міжнародний комітет зі стандартизації розробив чимало стандартів програмної ін- женерії, що регламентують порядок розроб- лення ПП з керованими методами для дея- кої фабрики програм. Ці стандарти створю- ють важливі ресурси фабрики. Базовий процес забезпечує «процесне продукування» ПП як вид інженерної ді- яльності з виготовлення ПП з операціями оцінки, вимірювання, керування змінами, вдосконаленням самого БП відповідно до стандарту ISO/IEC 15504-7 («Оцінюван- ня процесів ЖЦ ПЗ. Настанови з удоско- налення процесу»). Оцінку зрілості орга- нізації чи фабрики програм здійснюють за моделлю зрілості CMM (Capability Matu- rity Mo dels) [16] інституту SEI США, а та- кож моделями Bootstrap, Trillium тощо. Рівень зрілості визначає наявність фінан- сових ресурсів, стандартів, методик і зді- бностей (зрілості) членів колективу фа- брики, здатних виготовляти ПП у визна- чені час і вартість. Життєвий цикл у стандарті ISO/IEC 12207 «Процеси ЖЦ ПЗ» регламентовано різними напрямами діяльності щодо роз- роблення, проектування, керування ПП, ор- ганізації процесів (планування, керування й супроводу), вимірювання, оцінювання про- дуктів і процесів. Найважливіші стандарти ДСТУ наведені в підрозділі «Методи оціню- вання якості». Рис. 4. Структура груп виконавців фабрики ISSN 0372-6436. Вісн. НАН України, 2010, № 10 35 Ядро знань SWEBOK — стандарт SEI США містить опис 10 розділів (knowledge areas) програмної інженерії за двома кате- горіями. Перша — методи й засоби розроб- лення (формування вимог, проектування, конструювання, тестування, супровід), дру- га — методи керування проектом, конфігу- рацією, якістю, БП [43]. Методи ядра знань відповідають стандартним процесам ЖЦ з урахуванням потреб конкретної фабрики програм з регламентованою послідовністю розроблення і супроводу ПП, починаючи з вимог, вироблення проектних рішень, кар- каса майбутнього продукту, вибору готових компонентів для «наповнення» цього кар- каса [15, 39, 40, 55]. Ядро знань менеджменту проекту — стандарт керування проектом РМВОК, розроблений РМІ США, що містить у собі опис лексики, структури процесів, галузі знань: керування змістом проекту (плану- вання із розподілом робіт); якістю з контролем результатів на відповідність стандартам якості; людськими ресурсами відповідно до кваліфікації та професіона- лізму. Нині — це стандарт IEEE Std.1490 «IEEE Guide Adoption of PMI Standard. A Guide to the Project Management Body of Knowledge». Крім цих стандартів, є багато інших, які потрібно використовувати, ви- готовляючи ПП. 3.2. Середовище фабрик програм Розглянуті в розділі 1 різні види сере- довищ можуть бути базовими для певної фабрики. Рішення залежить від фінансів замовників і знань фахівців середовища для виготовлення відповідного ПП (напри- клад, із засобами інтероперабельності ком- понентів, засобами замовника ПП тощо). У наступному часі експериментальним ва- ріантом фабрики програм у ІПС є систе- ма Eclipse [45], яка безкоштовно подається через Інтернет і має новітні концепції ви- робництва ПП із готових КПВ, а саме: — механізм задання плагінів у форма ті XML засобами Plug Development Environ- ment, що забезпечує автоматизоване їх під- ключення та нові інструменти (наприклад, Protégé, Java, RMI) репозитаріїв і готових програм; — автоматизоване підключення нових меню до інтерфейсу користувача, іконок, сценаріїв тощо; — використання мови Java. виклику RMI для опису, об’єднання різних програм у вихідному коді тощо. Ці можливості моделюють на репозита- ріях компонентів, КПВ і методі збірки в сі- мействі СПС. Згодом ця система генерації буде використана в середовищі Grid. 4. БАЗОВІ ОСНОВИ МАЙБУТНЬОЇ ФАБРИКИ ПРОГРАМ В ІПС Серед розглянутих фабрик програм найрозвинутішою є інфраструктура об числень глобального масштабу — Grid та загальна структура Eclipse. Її поява зумовлена наявністю супероб- числювальних ресурсів (кластерів, super- computers, frameworks), високопродук- т ивних мереж і низки глобальних задач, ви рішення яких не під силу звичайним ком п’ютерам. У цьому середовищі будуть ви- користані світові ресурси: комп’ютери, сис- теми програм, розподілені процесорні по- тужності, системи сховищ даних, схеми взаємодії гетерогенних платформ, розташо- ваних у географічно віддалених адміністра- тивних доменах світу. Тобто середовище Grid стане новітньою фабрикою збірки різ- норідних і різноплатформених програм для обчислення за ними наукових задач гло- бального масштабу. Ця інфраструктура буде корисна багатьом інститутами НАН України. Її впроваджуватиме ІПС. Це на- самперед наукові проекти в інститутах фі- зики, космічних досліджень і програмних систем. Для першого інституту проект спрямований на поліпшення середовища 36 ISSN 0372-6436. Вісн. НАН України, 2010, № 10 GCube новими завданнями, які вдоскона- люють наукові експерименти, пов’язані із фізичними явищами колайдера. Інститут космічних досліджень застосувує системи Grid для вирішення задач [34, 35, 42], орі- єнтованих на адаптацію, розвиток систем- них і програмних основ збірки та взаємодії різнопланових і різноплатформених комп- лексів програм і систем у межах інфра- структури Grid з подальшим застосуван- ням їх у системі НАН України і наукових центрах світового товариства. Одним з важливих завдань збірки про- грам є форматизація і перебудова типів да- них шляхом приведення до виду відповід- ної платформи (наприклад, 16-розрядної до 64-розрядної структури комп’ютерів) або до вихідного скомпільованого коду тран- слятора з МП. Такі проблеми вирішують по-різному в сучасних програмних середо- вищах. Коли готові програми обмінюються даними для інших або нових платформ у ге- терогенному середовищі, виникають колізії з їхнім обчисленням із можливим отриман- ням неправильного кінцевого результату. ІПС пропонує нове фундаментальне ви- рішення завдань передачі даних по мережі, суть його полягає у розробленні оригіналь- ної системи генерації GDT загальних ти- пів даних із FDT [22–25] сучасних МП, на яких описують програми для фізичних, бі- ологічних та інших експериментів. Основи системи генерації GDT<=>FDT викладено у стандарті ISO/IEC 11404– 2007 (General Data Types) [26]. 4.1. Загальна характеристика типів даних FDT і GDT Фундаментальні типи даних — FDT визначають типи, операції над значеннями і формати їх подання на комп’ютері. Тип є математичним поняттям, що позначає мно- жину значень елементів. Базовий тип — еле- ментарний тип (ціле, дійсне та ін.), значен- ня якого визначає апаратура, компілятори програм з МП. Тип присвоєно змінній у програмі з МП, що визначає клас значень, кожне з яких належить одному й тільки од- ному типу. Операції над значеннями типу — аксіоми, що перетворюють відображення значень одного типу в значення іншого типу. FDT включають прості, структурні, складні дані, множину операцій і значень типів даних, їх властивості та зв’язки з ін- шими типами даних. Прості типи — пере- раховані й числові; структурні — масиви, записи тощо; складні — множини, об’єд- нання, динамічні дані, списки, послідовнос- ті, стеки, дерева та ін. Типи даних призначені для опису функ- цій програм у МП. Вони реалізовані систе- мами програмування на різних платформах комп’ютерів у вихідний код, який є джере- лом не лише для виконання програми на цій МП, але й для забезпечення взаємодії у різних сучасних середовищах, коли вони відрізняються між собою. Кожна реалізо- вана програма відображає тип даних кон- кретної МП, значення якої передано іншій програмі шляхом виклику (звернення) або протоколу. Типи даних загального призначення — GDT подані у стандарті ISO/IEC 11404– 2007 за номенклатурою і семантикою набо- рів типів даних, що найчастіше використо- вують у МП та інтерфейсах ПП. LI-типи да- них (LI — Language Independed) незалежні від МП, вони специфіковані як примітив- ні (базові, незалежні від інших) типи даних і непримітивні, що повністю/частково ви- значені через інші типи даних і становлять класи типів даних, реальні представники яких використані в МП, що ґрунтуються на концепції FDT. Механізм звернення — ви- клик процедур із завданням інтерфейсу до кожного стандартного сервісного засобу чи деякої системи. Типи даних стандарту створюють простір значень — сукупність (колекцію) значень деякого типу, що визначають одним із та- ISSN 0372-6436. Вісн. НАН України, 2010, № 10 37 ких способів: перелічення; аксіоматичність згідно з основними положеннями; підмно- жина вже визначеного простору значень; комбінація будь-яких значень визначено- го простору значень шляхом конструюван- ня нових значень. Кожне окреме значення належить тільки одному типові даних або кільком підтипам. Модель типів даних обчислювальна, аб- страктна. Вона має справу із властивостями одиниць інформації для визначення харак- терних операцій щодо типів даних та їхніх генераторів, типи даних яких можуть бути подані в комп’ютерні системи. Типи даних можуть належати одному сімейству, якщо існує заміна, яка перетворює весь простір значень одного типу даних (domain) у під- множину (діапазон) простору значень ін- шого типу так, щоби зберігалиcя значення відношень і характеристичних операцій із домену й діапазону. Генератор типів даних (datatype gene- rator) — концептуальна операція над одним або кількома типами даних, яка створює новий тип даних. Він формує згенерований чи параметричний тип даних. Згенеровані агрегатні типи даних можуть отримувати значення параметричних типів даних. Він має назву компонента типу даних, значен- ня яких відрізняються між собою власти- востями і відношеннями між кожним ком- понентом і агрегатним значенням. Рис. 5. Схема перебудови FDT<=>GDT 38 ISSN 0372-6436. Вісн. НАН України, 2010, № 10 Згенеровані типи даних (generated datatypes) — типи даних, які отримано в результаті застосування генератора типів даних як операції для створення нового типу з одного чи кількох типів даних. Цей тип даних семантично залежить від різних параметричних типів і має власні характе- ристичні операції. Стандарт має такі гене- ратори типів даних: вибір (сhoice), покаж- чик (pointer), процедура (procedure), запис (record), набір (set), портфель (bag), послі- довність (sequence), масив (array), таблиця (table) тощо. Із практичної точки зору типи даних ге- нерують за допомогою спеціального набору процедур (функцій), які треба розробляти для використання в різних комп’ютерних системах. Для цього пропонується нова схема генерації типів даних GDT<=>FDT. 4.2. Основні функції схеми генерації типів даних Відповідно до схеми генерації (рис. 5) слід розробити набір бібліотечних функцій (процедур) у загальноприйнятій мові XML для застосування їх при відображенні різ- них типів даних у програмах на сучасних або майбутніх МП за такими функціями: — перебудови типів даних МП1,…, МПn; — подання опису типів даних FDT; — представлення GDT у формі для об- роблення й апробування схеми FDT; — відображення типів даних GDT<=> FDT. Теорію подання FDT розроблено із при- кладами опису для класу МП 4GL [2–25, 60]. Для реалізації вказаного набору функ- цій необхідно провести: 1) створення бібліотек функцій для пе- ретворення типів даних GDT (примітив- них, агрегатних і генерованих) до FDT (простих, структурних і складних) МП як необхідних елементів середовища взаємо- дії різномовних компонентів, підсистем і проектів системи Grid; 2) специфікацію зовнішніх типів даних компонентів, підсистем і систем у МП за- собами мови GDT з накопиченням їх в од- ному з репозитаріїв середовища фабрики; 3) розроблення формату нових посе- редників, подібних до stub, з операція- ми звертання до відповідних функцій GDT<=>FDT з метою передачі взаємодію- чому компоненту і зворотно нерелевантних і перебудованих типів даних. Отже, проблему збирання різнорідних компонентів у нових МП з урахуванням архітектури платформ і гетерогенних сере- довищ у майбутньому, на наш погляд, буде розв’язано на інструментах і засобах пере- будови типів даних GDT<=>FDT. ВИСНОВКИ А втори і співробітники ІПС НАН Украї- ни стояли при витоках ідеї фабрик про- грам. У статті розглянуто основні позиції концепції академіка Глушкова, попередні шляхи її розвитку в Інституті кібернетики, основи чинних фабрик програм, базисом яких є інтегровані середовища збірки ПП, та сформульовано перспективні напрями. Наведено головні методи підтримки фа- брики програм у ІПС, а також подано орг- структуру сучасної фабрики програм для збірки окремих і готових компонентів, ви- значено ресурси, необхідні для її функціо- нування. Проект ІПС з інфраструктури системи Grid орієнтований на створення засобів пе- ретворення загальних типів даних стандар- ту GDT<=>FDT відповідно до нової кон- цепції, що відрізняється перебудовою типів даних сучасних і нових МП у майбутніх ге- терогенних середовищах із використанням оригінальної бібліотеки функцій відобра- ження GDT до FDT, а також функцій за- безпечення невідповідностей і відміннос- тей різних платформ комп’ютерів. Буде по- будовано і звичайні види інтерфейсів — конфігураційні файли, а також нові види ISSN 0372-6436. Вісн. НАН України, 2010, № 10 39 зв’язків і взаємодій компонентів, підсис- тем, СПС для виконання ПП у середовищі Європейського проекту Grid за участю різ- них інститутів НАН України. 1. Капитонова Ю.В., Летичевский А.А. Парадигмы и идеи академика В.М. Глушкова. — К.: Наук. дум- ка, 2003. — 454 с. 2. Глушков В.М., Лаврищева Е.М., Стогний А.А. й інші. Система автоматизации производства прог рамм (АПРОП). — К.: Ин-т кибернетики АН УССР, 1976. — 134 с. 3. Сергиенко И.В., Парасюк И.П., Тукалевская Н.И. Автоматизированные системы обработки дан- ных. — К.: Наук. думка, 1976. — 256 с. 4. Глушков В.М., Капитонова Ю.В., Летичевский А.А. О применении метода формализованных тех- нических заданий к проектированию программ обработки структур данных // Кибернетика. — 1978. — №6. — С. 31–43. 5. Вельбицкий И.В., Ходаковский В.Н., Шолмов Л.И. Технологический комплекс производства про- грамм на машинах ЕС ЭВМ и БЭСМ-6. — М.: Статистика, 1980. — 264 с. 6. Лаврищева Е.М., Грищенко В.Н. Связь разноязы- ковых модулей в ОС ЕС. — М.: Финансы и стати- стика, 1982. — 127 с. 7. Кахро М.И., Калья А.П., Тыугу Э.X. Инструментальная система программирования ЕС ЭВМ (ПРИЗ). — М.: Финансы и статистика, 1982. — 157 с. 8. Волховер В.Г., Иванов Л.А. Производственные методы разработки программ. — М.: Финансы и статистика, 1983. — 208 с. 9. Лаврищева Е.М. Основы технологической подго- товки разработки прикладных программ СОД. — К., 1987. — 30 с. 10. Лаврищева Е.М., Грищенко В.Н. Сборочное про- граммирование. — К.: Наук. думка, 1991. — 213 с. 11. Лаврищева Е.М. Проблематика программной ин- женерии. — К.: Знання, 1991. — 17 с. 12. Липаев В.В., Позин Б.А., Штрик А.А. Технология сборочного программирования. — М.: Радио и связь, 1992. — 272 с. 13. Андон Ф.И., Лаврищева Е.М. Методы инженерии распределенных компьютерных приложений. — К.: Наук. думка, 1997. — 229 с. 14. Лаврищева Е.М. Сборочное программирование. Некоторые итоги и перспективы. // Проблемы программирования. — 1999. — №2. — С. 20–31. 15. Лаврищева Е.М. Методы программирования. Те- ория, инженерия, практика. — К.: Наук. думка, 2006. — 451 с. 16. Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврище- ва Е.М., Суслов В.Ю. Основы инженерии качества программных систем: 2-е изд. — К.: Академперио- дика, 2007. — 680 с. 17. Коваль Г.И., Коротун Т.М., Лаврищева Е.М. Об одном подходе к решению проблемы межмодуль- ного и технологического интерфейсов // Диало- говые системы: Межотрасл. сб. АН СССР и Мин- вуза СССР. — 1988. 18. Лаврищева Е.М. Интерфейс в программирова- нии // Проблеми програмування. — 2007. — №2. — С. 126–139. 19. Лаврищева Е.М. Становление и развитие модульно-компонентной инженерии программи- рования в Украине. — 33 с. 20. Лаврищева Е.М. Сборочное программирование. Теория и практика // Кибернетика и системный анализ. — 2009. — №6. — С. 1–12. 21. Лаврищева Е.М., Грищенко В.Н. Сборочное про- граммирование. Основы индустрии программ- ных продуктов: 2-изд. — Доп. и перераб. — К.: Наук. думка, 2009. — 370 с. 22. Гоар К.О. Структурная организация данных // Структурное программирование. — М.: Мир, 1975. — С. 92–197. 23. Турский В. Методология программирования. — Пер. с анг. — М.: Мир, 1981. — 265 с. 24. Агафонов В.Н. Типы и абстракция данных в язы- ках программирования // Данные в языках про- граммирования. — М.: Мир, 1982. — С. 267–327. 25. Замулин А.В. Типы данных в языках программиро- вания и базах данных. — М.: Наука, 1987. — 152 с. 26. Стандарт ISO/IEC 11404–2007. General Data Types. 27. Лаврищева Е.М., Коваль Г.И., Коротун Т.М. Под- ход к управлению качеством программных си- стем обработки данных // Кибернетика и систем- ный анализ. — 2006. — №5. — С. 174–175. 28. Лавріщева К.М. Перспективні дисципліни про- грамної інженерії // Вісник НАН України. — 2008. — №9. — С. 12–17. 29. Corbin J. The Art of Distributed Applications. Pro- gramming Tech. for Remote Procedure Calls. — Ber- lin: Springer Verlag, 1992. — 305 p. 30. Эммерих В. Конструирование распределенных объектов. Методы и средства программирова- ния интероперабельных объектов в архитектурах OMG/CORBA, Microsoft/COM и Java/RMI. — М.: Мир, 2002. — 510 с. 31. Бей И. Взаимодействие разноязыковых прог- рамм. — М., СПб., К.: Изд. дом «Вильямс», 2005. — 868 с. 32. Гринфильд Дж. Фабрики разработки программ. — М., СПб., К.: Изд. дом «Вильямс», 2007. — 591 с. 33. Guckenheimer S., Perez J.I. Software Engineering with Microsoft Studio Team System. — Crawfords- ville: Adison–Wesley, 2006. — 304 p. 40 ISSN 0372-6436. Вісн. НАН України, 2010, № 10 34. Meglio A., Bégin M.E., Couvares P., Ronchieri E., Takacs E. ETICS: the International Software Engi- neering Service for the Grid // Journal of Physics Conference. — 2008. 35. Таковицкий О. Технология Grid computing. — С. 1–9. 36. Norhrop L.M. Software SEI’s Рroduct Line Tenets // IEEE Software. — 2002. — V. 19. — №4. — P. 32–39. 37. Чернецки К., Айзенекер У. Порождающее про- граммирование. Методы, инструменты, примене- ние. — М., СПб., Харьков, Минск: Издательский дом «Питер», 2005. — 730 с. 38. Лаврищева Е.М. Классификация дисциплин программной инженерии // Кибернетика и сис темный анализ. — 2008. — №6. — С. 3–9. 39. Лавріщева К.М. Визначення предмету — програм- на інженерія // Проблеми програмування. — 2008. — №2–3. — С. 191–204. 40. Лавріщева К.М. Програмна інженерія — напрями розвитку // Праці міжнародної конференції «50 років Інституту кібернетики імені В.М. Глушко- ва НАН України». — К., 2008. — С. 336–345. 41. Лаврищева Е.М. Проблема интероперабельности разнородных объектов, компонентов и систем. Подходы к ее решению // Матер. 7 міжнародної конференції з програмування. — С. 28–41. 42. Castelli D., Candela L., Pagano P., Simi M. 2005 2nd IEEE — CS International Symposium Global Data Interoperability (IEEE Computer Society). — P. 56–99. 43. http.//swebok.com 44. Лавріщева К.М. Генерувальне програмування програмних систем і сімейств // Проблеми про- грамування. — 2009. — №1. — С. 3–16. 45. Карлсон Д. Eclipse. — Изд. «Лори», 2004. — 335 с. 46. http.//www.oberon_ethz.ch 47. http.//en.wikipedia.org/babel-middleware 48. Грищенко В.Н., Лаврищева Е.М. Методы и сред- ства компонентного программирования // Ки- бернетика и системный анализ. — 2003. — №1. — С. 39–55. 49. Грищенко В.М. Метод об’єктно-компонентного проектування програмних систем // Проблеми програмування. — 2007. — №2. — С. 113–125. 50. Коротун Т.М. Моделі й методи інженерії тесту- вання програмних систем в умовах обмежених ресурсів. Автореф. дисер. — К.: Інст. кібернетики ім. академіка Глушкова, 2005. — 21 с. 51. Коваль Г.І. Моделі й методи інженерії якості про- грамних систем на ранніх стадіях життєвого ци- клу. Автореф. канд. дисер. — К.: Інст. кібернетики ім. академіка Глушкова, 2005. — 19 с. 52. Слабоспицька О.О. Моделі та методи експертного оцінювання у життєвому циклі програмних сис- тем. Автореф. канд. дисер. — К.: Інст. кібернетики ім. академіка Глушкова, 2008. — 21 с. 53. Задорожна Н.Т. Кероване проектування докумен- тообігу в управляючих інформаційних системах. Автореф. канд. дисер. — К.: Інст. кібернетики ім. академіка Глушкова, 2004. — 21 с. 54. Задорожна Н.Т., Лавріщева К.М. Менеджмент до- кументообігу в інформаційних системах освіти. — К.: Педагогічна думка, 2007. — 220 с. 55. Бабенко Л.П., Лавріщева К.М. Основи програмної інженерії. Посібник. — К.: Знання, 2001. — 269 с. 56. Бабенко Л.П. Проблемы повторного использова- ния в программной инженерии // Кибернетика и системный анализ. — 1999. — №2. — С. 155–166. 57. Protégé-OWL API Programmer’s Guide <URL: http://protege.stanford.edu/doc/owl/guide.html 58. Коваль Г.І., Колесник А.Л., Лавріщева К.М., Сла- боспицька О.О. Удосконалення процесу розроб- лення сімейств програмних систем елементами гнучких методологій // Проблеми програмуван- ня. — 2010. — №2–3. — C. 261–270. 59. Лаврищева Е.М., Слабоспицкая О.А. Подход к экспертизе оценивания в программной инжене- рии // Кибернетика и системный анализ. — 2009. — №4. — С. 151–168. 60. Лавріщева К.М. Програмна інженерія. Підруч- ник. — К.: Академперіодика, 2008. — 450 с. П. Андон, К. Лавріщева РОЗВИТОК ФАБРИК ПРОГРАМ В ІНФОРМАЦІЙНОМУ СВІТІ Р е з ю м е У 1975 р. академік Глушков запропонував концеп- цію конвеєрного способу виробництва ПП з готових програм. У статті проаналізовано розвиток цієї кон- цепції на прикладі попередніх і сучасних фабрик програм; засвідчено появу двох основних понять ви- робництва: інтерфейс як стиковочний елемент із пе- редачі і трансформації програм, що збираються, та інтегроване середовище збірки готових різнорідних програм із деяких МП. Упродовж останніх 35 років вони постійно вдосконалювались і стали базисом су- часної фабрики програм, наприклад, в інфраструк- турі Європейського проекту Grid, призначеного для обчислювання наукових завдань. Автори оприлюд- нюють результати наукових досліджень Інституту програмних систем НАН України, дають визначення фабрики програм за збіркою ПП із різнорідних і різ- ноплатформених програм з використанням люд- ських, технологічних та інструментальних ресурсів. Інститут планує упроваджувати ці результати в сис- тему Grid і в інститутах НАН України. В межах сис- теми будуть розроблені нові засоби інтерфейсу різ- норідних програм із перетворення стандартних ISO/ IEC 11404–2007 типів даних до тих, що є в багатьох мовах програмування, процедури генерації яких зба- ISSN 0372-6436. Вісн. НАН України, 2010, № 10 41 гатять майбутні гетерогенні середовища сучасними засобами збірки програм. Ключові слова: системи автоматизації, індустрія, ви- робництво програмних продуктів, інтерфейс, переда- ча типів даних, трансформація програм.. Andon P., Lavrischeva K. PROGRAM FACTORIES DEVELOPMENT IN THE INFORMATION WORLD A b s t r a c t In 1975, academician Hluskov proposed assembly line way in program products (PP) from ready programs manufacturing concept. The article analyzes that con- cept development on previous and modern program fac- tories example; demonstrates the appearance of two main notions in production — 1) interface as butt-joint ele- ment in assembling programs assignation and transfor- mation; 2) integrated medium for ready various programs of certain program languages assembling. During last 35 years they are being constantly improved and become a modern program factory basis, exempli gratia in the in- tended for scientific tasks calculation European Project Grid infrastructure. Authors expose the results of Pro- gram Systems Institute of Ukrainian NAS scientific ex- plorings; give definition for the program factory assem- bling PP of various programs having different platforms with the usage of human, technology and instrument re- sources. Institute plans to instill those results into Grid system and Ukrainian NAS institutes. Within system creases, new interface means will be treated. They belong to various programs transforming data types of ISO/IEC 11404–2007 standard to ones existing in the large number of program languages whose generation proce- dures enrich future heterogenous environments with modern program assembling means. Keywords: automatization systems, industry, program products production, interface, data type assignation, program transformation.

Розвиток фабрик програм в інформаційному світі

Institution

Ähnliche Einträge