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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5. Парадигма аспектно-орієнтованого програмування

Підхід до розроблення програм, близький до аспектно-орієнтованого програмування (АОП), був запропонований ще в 1970 році в СРСР проф. А.Л. Фуксманом (Ростовський університет) і названий технологією розосереджених дій – РД-технологією (або технологією вертикального шарування) [1]. Відповідно до цієї технології вертикальний шар (зріз) містить сукупністю розосереджених дій, фрагментів коду, які реалізують певну розширювальну функцію, а процес розроблення і модифікації програми являє собою послідовність операцій додавання або зміни розширювальних функцій.

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

Концепцію вертикальних шарів А.Л.Фуксман поклав в основу нової стратегії поетапного розроблення програм. Згідно цієї концепції на першому етапі створюється «основа» – максимально спрощена версія програми, що залишається після видалення з неї всіх вертикальних шарів. Потім, на подальших етапах (транзакціях) реалізуються і додаються до програми, яка таким чином розширюється, все нові і нові вертикальні шари. З технологічної точки зору помітна перевага даної стратегії полягає в тому, що при налагодженні будь-якої проміжної (без деяких вертикальних шарів) версії програми не потрібні «заглушки» – імітатори відсутніх частин, без яких не можуть обійтися відомі стратегії розроблення «згори-вниз» або «знизу вгору».

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