
- •Перелік термінів та позначень
- •Передмова
- •Частина 1. Початок програмування в срср. Витоки розвитку
- •1.1. Поява і розвиток технології програмування (1952–2012)
- •1.2. Формування технологічних напрямів (1965–1975)
- •1.3. Становленья технології програмування (1975–1982)
- •1.4. Розвиток інтерфейсу в технології програмування (1976–1992)
- •1.5. Розвиток об’єктної технології програмування (1992–2002)
- •1.6. Індустріальні основи технології програмування (2002–2012)
- •1.7. Навчання тп у кну Тараса Шевченко (1965–2012) та філії мфті (2000–2012)
- •Контрольні питання і завдання до частини 1
- •Список літератури до частини 1
- •Частина 2. Парадигми технології програмування
- •2.1. Модульне програмування та збиральний підхід
- •2.1.1. Інтерфейс в програмуванні
- •2.1.2. Зборка модулів по а.П.Єршову
- •2.1.3. Метод зборки готових програмних елементів
- •2.1.4. Формальне подання методу збирання різномовних модулів
- •2.2. Парадигма об’єктно-орієнтованого програмування
- •2.2.1. Базові концепції ооп
- •2.2.2. Чотирьох рівневе проектування ом
- •2.2.3. Концепції об’єктного аналізу
- •2.2.4. Функції, алгебра та операції об’єктного аналізу
- •2.2.5. Моделювання моделі ПрО
- •2.2.6. Опис параметрів інтерфейсу ом
- •2.3. Парадигма uml-метода моделювання
- •2.3.1 Основні діаграми методу
- •2.3.2. Моделювання поведінки системи
- •2.3.3. Побудова пс засобами uml
- •2.4. Парадигма компонентного програмування
- •2.4.1. Теоретичні аспекти компонентного програмування
- •2.4.2. Моделі компонентного програмування
- •2.4.3. Графове подання компонентної моделі ПрО
- •2.4.4. Об’єднання компонентів. Модель середовища
- •2.4.5. Компонентна алгебра
- •2.4.6. Іінструментальні засоби кп
- •2.4.7. Технологія компонентної розробки пс
- •2.4.8. Типізація і класифікація програмних компонентів
- •2.4.9. Жц проектування пс із типових компонентів та кпв
- •Розробка вимог до пс – це формування та опис функціональних, технологічних, організаційних та ін. Властивостей програмної системи, які необхідні чи бажані з точки зору кінцевого користувача.
- •Розгортання рпс. У випадку, коли рпс створюється для конкретного замовника, який є і користувачем, то деякі завдання розгортання виконуються на попередніх етапах. До них, зокрема, відносяться:
- •Супровід рпс компонентній пс характеризується наступними особливостями.
- •2.5. Парадигма аспектно-орієнтованого програмування
- •2.5.1.Основні елементи парадигми аоп
- •2.5.2. Засоби аоп
- •2.5.3. Підтримка аоп впродовж життєвого циклу пс
- •2.5.5. Методичні аспекти аоп
- •2.6. Парадигма генерувального програмування
- •2.6.1 Предметно-орієнтована мова – dsl
- •2.6.2. Простір проблем і рішень ПрО
- •2.6.3. Інженерія ПрО і кпв
- •2.7. Сервісно-орієнтоване програмування
- •2.7.1 Базові понятті сервісу Інтернет
- •2.7.2. Сервіси wcf мs.Net з контрактами
- •2.8. Парадигми теоретичного програмування
- •2.8.1 Алгебраїчне та інсерційне програмування
- •2.8.2. Реалізація агентних програм
- •2.8.3. Експлікативне, номінативне програмування
- •2.8.4. Алгоритмічні алгебри
- •Контрольні питання і завдання до частини 2
- •Список літератури до частини 2
- •Частина 3. Моделі і засоби проектування предметних областей
- •3.1. Моделі проектування ПрО предметних областей
- •3.1.1. Концептуальні моделі пс, спс за компонентами
- •3.1.2. Моделі взаємозв’язку об’єктів
- •3.1.3. Модель інтеграції (зборка) компонентів
- •3.1.4. Тестування прикладних і інтерфейсних об'єктів
- •3.1.5. Моделі взаємодії і варіабельності пс для організації обчислень
- •3.1.6. Підхід до виконання пс в сучасних розподілених середовищах
- •3.2. Онтологічний підхід до подання знань про проблемні області
- •3.2.1. Онтологічне моделювання проблемної області
- •3.2.2. Мовний опис онтології домену чи спс
- •3.2.3. Підхід до реалізація онтології ПрО
- •3.3. Типи даних та засоби їх генерації для використання в збиральному прогрмуванні
- •3.3.1. Проблема забезпечення сумісності типів даних при зборки кпв
- •3.3.2. Аксіоматика простих типів даних
- •3.3.3. Аксіоматика структурних і складних типів даних. Структурні типи даних.
- •3.3.4. Семантичні аспекти взаємодії різнорідних програм
- •3.3.5. Характеристика типів даних для зборки програм
- •3.3.6. Фундаментальні і загальні типи даних
- •3.3.6. Баові поняття стандарту з типів даних
- •3.3.7. Перебудова загальних типів даних до фундаментальних для мп
- •3.4. Підходи і методи доказу програм
- •3.4.1. Мови специфікації програм –vdm, raise, Concept
- •3.4.2. Концепторна мова специфікації
- •3.4.3. Методи доведення правильності програм
- •3.4.4. Модель доказу програми за твердженнями
- •З.5. Проектування пс засобами жц з реалізації доменів
- •3.4.1. За загальна характеристика стандарту жц iso/iec 12207:2002
- •3.4.2. Формування конкретних моделей життєвого циклу
- •3.4.3. Підходи до моделювання ПрО мовними засобами dsl
- •3.6. Модель якості пс
- •3.6.1. Структура моделі якості
- •3.6.2. Модель витрат сосомо Боєма
- •3.6.3. Інтегрована модель витрат на спс
- •Контрольні питання і завдання до частини 3
- •Список літератури до частини 3
- •Частина 4. Методи індустрії виробицтва програм і систем
- •4.1. Загальні основи методології виробництва пс і спс
- •4.1.1. Моделі взаємодії компонентів у пс
- •4.1.2 Методологічні аспекти виробництва спс з готових ресурсів
- •4.2. Мова опису моделей взаємодії на основі xml
- •4.2.1 Подання та обмін даними в компонентних моделях
- •4.2.3 Модель конфігурації компонентів на основі xml
- •4.3. Графове подання пс і спс
- •4.3.1 Графове визначення моделі взаємодії об'єктів
- •4.3.2 Типи зв’язків об’єктів у графової моделі ПрО
- •4.4. Розробка методів побудови проблемно-орієнтованих технологій
- •4.4.1. Аналіз динаміки розвитку фабрик програм
- •4.3.2. Базисні ресурси фабрики програм
- •4.5. Загальні лінії виробництва програм з кпв
- •4.4.1. М етодологія побудови тл
- •4.4.2. Нові дисципліни індустрії наукового совтвера
- •4.4.3. Новітні засоби Grid і Cloud для обчислення задач e–sciences
- •4.4.4. Сучасні системи побудови рпс з сервісних ресурсів
- •4.4.5. Методологія розроблення тл
- •4.4.6. Принципи проектування іс
- •4.5. Методи при оцінюванні економічних характеристик проектів
- •4.5.2. Формальний апарат експертно-аналітичного оцінювання об’єктів і процесів у спс
- •4.5.3. Методи оцінки розміру
- •4.6. Створення Windows застосувань
- •4.6.1. Створення нової програми.
- •4.6.2. Властивості і дизайн програм
- •4.6.3. Компіляція програм
- •2.5. Запуск застосунка
- •4.6.4. Розширення функціональності програм
- •4.7. Інженерії тестування програмних систем
- •4.7.1. Основні поняття інженерії тестування
- •4.7.2 Становлення інженерії тестування
- •4.7.3. Методи тестування. Метрики і критерії
- •4.7.4. Інструменти тестування та оцінювання
- •4.7.5. Тестування веб-застосувань
- •Контрольні питання і завдання до частини 4
- •Список літератури до частини 4
- •5.2. Фабрика програм в кну
- •5.2.3. Створення фабрики студентів
- •5.2.4. Лінії продуктів фабрики на головної сторінки
- •5.2.5. Принципи роботи з репозиторієм програм і артефактів
- •5.2.6. Навчання дисципліні “Програмна інженерія” на фабрики
- •5.3. Репозиторій кпв
- •5.3.1. Загальний опис репозиторію
- •5.3.2. Технологія обслуговування репозиторію кпв
- •5.4. Розробка кпв
- •5.4.1. Опис моделей кпв, інтерфейсу і операцій розробки кпв
- •5.4.2. Реалізація побудови компонентної системи
- •5.4.3. Процеси технології оброблення кпв
- •5.4.4. Зборка різномовних програм у середовищі Visual Studio
- •5.5. Конфігурація кпв
- •5.5.1. Конфігурування кпв з урахуванням варіабельності
- •5.5.2. Опис прикладу використання конфігуратору програм
- •5.6. Генерація систем мовою dsl
- •5.6.1. Лінія опису та генерації доменів dsl
- •5.6.2. Опис життєвого циклу пз та його реалізації на мові dsl
- •2.7. Онтологія – обчислювальна геометрія
- •5.7.1. Онтологія домену – Обчислювальна геометрія
- •5.7.3. Опис моделі онтології ПрО «Обчислювальна геометрія»
- •5.7.4. Опис програми домену «Обчислювальна геометрія» мовою owl
- •5.8. Оцінка якості пс
- •5.8.2. Оцінка витрат на продукт
- •5.8.3. Опис модуля прогнозування трудовитрат на розробку пс
- •5.8.4. Приклад оцінювання затрат на розробку пс ас
- •5.9.1. Опис веб-технології Java ee
- •5.9.3. Приклад взаємодії Java і ms.Net через веб-сервіси
- •5.9.4. Інструкція по використанню графічного інтерфейсу прикладу
- •5.10. Генерація тд
- •5.10.1. Відображення типів даних у середовищі ітк
- •5.10.2. Система генерації загальних типів даних до фундаментальних
- •5.11. Інструментальні засоби сайта ітк
- •5. 12. Розділ сайта «Технологія навчання»
- •Контрольні питання і завдання до частини 5
- •Список літератури до частини 5
- •Післямова
- •Додаток 1. Парадигма структурного програмування
- •Додаток 2. Приклад створення служб wcf у ms Visual Studio 2010
- •Додаток 3. Онтологічний підхід з подання тестування кпв та пс
- •Додаток 4. Оцінка застосування метода сосомо на конкретних даних
- •Додаток 5. Програма курсу «Технологія програмування іс»
4.4. Розробка методів побудови проблемно-орієнтованих технологій
4.4.1. Аналіз динаміки розвитку фабрик програм
Концепцію фабрик програм уперше сформулював академік В.М. Глушков на науковому семінарі 5 березня 1975 р. в Інституті кібернетики (ІК). Суть цей парадигми Глушкова – прискорити перехід від мистецтва програмування до промислових методів виробництва програмних продуктів (ПП) для розв’язання різних господарських задач у межах Радянського союзу і СЄВ.
Аналіз фабрик програм проведено, починаючи з того часу, коли цю ідею висловив акад. В.М. Глушков. Особливу увагу було приділено розробленим середовищам і системам з автоматизованим виробництвом різного роду ПП із різних елементів зборки, створених «ручними», автоматизованими або частково автоматизованими засобами. Це насамперед:
1. Система АПРОП в ІК, що працювала в середовищі ОС ЄС і об’єднувала за методом зборки різномовні модулі в МП 4GL через інтерфейсні міжмовні і між модульні посередники [2, 6, 9, 10, 19–21];
2. Інтегроване середовище IBM зі зборкою різномовних програм у 90–х рр. ХХ ст. і подальшим розвитком нових напрямів виробництва ПП, зокрема, моделлю архітектури SOA, Web-сервісами, новими мовами Ruby, Script [28];
3. Клієнт-серверне розподілене середовище CORBA OMG із віддаленою взаємодією клієнта й сервера у мережі через модулі–посередники, які отримали назву «заглушок» – stub (для клієнта); skeleton, adaptor, dynamic interface Dill (для сервера) і передають зовнішні дані із запитом брокеру від клієнта до сервера і зворотні [29];
4. Фабрика «ручної» зборки різномовних програм Інга Бей із використанням кількох засобів взаємодії різнорідних програм (інтерфейсні посередники, командні рядки, конфігураційні файли, інтерфейсні карти) у середовищах (VC++, VBasic, Matlab, Java, Visual Works Smalltalk тощо) [30];
5. Фабрики програм Дж. Грінфільда з технологією побудови складних бізнесних програм з використанням методології use case (UML), ліній виробництва й модельного підходу SOA [31, 36];
5. Колективне міжнародне середовище MS.VSTS для виробництва ПП широкого призначення за участю виконавців, що можуть звертатись через Інтернет до цього середовища із різних місць світового простору [32];
7. Інфраструктура розроблення, тестування, зборки наукових програм, систем і пакетів для обчислення їх у мережі Європейського проекту Grid [34–36] тощо.
8. Технологічна схема виробництва програмних продуктів Г. Ленца [52].
9. Фабрика за архітектурним каркасом, схемою Авдошина [53]
10. Зборочний конвеєр Глушкова та ін.
Домо короткий огляд названих систем
Система АПРОП – це фабрика, що працювала у середовищі ОС ЄС і забезпечувала зборку різномовних модулів у монолітну структуру на ЄС ЕВМ через інтерфейсні посередники, згенеровані за допомогою спеціально розробленої бібліотеки функцій перебудови не релевантних FTD типів даних (наприклад, символьне до цілого), що передаються CALL–викликами у модулях в МП 4GPL, які реалізують методи чисельного аналізу і статистики з Банку модулів.
Система IBM – середовище зі зборкою різномовних програм в мовах 4GPL (80–і роки) за допомогою зовнішніх інтерфейсних FDT даних, що трансформуються функціями XDR –бібліотеки, Sun Workshop, Toolbox тощо. Подальшим розвитком нових напрямів виробництва ПП цього середовище є модель архітектури SOA, Web–сервіси, нові мови С, С++, Java, Ruby, Script з забезпеченням зв'язків усіх програм в МП і з портуванням їх даних засобом AIX. Інтеграція різнорідних програм виконується на загальної платформі IBM у операційному середовищі, а також на сервері (WebSphere Application Server Compunity Edition).
Система CORBA або ОМА–архітектура (Apple, IBM, Win–NT, x–Open, Dec), як фабрика програм підтримує зв’язки різномовних об’єктів у МП (С, C++, Smalltalk, Java, Cobol, Visual , Ada–96) через інтерфейсні посередники (stub, skeleton, dill) за їх описом мовами ІDL, DII для клієнт–серверної архітектури (Client–interface, Server–Interface) з використанням операційних середовищ (COSS, DCE/RPC, PCTE, ToolTalk, Java2SDK, NetPilot CCS тощо). Дані між клієнтом і сервером передаються за протоколами TCP/IP, IIOP через брокера ORB, який забезпечує їх сервісом з перебудови невідповідних типів даних різномовних об’єктів, а також для усунення неоднорідності платформених даних взаємодіючих об’єктів клієнта і сервера. Це середовище підтримує зв’язки з іншими середовищами, як CORBA, OLE/DCOM, SOM/DSOM, IBM OS тощо
Фабрика «ручної» зборки по Інгу Беєві. Базисом цієї фабрики виробництва різномовних програм є інтерфейсні посередники, командні строки, конфігураційний файл перевірені автором у сучасних операційних середовищах (VC++, VBasic, Matlab, Java, Visual Works Smalltalk тощо) для різних платформ (Microsoft.Net, HP, Apple, IBM тощо). В них автор розробив різні варіанти зв’язків пар різномовних програм у наведених МП з використанням функцій перетворення не релевантних типів даних і з урахуванням особливостей платформ і принципів завдання зв’язків шляхом передачі даних протоколами, а також різними механізмами виклику інших програм – Active, строковий формат, dll–data, External interface class, а також засоби RMI, Java Native Interface, виклик exe–файлу, інтерфейсні карти MIO–16E–2. Апробовані Domain and Application Model, Model Interconnection, Microsoft Foundation, а також сучасні візуальні засоби, такі як, панелі, сценарії, іконки тощо. Вони дозволяють виконувати зміни типів даних і їх повторну перебудову з поверненням до модулів, що викликають інших.
Фабрика програм з UML Дж.Гринфильда. Для майбутній діючій фабрики сформульовані методологічні і технологічні аспекти виробництва систем за методом UML, моделями архітектур систем і комп’ютерів, механізмами інтеграції різнорідних компонентів з багатьох типів даних FDT і різних мов взаємодії (IDL, XML, RDF тощо). Головні концептуальні концепції виробництва: reuse, що накопичені у загальноприйнятих сховищах (бібліотеках, репозитаріях тощо) з сертифікатом якості; еволюція активів, програм і систем; використання моделей, шаблонів і інструментів з UML–побудови ПП на Product lines; веб–сервісне обслуговуння процесів ліній; вимірювання і контроль якості ПП тощо. Результати моделювання UML на цієї фабрики такі: мова UML є мовою ескізу ПП, що не допускає використання reuse і інтерфейсу з компонентами на різних МП; проблеми з модифікацією ПП тощо.Фактично розроблений автором меморандум сучасної фабрики ПП базується на reuses з використанням виробничих ліній, моделях систем, каркасах процесів и продуктів.
Фабрики програм фірми Microsoft. Базисом фабрики є середовище МS.NET з великою кількістю засобів і інструментів, а саме: готові ресурси (компоненти, сервіси) з Інтернету, базові мови – JAVA, C++, Basic, Java, Pascal, C#, бібліотеки CLR і FCL, зборка кодів (exe, dill) у готовий ПП, веб–застосування різного призначення, пакет VSTS, MSF, PM–2007 для керування розробниками ПП в різних місцях світу. До складу фабрики входять такі інструментальні системи: пакет інструментів VSTS–2005 (Visual Studio Teams Systems); MSF (Microsoft Solution Arhitecture) для побудови виробничій архітектури підприємства, стандарт PMBOK з керування ПП, моделі процесів і систем; Professional Studio та Foundation Server для підтримки процесів проектування, кодування, SDLC, IDE, MS Office, MS SQL server, MS Visual Studio 2005 для розроблення, тестування, формування версій ПП; CMMI Process Impovement для удосконалення процесів зборки. При зборки програм використовуються CLR–бібліотеки (Common Language Routine.), класи, FCL–типів, транслятори, а також General code (exe), Portable Executable code тощо з визначенням строків, працевтрат та показників якості з виробництва різних видів ПП командою фахівців.
Інфраструктура обчислення наукових задач Grid. Європейський проект Grid – мережна інфраструктура для організації розподілених обчислень задач по різним науковим напрямам (фізика, математика, медицина, біологія й ін.) [34, 35]. Він включає ряд підпроектів: Gcube–операційне середовище, ETICS – як збиркове середовище тощо. Призначений на ініціативне виробництво розподілених систем шляхом інтеграції існуючих процедур, інструментальних засобів і ресурсів з застосуванням Веб–порталу і мультіплатформених ресурсів.
Технологія створення великих наборів пакетів з вихідних або комбінацій перекомпильованих двійкових програм підтримується процесом доступу до репозитарію для формування розподіленої версії і її репродукції з урахуванням виконання компонентів системи на альтернативної платформі мережного середовища Grid. Однієї з важливих проблем є опис типів даних для споруджуваних трьох об'єктів: Проект, Підсистема і Компонент. Модель даних з типовим форматом CIM для взаємин між різними компонентами ґрунтується на моделі даних реляційного типу MySQL з вимогами на властивості (ім'я, ліцензія, URL репозиторія і т.д.), завдання глобального унікального ідентифікатора – ID (GUID), перевірки скомпільованого компонента та зв'язків з конфігурацією системи. В ньому головне – це ресурси, зокрема сервіси, для обчислювання завдань глобального масштабу. Ресурс може бути файлом, кластером, комп’ютером. Їх внутрішні протоколи (NFS) завантажується поза системою Grid. Протоколи з ресурсів регламентують їх взаємодію за даними в розподіленої мережі, що передається між ними. На основі стандартних протоколів будуються сервіси, інтерфейси в API та засоби розробки SDK (Software Development Kits). Зборка програм на канальному рівні з різних фабрик, а також виконання компонентів, підсистем і систем наукового призначення реалізується також глобальними протоколами (Global Protocol). Підсистема ETICS по сутності близька до фабрики програм з засобами розроблення, тестування нових пакетів і послуг, а також їх об’єднування за допомогою плагінів [8] з відкритим інтерфейсом послуг для споживачів або постачальників. Плагіни забезпечують перевірку договорів, тестів для різних елементів систем, генерацію документації і ведення готових програм в оперативному або постійному його репозитарії.
Технологічна схема виробництва ПП Г. Ленца. Основоположним елементом фабрики програм авторів Г.Ленца і К.Вінєндс є схема фабрики виробництва програм, яка побудована на основі загальних стандартних підпроцесів ЖЦ: аналіз, проектування, тестування, конфігурування та еволюції виготовлених продуктів. Виготовлення ПП починається з визначення вимог для майбутнього продукту з використанням таких базових понять, як констрейни, моделі, засоби специфікації доменів і їх характеристик. Сформульовані вимоги є джерелом створення моделі доменів та опису їхній специфіки мовою DSL. Головними методами схеми лінії виробництва на цієї фабрики є трансформація і генерація. Процеси ЖЦ підтримуються програмними засобами, інструментами, що враховують архітектуру комп’ютерів і формати даних.
Автором розглянуто два головних процеси виробництва ПП:
1) процеси підготовки і побудови необхідної лінії фабрики із множини операторів і характеристик проблемного домену, на якої надалі буде створюватися конкретні програми реалізації задач домену, а також відбірки інструментів, що автоматизують підпроцеси майбутньої лінії виробництва ПП, наприклад, інформації про варіабельність моделі архітектури домену;
2) процес автоматизованої розробки на побудованої лінії ПП конкретних моделей характеристик, засобів їх трансформації і збирання частин існуючих або згенерованих програм к вихідному коду ПП і файлу конфігурації для майбутнього розгортання і виконання цього ПП в деякому визначеному середовищі.
Фабрика за архітектурним каркасом Авдошина. Одним багато використаним ресурсом і активом фабрики є архітектурний каркас – деяка відправна точка, щодо якої може бути розроблений будь-який продукт у рамках лінії. Каркас купується або розробляється організацією-розроблювачем ПП у рамках фабрики. У ньому акумулюються ресурси: класи, компоненти, конфігурації, зразки і т.п. Активи відбираються на стадії розробки лінії фабрики [52].
База знань фабрики, включає різні посібники, довідники, статті, приклади програм і програми-зразки.
Модельно-орієнтована розробка складається з генерації коду по абстрактній моделі, що оперує деяким набором понять ПрО, заданих у мові DSL за допомогою графічного дизайнера або конструктора. Моделювання понять і основних концепцій використовується при генерації коду по моделях і конфігурованні у структуру продукту.
Досвід створення окремих ПС дозволяє задати необхідну форму лінії або схему фабрики, що охоплює всі присутні активи, точки зору і зв'язку між ними. Зі схеми витягається шаблон фабрики, що уточнює набір необхідних ресурсів і автоматизує роботу інтегрованого середовища розробки.
Розроблювач фабрики задає схему фабрики (модель опису робочих продуктів у заданій ПрО, а також процеси й активи у виді колекції обраних і ретельно підібраних активів і рекомендацій для реалізації застосування на лінії. Користувач фабрики працює з шаблоном фабрики, який специфікує процес розробки.
Фабрика розглядається з двох позицій:
– розроблювача фабрики;
користувача фабрики.
Будь-яка схема фабрики складається з набору взаємозалежних точок зору, кожна з яких дозволяє глянути на систему з різних сторін. Точки зору допомагають зрозуміти логічну і фізичну сторони системи, набір використовуваних компонентів і документування архітектури сімейства ПП. Точки зору найчастіше керують створенням типів і засобів проекту. Кожна точка зору має ім'я й опис, тобто вона повинна сказати розроблювачеві, що будувати, як будувати і з чого (моделей, засобів, шаблонів і т.п.). Точки зору — це стандартні блоки схеми фабрики, що формалізують налагоджені дії, створюють і змінюють робочі продукти.
Робочі продукти, що виробляються або споживаються з даної точки зору, складають вид – екземпляр точки зору, що описує розроблювальний продукт із якої-небудь сторони. Одна точка зору може мати кілька видів з наступних елементів:
1. ідентифікатор виду і його опис;
2. представлення системи відповідно до заданої точки зору;
3. конфігурація.
Відмічається, що є аналогія між об’єктно-орієнтованим програмуванням і фабрикою, тобто відношення між класом і об'єктом відповідають відношенню виду і точки зору.
Схема фабрики – це набір взаємозалежних точок зору, необхідних для побудови заданих продуктів. Вона подібна схемі бази даних, що допомагає визначити, як організована БД, щоб можна було звертатися, запитувати і маніпулювати даними, що вона містить. Схема описує організацію фабрики, вона складається з точок зору, які у свою чергу зв'язані з конкретними ресурсами.
Шаблон фабрики – це пакет з ресурсами в складі фабрики. Він є екземпляром схеми фабрики, так само як будь-яка модель є відображенням метамоделі. Шаблон включає сукупність всіх активів, обумовлених точками зору усередині схеми фабрики. До активів відносяться наступні категорії:
– бібліотеки і каркаси, що надають багаторазово використовувані програмні компоненти, розроблені в ході проектування лінії (типа, .NET Enterprise Library );
– рекомендації, технології, розпорядження і керівництва для автоматизації рутинного процесу побудови ПП;
– мови предметної області і дизайнери, що задають необхідний рівень абстракції при розробці застосування і дозволяють генерувати код по створеній моделі.
Побудований шаблон фабрики може бути завантажений в інтегроване середовище розробки для забезпечення автоматизації розробки. Шаблон фабрики дозволяє коректно сконфігуровати усі використовувані засоби, щоб сформувати програмний продукт із заданими параметрами. Це традиційний спосіб застосування шаблона аналогічно тому, коли відсилається лист заданого формату на основі створеного шаблона.
Зборочний конвейер Глушкова.
Ідею індустрії комп’ютерів і ПП сформулював академік В.М. Глушков в Інституті кібернетики в 60–70 роках 20 сторіччя. У 1975 році він вперше сформулював концепцію зборочного конвеєра з ліній виробництва програмних ресурсів на фабриках програм. Суть цієї парадигми Глушкова – прискорити перехід від мистецтва програмування до промислових методів виробництва програмних продуктів (ПП) для розв’язання різних господарських задач у межах завдань автоматизації різних напрямів народного господарства, так званих автоматизованих систем управлянні (АСУ) в межах широко відомої на той час парадигми ОГАС, великої мережі крупних організацій держави СРСР.
Під фабрикою програм розуміється інтегрована інфраструктура організації виготовлення ПП масового використання, котрі потрібні науковим, державним. комерційним і іншим замовникам і користувачам. Фабрика обладнається технологічними лініями, набором засобів, інструментів і сервісів, необхідних для автоматизованого виконання ПП.
Основа фабрики програм – зборочний конвеєр. Він включає набір різних простіших і складних ліній виробництва програмних артефактів, програм і КПВ. Лінії конвеєра містять процеси, виконання яких підтримується системними чи технологічними компонентами, модулями, що автоматизують їх виконання. З погляду інформаційних технологій фабрика дає набір інструментів обробки даних для переходу від індивідуального програмування окремих ресурсів до індустрії ПП масового застосування. Вона збільшує продуктивність розробки продукту на кожному процесі життєвого циклу (ЖЦ) за рахунок КПВ, що мають програмно реалізовані функції з досягнутою розробниками відповідної якості. Лінія розробки простих продуктів, як правило, відповідає деякий ЖЦ, наприклад, реалізований в середовищі MS.Net з використанням рекомендацій, каркасів (Framework), мов програмування, примітивів загальних бібліотек та системних засобів підтримки нових предметно-орієнтованих мов типу DSL (Domain Specific Language) і ін. Лінія розробки складних ПП запропоновано рахувати зборочного типу, тобто це інструмент для об’єднання деякої множини КПВ і за їх інтерфейсами, які містяться в різних проміжних бібліотеках середовищ, а також в репозиторіях КПВ і інтерфейсів.
Крім розглянутих типів фабрик є й інші: інтегроване середовище Eclipse [45]; система Oberon, яка з 90–х рр. виконує зборку різнорідних програм з новими МП для опису й виготовлення ПП на даний час й на комерційній основі. Зараз системне середовище поповнено новою мовою опису наукового інтерфейсу SIDL (Scientifically IDL) для забезпечення взаємодії наукових програм у мовах C, C++, Python, Java через прошарок типа glue для платформ Linux, AIX, Solaris, IBM з орієнтацією цієї мови на майбутнє використання у інфраструктурі проекту Grid.
Проведений аналіз фабрик програм дозволив визначити важливі технологічні джерела, інструменти і атрибути, таких як платформа, зв’язки, засоби, типи даних, інтерфейс, конфігурування (збирання). Підкреслюємо, що головним центральним джерелом деякої фабрики є метод зборки готових ресурсів [16–21].