Налагодження програми — найбільш трудомісткий та найменш придатний до формалізації елемент роботи програміста. Особливість його полягає в тому, що необхідність налагодження виникає в незапланованих випадкових подіях, тому неможливо розробити єдину конструктивну методику налагодження. Забезпечити правильність програми можна двома шляхами: профілактичними заходами на всіх етапах розробки програми для зменшення ймовірності появи помилок у тексті програми, а також теоретичною та експериментальною перевіркою створеного тексту програми.
Проаналізуємо джерела помилок:
1) Неправильність або неоднозначність вхідного опису. Звинувачувати у цих помилках можна постановника задачі, а виправляти їх змушений буде програміст (може, аж на етапі супроводження).
2) Неправильність тлумачення вхідного опису або помилки проектування.
Перелічені помилки мають змістовний характер, тому спричиняють помилки алгоритму обробки інформації.
3) Помилки етапу кодування можуть бути змістовного характеру та синтаксичні, яких припускається програміст при написанні тексту програми, або при трансляції отримується програма, не адекватна вхідному модулю.
Звичайно ж, краще запобігти таким помилкам, ніж знайти їх та виправити. Треба вжити всіх технологічних заходів, щоб не припуститися помилок або виявити їх на етапах, що передують кодуванню. Отже, якщо доведено коректність постановки задачі, тобто відповідність результативної інформації загальним специфікаціям, то тестування складеного алгоритму перевірить, наскільки він забезпечує деталізовані специфікації окремими модулями програми. Тестування програми — це перевірка її шляхом створення середовища, еквівалентного реальному, в якому повинна функціонувати програма. Це середовище має дві складові: програмну та інформаційну. Програмну ми обговоримо пізніше. Інформаційна складова містить вхідну оброблювану інформацію, вхідну управлінську інформацію задачі та вихідні дані. Перевірка здійснюється в умовах такої різноманітності середовища, коли перевіряється кожна можлива послідовність операторів, що з’єднує початок і кінець програми. Підмножину середовища, необхідну і достатню для повної перевірки програми, назвемо повним тестом програми. Якщо не виконується умова необхідності, то при тестуванні повторюватимемо окремі шляхи кілька зайвих разів. Якщо не виконується умова достатності, деякі шляхи залишаться неперевіреними. Це дуже складна і важлива задача — знайти повний тест, щоб користуватись ним упродовж усього життєвого циклу програми, і розв’язується вона за допомогою копіткого аналізу тексту програми чи проекту або аналізу середовища (може використовуватись змішаний варіант). Однак аналіз програми не гарантує виявлення помилок, припущених на етапах створення вихідних описів та проектування. Тому найчастіше тест складають на основі аналізу середовища та функції обробки, які разом визначають клас задач.
Принципове значення має послідовність перевірки модулів: від верху до низу або від низу до верху.
Якщо перевірка здійснюється від низу до верху, то відбувається локальне тестування окремих модулів найнижчого рівня, потім сумісне тестування груп модулів, інформаційно пов’язаних між собою, потім комплексне тестування всієї програми. На другому й третьому етапах тестування використовується інформація, отримана на першому етапі, та інформація, що імітує зв’язки між модулями, — саме вона і є програмною складовою середовища тестування.
При перевірці програми від верху до низу спочатку перевіряється модуль найвищого рівня, а потім до нього послідовно підключаються модулі більш низьких рівнів — аж до найнижчого. Складають дані для перевірки всієї програми в цілому, а для перевірки кожного окремого модуля імітують частину середовища, що відображає зв’язок з модулями нижчих рівнів.
Так чи інакше помилки виявляються, локалізуються, діагностуються та виправляються. Отримавши після тестування правильну програму, ми можемо бути впевненими не в абсолютній безпомилковості програми, а в її правильності відносно обраного тесту. Деякі помилки можуть бути виявлені на етапах використання та супроводження.
Для полегшення процесу налагодження розроблено велику кількість різноманітних засобів: вбудована в транслятор діагностика синтаксичних помилок, програми трасировки, спеціальні програми, використовувані у кожній технології програмування.
8.1.7. Використання інтерактивних методів у розробці
та налагодженні програм
Значно підвищити оперативність праці програміста можна за рахунок застосування інтерактивних методів, що забезпечують активну взаємодію програміста та ЕОМ. Існує велика кількість різних розвинутих систем інтерактивної роботи, але кожна має набір таких елементарних дій: коригування текстів, написаних вихідною мовою, видалення та дозапис рядків тексту, їх нумерація, об’єднання різних програмних текстів, виділення частин, перейменування розділів, де зберігаються тексти, створення копій і т.ін. Це дозволяє коригувати та використовувати типові програмні заготівки, виконувати деякі обслуговуючі функції тощо. Рівень автоматизації виконання перелічених дій у різних інтерактивних системах різний. Але всі вони мають і спільні риси. Отже, можна сформулювати їх, а також надати прості поради (на рівні здорового глузду), як готуватись до діалогу з ЕОМ та працювати в інтерактивному режимі.
Перш за все перелічимо типи діалогу, які використовуються в діалоговій системі (окремо чи в комбінації):
— меню;
— запити, що потребують відповіді ТАК / НІ;
— шаблон;
— простий запит;
— команда;
— взаємодія природною мовою.
Кожний із них має свої переваги та недоліки, особливості реалізації, аналіз яких дозволяє в кожному конкретному випадку обрати потрібний тип для ефективного ведення діалогу.
Діалог ЛЮДИНА – ЕОМ — це різновид діалогу взагалі. Суб’єкти діалогу: людина та діалогова система (ДC). Здійснюється обмін інформацією в інтерактивному режимі згідно з мовою та формою спілкування.
До початку сеансу необхідно з’ясувати:
— назву ДC, її функціональні можливості, режим роботи;
— до кого слід звернутися у випадку виникнення організаційних, технологічних та інших ускладнень; який прийнято порядок консультації;
— чи придатна ця ДC для розв’язання конкретної задачі;
— які ще ДC доступні для використання;
— до освоєння ДC краще її не критикувати, бо можна опинитись у незручному становищі;
— як виходити з тупикових ситуацій.
Тільки після вивчення ДC, підготувавши всі вихідні матеріали до 1-го сеансу роботи, можна замовляти машинний час та інші ресурси й братися до роботи.
Під час роботи з ДC:
— треба пам’ятати, що ДC є захищеною від помилкових дій користувача, які можуть її зруйнувати або пошкодити користувачеві (хоча, якщо ДC все ж таки зруйновано, то це погана ДC);
— якщо виникає незрозуміла ситуація, то необхідно викликати функції допомоги, які є у кожній ДC;
— слід пам’ятати, що ДC допомагає тільки в рутинній частині роботи, а творча частина та прийняття рішень залишаються користувачеві;
— дуже зручно, що користувач може задавати одне й те саме питання скільки завгодно разів, як правило, на стан діалогу це не вплине;
— не змагайтесь з ДC у швидкості роботи, працюйте у своєму звичному темпі;
— нові повідомлення ДC треба вивчити, виділити ті, що впливають на подальший хід діалогу;
— якщо невдача неодноразова, то необхідно переформувати запит до ДC, підійти з іншого боку, або розбити запит на декілька більш простих запитів;
— якщо знайдено вдалу послідовність дій в якомусь режимі, зробіть її аналогію в інших режимах у схожих ситуаціях;
— якщо ви все ж таки опинились у глухому куті, то доцільно припинити марні спроби, щоб не зіпсувати отримані результати;
— не треба вирішувати всі проблеми, сидячи перед екраном, це малоефективно; краще роздрукувати результати, стани задачі (текст, проміжні результати, результати тестування і т.ін.);
— після закінчення роботи з ДC необхідно проаналізувати результати, хід діалогу (особливо якщо результат негативний), знайти помилки, накреслити шляхи їх усунення, більш детально ознайомитись із ДC, проконсультуватися зі спеціалістами, розробити нову стратегію діалогу та підготуватись до наступного сеансу.
