Основні ідеї компонентної розробки

↑

▷ Содержание

⇐ ПредыдущаяСтр 9 из 33Следующая ⇒

Парадигма ООП і пов'язана з нею концепція «повторного використання» (reuse) стимулювали розвиток компонентного програмування)

Компонентна розробка (CBSE, від Component based software engineering або CBD, від Component-based development) – сучасний напрям в програмній інженерії, в основі якого лежить індустріальний підхід до створення програмних систем - «не з нуля», а шляхом швидкої збірки з готових програмних компонентів.

Головна задача CBSE – ґрунтуючись на знанні властивостей окремих компонентів, що інтегруються, гарантувати передбачуваність властивостей системи. CBSE узагальнює ідеї об'єктно-орієнтованої парадигми, повторного використання, абстрактної архітектури, формальних специфікацій і базується на концепціях компоненту (component), інтерфейсу (interface), контракту (contract), компонентної моделі (component model), компонентного каркасу (component framework), композиції (composition) і сертифікації (certification).

Схематично опис моделі компонентної системи подано на рис. 4.1 і стисло прокоментовано далі.

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

Компонентна програмна система ґрунтується на невеликій кількості компонентів різних типів (5), кожний з яких має спеціалізовану роль в системі і описується інтерфейсом (2). Компонентна модель (6) утворена множиною типів компонентів, їх інтерфейсів, а також специфікацією допустимих шаблонів (паттернів) взаємодії типів компонентів. Компонентний каркас (7) забезпечує множину сервісів (8) для підтримки функціонування компонентної моделі. У багатьох відношеннях компонентні каркаси подібні спеціалізованим операційним системам, хоча вони оперують на більш високих рівнях абстракції і мають більш обмежений діапазон механізмів координації взаємодії компонентів.

Рис. 4.1. Загальна модель компонентної системи

Компонентний підхід дає такі переваги при розробці ПС:

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

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

- економія часу виходу на ринок ПС завдяки тому, що ключові архітектурні рішення можуть бути «вбудовані» в компонентну модель і каркас;

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

Найбільш важливий аспект CBSE – передбачуваність композиції взаємодіючих компонентів і каркасів. Можливі три основні види композицій в ПС:

– «компонент-компонент» (взаємодія по контрактах прикладного рівня, яка визначається під час розробки (раннє зв’язування) або під час виконання (пізнє зв’язування);

– «каркас-компонент» (взаємодія між компонентом і іншими компонентами каркаса по контрактах системного рівня із забезпеченням управління ресурсами);

– «каркас-каркас» (взаємодія між компонентами, які розгортаються в гетерогенних середовищах (каркасах) по контрактах інтероперабельного (interoperation) рівня).

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

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

інформаційну частину - опис призначення, дати виготовлення, умов застосування (ОС, платформа тощо) та можливостей повторного використання;

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

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

– переносимість (мобільність) – здатність працювати на різних платформах;

– інтегрованість – здатність до об'єднання з іншими компонентами в складі ПС;

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

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

Специфікація інтерфейсу може виконуватися засобами API (Application Programming Interface) мови програмування або на мові специфікації інтерфейсу (не залежному від мови програмування) - Interface Definition Language (IDL).

Сучасні мови програмування, наприклад, Java, мають розширення, спеціально призначені для специфікації поведінки: iContract, JML (Java Modeling Language), Jass (Java with assertions), Biscotti, and JINSLA (Java INterface Specification LAnguage). Можуть використовуватися також методи (мови) VDM (VDM++), Z (OOZE, Object-Z). Всі вони забезпечують опис послідовності виконання операцій безвідносно до часу. Для опису синхронізації операцій в розподілених і паралельних системах можуть використовуватися, наприклад, Object Calculus, CSP (Communicating Sequential Processes), Piccola, а для специфікації не функціональних атрибутів - NoFun.

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

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

Компонентна модель пропонує:

- стандарти по типах компонентів (наприклад, проекти, форми, COBRA-компоненти, RMI-компоненти, стандартні класи-оболонки, бази даних, JSP-компоненти, сервлети, XML-документи, DTD-документи і т.п., які визначені у відповідних мовах програмування);

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

- угоди про зв’язування компонентів з ресурсами (сервісами, що надаються каркасом або іншим компонентом, розгорненим у цьому каркасі). Модель описує, які ресурси доступні компонентам, як і коли компоненти зв'язуються з цими ресурсами. Каркас, у свою чергу, розглядає компоненти як ресурси, що підлягають управлінню.

Найбільш відомі компонентні моделі - COM (Component Object Model) (DCOM – розподілена компонентна модель, COM+), CORBA, Java Beans,.Net Framework.

1. Component Object Model (COM) – початковий стандарт Microsoft для компонентів. Визначає протокол для конкретизації і використання компонент усередині процесу, між процесами або між комп'ютерами. Основа для ActiveX, OLE і багатьох інших технологій. Може використосуватися в Visual Basic, C++ і ін.

2. Java Beans – стандарт Sun Microsystems для компонентів (тільки для Java)

3. CORBA (стандарт OMG, має громіздкий IDL-інтерфейс, складність відображення однієї мови реалізації в іншу).

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

Тривалість успіху компонентної інженерії буде обумовлена доступністю високоякісних програмних компонентів і довірою споживачів до якості компонентів, які вони купують, що, у свою чергу, може бути забезпечено шляхом сертифікації компонентів. Сертифікації підлягають окремі компоненти, каркаси і сама компонентна система. Проте існує залежність властивостей системи від властивостей компонентів, що сертифікуються, і, чим більше ця залежність, тим більш значущими будуть результати сертифікації компонентів. При 100% упевненості взагалі відпаде необхідність сертифікувати систему. Вона буде «правильною» за визначенням (принаймні, в контексті певних властивостей, по яких встановлена залежність). У відсутності 100% упевненості проблема сертифікації системи переходить в площину прогнозів і обґрунтовувань композицій компонентів в умовах існуючої невизначеності.

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

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

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

Познавательные статьи:



Техника нижней прямой подачи мяча

Комплекс физических упражнений для развития мышц плечевого пояса

Стандарт Порядок надевания противочумного костюма

Общеразвивающие упражнения без предметов