Стандарт CORBA і концепція SPEM-специфікації програм

SPEM-специфікація метамодели програмної інженерії (Software Process Engineering Metamodel Specification) – новий напрямок у теорії і практиці об’єктно-орієнтованої технології розробки ПЗ, який розробляє консорціум OMG. Статут цієї організації включає створення індустріальних керівних нормативних документів і специфікацій щодо розвитку стандартів об'єктного програмування для забезпечення загальної архітектури розподілених застосувань. Основні задачі – повторне використання, мобільність і інтероперабельність об’єктно-орієнтованого ПЗ у розподілених гетерогенних середовищах. Відповідність цим специфікаціям дозволить розробити гетерогенне середовище застосувань між основними апаратними платформами й ОС. Сприяючи розвитку об’єктно-орієнтованої технології, OMG впливає на її напрямок за допомогою введення OMA-архітектури (Object Management Architecture) як концептуальної інфраструктури, на якій ґрунтуються всі OMG-специфікації.

Запропонована фірмою IBM технологія побудови розподілених об'єктних застосувань CORBA (Common Object Request Broker Architecture) – це відповідь OMG на вимогу інтероперабельності серед швидко зростаючого числа доступних апаратних і програмних продуктів. Простіше кажучи, застосуванням дозволяється підтримувати взаємозв'язок, при цьому не має значення, де вони розташовані чи ким розроблені. Введений у 1991 р. індустріальний стандарт CORBA 1.1 визначив мову IDL опису інтерфейсів (Interface Definition Language) і API-інтерфейс, що забезпечили змогу об'єктам (обчислювальним сутностям) зв'язки клієнт-сервер взаємодіяти через брокер об'єктних запитів ORB (Object Request Broker). Прийнята у 1999 р. CORBA 3.0 визначає справжню інтероперабельність, описуючи, як можуть взаємодіяти ORB від різних виробників.

Повертаючись до рис. 1.1, підвищення інтероперабельності застосувань можна легко пояснити як спрощення моделі CORBA-взаємодії, у якої число рівнів перетворення даних зменшилося. Оскільки реалізація CORBA доступна усім, потрібен протокол комунікації, щоб різні системи могли взаємодіяти одна з іншою. Протокол GIOP (General Inter-ORB Protocol) специфікований у ISO/IEC 19500-2:2003 як загальний інтерфейс, включаючи типи повідомлень та їхній формат для взаємодії. Семантичний шар IIOP (Internet Inter-Orb Protocol) специфікований у ISO/IEC 19500-2:2003 так, щоб відобразити GIOP на TCP/IP. Комбінація GIOP та IIOP необхідна для взаємодії за межами одного комп'ютера. Усі постачальники ORB, що підтримують цей протокол, мають працювати лише над цим протоколом. Проте одного протоколу недостатньо для всіх користувачів, тому є змога відображати GIOP на інші протоколи (скажімо, IPX чи SNA).

Тематично OMG-документи організовані у такий спосіб:

1) Моделювання OMG (OMG Modeling):

- UML-специфікація описує графічну мову UML для візуалізації, опису, побудови і документування артефактів розподілених систем об'єктів;

- MOF-специфікація (Meta-Object Facility) описує набір IDL-інтерфейсів CORBA, які можна використовувати для визначення і керування набором інтероперабельних метамоделей і їхніх відповідних моделей;

- XMI-специфікація OMG (XML Metadata Interchange) підтримує обмін різновидами метаданих, які можна виразити за допомогою MOF-специфікації, включаючи як модель, так і інформацію метамоделі.

2) Інструкція з OMA (Object Management Architecture Guide) як документ визначає технічні цілі і термінологію OMG, описує концептуальну модель, на якій ґрунтуються OMG-стандарти, і визначає структуру покриття для OMG-стандартів, а також надає інформацію про методи і процедури OMG, наприклад, як стандарти вносяться, оцінюються і приймаються.

3) “CORBA: архітектура і специфікація” містить опис архітектури і специфікації для брокера об'єктних запитів:

- OMG-специфікація IDL-мовного відображення (OMG IDL Mapping Specifications) як документ надає уніфікований метод визначення інтерфейсів до CORBA-об'єктів. IDL-визначення – це угода між клієнтом і тим, хто реалізує об'єкт, а IDL як непроцедурна мова із сильною типізацією побудована саме для мовно-незалежного програмування маршалінгу (marshaling). Мовні відображення дозволяють реалізувати об'єкти і пересилати вимоги мовою програмування розробника у кращому стилі, тобто природному для цієї мови. У OMG є розширюваний набір відображень для мов Ада, Cі/C++, Кобол, IDL для Java, Java для IDL, Лісп і Smalltalk;

- Сервіси CORBA (CORBA services) – це сервіси CORBA-об'єкта, тобто універсальні послуги загального призначення, що фундаментальні для розробки корисних розподілених CORBA-застосувань або надають універсальний, незалежний від домену базис для інтероперабельності застосування. Ці сервіси – основні будівельні блоки для розподілених застосувань, складених з об'єктів. Погоджені з CORBA-специфікаціями об'єкти можуть комбінуватися у різний спосіб і використовуватися у застосуваннях для створення функціональності вищого рівня і фреймворков, що можуть взаємодіяти між різними середовищами комп'ютерних платформ. Прийняті OMG-сервіси об'єкта звуться CORBA-сервісами в узагальненому значенні і включають специфікації Collection, Concurrency, Event, Externalization, Naming, Licensing, Life Cycle, Notification, Persistent Object, Property, Query, Relationship, Security, Time, Trader і Transaction;

- CORBA-засоби (CORBA facilities) – це загальні інтерфейси для горизонтального шару midleware-засобів, орієнтовані на кінцевого користувача і застосовувані до більшості доменів. Прийняті OMG узагальнені CORBA-засоби включають такі специфікації, як інтернаціоналізація, системний таймер (Time) і сервіс мобільних агентів (Mobile Agent Facility).

4) Об'єктні фреймворки й інтерфейси доменів (Object Frameworks and Domain Interfaces) на відміну від інтерфейсів індивідуальних частин "plumbing" в інфраструктурі OMA є повними компонентами більш високого рівня, що прямо забезпечують функціональність кінцевим користувачам у конкретному застосуванні технологічних доменів. Доменні комісії (Domain Task Forces) зфокусували свої зусилля на специфікаціях об'єктних фрйморків, що включають інтерфейси для таких прикладних доменів, як фінанси (Finance), охорона здоров'я (Healthcare), виробництво (Manufacturing), телекомунікація (Telecoms), електронна комерція (E-Commerce) і транспорт (Transportation). На даний час доступні SPEM-специфікації наступних доменів:

- CORBA-бізнес (CORBA Business) відповідає погодженим OMG-інтерфейсам для систем комерції, насамперед електронної;

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

- CORBA-медицина (CORBA Healthcare) містить SPEM-специфікації, які відповідають охороні здоров'я щодо продавців і медичних постачальників, платників і кінцевих користувачів;

- CORBA-виробництво (CORBA Manufacturing) містить SPEM-специфікації, що відповідають обробній промисловості і визначають стандартизовані об’єктно-орієнтовані інтерфейси між відповідними сервісами і задачами-функціями;

- CORBA-телекомунікація (CORBA Telecoms) містить SPEM-специфікації, що відповідають погодженим OMG-інтерфейсам для мереж зв'язку;

- CORBA-транспорт (CORBA Transportation) містить SPEM-специфікації, що відповідають погодженим OMG-інтерфейсам для транспортних перевезень.

OMG накопичує інформацію для кожної книги з набору документів, випускаючи запити на інформацію (Requests for Information), запити на пропозиції (Requests for Proposals) і запити на коментарі (Requests for Comment), а потім оцінюючи відповіді своїх рядових членів. Специфікації приймаються як стандарти тільки після того, як представники рядових членів OMG визнають їх шляхом голосування. Ці методи і процедури консорціуму OMG докладно описані в Object Management Architecture Guide.

Власне здобутками доменних комісій пояснюється підвищення до 97-98% використання компонентів повторного використання під час проектування/реінжинірингу програмної складової ІТ і, як наслідок, прогнозується суттєве зростання продуктивності праці розробників програмної складової ІТ. Скажімо, крім стовідсоткового підвищення продуктивності праці, компанія Motorola, закладає найвищі вимоги до якості програмного продукту: “шість дев'яток” і σδ. Перше означає 99.9999% завадостійкості функціонування програм, а друге - не більше двох помилок на 1 млн. рядків початкового тексту програм. Нагадаємо, що поширення наприкінці 80-х років CASE-інструментів розробки програмного продукту пов’язано із доведенням обсягу лише до 60-70% компонентів повторного використання, але не для розподілених застосувань, а лише для однопроцесорного застосування.

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

Дата добавления: 2015-11-26