К. М. Лавріщева програмна інженерія підручник Київ, 2008
 Скачать 5.23 Mb.
|
|
Визначення 1. КПВ – це деяка функція з певними атрибутами, що забезпечують взаємодію з середовищем і поведінку. Визначення 2. Готовий КПВ – це сукупність методів із визначеною сигнатурою і типами даних, які передаються і повертаються після виконання відповідного методу. Визначення 3. Компонент типу КПВ – це самостійний програмний елемент, який задовольняє певні функціональні вимоги, вимоги архітектури, структури і організації взаємодії в заданому середовищі, має специфікацію, що допомагає користувачу використовувати і об'єднувати його з іншими компонентами в інтегровану систему. Визначення 4. Програмний компонент – це незалежний від мови програмування, самостійно реалізований об'єкт, який забезпечує виконання певної сукупності прикладних сервісів, доступ до яких можливий тільки за допомогою інтерфейсів, що вказують функції і порядок операцій звернення до компонента. Ці та інші визначення наведено в [1, 2, 6–11] і вони відображають різні аспекти визначення або використання компонента. Далі наведено проблематику 214 Розділ 8 інженерії компонентів з використанням різних складових елементів двох останніх визначень. Модель специфікації компонента має такий вигляд: КПВ = (T, I, F, R, S), де T – тип компонента; I – множина інтерфейсів компонента; F – функціональність компонента; R – реалізація, прихована частина – програмний код; S – сервіс для взаємодії з середовищем або набір правил розгортки. Кожний з елементів специфікації компонента являє собою видиму або приховану від користувача частину його абстракції. Залежно від складності КПВ їх можна поділити на такі групи: – прості компоненти (функція, модуль, клас та ін.); – компонент як об’єкт, що має інтерфейс, функцію і реалізацію, а також можливість доповнювати свою специфікацію шаблоном розгортки й інтеграції; – готові до використання КПВ (наприклад, beans компоненти в Java, AWT– компоненти тощо); – складні КПВ типу каркасів, патернів з елементами групування декількох простих КПВ в структуру, де вони взаємодіють, забезпечуючи розв’язки певної задачі в межах системи. Наявність великої кількості готових компонентів вимагає від розробників і користувачів визначення метаінформації про те, які класи сумісні з семантичними обмеженнями, явно визначеними в специфікації КПВ. Метаінформація містить у собі інформацію щодо: – інтерфейсів, які реалізують компоненти; – механізмів повторного використання; – середовища розгортки компонента; – сервісу, підтримуваного компонентом; – ролей, які виконують компоненти в системі; – формалізованих мов опису КПВ. Сучасна технологія застосування КПВ базується на таких особливостях: – відображення здатності КПВ аналізувати самих себе і надавати свої можливості динамічно під час виконання, а не під час компіляції, тобто керувати більшістю властивостей, подій і методів, вбудованих в компонент; – стандартизований опис компонента для зручного аналізу і розуміння його сторонньою особою, а не самим розробником; – здатність компонента до трансформації із збереженням функцій, але з можливою зміною структури і початкового коду; – збереження параметрів конфігурації (шаблонів налагодження) у постійній пам'яті для повторного використання; – реєстрація повідомлень про події, одержані від інших об'єктів через посилання (наприклад, EJB-компоненти в JAVA), – групування компонентів у архіви (наприклад, JAR-файли) для подальшого повторного використання як сукупності; – використання компоненту в різних мовних середовищах; – адаптація КПВ до різних контекстів використання, виділення властивостей, які заважають повторному використанню та модифікація. Компоненти, на відміну від об'єктів ООП, можуть змінюватися і поповнюватися новими функціями і інтерфейсами. Вони конструюються у вигляді Розділ 8 215 деякої програмної абстракції, що складається з трьох частин: інформаційної, зовнішньої і внутрішньої. Інформаційна частина містить у собі такі відомості: призначення, дата виготовлення, умови застосування (ОС, платформа і т.п.), можливості КПВ, тип середовища оточення та ін. Зовнішня частина – це інтерфейс, який визначає взаємодію компонента із зовнішнім середовищем і з платформою, на якій він виконуватиметься, і має такі характеристики: – інтероперабельність – здатність взаємодіяти з компонентами інших середовищ; – переносність – здатність компонента виконуватися на різних комп'ютерних платформах; – інтеграційність – об'єднання компонентів за допомогою інтерфейсів у більш складні структури ПС; – нефункціональні вимоги, а саме, вимоги до безпеки, надійності і захисту компонентів і даних. Внутрішня частина компонента – це програмний код, системна або абстрактна структура (табл. 8.1). Ця частина компонента складається з: – інтерфейсу (interfaces); – реалізації (implementation); – схеми розгортки (deployment). Таблиця 8.1.Характеристики частин компонента Частини структури компонента Інтерфейс Реалізація Схеми розгортки Один або декілька Унікальність іменування Клієнтський або серверний Сигнатура опера- цій Методи взаємодії Одна або декілька Орієнтація на платформу і середовище Вибір конкретної реалізації Підтримка інтерфей- сів компонента Типовість процедури розгортки Конфігурація Керованість Настроювання на операційне середовище Модифікація І нтерфейс компонента містить у собі звернення до інших компонентів через описані параметри засобами мов IDL або APL. У ньому вказуються типи даних і операції передачі параметрів для взаємодії компонентів один з одним. Кожен компонент може реалізовувати цілу сукупність інтерфейсів. Інтерфейс – видима незмінна і обов'язкова частина специфікації компонента. Наприклад, система Inspector Components змінює деякі параметри інтерфейсу компонента без втручання в його код. Параметри інтерфейсу визначаються типом КПВ і відповідають специфікації, де зазначаються типи і імена компонентів, їхні вхідні і вихідні параметри, методи компонентів та ін. У мові JAVA, наприклад, типами компонентів можуть бути: проекти, форми (AWT-компоненти), beans-компоненти, компоненти Enterprise Java Beans, CORВA-компоненти, RMI-компоненти, стандартні класи-оболонки, JSP- компоненти, сервлети, XML-документи, DTD-документи і т.п. 216 Розділ 8 Реалізація – це код, який використовується при зверненні до операцій, визначених в інтерфейсах компонента. Компонент може мати декілька реалізацій, наприклад, залежно від операційного середовища або від моделі даних і відповідної системи керування базами даних, яка необхідна для функціонування компонента. Розгортка – це фізичний файл або архів, готовий до виконання, який передається користувачеві і містить у собі всі необхідні операції та інструкції для створення, настроювання і функціонування компонента. Опис компонентів не залежить від операційного середовища і від реальної платформи, де він має функціонувати (наприклад, XML, DSL-опис). Розширенням поняття компонента є каркас та патерн. Каркас являє собою абстракцію високого рівня в ПС. Суть цього поняття полягає у відділенні функціональності компонентів від задач керування ними. Іншими словами, функціональність компонентів — це бізнес–логіка, каркас не відповідає за правильну і надійну взаємодію компонентів, а також за забезпечення безпеки, вимог й т.п. Фактично каркас поєднує множину взаємодіючих між собою компонентів, що розгортаються у деякому інтегрованому середовищі для виконання кінцевої мети ПрО. Патерн є абстракція, що містить у собі опис взаємодії сукупності об'єктів або компонентів у спільній кооперативній діяльності, для якої визначені ролі учасників і розподілена їхня відповідальність. Патерн можна подати повторюваною частиною програмного елемента у вигляді схеми чи взаємозв'язків контекстного опису вирішення проблем ПрО. Він фіксує узагальнене розв’язання для спілкування з замовником, а також забезпечує повторне використання досвіду про відомі проблеми, які раніше передавалися моделлю ПрО. Крім того, КПВ можуть бути і моделі ПрО. 8.1.2. Репозітарій компонентів КПВ та інші компоненти багаторазового застосування розміщуються в різних сховищах. Ними можуть бути бібліотеки, репозитарії компонентів і ресурсів в Інтернеті (наприклад, GreedStone, Matlab, бібліотека класів С++ і ін.). Компонентами цих сховищ можуть користуватися багато разів усі бажаючі для реалізації своїх цілей, зокрема, при побудові програмних систем різного призначення. Репозітарії типу бібліотеки GreenStone і Matlab надають величезну кількість готових програм наукового, зокрема математичного, типу, тобто вони орієнтовані на математиків, фізиків і інших фахівців предметних областей. У загальному випадку репозитарій – це система засобів для зберігання, поповнення напрацьованих КПВ, що містить у собі інфраструктуру розробки ПС з компонентів, організацію доступу до КПВ, які розташовані в ньому, для подальшого їхнього застосування в нових проектах. З функціональної точки зору репозитарій працює за принципом інформаційно-пошукової системи, об'єктами зберігання якої є різні типи документів, текстів та ін. Система ставить запит користувача відповідо до ключових понять, слів, правил доступу, що містяться в колекції документів. Загальна структура репозитарія для деякої предметної області зображена на рис. 8.1. Розділ 8 217 Рис. 8.1. Структура репозитарію для ПрО Розділи репозитарію, що орієнтовані на використання в інженерії КПВ та інженерії ПрО, пропонуються такі: – компоненти КПВ; – засоби безпеки, захисту та змінювання для КПВ; – аспекти опису специфіки представників сімейства систем; – засоби підтримки взаємодії, синхронізації компонентів; – нові елементи сімейства ПрО; – сервіси для членів сімейства тощо. На відміну від систем пошуку інформації в репозитарії компонентів, окрім КПВ, розміщується семантична інформація у вигляді пошукового образу, створеного на основі опису інформаційної моделі кожного компонента. Ця модель – засіб побудови пошукового образу для каталогу КПВ, орієнтованого на осмислення людиною функцій КПВ і можливості їхнього зіставлення з власними потребами. Пошуковий образ готових компонентів в репозитарії може містити у собі: – список ключових слів, що найчастіше згадуються в тексті КПВ; – посилання на заздалегідь побудовану онтологію домену проблемної області, до якої цей КПВ належить. Інформаційну потребу щодо КПВ формулює користувач у вигляді пошукового запиту, який зіставляється зі описом пошукового образу КПВ, що зберігається у репозитарію. Пошук КПВ відповідно до заданого запиту виконується доти поки не буде знайдено потрібний КПВ або користувач не одержить велику кількість релевантних запиту компонентів для відбору потрібних. Їхньому розгляду допомагає онтологічна, понятійна база репозитарію, яка містить у собі інформаційну модель кожного КПВ з узгодженою і уніфікованою термінологію, з вказівками на відношення між поняттями і їх інтерпретаціями, а також ключовими словами тощо. Інформаційна модель КПВ забезпечує систему зберігання, пошуку і зіставлення КПВ у репозитарію, якій поділено на розділи відповідно до окремих ПрО, перелік яких є класифікатором першого рівня. Класифікаторами наступних рівнів можуть бути окремі поняття ПрО. Цей образ може містити у собі паспортні дані компонента (ім'я і адресу розробника, спосіб придбання, ціну і т.п.), відомості про середовище реалізації (ОС, МП, СКБД і т.п.), опис апаратних ресурсів, імена ПрО в системі класифікації, а також опис нефункціональних вимог до системи (безпека, конфіденційність, показники якості системи та ін.). 218 Розділ 8 Розділи репозитарію заповнюються відповідно до класифікації КПВ щодо різних предметних областей. Сутність будь–якої класифікації полягає у розбитті множини елементів на кілька класів еквівалентності згідно з класифікаційними характеристиками і ознаками. Класи еквівалентності не перетинаються і усі елементи конкретного класу мають відповідні ознаки. Для однієї і тієї ж множини може існувати декілька систем класифікації, кожна з них залежить від вибраних базових ознак і способів групування їх у класифікаційні характеристики (наприклад, програмна інженерія як наука якісного виробництва). Основою такої системи є інформація, що супроводжує компоненти, та правила впорядкування відповідно певним ознакам – функціональність, системне середовище, ресурс тощо. Система класифікації компонентів не існує, тому її побудова для компонентів засновується на загальних знаннях про компоненти та їх застосування. Ці знання розподіляються серед таких груп загальних властивостей компонентів, як структурні ознаки, функціональні можливості, характеристики поведінки. Класифікація компонентівуніфікує подання інформації про компоненти для подальшого пошуку і відбору їх з середовища репозитарію. Вона відбувається з урахуванням таких ознак: – приналежність до ПрО; – тип компонента (модуль, клас та ін.); – наявність інтерфейсу в КПВ; – готовність КПВ до застосування; – складність КПВ (каркас, патерн, контейнер тощо). Фізичне розміщення кодів КПВ в репозитарії виконується в каталозі, де розміщуються імена і посилання на місце розміщення самого коду. Вибрані компоненти з репозитарію настроюваються на умови середовища функціонування майбутньої системи. Інформаційна модель пошукового образу спрощує пошук необхідних КПВ і скорочує терміни розроблення ПС за рахунок: – відображення базових функцій і понять компонента; – приховування представлення даних, операцій оновлення і отримання доступу до цих даних; – обробки виняткових ситуацій, що відбувається в процесі виконання та ін. Розробка нових ПС може здійснюватися за технологією з використанням розроблених звичайних компонентів (КОМ 1 , …, КОМ k ) та КПВ (рис. 8.2). Наведені шляхи розроблення, накопичення, вибору та інтеграції КПВ визначають типову технологію розроблення ПС з компонентів та КПВ, коли вони подані у різних МП. Якщо компоненти написано на різних МП, то в процесі створення деякої унікальної системи для сімейства ПрО формуються спеціальні інтерфейсні модулі (Int 1 , ..., Int k ), які виконують функції перетворення нерелевантних (невідповідних значенням) типів даних для значень, що передаються між компонентами системи, які взаємодіють [2]. Шляхи технології інтеграції компонентів такі: 1. Розроблення компонентів (КОМ) на мові. 2. Відбір готових компонентів – КПВ. 3. Розроблення інтерфейсів – Іnt для КОМ. Розділ 8 219 Середовище інтеграції компонентів КОМ 1 Int 1 КОМ 2 КОМ 3 Int 2 Int 3 КОМ 4 КОМ 5 Int k ... КОМ i КОМ j Рис.8.2. Інтеграція компонентів на різних МП у середовищі 4. Генерація інтерфейсів пари КОМ на МП. 5. Розроблення середовища та репозитарію КОМ. 6. Типізація компонентів. 7. Тестування КОМ, інтерфейсів, КОМ-систем. 8. Інтеграція компонентів. 9. Розгортання КОМ-системи у середовищі . 10. Супровід компонентної системи. Дані шляхі охоплють процеси розроблення систем із різних компонентів, їх накопичення, тестування та інтеграція у компонентну структуру зі створенням в ній додаткових інтерфейсних модулів int для кожної пари різномовних компонентів. 8.1.3. Мова опису інтерфейсу компонентів Для об'єднання компонентів у ПС необхідною умовою є наявність для них формально визначених інтерфейсів у сучасних мовах IDL або APL, а також механізмів динамічного контролю зв'язків між компонентами. Специфікація інтерфейсу в API і IDL містить у собі опис функціональних властивостей компонентів, їхніх типів і порядку завдання операцій передачі аргументів і результатів для взаємодії компонентів. Описом інтерфейсу може бути інтерфейсний модуль між двома компонентами. Інтерфейси ПС, що побудована з компонентів і призначена для функціонування в розподіленому середовищі, мають деякі особливості. Така система складається з двох частин, кожна з яких може виконуватися в різних процесах і взаємодіяти одна з одною через виклик інтерфейсних функцій. Перша частина – серверна програма, а друга – клієнтська (далі просто сервер і клієнт). У функції інтерфейсного модуля клієнта входять: 220 Розділ 8 – підготовка зовнішніх даних (параметрів) для клієнта ; – набір викликів цих процедур або звернень до сервісу сервера; – обробка різних помилок, повернення даних від сервера до клієнта. Загальні функції інтерфейсного модуля сервера містять у собі: – очікування повідомлень клієнта і їхню обробку; – запуск віддаленої процедури і передачу їй параметрів клієнта; – повернення результатів процедури клієнту, знищення віддаленої процедури та ін. Структура інтерфейсного модуля не залежить від МП взаємодіючих об'єктів і в цілому однакова для всіх. Це пов'язано із стандартизованою його структурою і спільною мовою специфікації інтерфейсу, синтаксис якого подано нижче у формі Бекуса–Наура: <інтерфейс об’єкта> ::= оbject <ім’я_Об’єкта> :{<множина початкових інтерфейсів>};{<множина вхідних інтерфейсів>} end; <множина вхідних інтерфейсів> ::= <множина інтерфейсів>; <множина вихідних інтерфейсів> ::= <множина інтерфейсів>; < множина інтерфейсів > ::= | <інтерфейс>; < множина інтерфейсів >; <інтерфейс> ::= interface <ім’я _інтерфейса>:{<множина функцій>} end; <множина функцій > ::= | <функція>; <множина функцій>; <функція> ::= function < ім’я_функції>: <множина параметрів> еnd; <множина параметрів> ::= <параметр> | <параметр>, <множина параметрів >; <параметр> ::= <тип> (<вид параметра>); <вид параметра> ::= |