ПроектнийПрактикум / ПрофесійнаПрактика / Разное / lavrishcheva-6

У процесі створення ПС із застосуванням аспектів можуть використовуватися: ІP-бібліотека розширень, що містить у собі їх коди, а також активні бібліотеки, мова програмування SmallTalk, розширені засоби опису аспектів [17].

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

Використання таких бібліотек у розширених середовищах програмування називають родовим програмуванням, а вирішення проблем економії, перебудови компіляторів під кожне нове мовне розширення, використання шаблонів і результатів попередньої обробки відносять до області ментального програмування [17]. Бібліотека IP містить у собі: окремі функції компіляторів, засоби оптимізації, редагування, відображення понять, перебудови окремих компонентів компіляторів під нове мовне розширення, а також засоби програмування на основі шаблонів і т.п. Бібліотеки з такими можливостями одержали назву бібліотек генерації.

Інший вид бібліотек АОП – активні бібліотеки, які містять у собі не тільки базовий код реалізації понять ПрО, а й цільовий код забезпечення оптимізації, адаптації, візуалізації й редагування. Активні бібліотеки поповнюються засобами й інструментами інтелектуалізації агентів, за допомогою яких забезпечується розроблення спеціалізованих агентів для реалізації конкретних задач ПрО.

5.1.6. Генерувальне (порождувальне) програмування

Генерувальне програмування (generative programming) – це методи і засоби генерації сімейств систем і застосувань з окремих компонентів, аспектів, КПВ, каркасів і ін. Базис цього програмування – ООП, доповнене механізмами генерації багаторазових елементів і КПВ, а також властивостями їхньої змінюваності, взаємодії й ін. [17]. Це програмування є новим видом програмування, в ньому використовуються різні методи інженерії складних ПрО для розроблення сімейств ПС із різних виготовлених раніше програмних продуктів, згенерованих програмних застосувань і систем, сімейств систем, члени яких задовольняють певні показники якості.

Головний продукт інженерії ПрО – це сімейство ПС, яке генерується на основі загальної генерувальної моделі домену GDM (Generative Domain Model), що містить у собі засоби визначення окремих членів (представників) сімейства, до яких відносять предметно-орієнтовану мову DSL (Domain Specific Language), методи генерації окремих членів і їх збирання у сімейство, а також базу конфігурації для розгортання сімейства або його членів у середовищі.

Кожен член сімейства створюється з окремих компонентів. Це створення планується, контролюється й оцінюється після інтеграційного тестування на якість, а також обліку витрат на використання КПВ, у тому числі готових, узятих, наприклад, з активної бібліотеки [17].

Елементи цієї бібліотеки – цільовий код засобів забезпечення компіляції, налагодження, візуалізації й ін. Фактично компоненти бібліотеки – це інтелектуальні агенти, що генерують нові агенти в розширюваному середовищі програмування для розв’язання конкретних задач ПрО. У ньому містяться спеціальні метапрограми, тобто програми, що генерують інші програми, і

компоненти бібліотеки для здійснення збирання згенерованих компонентів і поповнення ними цього середовища для майбутнього створення нових членів сімейства з компонентів багаторазового використання.

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

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

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

–мова опису специфіки домену;

–мова опису функціональних задач домену;

–мова опису аспектів взаємодії, синхронізації компонентів у середовищі;

–мова опису захисту даних та безпеки виконання сімейства систем;

–мова опису інтерфейсів (PDL, IDL тощо).

Предметно-орієнтована мова – DSL. Вона вналежить до класу мов опису специфіки ПрО або домену, властивої саме цьому домену. Опис кожного члена сімейства може містить мову опису специфіки задач домену і генеруючої моделі домену GDM (Generative Domain Model), яка відображає склад домену із членів сімейства, специфікованих також у предметно-орієнтованих мовах.

Мова DSL не є новим винаходом, оскільки загальні абстракції програмування були визначені й вбудовані в мови загального призначення. І хоча мова DSL створюється багато років і для кожної ПрО є свій варіант мови, її застосування для специфікації особливостей ПрО не забезпечує формування повного уявлення про предметну область, оскільки вона дає лише засоби визначення загальних рис ПрО.

Відомо, що будь-яка мова має визначену область застосування, проте мова DSL є більш спеціалізованою, ніж інші мови програмування (Паскаль, Кобол), що створювалися для розв’язання конкретних типів задач (обчислювальних, економічних). Порівняно з ними, DSL близька до описових мов, таких, як HTML, XML. Вона має специфічні особливості порівняно з мовами загального призначення, а саме:

–абстракції DSL забезпечують визначення концепцій і абстрактних понять у предметній області;

–синтаксис мови DSL може надавати засоби природного опису понять домену і запобігати синтаксичній неузгодженості, що буває при використанні мови загального призначення;

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

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

–інструменти підтримки DSL потребують відповідного оточення, наприклад, середовища, редактора, контролера версій тощо.

Специфікована в DSL модель ПрО є загальною моделлю GDM (рис.5.10).

Рис.5.10. Структура генерувальної моделі GDM

Модель відображає:

–поняття, характеристики ПрО і членів сімейства в просторі проблем;

–набір членів сімейства і їхніх специфікацій у мовах типу DSL, RAISE (Rigorous Approach to Industrial Software Engineering), RSL (RAISE Specification Language) і ін.;

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

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

–модель характеристик (feature models) відображає загальні, змінювані і незмінні характеристики членів сімейства і правила конструювання систем сімейства з урахуванням їхньої залежності один від одного і від компонентів типу КПВ;

–архітектуру (каркас) сімейства систем;

–реалізацію компонентів архітектури у мовах програмування. Генерувальне програмування чітко поділяється на дві частини дослідження і

проектування продукту ПрО – формування опису простору проблеми і простору розв’язків задач ПрО [5]. Перша частина призначена для проведення аналізу ПрО, виявлення її задач, які потрібно реалізувати, а друга – для розроблення засобів реалізації цих задач. Ці частини об’єднує конфігураційна і трансформаційна база знань про конфігурацію, тим самим утворюючи структуру моделі генерації у ПрО (або GDM) розроблюваних ПС (див. вищі рис.5.10).

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

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

124 Розділ 5

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

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

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

Перетворення простору проблем у простір задач проводиться конфігураційним або трансформаційним способом. При конфігураційному способі використовують конструкторські правила й оптимізатори для додавання характерних рис до специфікації домену з урахуванням концепції домену, а також для перевірки комбінацій особливостей і залежностей в моделі GDM. Як результат утворюється конфігурація компонентів системи. Опис специфіки домену трансформується в опис мови реалізації компонентів простору розв’язання задач. Тобто перетворення опису ПрО у мову програмування відбувається шляхом генерації з використанням теорії мов і мовних перетворень.

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

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

У генерувальному програмуванні головним об’єктом є КПВ. Він використовується при створенні членів сімейства за двома інженерними напрямами

[11–14]:

1) прикладна інженерія (Application Engineering) – процес розроблення

сімейства або самого сімейства систем шляхом використання КПВ, які зафіксовані

у сховищах, а також частин і членів сімейства систем конкретної ПрО, отриманих за моделлю GDM (більш докладно див. розділ 9).

У цих напрямах інженерії моделювання архітектури здійснюється за модельно-орієнтованим підходом і завершується побудовою архітектури MDA (Model Driven Architecture). Моделювання MDA-архітектури відбувається на двох рівнях – платформо незалежному (за допомогою моделі PIM, Platform Independent Model) і платформо залежному (за допомогою моделей PSM, Platform Specific Models). Таке моделювання підтримує концепцію відображення простору у простір задач. Тобто в моделі сімейства ПС члени сімейства можуть мати спільні функції, але вони розрізняються платформами реалізації.

Вибір альтернативних платформ – є «точкою варіантності» у сімействі. Ця точка знаходиться над моделлю ПС, тобто вона невидима на її рівні. Керування «точкою варіантності» платформ відбувається через трансформацію PIM→PSM без участі розробника.

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

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

–розробка ПрО й одиночних програм;

–повторне використання ресурсів;

–менеджмент домену.

Розробка ПрО з КПВ є конвеєрною. Для ПрО плануються базові ресурси, якими можуть бути КПВ, програми, генератори, DSL-описи, моделі аналізу, документація й ін. Проектування в ПрО одиночних програм у прикладній інженерії базується на програмуванні з повторним використанням, де конкретні програми містять у собі різні готові ресурси (assets), які можуть бути і КПВ. Розробка ПрО є більш складним виробничим процесом, який містить у собі загальні етапи: аналіз, проектування і впровадження.

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

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

допомогою генераторів або конфігураторів готових ресурсів. Згенеровані продукти сімейства можуть містити у собі і методичні артефакти, наприклад, інструкції з користування DSL і компонентами домену.

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

Таким чином, інженерія ПрО охоплює:

–аналіз ПрО і виявлення об'єктів і відношень між ними;

–визначення області дій об'єктів ПрО;

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

–створення базису для інженерії виробництва конкретних прикладних членів сімейства з механізмами змінюваності незалежно від засобів їхньої реалізації;

–підбір і підготовка компонентів багаторазового застосування для задач

ПрО;

–генерація окремих членів сімейства або домену в цілому.

Етапи цієї схеми забезпечують формування моделі ПрО і моделі характеристик, як елементів простору проблем. Вони трансформуються в архітектуру системи й опис її компонентів, які об’єднуються у окремі системи для забезпечення розв’язання задач ПрО у просторі рішень.

Як готові ресурси в інженерії ПрО можуть використовуватися відомі горизонтальні і вертикальні типи компонентів загального призначення, що реалізовані зокрема в моделі CORBA [14]. Горизонтальні типи компонентів – це загальні системні засоби, що потрібні різним членам сімейства, а саме, графічні інтерфейси користувача, СКБД, бібліотеки розрахунку матриць, контейнери, каркаси і т.п.

До вертикальних типів компонентів належать прикладні системи (медичні, біологічні, наукові і т.д.), а також компоненти горизонтального типу з обслуговування архітектури багаторазового застосування компонентів і їхніх інтерфейсів.

Приклад системи підтримки інженерії ПрО і застосування горизонтальних методів – система DEMRAL [14, 17], призначена для розробки бібліотек: чисельного аналізу, графових обчислень і т.д. Основні види елементів цієї бібліотеки – абстрактні типи даних (abstract data types) і алгоритми. DEMRAL підтримує інженерію домену за допомогою бібліотек чисельного аналізу, обробки зображень тощо. Крім цього, ця система дозволяє моделювати характеристики ПрО і зображати їх у характеристичній моделі, а також в предметно-орієнтованих мовах опису членів ПС конфігурації.

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

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

5.1.7. Сервісно-орієнтоване програмування

Ця парадигма програмування з'явилася як наслідок розгляду програмних компонентів як готових сервісів, визначення для них інтерфейсів взаємодії в рамках нових архітектур ПЗ, зв'язаних із сервісами, у середовищі розподілених систем (CORBA, DCOM і EJB) і веб-сервісів у середовищі Інтернету. Такі архітектури отримали назву сервісно-орієнтованих архітектур – SOA (Service-Oriented Architecture) і зараз активно розвиваються разом із відповідними засобами їхньої підтримки й опису (XML, SOAP, WSDL і ін.) та механізмами взаємодії звичайних сервісів розподілених застосувань і веб-сервісів Інтернету [18].

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

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

Архітектура SOA має форму піраміди, що складається з кількох шарів [18].

1.Підґрунтям піраміди є базові сервіси і базові операції, а саме, публікація, виявлення, вибір і зв'язування, які націлені на створення і використання описів сервісів.

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

3.Шар менеджменту сервісу, а саме, керування платформою сервісу, розгортання, ведення статистики виконання, підвищення ефективності, забезпечення прозорості ходу виконання транзакцій, відстеження стану ходу виконання тощо.

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

розподілені між партнерами. Саме інформаційні потреби розподілених бізнесів викликали до життя веб-сервіси як адекватну форму компонентів типа КПВ.

Веб-сервіс має URL-адресу, інтерфейс і механізм взаємодії з іншим сервісом через протоколи Інтернету або зв'язки з іншими програмами, БД і діловими бізнесопераціями. Обмін даними між веб-сервісом і програмою здійснюється за допомогою XML-документів, оформлених у вигляді повідомлень. Веб-сервіси забезпечують розв’язання задачі інтеграції застосувань різної природи, будучи інструментом побудови розподілених систем. Веб-сервіс надається провайдером мережі Інтернету, який має стандартний спосіб взаємодії з розподіленими (.NET, J2EE, CORBA і ін.) і прикладними системами з отримання деякої послуги.

Основні засоби опису веб-сервісів:

–мова XML для опису і побудови SOA–архітектури;

–мова WSDL (Web Services Description Language) для опису веб-сервісів і їхніх інтерфейсів на XML, що стосується типів даних і повідомлень, а також моделей взаємодії і протоколів зв'язування сервісів між собою;

–SOAP (Simple Object Access Protocol) для визначення форматів запитів до веб-сервісів;

–UDDI (Universal Description, Discovery and Integration) для універсального опису, виявлення й інтеграції сервісів, забезпечення їхнього збереження, упорядкування ділової сервісної інформації в спеціальному реєстрі з покажчиками на конкретні інтерфейси веб-сервісів.

Сервісно-орієнтована архітектура – це сукупність взаємодіючих між собою сервісів і веб–сервісів і їхніх інтерфейсів. Будь-який з компонентів SOA створюється за допомогою сервісів безвідносно до конкретних технологій, за які можна брати готові застосування типу «чорна скринька». Інтеграція компонентів і сервісів в архітектуру SOA містить у собі наступні види:

–користувальницьку інтеграцію (user integration) для взаємодії інформаційної системи з конкретним користувачем;

–зв'язування застосувань (application connectivity) для забезпечення їхньої взаємодії;

–інтеграцію процесів (process integration) для об'єднання бізнес-процесів;

–інформаційну інтеграцію (information integration) для забезпечення доступу до інтегрованої інформації і даних.

При цьому до створюваної архітектури SOA висуваються наступні вимоги:

–наявність існуючих інформаційних систем і поява нових;

–поетапне впровадження нових і міграція існуючих інформаційних систем;

–стандартизація технології і реалізація інструментів для підтримки сервісних архітектур з повторним використанням застосувань і компонентів;

–використання різних моделей і систем (портали, grid-системи й ін. ). Якщо об'єктом сервісно-орієнтованої архітектури є веб-сервіс, то

застосовується дві технології, що забезпечує функціональність (Functions) і якість сервісів (Quality of service). Ці технології винесені на рівень IT-стандартів комітету W3C і мають наступні рівні.

Технологія забезпечення функціональності веб-сервісів має:

–транспортний рівень (transport layer) для обміну даними;

–комунікаційний рівень (service communication layer) для визначення протоколів;

–рівень опису сервісу (service description layer) і зв'язаних з ним інтерфейсів;

–рівень бізнес-процесів (business process layer) для реалізації бізнес-процесів

іпотоків робіт через механізми веб-сервісів;

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

Технологія забезпечення якості веб-сервісів має наступні рівні:

–політики (policy layer) для опису правил і умов застосування веб-сервісів;

–безпеки (security layer) для опису питань безпеки веб-сервісів і функціонування (авторизація, аутентифікація і розподіл доступу);

–транзакцій (transaction layer) для встановлення параметрів звертання до вебсервісів і забезпечення надійності їхнього функціонування;

–керування (management layer) веб-сервісами.

Технологічний фундамент веб-сервісів становлять: XML, SOAP, UDDI, WSDL. З їхньою допомогою здійснюється реалізація базових властивостей вебсервісу і механізму взаємодії між собою веб-сервісів у середовищі SOA, що вміщують компоненти, наведені на рис. 5.11.

Рис. 5.11. Компоненти веб-сервісів і взаємодія з різними системами

Як видно з рисунку до головних компонентів належать:

–провайдер сервісу, що здійснює реалізацію сервісу у вигляді веб-сервісу, прийом і виконання запитів користувачів сервісу, а також публікацію сервісу, відзначеного в реєстрі сервісів;

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

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

Зв'язок між діючими системами, наведений на рисунку, здійснюється через ХМL-повідомлення мережного середовища, що використовують інтерфейси веб-

сервісів. Посередником між загальносистемними службами розподілених систем і застосувань є провайдер, що звертається до них за сервісом, а інтегратор SOA, що створюються із сервісів і веб-сервісів, називається брокером.

Для отримання сервісу в архітектурі SOA виконуються наступні операції:

1.Публікація сервісу WSDL з метою забезпечення доступності (через виклик) користувачеві сервісу і його інтерфейсу;

2.Пошук за протоколом SOAP здійснює користувач сервісу в реєстрі сервісів за заданими критеріями;

3.Зв'язування UDDI через опис користувачем необхідного сервісу, який може надаватися в таких моделях як COM, CORBA, DBMS, .JNET тощо.

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

5.1.8. Агентне програмування

Поняття інтелектуального і програмного агента з'явилося понад 20 років тому, їхня роль у програмній інженерії увесь час зростає [19–23]. Так, Джекобсон [23] зазначив перспективу використання агентів як менеджерів проектів, розробників архітектури за діаграмами use case і ін.

Основний теоретичний базис даного програмування – темпоральна, модальна і мультимодельна логіки, дедуктивні методи доведення правильності властивостей агентів і ін.

Зпогляду програмної інженерії агент — це самодостатня програма, здатна керувати своїми діями в інформаційному середовищі функціонування для одержання результатів виконання поставленої задачі і зміни поточного стану середовища [19]. Агент має такі властивості:

– автономність – це здатність діяти без зовнішнього впливу;

– реактивність – це здатність реагувати на зміни даних, середовища і сприймати їх;

– активність – це здатність ставити мету і виконувати задані дії для досягнення цієї мети;

– здатність до взаємодії з іншими агентами (або людьми).

Зінтелектуальним агентом зв'язані знання, що відображають переконання, намір, зобов'язання і т.п. Ці поняття входять у концептуальну модель і зв'язуються між собою операційними планами реалізації цілей агента. Для досягнення цілей інтелектуальні агенти взаємодіють один з одним, установлюють зв'язок між собою через повідомлення або запити і виконують задані дії або операції відповідно до наявних знань. Агенти можуть бути локальними і розподіленими (рис.5.12).

Локальні агенти виконують задані функції у певних серверах і клієнтських комп’ютерах мережі і впливають на загальний стан середовища функціонування. Розподілені агенти розміщуються в різних вузлах мережі, виконують автономно (паралельно, синхронно, асинхронно) притаманні їм функції і можуть впливати на загальний стан розподіленого середовища.