"Валерий Аджиев "Мифы о безопасном ПО: уроки знаменитых катастроф" [V]" - читать интересную книгу автора

расчетную (для Ariane 4) более чем в пять раз.

Но почему же не была (пусть в порядке перестраховки) обеспечена защита
для всех семи, включая BH, переменных? Оказывается, для компьютера IRS
была продекларирована максимальная величина рабочей нагрузки в 80%, и
поэтому разработчики должны были искать пути снижения излишних
вычислительных издержек. Вот они и ослабили защиту там, где теоретически
нежелательной ситуации возникнуть не могло. Когда же она возникла, то
вступил в действие такой механизм обработки исключительной ситуации,
который оказался совершенно неадекватным.

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

Осмысление

Произошедшая с Ariane 5 катастрофа имела исключительно большой резонанс
и по причине беспрецедентных материальных потерь, и вследствие очень
оперативного расследования, характеризовавшегося к тому же открытостью
результатов (впервые такая практика публичности была опробована при
расследовании причин аварии космического корабля Challenger 1986 г.).
Сразу стало очевидным, что данному событию суждено войти в историю не
только космонавтики, но и программной инженерии. Поэтому неудивительно,
что авария послужила поводом для оживленной дискуссии, в которой приняли
участие многие известные специалисты.

Ж.-М. Жезекель (J.-M. Jezequel) и Б.Мейер (B.Meyer) [2] пришли к
совершенно однозначному выводу: допущенная (и так и не выявленная)
программная ошибка носит, по их мнению, чисто технический характер и
коренится в некорректной практике повторного использования ПО. Более
точная формулировка: роковую роль сыграло отсутствие точной спецификации
повторно-используемого модуля.
Расследование показало, что обнаружить требование, устанавливающее
максимальную величину BH (вмещающуюся в 16 битов), можно было с большим
трудом: оно затерялось в приложениях к основному спецификационному
документу. Мало того, в самом коде на этот счет не было никаких
комментариев, не говоря уже о ссылке на документ с обоснованием этого
требования.

В качестве панацеи в такого рода ситуациях авторы предложили
задействовать принцип "Контрактного Проектирования" (что и неудивительно,
ибо его разработчиком как раз и является Мейер [3]). Именно "контракт" в
духе языка Eiffel, явным образом (с помощью пред- и пост-условий)