Книга: Основы объектно-ориентированного программирования
Постскриптум: Катастрофа Ариан 5
Постскриптум: Катастрофа Ариан 5
Когда первое издание этой книги было опубликовано, Европейское Космическое Агентство опубликовало отчет международного исследования тестирования полета космической ракеты Ариан 5, потерпевшей катастрофу 4 июня 1996 года через 40 секунд после старта, по отчету стоившего 500 миллионов долларов (незастрахованного запуска).
Причина катастрофы: ошибки в бортовой компьютерной системе. Причина этой ошибки: преобразование числа с плавающей точкой, представленного 64 битами, в 16-и битовое знаковое целое привело к выбрасыванию исключения. Число задавало горизонтальный наклон (horizontal bias) ракеты. Некоторые исключения в системе обрабатывались, используя механизмы языка ADA, описанные в следующей лекции. Но это исключение не обрабатывалось, поскольку ранее проведенный анализ показал, что оно не может встречаться, поэтому решено было не загромождать код обработчиком соответствующего исключения.
Реальная причина: недостаточная спецификация. Проведенный анализ был вполне корректен, - но для траектории полета ракеты Ариан 4. Программный код был повторно использован при полете ракеты Ариан 5, и предположения, хотя и оставленные в маловразумительной документации, были просто забыты. Их просто не применяли к Ариан 5. При Проектировании по контракту было бы задано предусловие:
require
horizontal_bias <= Maximum_horizontal_bias
естественно подсказывающие команде, отвечающей за качество, проверить все ли программы выполняют это условие, и своевременно обнаружить возможность его нарушения. Хотя теперь мы уже никогда об этом не узнаем, но, представляется, что почти наверняка эта ошибка была бы обнаружена, вероятно, при статическом анализе, в худшем случае при тестировании с включенным механизмом мониторинга, описанным в этой лекции.
Урок ясен: повторное использование без контрактов безрассудно. Абстрактные модули, определенные нами, как единицы повторного использования, должны поставляться с ясными спецификациями условий их применения - предусловиями, постусловиями, инвариантами. Эти спецификации должны находиться не во внешних документах, а быть частью самих модулей. Эти принципы, которые мы изучили, особенно Проектирование по контракту и Самодокументирование являются необходимым условием любой успешной политики повторного использования. Даже если ошибки будут стоить менее полумиллиарда долларов, всегда помните об этих правилах:
[x]. Повторно используемый модуль должен быть специфицирован.
[x]. Язык программирования должен поддерживать механизм утверждений.
[x]. Спецификации являются частью самого ПО.
- Базисные механизмы надежности
- О корректности ПО
- Выражение спецификаций
- Введение утверждений в программные тексты
- Предусловия и постусловия
- Контракты и надежность ПО
- Работа с утверждениями
- Инварианты класса
- Когда класс корректен?
- Связывание с АТД
- Инструкция утверждения
- Инварианты и варианты цикла
- Использование утверждений
- Обсуждение
- Ключевые концепции
- Библиографические замечания
- Упражнения
- Постскриптум: Катастрофа Ариан 5
- Когда нужен постскриптум в бизнес-тексте?
- 6.2. Типичные ошибки при проведении программ продвижения и варианты их устранения
- 4. Варианты операций соединения
- 2.6.2. Выбор вариантов бронирования услуг контрагентов
- Приложение 1 Варианты учебных заданий
- 2.6.2. Варианты программы, полученые путем переупорядочивания предложений и целей
- Варианты дополнительных предложений
- Другие варианты подключения
- 2.3. МЕТОДЫ СИНТЕЗА ВАРИАНТОВ РЕАЛИЗАЦИЙ ПРОГРАММ
- Инварианты класса и семантика ссылок
- Варианты отображения значков в Проводнике
- Мини-вариант задачника