9. Декомпозиція, зв'язок та синхронізація.

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

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

Зв'язок

Після декомпозиції програмного рішення на перелік частин які викону­ю­ться паралельно як правило виникає питання про зв'язок цих частин між со­бою. Як же реалізувати зв'язок, якщо ці частини розділені за різними процесами або різними комп’ютерами? Чи повинні різні частини ПЗ спільно використову­вати загальну область пам’яті? Яким чином одна частина ПЗ дізнається про те, що інша справилася зі своєю задачею? Яка частина повинна першою почати роботу? Звідки один компонент дізнається про відмову іншого компонента? На ці та інші питання необхідно знайти відповіді при проектування паралельних та розподілених систем. Якщо окремим частинам ПЗ не потрібно зв’язуватись між собою, тоді, вони в дійсності не створюють єдиний додаток.

Синхронізація

Декомпозиція робіт, говорилося вище, визначає, що повинні робити різ­ні частини ПЗ. Коли декілька компонентів ПЗ працюють в межах однієї задачі, їх функціонування необхідно координувати. Певний компонент повинен вміти  визначати, коли досягається рішення всієї задачі. Необхідно також скоордину­вати порядок виконання компонент. При цьому виникає багато запитань. Чи всі частини ПЗ повинні одночасно притупити до роботи або тільки деякі, а інші можуть знаходитися в стані очікування? Яким двом (або більше) компонентам необхідний доступ до одного і того ж ресурсу? Хто має право отримати доступ першим? Якщо деякі частини ПЗ завершать свою роботу значно раніше інших, то чи потрібно їм доручити нову роботу? Хто повинен надавати нову роботу в таких випадках? ДЗС (декомпозиція, зв'язок, синхронізація) – це той мінімум запитань, які необхідно вирішувати, починаючи паралельне або розподілене об­числення. Окрім суті проблем, які виникають з ДЗС, важливо також розглянути їх прив’язку. Існує декілька рівнів паралелізму при розробці додатків, і на кож­ному з них ДЗС-складові застосовуються по різному.