7. Мульти-агентні розподілені обчислення.

Не дивлячись на те, що модель типу "клієнт/сервер" — найпоширеніша модель розподіленого програмування, все ж таки вона не єдина. Використовуються також агенти — раціональні компоненти ПЗ , які характеризуються самонаведенням і автономністю і можуть постійно знаходитися в стані виконання. Агенти можуть як створювати запити до інших програмних компонентів, так і відповідати на запити, одержані від інших програмних компонентів. Агенти співпрацюють в межах груп для колективного виконання певних завдань. У такій моделі не існує конкретного клієнта або сервера. Це — модель мережі з рівноправними вузлами (peer-to-peer), в якій всі компоненти мають однакові права, і при цьому у кожного компоненту є що запропонувати іншому. Наприклад, агент, який призначає ціни на відновлення старовинних спортивних машин, може працювати разом з іншими агентами. Один агент може бути фахівцем з моторів, інший — по кузовах, а третій вважає за краще працювати як дизайнер по інтер'єрах. Ці агенти можуть спільно оцінити вартість робіт по відновленню автомобіля. Агенти є розподіленими, оскільки всі вони розміщуються на різних серверах в Internet. Для зв'язку агенти використовують узгоджений Internet-протокол. Для одних типів розподіленого програмування краще підходить модель типу "клієнт/сервер", а для інших — модель рівноправних агентів. У цій книзі розглядаються обидві моделі. Більшість вимог, що пред'являються до розподіленого програмування, задовольняється моделями "клієнт/сервер" і рівноправних агентів.

8. Основні етапи проектування паралельних та розподілених алгоритмів.

Паралельне і розподілене програмування вимагає певних витрат. Не дивлячись на описані вище переваги, написання паралельних і розподілених програм не обходиться без проблем і необхідності наявності передумов. Написанню програми або розробці окремої частини ПЗ повинен передувати процес проектування. Що стосується паралельних і розподілених програм, то процес проектування повинен включати три складових: декомпозиція, зв'язок і синхронізація (ДЗС ).

8.1. Декомпозиція

Декомпозиція — це процес розбиття завдання і його рішення на частини. Іноді частини групуються в логічні області (тобто пошук, сортування, обчислення , введення і виведення даних і т.д.). У інших випадках частини групуються по логічних ресурсах (тобто файл, зв'язок, принтер, база даних і т.д.). Декомпозиція програмного рішення часто зводиться до декомпозиції робіт (work breakdown structure — WBS). Декомпозиція робіт визначає, що повинні робити різні частини ПЗ. Одна з основних проблем паралельного програмування — ідентифікація природної декомпозиції робіт для програмного вирішення. Не існує простого і однозначного підходу до ідентифікації WBS. Розробка ПЗ — це процес перекладу принципів, ідей, шаблонів, правил, алгоритмів або формул в набір інструкцій, які виконуються, і даних, які обробляються комп'ютером. Це, в основному, і складає процес моделювання. Програмні моделі — це відтворення у вигляді ПЗ деякого реального завдання , процесу або ідеалу. Мета моделі — проімітувати або скопіювати поведінку і характеристики деякої реальної суті в конкретній області. Процес моделювання розкриває природну декомпозицію робіт програмного рішення. Чим краще модель зрозуміла і розроблена, тим більше природною буде декомпозиція робіт. Наша мета — виявити паралелізм і розподіл за допомогою моделювання. Якщо природний паралелізм не спостерігається, не варто його нав'язувати насильно. На питання, як розбити програму на паралельно виконувані частини , необхідно знайти відповідь під час проектування, і правильність цієї відповіді повинна стати очевидною в моделі рішення. Якщо модель завдання і рішення не припускає паралелізму і розподілу, слід спробувати знайти послідовне рішення. Якщо послідовне рішення виявляється невдалим, ця невдача може дати ключ до потрібного паралельного рішення.