ПЗ АСУ ТП_Гузнин / Лк8
.docПЗ АСУ ТП
Тема 3.1. Загальні відомості про компонентну побудову програм.
Лекція 8.
Загальні відомості про компонентну побудову програм
-
Вступ в компонентну модель побудови програмного забезпечення.
-
Огляд технологій COM/DCOM, CORBA, SOAP, основні властивості, переваги та недоліки.
-
Вступ в компонентну модель побудови програмного забезпечення.
Велика кількість сучасних програмних систем реалізує принцип так званої «відкритої архітектури». Характерною особливістю цього підходу є можливість розширення функцій системи без безпосередньої участі розробника (без початкових кодів і необхідності перекомпіляції). Від розробника потрібно лише документування програмного інтерфейсу.
Способів реалізації принципу «відкритої архітектури» існує велика кількість. Більшість з цих способів можна поділити на наступні умовні групи:
1. Розширення за рахунок зовнішніх бібліотек функцій.
2. Завантаження «активних модулів розширення» (plug - ins технологія).
3. Використання технології «клієнт-сервер» для забезпечення доступу до даних і інтеграції програм (приклад, програми MS Office);
4. Компонентна модель архітектури і відкритий для виправлення сценарій зборки системи, що описує схему передачі управління і даних між компонентами.
Перші три способи мають один загальний недолік - це висока міра залежності від інформаційної і функціональної схеми (архітектура) базової системи. Компонентна модель покликана дозволити цю і інші проблеми, оскільки являється загальнішій і універсальний по відношенню до інших способів організації систем з «відкритою архітектурою».
Призначення:
1. Підтримка принципу «відкритої архітектури».
2. Забезпечення зручності колективної розробки окремих завдань.
3. Мінімізація «жорстких зв'язків» між програмними об'єктами і структурами даних.
Характерні особливості і властивості компонентної моделі :
1. Декомпозиція системи. Кожне завдання є набором компонентів, що реалізовують усі необхідні функції для роботи цього завдання. Кожен компонент має бути максимально незалежний (як «чорний ящик» з входами і виходами). Таким чином, можна розділити колектив розробників на дві групи: перша − займається декомпозицією завдань, визначаючи які компоненти потрібні і як вони можуть бути пов'язані в системі, а друга − розробкою і відладкою безпосередньо самих компонентів.
2. Системність. На етапі розробки системи або зборки завдань в єдине програмне середовище, виділяються загальні класи компонентів, за рахунок чого можна скоротити час розробки завдань і забезпечити уніфікований діалог (наприклад, зовнішній вигляд призначеного для користувача інтерфейсу, єдиний вид відображення графічних примітивів).
3. Поліморфізм. У вже зібраній системі можна підмінити деякі компоненти на інші, відповідні по структурі, але що відрізняються внутрішньою реалізацією. Ця властивість дозволяє якісно змінювати функціональність системи, не зачіпаючи її структурну схему організації взаємодії між компонентами і завданнями. Зручно також на початковій стадії колективної розробки (коли ще не створені деякі основні компоненти) замінювати бракуючі компоненти компонентами-заглушками або не повнофункціональними компонентами, що відповідає принципу «поступового нарощування функціональності» складної програмної системи.
4. Адаптація. Набір компонентів, що входять в систему, і зв'язки між ними можуть бути змінені залежно від вирішуваної задачі. Адаптація під завдання проводиться на етапі зборки системи і може бути як автоматичної, так і ручної, здійснюваної за допомогою спеціальної мови інтеграції компонентів.
Компонентна модель організації системи включає наступні об'єкти:
1. Компонент - програмний об'єкт, що містить безліч властивостей і методів, доступ до яких уніфікований і здійснюється по іменованих індексах (список усіх індексів компонента також доступний). Компоненти об'єднуються у бібліотеки.
2. Ядро - призначено для запуску системи і містить:
1) інтерпретатор сценарію зборки компонентів (адаптації), описаного за допомогою мови інтеграції (адаптації);
2) функції для завантаження компонентів з бібліотек;
3) менеджер «загальної» пам'яті.
3. Мова інтеграції (адаптації) компонентів системи призначена для опису сценарію зборки системи і визначення зв'язків між компонентами.
Достоїнства:
1. Гнучка система інтеграції окремих завдань в єдиному операційному просторі. Реалізація різних компонент інваріантна до процесу їх асемблювання і адаптації під конкретні завдання.
2. Декомпозиція завдання на безліч дрібних підзадач, з урахуванням властивості системності (див вище), тобто ефективніший розподіл завдань між членами груп програмістів і розробників, спрощення процесу відладки.
3. Одного разу створені і відлагоджені компоненти можуть бути легко (без змін і перекомпіляції) перенесені в нові проекти, де вони увійдуть до нової системи зв'язків, схеми функціонування і інформаційного обміну з іншими компонентами. І навпаки, відлагоджений сценарій зборки може бути використаний як основа нового проекту з новими або допрацьованими функціональними можливостями (див. поліморфізм).
4. Можливість проектування системи за принципом від «простого до складного», поступово нарощуючи функціональні можливості системи і вирішуючи першочергові завдання проекту.
Обмеження і недоліки :
1. Складність опису сценарію зборки і адаптації.
2. Необхідність виконання жорстких вимог до написання окремих компонентів. В основному, це стосується вимоги максимальної незалежності реалізації від інших компонентів.
3. Зберігаються жорсткі зв'язки з платформою (апаратна частина + операційна система).
4. Для включення до складу системи раніше створених програм необхідно написати «компоненти-мости», що реалізовують мінімум необхідної програмної взаємодії.
2. Огляд технологій COM/DCOM, CORBA, SOAP, основні властивості, переваги та недоліки.
COM (англ. Component Object Model — Об'єктна Модель Компонентів) — це технологічний стандарт від компанії Microsoft, призначений для створення програмного забезпечення на основі взаємодіючих розподілених компонентів, кожен з яких може використовуватися у багатьох програмах одночасно. Стандарт утілює в собі ідеї поліморфізму і інкапсуляції об'єктно-орієнтованого програмування.
Основним поняттям, яким оперує стандарт COM, є COM -компонент. Програми, побудовані на стандарті COM, фактично не є автономними програмами, а є набором тих, що взаємодіють між собою COM -компонентів. Кожен компонент має унікальний ідентифікатор (GUID) і може одночасно використовуватися багатьма програмами. Компонент взаємодіє з іншими програмами через COM -інтерфейси — набори абстрактних функцій і властивостей. Кожен COM -компонент повинен, як мінімум, підтримувати стандартний інтерфейс «IUnknown», який надає базові засоби для роботи з компонентом. Інтерфейс «IUnknown» включає три методи: QueryInterface, AddRef, Release.
DCOM - Distributed COM заснована на технології DCE/RPC (різновиди RPC). DCOM дозволяє COM -компонентам взаємодіяти один з одним по мережі. DCOM вирішує завдання виклику методу об'єкту, розташованого на іншій машині, а також передачу посилання на об'єкт з однієї машини на іншу. Технологія DCOM забезпечує базові установки безпеки, дозволяючи задавати, хто і з яких машин може створювати екземпляри об'єкту і викликати його методи.
CORBA (Common Object Request Broker Architecture — загальна архітектура брокера об'єктних запитів) — технологічний стандарт написання розподілених застосувань. Компонентна модель CORBA (CCM) описує стандартний каркас застосування для компонент CORBA. CCM надає абстракцію сутностей, які можуть надавати і отримувати сервіси через чітко певні іменовані інтерфейси, порти.
Модель CCM надає контейнер компонентів, в якому можуть поставлятися програмні компоненти. Контейнер надає набір служб, які може використовувати компонент. Ці служби включають (але не обмежені) службу повідомлення, авторизації, персистентности і управління транзакціями. Це найбільш часто використовувані розподіленим застосуванням служби. Переносячи реалізацію цих сервісів від необхідності реалізації самим застосуванням у функціональність контейнера застосування, можна значно понизити складність реалізації власне компонентів.
Нині використовувані технології віддаленого виклику методів (DCOM, CORBA) досить складні в налаштуванні і організації взаємодії. Це спричиняє за собою проблеми в експлуатації і функціонуванні розподілених систем (проблеми безпеки, транспорт через брандмауери і так далі). Існуючі проблеми успішно вирішені створенням SOAP (Simple Object Access Protocol), простого протоколу, заснованого на XML, для обміну повідомленнями в розподілених середовищах (WWW). Він призначений для створення веб-сервісів і віддаленого виклику методів. SOAP можна використовувати з різними транспортними протоколами, включаючи HTTP, SMTP і так далі.