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

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

convert (horizontal_bias:INTEGER): INTEGER is require horizontal_bias
"= Maximum_bias do ...
ensure ...
end

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

Однако, самым важным достоинством использования контрактных механизмов
является, по мнению авторов, явное присутствие легко понимаемых и при
необходимости верифицируемых ограничений как в документации, так и в коде.
При работе над сложными проектами типа Ariane именно контракты могли бы
выступать в качестве опорных ориентиров для групп качества "QA Team", чья
задача выполнять систематический мониторинг ПО на предмет соответствия
требованиям. Авторы с сожалением заключают, что контрактные механизмы
никак не получат должного распространения в современной практике. Более
того, положение только усугубляется: например, в Java даже исчезла
присутствовавшая в языке Cи скромная по возможностям инструкция "assert".
В составной части CORBA языке IDL (Interface Definition Language),
предназначенном обеспечить полномасштабное повторное использование
компонентов в распределенной среде, отсутствует какой-либо механизм
спецификации семантики. То же относится и к ActiveX. Авторы заключают: без
полной и точной спецификации, основанной на пред- и пост-условиях и
инвариантах, "повторное использование программных компонентов совершенное
безрассудство".

Эта точка зрения вызвала многочисленные отклики. Хотя полезность
использования контрактных механизмов никто не оспаривал, все же взгляд
авторов многим показался упрощенным. аиболее обстоятельный критический
разбор их статьи выполнил сотрудник Locheed Martin Tactical AirCraft
Systems, известный специалист в области разработки ответственных систем
Кен Гарлингтон (Ken Garlington) [4]. Он начал с того, что указал на ошибку
в приведенном наброске контракта, где предполагается, что BH преобразуется
не из вещественного (как то было в реальности) числа, а из целого.
Показательно, пишет Гарлингтон, что он оказался первым, кто обратил
внимание на столь очевидный прокол, а ведь статью читали и публично
обсуждали многие квалифицированные специалисты. С тем же успехом (а точнее
неуспехом) могла пройти мимо этого дефекта и "QA-team". Так что даже
точная спецификация сама по себе не панацея. Гарлингтон также подробно
разобрал нетривиальные проблемы, возникающие при написании не "наброска",
а действительно полной спецификации контракта для данной конкретной
ситуации.