1 дек. 2010 г.

Рекомендации NASA по написанию безопасных программ.

На сайте NASA разыскался документ "NASA Software Safety Guidebook". Сам документ датирован мартом 2004 года, но, имхо, ценности его это не умаляет. Документ является подборкой ркомендаций по написанию безопасных программ. Такая махина как NASA наверняка имеет мощную теоритическую базу по формированию требований к используемому ими софту. Так что прочтение этого руководства, думаю, будет не бесполезным. Сам я доку еще не прочитал - только нашел. Но вот в блоге у Алексея Пахунова подсмотрел несколько высказываний (мотиваторов к прочтению :) ). Пока их и приведу тут.


Например, идет речь о мультипрограммировании (N-Version Programming). Одна и та же функциональность реализуется разными способами. Если разные версии возвращают одинаковый результат, то всё в порядке. Если результаты не совпадают, то используется голосование, чтобы определить какой результат наиболее достоверный. Для защиты от одного сбоя нужно написать три разных реализации; от двух – пять.


Теперь интересное:


One major problem with N-Version programming is that it increases complexity, which has a direct relationship with the number of errors. In one NASA study of an experimental aircraft, all of the software problems found during testing were the result of the errors in the redundancy management system. The control software operated flawlessly!


Одна из главных проблем мультипрограммирования состоит в повышении сложности, что напрямую влияет на количество ошибок. Одно из исследований экспериментального самолета проведённое NASA показало, что все программные ошибки, найденные во время тестирования, были результатом ошибок в системе резервирования. Управляющее программное обеспечение работало безупречно!



Секция про языки тоже забавна. Сначала речь идет о «безопасном подмножестве» языков. Из него исключаются все мало-мальски неоднозначные, сложные, спорные и просто неудачные языковые конструкции. Далее разбираются разные языки. Про Ada – не интересно. Язык специально создавался для подобных применений. Ассемблер принимается за необходимое зло. Про Си написано уже интереснее:


In many ways, C is a higher level assembly language. This gives it great flexibility, and opens a Pandora’s box of possible errors.


Во многом, Си – это ассемблер высокого уровня. Это даёт значительную гибкость и открывает ящик Пандоры с возможными ошибками.


Ну да. Что есть, то есть.


Restricting the C language to certain constructs would not be feasible because the resulting language would not have the necessary functionality.


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


Практически все конструкции языка придуманы, чтобы программист, в конце концов, прострелил себе ногу.


С++:


A standard “safe subset” of C++ does not presently exist.


Стандартное «безопасное подмножество» C++ на данный момент не существует.


… и вряд ли появится.


Don’t use the RTTI (Run-Time Type Information). It was added to support object oriented data bases. If you think it’s necessary in your program, look again at your design.


Не используйте RTTI. Эта функциональность была добавлена для поддержки объектно-ориентированных баз данных. Если вы думаете RTTI необходима вашей программе, пересмотрите свой дизайн.


+1. Но пассаж про ОО базы данных непонятен.


Про C# написали, что это интерпретируемый язык. Про NGEN они не в курсе. С другой стороны, ну зачем им сборщик мусора во встроенной железке?


Forth:


Forth has no “safety” features.


В Форте нет «безопасных» конструкций.


Просто и понятно. Ну и так далее. Там даже Visual Basic есть.


В приложении есть рекомендации для каждого языка. Попадаются волшебные:


Use comments to describe WHAT the procedure or section is meant to do. It is not always clear from the assembly code.


Используйте комментарии для описания того ЧТО процедура или секция должны делать. Это не всегда понятно из ассемблерного кода.



Комментариев нет:

Отправить комментарий