ТЕМА 8
ІНЖЕНЕРІЯ ВИРОБНИЦТВА ПРОГРАМНИХ ПРОДУКТІВ

 

Одна з характерних рис інженерної діяльності в промисловості – використання готових рішень і деталей. У програмуванні промислове використання готових рішень і програмних продуктів ще не ввішло у повсякденну практику, але сформувалися ознаки цієї інженерної діяльності. Головна ідея компонентів, КПВ, що повторно використовуються, полягає у накопиченні досвіду програмування, отриманого під час розробок різних ПС, і подання його у вигляді, придатному для використання при побудові майбутніх систем за конвеєрною технологією. Зараз накопичено велику кількість КПВ; це привело до формування таких напрямів їхнього практичного застосування у інженерній діяльності виробництва програмних продуктів [1–4]:

1) інженерія КПВ – систематична і цілеспрямована діяльність з визначення можливостей готового компонента або повторно застосовуваного в ПС, або об’єднуваного у цільову їхню сукупність для виконання більш загальних напрямів роботи;

2) інженерія застосувань (application engineering), або прикладних систем − процес виробництва конкретних нових систем, застосувань із КПВ (модулів, програм, підпрограм та ін.), раніше створених як самостійні програмні продукти або як окремі елементи багаторазового використання в інженерії іншої предметної області;

3) інженерія ПрО або інженерія домену (domain engineering) містить у собі методи розробки, пошуку, класифікації, адаптації, збирання КПВ, а також одиночних програмних застосувань і створення з них або з готових частин прикладних систем сімейств систем. Системи сімейства зберігають напрацьований досвід з реалізації однієї прикладної проблеми предметної області для застосування його в даному або іншому, більшому сімействі. Необхідна умова цієї інженерії – системні інструментальні засоби підтримки методів накопичення КПВ і впровадження їх у системи нового сімейства.

4) інженерія виробництва ПС технологічними засобами та інструментами середовищ сучасних систем автоматизації.

У програмній інженерії під доменом розуміють предметну (проблемну) область, яка трактується як сімейство систем, призначених для розв’язання різних задач (проблем) цього домену відповідними користувачами. Це визначення з’явилися у мовно-орієнтованому і генерувальному програмуванні [3, 4, 5]. Воно є новим щодо класичного визначення ПрО, яке сформоване раніше під впливом розвитку об’єктного підходу і наведено у темі 4. Домен визначається набором понять, які однаково розуміються усіма системами сімейства та користувачами. Предметні області можна поділити на:

– спеціалізовані, що відбивають специфічні і виробничі інтереси груп фахівців у рамках деякої людської спільноти (наприклад, на підприємстві відображення інтересів бухгалтерів, плановиків, керівника кадрами тощо), певної галузі науки, фірми тощо;

– загальні, що відбивають процеси ЖЦ (визначення вимог, проектування, тестування, оцінювання показників якості тощо) або виробництво програмних систем за типом конвеєрпій технології;

– універсальні, що відображають загальні функції, необхідні для використання у спеціалізованих і загальних ПрО (наприклад, системи БД, захисту, ліцензування, редагування тощо).

У межах деякої ПрО розв’язуються задачі, які відображають спільні і варіантні аспекти її проблем, а також правила маніпулювання ними. Задачі представляються у моделі ПрО шляхом моделювання проблем області у просторі понять цієї предметної області або на перехресті декількох областей і входять до складу спільної мови між розробниками, користувачами і замовником системи.

Іншими исловами, кожний домен (область) має систему знань, знайому відповідним професіоналам, з притаманними йому характерними властивостями (атрибутами), відношеннями та правилами поведінки. Посередником між професіоналами і розробниками різних систем, що містяться у домені (наприклад, бухгалтерська, кадрова системи тощо) є специфікована модель ПрО, яка повинна забезпечувати точність та однозначність трактування встановлених понять цієї області як фахівцям ПрО, так і різними категоріями її користувачів. Ця модель застосовується при комунікації між людьми і системами, анотуванні окремих її елементів щодо КПВ, а також при її трансформації у вихідну систему.

Перший і другій напрями інженерії фактично характеризують створення унікальних, одиночних ПС з різного роду КПВ, а третій ставить завдання створення програмних систем і їхніх сукупностей з виділенням окремих частин ПС, що мають загальні властивості і характеристики, які можна багаторазово використовувати в інших системах сімейства. В основному вказані проблеми інженерії ПрО, висвітлені у параграфі 5.6 при описі генерувального програмування.

Четвертий напрям – це засоби і інструменти автоматизації виробництва програмних продуктів, які подаються для застосування сучасними закордонними фірмами (Microsoft, IBM, Rational Rose тощо).

Далі розглядаються названі напрями інженерії побудови програмних продуктів детальніше.

 

8.1. Інженерія компонентів повторного використання

Інженерія КПВ – це систематична і цілеспрямована діяльність з підбору реалізованих і представлених у вигляді КПВ програмних артефактів, аналізу їхніх функцій для додавання їх у проектовану систему як готових компонентів та інтеграції з іншими компонентами. Згідно з стандартом ISO/IEC-12207 ця діяльність класифікується як організаційна і планована інженерна діяльність, що полягає у виявленні загальних і специфічних рис компонентів для прийняття рішень про їх використання при розробці нових ПС [1–4, 7, 8].

При цьому передбачається, що є каталог сховища, за допомогою якого можна зрозуміти, які КПВ є готовими «деталями» і як їх можна по’єднати в більш складну програмну конструкцію. Саме ця сторона характеризує повторне використання як систематичну і цілеспрямовану діяльність із створення і використання каталогу КПВ зі сховища або репозитарію.

Систематичне повторне використання – це капіталомісткий підхід, який передбачає наявність двох процесів ЖЦ при розробці ПС.

Перший процес – це побудова КПВ шляхом:

– вивчення спектра розв’язуваних задач ПрО, виявлення серед них загальних властивостей і функцій;

– опис компонентів, реалізуючих виявлені функції у вигляді звичайних компонентів або КПВ;

– зберігання виготовлених компонентів у каталозі і організація пошуку необхідних компонентів з запитів користувачів.

Для успішної реалізації такого процесу необхідно мати певний досвід з розв’язку декількох подібних між собою задач, що дозволить визначити загальні риси і відмінності для знаходження розв’язку зїхньої реалізації, а також розробити прийоми настроювання на характерні для кожного завдання особливості.

Другий процес – конструювання нових систем з готових компонентів шляхом:

– визначення цілей майбутній системи і вимог, що висуваються до неї;

– пошуку в каталозі готових компонентів, які можуть відповідати вимогам до нової системи;

– зіставлення окремих цілій нової розробки з можливостями знайдених КПВ і прийняття рішень про доцільність і місце їхнього застосування в системі;

– інтеграція КПВ у нову розробку із забезпеченням інтерфейсу з підсистемами та іншими компонентами.

Перший процес вимагає вкладення капіталу, другий – дає прибуток за рахунок заощадження трудовитрат від застосування готових КПВ. Інвестиції в повторне використання вимагають оцінки ефективності вкладення капіталу, прогнозування термінів і обсягів повернення цього вкладення, оцінки ризиків та ін. Бізнес повторного використання, як будь-який бізнес, вимагає спеціальних умов щодо менеджменту всієї інженерної діяльності в межах інженерії систем із КПВ. Критерії успіху такого бізнесу визначаються такими передумовами:

1) повторне використання готових компонентів вимагає менших трудовитрат, ніж їхня нова розробка;

2) пошук придатних для використання компонентів вимагає менших зусиль, ніж реалізація необхідних функцій у проектованій системі;

3) розгортання компонентів в нових умовах середовища, потребує менших трудовитрат, ніж знов виконаної розробки.

Основна парадигма КПВ – «писати один раз, виконувати багато разів, де завгодно». Архітектура, в яку вбудовується готовий КПВ, підтримує стандартні механізми для роботи з компонентами як із будівельними блоками. Щоб забезпечити високу ефективність повторного використання, вони повинні мати такі властивості, як функціональність, зручність використання і якість реалізації.

Різновиди КПВ. За КПВ можуть використовуватися формалізовані артефакти діяльності розробників ПС, які відображають певну функціональність для застосування в нових розробках. Під артефактом розуміється реальна порція інформації, яка може створюватися, змінюватися і використовуватися при виконанні діяльності, пов’язаної з розробкою ПС різного призначення.

Артефактами можуть бути:

– моделі ПрО в термінах понять і лексики деякої предметної області;

– готові компоненти ПС, КВП або окремі частини системи;

– проміжні продукти процесу розробки ПС (вимоги, постановки завдань, архітектура та ін.);

– описи процесу проектування ПС (специфікація, модель, каркас і т.п.);

– діаграми, патерни і т.п.

До компонентів КПВ висуваються такі вимоги, як незалежність від конкретної платформи, наявність стандартного інтерфейсу і параметрів настроювання на нове середовище, можливість їхньої взаємодії з іншими компонентами системи без внесення в них змін.

Розробці ПС за допомогою КПВ відповідає модель ЖЦ з такими загальними процесами:

– аналіз об’єктів і зв’язків у ПрО, яка реалізується, для виявлення КПВ, що мають загальні властивості, притаманні групам об’єктів цієї області;

– адаптація наявних в базі репозитарію КПВ, розробка нових функціональних компонентів, не представлених у цій базі, і доведення їх до рівня повторного використання;

– розробка інтерфейсів компонентів і розміщення їх в репозитарії інтерфейсів системи;

– інтеграція КПВ з їхніми інтерфейсами та іншими елементами створюваної системи і формування конфігурації цієї системи.

КПВ можуть бути прикладними і загальносистемними. Прикладні компоненти виконують окремі задачі і функції прикладної області (домени бізнесу, комерції, економіки і т.п.), які можуть використовуватися надалі як прикладні системи в інших доменах з аналогічними функціями.

До загальносистемних компонентів належать компоненти загального і універсального призначення, а також загальносистемні сервісні засоби, які забезпечують системне обслуговування і надають різні види сервісу для багатьох створюваних програмних систем різного призначення. До компонентів загального призначення належать: транслятори, редактори текстів, системи генерації, інтеграції, завантажувачі та ін. Вони використовуються всіма прикладними системами в процесі проектування і виконання. Універсальні системні компоненти забезпечують функціонування будь-яких (у тому числі і прикладних) компонентів, обмін даними і передачу повідомлень між усіма видами систем і компонентів, розміщених в різних операційних середовищах. До них належать ОС, СКБД, мережне забезпечення, електронна пошта та ін.

Зв’язок між прикладними і загальносистемними засобами здійснюється через стандартні інтерфейси, що забезпечують взаємодію різних типів компонентів через механізми передачі даних і повідомлень.

На сучасному ринку програмних продуктів циркулюють такі види готових компонентів:

– процедури і функції на МП високого рівня;

– алгоритми, програми;

– класи об’єктів і абстрактні класи;

– структури даних і часто використовувана інформація (наприклад, інформаційні ресурси Інтернету);

– API, IDL-модулі в бібліотеках (наприклад, GUI, графіка і ін.);

– веб-ресурси і сервіси;

– засоби розгортки систем і компонентів в операційному середовищі (наприклад, CORBA, COM,.NET) [17-19];

– готові розв’язки у вигляді абстракцій – патерни, фрейми та ін.

Уся різноманітність видів і типів готових компонентів вимагає від розробників нових систем пошуку і вивчення їх для використання в цих системах. Процес розробки нових ПС за допомогою різних видів КПВ є капіталомісткий, у ньому як капітал виступають готові КПВ, на застосування яких витрачається менше зусиль та ресурсів, ніж на їхню повторну розробку.

 

8.1.1. Специфікація КПВ

Як КПВ можуть бути класи, створені в рамках об’єктно-орієнтованого програмування (наприклад, величезна бібліотека класів в С++) разом із реалізацією їхніх методів. У компонентному програмуванні успадковується реалізація компонента і його інтерфейси. Компонент може змінюватися і поповнюватися новими функціональними можливостями і інтерфейсами. Один компонент може вміщати реалізацію декількох різних інтерфейсів, а один інтерфейс, у свою чергу, може бути реалізований в різних компонентах. Заміна одного компонента іншим не призводить до перекомпіляції ПС або перенастроювання зв’язків у ній.

Приклад КПВ – контейнерні класи, які зберігають структури даних з правилами їхнього запам’ятовування або видачі чергового елемента, що входить в контейнер. Механізм контейнерів реалізовано в С++ у вигляді так званих шаблонів (templates) і їхніх бібліотек.

Кожний компонент має такі властивості:

– зв’язок через інтерфейси із зовнішними компонентами в процесі розробки системи;

– інкапсуляція компонента як «чорна скринька» без можливостівтручання у вихідний код;

– успадкування інтерфейсів, їхня зміна і настроювання на застосування;

– повторне використання вихідного коду.

Із загальної точки зору компонент визначається по-різному залежно від середовища і функцій. Наведемо деякі визначення [1, 2, 7].

Визначення 1. КПВ – це деяка функція з певними атрибутами, що забезпечують взаємодію з середовищем і поведінку.

Визначення 2. Готовий КПВ – це сукупність методів із визначеною сигнатурою і типами даних, які передаються і повертаються після виконання відповідного методу.

Визначення 3. Компонент типу КПВ – це самостійний програмний елемент, який задовольняє певні функціональні вимоги, вимоги архітектури, структури і організації взаємодії в заданому середовищі, має специфікацію, що допомагає користувачу використовувати і об’єднувати його з іншими компонентами в інтегровану систему.

Визначення 4. Програмний компонент – це незалежний від мови програмування, самостійно реалізований об’єкт, який забезпечує виконання певної сукупності прикладних сервісів, доступ до яких можливий тільки за допомогою інтерфейсів, що вказують функції і порядок операцій звернення до компонента.

Ці та інші визначення наведено в [1, 2, 6-11] і вони відображають різні аспекти визначення або використання компонента. Далі наведено проблематику інженерії компонентів з використанням різних складових елементів двох останніх визначень.

Модель специфікації компонента має такий вигляд:

КПВ = (T, I, F, R, S),

де T – тип компонента; I – множина інтерфейсів компонента; F – функціональність компонента; R – реалізація, прихована частина – програмний код; S – сервіс для взаємодії з середовищем або набір правил розгортки.

Кожний з елементів специфікації компонента являє собою видиму або приховану від користувача частину його абстракції.

Залежно від складності КПВ їх можна поділити на такі групи:

– прості компоненти (функція, модуль, клас та ін.);

– компонент як об’єкт, що має інтерфейс, функцію і реалізацію, а також можливість доповнювати свою специфікацію шаблоном розгортки й інтеграції;

– готові до використання КПВ (наприклад, beans компоненти в Java, AWT– компоненти тощо);

– складні КПВ типу каркасів, патернів з елементами групування декількох простих КПВ в структуру, де вони взаємодіють, забезпечуючи розв’язки певної задачі в межах системи.

Наявність великої кількості готових компонентів вимагає від розробників і користувачів визначення метаінформації про те, які класи сумісні з семантичними обмеженнями, явно визначеними в специфікації КПВ. Метаінформація містить у собі інформацію щодо:

– інтерфейсів, які реалізують компоненти;

– механізмів повторного використання;

– середовища розгортки компонента;

– сервісу, підтримуваного компонентом;

– ролей, які виконують компоненти в системі;

– формалізованих мов опису КПВ.

Сучасна технологія застосування КПВ базується на таких особливостях:

– відображення здатності КПВ аналізувати самих себе і надавати свої можливості динамічно під час виконання, а не під час компіляції, тобто керувати більшістю властивостей, подій і методів, вбудованих в компонент;

– стандартизований опис компонента для зручного аналізу і розуміння його сторонньою особою, а не самим розробником;

– здатність компонента до трансформації із збереженням функцій, але з можливою зміною структури і початкового коду;

– збереження параметрів конфігурації (шаблонів налагодження) у постійній пам’яті для повторного використання;

– реєстрація повідомлень про події, одержані від інших об’єктів через посилання (наприклад, EJB-компоненти в JAVA),

– групування компонентів у архіви (наприклад, JAR-файли) для подальшого повторного використання як сукупності;

– використання компоненту в різних мовних середовищах;

– адаптація КПВ до різних контекстів використання, виділення властивостей, які заважають повторному використанню та модифікація.

Компоненти, на відміну від об’єктів ООП, можуть змінюватися і поповнюватися новими функціями і інтерфейсами. Вони конструюються у вигляді деякої програмної абстракції, що складається з трьох частин: інформаційної, зовнішньої і внутрішньої.

Інформаційна частина містить у собі такі відомості: призначення, дата виготовлення, умови застосування (ОС, платформа і т.п.), можливості КПВ, тип середовища оточення та ін.

Зовнішня частина – це інтерфейс, який визначає взаємодію компонента із зовнішнім середовищем і з платформою, на якій він виконуватиметься, і має такі характеристики:

– інтероперабельність – здатність взаємодіяти з компонентами інших середовищ;

– переносність – здатність компонента виконуватися на різних комп’ютерних платформах;

– інтеграційність – об’єднання компонентів за допомогою інтерфейсів у більш складні структури ПС;

– нефункціональні вимоги, а саме, вимоги до безпеки, надійності і захисту компонентів і даних.

Внутрішня частина компонента – це програмний код, системна або абстрактна структура (табл. 8.1). Ця частина компонента складається з:

– інтерфейсу (interfaces);

– реалізації (implementation);

– схеми розгортки (deployment).

Інтерфейс компонента містить у собі звернення до інших компонентів через описані параметри засобами мов IDL або APL. У ньому вказуються типи даних і операції передачі параметрів для взаємодії компонентів один з одним. Кожен компонент може реалізовувати цілу сукупність інтерфейсів. Інтерфейс – видима незмінна і обов’язкова частина специфікації компонента. Наприклад, система Inspector Components змінює деякі параметри інтерфейсу компонента без втручання в його код.

Параметри інтерфейсу визначаються типом КПВ і відповідають специфікації, де зазначаються типи і імена компонентів, їхні вхідні і вихідні параметри, методи компонентів та ін. У мові JAVA, наприклад, типами компонентів можуть бути: проекти, форми (AWT-компоненти), beans-компоненти, компоненти Enterprise Java Beans, CORВA-компоненти, RMI-компоненти, стандартні класи-оболонки, JSP- компоненти, сервлети, XML-документи, DTD-документи і т.п.

 

Таблиця 8.1. Характеристики частин компонента

Частини структури компонента

Інтерфейс

Реалізація

Схеми розгортки

Один або декілька

Унікальність іменування

Клієнтський або серверний

Сигнатура операцій

Методи взаємодії

Одна або декілька

Орієнтація на платформу і середовище

Вибір конкретної реалізації

Підтримка інтерфейсів компонента

Типовість процедури розгортки

Конфігурація

Керованість

Настроювання на операційне середовище

Модифікація

 

Реалізація – це код, який використовується при зверненні до операцій, визначених в інтерфейсах компонента. Компонент може мати декілька реалізацій, наприклад, залежно від операційного середовища або від моделі даних і відповідної системи керування базами даних, яка необхідна для функціонування компонента.

Розгортка – це фізичний файл або архів, готовий до виконання, який передається користувачеві і містить у собі всі необхідні операції та інструкції для створення, настроювання і функціонування компонента.

Опис компонентів не залежить від операційного середовища і від реальної платформи, де він має функціонувати (наприклад, XML, DSL-опис).

Розширенням поняття компонента є каркас та патерн.

Каркас являє собою абстракцію високого рівня в ПС. Суть цього поняття полягає у відділенні функціональності компонентів від задач керування ними. Іншими словами, функціональність компонентів − це бізнес–логіка, каркас не відповідає за правильну і надійну взаємодію компонентів, а також за забезпечення безпеки, вимог й т.п. Фактично каркас поєднує множину взаємодіючих між собою компонентів, що розгортаються у деякому інтегрованому середовищі для виконання кінцевої мети ПрО.

Патерн є абстракція, що містить у собі опис взаємодії сукупності об’єктів або компонентів у спільній кооперативній діяльності, для якої визначені ролі учасників і розподілена їхня відповідальність. Патерн можна подати повторюваною частиною програмного елемента у вигляді схеми чи взаємозв’язків контекстного опису вирішення проблем ПрО. Він фіксує узагальнене розв’язання для спілкування з замовником, а також забезпечує повторне використання досвіду про відомі проблеми, які раніше передавалися моделлю ПрО. Крім того, КПВ можуть бути і моделі ПрО.

 

8.1.2. Репозітарій компонентів

КПВ та інші компоненти багаторазового застосування розміщуються в різних сховищах. Ними можуть бути бібліотеки, репозитарії компонентів і ресурсів в Інтернеті (наприклад, GreedStone, Matlab, бібліотека класів С++ і ін.).

Компонентами цих сховищ можуть користуватися багато разів усі бажаючі для реалізації своїх цілей, зокрема, при побудові програмних систем різного призначення. Репозітарії типу бібліотеки GreenStone і Matlab надають величезну кількість готових програм наукового, зокрема математичного, типу, тобто вони орієнтовані на математиків, фізиків і інших фахівців предметних областей.

У загальному випадку репозитарій – це система засобів для зберігання, поповнення напрацьованих КПВ, що містить у собі інфраструктуру розробки ПС з компонентів, організацію доступу до КПВ, які розташовані в ньому, для подальшого їхнього застосування в нових проектах.

З функціональної точки зору репозитарій працює за принципом інформаційно-пошукової системи, об’єктами зберігання якої є різні типи документів, текстів та ін. Система ставить запит користувача відповідо до ключових понять, слів, правил доступу, що містяться в колекції документів. Загальна структура репозитарія для деякої предметної області зображена на рис. 8.1.

 

Рис. 8.1. Структура репозитарію для ПрО

 

Розділи репозитарію, що орієнтовані на використання в інженерії КПВ та інженерії ПрО, пропонуються такі:

– компоненти КПВ;

– засоби безпеки, захисту та змінювання для КПВ;

– аспекти опису специфіки представників сімейства систем;

– засоби підтримки взаємодії, синхронізації компонентів;

– нові елементи сімейства ПрО;

– сервіси для членів сімейства тощо.

На відміну від систем пошуку інформації в репозитарії компонентів, окрім КПВ, розміщується семантична інформація у вигляді пошукового образу, створеного на основі опису інформаційної моделі кожного компонента. Ця модель – засіб побудови пошукового образу для каталогу КПВ, орієнтованого на осмислення людиною функцій КПВ і можливості їхнього зіставлення з власними потребами.

Пошуковий образ готових компонентів в репозитарії може містити у собі:

– список ключових слів, що найчастіше згадуються в тексті КПВ;

– посилання на заздалегідь побудовану онтологію домену проблемної області, до якої цей КПВ належить.

Інформаційну потребу щодо КПВ формулює користувач у вигляді пошукового запиту, який зіставляється зі описом пошукового образу КПВ, що зберігається у репозитарію. Пошук КПВ відповідно до заданого запиту виконується доти поки не буде знайдено потрібний КПВ або користувач не одержить велику кількість релевантних запиту компонентів для відбору потрібних. Їхньому розгляду допомагає онтологічна, понятійна база репозитарію, яка містить у собі інформаційну модель кожного КПВ з узгодженою і уніфікованою термінологію, з вказівками на відношення між поняттями і їх інтерпретаціями, а також ключовими словами тощо.

Інформаційна модель КПВ забезпечує систему зберігання, пошуку і зіставлення КПВ у репозитарію, якій поділено на розділи відповідно до окремих ПрО, перелік яких є класифікатором першого рівня. Класифікаторами наступних рівнів можуть бути окремі поняття ПрО. Цей образ може містити у собі паспортні дані компонента (ім’я і адресу розробника, спосіб придбання, ціну і т.п.), відомості про середовище реалізації (ОС, МП, СКБД і т.п.), опис апаратних ресурсів, імена ПрО в системі класифікації, а також опис нефункціональних вимог до системи (безпека, конфіденційність, показники якості системи та ін.).

Розділи репозитарію заповнюються відповідно до класифікації КПВ щодо різних предметних областей. Сутність будь–якої класифікації полягає у розбитті множини елементів на кілька класів еквівалентності згідно з класифікаційними характеристиками і ознаками. Класи еквівалентності не перетинаються і усі елементи конкретного класу мають відповідні ознаки.

Для однієї і тієї ж множини може існувати декілька систем класифікації, кожна з них залежить від вибраних базових ознак і способів групування їх у класифікаційні характеристики (наприклад, програмна інженерія як наука якісного виробництва). Основою такої системи є інформація, що супроводжує компоненти, та правила впорядкування відповідно певним ознакам – функціональність, системне середовище, ресурс тощо. Система класифікації компонентів не існує, тому її побудова для компонентів засновується на загальних знаннях про компоненти та їх застосування. Ці знання розподіляються серед таких груп загальних властивостей компонентів, як структурні ознаки, функціональні можливості, характеристики поведінки.

Класифікація компонентів уніфікує подання інформації про компоненти для подальшого пошуку і відбору їх з середовища репозитарію. Вона відбувається з урахуванням таких ознак:

– приналежність до ПрО;

– тип компонента (модуль, клас та ін.);

– наявність інтерфейсу в КПВ;

– готовність КПВ до застосування;

– складність КПВ (каркас, патерн, контейнер тощо).

Фізичне розміщення кодів КПВ в репозитарії виконується в каталозі, де розміщуються імена і посилання на місце розміщення самого коду. Вибрані компоненти з репозитарію настроюваються на умови середовища функціонування майбутньої системи.

Інформаційна модель пошукового образу спрощує пошук необхідних КПВ і скорочує терміни розробки ПС за рахунок:

– відображення базових функцій і понять компонента;

– приховування представлення даних, операцій оновлення і отримання доступу до цих даних;

– обробки виняткових ситуацій, що відбувається в процесі виконання та ін.

Розробка нових ПС може здійснюватися за технологією з використанням розроблених звичайних компонентів (КОМ1, …, КОМk) та КПВ (рис. 8.2).

 

Рис. 8.2. Інтеграція компонентів на різних МП у середовищі

Наведені шляхи розробка, накопичення, вибору та інтеграції КПВ визначають типову технологію розробки ПС з компонентів та КПВ, коли вони подані у різних МП.

Якщо компоненти написано на різних МП, то в процесі створення деякої унікальної системи для сімейства ПрО формуються спеціальні інтерфейсні модулі (Int1,..., Intk), які виконують функції перетворення нерелевантних (невідповідних значенням) типів даних для значень, що передаються між компонентами системи, які взаємодіють [2].

Шляхи технології інтеграції компонентів такі:

1. Розробка компонентів (КОМ) на мові.

2. Відбір готових компонентів – КПВ.

3. Розробка інтерфейсів – Іnt для КОМ.

4. Генерація інтерфейсів пари КОМ на МП.

5. Розробка середовища та репозитарію КОМ.

6. Типізація компонентів.

7. Тестування КОМ, інтерфейсів, КОМ-систем.

8. Інтеграція компонентів.

9. Розгортання КОМ-системи у середовищі.

10. Супровід компонентної системи.

Дані шляхі охоплють процеси розробки систем із різних компонентів, їх накопичення, тестування та інтеграція у компонентну структуру зі створенням в ній додаткових інтерфейсних модулів int для кожної пари різномовних компонентів.

 

8.1.3. Мова опису інтерфейсу компонентів

Для об’єднання компонентів у ПС необхідною умовою є наявність для них формально визначених інтерфейсів у сучасних мовах IDL або APL, а також механізмів динамічного контролю зв’язків між компонентами.

Специфікація інтерфейсу в API і IDL містить у собі опис функціональних властивостей компонентів, їхніх типів і порядку завдання операцій передачі аргументів і результатів для взаємодії компонентів. Описом інтерфейсу може бути інтерфейсний модуль між двома компонентами.

Інтерфейси ПС, що побудована з компонентів і призначена для функціонування в розподіленому середовищі, мають деякі особливості. Така система складається з двох частин, кожна з яких може виконуватися в різних процесах і взаємодіяти одна з одною через виклик інтерфейсних функцій. Перша частина – серверна програма, а друга – клієнтська (далі просто сервер і клієнт).

У функції інтерфейсного модуля клієнта входять:

– підготовка зовнішніх даних (параметрів) для клієнта;

– набір викликів цих процедур або звернень до сервісу сервера;

– обробка різних помилок, повернення даних від сервера до клієнта.

Загальні функції інтерфейсного модуля сервера містять у собі:

– очікування повідомлень клієнта і їхню обробку;

– запуск віддаленої процедури і передачу їй параметрів клієнта;

– повернення результатів процедури клієнту, знищення віддаленої процедури та ін.

Структура інтерфейсного модуля не залежить від МП взаємодіючих об’єктів і в цілому однакова для всіх. Це пов’язано із стандартизованою його структурою і спільною мовою специфікації інтерфейсу, синтаксис якого подано нижче у формі Бекуса-Наура:

 

<інтерфейс об’єкта> ::= оbject <ім’я_Обєкта>: {<множина початкових інтерфейсів>}; {<множина вхідних інтерфейсів>} end;

<множина вхідних інтерфейсів> ::= <множина інтерфейсів>;

<множина вихідних інтерфейсів> ::= <множина інтерфейсів>;

< множина інтерфейсів> ::= Ø | <інтерфейс>; < множина інтерфейсів>;

<інтерфейс>::= interface <ім’я _інтерфейсу>: {<множина функцій>} end;

<множина функцій> ::= Ø | <функція>; <множина функцій>;

<функція> ::= function < ім’я_функції>: <множина параметрів> еnd;

<множина параметрів> ::= <параметр> | <параметр>, <множина параметрів>; <параметр> ::= <тип> (<вид параметра>);

<вид параметра> ::= in | out | inout (вхідний, вихідний, разом вхідний і вихідний).

 

Тип даних описується засобами мов програмування (C++, Pascal і т.п.) і забезпечує взаємодію між процесами, а параметри <вид параметра> можуть бути: in – вхідний параметр, out – вихідний параметр, inout – параметр, через який передаються та повертаються дані.

Приклад фрагменту мови опису інтерфейсу наближений до опису в мові IDL для середовища CORBA.

 

Interface Vlst (

status add_item (

in identifier item_name

in type code item_type

in long value_len

);

statгs free_memory ();

statгs get _count (

out long count

);

);

 

8.2. Прикладна інженерія та інженерія предметної області

Інженерія програмування заснована на інженерії КПВ, що розглянуто вище, містить у собі ще прикладну інженерію і інженерію ПрО. Вони використовують готові КПВ, унікальні програми після інженерії КПВ, а також окремі частини сімейства систем з компонентів багаторазового застосування та прикладні системи із сімейства. [2–5, 13]. Як уже зазначалося, прикладна інженерія, або інженерія застосувань – це інженерія побудови прикладної системи (Application) на основі її моделі, вибраних готових КПВ та заново розроблених компонентів, що реалізують окремі задачі цієї системи, а інженерія ПрО орієнтована на створення архітектури ПрО – каркаса (framework), що містить у соб КПВ, компоненти багаторазового застосування з сімейства програм різних доменів і інтерфейси компонентів, а також готові застосування, розроблені методами прикладної інженерії, як готові члени сімейства.

Кожний член сімейства повинен мати відображення своєї специфіки на мові високого рівня – DSL (Domain Specific Language), яка зараз широко використовується розробниками ПрО. На загальному рівні ця мова складається з трьох частин:

метамодель, що відображає абстрактно синтаксис при визначенні специфіки ПрО і правила опису специфіки ПрО, необхідної для розробки моделі генерації GMD (Generative Model Development);

– конкретного синтаксису МП для опису нотацій моделі GMD та інших моделей ПрО;

– семантичного опису змісту всіх моделей.

Моделі ПрО, описані за допомогою однієї DSL, можуть бути трансформовані в моделі, що описані за допомогою іншої DSL. Це дозволяє інтегрувати між собою різні частини системи, написані на різних DSL. ПрО може бути описана на одному рівні абстракції, а потім перетвориться на більш низькі рівні абстракції, що дозволяє доповнювати модель GMD на різних процесах розробки системи. Мова DSL дає можливість автоматизувати реструктуризацію, інтеграцію і розгортання системи на основі опису специфіки моделі домену, набудованої на деяку МП. Ця модель може містити у собі інформацію про збирання артефактів, використаних у ній, а також установлювати залежності між артефактами, включаючи конфігурацію програм, що виконуються, обсяги апаратних і програмних ресурсів, необхідних цим програмам.

 

8.2.1. Прикладна інженерія

Інженерія застосувань (applications), або прикладна інженерія, входить до інженерії ПрО, як складова її частина. Сутність цієї інженерії полягає у виробництві окремих членів сімейства або нових КПВ, багаторазово використовуваних проектних рішень при генерації окремих членів сімейства систем.

Ця інженерія компонентних застосувань містить у собі процеси створення прикладної системи і їхній менеджмент. Процес створення починається з аналізу предметної області, задачі якої автоматизуються, побудови концептуальної моделі, на основі якої створюється компонентна модель, що вміщує проектні рішення з пошуку і збирання компонентів, використання різних типів шаблонів, зв’язків між ними й операцій розгортки ПС у середовищі функціонування.

Будь-яка інженерія, як колективна діяльність, потребує менеджмент. Менеджмент – це керування створенням прикладної системи, яке складається з розподілу робіт між кожним учасником, створення графіка цих робіт для контролю їхнього виконання відповідно до заданих термінів і оцінювання якості як окремого компонента, так і сукупності компонентів, що взаємодіють.

Перелічимо етапи інженерного процесу створення ПС з компонентів, враховуючи, що компоненти розміщуються в репозитарії.

1. Пошук, вибір КПВ і розробка нових компонентів, виходячи із системи класифікації компонентів і їхньої каталогізації, формалізоване визначення специфікацій інтерфейсів, поведінки і функціональності компонентів, а також їхнього анотування і розміщення в репозитарії системи або в Інтернеті.

2. Розробка вимог (Requirements) до ПС, тобто – це формування й опис функціональних, нефункціональних і інших властивостей ПС.

3. Аналіз поведінки (Behavioral Analysis) ПС – визначення функцій системи, деталей проектування і методів реалізації функції, кожний з яких має відповідну поведінку.

4. Специфікація інтерфейсів і взаємодій компонентів (Interface and Interaction Specification) відбиває розподіл ролей компонентів, інтерфейсів, їхню ідентифікацію і взаємодію через робочі потоки (workflow).

5. Збирання застосувань і повторне використання компонентів (Application Assembly and Component Reuse) ґрунтується на підборі й адаптації КПВ, визначенні сукупності правил, умов інтеграції і побудові конфігурації каркаса системи.

6. Тестування компонентів і середовища (Component Testing) ґрунтується на методах верифікації і тестування для перевірки правильності як окремих компонентів і КПВ, так і інтегрованої з компонентів ПС.

7. Розгортка (System Deployment) містить у собі оптимізацію плану компонентної конфігурації з урахуванням середовища, розгортання окремих компонентів і створення цільової компонентної конфігурації для функціонування ПС.

8. Супровід ПС (System Support and Maintenance) складається з аналізу помилок і відмов при функціонуванні ПС, пошуку і виправленні помилок, повторного його тестування й адаптації нових компонентів до вимог і умов інтегрованого середовища.

Цей процес є ітераційним. У ньому можна повертатися на попередні етапи у випадку невиконання деякого правила або вимоги.

На кожному з названих процесів проводиться менеджмент, тобто перевіряється правильність його виконання і відповідність вимогам, що сформульовані для системи. Виявлення помилок на останньому процесі може призвести до повторення деяких перелічених пунктів, коли або з’являються нові обставини у замовника, або усуваються деякі помилки.

 

8.2.2. Інженерія сімейства систем домена

Інженерія домену або ПрО призначена для побудови сімейства систем з урахуванням задач домену, загальних і змінюваних характеристик представників сімейства в моделі характеристик. Вибрані КПВ або одиночні програмні застосування знаходять в репозитарії і вбудовують у нові члени сімейства ПС.

Інженерія ПрО базується на різних видах мови опису специфіки предметної області в мові DSL [4, 6, 13]. Мова DSL має виразну особливість, спрямовану на відображення специфіки предметної області. Тоді як мови загального призначення (Java, C++ і ін.) створювалися для задоволення будь-якого типу програм.

Мова DSL не є новим винаходом, оскільки в неї були вбудовані загальні абстракції програмування. І хоча мова DSL створюється багато років для кожних нових ПрО, систематичне її застосування для специфікації особливостей ПрО ще не є загальноприйнятою практикою.

Будь-яка мова має свою визначену область застосування, мова DSL є більш спеціалізованою, ніж інші мови програмування (Паскаль або Кобол), які створювалися з визначеною метою. Порівнянно з ними DSL близька до спеціалізованих мов, таких, як HTML, XML.

Характеристика мови DSL для опису специфіки ПрО. Прівнянно з мовами загального призначення ця мова має [6]:

– абстракції, які забезпечують визначення концепцій і абстрактних понять із предметної області;

– синтаксис, призначений для природного представлення понять домену і запобігання синтаксичній неузгодженості понять ПрО;

– опис в DSL вимагає наявності спеціалізованих статичних аналізаторів для перевірки синтаксису, щоб знайти помилки в описі специфікації моделі, і подати з них відомості уією мовою;

– оптимізація коду за описом в DSL базується на знаннях про цю область і це не доступно компіляторам МП загального призначення;

– інструменти підтримки DSL вимагають оточення, наприклад, середовища, редактора, засобу контролю версій і т.п.;

– предметні абстракції в мовах програмування базуються на використанні бібліотек програм і КПВ, визначених користувачем функцій, класів і структур даних.

Специфікована в DSL модель ПрО є загальною моделлю генерації домену GDM, що відбиває:

– поняття, характеристики ПрО і членів сімейства в просторі проблем;

– набір членів сімейства і їхніх специфікацій у мовах типу DSL, RSL, CSP і ін.;

 задачі ПрО в просторі задач для їхньої реалізації компонентами і з наступним збиранням їх у конфігурацію визначених членів сімейства;

– знання про конфігурацію (Configuration knowledge) відбивають характеристики членів сімейства і їхнє об’єднання в конфігурації;

 модель характеристик (feature models) відображає загальні, змінювані і незмінні характеристики членів сімейства, а також правила конструювання систем сімейства з урахуванням їхніх взаємозв’язків і залежності від КПВ;

– архітектуру (каркас) сімейства систем;

– реалізацію компонентів архітектури у мовах програмування.

При проектуванні каркаса або моделі ПрО у вигляді моделі GDM можуть задаватися механізми змінювання, синхронізації, безпеки з використанням аспектного програмування.

Головною частиною моделі ПрО є моделі характеристик, що призначені для подання вимог до сімейств ПС, різних характеристик систем, що входять до складу ПрО та застосування КПВ. Ці моделі поділені на дві категорії [6]:

– моделі характеристик FODA (Feature-oriented Development Architecture), FORM (Feature-oriented Reuse Method), RSEB (Reuse-Driven Software Engineering Business), FeatureRSEB (з інтеграцією у RSEB–діаграм характеристик з FODAcom) тощо [13];

– моделі варіантів сценаріїв використання (Use Case Variants) [14].

У першу категорію потрапляють традиційні методології моделювання, використовувані при побудові ПС, у другу – методології, засновані на аналізі сценаріїв діяльності потенційних користувачів ПС у ПрО, що будуються за допомогою UML (Sequence diagrams та Activity diagrams).

Про трансформацію DSL опису моделей ПрО. Як було сказано раніше, модель предметної області Мпро є загальною моделлю GDM домену, який складається з декількох моделей окремих прикладних систем Мпро1, Мпро2,..., МпроN.

Кожна з цих моделей відображає поняття і специфіку відповідної системи із сімейства систем домену. На їхньому перетині існують загальні поняття, характеристики і обмеження, які відображаються у моделі характеристик ПрО. Опис кожної моделі Мпроi виконується відповідною проблемно-орієнтованою DSLi мовою. Цей опис трансформується безпосередньо у відповідну МПi, тобто мову реалізації (рис. 8.3), або у іншу DSLj мову, яка потім трансформується у МП.

 

Рис. 8.3. Схема трансформація моделей прикладних систем

 

Після трансформації опис моделей Мпро1, Мпро2,..., МпроN, що отриманий у МП, транслюється до вихідного коду того середовища, де цей код буде функціонувати. Крім того, вибрані КПВ і знову розроблені компоненти для окремих функцій простору проблем також описуються відповідними МП, і отже, можуть розглядатися як елементи реалізації завдань у просторі задач. Перебудова до вихідного коду залежить також від платформи, коцепція якої буде розглянута нижче.

Даний підхід подання моделей ПрО відповідає відомій модельно-керованій розробці MDD (Model Driven Development). Відповідно до цієї моделі архітектури системи моделюються на двох рівнях – платформа незалежного рівня за моделлю PIM (Platform Independent Model) і платформа залежного рівня за моделлю PSM (Platform Specific Models). Концепції дворівневого моделювання архітектури MDA (Model Driven Architecture) і відображення PIM → PSM безпосередньо відповідають наведеній ідеології побудови сімейства ПрО, які базуються на відображенні опису Мпроi моделей прикладних систем (Application model) у DSL-мовах у МП (рис. 8.4).

Відповідно до підходу MDD моделі прикладних систем у моделі сімейства ПС відображають члени сімейства. Вони мають спільні функції, але розрізняються платформами реалізації.

 

Рис. 8.4. Схема трансформації прикладної моделі до платформи

 

Вибору альтернативної платформи відповідає точка варіантності у сімействі систем. Ця точка невидима на рівні конкретної ПС і при керуванні варіантами платформ з ней почінається автоматично виконання шляхом трансформації PIM → PSM, розробник не бере участі в цьому.

Зазначимо, що члени сімейства розрізняються не лише на рівні платформи реалізації, а й на рівні функцій ПС, вимог до якості, які реалізують альтернативні концепції. У такому випадку до моделі ПрО додається точка, де можуть бути подані необхідні альтернативні концепції.

Моделювання архітектури сімейства за характеристиками. Моделювання архітектури сімейства виконується за підходом, орієнтованим на характеристики (feature-oriented approach) її членів. Архітектура сімейства систем містить у собі окремі члени і «успадковує» еталонну архітектуру у просторі рішень (реалізації) генерувального програмування. Ця архітектура формується у просторі проблем таким чином, щоб різні комбінації характеристик цієї архітектури могли бути застосовані як компоненти реалізації простору рішень та і у кінцевому програмному продукту сімейства. Архітектура сімейства може бути подана у вигляді генерувальної предметно-орієнтованої мови зразка, яка визначає архітектурний стиль ПС сімейства за інваріантами систем, механізмами мінливості та еволюційного її розвитку через подання комбінацій відповідних шаблонів проектування цієї архітектури.

При цьому доменна модель ПС сімейства розширюється шляхом залучення до неї інваріантних понять та характеристик членів системи відповідно до певних їх критеріїв та предметно-орієнтованого опису цієї моделі засобами відповідного DSL для опису проблем або задач, що створюють область перспектив. При аналізі завдань домену досліджуються інформаційні джерела простору проблем, будується модель характеристик (feature model), що відображає загальні і змінні характеристики членів систем в сімействі, їх властивості і сполучення, а також опис проблем кожного члена мовою DSL (рис. 8.5). Ця модель використовується для подання архітектури системи і визначення компонентів для деяких задач домену.

 

Рис. 8.5. Схема побудови моделі характеристик ПрО

 

Характеристика – це властивість членів сімейства, яка доступна користувачу системи и можуть бути обов’язковою, необов’язковою або альтернативною. До них відносять інтерфейсні, проектні, продуктивні та реалізаційні характеристики. Вони відображаються у моделі характеристик відповідними діаграмами орієнтованого графа домену. Ця модель відбуває область дії сімейства систем і здатність до змінювання архітектури і її компонентів. В ній містяться знання щодо конфігурації системи, яка застосовується при автоматизованому виробництві членів сімейства.

Доменна модель може розглядатись як метамодель предметно-орієнтованих описів моделей сімейства DSL з механізмами підвищення рівня абстракцій подання сімейства ПС для запровадження цих механізмів до реалізації окремих членів сімейства. При цьому інструментальні засоби повинні забезпечувати відображення характеристик членів сімейства з простору проблемних задач у простір рішень з трасуванням таких відображень.

Розробка архітектури домену виконується у просторі проблем і є їхньою проекцією на модель характеристик. Цей простір конкретизується на прикладних і аспектних характеристиках, які виконуються у компонентах простору рішень. У моделі характеристик прикладними можуть бути архітектурні шаблони, які слугують реалізації архітектури сімейства систем.

Методологія розробки домену. На основі мови DSL створено методологію розробки домену MDD, що базується на генеративної моделі домену GDM (Generative Domain Model), яка специфікується [7]. Методологія містить у собі:

– модельно-керовану архітектуру MDA, що використовує мову моделювання UML для подання архітектури системи і її конкретні профілі для різних платформ;

– модельно-інтегровану обробку MIC (Model-Integrated Computing) для реалізації елементів системи і їхніх зв’язків за допомогою засобів предметно- орієнтованої мови моделювання DSML (Domain-Specific Modeling Language) і перетворення цього опису у платформозалежні артефакти.

Архітектура MIC поєднує:

– предметно-орієнтовані мови моделювання DSML, за допомогою яких формалізується структура, поведінка і вимоги до застосувань усередині ПрО, а також визначаються зв’язки між її поняттями, семантика й обмеження щодо використовування поняття;

– трансформаційні процесори і генератори, що аналізують задані аспекти моделей і синтезують вихідний код у XML-опис, включаючи схеми розгортки, позгодження між реалізаціями і зафіксованими у моделі вимогами до функцій системи з відповідною якістю.

При проектуванні каркаса або моделі ПрО у вигляді моделі GDM можуть задаватися механізми змінювання, синхронізації, безпеки з використанням аспектного програмування.

Технологія розробки сімейства програм вміщує три види базових процесів:

– розробка ПрО з унікальних, одиночних програм і інших компонентів;

– інженерія повторного використання програмних ресурсів;

– менеджмент домену.

Розробка ПрО належить до конвеєрної з повторним використанням компонентів. Для ПрО планується створення базових ресурсів, що можуть повторно використовуватися: компоненти, генератори, DSL-описи, моделі аналізу, КПВ, документація й ін. Розробка предметної області – це більш складний виробничий процес, що містить у собі такі загальні етапи: аналіз, проектування і впровадження в ПрО одиночних програм або КПВ.

Аналіз області містить у собі аналіз усього сімейства, яке треба побудувати, визначаючи в ньому загальні і різні риси, створюючи структурні і поведінкові специфікації сімейства. Аналіз ПрО починається з вибору вимог і їхньої специфікації для системи як членів сімейства. Специфікація вимог – це вхідні дані для ручного або автоматичного створення домену з готових ресурсів.

Інженерія повторного використання – це пошук і аналіз КПВ для їхнього повторного використання під час розв’язання задач ПрО. Вони відображаються в загальній архітектурі сімейства і в архітектурі всіх членів (тобто прикладних систем) сімейства цієї ПрО. Такими членами можуть бути одиночні прикладні системи, що вироблені методами прикладної інженерії, або готові КПВ.

Впровадження або реалізація ресурсів – це повторне використання в ПрО готових компонентів, одиночних програм, генераторів, DSL-описів й ін. Об’єднання цих ресурсів у зв’язану сукупність виконується за допомогою генераторів або конфігураторів готових ресурсів. Згенерировані продукти сімейства можуть мати не програмні артефакти, наприклад, інструкції з користування DSL та задач домену й ін.

Менеджмент домену – це керування технологією конвеєрної розробки з повторним використанням різних програмних ресурсів. Вона містить у собі планування і контроль підбору типових для ПрО ресурсів, їхню оцінку і перевірку відповідності вимогам. У задачу менеджменту входить також перевірка можливості застосування тих чи інших готових ресурсів для реалізації специфіки ПрО і програмування компонентів простору задач відповідно до потреб клієнтів домену.

Таким чином, інженерія ПрО складається з таких процесів:

– аналіз ПрО, виявлення об’єктів і зв’язків між ними;

– визначення області дій об’єктів ПрО;

– визначення загальних функціональних і змінюваних характеристик для побудова моделі характеристик з встановленими залежностями між різними членами сімейства;

– створення базису для інженерії виробництва конкретних прикладних членів сімейства з механізмами змінювання незалежно від засобів їхньої реалізації;

– підбір і підготовка компонентів багаторазового застосування для різних задач ПрО;

– генерація окремих членів сімейства або домену в цілому.

Процеси в цій схемі забезпечують формування моделі ПрО і моделі характеристики, як елементів простору проблем. Вони трансформуються в архітектуру системи й опис її компонентів. При цьому проводиться підбір готових компонентів і їхня генерація для одержання програм, що розв’язують задачі ПрО у просторі задач. Таким чином, дана схема приводить до генерації доменної моделі GMD для сімейства ПС і породженню готових підсистем або окремих членів сімейства [4].

Для забезпечення гнучкості і змінюваності деяких членів сімейства технологічна схема інженерії ПрО може мати додаткові етапи:

– коректування процесів виробництва в зв’язку з включенням у систему нових проектних рішень або при зміні складу КПВ;

– моделювання змінності і залежностей між компонентами шляхом зміни елементів доменної моделі GMD, інших моделей (об’єктної, взаємодії й ін.), додавання нових вимог і понять, а також фіксації їх у моделі характеристик і в конфігурації системи;

– розробка інфраструктури КПВ опис, збереження, пошук, оцінювання й об’єднання готових КПВ, що розміщаються в репозитарію системи;

– фіксація залежностей між характеристиками моделі, яка позбавляє розробників від деяких конфігураційних операцій, що виконуються, як правило, вручну;

– створення репозитарію КПВ і компонентів багаторазового використання в класі завдань ПрО;

– забезпечення безпеки, захисту даних, змін тощо;

– забезпечення синхронізації і взаємодії КПВ.

Таким чином, при генерації моделі ПрО для сімейства ПС використовується модель характеристик і набір компонентів для реалізації завдань ПрО. Використовуючи дану модель, знання про конфігурацію і специфікацію домену в мові DSL і компонентів в МП, що беруть участь у цьому процесі, можна автоматизовано згенерувати окремий член сімейства, а також ПС для систем сімейства ПрО.

 

8.2.3. Стандартизація процесів інженерії домену

У стандарті ISO/IEC 12207: 2002 подано опис процесу доменної інженерії домену (Domain engineering process) як нового процесу в моделі процесів ЖЦ. Згідно з цим стандартом процес інженерії домену охоплює ряд видів діяльності: аналіз і проектування домену, а також технологію інженерії домену.

Аналіз домену полягає у:

– визначенні меж домену і зв’язків з іншими доменами;

– виявленні, формальному описі спільних і різних особливостей усередині домену (постійних і змінних вимог) і включенні у модель домену;

– формуванні словників для опису основних понять у домені і взаємозв’язків між активами в домені;

– класифікації і документуванні моделей;

– оцінці моделей і словників домену з урахуванням вибраної методології моделювання.

Проектування домену (Domain design) – це визначення архітектури домену за допомогою програмних компонентів, специфічних ресурсів, або активів (Assets).

Крім цього стандарту, відмітимо проект стандарту комітету OMG (http:\\www.omg.org) з повторних компонентів RAS (Reusing Assets Specifications). У ньому пропонується формат опису інформації щодо повторно використовуваних ресурсів при розробці ПС, що є узагальненням поняття активу (asset) як програмного розв’язання деякої задачі в заданому контексті, яка належать до проблеми розробки ПС, а контекст визначає процес розробки або виконання програмного продукту. Актив − це компонент або КПВ, тобто робочий продукт або засіб розробника, який може бути використаний в інших програмних розробках. Поняття активу можливо розуміти більш широко, воно відповідає поняттю готовий ресурс у програмній інженерії.

Архітектура домену – каркас з КПВ, активів і формально визначених інтерфейсів і вона повинна узгоджуватися з моделлю домену, стандартами організації і оцінюватися на відповідність вибраній методології архітектурного проектування.

Технологія інженерії домену, що базується на новому процесі в моделі ЖЦ (ISO/IEC 12207) і понятті ресурсу (asset), містить у собі наступні стандартизовані підпроцеси:

– формування ресурсів (asset provision), тобто розробка або придбання ресурсів, які можуть використовуватися при компонуванні нових програмних систем або підсистем;

– розробка бази ресурсів (asset-based development), основою якої є концепція повторного використання (software reuse) – КПВ, що забезпечує компоновку програмних продуктів домена;

– супровід ресурсів (Asset maintenance) – модифікація і еволюція моделі, архітектури і продуктів домену за рахунок готових ресурсів типу КПВ.

Ця технологія припускає розробку методик і інструментів для ефективного виконання процесів ЖЦ а також для генерації системи із КПВ і компонентів багаторазового застосування відповідно до специфікацій вимог до системи та опису специфіки ПрО засобами спеціалізованих мов DSL.

Застосування технології інженерії домену в організації, що створює ПС, не дає можливості підтримки і розвитку архітектурного базису з множини ресурсів типу КПВ, що зберігаються в репозитарії, враховують загальні і специфічні особливості різних сторін діяльності в технології інженерії ПрО.

Основна мета інженерії ПрО – забезпечення багаторазового застосування використовуваних рішень для сімейства ПС, а в інженерії застосувань – серійне виробництво одиночних систем з використанням лінії виробництва конкретної ПС або деякого ринкового продукту, що базується на КПВ і вимогах до неї.

 

8.3. Інженерія індустріального виробництва програмних продуктів

На даний час багатьма фірмами, що займаються випуском програмної продукції, створені технологічні і інструментальні умови для автоматизованого виробництва програмних продуктів. До умов відносять засоби і інструменти, процеси та технологічні лінії виготовлення продуктів. Фірми-виготовники проводять моніторинг для визначення запиту на деякий вид програмного продукту.

Вони підготовляють команду розробників, будують технологічний базовий процес і здійснюють настройку інформаційного, технологічного і технічного станів середовища, що використовується для вироблення в ньому продукту. Об’єктами виробництва можуть бути прості і складні за своєю природою продукти ПП. В основному вони складаються з різного роду КПВ. До об’єктів виробництва формулюються загальні вимоги, в яких відображаються властивості всіх КПВ, а також властивості, специфічні для окремих представників компонентів системи.

Більш точно, розглядаються обов’язкові, необов’язкові і альтернативні властивості КПВ. До обов’язкових властивостей належать такі, які обов’язково присутні в кожному з представників сімейства систем, хоча їхня реалізація може дещо розрізнятися. До альтернативних властивостей відносять властивості, які відображають особливості вибору представника сімейства, який використовується багато разів. Необов’язкові властивості відображають певні специфічні особливості або можуть бути відсутні.

Створення програмних продуктів у середовищі на визначеній платформі залежить від її архітектурних особливостей, що можуть впливати на генерацію компонентів та програм.

Відомими середовищами для виготовлення програмних продуктів є лінії виробництва (Product Line Practice), система Microsoft Visual Studio Teams Systems, Microsoft MSF, Eclips тощо. Розглянемо їх детальніше.

 

8.3.1. Структура лінії виробництва програмних продуктів

Технологічні прийоми виробництва програмних продуктів з готових компонентів і програмних систем втілені у, так звані лінії продуктів, що відповідають конвеєрному виробництву програмних продуктів на ринковій основі. Виробництво систем виконується з множини компонентів КПВ, програм і ПС, які задовольняють специфічні потреби деякого ринку програмної продукції і показники якості.

Концепцію лінії виробництва продуктів або лінії сімейства продуктів запропонував Американський інститут програмної інженерії SEI. Головна мета такої лінії – це виробництво нових систем з готових КПВ і ПС, які задовольняють певний сегмент ринку програмної продукції. Вона є підтримкою інженерії ПрО, у завдання якої входить застосування підходів і методів для автоматизованої технологічної побудови різних видів окремих програмних продуктів.

При цьому в межах домену досліджуються ринок і потреби покупців, будується виробничий план, процеси і визначається організація їхньої взаємодії. Відповідно до потреб ринку будується технологічна лінія продукту, в яку включаються процеси, необхідні методи розробки, тестування і оцінки продуктів та процесів цієї лінії. Основу лінії становить інфраструктура, в яку входять групи розробників, різні методи і засоби інженерії ПрО, необхідні для побудови і експлуатації лінії виробництва продуктів (рис. 8.6) [10-12], а також відповідні керівні матеріали і методики.

Побудова конкретної лінії виробництва програмного продукту для певного представника сімейства визначається:

– обмеженнями, властивими майбутнім продуктам лінії;

– зразками і каркасами, які можуть використовуватися на лінії виробництва;

– виробничими обмеженнями, стратегіями і методами;

– набором засобів і інструментів автоматизації процесів виробництва продуктів на лінії.

 

Рис. 8.6. Інфраструктура лінії програмного продукту

 

На основі цих даних визначаються область дії лінії виробництва і набір базових засобів автоматизації, будується план створення продукту на ній, що враховує терміни, вартість і вимоги до керування виробництвом продукту шляхом:

– контролю плану робіт і відстеження ходу вироблення продукту;

– виявлення ризиків і керування ними в процесі проектування сімейства;

– прогнозування вартісних і технічних ресурсів проекту;

– застосування технології керування конфігурацією;

– вимірювання і оцінки якості продукту.

На лінії може видаватися декількох програмних систем за умови, коли вони:

– поділяють спільний і керований набір якостей;

– задовольняють специфічні потреби певного сегмента ринку;

– розроблені з використанням спільного набору готових ресурсів.

Ця множина програм є фактично сімейством, якщо для її членів визначені їхні спільні властивості, а також індивідуальні властивості окремих членів сімейства програмних продуктів.

Напрям інженерії ПрО, а саме, лінія виробництва програмного продукту, розвивається за рахунок використання готових компонентів, що накопичуються в репозитаріях доменів з метою вибору готових функцій, компонентів КПВ для використання на виробничому процесі цієї лінії.

 

8.3.2. Технологічне виготовлення систем у середовищі Microsoft

У зв’язку з відсутністю в Україні власно створених програмних середовищ для підтримки технологічних процесів розробки ПП, в даному підрозділі дано опис засобів та інструментів фірми Microsoft (рис. 8.7), призначених для керування проектом підприємства EPM (Enterprise Project Management).

 

Рис. 8.7. Архітектура середовища EPM Microsoft

 

До їхнього складу входять такі:

– пакет інструментів VSTS-2005 (Visual Studio Teams Systems), орієнтований на розробку великих проектів за участю різних спеціалістів (аналітиків, менеджерів, тестувальників, програмістів, кодувальників и ін.), що можуть бути розташовані в різних географічних точках;

– методологія MSF (Microsoft Solution Arhitecture), що призначена для побудови виробничій архітектури підприємства за допомогою ЖЦ розробки ПС (Software Development Life Cycle), стандарту PMBOK, моделей перспектив та процесів;

– системи Professional Studio та Foundation Server для підтримки процесів проектування, кодування, тестування, формування версій ПП тощо;

– системи CMMI Process Impovement для регулюванням строків розробки за інструментами технології Agile.

Пакет VSTS є сімейством продуктів, призначених для проектування ПС, взаємодії різних членів команди, а також для підбору, розподілу і виконання робіт щодо програмного проекту. Виконавці проектів поділені за чотирма категоріями з урахуванням їх рівня знань і навиків програмування систем (рис. 8.8).

 

Рис. 8.8. Категорії розробників в пакеті VSTS

 

Кожний член отримає роботу відповідно до здібностей і виконує її за відповідними для категории засобами. Перехід з першої категорії на вищу категорію можливий за допомогою якісного виконання завдання або додаткового навчання. Спеціалісти четвертої групи це кваліфіковані і відповідальні за функціональну правильність розробки ПС.

Засобом підтримки процесу розробки елементів ПС є IDE (Integrated Development Environment), а перевірка вимог, відстеження процесів і результатів розробки з оцінюванням ступеня їхньої готовності виконує Microsoft Office Project й Microsoft Office Excel. Тестування елементів ПС здійснюється додатковими засобами, що інтегруються з Visual Studio. У середовищі VSTS є також такі засоби:

Microsoft SQL Server 2005, що забезпечує збереження усіх робочих результатів, вихідного коду й даних інтеграції зусиллями Team команди. Підтримка різних типів звітів членів команди і роботи порталу забезпечується інструментами Analysis і Reporting Services та SharePoint Portal Services;

Microsoft Project 2003 – альтернативний засіб для керівників проекту;

Microsoft Excel 2003 – альтернативний засіб для керування проектуванням ПС тощо.

До основних елементів продукування ПП у середовищі VSTS відносять наступні.

Вимоги до якості (quality of service), які визначають характеристики системи, а саме: продуктивність (performance), навантажувальна здатність (loadability), стійкість до перевантажень (stressability), наявність і доступність функцій (availability, accessibility), зручність експлуатації (serviceability) і простота обслуговування (maintainability).

Завдання – це task, що визначає певні дії (наприклад, опис вимог, підготовка й виконання тестів тощо).

Ризики, тобто визначення ймовірних подій або умов, що можуть негативно позначитися в майбутньому ПП, а також дії по їхню мінімізацію і зменшенню.

Помилка – інформація про наявність у системі потенційної проблеми та шляхи її виправлення.

Таким чином, середовище VSTS є прикладом колективного вироблення ПП. Для цього є багатий набір інструментів для керованої підримки процесу ЖЦ проекту за графіком, а також його відслідкування, оцінювання результатів на якість, відповідну вартість та строки виконання проекту.

Засоби й інструменти методології MSF. Ця методологія – система стратегій, принципів і керування проектом побудови виробничої архітектури підприємства з урахуванням [15]: обсягів робіт у проекті, часу і вартості, кількості персоналу, комунікацій, закупівель і контрактів, ризиків.

Модель архітектури підприємства розробляється за такими аспектами: бізнес, застосування, інформація, технологія. Для розробки ПП створюється скоординований технологічний план, що відповідає пріоритетові архітектури й одержанню максимального ефекту при мінімумі витрат. При цьому дотримується баланс між цілями і вимогами ПС, головними проектними рішеннями, людськими і фінансовими ресурсами організації.

Метод MSF базується на аналізі і розробці вимог до ПС, проектуванні проектних рішень, що враховують базові концепції підприємства і пріоритетності архітектури. Цей метод містить у собі набір моделей:

– виробничої архітектури;

– проектної групи;

– процесу розробки ПС;

– керування ризиками;

– процесу проектування;

– застосування.

Модель виробничої архітектури – це набір принципів для створення версії виробничої архітектури підприємства за чотирма перспективами: бізнес, область застосування, інформацію і технологію (рис. 8.9).

Основна задача цієї моделі – пристосування виробничої архітектури до бізнес-цілей організації поетапний випуск серії послідовних версій, орієнтованих на зазначені пріоритети та їхне послідовне коректування для одержання цілевої виробничої архітектури.

 

Рис. 8.9. Перспективи виробничої архітектури

 

Бізнес-перспектива вміщує стратегії і плани переходу до поліпшеного стану підприємства, коли визначені глобальні цілі і задачі організації; види продуктів і послуг; бізнес-процеси реалізації основних функцій і зв’язків між ними.

Інформаційна перспектива ґрунтується на можливостях організації автоматизувати бізнес-завдання на персональних комп’ютерах з використанням загальносистемних засобів, мереж, документів і таблиц БД, створених у процесі роботи організації.

Технологічна перспектива призначена для регламентації дій розробників з створення архітектури шляхом опису інфраструктури і системних компонентів, необхідних для підтримки прикладної й інформаційної перспектив з використанням відповідних технологічних стандартів і сервісів.

Модель проектної групи визначає ролі, обов’язки кожного учасника проекту і розподіл між ними відповідальності з урахуванням змісту проекту, розміру групи і кваліфікації учасників. Члени проектної групи аналізують плани робіт, виявляють взаємозв’язки і перевіряють роботи на функціональність.

Модель процесу розробки ПС – це набір процесів, їх процесів, видів діяльності і результатів процесу розробки ПС. Між цією моделлю і моделлю проектної групи встановлюється тісний зв’язок. Це дає можливість проводити контроль ходу розробки проекту, мінімізацію ризиків, підвищення якості і скорочення термінів виконання проекту.

Члени проектної групи на процесі розробки створюють: код системи, конфігурацію, функціональну специфікацію і сценарії тестування. Вони також створюють інфраструктуру і документ на конфігурацію. До основних задач інфраструктури відносять:

– залучення клієнтів до створення системи;

– установлення зв’язків з корпоративною мережею;

– збереження даних, створюваних на різних комп’ютерах і розташованих на окремих територіях підприємства;

– видача інформації про властивості продукту комп’ютерною мережею і т.п.

Виконання цих задач базується на:

– узгоджені інформаційних технологій з цілями бізнесу;

– обґрунтовані змін і відповідних витрат з урахуванням майбутніх інвестицій;

– удосконалені внутрішніх і зовнішніх зв’язків між підрозділами підприємства, а також між замовником, постачальником і т.п.;

– керуванні ризиками проекту шляхом їх аналізу і виявлення найбільш істотних моментів ризику, реалізації стратегії їхнього усунення, планування і моніторингу ризиків.

Модель процесу проектування визначає мету і задачі процесу розробки виробничої архітектури за трьома фазами розробки, а саме, концептуальної, логічної і фізичної. На цих фазах виконується систематичний перехід від абстрактних концепцій до конкретних технічних рішень.

Модель застосування – це трирівнева структура, створена сценарним методом проектування і розробки системи. Її мета – забезпечити наочність, рівнобіжне виконання робіт і різні зручності при експлуатації і розгортанні компонентів системи на комп’ютерах і в різних серверах.

Таким чином, методологія MSF дає можливість проектувати програмне і інформаційне забезпечення підприємства за допомогою розглянутих принципів, моделей і методів вирішення задач цього підприємства.

Скоротити час розробки ПС, домогтися максимальної відповідності процесів вартісним і часовим вимогам, а також підвищити якість програмних продуктів виконується з використанням моделі MSF for CMMI Process Improvement. У ній містяться набір формальних методик для оцінки бізнес-процесів і можливості компаній, що займаються розробкою ПС. Вона має засоби для зниження ризиків у великих проектах та одержання в майбутньому сертифікатів різних рівнів.

 

8.3.3. Загальна характеристика інструментів Rational Rose

CASE-cистема Rational Rose [16] підтримує застосування мови моделювання UML для представлення архітектури ПС з об’єктів. Засоби проектування і моделювання загальної (або абстрактної) архітектури та моделі системи поступово уточнюються до конкретної (фізичної) моделі класів об’єктів щодо створюваної ПС. Результат моделювання – візуальна (діаграмна) логічна модель системи.

Об’єктно-орієнтовані програмні і інформаційні системи представляються у вигляді файлів логічної моделі за мовою UML. На її основі проводиться кодування її елементів засобами МП (С++, Ada, Java, Basic, XML, Oracle). Для зв’язування програмного коду ПС з БД може застосовуватися система Delphi. Допускається зворотне проектування, тобто перетворення готової інформаційної системи (наприклад, на С++) або база даних (Oracle) у візуальну модель ПС.

Мова UML отримала автоматизовану підтримку в системі Rational Rose, а деякі аспекти проектування з метою досягнення якості знайшли відображення у ряді інструментальних засобів, короткий опис яких додається нижче.

Керування вимогами – RequisitePro. Цей інструмент дозволяє виявляти, формувати і структурувати набори вимог у наочній формі. Для кожної вимоги зберігається історія створення, що дозволяє відслідковувати внесені зміни у попередні вимоги. Усі документи і дані, що пов’язані з вимогами, зберігаються у централізованій базі проекту. Там же зберігаються сценарії, функціональні і нефункціональні специфікації вимог, плани їхнього трасування та тестування.

Керування проектом і версіями – ClearCase. Це система керування програмним проектом. Вона зберігає всі проектні рішення, структури й інші артефакти у репозитарії. В ньому зберігаються вихідні тексти об’єктних і програмних модулів, а також усі зміни, що були внесені в проект та в сформовані версії. Ця система дозволяє виводити характеристики змінених файлів у графічній формі і надавати всі зміни у вигляді дерева версій.

Дана система забезпечує контроль робіт команди розробників, а також обмін даними між різними розробниками проекту, що географічно розташовані на відстані один від одного. При одержанні останньої версії ПС проводиться їхній контроль, керування робочим простором за допомогою унікального інваріантного підходу. Є можливість прискорити цикли розробки ПС і створити нові, надійні в експлуатації продукти ПС, а також допрацьовувати і підтримувати раніше реалізовані продукти без зміни середовища, інструментів і методу розробки.

Кожен учасник проекту може мати доступ, як до усіх файлів проекту, так і до тільки що визначеної його частини з використанням системи фільтрів, яка заховує непотрібну інформацію. Розробник може виходити з загального складу розробки проекту, а також після усіх внесених змін повернутися знову у проект. ClearCase здійснює автоматичне злиття версій, контроль конфігурацій і версій на основі збереження всієї історії і кожного файлу проекту, включаючи міграцію файлів між незалежними проектами.

Змінювання систем – ClearQuest. Її мета – архівація всіх змін та створення БД засобами SQL, MS Access, Sybase SQL Anywhere або Oracle. SQL-запити можуть додаватися до вже готової БД. Тобто ClearQuest забезпечує:

– керування змінами об’єктів у ході процесу розробки ПС;

– оптимізацію шляху проходження запитів і зв’язаних з ними форм і процедур;

– зв’язок об’єктів, розділених територіально через World Wide Web;

– упровадження надійного і перевіреного процесу або зміну вже існуючого процесу для задоволення специфічним вимогам;

– візуальний аналіз проекту з графічним подання інформації і звітів;

– інтеграцію з засобами ClearCase з метою створювання зв’язку між запитами та розвитком коду;

– зв’язок з Sybase, Oracle, Microsoft;

– інтеграцію з засобами тестування (TeamTest, VisualTest, Purify, PureCoverage, Quantify і Robot);

– створення звітів за допомогою Crystal Reports;

– інтеграцію COM з MS Word і MS Excel.

Інструменти вимірювання продукту – Rational Quantify. Цей інструмент призначений для ідентифікації «вузьких місць» у ПС, що розробляється, виявлення частин застосування, що сповільнюють швидкість його виконання, та обліку продуктивності. Він може генерувати список усіх викликуваних у процесі роботи функцій ПС в табличній формі, указуючи тимчасові характеристики та статистику за усіма викликах (зовнішнім і внутрішнім). Це створюється за допомогою технології OCI (Object Code Insertion) шляхом підрахунку циклів, вставки лічильників у код тестованої програми для фіксації виконаних циклів. Накопичена статистична інформація щодо викликів може бути використана для побудови графіків і зведених таблиць у середовищі Microsoft Excel. Інакше кажучи, даний інструмент може надавати точну інформацію про продуктивність створеної ПС та вузькі місця виконаних функцій, викликів, бібліотек тощо.

Для підвищення продуктивності ПС до складу інструменту входять наступні засоби:

– Call Graph призначений для графічного подання даних, що використовуються у критичних функціях і вимагають найбільшого часу їхнього виконання;

– Function List і Function Detail забезпечують видачу візуальних даних у табличній формі у вікнах, в які можна безпосередньо вносити зміни до коду і построкове переглядати дані в анотованих копіях цих вікон;

– можливій вихід у середовище DCE, систему Solaris і бібліотеки SunOS IBM;

– збирання даних про продуктивність в усіх використовуваних інструментах;

– використання мов (C, C++, Fortran, Ada і Java).

Тестування ПС – Visual Test. Цей інструмент забезпечує функціональне тестування незалежно від мови реалізації компонентів ПС для Windows, а також компонентів Active, DLL, сервера автоматизації OLE (OLE Automation server). Він має інтерфейс із Microsoft Visual Studio, в якому можливо створювати, розширювати можливості компонентів та КПВ, а також пристосовувати їх з інших проектів. Інший засіб Rational Robot дозволяє тестування графічного інтерфейсу більше ніж у GUI, а також тестувати сотні і тисячі властивостей всіх об’єктів ПС в цілому і кожний окремо. Він працює в двох режимах: в автоматичному і ручному. У ручному режимі користувач сам задає сценарій тестування у спеціальної мові, а в автоматичному режимі генерують необхідні скріпти для подальшого повторного тестування ПС.

LoadTest – засіб автоматизованого тестування характеристик розподілених мережних застосувань для платформ Windows і Unix. При тестуванні продуктивності допускається завантаження сервера для великої кількості віртуальних користувачів. Наприклад, можна установити таймер для одного користувача, щоб визначити час виконання запиту при його посилці на той же самий сервер або в той же самий час їх множину. Для перевірки продуктивності ПС можуть створюватися навантажувальні, стресові, конкуруючі і конфігураційні тести. Якщо клієнт/серверна система має розподілену архітектуру, то завантажувальне тестування може бути використане для перевірки правильності вибраних методів з метою конструювання системи. Крім того виміряється час виклику серверної частини. Графічний інтерфейс дає вимір часу відзиву системи в конкретному клієнтському застосуванні.

Pure Coverage призначений для виявлення ділянок коду, пропущених для тестування застосування у Windows NT та компонентів, опис яких подано у мовах Visual Basic, Visual C++ або Java. Цей інструмент збирає статистику про ті ділянки програми, що під час тестування не були пройдені, виявляє рядки, що не виповнюються, й аналізує причини їхнього невиконання.

Керування якістю. Для поліпшення якості ПС використовується набір інструментальних засобів: Visual Test, Rational Quantify, Purify, Pure Coverage.

Інструмент Visual Test використовується для тестування компонентів і їхніх інтерфейсів на рівні опису МП, а інструменти Rational Robot і LoadTest підтримують тестування завантажених застосувань у клієнт-серверному середовищі. Вони збирають дані для оцінювання деяких показників якості, наприклад, надійності.

Засоби інженерії і реінженерії. Інструмент Rational Rose Professional призначений для прямого і зворотного проектування ПС з урахуванням обраної МП. Результат проектування – шаблон інформаційної системи, який необхідно запрограмувати на підходящій МП. Інструмент Rose Enterprise призначений для проектування архітектури підприємства з використанням багатьох перерахованих вище інструментів.

Rose DataModeler призначений для проектування ПС і БД без кодогенерації. Rose RealTime – спеціалізована версія для проведення повної кодогенерації і реінженерії ПС на мовах С и С++ з використанням діаграм UML.

Інструменти аналізу стану середовища – Purify. Це інструмент призначений для збирання даних про будь-які втрати пам’яті (наприклад, неповернення з блоку), зупинки виконання програм за станом середовища, пов’язаним з помилкою типу run–time. Розробник ПС має можливість не тільки знати стан її виконання (попередження, помилки), а й переходити до відповідних внутрішніх викликів інших компонентів.

Інструмент документування – SoDa. Призначений для автоматизації документів і підготовки звітів по заздалегідь установленому шаблону, по якому компілюється документація з текстовими і графічними даними, а також з використанням стандартних шаблонів, створених за допомогою Wizard і меню Word.

 

8.3.4. Засоби підтримки процесу RUP

RUP (Rational Unified Process) – це уніфікований процес побудови моделей і з них ПС. Функціональні можливості системи, що створюється, визначаються прецедентами, кожний з яких відображає спосіб використання ПС. Опис прецеденту визначає те, що відбудеться у системі, коли він буде виконаний. Прецедент – це набір екземплярів, а кожний екземпляр – це послідовність дій з виконання задачі системи і отримання відповідного результату, який чекає деякий суб’єкт або користувач. Як претендент може бути будь-яка інша система, взаємодіюча з даною ПС [17].

Модель – це структура предметної області, її елементи, що виділяються на ранніх процесах її проектування. Коли обговорюється система і вимоги до неї, наприклад, з кінцевим користувачем або замовником, модель повинна описувати те, що система повинна робити, абстрагуючи від різних подробиць на рівні, що вище рівень МП, з метою задовольняння потреб проектувальників. Формалізація моделей у RUP забезпечується засобами UML і дає можливість строго описувати вимоги, що перетворяться до готового продукту.

Головною моделлю є модель варіантів використання, на основі якої розробляються моделі аналізу, проектування, реалізації системи тощо (рис. 8.10).

 

Рис. 8.10. Зв’язок моделей у системі RUP

 

Кожна модель відповідає моделі варіантів використання, в які входять вхідні дані для пошуку і специфікації класів, для підбора і специфікації тестів, а також планування ітерацій розробки й інтеграції ПС.

Модель аналізу забезпечує специфікацію вимог до системи й опис варіантів використання як кооперації між концептуальними класифікаторами. Модель проектування забезпечує створення статичної структури й інтерфейсів системи, а також реалізацію варіантів використання у вигляді набору кооперацій між підсистемами, класами й інтерфейсами. Модель реалізації містить у собі компоненти системи у вхідно МП. Інші моделі – модель тестування і модель розміщення компонентів призначені для їхнього виконання в операційному середовищі комп’ютерів.

Артефакти однієї моделі зв’язані між собою і повинні бути сумісні один з одним. Відношення між моделями є не цілком формальними, оскільки частини моделей специфіковані мовою метамоделі, а інші описані неформально, природною мовою. Специфікації діаграм UML – формальні.

Моделі задаються відповідними діаграмами use case. Вони взаємозалежні, семантично перетинаються і визначають систему як єдине ціле. Варіант використання може мати відношення залежності до кооперації в моделі проектування, що задає реалізацію. Моделі, визначені на кожній ітерації процесу RUP, уточнюються або розширюють моделі попередніх ітерацій процесу. Варіанти використання специфікують тип відношень між діючою особою (актором), користувачем і системою. На високому рівні абстракції вони представляються упорядкованою послідовністю дій або альтернатив. Крім цього, варіант використання це різновид класифікатора, операції якого – повідомлення, одержувані екземплярами конкретного варіанта використання. Методи задають реалізацію операцій у термінах послідовностей дій, виконуваних екземплярами прецеденту або варіанта використання.

 

Приклад.

Нехай uc – варіант використання (– use case), операція якого виконується над обліковим записом і має наступне визначення:

uc.operations = <op1>, op1.name = запит і відновлення облікового запису,

op1.method.body = {< перевірка ідентифікації користувача, наявності сервісу, запиту про борги, відновлення облікового запису >,

< перевірка ідентифікації користувача на відхилення облікового запису >,

< перевірка ідентифікації користувача на наявність сервісу і відхилення облікового запису >,

< перевірка ідентифікації користувача і перевірка наявності сервісу або запиту про борги, на оплату, відновлення облікового запису >}.

 

Тіло методу – процедура реалізації операцій у вигляді послідовності дій op.method.body. Між іменами дій варіанта використання й іменами дій у кооперації установлюється відображення, що забезпечує гнучкість у процесі розробки і модифікації імен дій. Між кооперацією і варіантом використання створюється відношення реалізації.

Варіант використання, що реалізується кооперацією, забезпечує взаємодію і поведінку. Якщо кооперація має більш складне поводження, ніж задане варіантом використання, то цей варіант використання – часткова специфікація поведінки кооперації. Варіанти використання специфікують дії, видимі за межами системи, але не специфікують внутрішніх дій (створення і видалення екземплярів класифікаторів, взаємодія між екземплярами класифікаторів і т.д.).

З практичної точки зору RUP представляється упорядкованим набором процесів: формування вимог, аналіз, проектування, реалізація й іспит кроків і процесів ЖЦ, що виконуються ітеративно. Кожен етап процесу має завершення, що називається черговою ітерацією. Остання ітерація – це випуск продукту. На кожній ітерації цикл робіт може повторюватися, починаючи зі збирання й уточнення вимог.

Етап формування вимоги. На цьому процесі проводиться збирання функціональних, технічних і прикладних вимог до проекту. На основі вимог замовника і користувачів система описується так, щоб досягти розуміння між користувачами і проектною групою. Інформація збирається з урахуванням особливостей існуючих систем і документів, підготовлених замовником, і містить у собі:

– модель ПрО;

– модель схем використання з описом функціональних і загальних вимог у формі результатів опитування, наборів діаграм і детального опису кожної схеми;

– дизайн і прототип інтерфейсу користувача для кожного актора;

– список вимог, що не відносять до конкретних схем використання.

Етап аналізу. Сформульовані вимоги уточнюються і відображаються в моделі сценаріїв використання. Крім того, створюється аналітична модель системи, що містить у собі формалізми для аналізу внутрішньої структури системи, визначення класів і перетворення цієї моделі на проектні концепції і схеми їхньої реалізації. Основу моделі аналізу становлять діаграми класів, взаємодії, що задають можливі сценарії варіантів використання системи в термінах взаємодії об’єктів на процесі аналізу.

Етап проектування слугує для уточнення класів і опису їхніх чотирьох рівнів: користувальницького інтерфейсу, бізнес-рішень, рівня доступу і рівня даних. Створювана проектна модель системи складається зі структури підсистем, їхнього розподілу між рівнями, інтерфейсів класів і об’єктів, зв’язків класів з вузлами розгортання (модель розгортки).

На процесі реалізації виконується побудова прототипу з компонентів; створення тестів за схемами використання; тестування й інтеграція компонентів; перевірка архітектури; перехід до наступної ітерації. При кожній ітерації тестова модель уточнюється шляхом виключення неактуальних тестів, створення схеми регресійного тестування і додавання тестів для компонентів, що збираються. Кожен тест створюється за допомогою варіантів використання і реалізує конкретний метод перевірки функцій системи на вхідних даних.

 

8.3.5. Середовище розробки систем – CORBA

Система CORBA підтримує об’єктно-орієнтовану парадигму програмування. Її основу становить OMA-архітектура, як базис побудови конкретних прикладних розподілених систем. Цей базис містить у собі сервіси і послуги, компоненти яких мають стандартний інтерфейс для взаємодії один з одним і визначаються як компоненти верхнього і проміжного рівнів [18, 19].

Компоненти верхнього рівня − сервісні, надають сервіс для об’єктів і доступ до них різних зовнішніх застосувань. Наприклад, компонент-система керування складними документами надає розробнику або користувачу стандартний спосіб доступу до документів цієї системи для маніпулювання ними.

Компоненти проміжного рівня надають сервіс застосуванням для доступу до розподілених системних засобів комунікації, інтеграції, маркетингу й ін.

Еталонна модель надає механізм інтеграції різних компонентів системи в профілі, що повинні узгоджуватися зі стандартною архітектурою і складати деяку готову конфігурацію готової програмної системи.

До складу еталонної моделі входять набори компонентів по кожним її системам і засобам, а саме:

– брокер об’єктних запитів (Object Request Broker − ORB), що забезпечує взаємодію об’єктів;

– загальні об’єктні сервіси (Common Object Services), що забезпечують сервіс всім об’єктам, а також в керуванні змінами, реалізаціями, контролем, транзакціями т.п.;

– загальні засоби обслуговування (Common Facilities) або загальні послуги, що надають ряд загальних прикладних функцій, що можуть поєднуватися в різні конфігурації в залежності від заданих вимог (наприклад, засобу печатки, БД і електронна пошта);

– об’єктні застосування (Application Objects), до яких відносять і їхні компоненти, що реалізують задачі й об’єкти користувача для функціонування в об’єктно-орієнтованому середовищі, і над якими можуть вироблятися операції типу − відкрити, перемістити і помістити.

Три компоненти (загальні об’єктні сервіси, загальні засоби обслуговування й об’єктні застосування) відповідають розбивці ПС на функції − базові для більшості застосувань або досить загальні для широкого класу ПС. Ці компоненти взаємодіють між собою через брокер ORB.

Об’єктні застосування і загальні засоби обслуговування забезпечують функції і сервіси за допомогою об’єктних інтерфейсів, а також дозволяють адаптуватися до нових поколінь мереж, мов і середовищ.

У загальному випадку об’єкти можуть видавати, обробляти запити і надавати сервіси для інших об’єктних застосувань або для загальних засобів, що підтримують механізм повторного використання класів і об’єктів. Для зв’язку об’єктно-орієнтованого застосування із сервісними або загальними засобами обслуговування використовуються адаптери інтерфейсів або посередники.

Еталонна модель не накладає яких-небудь обмежень на структуру і реалізацію об’єктних ПС або загальних засобів. Об’єкти можуть забезпечувати подання інформації, взаємодію з користувачем, виконання прикладних функцій, постійне збереження даних або різні комбінації перерахованих можливостей.

При реалізації сервісів більш низького рівня використовуються сервіси, що підтримуються операційними системами і середовищами, а також базовими сервісами, наданими мережними обчислювальними системами.

Технологія обробки запитів брокером ORB дозволяє прикладній програмі запитувати сервіси в іншої програмі, викликаючи методи вилучених об’єктів. Для реалізації взаємодії об’єктів і програм (клієнта і сервіра) використовується мова інтерфейсу IDL для сторони сервера або клієнта або для обох. З боку клієнта потрібна специфічна IOR форма (Interoperable Object Reference), що підтримує іменування сервера. Браузер CORBA переглядає імена сервісів і генерує код для вставки його у файл класу клієнта. Для сторони сервера він доповнює код, що зв’язує екземпляри сервентів з іменами сервісів і вставити його у файл класу сервера. IDL файл компілюється, отримана програма запускається для виконання [2, 18].

Інтеграція компонентів в системі CORBA виконується за такими засобами:

– Client class викликає метод, що буде виконаний сервером;

– Stub class забезпечує конвертування даних методом, що ініціює роботу клієнта в Wire форматі, використовуваному при зв’язуванні на стороні клієнта мережі;

– ORB class керує методами передачі даних і викликами методів між процесами, а також зв’язками з сервером та адаптером (рис. 8.11);

 

Рис. 8.11. Головні функції брокера ORB в ОМА-архітектурі

 

– Server class створює сервент і посилання ORB, що він записує в стандартний вихідний файл;

– Implementation class містить у собі ділову логіку сервера, екземпляр класу сервент, що реєструється в ORB для запуску іншого процесу клієнтом;

– Skeleton class конвертує ініціюючий метод з Wire форматом у формат, що може прочитати екземпляр сервента;

– адаптер POA (Portable Object Adapter) для породження порожнього сервера (Empty), основного сервера (ServerMain), простого Simple та клієнта (ClientMain).

Для ініціалізації компонентів використовується три параметри (value, title, type), кожний з яких задається змінною строкового типу:

 

<server-binding name = ‘Proprietary Binder’

Template-tag = ‘SERVER_BINDING’>

<wizard requires-value = /*FFJ_COBRA_TODO_SERVER_NAME*/’

title = ‘Server name:’ type = ‘string’/>

 

Інтерфейси об’єктів у IDL-мові запам’ятовуються в репозитарії інтерфейсів (Interface Repository), а реалізації об’єктів – у репозитарії реалізацій (Implementation Repository). Незалежність інтерфейсів від реалізацій об’єктів дозволяє них використовувати статично і динамічно різними застосуваннями [2, 18, 19].

Об’єкт-клієнт і об’єкт-сервер обмінюються між собою за допомогою запитів, кожний з яких виповнюється брокером ORB.

Інтерфейс клієнта (Сlient Interface) забезпечує взаємодію з об’єктом- сервером через ORB і складається з трьох інтерфейсів:

– stub-інтерфейсу, що містить у собі опис зовні видимих параметрів і операцій об’єкта в IDL-мові, утворить статичну частину програми клієнта і зберігається в репозитарію інтерфейсів;

– інтерфейсу динамічного виклику DII (Dynamic Invocation Interface) об’єкта, обумовленого під час виконання програми клієнта, використовуючи опис інтерфейсу з репозитарії інтерфейсів;

– інтерфейсу сервісів SI (Services Interface), що містить у собі набір сервісних функцій, які клієнт запитує у сервера через брокера.

Stub-інтерфейс – клієнтський інтерфейс, забезпечує взаємозв’язок клієнта з ORB. Прикладна програма клієнта через посередника stub, як статичної частини програми клієнта, посилає в запиті параметри, яким зіставляються відповідні описи інтерфейсу з репозитарієм інтерфейсів.

Інтерфейс DII забезпечує доступ до об’єктів і їхніх інтерфейсів під час виконання. Цей інтерфейс стає відомим під час виконання і доступний при обробленні викликів ORB. У кожнім виклику вказується тип об’єкта, тип запиту і параметри. Таку інформацію посилає прикладна програма або вона витягається з репозитарію інтерфейсів.

Інтерфейс SI підтримується об’єктним адаптером (Object-Adapter) в часті забезпечення такого сервісу: генерація й інтерпретація посилань, виклик методів, захист, активізація (пошук і виконання об’єкта), відображення посилань і їхню реєстрацію. Існує кілька видів адаптерів:

– базовий адаптер (Basic Object Adapter) може забезпечити виконання об’єктів незалежно від брокера;

– бібліотечний адаптер (Library Adapter) забезпечує виконання об’єктів з бібліотеці об’єктів або із прикладної програми клієнта;

– адаптер БД (Database Adapter) забезпечує доступ до об’єктно-орієнтованої БД.

Загальні об’єктні сервіси забезпечують базові операції для моделювання і збереження об’єктів, визначають сукупність кореневих операцій, що можуть реалізовувати або успадковувати всі класи.

Сервіси специфікують COSS (Common Object Services Specification) і забезпечують набір об’єктів, що виконують операції з визначенням подій, іменуванням, взаємодією і керуванням рівнобіжними обчисленнями й ін. Ці операції стають доступними застосуваннями через ORB або інші інтерфейси. Інакше кажучи, об’єктні сервіси не припускають єдиного інтерфейсу або реалізації. Вони є операціями, що служать як «цеглинка» при розширенні або додаванні функцій, наданих загальними засобами системи CORBA. Наприклад, об’єктні сервіси можуть виконувати керування трансакціями, зв’язками об’єктів. До операцій загального об’єктного сервісу відносять:

– керування екземплярами і класами об’єктів;

– збереження об’єктів, їхніх станів і методів;

– забезпечення цілісності, несуперечності і вірогідності стану об’єктів як усередині одного об’єкта, так і серед об’єктів класу;

– забезпечення безпеки і захисту об’єктів і даних;

– реалізацію запитів і рівнобіжне їхнє виконання;

– забезпечення життєвого циклу об’єктів (утворення, знищення, переміщення, копіювання);

– обслуговування черг запитів і ін.

Даний сервіс підтримує роботу з об’єктами, їхнє існування і незалежність від систем, що до них звертаються.

Загальні засоби обслуговування призначені для багатьох прикладних доменів, вони полегшують побудову застосувань, що функціонують під керуванням ORB. Для кінцевих користувачів ці засоби забезпечують уніфіковану семантику загальних компонентів і взаємодію з іншими об’єктами через брокера ORB і об’єктний інтерфейс. Вони підрозділені на такі компоненти:

1) інтерфейс користувача (User Interface);

2) керування інформацією (Information Managment);

3) керування системами (Systems Managment);

4) керування завданнями (Task Managment).

Дамо загальну характеристику цим засобам.

1. Інтерфейс користувача підтримує архітектуру структур документів для застосування в різних областях, а саме:

– менеджер вікон (Windows manager) і емулятор програм (Emulator program);

– система керування роботами (A work managment system) для керування розділами і візуалізацією дисків;

– автоматизація завдань і процесів (Task and process automatisation) та видання електронних таблиць (spreadsheep) і макросів діалогу.

Ці компоненти утворять проміжна ланка між системою і сервісом відображення результатів на дисплей.

2. Керування інформацією відповідає відомим засобам керування інформацією в інформаційних системах і містить у собі:

– обмін даними;

– доступ до даних (читання, запис, збереження й ін.);

– кодування і представлення даних;

– посилка транзакцій і облік часу обробки;

– моделювання інформації й ін.

До засобів керування відносять також: утилізацію, контроль доступу, підтримка конфігурацій і метаданих і т.п.

3. Керування системами обслуговування (CORBA-facilities), що входять до складу функцій адміністратора розподіленими системами. Основа засобу − це адміністрування застосуваннями при звертанні до загальних засобів обслуговування і до засобів сервісу CORBA. Фактично це керування виконує адміністратор розподілених систем.

4. Керування завданнями складається з засобів виконання завдань, зв’язаних з об’єктами, інтерфейсами, що мають опис у IDL системи CORBA, і доступ до об’єктів через scripts і макроси.

Об’єктні застосування розробляють незалежні розробники ПС за об’єктним підходом і ті, хто забезпечує розширення функцій існуючих систем. Це зв’язані набори прикладних функцій (наприклад, підготовка текстів і відображення витраченого часу й ін.). Вони не стандартизовані, утворять компоненти середовища CORBA і можуть мати доступ до сервісу і послуг системи через стандартний інтерфейс.

Класи об’єктів у цих застосуваннях знаходяться на тому ж семантичному рівні, що і класи в загальних засобах обслуговування.

Різниця лише в тому, що класи загальних засобів обслуговування – це дуже загальні функції, а класи об’єктних застосувань і більш спеціалізовані і надають специфічні для прикладного домену інтерфейси. Програми, що входять у складі об’єктних застосувань, можуть використовувати:

– загальні прикладні засоби (підготовка текстів, електронні таблиці, електронна пошта й ін.);

– системи автоматизації застосувань (СА, ECAD, MCAD);

– системи автоматизованого проектування архітектури;

– інструментальні засоби підтримки розробки програм, проектування БД і ін.;

– системні програми керування мережею;

– засоби доступу до інформації й одержання довідок з довідкових систем і з БД інформаційних систем і т.д.).

Окремі класи в об’єктних застосувань можуть «мігрувати» у загальні засоби обслуговування, якщо є спільність реалізованої задачі й інтерфейсів для класів об’єктів у різних застосуваннях.

Таким чином, CORBA надає розробникам загальну архітектуру створюваної системи, що адаптується до конкретних умов прикладної області, і на її основі реалізуються специфічні задачі системи за об’єктами, методами і їхніми інтерфейсами. О’єктів повторного використання мають тільки інтерфейси.

 

8.3.6. JAVA-технологія

JAVA-технологія базується на стандартній моделі EJB (Enterprise Java Beans), призначеній для забезпечення взаємодії різних компонентів за допомогою виклику методу RMI (Remote Method Invocation) мови Java. Відповідно до цієї моделі програмні компоненти групуються в прикладну програму для роботи в будь-якому середовищі на віртуальній машині JVM (Java Virtual Machine). Веаns-компонент розробляють як КПВ для різних середовищ. Механізм розгортання beans-компонентів на сервері базується на програмах, записаних мовою Java. Існуює спеціальна утиліта побудови застосування для його конфігурування, об’єднання і включення до них нових компонентів [20].

Для визначення функціональних властивостей компонентів, орієнтованих на КПВ, використовують проектні шаблони властивостей і подій. До властивостей beans-компонентів відносять підмножину станів, значення яких визначають поведінку і зовнішній вигляд компонента. Bean-компоненти генерують події або посилають їх іншим об’єктам, а проектні шаблони забезпечують ідентифікацію цих подій.

Компоненти beans підрозділяють на три категорії:

1. Компоненти сеансів, що підтримують правила бізнесу-логіки, орієнтовані на стани і можуть бути пов’язані з конкретним клієнтським сеансом.

2. Компоненти сутностей, що виконують зв’язок з БД безпосередньо і надають дані в об’єктній формі.

3. Компоненти керування подіями, що функціонують за одержанням повідомлень, а також отримують від системи повідомлення JMS (Java Messaging System).

При створенні beans-компонентів використовуються інтерфейси: home – для керування ЖЦ компонента; інтерфейс Remote для виклику і реалізації компонента в середовищі віртуальної машини JVM. Кожен компонент beans має свій контейнер, що викликає і регулює всі процеси ЖЦ і інтерфейс.

Основна особливість beans компонентів у JAVA – це відображення здатності аналізувати самого себе і реалізовувати свої можливості динамічно під час виконання, а не під час компіляції. З цією метою використовується пакет Java.lang.reflect, що входить у ядро API, він підтримує відображення різних компонентів і містить у собі інтерфейс (member), що визначає методи одержання інформації про поля і структуру класів.

Для задання властивостей, подій і методів beans компонентів є два способи. Перший спосіб – використання погоджених імен, другий – створення додаткового класу для надання необхідної інформації.

Beans компонент можна розглядати як підмножину станів, що визначають його поведінку і зовнішній вигляд. Ці властивості підрозділяються на прості, булеві, індексовані і зв’язані. Прості властивості мають одиночні значення, можуть бути ідентифіковані проектними шаблонами (наприклад, властивості для read/write, read-only, write-only). Булеві властивості приймають значення true або false і ідентифікуються проектними шаблонами. Індексовані властивості складаються з множини індексованих значень, що задаються проектним шаблоном. Зв’язані властивості відбивають події без зміни функціональності компонента. Інформаційні масиви властивостей (PropertyDescriptor), подій (EventSetDescriptor) і методів (MethodDescriptor) утримуються безпосередньо в стандартному шаблоні BeanInfo. При реалізації цих властивостей розробник може задовольнити вимоги користувача. Обмежена властивість відбиває подію, значення властивості якої змінюється, і відсилає подію об’єктам, що можуть відхилити змінені властивості або підтримати їх залежно від середовища виконання. За допомогою меню (File, Save) інструмента BDK компоненти зберігаються в JАR-архіві у послідовності дій:

– створити каталог для нового beans компонента;

– створити один або трохи вихідних JAVA файлів, що реалізують компонент, і скомпілювати них;

– створити файл опису властивостей компонента;

– згенерувати JAR файл;

– запустити інструментарій BDK для збереження компонента;

– протестувати компонент.

Взаємодія різних компонентів здійснюється за допомогою механізму виклику вилученого методу RMI, що доповнює мова JAVA стандартною моделлю EJB (Enterprise Java Beans) компанії Sun. До неї підключені класи мови JAVA, їхні атрибути, параметри середовища і властивості групування компонентів у прикладну програму для виконання на віртуальній машині JVM. Механізм розгортання JAVA-компонентів типу beans на сервері описується в програмах вхідною мовою, а сервер створює для них оптимальне середовище для виконання задач EJB.

Для реалізації і повторного використання КПВ типу beans маються такі шаб- лони в Java for Forte:

– Beans для створення нового компонента, формування каркаса компонента з простими властивостями і можливістю автоматичної їхньої зміни;

– BeanInfo для інтеграції beans компонентів і забезпечення взаємодії;

– Customizer для створення панелі, на якій розміщаються елементи, використовувані для керування конфігурацією beans компонентів;

– Property Editor для створення класу, що використовується під час проектування і редагування властивостей beans компонентів.

Beans компоненти можуть застсовуватися в інтегрованої архітектурі системі Microsoft Active, контейнери яких підтримують Internet Explorer, Microsoft Office і Visual Basic. Крім того, на сайте java.sun.com можна завантажити інструментальну систему Bridge for Active для застосування Java Beans компонентів у контейнерах Active, а також завантажити інструментарій Java Beans Migration Assistant for Active з метою аналізу елементів керування Active і генерації каркаса JavaBean компонентів.

При інтеграції компоненти використовуєть інтерфейс, опис якого задається парою – ім’я параметра і значення параметра. Вони можуть змінюватися автоматично без втручання в код компонента. Цей опис та змінювання необхідних параметрів інтерфейсу перевіряє Inspector Components.

Таким чином, мова JAVA підтримує стандартні механізми для роботи з компонентами як з будівельними блоками, що мають такі особливості:

– властивості, події і методи керування;

– параметри часу розробки шляхом реінженерії компонента;

– збереження і використання параметрів налагодження конфігурації в заданий час;

– реєстрація повідомлень про події або їхня генерація beans компонентами;

– збереження КПВ в архіві системи JAVA за допомогою шаблона JAR Contents самостійно або у вигляді групи;

– опис компонентів різними МП.

Forte for Java пропонує шаблони інтеграції всіх класів компонентів у програмну структуру в [21].

Інтеграція компонентів. До основних типів компонентів у мові JAVA відносяться: проекти, форми (AWT компоненти), beans компоненти, СОRВА компоненти, RMI компоненти, стандартні класи-оболонки, бази даних, JSP компоненти, сервлети, XML документи, DTD документи, файли різних типів і їхніх груп. Тип компонента має функціональність і підтримується стандартним набором методів JAVA для запуску, функціонування і знищення компонента. Для опису й ініціалізації різних типів компонентів і інтеграції їх у новий проект використовують спеціалізовані шаблони.

Таким чином, розглянуті сучасні засоби, інструменти та середовища значно спрощують процес створення нових типів компонентів, в том числі і КПВ. Саме вони забезпечують виробництво ПС на автоматизованої основі.

 

8.4. Оцінювання вартості системи з компонентів

Інженерія ПС з компонентів, які повторно розробляються або беруться готові, базується на КПВ. Вона вміщує оцінку вартості нової розробки з метою обчислення витрат на створення продукту з сукупності взаємозв’язаних компонентів, що реалізують функції ПрО.

Загальну вартість створення компонентної системи вважаємо такою, що складається з таких складових елементів:

С = С1 + С2 + С3 + С4,

де С1 – вартість аналізу функцій ПрО;

С2 – вартість підбору КПВ з репозитарію або сучасних бібліотек методів з урахуванням знов розроблених компонентів;

С3 – вартість інтеграції всіх компонентів в систему;

С4 – вартість визначення і обробки даних ПС.

Розглянемо окремо кожну складову вартості ПС.

Вартість аналізу функцій ПрО має вигляд

 

 

де  – дані i-функції, M – кількість функцій F в системі,

 

Вартість пошуку і дослідження можливостей застосування КПВ з репозитарію для реалізації деякої визначеної функції ПрО визначається за допомогою виразу

 

 

де  – вартість пошуку КПВ для функції , сформульованої на процесі аналізу ПрО, – кількість нових компонентів і КПВ,  – вартість розробки деяких типових програмних компонентів,

 

Вартість композиції компонентів визначається так:

 

 

де  – вартість створення інтерфейсних модулів пари компонентів Ki і Kr,

 

 

Таким чином, кінцевий результат оцінювання вартості ПС має вигляд (розрахунок С4 громіздкий, тому не приводиться):

 

 

Головне обмеження цього виразу – це необхідність реалізації заданих функцій в ПС, наявність засобів інтеграції пар компонентів Ki і Kr, які можна представити в будь-яких сучасних МП в певному середовищі функціонування, віповідність кількості компонентів R заданим функціям для розв’язання задач ПрО.

Розрахунок вартості для компонентних систем є трудомістким процесом. Загальна вартість зменшується, якщо опис компонентів виконано на одній МП, за рахунок відсутності інтерфейсних модулів перетворення даних в системі.

Висновки. Програмна інженерія характеризується ступенем використання накопиченої програмної продукції у вигляді КПВ і компонентів ПрО багаторазового використання. Розглянуті три напрямки інженерії КПВ, застосувань та ПрО. Інженерія припускає не тільки їхній підбір для застосування в нових розробках ПС, але відповідні інженерні методи планування відбору та оцінювання їхніх показників якості, вартості і ризику придбання КПВ. Наведено загальний опис підходу до опису специфіки ПрО з використанням мови DSL. Визначено процедуру оцінювання вартості розробленої компонентної системи.