工业开发中的形式化方法成就问题和未来-北京大学数学科学学院.PDFVIP

裘宗燕译：工业开发中的形式化方法：成就、问题和未来（作者J.-R. Abrial ） 第 1 页 共 9 页 工业开发中的形式化方法：成就、问题和未来 Jean-Raymond Abrial Swiss Federal Institute of Technology, Zurich （国际软件工程大会特邀报告，2006 年元月，上海） 摘要：本文简单介绍用 B 形式化方法做的两个实际项目，它们说明了复杂系统里的重要部 分可以如何用这样一种“构造即正确”的方式开发出来。随后分析了关于将这种方法用于工 业开发的一些正面和反面意见，并分析了其中的困难。 1，引言 本文的意图是报告在工业中应用形式化方法的经验。虽然下面主要给出了我知道的几个应用 B 方法 [1] 的案例，但从这些案例得到一些结果也适合其他形式化方法的应用。我将先简 要介绍相关案例，而后分析其中的所学所悟。在做这些之前，首先简要概述一下什么是这里 所说的“形式化方法”。 2 ，形式化方法 本文用术语“形式化方法”时取其最精确、或许最窄的意义。应该说明，今天人们赋予这一 术语许多不同理解。为使本文简短，这里只给出与使用B 形式化方法有关的最重要概念。 2.1 形式化开发 本文案例中使用的 B 形式化方法是一种途径，工程师可以按这种途径把软件需求文档转换 到某种可执行代码。这一说法似乎与普通程序员做的事情没什么差别。使这一途径与常规方 法大相径庭的地方在于应用它的工程师再不需要去编任何程序。事实上，他们不再使用某种 经典程序设计语言，而是工作在更抽象的层次上，那里根本就没有执行的概念。 由于这种情况，在这里不能通过执行代码的方式做测试和调试。显然我们不可能保证工程师 不再犯任何错误，因此需要通过其他途径验证他们做出的东西。在下面2.2 和2.4 节，我们 将看到用什么东西取代可执行的测试。 这一开发途径可以划分为三个独立的相继进行的阶段： (1) 阶段 1，从软件需求文档中逐步抽取出问题的细节。这一工作要通过逐步求精最终构造 出一个抽象模型。抽象模型的抽取和逐步构造需要大量人工参与。 (2) 阶段2 ，软件需求文档已经不再使用了，现在的出发点就是得到的抽象模型，它被（仍 然是逐步地）转换到一个具体模型。这一阶段也需要一些人工参与，但是如我们将在4.5 节里看到的，这种参与不像前一阶段那么广泛。 (3) 阶段3，将具体模型自动翻译为可执行代码。这一阶段完全无须人工参与。 这种途径的整体效果是：得到的可执行代码是构造即正确的（相对于软件需求规范而言）。 下面几小节将简要说明这些阶段的一些情况。 2.2 抽象模型 裘宗燕译：工业开发中的形式化方法：成就、问题和未来（作者J.-R. Abrial ） 第 2 页 共 9 页 本小节将简要描述抽象模型的结构，还要说明工程师在构造它的过程中进行验证的方法。 抽象模型里首先包含一些数据，数据通过不变式引入。这些大大扩充了程序设计语言里用的 数据声明的简单概念。不变式是用一阶逻辑或集合论结构（集合、关系、函数等）写出的谓 词。正如其名字说明的，一个不变式也就是数据的一种性质，在系统的动态活动中总保持不 变（虽然其间数据本身可能变化）。注意，不变式也可能描述了某种全局性质，这种性质是 不可能在程序语言里表达的。还请注意，变量及其不变式并不是一下子引进的，而是随着抽 象模型的构造工作的进展，通过逐步叠加的方式将它们结合进来。 模型的动态特性用简单转换描述。在许多情况下这种转换为非确定性的，一般用经典的集合 论结构定义。再说一次，与数据一样，随着抽象模型的构造工作的进展，也要通过逐步叠加 的方式扩充这种转换。 2.3 证明 工程师通过数学证明的方式，逐步验证他们正在构造的抽象模型。注意，在这里要证明的语 句不是工程师自己定义的，而是由一个称为证明义务生成器的工具自动生成。为了生成证明 义务，该工具将不断分析抽象模型的各个精化形式。请注意，由工具确定应该证明什么（它 可能生成数以千计的证明义务）是非常重要的。如果让工程师自己做，他们很可能在生成这 种待证明语句时犯错误，从而把复杂性从一个地方搬到了另一个地方。 要做的证明主要关注两方面情况： (1) 抽象模型里的转换是否保持了不变式的成立。这方面的证明称为不变式保持性证明。 (2) 抽象模型的每个更准确的版本是否破坏了前一版本中已