工业开发中的形式化方法：成就、问题和未来.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 抽象模型的每个更准确的版本是否破坏了前一版本中已经证明的性质, 这称为精化正确 性证明。 在开发抽象模型的过程中, 第二类关注所导致的证明义务通常比不变式保持性 的证明义务简单一些。究其原因,在这一步做的事情也就是