最近我读了很多关于形式验证的内容，我对这个话题非常着迷。但我无法弄清楚以下几点：
正式验证需要正式的规范，因此当没有正式的程序规范时，h ow可以是编译器中任何源代码使用的抽象解释吗？
从外语文本中翻译似乎是正确的（并且似乎不需要正式的规范。）
如果程序由其控制流程图表示，则每个程序 branch表示程序状态（可以多于一个 - 例如在a中 循环分支遍历多次）和抽象解释 创建近似于这种状态集的静态语义。
这里有一篇关于抽象解释作为形式验证技术的文章：http://www.di.ens.fr/~cousot/publications.www/Cousot-NFM2012.pdf
答案 0 :(得分：2)
可以通过为语言构建解释器来进行“具体解释”，该解释器根据语言规范手册计算结果。 （语言手册是非正式的这一事实使得这种翻译的正确性永远存在疑问）。
抽象解释只要求人们对程序语义有一个很好的理解，并且需要一个关于什么是值得抽象的想法。你可以通过上面的解释器来获得这个，并用计算的抽象替换实际的计算，例如，你可以决定将所有整数值表示为“正”，“零”，“负”或“未知”。您仍然可以使用此计算，现在可以生成定性结果。更重要的是，您可以使用此计算，而不必具有实际的程序输入（可能只是抽象值）。我注意到抽象解释器在正式意义上也是完全不值得信任的，因为你仍然使用非正式参考手册作为语言将做什么的指南。
现在，通过运行这样一个抽象程序，您可能会发现它使用控制该空值不是“未定义”的变量来犯错误（例如，取消引用空值）。在这种情况下，您可以建议程序中存在错误;你可能不对，但这可能会产生有用的结果。
在实践中，抽象解释无处可告诉您程序正式计算的内容，因为您仍在使用非正式参考手册。如果手册要成为正式文档，并且您的抽象解释器是通过可证明的正确步骤派生的，那么我们可能会同意对程序的抽象解释是一种规范模式，以抽象为程序实际上是。
抽象解释无法访问程序的意图的正式规范。因此，您不能单独使用它来证明程序相对于规范是“正确的”。
答案 1 :(得分：0)
抽象解释是一种用于静态理解软件行为方式的方法。它永远不会一个人 - 总是有一些目标，其中包括抽象解释作为其组成部分之一。
此类目标的一个示例是形式验证，其中使用静态技术（例如，抽象解释）来获取有关代码的信息，然后将其与提供的规范进行比较。这就是为什么验证需要规范 - 你需要一些东西来比较它。