Бертран Мейер - Основы объектно-ориентированного программирования

Следующие ключевые слова, управляющие проверкой утверждений, могут появиться в круглых скобках assertion(...) :

[x]. no- не выполнять никакое из утверждений. В этом режиме оказывают на выполнение не больший эффект, чем комментарии;

[x]. require- только проверка выполнимости предусловий на входе программ;

[x]. ensure- проверка выполнимости постусловий на выходе из программы;

[x]. invariant- проверка выполнимости инвариантов класса на входе и выходе программы для квалифицированных вызовов (obj.f) ;

[x]. loop- проверка выполнимости инвариантов цикла перед и после каждой итерации; проверка уменьшения вариантов на каждой итерации с сохранением их не отрицательности;

[x]. check- выполнение предложений check, проверяющих выполнимость соответствующих утверждений. Ключевое слово allявляется синонимом check.

За исключением " no" каждый уровень автоматически влечет выполнение всех предыдущих уровней. В частности, не имеет смысла управлять постусловиями, если не проверить выполнимость предусловий. Этим объясняется эквивалентность checkи all.

При включенном мониторинге пока утверждения выполняются никакого видимого эффекта на процесс вычислений они не оказывают, если не считать затрат процессорного времени. Но если одно из утверждений принимает значение false , то это довольно серьезное событие, приводящее обычно к завершению работы. Фактически, возбуждается исключение, и, если не принять специальных мер по захвату этого исключения, то выполнение остановится. При этом, однако, будет создана таблица истории исключения ( exception history table) в ее общей форме:

Failure: object: O2 class: YOUR_CLASS routine: your_routine

Cause: precondition violation, clause: not_too_small

Called by: object: O2 class: YOUR_CLASS routine: his_routine

Called by: object: O1 class: HER_CLASS routine: her_routine

...

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

Возможные метки, допускаемые в утверждениях, такие как not_too_small в

your_routine (x: INTEGER) is

require

not_too_small: x >= Minimum_value

...

перечисляются при трассировке исключения, что помогает идентифицировать, что же именно пошло не так.

Какой уровень трассировки следует включать? Ответ вырабатывается в результате компромисса, с учетом следующих факторов: уровня доверия к корректности ПО, насколько критичны потери эффективности, насколько серьезны последствия не обнаруженных ошибок в период выполнения.

В экстремальных ситуациях все ясно:

[x].При тестировании системы или очередной ее версии следует включать на самом высоком уровне мониторинг классов (для используемых библиотек это не обязательно). Эта возможность - один из принципиальных вкладов метода, представленного в этой книге. Мало кто из людей осознавал мощь этих идей, и как основательно они влияют на практику разработки ПО. Перелом наступил, когда фактически был получен опыт тестирования больших систем с утверждениями, включающих механизм мониторинга, описанный в этом разделе.

[x].Для системы с полной степенью доверия в приложениях, критичных по времени выполнения, где каждая микросекунда на счету, - следует полностью удалять мониторинг.

Последний совет парадоксален, при отсутствии формальных доказательств корректности говорить о "полной степени доверия" вряд ли возможно. Стоит привести красноречивое высказывание C. A. Hoare:

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