В колледже я познакомился с логикой Хоара. То, что мы сделали, было действительно просто. В основном я доказывал правильность простых программ, состоящих из циклов while, операторов if и последовательности инструкций, но не более того. Эти методы кажутся очень полезными!

Широко ли используются в промышленности формальные методы?

Используются ли эти методы для проверки критически важного программного обеспечения?

14
Khaled Alshaya 29 Июл 2009 в 01:20

10 ответов

Лучший ответ

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

Существует много уровней «формальных методов», поэтому я предполагаю, что вы имеете в виду те, которые основаны на строгой математической основе (в отличие, скажем, от процесса в стиле 6 сигм). Некоторые типы формальных методов имели большой успех - например, системы типов. Инструменты статического анализа, основанные на анализе потока данных, также популярны, проверка моделей почти повсеместно используется при проектировании оборудования, а вычислительные модели, такие как Pi-Calculus и CCS, похоже, вдохновляют на некоторые реальные изменения в практическом проектировании языков для параллелизма. Завершающий анализ - это то, о чем в последнее время много писали в прессе. Проект SDV в Microsoft и работа Байрона Кука - недавние примеры пересечения исследований и практики в формальных методах.

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

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

Вероятно, для меня будет хорошей идеей воскресить свой блог и сделать еще несколько сообщений об этом ...

12
Adam Wright 28 Июл 2009 в 22:02

Что ж, сэр Тони Хоар присоединился к Microsoft Research около 10 лет назад, и одним из его начинаний была формальная проверка ядра Windows NT. В самом деле, это было одной из причин долгой задержки Windows Vista: начиная с Vista, большие части ядра фактически формально проверены. к определенным свойствам, таким как отсутствие тупиков, отсутствие утечек информации и т. д.

Это, конечно, нетипично, но это, вероятно, самое важное применение формальной проверки программы с точки зрения ее воздействия (в конце концов, почти каждый человек в той или иной форме, форме или форме подвержен влиянию компьютера под управлением Windows).

14
Jörg W Mittag 28 Июл 2009 в 21:32

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

Формальные методы пострадали, потому что ранние защитники, такие как Эдсгер Дейкстра, настаивали на том, что их следует использовать повсюду. Ни формализмы, ни поддержка программного обеспечения не подходили для работы. Более здравомыслящие сторонники считают, что эти методы следует использовать для решения сложных проблем. Они не получили широкого распространения в промышленности, но их распространение растет. Вероятно, наибольшее распространение получили формальные методы проверки свойств безопасности программного обеспечения. Некоторые из моих любимых примеров - проверка модели SPIN и код Джорджа Некулы для проверки.

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

Формальные методы еще не получили широкого распространения в промышленности, но они используются более широко, чем 20 лет назад, и через 20 лет они будут еще более широко использоваться. Так что вы готовы к будущему :-)

6
Norman Ramsey 28 Июл 2009 в 23:47

Да, они используются, но не во всех сферах. Есть больше методов, чем просто хоровая логика, некоторые используются больше, некоторые меньше, в зависимости от пригодности для данной задачи. Распространенная проблема заключается в том, что программное обеспечение является biiiiiiig, и проверка его правильности по-прежнему является слишком сложной задачей.

Например, средство доказательства теорем (программное обеспечение, которое помогает людям доказывать правильность программы) ACL2 использовалось, чтобы доказать, что определенный блок обработки с плавающей запятой не имеет определенного типа ошибки. Это была большая задача, поэтому этот метод не слишком распространен.

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

Строгое тестирование также можно рассматривать как формальную проверку - существуют некоторые формальные спецификации того, какие пути программы следует тестировать, и так далее.

5
Roman Plášil 28 Июл 2009 в 21:41

«Используются ли формальные методы в промышленности?»

Да.

Оператор assert во многих языках программирования относится к формальным методам проверки программы.

«Широко ли используются формальные методы в промышленности?»

Нет.

«Используются ли эти методы для проверки критически важного программного обеспечения?»

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

3
S.Lott 28 Июл 2009 в 21:24

В отрасли есть два разных подхода к формальным методам.

Один из подходов - полностью изменить процесс разработки. Обозначение Z и метод B, которые были упомянуты, относятся к этой первой категории. B был применен к развитию линии 14 метро без водителя в Париже (если у вас есть возможность, залезьте в передний вагон. Не часто вы можете увидеть рельсы перед собой).

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

http://dblp.uni-trier.de/db/indices/a-tree/d/Delmas:David.html

(извините, для новых пользователей разрешена только одна гиперссылка :()

Вы найдете примеры практического применения формальных методов для проверки программ на C (со статическими анализаторами Astrée, Caveat, Fluctuat, Frama-C) и двоичного кода (с инструментами от AbsInt GmbH).

Кстати, поскольку вы упомянули Hoare Logic, в приведенном выше списке инструментов только Caveat основан на логике Хоара (а Frama-C имеет подключаемый модуль логики Хоара). Другие полагаются на абстрактную интерпретацию, другую технику с более автоматическим подходом.

2
Pascal Cuoq 3 Авг 2009 в 22:08

Polyspace - это (ужасно дорогой, но очень хороший) коммерческий продукт, основанный на проверке программ. Это довольно прагматично, поскольку масштабируется от «расширенного модульного тестирования, которое, вероятно, обнаружит некоторые ошибки», до «следующие три года вашей жизни будут потрачены на то, чтобы показать, что эти 10 файлов не имеют дефектов».

Он основан больше на отрицательной проверке («эта программа не повредит ваш стек»), а не на положительной проверке («эта программа будет делать именно то, что говорят эти 50 страниц уравнений»).

1
soru 28 Июл 2009 в 22:52

Чтобы добавить в ответ Йорга < / a>, вот интервью с Тони Хоаром. Я думаю, что инструменты, о которых говорит Йорг, - это PREfast и PREfix. См. здесь для получения дополнительной информации.

1
Community 23 Май 2017 в 12:09

Помимо других процедурных подходов, логика Хоара лежала в основе дизайна по контракту , представленного как объектно-ориентированный метод Бертраном Мейером в книге Eiffel (см. статью Мейера от 1992 г., стр. 4). Хотя дизайн по контракту - это не то же самое, что формальные методы проверки (с одной стороны, DbC ничего не доказывает , пока программное обеспечение не запущено), на мой взгляд, он обеспечивает более практическое использование.

0
Daniel Daranas 27 Окт 2009 в 10:44

Моя область знаний - использование формальных методов статического анализа кода, чтобы показать, что программное обеспечение не содержит ошибок времени выполнения. Это реализовано с использованием формальных методов, известных как «абстрактная интерпретация». Этот метод по существу позволяет вам доказать определенные свойства программной программы. Например. докажите, что a + b не будет переполняться или x / (x-y) не приведет к делению на ноль. Примером инструмента статического анализа, использующего эту технику, является Polyspace.

Относительно вашего вопроса: «Широко ли используются формальные методы в промышленности?» и «Используются ли эти методы для проверки критически важного программного обеспечения?»

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

Я не верю, что все 100% этих сегментов отрасли используют эти инструменты, но их использование растет. Я считаю, что аэрокосмическая и автомобильная промышленность лидируют, а промышленность медицинских устройств быстро расширяет масштабы использования.

2
Jay Abraham 19 Авг 2011 в 18:08