阻碍广泛采用正式方法的障碍是什么？[关闭]

形式化方法可用于指定，证明和生成应用程序的代码。这不太容易出错-因此通常用于安全/关键程序中。

为什么我们不经常在日常编程或Web应用程序等中使用它？

参考文献：

• 形式方法
• B法
• 霍尔逻辑

工程师是一个可以用一美元做的人，任何白痴都可以用十美元做。

资源限制，预算限制，时间限制都很重要。

使用正式方法开发软件通常会比不使用正式方法贵得多，并且花费的时间要长得多。同样，对于许多项目而言，最困难的部分是了解业务需求。在这种情况下，使用正式方法购买的所有东西都可以证明您的代码100％对应于您对业务需求的不完整和不正确的理解。

因此，正式方法，证明，程序验证和类似技术的使用通常限于“重要的事情”，即航空电子软件，医疗设备的控制系统，发电厂等。

要编程还是不编程？

为了解决与软件产品的问题，其要求的理解后，就可以无论是使用编程语言编写程序或指定使用正式语言和使用代码生成工具程序。后者只是增加了一个抽象级别。

做对了还是做对了？

正式的方法可以证明您的软件可以按照规范运行。因此，您的产品可以正确执行操作。但是它做对了吗？

您正在处理的要求可能不完整或不明确。他们甚至可能是越野车。在最坏的情况下，甚至没有表达出真正的需求。但是一张图片价值一千个单词，仅是Google图片中“客户想要的”图片，例如，来自本文：

手续费

在一个完美的世界中，您从一开始就将具有完全详细和完美的要求。然后，您可以完全指定您的软件。如果您要正式注册，您的代码将自动生成，从而提高工作效率。生产力的提高将抵消正式工具的成本。现在每个人都将使用正式方法。那为什么不呢？

实际上，这很少是现实！这就是为什么如此多的瀑布项目失败的原因，以及为什么迭代开发方法（敏捷，RAD等）起带头作用：它们可以处理不完整和不完美的需求，设计和实现，并对其进行完善，直到达到最佳效果为止。

这就是重点。使用形式方法，每个迭代都需要具有完全一致的形式规范。这需要仔细的思考和额外的工作，因为形式逻辑并不宽容，也不喜欢不完整的思想。在这种限制下，简单的一次性实验变得昂贵。因此，每次迭代都会导致回溯（例如，一个无效的想法或被误解的需求）。

在实践中

当出于法律或合同原因而不必使用正式方法时，您也可以在没有正式系统的情况下获得很高的质量，例如，通过使用基于合同的编程和其他良好实践（例如，代码审查，TDD等）。您将无法证明您的软件可以运行，但是您的用户将更喜欢使用软件。

更新：测量的努力

在2018年10月发行的ACM通讯中，有一篇有趣的文章介绍了在现实世界中经过正式验证的软件，并对此做了一些估算。

有趣的是（基于军事设备的OS开发），似乎生产经过正式验证的软件比传统工程技术需要3.3倍的工作量。因此，这确实很昂贵。

另一方面，以这种方式获得高安全性软件所需的精力要比传统设计的软件少2.3倍，如果您加倍努力使这种软件获得高安全性级别的认证（EAL 7）。因此，如果您对可靠性或安全性有很高的要求，那么一定要有正式的商业案例。

seL4设计和代码开发花费了两个人年的时间。这些年来，所有血清特异性证明加起来总计为8700行C代码的18个人年。相比之下，L4Ka :: Pistachio是L4家族中的另一个微内核，大小与seL4相当，需要花费6人年的时间才能开发出来，并且没有提供足够的保证水平。这意味着经过验证的软件与传统设计的软件之间只有3.3的因数。根据Colbert和Boehm的估算方法，8，针对8700行C代码的传统Common Criteria EAL7认证将花费超过45.9个人年。这意味着正式的二进制级实现验证已经超过2.3倍 与通用标准的最高认证水平相比，其成本更低，但是却提供了更为强大的保证。

可以将任何语言的每个程序视为正式规范（相当于某些车床）。用于证明形式正确性的任何更高级别的“形式规范”也都是-另一个程序。但是，它（通常）是不好的，不完整的，模糊的，对程序没有充分考虑的。并非巧合，通常是由不懂编程的人（他们通常是领域专家）编写的。

因此，要证明一个程序与它的较高级别的正式要求兼容（产生相同的答案，或者根据您的描述来定性），就可以归结为您如何解决较高级别的正式规范中的歧义。没有好的通用方法可以做到这一点。

高层需求到低层细节的映射是真正编程的要旨。毫不奇怪，程序员阅读和解释规范所完成的核心工作不能被挥舞着说“现在只要看看这个示例程序是否遵守了这个高级正式规范”就可以代替。

即使在逻辑编程的早期，这个概念最初看起来也是很有希望的（因为高级规范和实际的基础程序都可以用相同的语言编写），但这个核心问题却被证明是棘手的。