Есть ли место формальным методам верификации программ в промышленности?
Я взглянул на Логике Хоара в колледже. То, что мы сделали, было очень просто. Большая часть того, что я сделал, доказывала правильность простых программ, состоящих из while циклы if операторы и последовательность инструкций, но не более того. Эти методы кажутся очень полезными!
формальные методы широко используются в промышленности?
используются ли эти методы для доказательства критически важного программного обеспечения?
10 ответов
Это вопрос, близкий моему сердцу (Я исследователь проверки программного обеспечения с использованием формальной логики), поэтому вы, вероятно, не удивитесь, когда я скажу, что считаю, что эти методы имеют полезное место и еще недостаточно используются в отрасли.
существует много уровней "формальных методов", поэтому я предполагаю, что вы имеете в виду те, которые опираются на строгую математическую основу (в отличие, скажем, от некоторого процесса в стиле 6 сигм). Некоторые виды формальных методов имели большой успех - одним из примеров являются системы типов. Инструменты статического анализа, основанные на анализе потока данных, также популярны, проверка моделей почти повсеместна в аппаратном дизайне, а вычислительные модели, такие как Pi-исчисление и CCS, похоже, вдохновляют некоторые реальные изменения в практическом языковом дизайне для параллелизма. Анализ прекращения-это тот, который в последнее время имел много прессы - проект SDV в Microsoft и работа Байрона Кука-последние примеры исследований / практики кроссовера в формальном методы.
рассуждения Хоара до сих пор не сделали больших набегов в отрасли - это по большему количеству причин, чем я могу перечислить, но я подозреваю, что в основном вокруг сложности написания, а затем доказывания спецификаций для реальных программ (они, как правило, получают большой, и не в состоянии выразить свойства многих реальных сред). Различные под-поля в этом типе рассуждений теперь делают большие вторжения в эти проблемы-логика разделения одна.
Это частично характер текущих (тяжелых) исследований. Но я должен признаться, что мы, как теоретики, совершенно не смогли объяснить отрасли, почему наши методы полезны, чтобы они соответствовали потребностям отрасли и были доступны разработчикам программного обеспечения. На каком - то уровне это не наша проблема-мы исследователи, часто математики, и практическое использование не является главным в наших умах. Кроме того, разрабатываемые методы часто слишком эмбриональны для использования в крупномасштабных системах - мы работаем на небольших программах, на упрощенных системах, получить математику работает, и двигаться дальше. Однако я не очень верю в эти оправдания - мы должны быть более активными в продвижении наших идей и получении обратной связи между отраслью и нашей работой (одна из основных причин, по которой я вернулся к исследованиям).
вероятно, это хорошая идея для меня, чтобы воскресить мой блог и сделать еще несколько сообщений об этом материале...
Ну, сэр Тони хор присоединился к Microsoft Research около 10 лет назад, и одной из вещей, которые он начал, была официальная проверка ядра Windows NT. Действительно, это было одной из причин длительной задержки Windows Vista: начиная с Vista, большие части ядра are фактически официально проверенный wrt. к некоторым свойствам, таким как отсутствие тупиков, отсутствие утечек информации и т. д.
Это, конечно, не типично, но это, вероятно, один самое важное применение формальной проверки программы, с точки зрения ее воздействия (ведь почти каждый человек так или иначе, форма или форма влияет на компьютер под управлением Windows).
Я не могу много комментировать критически важное программное обеспечение, хотя я знаю, что индустрия авионики использует широкий спектр методов для проверки программного обеспечения, включая методы в стиле Хоара.
формальные методы пострадали, потому что ранние защитники, такие как Edsger Dijkstra настаивали на том, что они должны использоваться везде. Ни формализм, ни поддержка программного обеспечения не подходили для этой работы. Более здравомыслящие сторонники считают, что эти методы следует использовать для решения трудных проблем. Они не широко использованы в индустрии, но принятие увеличивает. Вероятно, наибольшие успехи были в использовании формальных методов для проверки свойства безопасности программного обеспечения. Некоторые из моих любимых примеров -спина model checker и код доказательства Джорджа Некулы.
переход от практики и в исследования, Microsoft сингулярность проект операционной системы с помощью формальных методов для обеспечения гарантий безопасности обычно требуется аппаратная поддержка. Это, в свою очередь, приводит к более быстрой производительности и более прочным гарантиям. Например, в singularity они доказали, что если сторонний драйвер устройства разрешен в систему (что означает, что основные условия проверки были доказаны), то он не может сбить всю эту ОС-худшее, что он может сделать, это шлангом свое собственное устройство.
формальные методы пока не широко использованы в индустрии, но они более широко использованы чем они были 20 лет назад, и Через 20 лет они будут еще более широко использоваться. Так что вы будущее-proofed : -)
Да, они используются, но не широко во всех областях. Существует больше методов, чем просто логика Хоара, некоторые используются больше, некоторые меньше, в зависимости от пригодности для данной задачи. Общая проблема заключается в том, что программное обеспечение biiiiiiig и проверка того, что все это правильно, все еще слишком сложная проблема.
например, теорема-prover (программное обеспечение, которое помогает людям в доказательстве правильности программы) ACL2 был использован, чтобы доказать, что определенный блок обработки с плавающей запятой не имеет определенный тип ошибки. Это была большая задача, поэтому эта техника не слишком распространена.
проверка модели, другой вид формальной проверки, используется довольно широко в настоящее время, например, Microsoft предоставляет тип проверки модели в наборе разработки драйверов, и его можно использовать для проверки драйвера на наличие набора распространенных ошибок. Модельные контролеры также часто использованы в проверять цепи оборудования.
строгое тестирование также можно рассматривать как формальную проверку - есть некоторые формальные спецификации, какие пути программы должны быть протестированы и так далее.
" формальные методы используются в промышленности?"
да.
на assert оператор на многих языках программирования связан с формальными методами проверки программы.
" широко ли используются формальные методы в промышленности ?"
нет.
" используются ли эти методы для доказательства критически важного программного обеспечения ?"
иногда. Чаще всего они используются, чтобы доказать, что программное обеспечение безопасно. Более формально, они используются, чтобы доказать утверждения о безопасности программного обеспечения.
существует два разных подхода к формальным методам в отрасли.
один подход заключается в том, чтобы полностью изменить процесс разработки. Обозначения Z и метод B, которые были упомянуты в первой категории. B был применен для развития линии метро без водителя 14 в Париже (если у вас есть шанс, забирайтесь в передний вагон. Это не часто, что вы получаете шанс увидеть рельсы перед вами).
другой, более поэтапный подход к сохранить существующие процессы разработки и верификации и одновременно заменить только одну из задач верификации новым методом. Это очень привлекательно, но это означает разработку инструментов статического анализа для выхода из используемых языков, которые часто нелегко анализировать (потому что они не были разработаны). Если вы идете в (например)
http://dblp.uni-trier.de/db/indices/a-tree/d/Delmas:David.html
(извините, только одна гиперссылка разрешена для новых пользователи :( )
вы найдете примеры практического применения формальных методов для верификации C-программ (со статическими анализаторами Astree, Caveat, Fluctuat, Frama-C) и двоичного кода (с инструментами AbsInt GmbH).
кстати, поскольку вы упомянули логику Хоара, в приведенном выше списке инструментов, только предостережение основано на логике Хоара (и Frama-C имеет плагин логики Хоара). Другие полагаются на абстрактную интерпретацию, другую технику с более автоматическим подход.
моя область знаний является использование формальных методов статического анализа кода, чтобы показать, что программное обеспечение свободно от ошибок времени выполнения. Это реализовано с использованием метода формальных методов, известного как "абстрактная интерпретация". Этот метод по существу позволяет вам доказать определенные атрибуты s / w-программы. Е. Г. докажите, что A+B не будет переполнения или Х/(Х-г) не приведет к делению на ноль. Примером инструмента статического анализа, использующего этот метод, является Polyspace.
в отношении ваш вопрос: "широко ли используются формальные методы в промышленности?" и " используются ли эти методы для доказательства критически важного программного обеспечения?"
ответ-да. Это мнение основано на моем опыте и поддержке инструмента Polyspace для отраслей, которые полагаются на использование встроенного программного обеспечения для управления критическими системами безопасности, такими как электронный дроссель в автомобиле, тормозная система для поезда, контроллер реактивного двигателя, инфузионный насос для доставки лекарств и т. д. Эти отрасли действительно используют эти типы инструментов формальных методов.
Я не верю, что все 100% этих сферах, используя эти инструменты, но растет. Мое мнение заключается в том, что аэрокосмическая и автомобильная промышленность лидируют с медицинской промышленностью, быстро наращивая использование.
Polyspace - это (ужасно дорогой, но очень хороший) коммерческий продукт, основанный на проверке программы. Это довольно прагматично, поскольку он масштабируется от "расширенного модульного тестирования, которое, вероятно, найдет некоторые ошибки" до "следующие три года вашей жизни будут потрачены, показывая, что эти 10 файлов имеют нулевые дефекты".
Он основан больше на отрицательной проверке ("эта программа не повредит ваш стек") вместо положительной проверки ("эта программа будет делать точно что скажут эти 50 страниц уравнений").
помимо других более процедурных подходов, логика Хоара была в основе оформление по договору, введенный в качестве объектно-ориентированной техники Бертраном Мейером в Эйфеле (см. статью Мейера 1992 года, стр. 4). Хотя дизайн по контракту не совпадает с формальными методами проверки (во-первых, DbC не доказать ничего, пока программное обеспечение не будет выполнено), на мой взгляд, это обеспечивает более практическое использование.