Event-B 形式化方法

最新推荐文章于 2021-03-18 17:57:52 发布

原创最新推荐文章于 2021-03-18 17:57:52 发布 · 1k 阅读

CC 4.0 BY-SA版权

本文介绍Event-B形式化方法在软件工程的需求分析阶段的应用，强调其通过集合论、精化和数学证明确保系统模型的正确性。Event-B使用抽象机和上下文构建模型，并通过Rodin平台提供支持，包括模型精化、证明义务和工具链。文章还概述了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等语言的代码。

Fig. 1.4 工具流程

Rodin可以通过Event-B官网进行下载和安装（http://www.event-b.org/install.html）。在后面的博文中，我将介绍了两个通过Rodin平台建模的完整的例子，一个例子是控制桥上的汽车，另一个例子是简单文件传输协议。

二、Event-B基础知识

2.1 Event-B的组成

用Event-B做形式化开发，最基本的概念就是模型。一个模型包含了一个离散迁移系统的完整数学开发，它由分属两个类别的一些组件构成，这两个类别分别称为抽象机和上下文。抽象机包含模型的动态部分，也就是变量、不变式、定理、变动式和事件；而上下文包含模型的静态部分，包括载体集合、常量、公理和定理。

使用Event_B建模时，首先建立一个模型（model），一个完整的 Event－B模型应该包括上下文( Context) 和抽象机( Machine)：

Context（上下文）：上下文主要定义常量，这些常量可以是数值或者数据集合。
Machine（抽象机）：抽象机主要定义动态的行为，包括状态以及状态属性，还有事件模型的建立都在machine模型里建立。

Variable：Variable定义了状态变量，我的理解是全局的变量
Invariant：Invariant则定义了相应Variable的类型
Theorems：Theorems定义了相应variable的行为
Events：Events则定义了能使状态变量改变的事件，其中包括初始化。
Variant：variant相对于Variable来说，则是Events中临时变量，作用域比Variable小。
Sets：是数据集合
Constants：是定义的一些常量
Axioms：描述了不能从其他公理派生出来的属性
Theorems：描述了可以由公理导出的性质

上下文的例子：

CONTEXT

context

SET

CONSTANTS

⚬ n

⚬ f

⚬ v

AXIOMS

⚬ axm1: n∈ℕ

⚬ axm2: f∈1..n→D

⚬ axm3: v∈ran(f)

END

抽象机的例子：

MACHINE

machine

SEES

⚬ context

VARIABLES

⚬ i

INVARIANTS

⚬ inv1: i∈ℕ

EVENTS

⚬ ...

END

2.2 精化和扩展

一个项目中可以存在多个Machine和Context，但它们不能是独立的，这也从侧面解释了“Event-b支持逐步精化地建立系统模型”。抽象机和上下文之间存在多种关系：一个抽象机可以被另一个抽象机“精化”，一个上下文可以被另一个上下文“扩展”，一个抽象机可以“观看”一个或几个上下文，下图描绘了机器和上下文之间的关系。

精化是增加系统的功能、增加细节、改变状态模型。精化一个自动机过程中，可能需要增加新的变量和新的事件。一般一个模型需要进行多次精化才能符合要求。即Machine在精化中越来越复杂，越来越细致。Context也越来越庞大。抽象机和上下文之间的可见性遵循下面的规则：

一个抽象机可以显式地观看若干上下文（也可以不观看上下文）。
一个上下文可以显式地扩充若干上下文（也可以不扩充任何上下文）。
上下文扩充的概念具有传递性：当上下文C1显式地扩充另一上下文C2时，它也隐式地扩充了那些被C2扩充的上下文。
当上下文C1扩充上下文C2时，C2的集合和常量都能被C1使用。
一个抽象机显式观看某个上下文时，也就隐含地观看所有被其扩充的上下文。
抽象机M观看上下文C，就意味着C的所有集合和常量都能在M里使用。
把精化和扩充关系放一起，不允许出现任何循环。
一个抽象机只能精化至多另一个抽象机
一个抽象机显式或隐式观看的上下文必须不小于它所精化的那一个抽象机。

Event-B方法支持构造不同精化层次的形式化模型，能使每一个抽象机都保持适当的规模。抽象机必须保持不变式和联结不变式（Gluing Invariants，联系具有精化关系的两个抽象机的不变式）。一个抽象机最多只能精化一个抽象机，通过引入新的变量、新的不变式和新的事件精化抽象机中的状态或事件。抽象机之间的精化关系是指对应事件之间具有精化关系，事件之间的精化关系是指对应事件的卫式条件满足卫式条件加强、动作满足模拟关系。

2.3 证明义务

证明义务规则定义定义了“对一个Event-B模型必须证明些什么”。证明义务（proof obligation）并不是为了得到某些信息而进行的操作，它并不是必须的。它的作用只是确定建立的模型是否符合原始需求以及内部需求。

Rodin平台中有一个称为证明义务生成器的工具，它对上下文和抽象机的正文做一些静态检查，自动确定要证明的东西。这些相继式被送给证明器，在那里完成自动的或者交互式的证明。证明义务规则包括：

不变式保持证明义务规则INV：这一证明义务规则保证机器里的每一条不变式被每个事件保持
可行性证明义务规则FIS：这一证明义务规则的用途是保证非确定性动作的可行性。
卫加强证明义务规则GRD：这一证明义务规则的用途是保证一个具体事件的具体卫强与对应的抽象事件的抽象卫。这样就能保证，当具体事件被使能时，抽象事件也能被使能。
归并证明义务规则MRG：这一证明义务保证，当一个具体事件归并了两个抽象事件时，它的卫应强于那两个抽象事件卫的析取。
模拟证明义务规则SIM：这一证明义务规则的作用是保证在一个精华里，每一个抽象事件的每个动作，在相应精华里都得到了正确的模拟。
数值变动式证明义务规则NAT：这一证明义务规则保证，在每个收敛的或者预期事件的卫条件下，我们提出的变动式确实是有自然数值。
有穷集变动式证明义务规则FIN：这一证明义务规则保证，在每个收敛的或者预期事件的卫条件下，我们提出的集合变动式确实是一个有穷集。
变动量证明义务规则VAR：这一证明义务规则保证，每一个收敛事件都能使我们提出的数值变动式或者有穷集变动式减小。它也保证了每一个预期事件不会增大我们提出的数值变动式或有穷集变动式。
非确定性见证证明义务规则WFIS：这一证明义务规则保证，在一个具体事件的见证谓词中提出的每个见证都存在。
定理证明义务规则THM：这一证明义务规则保证所提出的上下文或及其定理是可证的。定理的重要性在于有可能简化证明。
良好证明义务规则WD：这一证明义务规则保证，每个有可能病态定义的公理、定理、不变式、卫、动作、变动式或者见证都确实是良好定义的。