静态分析真的是形式化验证吗？
Is static analysis really formal verification?
我一直在阅读有关形式验证的内容，基本要点是它需要一个正式的规范和模型才能使用。然而，许多资料将静态分析归类为一种形式化验证技术，一些资料提到抽象解释并提到它在编译器中的使用。
所以我很困惑-如果没有模型的正式描述，这些怎么能成为正式验证？
编辑：我找到的来源是：
Static analysis: the abstract semantics is computed automatically from
the program text according to predefined abstractions (that can
sometimes be tailored automatically/manually by the user)
那么这是否意味着它只适用于源代码而不需要正式规范？这就是静态分析器所做的。
另外，没有形式化验证是否可以进行静态分析？例如。 SonarQube 真的执行形式化方法吗？
在硬件和软件系统的上下文中，形式验证是证明或反驳预期算法的正确性的行为 相对于特定形式规范或属性，使用形式化的数学方法。
How can these be formal verification if there is no formal description of the model?
静态分析器将生成一段代码的 control/data 流，然后可以应用 formal methods 来验证是否符合系统's/unit 的预期设计模型.
请注意 modelling/formal-specification 不是 static-analysis.[=55= 的一部分]
不管如何组合在一起，这两种工具在形式验证中都很有用。
例如，如果将系统建模为具有
的有限状态机 (FSM)
- 预定义的状态数
由特定成员数据的特定值组合定义。
- 各种状态之间的一组预定义转换
由成员函数列表定义。
Then the results of static analysis will help in formal verification of the fact that
the control NEVER flows along a path that is NOT present in the above FSM model.
此外，如果可以简单地根据类型定义、数据流、control-flow/call-graph 来定义模型，即静态分析器可以验证的代码度量，那么静态分析本身就足够了正式验证代码是否符合这样的模型。
注意 1。上面的黄色区域是静态分析器，用于执行编码指南和命名约定等内容，即不会影响程序行为的代码方面。
注2。上面的红色区域是形式验证，需要额外的步骤，例如 100% 动态代码覆盖率、消除未使用的代码和死代码。这些不能 detected/enforced 使用静态分析器。
静态分析在验证 system/unit 是否使用语言规范的子集实现以满足 system/unit 设计中规定的目标方面非常有效。
例如，如果防止堆栈内存超过特定限制是设计目标，则可以对递归深度施加限制（或完全禁止递归函数调用）。静态分析用于识别此类违反设计目标的行为。
In the absence of any warnings from the static-analyser,
the system/unit code stands formally verified against such design-goals of its respective model.
例如。 MISRA-C standard for Automotive software 定义了用于汽车系统的 C 子集。
MISRA-C:2012 包含
143 条规则 - 每条规则都可以使用静态程序分析进行检查。
16 "directives"更开放的解释，或涉及过程。
当然可以把静态分析归为形式化验证的一种。
how can these be formal verification if there is no formal description of the model?
对于静态分析工具，模型是隐式的（或在某些工具中，部分隐式）。例如，"a well-formed C++ program will not leak memory, and will not access memory that hasn't been initialized"。这些规则可以从语言规范或特定项目的编码标准中导出。
静态分析就是"read the source code and possibly complain"。 （对比 "dynamic analysis"，意思是 "run the program and possibly complain about some execution behavior"）。
有许多不同类型的可能的静态分析投诉。
一种可能的投诉可能是，
Your source code does not provably satisfy a formal specification
如果静态分析器有它解释的正式规范"formally"、源代码的正式解释以及无法找到合适定理的可信定理证明者，则此投诉将基于正式验证.
您可能从静态分析器得到的所有其他类型的抱怨几乎都是启发式的意见，也就是说，它们基于对代码（或规范，如果确实存在）的一些非正式解释。
"heavy duty" 静态分析器如 Coverity 等有很好的程序模型，但他们不会告诉你你的代码符合规范（他们甚至不看你是否有一个).他们充其量只是告诉您您的代码根据语言 ("dereference a null pointer") 做了一些未定义的事情，甚至这种抱怨也不总是正确的。
MISRA之类所谓的"style checkers"也是静态分析器，但他们的抱怨本质上是"You used a construct that some committee decided was bad form"。这实际上不是一个错误，它是纯粹的意见。
我一直在阅读有关形式验证的内容，基本要点是它需要一个正式的规范和模型才能使用。然而，许多资料将静态分析归类为一种形式化验证技术，一些资料提到抽象解释并提到它在编译器中的使用。
所以我很困惑-如果没有模型的正式描述，这些怎么能成为正式验证？
编辑：我找到的来源是：
Static analysis: the abstract semantics is computed automatically from the program text according to predefined abstractions (that can sometimes be tailored automatically/manually by the user)
那么这是否意味着它只适用于源代码而不需要正式规范？这就是静态分析器所做的。
另外，没有形式化验证是否可以进行静态分析？例如。 SonarQube 真的执行形式化方法吗？
在硬件和软件系统的上下文中，形式验证是证明或反驳预期算法的正确性的行为 相对于特定形式规范或属性，使用形式化的数学方法。
How can these be formal verification if there is no formal description of the model?
静态分析器将生成一段代码的 control/data 流，然后可以应用 formal methods 来验证是否符合系统's/unit 的预期设计模型.
请注意 modelling/formal-specification 不是 static-analysis.[=55= 的一部分] 不管如何组合在一起，这两种工具在形式验证中都很有用。
例如，如果将系统建模为具有
的有限状态机 (FSM)- 预定义的状态数
由特定成员数据的特定值组合定义。 - 各种状态之间的一组预定义转换
由成员函数列表定义。
Then the results of static analysis will help in formal verification of the fact that
the control NEVER flows along a path that is NOT present in the above FSM model.
此外，如果可以简单地根据类型定义、数据流、control-flow/call-graph 来定义模型，即静态分析器可以验证的代码度量，那么静态分析本身就足够了正式验证代码是否符合这样的模型。
注意 1。上面的黄色区域是静态分析器，用于执行编码指南和命名约定等内容，即不会影响程序行为的代码方面。
注2。上面的红色区域是形式验证，需要额外的步骤，例如 100% 动态代码覆盖率、消除未使用的代码和死代码。这些不能 detected/enforced 使用静态分析器。
静态分析在验证 system/unit 是否使用语言规范的子集实现以满足 system/unit 设计中规定的目标方面非常有效。
例如，如果防止堆栈内存超过特定限制是设计目标，则可以对递归深度施加限制（或完全禁止递归函数调用）。静态分析用于识别此类违反设计目标的行为。
In the absence of any warnings from the static-analyser,
the system/unit code stands formally verified against such design-goals of its respective model.
例如。 MISRA-C standard for Automotive software 定义了用于汽车系统的 C 子集。
MISRA-C:2012 包含
143 条规则 - 每条规则都可以使用静态程序分析进行检查。
16 "directives"更开放的解释，或涉及过程。
当然可以把静态分析归为形式化验证的一种。
how can these be formal verification if there is no formal description of the model?
对于静态分析工具，模型是隐式的（或在某些工具中，部分隐式）。例如，"a well-formed C++ program will not leak memory, and will not access memory that hasn't been initialized"。这些规则可以从语言规范或特定项目的编码标准中导出。
静态分析就是"read the source code and possibly complain"。 （对比 "dynamic analysis"，意思是 "run the program and possibly complain about some execution behavior"）。
有许多不同类型的可能的静态分析投诉。 一种可能的投诉可能是，
Your source code does not provably satisfy a formal specification
如果静态分析器有它解释的正式规范"formally"、源代码的正式解释以及无法找到合适定理的可信定理证明者，则此投诉将基于正式验证.
您可能从静态分析器得到的所有其他类型的抱怨几乎都是启发式的意见，也就是说，它们基于对代码（或规范，如果确实存在）的一些非正式解释。
"heavy duty" 静态分析器如 Coverity 等有很好的程序模型，但他们不会告诉你你的代码符合规范（他们甚至不看你是否有一个).他们充其量只是告诉您您的代码根据语言 ("dereference a null pointer") 做了一些未定义的事情，甚至这种抱怨也不总是正确的。
MISRA之类所谓的"style checkers"也是静态分析器，但他们的抱怨本质上是"You used a construct that some committee decided was bad form"。这实际上不是一个错误，它是纯粹的意见。