1.3. Методи подолання складності
1.3.1. Роль декомпозиції
Спосіб керування складними системами був відомий ще в старовині - divide et impera (розділяй і володарюй). Під час проектування складної ІС необхідно розділяти її на всі менші і менші підсистеми, кожну з яких можна удосконалювати незалежно. В цьому випадку ми не перевищимо пропускної спроможності людського мозку: для розуміння будь-якого рівня системи нам необхідно одночасно тримати в думці інформацію лише про небагато її частин (зовсім не про всі). Насправді, як відмітив Парнас, декомпозиція викликана складністю програмування системи, оскільки саме ця складність вимушує ділити простір станів системи.
Декомпозиція викликана складністю програмування системи, оскільки саме ця складність змушує поділяти простір станів системи.
Декомпозиція – це закріплення цілей, задач, критеріїв їх досягнення і відповідних числових показників за структурними елементами організації різного ієрархічного рівня. Були розроблені різні підходи декомпозиційних методів.
На етапі декомпозиції, що забезпечує загальне уявлення про поставлену проблему, здійснюються:
визначення і декомпозиція загальної мети дослідження;
виділення проблеми зі середовища, визначення її ближнього і далекого оточення;
опис факторів впливу.
Найчастіше декомпозиція проводиться шляхом побудови дерева цілей і дерева функцій. Основною проблемою при цьому є дотримання двох суперечливих принципів:
повнота — проблема має розглядатись максимально всесторонньо і детально;
простоти — все дерево має бути максимальне компактним «вшир» і «углиб».
Компроміс досягається за допомогою чотирьох основоположних понять:
суттєвості — в модель включаються тільки компоненти, суттєві по відношенню до цілей аналізу;
елементарності — доведення декомпозиції до простого, зрозумілого результату, який можна реалізувати;
поступовій деталізації моделі;
інтегративності — можливість введення нових елементів в підстави і продовження декомпозиції по ним на різних гілках дерева.
Структурна (алгоритмічна) декомпозиція. Більшість з нас формально навчена структурному проектуванню "зверху донизу", і ми сприймаємо декомпозицію як звичайне розділення алгоритмів, де кожний модуль системи виконує один з етапів загального процесу. На рис. 1.2 наведений як приклад один з продуктів структурного проектування: структурна схема, яка показує зв'язки між різними функціональними елементами системи. Дана структурна схема ілюструє частину програмної схеми, що змінює вміст керуючого файлу. Вона була автоматично отримана з діаграми потоків даних спеціальною експертною системою, якій відомі правила структурного проектування.
Об'єктно-орієнтована декомпозиція. Існує альтернативний спосіб декомпозиції. На рис. 1.3 ми розділили систему, вибравши як критерій декомпозиції приналежність її елементів до різних абстракцій заданої ПО. Спочатку ніж розділяти задачу на кроки типу Get formatted update (Отримати зміни у автовідформатованому вигляді) і Add check sum (Додати до контрольної суми), ми повинні визначити такі об'єкти як Master File (Основний файл) і Check Sum (Контрольна сума), які запозичуються із словника ПО.
Хоча обидві схеми вирішують одну і ту ж задачу, але вони роблять це різними способами. У другій декомпозиції світ представлений сукупністю автономних дійових осіб, які взаємодіють один з одним, аби забезпечити поведінку системи, що відповідає вищому рівню. Get formatted update (Отримати зміни у автовідформатованому вигляді) більше не присутній як незалежний алгоритм; ця дія існує тепер як операція над об'єктом File of Updates (Файл змін). Ця операція створює інший об'єкт - Update to Card (Зміни в карті). Таким чином, кожний об'єкт володіє своєю власною поведінкою, і кожний з них моделює деякий об'єкт реального світу. З цієї точки зору об'єкт є деякою річчю, яка володіє певною поведінкою. Об'єкти щось роблять, і ми можемо, пославши їм повідомлення, попросити їх виконати те-то і те-то. Оскільки наша декомпозиція заснована на об'єктах, а не на алгоритмах, ми називаємо її об'єктно-орієнтованою декомпозицією.
Рис. 1.2. Алгоритмічна декомпозиція.
Рис.1.3. Об'єктно-орієнтована декомпозиція
Декомпозиція: алгоритмічна чи об'єктно-орієнтована? Яка декомпозиція складної системи правильніша - алгоритмічна чи за об'єктами? У цьому питанні є каверза, і правильна відповідь на нього: важливі обидва аспекти. Розділення за алгоритмами концентрує увагу на порядку подій, що відбуваються, а розділення за об'єктами надає особливе значення агентам, які є або об'єктами, або суб'єктами дії. Проте ми не можемо сконструювати складну систему одночасно двома способами, тим паче, що ці способи за своєю суттю ортогональні. Ця ортогональность вивчалася з давніх часів. Пасивний погляд пропонувався Демокрітом, який стверджував, що світ складається з атомів. Ця позиція Демокріта ставила в центр всього матерію. Класичним представником іншої сторони - активного погляду - був Геракліт, який виділяв поняття процесу. Ми повинні почати розділення системи або за алгоритмами, або за об'єктами, а потім, використовуючи отриману структуру, спробувати розглянути проблему з іншої точки зору.
Досвід показує, що корисно починати з об'єктної декомпозиції. Такий початок допоможе нам краще впоратися в організації складності програмних систем. Вище цей об'єктний підхід допоміг нам під час опису таких несхожих систем, як комп'ютери, рослини, галактики і суспільні інститути. Як буде показано далі, об'єктна декомпозиція має декілька надзвичайно важливих переваг перед алгоритмічною. Об'єктна декомпозиція зменшує розмір програмних систем за рахунок повторного використання загальних механізмів, що наводить до істотної економії програмних засобів. Об'єктно-орієнтовані системи гнучкіші і простіше еволюціонують з часом, тому що їх схеми базується на стійких проміжних формах. Дійсно, об'єктна декомпозиція істотно знижує ризик при створенні складної програмної системи, оскільки вона розвивається з менших систем, в яких ми вже упевнені. Більш того, об'єктна декомпозиція допомагає нам розібратися в складній програмній системі, пропонуючи нам розумні рішення відносно вибору підпростору великого простору станів.
Приклад 1.1. Яскравим прикладом декомпозиції є процедура визначення програмних засобів, на яких студентові найкраще виконати курсову роботу з програмування. Головною задачею він для себе ставить – реалізувати завдання курсової роботи (рис. 1.4). Ця задача розбивається на дві менші – доступ до даних та робота з програмою, вказані задачі – ще на дрібніші, що, у свою чергу, дозволяє йому визначити, яке саме програмне забезпечення із можливих (нижній рівень) йому краще обрати.