Компонентна алгебра


Скачати 76.85 Kb.
НазваКомпонентна алгебра
Дата09.05.2013
Розмір76.85 Kb.
ТипДокументи
bibl.com.ua > Інформатика > Документи
Розробка КПВ - компонентів повторного використання
Модель інтерфейсу

CInt = (IntName, IntFunc, IntSpec),

де IntName – ім'я інтерфейсу, IntFunc – ім'я функції, IntSpec - специфікатор інтерфейсу.


Модель компонентного середовища


CE = (NameSpace, IntRep, ImpRep, CServ, CServImp),

де
NameSpace = {CNamem} – безліч імен компонентів;
IntRep = {IntRepi} – репозитарий інтерфейсів компонентів;
ImpRep = {ImpRepj} – репозитарий реалізацій;
CServ = CServr} – інтерфейс безлічі сервісів;
CServImp = {CServImpr} – безліч реалізацій сервісів.


Компонентна алгебра -

 = 1  2 = {CSet, CESet, 1, 2}
Зовнішня
Зовнішня алгебра: 1 = { CSet, CESet, 1}.

Операції алгебри W1= { CE1 , CE2, CE3 , CE4}:

1. інсталяції (розгортання) CE = Comp Å CE1


2. об'єднання компонентних середовищ CE3 = CE1 È CE2


3. видалення компонента із середовища
CE2 = CE1 \ Comp

4. заміни компонента Comp1 на Comp2 ,
CE2 = Comp2 Å (CE1 \ Comp1).
Внутрішня алгебра: 2 = {CSet, CESet, 2}.

ОпераціїОперації алгебри: 2 = {Оrefac, Oreing, Orevers},

МодельМодель рефакторингу компонентів:
Мrefac = {Orefac, {CSet = {NewCompn}},

операції

Оrefac = {AddOImp, AddNImp, ReplImp, AddInt}.

МодельМодель реінженерії компонентів:
МReing = {Oreing, {CSet = {NewCompn}},

операції

Oreing = {rewrite, restruc, adop, supp, conver }.
 

Модель реверсної інженерії компонентів:

Мrevers = {Orevers , {CSet = {NewCompn}},

операції Orevers = {visual, design, destruct, rewrite).

Операції компонентної алгебри реалізовані в системі ГП для оброблення компонентів або КПВ у репозиторію, а також на фабрики програм в технології зборки КПВ.
ЖЦ побудови компонентної системи


  1. Аналіз предметної області для декомпозиції на підсистеми і відокремлення окремих функцій майбутній системи для їх подання окремими компонентами або пошук готових за такими функціями.

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

3. Розроблення вимог (Requirements) до ПС – це формування й опис функціональних, нефункціональних і інших властивостей ПС.

4. Аналіз поведінки (Behavioral Analysis) ПС полягає у визначенні функцій системи, деталей проектування і методів їхнього виконання.

5. Специфікація інтерфейсів і взаємодій компонентів (Interface and Interaction Specification) віддзеркалює розподіл параметрів компонентів для завдання інтерфейсів і взаємодії компонентів через потоки дій або робіт (workflow).

6. Інтеграція набору компонентів і КПВ (Application Assembly and Component Reuse) у єдине середовище ґрунтується на підборі й адаптації КПВ, визначенні сукупності правил, умов інтеграції (зборки) і побудові конфігурації системи.

7. Тестування компонентів (Components Testing) ґрунтується на методах верифікації і тестування для перевірки правильності як окремих компонентів і КПВ, так і інтегрованої з компонентів програмної системи.

8. Розгортання (System Deployment) містить у собі оптимізацію плану компонентної конфігурації з урахуванням середовища, розгортання окремих компонентів і створення цільової компонентної конфігурації для функціонування ПС.

9. Супровід ПС (System Support and Maintenance) складається з аналізу помилок і відмов при функціонуванні ПС, пошуку і виправлення помилок, повторного її тестування й адаптації нових компонентів до вимог і умов інтегрованого середовища.

Технологія оброблення КПВ це процеси:

– опису КПВ мовами програмування;

– специфікації інтерфейсів КПВ (IDL, XML, Icontract, SIDL…);

– інженерія розроблення доменів, сімейств програм і систем – СПС;

– зборки






    • компонентів із КПВ готових програм і систем;




Типи компонентних структур

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

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

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

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

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

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

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

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

До компонентів середовища відносяться:

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

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

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

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

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

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

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

До архітектура компонентноїї системи віднесені:

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

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

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

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

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

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

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

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

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

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

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

Схожі:

АЛГЕБРА
Самостійні і контрольні роботи складені за посібником “А. Капіносов. Дидактичні матеріали. Алгебра, 8 клас”, рекомендованим Міністерством...
АЛГЕБРА
Самостійні і контрольні роботи складені за посібником “А. Капіносов. Алгебра. 7 клас. Систематичний курс”, рекомендованим Міністерством...
Тест : Повторення за курс 7 класу, алгебра

7-й клас. АЛГЕБРА
Розв'язування задач за допомогою лінійних рівнянь. Рів­няння як математична модель задачі
8-й клас. АЛГЕБРА
Розпізнає цілі раціональні вирази, дробові раціональні ви­рази, наводить приклади таких виразів
Шкіяь М.І., Сяєпкань З.І., Дубинчук О. С. Алгебра і початки аналізу:...
На вивчення розділу «Комбінаторика» в 11-му класі загальноосвітньої школи за програмою відводиться 8 годин
Сума та перетин пiдпросторiв, розклад в пряму суму, фактор-простори”
Алгебра і теорія чисел” I курсу, проведене 03. 03. 2008 студентом-практикантом VI курсу
9-й клас. АЛГЕБРА
Нерівності зі змінними. Лінійні нерівності з однією змін­ною. Розв'язок нерівності
8-й клас. Алгебра
Цілі вирази. Тотожні вирази. Тотожність. Степінь з натуральним показником і його властивості. Одночлени і многочлени та дії над ними....
Лінійна алгебра та аналітична геометрія” Завдання 1
Завдання Знайти відстань від точки М0 до площини, що проходить через точки М1, М2, М3
Додайте кнопку на своєму сайті:
Портал навчання


При копіюванні матеріалу обов'язкове зазначення активного посилання © 2013
звернутися до адміністрації
bibl.com.ua
Головна сторінка