Студопедия

Главная страница Случайная страница

Разделы сайта

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






Обнаружение ошибок






 

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

Большинство методов направлено по возможности на неза­медлительное обнаружение сбоев. Немедленное обнаружение имеет два преимущества: можно минимизировать влияние ошиб­ки и последующие затруднения для человека, которому придется извлекать информацию о ней, находить ее и исправлять.

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

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

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

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

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

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

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

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

Активное обнаружение ошибок. Не все ошибки можно выя­вить пассивными методами, поскольку эти методы обнаружива­ют ошибку лишь тогда, когда ее симптомы подвергаются соот­ветствующей проверке. Можно делать и дополнительные провер­ки, если спроектировать специальные программные средства для активного поиска признаков ошибок в системе. Такие средства называются средствами активного обнаружения ошибок.

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

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

Иногда желательно, чтобы в чрезвычайных обстоятельствах монитор выполнял диагностические тесты системы. Он может вы­зывать определенные системные функции, сравнивая их результат с заранее определенным и проверяя, насколько разумно время вы­полнения. Монитор может также периодически предъявлять сис­теме «пустые» или «легкие» задания, чтобы убедиться, что система функционирует хотя бы самым примитивным образом.






© 2023 :: MyLektsii.ru :: Мои Лекции
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав.
Копирование текстов разрешено только с указанием индексируемой ссылки на источник.