26. Возможности интегрированных средств отладки.

Методы и средства получения дополнительной информации

Для получения дополнительной информации об ошибке можно выпол­нить добавочные тесты или использовать специальные методы и средства:

• отладочный вывод;

• интегрированные средства отладки;

• независимые отладчики.

Интегрированные средства отладки. Большинство современных сред программирования (Delphi, Builder С++, Visual Studio и т. д.) включают сред­ства отладки, которые обеспечивают максимально эффективную отладку. Они позволяют:

• выполнять программу по шагам, причем как с заходом в подпрограм­мы, так и выполняя их целиком;

• предусматривать точки останова;

выполнять программу до оператора, указанного курсором;

• отображать содержимое любых переменных при пошаговом выполне­нии;

• отслеживать поток сообщений и т. п.

На рис. 11.5 покачан вид программы в момент перехода в режим поша­гового выполнения по достижении точки останова в Delphi. В этот момент программист имеет возможность посмотреть значения интересующих его переменных.

Применять интегрированные средства в рамках среды достаточно про­сто. Используют разные приемы в зависимости от проявлений ошибки. Мели получено сообщение об ошибке, то сначала уточняют, при выпол­нении какого оператора программы оно получено. Для этого устанавливаю! точку останова в начало фрагмента, в котором проявляется ошибка, и выпол­няют операторы в пошаговом режиме до проявления ошибки.

Аналогично поступают при «зависании» компьютера.

Если получены неправильные результаты, то локализовать, ошибку обычно существенно сложнее. В этом случае сначала определяю! фрагмент, при выполнении которого получаются неправильные результаты. Для этого последовательно проверяют интересующие значения в узловых точках. Обнаружив значения, отличающиеся от ожидаемых, по шагам транслируют соответствующий фрагмент до выявления оператора, выполнение которого дает неверный результат.

27. Важные особенности процесса отладки по.

Следует иметь в виду, что процесс отладки можно существенно упрос­тить, если следовать основным рекомендациям структурного подхода к про­граммированию:

• программу наращивать «сверху-вниз», от интерфейса к обрабатываю­щим подпрограммам, тестируя ее по ходу добавления подпрограмм;

• выводить пользователю вводимые им данные для контроля и прове­рять их на допустимость сразу после ввода;

• предусматривать вывод основных данных во всех узловых точках ал­горитма (ветвлениях, вызовах подпрограмм).

Кроме того, следует более тщательно проверять фрагменты программ­ного обеспечения, где уже были обнаружены ошибки, так как вероятность ошибок в этих местах по статистике выше. Это вызвано следующими причи­нами. Во-первых, ошибки чаще допускают в сложных местах или в тех случаях, если спецификации на реализуемые операции недостаточно прора­ботаны. Во-вторых, ошибки могут быть результатом того, что программист устал, отвлекся или плохо себя чувствует. В-третьих, как уже упоминалось выше, ошибки часто появляются в результате исправления уже найденных ошибок.

Возвращаясь к рис. 11.2, можно отметить, что проще всего обычно ис­кать ошибки определения данных и ошибки накопления погрешностей: их причины локализованы в месте проявления. Логические ошибки искать су­щественно сложнее. Причем обнаружение ошибок проектирования требует возврата на предыдущие этапы и внесения соответствующих изменений в проект. Ошибки кодирования бывают как простые, например использование неинициализированной переменной, так и очень сложные, например ошиб­ки, связанные с затиранием памяти.

Затиранием памяти называют ошибки, приводящие к тому, что в резуль­тате записи некоторой информации не на свое место в оперативной памяти, затираются фрагменты данных или даже команд программы. Ошибки подоб­ного рода обычно вызывают появление сообщения об ошибке. Поэтому оп­ределить фрагмент, при выполнении которого ошибка проявляется, неслож­но. А вот определение фрагмента программы, который затирает память - сложная задача, причем чем длиннее программа, тем сложнее искать ошибки такого рода. Именно в этом случае часто прибегают к удалению из програм­мы частей, хотя это и не обеспечивает однозначного ответа на вопрос, в ка­кой из частей программы находится ошибка. Эффективнее попытаться опре­делить операторы, которые записывают данные в пямять не по имени, а по адресу, и последовательно их проверить. Особое внимание при этом следует обращать на корректное распределение памяти под данные.