Об'єкт но-орієнтоване програмування

 

Розглянемо аспекти об'єктно-орієнтованого програмування систем, а саме, операції над об'єктами та процеси ЖЦ для побудови прикладнихоб'єктно-орієнтованих ПС [4, 5].

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

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

Операції над об 'єктами. Це такі операції:

- введення, збереження, видалення об'єктів тощо, тобто операції життєвого циклу об'єктів;

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

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

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

Загальна форма опису операції має вигляд

Operation_name (param₁,..., param_n)

returns (res₁,..., res_m)

param_i ::= parameter_name: parameter_type

res_i ::= result_name: result_type

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

w: (x₁:s₁, x₂:s₂,..., x_n:s_n) ->(у₁:r₁, y₂:r₂, …, y_m:r_m)

 

де w - ім'я операції;

x₁, x₂,..., x_n - вхідні параметри, a x₁ - керуючий оператор;

s₁, s₂,..., s_n - типи вхідних параметрів;

у₁, у₂,..., у_m - вихідні параметри;

r₁, r₂,..., r_m - типи вихідних параметрів.

 

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

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

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

Об'єктно-орієнтована модель програмної системи створюється на таких ета­пах ЖЦ (рис. 5.3):

 

Рис. 5.3. ЖЦ розробки моделі системи у середовищі ООП

 

Етапам відповідають такі процеси:

- аналіз - створення ОМ ПрО, у якій об'єкти відбивають її реальні сутності і операції над ними;

- проектування - уточнення ОМ з урахуванням опису вимог для реалізації конкретних задач системи;

- програмування - реалізація ОМ засобами мов програмування С++, Java та ін.

- супроводження - використання й розвиток системи шляхом внесення змін у об'єкти або в методи;

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

Наведені процеси можуть виконуватися ітераційно один за.одним і з повер­ненням до попереднього процесу. На кожному процесі може застосовуватися та та сама система нотацій.

Перехід до наступного процесу зумовлює вдосконалення результатів попере­днього процесу шляхом більш детальної розробки раніше визначених класів об'єк­тів і додавання нових класів.

Результат процесу аналізу ЖЦ - модель ПрО й набір інших моделей (модель архітектури, модель оточення й використання). Моделі відображають зв'язки між об'єктами, їхні стани та набір операцій для динамічної зміни стану інших об'єктів, а також їх відношення із навколишнім середовищем.

Існує два типи моделей системної архітектури:

- статична модель для опису статичної структури системи в термінах класів об'єктів і відношень між ними (узагальнення, розширення, використання, успадку­вання);

- динамічна модель для опису динамічної структури системи і взаємодії між об’єктами (але не класами об'єктів) під час роботи системи.

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

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

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

 

UML - метод моделювання

 

Загальна характеристика UML (Unified Modeling Language), як підхід до проектування різних систем, була дана у п. 4.2.1. Тут UML розглядається детальніше, як мова візуального моделювання систем, шляхом подання у вигляді діаграм їхніх статичних і динамічних моделей на всіх процесах ЖЦ [6, 7].

В основу методу покладено парадигму об'єктного підходу, при якій концеп­туальне моделювання проблеми полягає у побудові:

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

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

- моделі процесів, що визначає дії, які виконуються при проектуванні об'єктів як компонентів.

Проектування в UML починається з побудови сукупності діаграм, які візуалізують основні елементи структури системи.

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

Діаграма класів (Class diagram) відображає онтологію домену, за змістом еквівалентна структурі інформаційної моделі методу С. Шлеєра і С. Мелора, визначає склад класів об'єктів і їх зв'язків. Діаграма задасться зображенням, на якому класи позначаються поділеними на три часті прямокутниками, а зв'язки — лініями, що з'єднують прямокутники. Це відповідає візуальному зображенню понять і зв'язків між ними. Верхня частина прямокутника — обов'язкова, в ній записуєтьсяім'я класу. Друга і третя частини прямокутника визначають відповідно список операцій і атрибутів класу, що можуть мати такі специфікатори доступу:

- public (загальний) позначає операцію або атрибут, доступ до яких здійснюється з будь-якої частини програми будь-яким об'єктом системи;

- protected (захищений) позначає операцію або атрибут, доступ до яких здійснюється об'єктами ТОГО класу, в якому вони оголошені, або об'єктами класів-нащадків,

- private (приватний) позначає операцію або атрибут, доступ до яких здійснюється тільки об'єктами того класу, в якому вони визначені.

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

Класи можна перебудувати в наступних відношеннях або зв'язках.

Асоціація - взаємна залежність між об'єктами різних класів, кожний з яких це рівноправний її член. Вона може позначати кількість екземплярів об'єктів кожного класу, які беруть участь у зв'язку (0 - якщо жодного, 1 - якщо один, N - якщо багато).

Залежність - залежність між класами, при якій клас-клієнт може використовувати певну операцію іншого класу; класи можуть бути зв'язані відношеннями трасування, якщо один клас трансформується в іншій внаслідок виконання певного процесу ЖЦ.

Екземпляризація - залежність між параметризованим абстрактним класом-шаблоном (template) і реальним класом, який ініціює параметри шаблону (наприклад, контейнерні класи мови C++).

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

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

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

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

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

Діаграма реалізації — це діаграма компонентів і розміщення. Діаграма компонентів слугує відображенню структури системи як композиції компонентів і зв'язків між ними.

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

Побудова ПС методом UML здійснюється у наступні етапи ЖЦ (рис 5. 4.).

 

Рис.5.4. Схема моделювання і проектування ПС в UML

 

У UML передбачено загальний механізм організації деяких елементів системи (об'єктів, класів, підсистем і т.п.) у групи. Групування можливе починаючи від системи, далі до підсистем різного рівня деталізації і аж до класів. Результат групування називається пакетом. Пакет містить у собі назву простору імен, що займають елементи, які є його складовими, і спосіб посилання на цей простір. Це важливо для великих систем, що нараховують сотні, а іноді і тисячі елементів, і тому вимагають ієрархічного структурування.

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

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

 

Компонентне програмування

 

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

Компонентне програмування дозволяє уникнути цих проблем. Воно є пода­льшим розвитком ООП, заснованим на повторному використанні, специфікації компонентів і їхніх інтерфейсів, композиції та конфігурації компонентів. Зв'язки між компонентами містять у собі підтипи й еквівалентність, а об'єктні зв'язки — класи і суперклас. Сформульовано багато визначень поняття «компонент». Наве­демо одне з них.

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

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

Перехід до компонентів відбувався еволюційно (табл.5.1.) від підпрограм, модулів і функцій.

 

Таблиця 5.1.

Схема еволюції повторних елементів компонентного типу

Елемент композиції	Опис елемента	Схема взаємодії	Форма збереження	Результат композиції
Процедура, підпрограма, функція	Ідентифікатор	Безпосереднє звертання, оператор виклику	Бібліотеки підпрограмі функцій	Програма на мові програ­мування
Модуль	Паспорт модуля, зв'язки	Виклик модулів, інтеграція модулів	Банк, бібліотеки модулів	Програма з модульною структурою
Об'єкт	Опис класу	Створення екземплярів класів, методів	Бібліотеки класів	Об'ектно-орієнтована програма
Компонент	Опис логіки, інтерфейсів (АРІ, IDL), розгорнення	Вилучений виклик у компонентних моделях систем (COM, CORBA, OSF, JAVA,...)	Репозитарій компонентів, сервери, контейнери компонентів	Розподілена компонентно- орієнтована програмна система
Сервіс	Опис логіки і інтерфейсів (XML,WSDL..)	Віддалений виклик (RPC, HTTP,INVOKE» SOAP,...)	Індексація і каталогізація сервісів (XML, UDDI,...)	Розподілене сервісо-орієнговане застосування

 

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

Компоненти конструюються самостійно, як деяка абстракція, що містить у собі інформаційну частину й артефакт (специфікація, код, каркас і ін.).

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

Артефакт - це реалізація (implementation), інтерфейс (interface) і схема розго­ртання (deployment) компонента.

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

Для опису компонентів, як правило, застосовуються мови об'єктно-орієнтованого програмування, зокрема Java, у якій поняття інтерфейсу і класу - базові, використовуються в моделях JavaBeans і Enterprise JavaBeans і в об'єктній моделі CORBA [14].

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

Розгортання - це виконання фізичного файлу відповідно до конфігурації (ве­рсії), з урахуванням параметрів запуску системи.

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

Компонент описується мовою програмування, не залежить від операційного середовища (наприклад, від середовища віртуальної машини Java) і від реальної платформи (наприклад, від платформ у моделі CORBA), де він буде функціонувати.

Типи компонентних структур. Розширенням поняття компонента є шаблон (паттерн) - абстракція, що містить у собі опис взаємодії сукупності об'єктів у зага­льній кооперативній діяльності, для якої визначені ролі учасників і їхня відповіда­льність. Шаблон є повторюваною частиною програмного елемента або схемою вирішення проблеми.

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

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

Каркас типу «біла скринька» містить у собі абстрактні класи для зображення об'єктів і їх інтерфейсів. При реалізації ці класи трансформуються в конкретні кла­си 3 указівкою відповідних методів реалізації. Використання такого типу каркаса є характерним для ООП.

Для каркаса типу «чорна скринька» у його видиму частину виносять точки, що дозволяють змінювати входи і виходи.

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

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

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

Перший тип інтерфейсу — домашній (Home interface) забезпечує керування екземплярами компонента з обов'язковими реалізаціями методів пошуку, створення і видалення окремих екземплярів.

До другого типу належать функціональні інтерфейси (function interface), що забезпечують доступ до реалізації компонента. Фактично з кожним екземпляром зв'язаний свій функціональний інтерфейс.

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

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

- сервери компонентів;

- контейнери компонентів;

- реалізації функцій, подані як екземпляри усередині контейнерів;

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

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

- компонентне застосування, подане як сукупність компонентів.

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

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

Композиція (інтеграція) компонентів і розгортання не залежать від ЖЦ роз­робки компонентів, заміна будь-якого компонента на новий компонент не повинна призвести до перекомпіляції або пере настроювання зв'язків у ПС.

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

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

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

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

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

Повторне використання в компонентному програмуванні - це застосування готових порцій формалізованих знань, здобутих під час попередніх реалізацій ПС, у нових розробках систем [13-15].

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

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

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

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

Методологія компонентної розробки ПС. Створення компонентної системи починається з аналізу ПрО і побудови концептуальної моделі, на основі якої ство­рюється компонентна модель (рис. 5.6).

 

Рис. 5.6. Схема побудови ПС із компонентів, взятих з Інтернету

 

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

Готові компоненти беруться, наприклад, з репозитаріїв у Інтернеті і викорис­товуються при створенні програмних систем, технологія побудови яких описується наступними етапами ЖЦ.

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

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

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

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

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

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

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

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

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