Інтеграція
29.1. Важливість вибору підходу до інтеграції
29.2. Частота інтеграції – поетапна чи інкрементна?
29.3. Стратегії інкрементної інтеграції
29.4. Щоденне складання та димові тести
Тестування під час розробки: розділ 22
Налагодження: розділ 23
Управління конструюванням: розділ 28
Термін «інтеграція» відноситься до такої операції в процесі розробки ПЗ, при якій об'єднуєте окремі програмні компоненти в єдину систему. У невеликих проектах інтеграція може зайняти один ранок і полягати в поєднанні жменьки класів. У великих — можуть знадобитися тижні чи місяці, щоб пов'язати докупи весь набір програм. Незалежно від розміру завдань у них застосовуються одні й самі принципи.
Тема інтеграції тісно переплітається із питанням послідовності конструювання. Порядок, у якому ви створюєте класи чи компоненти, впливає порядок їх інтеграції: ви можете інтегрувати те, що ще створено. Послідовності інтеграції та конструювання мають велике значення. У цьому розділі ми розглянемо обидва питання з погляду інтеграції.
29.1. Важливість вибору підходу до інтеграції
В інженерних галузях, відмінних від розробки програмного забезпечення, важливість правильної інтеграції добре відома. На північно-західному узбережжі Тихого океану, де живу, зіткнулися з драматичними наслідками поганої інтеграції, коли футбольний стадіон Університету Вашингтон частково обрушився під час будівництва (рис. 29#1).
ЧАСТИНА VI Системні питання
Мал. 29'1. Навіс над футбольним стадіоном Вашингтонського університету впав, не витримавши власної ваги під час будівництва. Він швидше за все був би досить міцним після завершення робіт, але будівництво велося у неправильномупорядку — помилка інтеграції
Не має значення, що після завершення будівництва стадіон був би доволі міцним — він мав бути таким і на інших етапах роботи. Якщо ви створюєте та інтегруєте ПЗ у неправильному порядку, його складніше кодувати, складніше тестувати та складніше налагоджувати. Якщо нічого не працює до того, як почне працювати разом, можна припустити, що проект ніколи не буде завершений. Він також може впасти під власною вагою під час конструювання: кількість дефектів може виявитися непереборною, прогрес невидимим, а складність надмірною, навіть якщо закінчений продукт був би цілком працездатний.
Оскільки інтеграція виконується після того, як розробник завершив своє тестування, і одночасно із системним тестуванням, її іноді вважають операцією, що стосується тестування. Однак вона досить складна, і тому її слід розглядати як незалежну діяльність.
Акуратна інтеграція забезпечує:
спрощену діагностику дефектів; менша кількість помилок;
менша кількість «лісів»;
раннє створення першої працюючої версії продукту;
зменшення загального часу опрацювання;
найкращі відносини із замовником;
покращення морального клімату;
збільшення шансів на завершення проекту;
надійніші оцінки графіка проекту;
більш акуратні звіти про стан;
РОЗДІЛ 29 Інтеграція
найкраща якість коду;
менше документації.
Інтеграцію часто недооцінюють, незважаючи на її важливість, і саме тому я присвятив їй окремий розділ.
29.2. Частота інтеграції – поетапна чи інкрементна?
Інтеграція програм виконується за допомогою поетапного чи інкрементного підходу.
За винятком останніх років поетапна інтеграція була нормою. Вона складалася з добре визначених етапів, наведених нижче.
1. «Модульна розробка»: проектування, кодування, тестування та налагодження кожного класу.
2. «Системна інтеграція»: об'єднання класів на одну велику систему.
3. «Системна дезінтеграція» [дякую Мейліру Пейдж # Джонсу (Meilir Page # Jones) за це дотепне зауваження]: тестування та налагодження всієї системи.
Проблема поетапної інтеграції в тому, що коли класи в системі вперше з'єднуються разом, неминуче виникають нові проблеми і їх причини можуть бути в чому завгодно. Оскільки у вас багато класів, які ніколи раніше не працювали разом, винуватцем може бути погано протестований клас, помилка в інтерфейсі між двома класами або помилка, викликана взаємодією двох класів. Усі класи перебувають під підозрою.
Невизначеність місцезнаходження будь-якої проблеми поєднується з тим фактом, що всі ці проблеми раптом проявляють себе одночасно. Це змушує вас мати справу не лише з проблемами, викликаними взаємодією класів, але й іншими помилками, які важко діагностувати, оскільки вони взаємодіють. Тому поетапну інтеграцію називають ще "інтеграцією великого вибуху" (рис. 29 # 2).
Мал. 29'2. Поетапну інтеграцію також називають інтеграцією "великого вибуху" - і заслужено!
ЧАСТИНА VI Системні питання
Поетапну інтеграцію не можна розпочинати до початку останніх стадій проекту, коли будуть розроблені та протестовані всі класи. Коли класи нарешті будуть об'єднані і виявиться велика кількість помилок, програмісти відразу вдаряться в панічну налагодження замість методичного визначення та виправлення помилок.
Для невеликих програм – ні,а для крихітних – поетапна інтеграція може бути найкращим підходом. Якщо програма складається з двох класів, поетапна інтеграція може заощадити ваш час, якщо вам пощастить. Але в більшості випадків інший підхід буде кращим.
При інкрементній інтеграції ви пишете та тестуєте маленькі ділянки програми, а потім комбінуєте ці шматочки один з одним по одному. При такому підході – по одному елементу за раз – ви виконуєте перелічені далі дії.
1. Розробляєте невелику, функціональну частину системи. Це може бути найменша функціональна частина, найскладніша частина, основна частина або їхня комбінація.
Ретельно тестуєте та налагоджуєте її. Вона послужить скелетом, у якому нарощуватимуться м'язи, нерви і шкіра, складові інші частини системи.
2. Проектуєте, кодуєте, тестуєте та налагоджуєте клас.
3. Прикріплюєте новий клас до кістяка. Тестуєте та налагоджуєте з'єднання скелета та нового класу. Переконуєшся, що ця комбінація працює, перш ніж переходити до додавання нового класу. Якщо справа зроблена, повторюєте процес, починаючи з п. 2.
У вас може виникнути бажання інтегрувати більші модулі, ніж окремий клас. Наприклад, якщо компонент був ретельно протестований і кожен з його класів пройшов міні#інтеграцію, ви можете інтегрувати весь компонент, і це все ще інкрементна інтеграція. У міру того, як ви додаєте нові шматки, система розростається і прискорюється, як розростається і прискорюється снігова грудка, що котиться з гори (рис. 29 # 3).
Мал. 29'3. Інкрементна інтеграція дає проекту рушійну силу і нагадує снігову кулю, що котиться з гори.
РОЗДІЛ 29 Інтеграція
Переваги інкрементної інтеграції
Інкрементний підхід має масупереваг перед традиційним поетапним підходом незалежно від того, яку інкрементну стратегію ви використовуєте:
Помилки можна легко виявити Коли під час інкрементної інтеграції виникає нова проблема, то очевидно, що до цього причин новий клас. Або його інтерфейс з іншою частиною програми неправильний, або його взаємодія з раніше інтегрованими класами призводить до помилки. У будь-якому випадку ви точно знаєте, де шукати проблему (рис. 29 # 4). Більше того, оскільки ви стикаєтеся з меншою кількістю проблем одночасно, ви зменшуєте ризик того, що кілька помилок взаємодіятимуть або маскуватимуть один одного. Що більше інтерфейсних помилок може виникнути, то більше переваг від інкрементної інтеграції отримають ваші проекти. Облік помилок у одному проекті показав, що 39% становили помилки міжмодульних інтерфейсів (Basili і Perricone, 1984). Оскільки розробники багатьох проектів проводять до 50% часу за налагодженням, максимізація ефективності налагодження шляхом спрощення пошуку помилок дає виграш як і продуктивність.
Мал. 29'4. При поетапній інтеграції ви об'єднуєте багато компонентів одночасно, що важко зрозуміти, де знаходиться помилка. Вона може бути в будь-якому компоненті або їх сполуках. При інкрементній інтеграції помилка
зазвичай таїться або в новому компоненті, або в місці з'єднання нового компонента та решти системи
У такому проекті система раніше стає працездатною. Коли код інтегрований і здатний виконуватися, навіть якщо система ще не придатна до використання, це виглядає так, ніби це станеться. При інкрементній інтеграції програмісти раніше бачать результати своєї роботи, тому їхній моральний стан кращий, ніж у тому випадку, коли вони підозрюють, що їхній проект може ніколине зробити перший вдих.
Ви отримуєте покращений моніторинг стану При частій інтеграції реалізована та нереалізована функціональність видно з першого погляду. Менеджери матимуть найкраще уявлення про стан проекту, бачачи, що 50% системи вже працює, а не чуючи, що кодування завершено на 99%.