Пассивное обнаружение ошибок

Если мы исходим из предположения, что в программном обеспе­чении будут ошибки, то, очевидно, в первую очередь следует принять меры для их обнаружения. Более того, если необходимо принимать дополнительные меры (например, исправлять ошибки или их по­следствия), то все равно сна­чала нужно уметь обнаруживать ошибки.

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

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

Разрабатывая эти меры, мы будем опираться на следующие положе­ния:

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

2. Немедленное обнаружение. Ошибки необходимо обнаружить как можно раньше. Это не только ограничивает наносимый ими ущерб, но и значительно упрощает задачу отладки.

3. Избыточность. Все средства обнаружения ошибок основаны на некоторой форме избыточности (явной или неявной).

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

1. Проверяйте атрибуты любого элемента входных данных. Если вход­ные данные должны быть числовыми или буквенными, про­верьте это. Если число на входе должно быть положительным, про­верьте его значение. Если известно, какой должна быть длина входных данных, проверьте ее.

2. Применяйте «тэги» [4] в таблицах, записях и управляющих блоках и проверяйте с их помощью допустимость входных данных. Тэг – это поле записи, явно указывающее на ее назначение.

3. Проверяйте, находится ли входное значение в установлен­ных пре­делах. Например, если входной элемент – адрес в основ­ной памяти, прове­ряйте его допустимость. Всегда проверяйте по­ле адреса или указателя на нуль и считайте, что оно неверно, если равно нулю. Если входные данные – таблица вероятностей, про­верьте, находятся ли все значения между нулем и единицей.

4. Проверяйте допустимость всех вариантов значений. Если входное поле – код, обозначающий один из десяти районов, ни­когда не предпола­гайте, что если это не код ни одного из районов 1, 2,..., 9, то это обяза­тельно код района 10.

5. Если во входных данных есть какая-либо явная избыточность, вос­пользуйтесь ею для проверки данных.

6. Там, где во входных данных нет явной избыточности, введи­те ее. Если ваша система использует крайне важную таблицу, подумайте о вклю­чении в нее контрольной суммы. Всякий раз, когда таблица обновляется, следует просуммировать (по некото­рому модулю) ее поля и результат по­местить в специальное поле контрольной суммы. Подсистема, использую­щая таблицу, сможет теперь проверить, не была ли таблица случайно ис­порчена, – для этого только нужно выполнить контрольное суммирование.

7. Сравнивайте, согласуются ли входные данные с какими-ли­бо внутренними данными. Если на входе операционной системы возникает требование освободить некоторый блок памяти, она дол­жна убедиться, что этот блок в данный момент действительно занят.

Когда разрабатываются меры по обнаружению ошибок, важно при­нять согласованную стратегию для всей системы (т.е. приме­нить идею концептуальной целостности к обнаружению ошибок). Действия, предпри­нимаемые после обнаружения ошибки в программном обеспечении (напри­мер, возврат кода ошибки), должны быть единообразными для всех компо­нент системы. Это ставит вопрос о том, какие именно действия следует пред­принять, когда ошибка обнаружена. Наилучшее решение – немедленно за­вершить выполнение программы или (в случае опе­рационной системы) пе­ревести центральный процессор в состояние ожидания. С точ­ки зрения предоставления человеку, отлаживающему программу, например систем­ному программисту, самых благоприятных ус­ловий для диагностики оши­бок немедленное завершение представ­ляется наилучшей стратегией. Ко­нечно, во многих системах подоб­ная стратегия бывает нецелесообразной (например, может оказать­ся, что приостанавливать работу системы нельзя). В таком случае используется метод регистрации ошибок. Описание симптомов ошиб­ки и «моментальный снимок» состояния системы сохраняется во внешнем файле, после чего система может продолжать работу. Этот файл позднее будет изучен обслуживающим персоналом.

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