Event-B 形式化方法

Event-B 形式化软件开发方法

 

一、引言

 

软件工程的生命周期主要可以分为七个阶段，如图1.1所示。其中，有一部分非常重要的工作，那就是进行需求分析和写出需求文档。需求分析阶段需要清晰地说明什么是这个系统的功能和约束条件，而需求文档多半是使用自然语言写出的（大多数情况中，需求文档根本没有，或者写得很差）。需求文档如果不规范，会给后续阶段带来许多困难。特别是，由于需求文档的脆弱性，在设计阶段中就会出现不可避免的规范修改，并因此带来综合性的影响。如果需求文档写得好，这种困难可能就消失了。正因为这样，理解这个阶段可以怎样改进，就显得特别重要了。

Fig. 1.1 软件工程的生命周期

形式化语言常用于软件工程生命周期的需求分析阶段，可以帮助工程师理解需求文档，完成建模（需求到形式化模型的转换），甚至进一步完善需求文档（挖掘隐藏的需求，以及改进需求中矛盾的部分）。需求文档常常用自然语言等非形式化的方式被说明，这样会引出很多问题。我们怎么能确信这样一个描述是正确的？我们能保证所描述的程序一定终止吗（没有无穷循环，也没有死锁）？程序应该维持哪些类别的性质？为了回答这些问题，我们需要形式化地构造我们的程序。这类活动应该在正式开始编码前完成，以便使被考虑的系统能做到构造即正确。

Fig. 1.2 形式化方法在需求分析中的作用

Event-B是系统级建模和分析的一种形式化方法。Event-B的主要特点是使用集合论作为建模符号，使用精化来表示不同抽象级别的系统，以及使用数学证明来验证精化级别之间的一致性。在需求分析的过程中，工程师根据需求文档为软件建立抽象模型，建模的过程会构建软件的一系列越来越精确的模型，这种技术称为精化。当构建好抽象模型化，再将抽象模型精化成具体模型。之所以需要构造一系列模型，是因为如果只构造一个模型，该模型就会过于复杂，以至于我们难以对它进行推理和证明。构造出每个模型都要进行分析并给与证明，这样就使我们能建立起所做的模型相对于某些评价标准的正确性。作为这样工作的结果，当最后一个模型完成时，我们就能说这个模型是构造即正确的。进一步说，最后的那一个模型将如此地接近最终实现，我们可以很容易地将其翻译成为一个真正的程序。

Fig. 1.3 构建抽象模型与具体模型

Rodin平台是一个基于Eclipse的Event-B IDE，能为精化模型和数学证明提供有效的支持。该平台是开源的，并且可以通过插件进一步扩展。Rodin通过插件扩展后可以实现如图1.4所示的流程，Rodin平台包含下面一些工具：静态检查器（由词法分析器、语法分析器和类型检查器组成），证明义务生成器，以及证明器，其中证明器包括pp，ml，z3，CVC4等等，代码生成插件能生成C/C++，JAVA等语言的代码。