1.2.3. Організована і неорганізована складність
Канонічна форма складної системи. Виявлення загальних абстракцій і механізмів значно полегшує розуміння складних систем. Наприклад, досвідчений пілот, зорієнтувавшись всього за декілька хвилин, може узяти на себе керування багатомоторним реактивним літаком, на якому він раніше ніколи не літав, і спокійно його вести. Визначивши елементи, загальні для всіх подібних літаків (такі, як кермо керування, елерони і дросельний клапан), пілот потім знайде відмінності цього конкретного літака від інших. Якщо пілот вже знає, як керувати одним літаком певного типу, йому набагато легко навчитися керувати іншим схожим літаком.
Цей приклад наводить на думку, що ми мали на увазі термін ієрархія у подібному сенсі. Найцікавіші складні системи містять багато різних ієрархій. У літаку, наприклад, можна виділити декілька систем: живлення, керування польотом і так далі Таке розбиття дає структурну ієрархію типу "бути частиною". Цю ж систему можна розкласти абсолютно іншим способом. Наприклад, турбореактивний двигун - особливий тип реактивного двигуна, а "Pratt and Whitney TF30" - особливий тип турбореактивного двигуна. З іншого боку, поняття "Реактивний двигун" узагальнює властивості, властиві всім реактивним двигунам; "турбореактивний двигун" - це просто особливий тип реактивного двигуна з властивостями, які відрізняють його, наприклад, від прямоточного.
Така ієрархія є ієрархією типу "is-а". Виходячи з нашого досвіду, ми визнали необхідним розглянути систему з двох точок зору, як ієрархію першого і другого типу. По причинах, викладених в другій частині навчального посібника, ми назвемо ці ієрархії відповідно структурою класів і структурою об'єктів. Складні програмні системи включають також і інші типи ієрархії. Особливе значення мають їх модульна структура, яка описує відношення між фізичними компонентами системи, і ієрархія процесів, яка описує відношення між динамічними компонентами.
Об'єднуючи поняття структури класів і структури об'єктів з п'ятьма ознаками складних систем, ми приходимо до того, що фактично всі складні системи можна представити однією і тією ж (канонічною) формою, яка показана на рис. 1.1. Тут приведено дві ортогональні ієрархії однієї системи: класів і об'єктів. Кожна ієрархія є багаторівневою, причому в ній класи і об'єкти більш високого рівня побудовані з простіших. Який клас або об'єкт вибрати за елементарний, залежатиме від конкретного завдання. Об'єкти одного рівня мають чітко виражені зв'язки, особливо це стосується компонентів структури об'єктів. Усередині будь-якого рівня знаходиться наступний рівень складності. Відзначимо також, що структури класів і об'єктів не є незалежними: кожний елемент структури об'єктів представляє специфічний екземпляр певного класу. Як видно з рис. 1.1, об'єктів в складній системі зазвичай значно більше, ніж класів. Показуючи обидві ієрархії, ми демонструємо надмірність даної системи. Якби ми не знали структуру класів нашої системи, нам довелося б повторювати одні і ті ж відомості для кожного екземпляра класу. З введенням структури класів ми розміщуємо в ній загальні властивості екземплярів.
Найуспішнішими є ті програмні системи, в яких закладені добре продумані структури класів і об'єктів і які володіють п'ятьма ознаками складних систем, описаними вище. Оцінимо важливість цього спостереження і виразимося категоричніше: дуже рідко можна зустріти програмну систему, розроблену точно за графіком, що вклалася б у бюджет і задовольняла вимогам замовника, в якій би не були враховані міркування, викладені вищі.
Структури класів і об'єктів системи разом називається архітектурою системи.
Людські можливості і складні системи. Якщо ми знаємо, як мають бути спроектовані складні програмні системи, то чому при створенні таких систем ми стикаємося з серйозними проблемами? Як показано в другій частині, ідея про те, як боротися із складністю програм (цю ідею ми називатимемо об'єктний підхід) відносно нова. Існує, проте, ще одна, мабуть, головна причина: фізична обмеженість можливостей людини під час роботи із складними системами.
Рис. 1.1. Канонічна форма складної системи.
Коли ми починаємо аналізувати складну програмну систему, в ній виявляється багато складових частин, яка взаємодіє одна з одною різними способами, причому ні самі частини системи, ні способи їх взаємодії не виявляють жодної схожості. Це приклад неорганізованої складності. Коли ми починаємо організовувати систему в процесі її проектування, необхідно думати відразу про багато речей. Наприклад, в системі керування рухом літаків доводиться одночасно контролювати стан багатьох літальних апаратів, враховуючи такі їх параметри, як місце розташування, швидкість і курс. Під час аналізу дискретних систем необхідно розглядати великі, складні і не завжди детерміновані простори станів. На жаль, одна людина не може стежити за всім цим одночасно. Експерименти психологів, наприклад Міллера, показують, що максимальна кількість структурних одиниць інформації, за якими людський мозок може одночасно стежити, приблизно рівний семи плюс-мінус два. Ймовірно, це пов'язано з об'ємом короткострокової пам'яті у людини. Додатковим обмежуючим чинником є швидкість опрацювання мозком інформації, що поступає: на сприйняття кожної нової одиниці інформації йому вимагається близько 5 секунд.
Таким чином, ми виявилися перед серйозною дилемою. Складність програмних систем зростає, але здатність нашого мозку впоратися з цією складністю обмежена. Як же нам вийти із цього скрутного становища?