Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Основні ідеї компонентної розробки
Парадигма ООП і пов'язана з нею концепція «повторного використання» (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-бібліотек), проблема розробки розподілених застосувань і ін. Основна ідея компонентної парадигми - розповсюдження класів в бінарномувигляді (тобто не у вигляді початкового коду) і надання доступу до методів класу через чітко визначені інтерфейси, що дозволяє зняти проблему несумісності компіляторів і забезпечує зміну версій класів без перекомпіляції компонентів.
|
|||||||
Последнее изменение этой страницы: 2017-02-21; просмотров: 663; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.22.171.136 (0.008 с.) |