Question

我一直在阅读有关正式验证的内容，基本观点是它需要正式的规范和模型才能使用。然而，许多来源将静态分析归类为形式验证技术，一些提及抽象解释并提及其在编译器中的使用。所以我很困惑 - 如果没有对模型的正式描述，这些怎么可能是形式验证呢？编辑：我找到的来源是：

静态分析：抽象语义自动计算程序文本根据预定义的抽象（可以有时由用户自动/手动定制）

这是否意味着它只对源代码起作用而不需要正式的规范？这将是静态分析仪的功能。

此外，没有正式验证，静态分析是否可行？例如。 SonarQube真的执行正式方法吗？

Answer 1

在硬件和软件系统的上下文中，形式验证是证明或反驳系统相对于某个正式规范或属性的预期算法的正确性的行为，使用正式的方法数学

如果没有正式的模型描述，这些如何才能进行形式验证？

静态分析器将生成一段代码的控制/数据流，然后可以应用formal methods来验证与系统/单元的预期设计模型的一致性。< / p>

请注意，建模/形式规范不是静态分析的一部分。
无论如何组合在一起，这两种工具在形式验证中都很有用。

例如，如果使用

将系统建模为有限状态机（FSM）

然后静态分析的结果将有助于形式验证的事实控制器永远不会沿着上述FSM模型中不存在的路径流动。

此外，如果模型可以简单地根据类型定义，数据流，控制流/调用图来定义，即静态分析器可以验证的代码度量，那么静态分析本身就足够了正式验证代码是否符合此类模型。

<子> 注1。上面的黄色区域将是静态分析器，用于执行诸如编码指南和命名约定之类的内容，即不会影响程序行为的代码方面。

<子> 注2。上面的红色区域将是正式验证，需要额外的步骤，如100％动态代码覆盖，消除未使用和死代码。使用静态分析器无法检测/强制执行这些操作。

静态分析在验证使用语言规范的子集实现系统/单元以实现系统/单元设计中规定的目标时非常有效。

例如，如果设计目标是防止堆栈内存超出特定限制，则可以对递归深度应用限制（或者完全禁止递归函数调用）。静态分析用于识别此类违反设计目标的行为。

在静态分析仪没有任何警告的情况下，
系统/单元代码正式验证其各自模型的设计目标。

例如。 MISRA-C standard for Automotive software定义了C的一个子集，用于汽车系统。

MISRA-C：2012包含

Answer 2

静态分析只是意味着＆＃34;阅读源代码并可能抱怨＆＃34;。（对比＆＃34;动态分析＆＃34;，意思，＆＃34;运行程序并可能抱怨某些执行行为＆＃34;）。

有许多不同类型的静态分析投诉。一个可能的抱怨可能是，

 Your source code does not provably satisfy a formal specification

如果静态分析器具有正式的规范，并且正式解释了源代码的正式解释，以及无法找到合适的可信定理证明器，则该投诉将基于形式验证。定理。

您可能从静态分析器获得的所有其他类型的投诉都是非常具有启发性的意见，也就是说，它们基于对代码的一些非正式解释（或者如果确实存在，则为规范）。

＆＃34;重型＆＃34;像Coverity等静态分析器有很好的程序模型，但他们并没有告诉你你的代码符合规范（他们甚至不会看你是否有一个）。他们最多只告诉你你的代码根据语言做了一些未定义的事情（＆＃34;取消引用一个空指针＆＃34;）甚至那个投诉也不总是正确的。

所谓的＆＃34;风格的跳棋＆＃34;例如MISRA也是静态分析器，但他们的抱怨本质上是＆＃34;你使用了一些委员会认为是糟糕形式的结构＆＃34;。这实际上不是一个错误，这是纯粹的意见。

Answer 3

您当然可以将静态分析归类为一种形式验证。

如果没有对模型的正式描述，这些如何才能进行形式验证？

对于静态分析工具，模型是隐式的（或者在某些工具中，部分隐含）。例如，＆＃34;格式良好的C ++程序不会泄漏内存，也不会访问尚未初始化的内存＆＃34;。这些规则可以从语言规范或特定项目的编码标准中导出。