Анотація: Розглядаються основні поняття компонентних технологій розробки ПЗ і поняття компонента. Розповідається про загальні принципи розробки розподіленого ПО і про організацію взаємодії його компонентів в рамках RPC і транзакцій.
Основні поняття компонентних технологій
Поняття програмного компонента (software component) є одним з ключових в сучасній інженерії ПО. Цим терміном позначають кілька різних речей, часто не уточнюючи якого мається на увазі в кожному конкретному випадку сенсу.
- Якщо мова йде про архітектуру ПО (або веде її архітектор ПО), під компонентом мається на увазі те саме, що часто називається програмним модулем. Це досить довільний і абстрактний елемент структури системи, певним чином виділений серед оточення. вирішальний деякі підзадачі в рамках загальних завдань системи і взаємодіє з оточенням через певний інтерфейс. У цьому курсі для цього поняття вживається термін архітектурний компонент або компонент архітектури.
- На діаграмах компонентів в мові UML часто зображуються компоненти, які є одиницями збірки і конфігураційного управління, - файли з кодом на якійсь мові, бінарні файли, будь-які документи, що входять до складу системи. Іноді там же з'являються компоненти, що представляють собою одиниці розгортання системи, - це компоненти вже в третьому, наступного сенсі.
- Компоненти розгортання є блоками, з яких будується компонентне програмне забезпечення. Ці ж компоненти маються на увазі, коли говорять про компонентних технологіях, компонентної або компонентно-орієнтованої (component based) розробці ПО, компонентах JavaBeans. EJB. CORBA, ActiveX, VBA, COM, DCOM. Net, Web-службах (web services), а також про компонентний підході, згадані в назві даного курсу. Згідно [1]. такий компонент являє собою структурну одиницю програмної системи, що володіє чітко визначеним інтерфейсом. який повністю описує її залежності від оточення. Такий компонент може бути незалежно поставлений або не поставлений, доданий до складу деякої системи або видалений з неї, в тому числі, може включатися до складу систем інших постачальників.
Різниця між цими поняттями, хоча і досить тонке, все ж може привести до серйозного нерозуміння тексту або співрозмовника в деяких ситуаціях.
У визначенні архітектурного компонента або модуля робиться акцент на виділення структурних елементів системи в цілому і декомпозицію вирішуваних нею завдань на більш дрібні підзадачі. Подання такого компонента у вигляді одиниць зберігання інформації (файлів, баз даних та ін.) Не має ніякого значення. Його інтерфейс хоча і визначено, але може бути уточнений і розширений в процесі розробки.
Поняття компонента збірки і конфігураційного управління пов'язано зі структурними елементами системи, з якими доводиться мати справу інструментам, які здійснюють збірку і конфігураційне управління. а також людям, які працюють з цими інструментами. Для цих видів компонентів інтерфейси взаємодії з іншими такими ж елементами системи можуть бути не визначені.
У даній лекції і в більшості наступних ми будемо мати справу з компонентами в третьому значенні. Це поняття має декілька аспектів:
- Компонент в цьому сенсі - виділена структурна одиниця з чітко визначеним інтерфейсом. Він має більш суворі вимоги до чіткості визначення інтерфейсу. ніж архітектурний компонент. Абсолютно всі його залежності від оточення повинні бути описані в рамках цього інтерфейсу. Один компонент може також мати кілька інтерфейсів. граючи кілька різних ролей в системі.
При описі інтерфейсу компонента важлива не тільки сигнатура операцій. які можна виконувати з його допомогою. Стає важливим і те, які інші компоненти він може задіяти при роботі, а також яким обмеженням повинні задовольняти вхідні дані операцій і які властивості виконуються для результатів їх роботи.
Ці обмеження є так званим інтерфейсним контрактом або програмним контрактом компонента. Інтерфейс компонента включає набір операцій, які можна викликати у будь-якого компонента, що реалізує даний інтерфейс. і набір операцій, які цей компонент може викликати у відповідь у інших компонентів. Інтерфейсний контракт для кожної операції самого компонента (або використовуваної їм) визначає передумовою та постусловіем її виклику. Передумова операції повинно бути виконано при її виклику, інакше коректність результатів не гарантується. Якщо ця операція викликається у компонента, то обов'язок подбати про виконання передумови лежить на клієнті, що викликає операцію. Якщо ж ця операція викликається компонентом у іншого компонента, він сам зобов'язується виконати це передумова. З постусловіем все навпаки - постусловіем викликаної у компонента операції повинно бути виконано після її виклику, і це - обов'язок компонента. Постусловіем операції визначає, які її результати вва ються коректними. Відносно викликаються компонентом операцій виконання їх постусловіем має гарантуватися тими компонентами, у яких вони викликаються, а викликає компонент може на них спиратися в своїй роботі.
При реалізації інтерфейсу передумови операцій можуть послаблюватися, а постумови - тільки посилюватися. Це означає, що, реалізуючи дану операцію, деякий компонент може реалізувати її для більш широкого безлічі вхідних даних, ніж це потрібно передумовою, а також може виконати в результаті більш суворі обмеження, ніж це потрібно постусловіем. Однак зовнішнім компонентам можна спиратися на це, поки вони працюють з вихідним інтерфейсом. - реалізація може помінятися. Точно так же, якщо інтерфейс компонента вимагає наявності в системі інших компонентів з певним набором операцій, це не означає, що дана реалізація цього інтерфейсу дійсно викликає ці операції.
В ідеалі такий компонент може бути доданий або повністю заміщений інший реалізацією тих же інтерфейсів прямо в ході роботи системи, без її зупинки. Хоча і не всі різновиди компонентів володіють цією властивістю, його наявність визнається вкрай бажаним.
Все це означає, що такий компонент повинен бути працездатний в будь-якому середовищі, де є необхідні для його роботи інші компоненти. Це вимагає наявності певної інфраструктури, яка дозволяє компонентам знаходити один одного і взаємодіяти за певними правилами.
Існують кілька компонентних моделей. Правильно взаємодіяти один з одним можуть тільки компоненти, побудовані в рамках однієї моделі, оскільки компонентна модель визначає "мову", на якому компоненти можуть спілкуватися один з одним.
Крім компонентної моделі. для роботи компонентів необхідний певний набір базових служб (basic services). Наприклад, компоненти повинні вміти знаходити один одного в середовищі, яка, можливо, розподілена на кілька машин. Компоненти повинні вміти передавати один одному дані, знову ж таки, може бути, за допомогою мережевих взаємодій, але реалізації окремих компонентів самі по собі не повинні залежати від виду використовуваної зв'язку і від розташування їх партнерів по взаємодії. Набір таких базових. необхідних для функціонування більшості компонентів служб, разом з підтримуваної з їх допомогою компонентної моделлю називається компонентної середовищем (або компонентним каркасом, component framework). Приклади відомих компонентних середовищ - різні реалізації J2EE. NET, CORBA. Самі по собі J2EE. NET і CORBA є специфікаціями компонентних моделей і набору базових служб. які повинні підтримуватися їх реалізаціями.
Компоненти, які працюють в компонентних середовищах. по-різному реалізують одну й ту ж компонентну модель і одні і ті ж специфікації базових служб. повинні бути в змозі вільно взаємодіяти. На практиці цього, на жаль, не завжди вдається досягти, але будь-яка перешкода до такої взаємодії розглядається як серйозна, що підлягає швидкому вирішенню проблема.
Співвідношення між компонентами, їх інтерфейсами. компонентної моделлю і компонентної середовищем можна зобразити так, як це зроблено на рис. 12.1.
- Клас визначає не тільки набір реалізованих інтерфейсів. але і саму їх реалізацію, оскільки він містить код визначених операцій. Контракт компонента, частіше за все, не фіксує реалізацію його інтерфейсів.
- Клас написаний певною мовою програмування. Компонент ж не прив'язаний до певної мови, якщо, звичайно, його компонентна модель цього не вимагає, - компонентна модель є для компонентів тим же, чим для класів є мова програмування.
- Зазвичай компонент є більшою структурною одиницею, ніж клас. Реалізація компоненту часто складається з декількох тісно пов'язаних один з одним класів.
збільшити зображення
Мал. 12.1. Основні елементи компонентного програмного забезпечення
Треба відзначити, що, хоча ринок ПЗ існує досить давно, а компонентні технології розробляються вже близько 20 років, ринок компонентів розвивається досить повільно. Постачальниками компонентів стають лише окремі компанії, тісно пов'язані з розробниками конкретних компонентних середовищ. а не широке співтовариство індивідуальних і корпоративних розробників, як це уявляли собі творці компонентних технологій при їх зародження.
Мабуть, один з основних факторів, що заважають розвитку цього ринку, - це "гонка технологій" між постачальниками основних компонентних середовищ. Її наслідком є відсутність стабільності в їхньому розвитку. Нові версії з'являються занадто часто, і досить часто при виході нових версій змінюються елементи компонентної моделі. Так що при розробці компонентів для наступної версії доводиться слідувати вже дещо іншим правилам, а старі компоненти насилу можуть бути перевикористати.