Какие барьеры мешают широкому распространению формальных методов? [закрыто]

Формальные методы могут использоваться для указания, проверки и генерации кода для приложения. Это менее подвержено ошибкам - поэтому в основном используется в программах безопасности / критических.

Почему бы нам не использовать его чаще для повседневного программирования, для веб-приложений и т. Д ...?

Ссылки :

• Формальные методы
• B метод
• Hoare Logic

Инженер - это человек, который может делать с долларом то же, что любой идиот может делать с 10.

Ресурсные ограничения, бюджетные ограничения, временные ограничения, все они важны.

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

По этой причине использование формальных методов, доказательств, верификации программ и подобных методов обычно ограничивается «важными вещами», то есть программным обеспечением авионики, системами управления медицинским оборудованием, электростанциями и т. Д.

Программировать или не программировать?

Чтобы решить проблему с программным продуктом, после понимания требований вы можете ЛИБО написать программу, используя языки программирования, ИЛИ указать программу, используя формальный язык, и использовать инструменты генерации кода. Последний просто добавляет уровень абстракции.

Делать вещи правильно или делать правильные вещи?

Формальный подход дает вам подтверждение того, что ваше программное обеспечение работает в соответствии со спецификациями. Так что ваш продукт все делает правильно. Но делает ли это правильные вещи?

Требования, над которыми вы работаете, могут быть неполными или неоднозначными. Они могут даже глючить. В худшем случае реальные потребности даже не выражаются. Но картинка стоит тысячи слов, просто изображения Google для «Что хочет клиент», например, из этой статьи :

Стоимость формальности

В идеальном мире у вас были бы полностью подробные и совершенные требования с самого начала. Затем вы можете полностью указать свое программное обеспечение. Если вы пойдете на формальный, ваш код будет сгенерирован автоматически, чтобы вы были более продуктивными. Повышение производительности компенсирует стоимость формальных инструментов. И теперь все будут использовать формальные методы. Так почему бы и нет?

На практике это редко бывает реальностью! Вот почему так много проектов с водопадом провалились, и почему итеративные методы разработки (agile, RAD и т. Д.) Взяли на себя инициативу: они могут обрабатывать неполные и несовершенные требования, проекты и реализации и совершенствовать их до тех пор, пока они не будут в порядке.

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

На практике

Когда нет необходимости использовать формальные методы по юридическим или договорным причинам, вы также можете достичь очень высокого качества без формальных систем, например, с помощью контрактного программирования и других передовых методов (например, проверка кода, TDD и т. Д.). Вы не сможете доказать, что ваше программное обеспечение работает, но ваши пользователи будут наслаждаться рабочим программным обеспечением раньше.

Обновление: измеренное усилие

В октябрьском выпуске Communications of ACM за 2018 год есть интересная статья о официально проверенном программном обеспечении в реальном мире с некоторыми оценками усилий.

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

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

Разработка seL4 и разработка кода заняли два человека-года. Суммирование всех сероспецифических доказательств за эти годы дает в общей сложности 18 человеко-лет на 8 700 строк кода C. Для сравнения, L4Ka :: Pistachio, еще одно микроядро в семействе L4, сопоставимое по размеру с seL4, потребовалось шесть человеко-лет на разработку и не обеспечивает значительного уровня уверенности. Это означает, что существует только коэффициент 3.3 между проверенным программным обеспечением и программным обеспечением, разработанным традиционным способом . Согласно методу оценки Колберта и Бема 8, традиционная сертификация EAL7 по Common Criteria для 8 700 строк кода C потребует более 45,9 человеко-лет. Это означает, что формальная проверка реализации на двоичном уровне уже более чем в 2,3 раза менее дорогой, чем самый высокий уровень сертификации Common Criteria, но обеспечивает значительно более надежную гарантию.

Любая программа на любом языке может рассматриваться как формальная спецификация (эквивалентная некоторому токарному станку). Любая «формальная спецификация» более высокого уровня, которая будет использоваться для доказательства формальной корректности, также является просто другой программой. Но это (как правило) плохая, неполная, расплывчатая, недостаточно продуманная программа. И не случайно, как правило, написано людьми, которые не знают, как программировать (они, как правило, эксперты в области).

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

Это отображение требований высокого уровня к деталям более низкого уровня - это суть настоящего программирования. Не должно быть удивительно, что основную работу, выполняемую программистом, читающим и интерпретирующим спецификации, нельзя заменить ручным взмахом руки и сказать: «Теперь просто посмотрите, соответствует ли эта формальная спецификация высокого уровня этой примерной программе».

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