PrIS

31

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

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

Структури класів і об'єктів системи разом називаються архітектурою системи.

Людські можливості і складні системи. Якщо ми знаємо, як мають бути спроектовані складні програмні системи, то чому при створенні таких систем ми стикаємося із серйозними проблемами? Як показано в другій частині, ідея про те, як боротися зі складністю програм (цю ідею ми називатимемо об'єктний підхід) відносно нова. Існує, проте, ще одна, мабуть, головна причина: фізична обмеженість можливостей людини під час роботи зі складними системами.

Коли ми починаємо аналізувати складну програмну систему, в ній виявляється багато складових частин, які взаємодіють одна з одною різними способами, причому ні самі частини системи, ні способи їх взаємодії не виявляють жодної схожості. Це приклад неорганізованої складності. Коли ми починаємо організовувати систему у процесі її проектування, необхідно враховувати відразу багато нюансів. Наприклад, у системі керування рухом літаків доводиться одночасно контролювати стан багатьох літальних апаратів, враховуючи такі їх параметри, як місце перебування, швидкість і курс. Під час аналізу дискретних систем необхідно розглядати великі, складні і не завжди детерміновані простори станів. На жаль, одна людина не може стежити за всім цим одночасно. Експерименти психологів, наприклад Міллера, показують, що максимальна кількість структурних одиниць інформації, за якими людський мозок може одночасно стежити, приблизно дорівнює семи плюс-мінус два. Ймовірно, це пов'язано з обсягом короткострокової пам'яті у людини. Додатковим обмежувальним чинником є швидкість опрацювання мозком інформації, що надходить: на сприйняття кожної нової одиниці інформації йому необхідно біля 5 секунд.

32

Отже, ми опинилися перед серйозною дилемою. Складність програмних систем зростає, але здатність нашого мозку впоратися з цією складністю обмежена. Як же нам вийти із цього скрутного становища?

1.3. Методи подолання складності

1.3.1. Роль декомпозиції

Спосіб керування складними системами був відомий ще в стародавні часи – divide et impera (розділяй і володарюй). Під час проектування складної ІС необхідно розділяти її на все менші і менші підсистеми, кожну з яких можна удосконалювати незалежно. У цьому випадку ми не перевищимо пропускної спроможності людського мозку: для розуміння будь-якого рівня системи нам необхідно одночасно тримати у пам’яті інформацію лише про небагато її частин (зовсім не про всі). Насправді, як відзначив Парнас, декомпозиція викликана складністю програмування системи, оскільки саме ця складність вимушує ділити простір станів системи.

Декомпозиція – це закріплення цілей, критеріїв їх досягнення і відповідних числових показників за структурними елементами організації різного ієрархічного рівня. Розроблені різні підходи декомпозиційних методів.

На етапі декомпозиції, що забезпечує уявлення про виниклу проблему, здійснюються:

визначення і декомпозиція загальної мети дослідження;

виділення проблеми із середовища, визначення її ближнього і дальнього оточення;

опис факторів впливу.

Найчастіше декомпозиція здійснюється шляхом побудови дерева цілей і дерева функцій. Основною проблемою при цьому є дотримання двох суперечливих принципів:

повноти — проблема має розглядатися максимально всесторонньо і детально;

простоти — все дерево має бути максимально компактним «вшир» і «углиб».

Компроміс досягається за допомогою чотирьох основоположних понять:

суттєвості — в модель включаються тільки компоненти, суттєві по відношенню до цілей аналізу;

33

елементарності — доведення декомпозиції до простого, зрозумілого результату, який можна реалізувати;

поступовій деталізації моделі;

інтеґративності — можливості введення нових елементів у зміст і продовження декомпозиції за ними на різних гілках дерева.

Структурна (алгоритмічна) декомпозиція. Більшість з нас формально навчена структурному проектуванню "зверху донизу", і ми сприймаємо декомпозицію як звичайне розділення алгоритмів, де кожний модуль системи виконує один з етапів загального процесу. На рис. 1.2 наведений як приклад один з продуктів структурного проектування: структурна схема, яка показує зв'язки між різними функціональними елементами системи. Ця структурна схема ілюструє частину програмної схеми, що змінює вміст керівного файла. Вона автоматично отримана з діаграми потоків даних спеціальною експертною системою, якій відомі правила структурного проектування.

Рис. 1.2. Алгоритмічна декомпозиція.

Об'єктно-орієнтована декомпозиція. Існує альтернативний спосіб декомпозиції. На рис. 1.3 ми розділили систему, вибравши як критерій декомпозиції належність її елементів до різних абстракцій заданої ПО. Перше ніж розділяти задачу на кроки типу Get formatted update (Отримати зміни в автовідформатованому вигляді) і Add check sum (Додати до контрольної суми), ми повинні визначити такі об'єкти як Master File (Основний файл) і Check Sum (Контрольна сума), які запозичуються зі словника ПО.

34

Рис.1.3. Об'єктно-орієнтована декомпозиція

Хоча обидві схеми вирішують одне і те саме завдання, але вони роблять це різними способами. У другій декомпозиції світ поданий сукупністю автономних дійових осіб, які взаємодіють одна з одною, щоб забезпечити поведінку системи, що відповідає вищому рівню. Get formatted update (Отримати зміни в автовідформатованому вигляді) більше не присутній як незалежний алгоритм; ця дія існує тепер як операція над об'єктом File of Updates (Файл змін). Ця операція створює інший об'єкт – Update to Card (Зміни у карті). Отже, кожний об'єкт має свою власну поведінку, і кожний з них моделює деякий об'єкт реального світу. Із цього погляду об'єкт є деякою річчю з певною поведінкою. Об'єкти щось роблять, і ми можемо, пославши їм повідомлення, попросити їх виконати певні дії. Оскільки наша декомпозиція заснована на об'єктах, а не на алгоритмах, ми називаємо її об'єктно-орієнтованою декомпозицією.

Декомпозиція: алгоритмічна чи об'єктно-орієнтована? Яка декомпозиція складної системи правильніша – алгоритмічна чи за об'єктами? У цьому запитанні є каверза, і правильна відповідь на нього: важливі обидва аспекти. Розділення за алгоритмами концентрує увагу на порядку подій, що відбуваються, а розділення за об'єктами надає особливе значення аґентам, які є або об'єктами, або суб'єктами дії. Проте ми не можемо сконструювати складну систему одночасно двома способами, тим паче, що ці способи за своєю суттю ортогональні. Ця ортогональність вивчалася з давніх часів. Пасивний погляд пропонувався Демокрітом, який стверджував, що світ складається з атомів. Ця позиція Демокріта ставила в центр всього матерію. Класичним представником іншої сторони

– активного погляду – був Геракліт, який виділяв поняття процесу. Ми повинні почати розділення системи або за алгоритмами, або за об'єктами, а потім, використовуючи отриману структуру, спробувати розглянути проблему з іншого погляду.

35

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

Приклад 1.1. Яскравим прикладом декомпозиції є процедура визначення програмних засобів, на яких студентові найкраще виконати курсову роботу із програмування. Головною задачею він для себе ставить

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

Рис. 1.4. Декомпозиція задачі визначення програмних засобів.

36

1.3.3. Роль абстракції

Вище ми посилалися на експерименти Міллера, в яких було встановлено, що зазвичай людина може одночасно сприйняти лише 7 2 одиниці інформації. Ця кількість, мабуть, не залежить від змісту інформації. Розмір нашої пам'яті накладає жорсткі обмеження на кількість інформації, яку ми можемо сприйняти, опрацювати і запам'ятати. Організовуючи надходження інформації одночасно декількома різними каналами і у вигляді послідовності окремих порцій, ми можемо позбутися цього інформаційного затору. У сучасній термінології це називають розбиттям або виділенням абстракцій.

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

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

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

1.3.4. Роль ієрархії

Іншим способом, що розширює інформаційні одиниці, є організація всередині системи ієрархій класів і об'єктів.

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

37

Деревовидна структура є найпростішою для аналізу та реалізації. Майже у всіх випадках в ній виділяються ієрархічні рівні — групи елементів, що розташовані на однаковій віддалі (вимірюваній як кількість ребер) від головного елемента (кореня дерева). Структури цього типу є надзвичайно поширеними (ієрархія проектування складної програмної системи, ієрархія цілей у складній орґанізаційній системі, ієрархія за ознакою керованості процесів в живому організмі, ієрархія у зграї тварин).

Ромбовидна структура приводить до множинної (частковий випадок

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

Існують різні типи деревовидних ієрархій [88].

1.Збалансовані (balanced) – ієрархії, в яких кількість рівнів визначена їх структурою і незмінна, і кожна гілка ієрархічного дерева містить об'єкти кожного з рівнів. Кожному виробнику автомобілів може відповідати декілька марок автомобілів, а кожній марці – декілька моделей автомобілів, тому можна говорити про трирівневу ієрархію цих об'єктів. У цьому випадку на першому рівні ієрархії розташовуються виробники, на другому – марки, а на третьому – моделі. Як неважко зрозуміти, для формування збалансованої ієрархії необхідна наявність зв'язку «один-до-багатьох» між об'єктами менш детального рівня по відношенню до об'єктів детальнішого рівня. У принципі, кожен рівень збалансованої ієрархії можна подати як окремі прості виміри, але тоді ці виміри виявляться залежними, а отже, неминуче підвищення розрідженості куба.

2.Незбалансовані (unbalanced) – ієрархії, в яких кількість рівнів може бути змінена, і кожна гілка ієрархічного дерева може містити об'єкти, що належать не до всіх рівнів, тільки до декількох перших. Необхідно зазначити, що всі об'єкти незбалансованої ієрархії належать до одного типу. Типовий приклад незбалансованої ієрархії – ієрархія типу «керівник-підлеглий», де всі об'єкти мають один і той самий тип – «Співробітник».

3.Нерівні (balanced) – ієрархії, в яких кількість рівнів визначена їх структурою і незмінна, проте, на відміну від збалансованої ієрархії, деякі гілки ієрархічного дерева можуть не містити об'єктів якогось рівня. Ієрархії такого вигляду містять такі члени, логічні «батьки» яких не перебувають на безпосередньо вищому рівні. Типовим

38

прикладом є географічна ієрархія, в якій є рівні «Країни», «Штати» і «Міста», але при цьому в наборі даних є країни, що не мають штатів або реґіонів між рівнями «Країни» і «Міста».

Типовий приклад незбалансованої ієрархії — ієрархія типу «керівник – підлеглий» (її можна побудувати, зокрема, використовуючи значення поля Прізвище_підлеглого початкового набору даних з розглянутого вище прикладу), поданого на рис. 1.5. Іноді для таких ієрархій використовується термін Parent-child hierarchy.

Різник

Васильків Петренко Іваненко Якимів

Корягіна Вакула Росленко

Рис. 1.5. Незбалансована ієрархія «керівник-підгеглий».

Існують також ієрархії, що займають проміжне положення між збалансованими і незбалансованими (вони позначаються терміном ragged

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

Нерегулярні ієрархії виникають в різних застосуваннях, зокрема в ієрархії адміністративних структур [8], ієрархії медичних діагнозів [9] і ієрархії концепцій для Web-порталів, подібних до Yahoo.

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

39

Рис. 1.6. Нерівна ієрархія.

Визначити ієрархії у складній ІС не завжди легко, оскільки це вимагає розроблення моделей багатьох об'єктів, поведінка кожного з яких може відрізнятися надзвичайною складністю. Проте після їх визначення, структура складної системи і, своєю чергою, наше розуміння її відразу багато в чому прояснюються. У розділі 14 детально розглядається природа ієрархій класів і об'єктів, а у розділі 15 описуються прийоми розпізнавання цих структур.

1.4. Про проектування складних систем

1.4.1. Інженерна справа як наука і мистецтво

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

Коли розробляється абсолютно нова система, роль інженера як художника висувається на перший план. Це відбувається постійно під час проектування програм. А тим більше під час роботи із системами, що мають зворотний зв'язок, і особливо в разі систем керування і контролю, коли нам доводиться писати програмне забезпечення, вимоги до якого нестандартні, і до того ж для спеціально сконструйованого процесора. В інших випадках, наприклад, під час створення прикладних наукових

40

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

1.4.2.Сенс проектування

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

задоволенні заданих (можливо, неформальних) функціональних специфікацій;

погодженні з обмеженнями, що накладаються устаткуванням;

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

задоволенні явних і неявних критеріїв дизайну продукту;

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

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

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