ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 20.11.2019
Просмотров: 9468
Скачиваний: 184
10.4.
Общая
методика
отладки
программного
обеспечения
Суммируя
все
сказанное
выше
,
можно
предложить
следующую
методику
отладки
программного
обеспечения
,
написанного
на
универсальных
языках
программирования
для
выполнения
в
операционных
системах
MS DOS
и
Win32:
1
этап
-
изучение
проявления
ошибки
-
если
выдано
какое
-
либо
сообщение
или
выданы
неправильные
или
неполные
результаты
,
то
необходимо
их
изучить
и
попытаться
понять
,
какая
ошибка
могла
так
проявиться
.
При
этом
используют
индуктивные
и
дедуктивные
методы
отладки
.
В
результате
выдвигают
версии
о
характере
ошибки
,
которые
необходимо
проверить
.
Для
этого
можно
применить
методы
и
средства
получения
дополнительной
информации
об
ошибке
.
Если
ошибка
не
найдена
или
система
просто
«
зависла
»,
переходят
ко
второму
этапу
.
2
этап
-
локализация
ошибки
-
определение
конкретного
фрагмента
,
при
выполнении
которого
произошло
отклонение
от
предполагаемого
вычислительного
процесса
.
Локализация
может
выполняться
:
•
путем
отсечения
частей
программы
,
причем
,
если
при
отсечении
некоторой
части
программы
ошибка
пропадает
,
то
это
может
означать
как
то
,
что
ошибка
связана
с
этой
частью
,
так
и
то
,
что
внесенное
изменение
изменило
проявление
ошибки
;
•
с
использованием
отладочных
средств
,
позволяющих
выполнить
интересующих
нас
фрагмент
программы
в
пошаговом
режиме
и
получить
дополнительную
информацию
о
месте
проявления
и
характере
ошибки
,
например
,
уточнить
содержимое
указанных
переменных
.
При
этом
если
были
получены
неправильные
результаты
,
то
в
пошаговом
режиме
проверяют
ключевые
точки
процесса
формирования
данного
результата
.
Как
подчеркивалось
выше
,
ошибка
не
обязательно
допущена
в
том
месте
,
где
она
проявилась
.
Если
в
конкретном
случае
это
так
,
то
переходят
к
следующему
этапу
.
3
этап
-
определение
причины
ошибки
-
изучение
результатов
второго
этапа
и
формирование
версий
возможных
причин
ошибки
.
Эти
версии
необходимо
проверить
,
возможно
,
используя
отладочные
средства
для
просмотра
последовательности
операторов
или
значений
переменных
.
4
этап
-
исправление
ошибки
-
внесение
соответствующих
изменений
во
все
операторы
,
совместное
выполнение
которых
привело
к
ошибке
.
5
этап
-
повторное
тестирование
-
повторение
всех
тестов
с
начала
,
так
как
при
исправлении
обнаруженных
ошибок
часто
вносят
в
программу
новые
.
Следует
иметь
в
виду
,
что
процесс
отладки
можно
существенно
упростить
,
если
следовать
основным
рекомендациям
структурного
подхода
к
программированию
:
•
программу
наращивать
«
сверху
-
вниз
»,
от
интерфейса
к
обрабатывающим
подпрограммам
,
тестируя
ее
по
ходу
добавления
подпрограмм
;
•
выводить
пользователю
вводимые
им
данные
для
контроля
и
проверять
их
на
допустимость
сразу
после
ввода
;
•
предусматривать
вывод
основных
данных
во
всех
узловых
точках
алгоритма
(
ветвлениях
,
вызовах
подпрограмм
).
Кроме
того
,
следует
более
тщательно
проверять
фрагменты
программного
обеспечения
,
где
уже
были
обнаружены
ошибки
,
так
как
вероятность
ошибок
в
этих
местах
по
статистике
выше
.
Это
вызвано
следующими
причинами
.
Во
-
первых
,
ошибки
чаще
допускают
в
сложных
местах
или
в
тех
случаях
,
если
спецификации
на
реализуемые
операции
недостаточно
проработаны
.
Во
-
вторых
,
ошибки
могут
быть
результатом
того
,
что
программист
устал
,
отвлекся
или
плохо
себя
чувствует
.
В
-
третьих
,
как
уже
упоминалось
выше
,
ошибки
часто
появляются
в
результате
исправления
уже
найденных
ошибок
.
Возвращаясь
к
рис
. 10.2,
можно
отметить
,
что
проще
всего
обычно
искать
ошибки
определения
данных
и
ошибки
накопления
погрешностей
:
их
причины
локализованы
в
месте
проявления
.
Логические
ошибки
искать
существенно
сложнее
.
Причем
обнаружение
ошибок
проектирования
требует
возврата
на
предыдущие
этапы
и
внесения
соответствующих
изменений
в
проект
.
Ошибки
кодирования
бывают
как
простые
,
например
,
использование
неинициализированной
переменной
,
так
и
очень
сложные
,
например
,
ошибки
,
связанные
с
затиранием
памяти
.
Затиранием
памяти
называют
ошибки
,
приводящие
к
тому
,
что
в
результате
записи
некоторой
информации
не
на
свое
место
в
оперативной
памяти
,
затираются
фрагменты
данных
или
даже
команд
программы
.
Ошибки
подобного
рода
обычно
вызывают
появление
сообщения
об
ошибке
.
Поэтому
определить
фрагмент
,
при
выполнении
которого
ошибка
проявляется
,
несложно
.
А
вот
определение
фрагмента
программы
,
который
затирает
память
-
сложная
задача
,
причем
,
чем
длиннее
программа
,
тем
сложнее
искать
ошибки
такого
рода
.
Именно
в
этом
случае
часто
прибегают
к
удалению
из
программы
частей
,
хотя
это
и
не
обеспечивает
однозначного
ответа
на
вопрос
,
в
какой
из
частей
программы
находится
ошибка
.
Эффективнее
попытаться
определить
операторы
,
которые
записывают
данные
в
память
не
по
имени
,
а
по
адресу
,
и
последовательно
их
проверить
.
Особое
внимание
при
этом
следует
обращать
на
корректное
распределение
памяти
под
данные
.
Контрольные
вопросы
1.
Какой
процесс
называют
отладкой
?
В
чем
его
сложность
?
2.
Назовите
основные
типы
ошибок
.
Как
они
проявляются
при
выполнении
программы
?
3.
Перечислите
основные
методы
отладки
.
В
чем
заключается
различие
между
ними
?
Возьмите
любую
программу
,
содержащую
ошибки
,
и
попробуйте
найти
ошибку
,
используя
каждый
из
перечисленных
методов
.
Какой
метод
для
вас
проще
и
естественней
и
почему
?
4.
Какие
средства
получения
дополнительной
информации
об
ошибках
вы
знаете
?
Вспомните
,
какие
ошибки
вы
искали
дольше
всего
и
почему
.
В
каких
случаях
дополнительная
информация
позволяет
найти
ошибку
?
11.
СОСТАВЛЕНИЕ
ПРОГРАММНОЙ
ДОКУМЕНТАЦИИ
Составление
программной
документации
-
очень
важный
процесс
.
Стандарт
,
определяющий
процессы
жизненного
цикла
программного
обеспечения
,
даже
предусматривает
специальный
процесс
,
посвященный
указанному
вопросу
.
При
этом
на
каждый
программный
продукт
должна
разрабатываться
документация
двух
типов
:
для
пользователей
различных
групп
и
для
разработчиков
.
Отсутствие
документации
любого
типа
для
конкретного
программного
продукта
не
допустимо
.
При
подготовке
документации
не
следует
забывать
,
что
она
разрабатывается
для
того
,
чтобы
ее
можно
было
использовать
,
и
потому
она
должна
содержать
все
необходимые
сведения
.
11.1.
Виды
программных
документов
К
программным
относят
документы
,
содержащие
сведения
,
необходимые
для
разработки
,
сопровождения
и
эксплуатации
программного
обеспечения
.
Документирование
программного
обеспечения
осуществляется
в
соответствии
с
Единой
системой
программной
документации
(
ГОСТ
19.XXX).
Так
ГОСТ
19.101-77
устанавливает
виды
программных
документов
для
программного
обеспечения
различных
типов
.
Ниже
перечислены
основные
программные
документы
по
этому
стандарту
и
указано
,
какую
информацию
они
должны
содержать
.
Спецификация
должна
содержать
перечень
и
краткое
описание
назначения
всех
файлов
программного
обеспечения
,
в
том
числе
и
файлов
документации
на
него
,
и
является
обязательной
для
программных
систем
,
а
также
их
компонентов
,
имеющих
самостоятельное
применение
.
Ведомость
держателей
подлинников
(
код
вида
документа
— 05)
должна
содержать
список
предприятий
,
на
которых
хранятся
подлинники
программных
документов
.
Необходимость
этого
документа
определяется
на
этапе
разработки
и
утверждения
технического
задания
только
для
программного
обеспечения
со
сложной
архитектурой
.
Текст
программы
(
код
вида
документа
- 12)
должен
содержать
текст
программы
с
необходимыми
комментариями
.
Необходимость
этого
документа
определяется
на
этапе
разработки
и
утверждения
технического
задания
.
Описание
программы
(
код
вида
документа
- 13)
должно
содержать
сведения
о
логической
структуре
и
функционировании
программы
,
Необходимость
данного
документа
также
определяется
на
этапе
разработки
и
утверждения
технического
задания
.
Ведомость
эксплуатационных
документов
(
код
вида
документа
- 20)
должна
содержать
перечень
эксплуатационных
документов
на
программу
,
к
которым
относятся
документы
с
кодами
:
30, 31, 32, 33, 34, 35, 46.
Необходимость
этого
документа
также
определяется
на
этапе
разработки
и
утверждения
технического
задания
.
Формуляр
(
код
вида
документа
- 30)
должен
содержать
основные
характеристики
программного
обеспечения
,
комплектность
и
сведения
об
эксплуатации
программы
.
Описание
применения
(
код
вида
документа
- 31)
должно
содержать
сведения
о
назначении
программного
обеспечения
,
области
применения
,
применяемых
методах
,
классе
решаемых
задач
,
ограничениях
для
применения
,
минимальной
конфигурации
технических
средств
.
Руководство
системного
программиста
(
код
вида
документа
- 32)
должно
содержать
сведения
для
проверки
,
обеспечения
функционирования
и
настройки
программы
на
условия
конкретного
применения
.
Руководство
программиста
(
код
вида
документа
- 33)
должно
содержать
сведения
для
эксплуатации
программного
обеспечения
.
Руководство
оператора
(
код
вида
документа
- 34)
должно
содержать
сведения
для
обеспечения
процедуры
общения
оператора
с
вычислительной
системой
в
процессе
выполнения
программного
обеспечения
.
Описание
языка
(
код
вида
документа
- 35)
должно
содержать
описание
синтаксиса
и
семантики
языка
.
Руководство
по
техническому
обслуживанию
(
код
вида
документа
- 46)
должно
содержать
сведения
для
применения
тестовых
и
диагностических
программ
при
обслуживании
технических
средств
.
Программа
и
методика
испытаний
(
код
вида
документа
- 51)
должны
содержать
требования
,
подлежащие
проверке
при
испытании
программного
обеспечения
,
а
также
порядок
и
методы
их
контроля
.
Пояснительная
записка
(
код
вида
документа
-81)
должна
содержать
информацию
о
структуре
и
конкретных
компонентах
программного
обеспечения
,
в
том
числе
схемы
алгоритмов
,
их
общее
описание
,
а
также
обоснование
принятых
технических
и
технико
-
экономических
решений
.
Составляется
на
стадии
эскизного
и
технического
проекта
.
Прочие
документы
(
коды
вида
документа
- 90-99)
могут
составляться
на
любых
стадиях
разработки
,
т
.
е
.
на
стадиях
эскизного
,
технического
и
рабочего
проектов
.
Допускается
объединять
отдельные
виды
эксплуатационных
документов
,
кроме
формуляра
и
ведомости
.
Необходимость
объединения
указывается
в
техническом
задании
,
а
имя
берут
у
одного
из
объединяемых
документов
.
Например
,
в
настоящее
время
часто
используется
эксплуатационный
документ
,
в
который
отчасти
входит
руководство
системного
программиста
,
программиста
и
оператора
.
Он
называется
«
Руководство
пользователя
» (
см
. § 11.3).
Рассмотрим
наиболее
важные
программные
документы
более
подробно
.
11.2.
Пояснительная
записка
Пояснительная
записка
должна
содержать
всю
информацию
,
необходимую
для
сопровождения
и
модификации
программного
обеспечения
:
сведения
о
его
структуре
и
конкретных
компонентах
,
общее
описание
алгоритмов
и
их
схемы
,
а
также
обоснование
принятых
технических
и
технико
-
экономических
решений
.
Содержание
пояснительной
записки
по
стандарту
(
ГОСТ
19.404-79)
должно
выглядеть
следующим
образом
:
•
введение
;
•
назначение
и
область
применения
;
•
технические
характеристики
;
•
ожидаемые
технико
-
экономические
показатели
;
•
источники
,
используемые
при
разработке
.
В
разделе
Введение
указывают
наименование
программы
и
документа
,
на
основании
которого
ведется
разработка
.
В
разделе
Назначение
и
область
применения
указывают
назначение
программы
и
дают
краткую
характеристику
области
применения
.
Раздел
Технические
характеристики
должен
содержать
следующие
подразделы
:
•
постановка
задачи
,
описание
применяемых
математических
методов
и
допущений
и
ограничений
,
связанных
с
выбранным
математическим
аппаратом
;
•
описание
алгоритмов
и
функционирования
программы
с
обоснованием
принятых
решений
;
•
описание
и
обоснование
выбора
способа
организации
входных
и
выходных
данных
;
•
описание
и
обоснование
выбора
состава
технических
и
программных
средств
на
основании
проведенных
расчетов
или
анализов
.
В
разделе
Ожидаемые
технико
-
экономические
показатели
указывают
технико
-
экономические
показатели
,
обосновывающие
преимущество
выбранного
варианта
технического
решения
.
В
разделе
Источники
,
использованные
при
разработке
,
указывают
перечень
научно
-
технических
публикаций
,
нормативно
-
технических
документов
и
других
научно
-
технических
материалов
,
на
которые
есть
ссылки
в
исходном
тексте
.
Пояснительная
записка
составляется
профессионалами
в
области
разработки
программного
обеспечения
и
для
специалистов
того
же
уровня
квалификации
.
Следовательно
,
в
ней
уместно
использовать
специальную
терминологию
,
ссылаться
на
специальную
литературу
и
т
.
п
.
11.3.
Руководство
пользователя
Как
уже
указывалось
выше
,
в
настоящее
время
часто
используют
еще
один
эксплуатационный
документ
,
в
который
отчасти
входит
руководство
системного
программиста
,
программиста
и
оператора
.
Этот
документ
называют
Руководством
пользователя
.
Появление
такого
документа
явилось
следствием
широкого
распространения
персональных
компьютеров
,
работая
на
которых
пользователи
совмещают
в
своем
лице
трех
указанных
специалистов
.
Составление
документации
для
пользователей
имеет
свои
особенности
,
связанные
с
тем
,
что
пользователь
,
как
правило
,
не
является
профессионалом
в
области
разработки
программного
обеспечения
.
В
книге
С
.
Дж
.
Гримм
[17]
даны
рекомендации
по
написанию
подобной
программной
документации
:
•
учитывайте
интересы
пользователей
-
руководство
должно
содержать
все
инструкции
,
необходимые
пользователю
;
•
излагайте
ясно
,
используйте
короткие
предложения
;
•
избегайте
технического
жаргона
и
узко
специальной
терминологии
,
если
все
же
необходимо
использовать
некоторые
термины
,
то
их
следует
пояснить
;
•
будьте
точны
и
рациональны
-
длинные
и
запутанные
руководства
обычно
никто
не
читает
,
например
,
лучше
привести
рисунок
формы
,
чем
долго
ее
описывать
.
Руководство
пользователя
,
как
правило
,
содержит
следующие
разделы
:
•
общие
сведения
о
программном
продукте
;
•
описание
установки
;
•
описание
запуска
;
•
инструкции
по
работе
(
или
описание
пользовательского
интерфейса
);
•
сообщения
пользователю
.
Раздел
Общие
сведения
о
программе
обычно
содержит
наименование
программного
продукта
,
краткое
описание
его
функций
,
реализованных
методов
и
возможных
областей
применения
.
Раздел
Установка
обычно
содержит
подробное
описание
действий
по
установке
программного
продукта
и
сообщений
,
которые
при
этом
могут
быть
получены
.
В
разделе
Запуск
,
как
правило
,
описаны
действия
по
запуску
программного
продукта
и
сообщений
,
которые
при
этом
могут
быть
получены
.
Раздел
Инструкции
по
работе
обычно
содержит
описание
режимов
работы
,
форматок
ввода
-
вывода
информации
и
возможных
настроек
.
Раздел
Сообщения
пользователю
должен
содержать
перечень
возможных
сообщений
,
описание
их
содержания
и
действий
,
которые
необходимо
предпринять
по
этим
сообщениям
.
11.4.
Руководство
системного
программиста
По
ГОСТ
19.503-79
руководство
системного
программиста
должно
содержать
всю
информацию
,
необходимую
для
установки
программного
обеспечения
,
его
настройки
и
проверки
работоспособности
.
Кроме
того
,
как
указывалось
выше
,
в
него
часто
включают
и
описание
необходимого
обслуживания
,
которое
раньше
приводилось
в
руководстве
оператора
(
ГОСТ
19.505-79)
и
/
или
руководстве
по
техническому
обслуживанию
(
ГОСТ
19.508-79).
В
настоящее
время
данную
схему
используют
для
составления
руководства
системному
администратору
.
Руководство
системного
программиста
должно
содержать
следующие
разделы
:
•
общие
сведения
о
программном
продукте
,