Іінструментальні засоби КП

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 2.3. Загальний вигляд каркасу компонентної системи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<== попередня сторінка	\|	наступна сторінка ==>
Компонентна алгебра	\|	Технологія компонентної розробки ПС

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

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