|
|
Скачати 76.85 Kb.
|
|
Розробка КПВ - компонентів повторного використання Модель інтерфейсу 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). Операції компонентної алгебри реалізовані в системі ГП для оброблення компонентів або КПВ у репозиторію, а також на фабрики програм в технології зборки КПВ. ЖЦ побудови компонентної системи
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 |