Налагодження програм — Вікіпедія
Цикл розробки програмного забезпечення |
---|
Програміст за роботою |
Діяльність і кроки |
Допоміжні дисципліни |
Практики |
Інструменти |
Стандарти та галузі знань |
Нала́годження програ́ми [1] [2] [3] [4] [5] [6] [7], в мережі рідше знева́дження[8] (англ. debugging) — методичний процес пошуку та зменшення числа помилок або дефектів у комп'ютерній програмі або електронному обладнанні з метою отримання очікуваної поведінки. Зневадження, як правило, ускладнюється, коли різні підсистеми міцно пов'язані між собою, оскільки зміни в одній частині можуть викликати помилки в іншій.
Існують різні варіанти тлумачення походження терміна англ. debugging. Серед програмістів популярна легенда, що терміни «bug» та «debugging» першою вжила Ґрейс Гоппер у 1940-х роках[9]. Коли вона працювала на комп'ютері Mark II в Гарвардському університеті, її співробітники виявили, що міль застрягла в реле і тим самим призвела до збою в роботі комп'ютера. Грейс підклеїла в щоденник міль і написала, що це перший випадок в історії, коли жучка (англ. bug — жучок, комаха) виявили насправді (actual case). Сам запис свідчить про те, що слово баг у значенні помилки в програмі було вже відоме їй. Термін «bug» в сенсі технічної помилки вживався, принаймні ще в 1878 Томасом Едісоном, і «debugging», судячи з усього, використовувався як термін в аеронавтиці перед появою комп'ютерів. В Оксфордському словнику слово «debugging» з'явилося ще за два роки, до випадку з комахою. Слова bug і debugging у вузькому значенні помилки в програмі та процесу її виправлення утвердилися впродовж 50-х років, і на початку 60-х його вживання в літературі не потребувало додаткового пояснення.
Більшість перекладних і тлумачних словників ще з радянських часів як відповідник до «debugging» вказують «налагоджування». Термін «зневадження» був запропонований О. Кочергою та Є. Мейнаровичем на початку 2000-х, імовірно, щоб уникнути неоднозначності [джерело?] з поняттям загального налагоджування програми.
Пошук і виправлення помилок, які програмісти називають багами, — трудомісткий процес. Програмістський напівжарт визначає цикл життя програми, як 1:3:1 (написання:налагодження:використання). Вади трапляються переважно через неуважність або втому програміста, але інколи через непродуманий до кінця алгоритм. Кількість багів зростає зі зростанням розміру програми, а з її ускладненням виникають нові помилки, пов'язані зі взаємодією та взаємовпливом різних модулів.
Частина багів виправляється уже на етапі написання програми. Інша частина — після незалежного тестування. Зазвичай тестування, яке проводить користувач, який не знає механізму роботи програми, дозволяє виловити нові помилки, які програмісти не помічають, бо мають схильність робити тільки «правильні дії». Ще одна частина багів проявляється уже в роботі програми і потребує пізнього латання, чому служать патчі і сервісні пакунки.
Цей розділ не містить посилань на джерела. (квітень 2013) |
Пошук помилки в програмі, як правило, — тривале і клопітке завдання. Найважливішим чинником успішності та швидкості цього процесу є, мабуть, досвід програміста, але труднощі зі зневадженням програмного забезпечення також залежать значною мірою від мови програмування. Чимало середовищ розробки програмного забезпечення мають серед своїх інструментів спеціальну програму зневаджувач. Зневаджувач є програмним інструментом, який дозволяє програмісту контролювати виконання програми, зупиняти його, знову запускати, встановлювати точки зупинки, змінювати значення змінних у пам'яті й навіть, у деяких випадках, надає можливість повернутися в минуле. Термін зневаджувач може також стосуватися програміста.
Мови програмування високого рівня, наприклад, Java, спрощують зневадження, оскільки мають спеціальні програмні засоби, як, наприклад, обробка виняткових ситуацій, що дозволяють швидше локалізувати помилку. У мов програмування нижчого рівня, таких як C або Асемблер, помилка в програмі часто може створити проблеми, що проявляються не зразу, такі, як пошкодження цілісності пам'яті, і їх набагато важче виявити, оскільки зовнішньо проблема може проявитися набагато пізніше і в несподіваній формі. В таких випадках, надзвичайно корисними є спеціальні програми на кшталт зневаджувача пам'яті.
У деяких ситуаціях можуть бути дуже корисними програмні засоби загального призначення, що прив'язані до конкретної мови. Прикладом можуть бути інструменти статичного аналізу коду. Ці інструменти виконують пошук дуже конкретних відомих (поширених та рідкісних) проблем у тексті програми. Вони дозволяють знаходити помилки, які рідко фіксуються компілятором або транслятором, оскільки вони не синтаксичні, а семантичні. Наприклад, інструкція С
if (x = foo()) bar();
підозріла. Можливо, програміст помилково використав присвоювання замість порівняння. Однак, вона є цілком легальною в С, і компілятор її пропустить.
Деякі виробники таких інструментів стверджують, що їхні програми можуть виявити понад 300 різних потенційних проблем. Такі засоби можуть бути надзвичайно корисними при перевірці дуже великих обсягів сирцевого коду, коли дуже неефективно переглядати весь код чи відстежувати всі шляхи його виконання. Типовим прикладом виявленої проблеми може бути звернення до змінної до її ініціалізації. Іншим прикладом може бути суворіша перевірка типів, якщо мова такої не має. Таким чином, ці засоби є кращими для виявлення потенційних вад, на противагу фактичним вадам. Як наслідок, ці засоби мають високий рівень помилкового спрацьовування. Давня утиліта Unix lint є одним з найстаріших прикладів засобів такого типу.
Для налагодження електронних пристроїв (наприклад, комп'ютерного обладнання), а також програмного забезпечення низького рівня (BIOS, драйвери пристроїв тощо) і вбудованих програм, застосовують такі інструменти, як осцилограф, аналізатор логіки, ICE, POST-контролери, які часто використовується і в комбінації. Вони можуть виконувати багато типових дій звичайних зневаджувачів для програмного забезпечення мікропроцесорних систем.
Часто перший крок зневадження полягає в тому, щоб спробувати відтворити проблему, тобто точно визначити ситуацію, коли програма працює неправильно. Випадок, коли програма працює неправильно завжди є відносно простим, але часто проблеми проявляються тільки при експлуатації, уже після того, як програма пройшла тестування, яке не може перевірити всі можливі ситуації. Відтворення проблеми може бути особливо нетривіальним завданням, наприклад, у випадку паралельних процесів або незвичайних помилок. Крім того, специфічне вживання програми користувачем, або незвичайне оточення може значно ускладнити відтворення проблеми.
Після того, як помилку відтворено, потрібно виділити ту частину програми, де виникає збій, щоб працювати тільки з нею. Часто достатньо обмежитися тільки кількома рядами коду. Таке спрощення можна зробити вручну, за допомогою підходу «розділяй і володарюй». Програміст пробує вилучити деякі частини програми і перевіряє чи проблема все ще існує. При роботі з програмами, що використовують графічному інтерфейсі користувача, програміст спрощуватиме вікно програми, прибираючи контрольні елементи й перевіряючи, чи помилка все ще залишається. Для автоматизації цього процесу може використовуватися зневадження дельтою[10].
Цей розділ не містить посилань на джерела. (квітень 2013) |
Після того, як випробування випадку спрощено достатньо, програміст може розпочати пошук та виправлення помилки. Це можна робити або вручну, або з використанням зневаджувача. Поширеним є вставляння в програму додаткових інструкції, що регулярно роздруковували б інформацію про хід виконання програми. Такий метод називається трасуванням. У простих випадках трасування — лише декілька інструкцій виводу, що показує значення змінних в певних точках виконання програми.
Наприклад,
#ifdef DEBUG printf ("Перед викликом foo x= %d\n", x); #endif x = foo(); #ifdef DEBUG printf ("Після виклику foo x= %d\n", x); #endif
Можна використати зневаджувач, який дає доступ до стану програми (значення змінних, стек викликів) і відстежити походження помилки. Якщо мова програмування використовує компілятор, то зазвичай у бінарному коді програми вже втрачено відповідність між інструкціями процесору та рядками тексту програми. Тому для зневаджувача програму потрібно відкомпілювати в спеціальному режимі, де така відповідність збережена. При цьому розмір бінарного файлу програми зростає, а її виконання сповільнюється. Після того як помилку знайдено й виправлено, відповідний файл потрібно відкомпілювати в звичайному режимі. Зазвичай, при розробці програмного забезпечення в інтегрованому середовищі режим зневадження використовується за умовчанням, а перед поставкою програмного забезпечення замовнику його відключають.
Цей розділ не містить посилань на джерела. (квітень 2013) |
Іноді помилку можна знайти, аналізуючи дамп процесу. Таке зневадження називають посмертним (post mortem). Деякі операційні системи створюють дамп (відбиток пам'яті процесу) при аварійному завершенні програми, програміст може утворити його вручну, за потреби, наприклад командою dump операційної системи Unix. Для зіставлення пам'яті зі змінними програми бажано мати таблицю символів. В роботі допомагають спеціальні програми — аналізатори дампу. Дебаґери на зразок gdb теж можуть зчитати і проаналізувати дамп.
Шукати помилку можна, спостерігаючи за процесом з іншого комп'ютера. Для запуску віддаленого зневадження зневаджувач підключається до віддаленої системи через мережу. Після того, як зв'язок встановлено, зневаджувач може контролювати виконання програми на віддаленій системі та отримувати інформацію про її стан.
Антизневадження є «застосування в комп'ютерному коді одного або декількох методів, що перешкоджають спробам зворотної розробки та зневадження цільового процесу».[11] Види підходів:
- На основі API: перевірка на наявність зневаджувачів, використовуючи інформацію про систему
- На основі обробки виняткових ситуацій: перевіряється, чи йде перехоплення виняткових ситуацій
- Блокування процесів і потоків: перевіряється, чи були маніпуляції з блокуванням процесу або потоків
- Зміна коду: перевіряється чи були зміни в коді внесені зневаджувачем для обробки програмних точок зупину
- На основі обладнання та регістрів: перевіряються апаратні точки зупину і регістри процесора
- Час і латентність: перевіряється час виконання інструкцій
Зневадження може бути перешкодою при використанні одного або кількох з вищезазначених методів. Є достатньо багато методів антизневадження для захисту програмного забезпечення від більшості загроз.[12]
- ↑ Короткий тлумачний словник з інформатики та інформаційних систем для економістів / Л. С. Козловська, Н. М. Поліщук, К.: КНЕУ, 2004, С. 21: налагоджування (рос. налаживание, англ. debugging) — процес виявлення та усунення помилок у комп'ютерних програмах або обладнанні;
- ↑ Англо-український тлумачний словник з обчислювальної техніки, інтернету і програмування. К., 2006, С. 146: debugging — 1. налагодження # пошук і виправлення помилок у розроблюваній програмі.
- ↑ Коллін С. М. Г. Англо-український словник комп'ютерних термінів / Перекл. В. Воробйов. — Х., 2002. — С. 19: adjust (регулювати, настроювати); adjustment (регулювання настроювання); С. 126. debug (налагоджувати, усувати неполадки) дієсл. тестування програми для виявлення і виправлення всіх неполадок і помилок… debugger (налагоджувач, програма налагодження) ім. програмне забезпечення, що дозволяє програмістові знаходити несправності та помилки в програмі…
- ↑ Короткий англо-український тлумачний словник з комп'ютерної техніки / Укл. Р. Сіренко та ін. — Львів: ЛНУ, 2005. — С. 22: debugging — налагодження, пошук та виправлення помилок у програмі для комп'ютера.
- ↑ Саврук М. П. Українсько-англійський науково-технічний словник: понад 120 000 слів та словосполучень / НАН України, Фізико-механічний ін-т ім. Г. В. Карпенка. — К. : Наукова думка, 2008. — (Словники України). — С. 460—461: налагоджування, налагодження — (регулювання) adjustment; мат. setting-up; автотр. (двигуна, карбюратора) tune-up, tunung-up; комп. debugging, checkout; ~ верстата setting-up of a machine-tool; ~ двигуна engine tune-up; ~ ЕОМ (computer) debugging; ~ програми (programme) checkout / debugging/; автономне ~ off-line debugging; дистанційне ~ remote debugging; експлуатаційне ~ field adjustment; комплексне ~ complex debugging; покрокове ~ single-step debugging; попереднє ~ комп. prestage. Налагоджувач — комп. (програма) debugger; діалоговий ~ console /interactive/ debugger; моделювальний ~ simulation debugger; символьний ~ symbolic debugger.
- ↑ Тлумачний словник сучасної української мови: Фахова лексика: Бл. 20000 сл. / Заг. ред. В. Калашника. — Х, 2009. — С. 222—223: налагоджувач. У системах програмування — програма, призначена для аналізу функціонування та для налагоджування іншої програми.
- ↑ Тлумачний словник з інформатики / Заг. ред. акад. Г. Г. Півняка. — Д.: Нац. гірн. ун-т, 2010. — С. 68: debugger (налагоджувач) (див. дебаггер); Debugging (налагодження). Процес знаходження і виправлення помилок у програмі. С. 310: дебаггер (debugger) (див. баг) син. — налагоджувач, програма налагодження, налагоджувальна програма… С. 441: налагодження (debugging) (див. дебаггер) Процес виконання програми з метою виявлення помилок.
- ↑ Англійсько-український словник: Математика та кібернетика / Є. Мейнарович, М. Кратко — К.: Перун, 2010. — 560 с.: debugging = [ˌdi:'bʌgɪŋ] знева́джування/знева́дження, усува́ння/усу́нення вад; налаго́джування/налаго́дження; вилуча́ння/ви́лучення вад.
У Вікіпедії цей менш поширений термін вживається за домовленістю дописувачів. - ↑ Grace Hopper [Архівовано 5 березня 2016 у Wayback Machine.] з FOLDOC
- ↑ Zeller, p. 123.
- ↑ Архівована копія. Архів оригіналу за 19 жовтня 2016. Процитовано 18 січня 2009.
{{cite web}}
: Обслуговування CS1: Сторінки з текстом «archived copy» як значення параметру title (посилання) - ↑ ((DOI | 10.1109/MSP.2007.71))
- Andreas Zeller: Why Programs Fail: A Guide to Systematic Debugging, Morgan Kaufmann, 2005. ISBN 1-55860-866-4
- Додаткові матеріали
- David J. Agans: Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems, AMACOM, 2002. ISBN 0-8144-7168-4
- Bill Blunden: Software Exorcism: A Handbook for Debugging and Optimizing Legacy Code, APress, 2003. ISBN 1-59059-234-4
- Ann R. Ford, Toby J. Teorey: Practical Debugging in C++, Prentice Hall, 2002. ISBN 0-13-065394-2
- Thorsten Grötker, Ulrich Holtmann, Holger Keding, Markus Wloka, The Developer's Guide to Debugging, Springer, 2008. ISBN 1-40205-539-0
- Robert C. Metzger: Debugging by Thinking: A Multidisciplinary Approach, Digital Press, 2003. ISBN 1-55558-307-5
- Glenford J Myers: *The Art of Software Testing, John Wiley & Sons inc, 2004. ISBN 0-471-04328-1
- John Robbins: Debugging Applications, Microsoft Press, 2000. ISBN 0-7356-0886-5
- Matthew A. Telles, Yuan Hsieh: The Science of Debugging, The Coriolis Group, 2001. ISBN 1-57610-917-8
- Dmitry Vostokov: Memory Dump Analysis Anthology, Volume 1, OpenTask, 2008. ISBN 978-0-9558328-0-2
- Debugging tools, каталог посилань Open Directory Project
- Algorithmic and Automatic Debugging — велика збірка посилань на засоби та методи зневадження
- Crash dump analysis patterns — ґрунтовна стаття по аналізу та знаходження вад в аварійних дампах
- Debugging Tools for Windows
- GDB: The GNU Project Debugger
- DDD/DataDisplayDebugger
Це незавершена стаття про програмування. Ви можете допомогти проєкту, виправивши або дописавши її. |