Супровід РПС компонентній ПС характеризується наступними особливостями.

 обслуговуючий персонал РПС не має доступу до коду компонентів.

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

 окремі компоненти, що застосовуються у РПС, можуть створюватися сторонніми розробниками, тому провадиться власна політика щодо підтримки, вдосконалення, розвитку таких компонентів.

До основних процесів на цьому етапі відносяться: модифікація компонентної конфігурації; адаптація нових компонентів до вимог та умов інтегрованого середовища; аналіз відказів функціонування, пошук та виправлення помилок у РПС; тестування РПС.

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

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

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

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

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

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

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

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

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

6) закінчене компонентне РПС чи деяке застосування, представлене як компонентна програма.

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

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

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
ЖЦ проектування ПС із типових компонентів та КПВ	\|	Парадигма аспектно-орієнтованого програмування

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.004 сек.