形式化方法--程序的正确性验证-14

合集下载

程序正确性证明

程序正确性证明

缺乏有效工具的挑战
挑战
01
目前市场上缺乏高效、可靠的程序正确性证明工具,导致验证
过程耗时费力。
解决方案
02
加大研发力度,开发更多具有自主知识产权的程序正确性证明
工具。
解决方案
03
推广使用已有的开源工具和平台,提高工具的可用性和可维护
性。
缺乏专业人才的挑战
挑战
程序正确性证明需要专业的知识和技能,而目前 市场上缺乏足够的专业人才。
Part
04
程序正确性证明的挑战与解决 方案
证明复杂性的挑战
STEP 01
挑战
STEP 02
解决方案
随着软件和算法的复杂性 增加,程序正确性证明的 难度也随之增加。
STEP 03
解决方案
利用高级编程语言和开发 框架,简化程序设计和验 证过程,降低复杂性。
采用形式化方法和工具, 将复杂的程序逻辑转化为 数学模型,以便进行形式 化验证。
总结词
通过在实际运行程序时收集和分析运行时信息,评估程序 的正确性和性能。
要点二
详细描述
动态分析技术是一种在实际运行程序时收集和分析运行时 信息的方法,用于评估程序的正确性和性能。它通过监控 程序的运行状态、内存使用、CPU占用率等信息,分析程 序的动态行为,从而发现潜在的问题和错误。动态分析技 术能够提供更全面的信息,但需要实际运行程序,因此可 能无法覆盖所有情况。
测试与验证
总结词
通过实际运行程序并检查其输出,验证程序的正确性。
详细描述
测试与验证是一种实践性的方法,通过实际运行程序并检查其输出是否符合预 期结果,来验证程序的正确性。这种方法简单直观,但可能无法覆盖所有可能 的输入和状态,因此需要结合其他方法一起使用。

形式化验证讲义范文

形式化验证讲义范文

形式化验证讲义范文形式化验证是通过数学方法来证明一个系统或算法的正确性的过程。

它可以帮助我们在软件开发过程中找到潜在的错误和漏洞,并确保我们的系统在各种情况下都能正常工作。

在这篇讲义中,我们将介绍形式化验证的基本原理和方法,以及一些常用的工具和技术。

一、什么是形式化验证形式化验证是一种通过形式规范和数学证明来验证软件或硬件系统的方法。

它使用数学符号和逻辑推理来描述和证明系统的性质,从而确保系统在不同的输入条件下都能正确运行。

形式化验证可以帮助我们验证系统的正确性、安全性和性能。

二、形式化验证的原理和方法1.系统建模:将系统的行为和性质用数学语言描述出来。

这可以包括使用形式化规范语言(如Z、VDM、B、TLA+等)或编程语言来定义系统的接口、状态和操作。

2.性质定义:明确要验证的系统性质,如安全性、正确性、活性、一致性等,并用数学逻辑表达出来。

常用的逻辑形式包括命题逻辑、一阶逻辑、时态逻辑等。

3.形式化证明:使用数学推理规则和工具来证明系统模型满足所要求的性质。

常见的形式化验证方法有定理证明、模型检测、符号执行等。

其中,定理证明方法通常使用数学逻辑和推理规则来构造证明树,而模型检测方法则通过对系统的状态空间进行穷举来验证性质。

4.反例分析:如果无法证明系统满足所要求的性质,可以通过生成反例来帮助找到问题所在。

反例可以是系统的一个具体执行序列,或是一个导致性质不成立的条件。

三、形式化验证的工具和技术1. 定理证明器:它是一种可以自动验证逻辑公式和数学定理的工具。

常见的定理证明器有Coq、Isabelle、ACL2等。

这些工具提供了一种交互式的证明环境,可以帮助用户构造和验证证明脚本。

2.模型检测工具:它是一种可以对系统的状态空间进行穷尽,并验证性质是否成立的工具。

常见的模型检测工具有SPIN、NuSMV、PRISM等。

这些工具通常基于有限状态机模型和时序逻辑来进行验证。

3.符号执行工具:它是一种可以对程序进行符号执行,并生成或检查路径条件的工具。

形式化方法

形式化方法

两个用于转换的输入函数,用由位置指向转换的 箭头表示,它们是: I(t1)={P2,P4} I(t2)={P2} 两个用于转换的输出函数,用由转换指向位置的
箭头表示,它们是:
O(t1)={P1} O(t2)={P3,P3} 注意,输出函数O(t2)中有两个P3,是因为有两个 箭头由t2指向P3。
5.3.1 基本概念 Petri网包含4种元素:一组位置P、一组转换T、 输入函数I以及输出函数O。图5.5举例说明了Petri网 的组成。 其中, 一组位置P为{P1,P2,P3,P4},在图中用圆圈 代表位置。 一组转换T为{t1,t2},在图中用短直线表示转 换。
图5.5 Petri网的组成
数学作为软件开发工具的最后一个优点是,它提 供了高层确认的手段。可以使用数学方法证明,设计 符合规格说明,程序代码正确地反映了设计结果。
5.1.3
应用形式化方法的准则
为了更好地发挥这种方法的长处,下面给出应用 形式化方法的几条准则,供读者在实际工作中使用。 · 选择适用于当前项目的符号系统。 · 应该形式化,但不要过分形式化。通常没有必 要对系统的每个方面都使用形式化方法。 · 应该进行成本/效益分析。 · 需要有形式化方法的顾问。
6元组,其中每个谓词都是系统全局状态Y的函数。转
换函数T现在是一个从(J-F)×K×P到J的函数。现在的 转换规则形式如下: 当前状态〔菜单〕+事件〔所选择的项〕+谓词 下个状态。
5.2.2
电梯问题
为了说明在实际工作中怎样使用形式化的方法, 现在我们用有穷状态机技术给出电梯问题的规格说明。
果t2也被激发了,则令牌从P2中移出,两个新令牌被
J是一个有穷的非空状态集;
K是一个有穷的非空输入集; T是一个从(J-F)×K到J的转换函数; S∈J,是一个初始状态; FJ,是终态集。

形式化方法

形式化方法

形式化方法
By 周帝
目录
1.形式化方法 形式化方法 2.软件中的形式化方法 软件中的形式化方法 2.1非形式化方法的缺点 非形式化方法的缺点 2.2形式化方法的优点 形式化方法的优点 3.形式化方法的举例 形式化方法的举例 4.形式化方法语言 形式化方法语言
形式化方法
By 周帝
非形式化的缺点
用自然语言书写的系统规格说明书,可能存在矛盾、二义性、含糊性、不完整 性及抽象层次混乱等问题。 矛盾:指一组相互冲突的陈述。监控化学反应容器中的温度,监控在一定范围 内的温度 二义性:指读者可以用不同方式理解的陈述。操作员标识由操作员姓名和密码 组成,密码由6位数字构成。当操作员登陆进系统时它被放在注册文件里 含糊性:系统规格说明书庞大,易出现含糊性。 不完整性:遗漏了客户的一些需求。例如,AVERAGE命令的功能是显示某个 传感器在两个日期内获得的平均水深(每个数据保留6个月) 抽象层次混乱:是指在非常抽象的陈述中混进了一些关于细节的低层次陈述。
形式化方法
By 周帝
形式化方法的定义
用于开发计算机系统的形式化方法是描述系统 性质的基于数学的技术,这样的形式化方法提供了 一个框架,可以在框架中以系统的而不是特别的方 式刻划、开发和验 证系统。 如果一个方法有良好 的数学基础,那么它就是形式化的,典型地以形式 化规约语言给出。这个基础提供一系列精确定义的 概念,如:一致性和完整性,以及定义规范 的实 现和正确性。 形式化方法的本质是基于数学的方 法来描述目标软件系统属性的一种技术。
形式化方法
By 周帝
事例
在一幢M层楼的大厦里,用电梯内的和每个楼层的按 钮来控制N部电梯的运动。当按下电梯按钮请求电梯 在指定楼层停下时,按钮指示灯亮;当电梯到达指定 楼层时,指示灯灭。除了大厦的最底层和最高层外, 每层楼都有两个按钮分别指示电梯上行和下行。当这 两个按钮之一被按下时相应的指示灯亮,当电梯到达 此楼层时灯熄灭,电梯向要求的方向移动。当电梯无 升降动作时,关门并停在当前楼层。

形式化方法

形式化方法

关系表示法关系表示法-规则表达式
基本规则: 原子:字母表中的基本符号 基本规则 原子 字母表中的基本符号 递归规则: 递归规则 错列:如果 如果R1,R2是规则表达式 错列 如果 是规则表达式 那么(R1|R2)也是规则表达式 那么 也是规则表达式 字符串集合的并集 合成:如果 是规则表达式, 合成 如果R1,R2是规则表达式 如果 是规则表达式 那么(R1R2)也是规则表达式 那么 也是规则表达式 R2中的串接到 中的串上 中的串接到R1中的串上 中的串接到 形成新串
常见的形式化规格说明方法
1、关系表示法 (relational notations) 、 (1) 固有方程 (implicit equations) (2) 递归关系 (recurrence relation) (3) 代数公理 (algebraic axioms) (4) 规则表达式 2、基于模型的表示方法 、 (1)有限状态机 有限状态机 (2)Petri网 网 (3)Z方法等 方法等
闭包:如果 是规则表达式 那么(R1)*也是规则表 闭包 如果R1是规则表达式 那么 如果 是规则表达式,那么 也是规则表 达式,表示把空串或R1中元素的多个串联 中元素的多个串联。 达式,表示把空串或 中元素的多个串联。 (R1)+ 表 示把R1中元素 中元素1个或多个串联 示把 中元素 个或多个串联
规则表达式有多种解释: 规则表达式有多种解释: 可能表示的意义: 如: (a(b|c))+ 可能表示的意义 数据流: a,b,c 为输入数据 数据流 消息传递: 消息传递 a,b,c 为不同的消息类型 操作序列: 操作序列 a,b,c代表过程 代表过程 资源流: a,b,c表示系统的一个组成部分 资源流 表示系统的一个组成部分

形式化验证方法

形式化验证方法

形式化验证方法
形式化验证是一种基于数学和逻辑理论的验证方法,可以用于验证电子系统的正确性和性能。

其主要思想是将系统抽象成数学模型,然后利用形式化语言描述系统规范和性质,再通过计算机自动化地验证系统是否满足这些规范和性质。

形式化验证方法具有以下特点:
1. 精确性:形式化验证方法是基于数学和逻辑理论的,能够对系统进行精确的推理和验证,避免了人为误判和漏判的可能性。

2. 自动化:形式化验证方法可以通过计算机自动化地进行验证,能够大大提高效率,并且可以重复验证,确保验证结果的可靠性。

3. 可靠性:形式化验证方法能够对系统的所有可能性进行验证,能够发现系统中的所有潜在问题,提高系统的可靠性和安全性。

4. 应用广泛:形式化验证方法可以应用于多种电子系统的验证,包括芯片设计、软件开发、通信协议等。

总之,形式化验证方法是一种高效、精确、可靠的验证方法,可以保证电子系统的正确性和性能,值得被广泛应用和推广。

- 1 -。

基于模型检测的程序验证与形式化验证方法研究

基于模型检测的程序验证与形式化验证方法研究

基于模型检测的程序验证与形式化验证方法研究程序验证是软件工程中非常重要的一环,旨在确保软件系统能够以期望的方式运行,避免潜在的错误和安全漏洞。

随着软件规模的增长和复杂性的提高,传统的手工验证方法已经无法满足需求,因此形式化验证方法逐渐被引入。

形式化验证旨在通过形式化方法来验证程序的正确性。

模型检测是其中一种形式化验证的方法,其基本思想是通过构建系统的有限状态模型,然后对该模型应用逻辑规范进行验证。

一、模型检测的基本原理和流程在进行模型检测之前,首先需要明确待验证的属性和系统的规范。

这些规范可以使用时序逻辑等形式化语言来表达,如线性时序逻辑(LTL)或计时时序逻辑(CTL)。

模型检测的基本流程如下:1. 构建系统模型:根据被验证系统的需求和规范,构建一个有限状态模型,以有限状态自动机(Finite State Automaton)的形式进行表示。

2. 编码规范:将系统规范用形式化的语言进行编码,常用的形式化语言有CTL、LTL、Promela等。

3. 开始验证:使用模型检测工具对系统模型和规范进行验证。

模型检测工具会遍历系统的所有可能状态,判断是否满足规范的要求。

4. 结果分析:根据模型检测工具的输出结果,对验证结果进行分析,确定系统是否满足规范。

二、模型检测的优势与局限性相比传统的测试方法,模型检测具有以下优势:1. 全面性:模型检测可以遍历系统的所有可能状态,从而能够全面地检查系统是否满足给定的规范。

2. 高效性:模型检测通过自动化的方式进行验证,相比手工验证工作效率更高。

3. 自动化:模型检测可以通过计算机程序来执行,提高验证的自动化程度。

然而,模型检测也存在一些局限性:1. 状态爆炸:当系统的状态空间非常大时,模型检测可能面临状态爆炸问题,导致验证效率低下。

2. 时序逻辑限制:模型检测的时序逻辑规范通常只能描述单一性质,而对于复合性质的验证较为困难。

3. 完备性问题:模型检测对于未能在验证规范中明确定义的错误无法发现,因此需要谨慎选择验证规范。

形式化验证方法浅析

形式化验证方法浅析

形式化验证方法浅析随着信息技术的不断发展,软件系统已经成为现代社会和经济的基础设施之一。

软件系统的正确性和可靠性越来越受到重视,因为软件错误会带来巨大的经济损失和安全隐患。

为了提高软件系统的质量和可靠性,形式化验证方法逐渐成为了重要的研究领域。

本文将对形式化验证方法进行一定的浅析,介绍其基本概念、原理和应用。

一、形式化验证方法的基本概念形式化验证是一种基于数学逻辑的方法,通过数学语言描述待验证系统的行为规范或性质,然后利用自动化或手工化的技术对系统进行验证。

形式化验证方法主要包括模型检测、定理证明和符号执行等技术,其中模型检测和定理证明是相对常见和成熟的技术。

模型检测是一种自动化验证技术,它通过穷举系统的所有可能状态来检测系统是否满足给定的性质。

模型检测的核心就是构建系统的状态转移模型,然后利用状态空间搜索算法进行验证。

常用的状态空间搜索算法包括符号模型检测、显式状态搜索和隐式状态搜索等。

模型检测方法的优点是自动化程度高,能够发现系统中的错误和性质违反情况,但是其缺点是状态空间爆炸问题,对于大规模的系统往往难以处理。

定理证明是一种手工化验证技术,它通过数学推理和演绎来证明系统是否满足给定的性质。

定理证明的核心是将系统的行为规范或性质转化为逻辑公式,然后利用数学推理规则和定理证明工具来验证系统。

定理证明方法的优点是能够处理复杂的性质和系统,但是其缺点是依赖于人工的推理和分析,效率较低并且受到形式化规约的限制。

1. 系统建模:形式化验证的第一步是对系统进行建模,将系统的行为规范或性质形式化描述。

系统建模可以采用多种形式化语言和工具,如时序逻辑、Petri网、状态机和模型检测工具等。

建模的目的是将系统的行为抽象化和形式化,为后续的验证工作奠定基础。

2. 性质描述:形式化验证的第二步是对系统的性质进行描述,通常包括功能性要求和安全性要求。

功能性要求是描述系统的期望行为,如正确性、完备性和一致性等;安全性要求是描述系统的禁止行为,如死锁、饥饿和冲突等。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

第十四讲形式化方法--程序的正确性验证一、概述计算机的程序是一种静态的对象,但它所描述的问题(问题的解)却是一个动态的对象。

所谓的程序设计就是用程序设计语言中的语句改变程序中数据对象的状态,构造所描述问题的动态行为。

这是不自然的,程序所描述的动态行为也无法直接用程序本身的静态结构进行正确性证明。

形式化规约(formal specification)是需求阶段的形式化说明,是用户需求的严格描述,其一般形式用Hoare逻辑描述[1]如下:├{Φ}P{Ψ} <1>其中Φ和Ψ分别表示初始和结束断言条件,其含义是:“假如初始状态d I满足条件Φ,那么程序结束并且终结状态d f必须满足Ψ”。

设D=D1×……×D n为程序P的状态空间,其中,D j(j=1,……,n)表示程序中数据对象的值域。

显然,由Φ和Ψ断言条件所确定的合法初始和结束状态的集合是D的一个子集。

执行函数E:Φ×P→Ψ定义如下:无定义对合法的初始状态d i,程序P不结束E(P,d I)=终结状态d f对合法的初始状态d i,程序P结束程序的正确性即为:├{Φ}P{Ψ}iff <2>∀d i(├Φ(d i)→(├程序P结束 and ├Ψ(E(P,d i))))总地来讲,验证一个程序的正确与否有两种办法,一种是程序的测试,另一种是程序的正确性证明。

1.程序的测试与程序的验证对给定的一个合法的初始状态d i,当程序执行结束时其终结状态为d f,那么,Φ(d i)和Ψ(d f)都应该被满足。

这一点可用下式表示:{d i}P{d f} <3>所谓程序的测试就是验证测试用例{d i}P{d f},即验证程序对d i的执行结果是否为d f。

由于合理的初始状态是无限的,因此,对程序验证来讲,测试不是一个完备的方法。

测试被认为是一种尽量发现错误,但并不能保证程序中没有错误[2]的方法。

对大数应用来讲,它是可满足的;但对有些应用来讲,测试是一种不能满足的验证方法,例如:航空、航天等领域的软件系统。

显然,对要求绝对正确的软件,测试是一种不能采用的方法。

无论白盒测试还是黑盒测试都是在无限集合{(d i,d f)|∀d i,∀d f, d i和d f满足{d i}P{d f}中选择有限的一些(d i,d f)对进行验证,而各种测试方法只是选择(d i,d f)的策略不同而已。

因此,验证程序是否完全正确要寻求另外的解决途径。

那就是程序的正确性验证。

2.形式语义与程序的正确性验证程序的正确性验证应该具有严密的推量过程,以保证程序每步执行结果都是希望的结果,而与程序执行的某个初始状态无关。

程序的正确性证明现有三种方式:操作语义、指称语义和公理语义。

它们分别用不同的形式化方法,严格地证明一个程序是否正确。

尽管这种方法还不够完善,还不为一般软件人员所掌握,但它确实是保证软件绝对正确的唯一途径。

操作语义(Operational Semantics)操作语义的根据是,一种程序设计语言一但在某种计算机系统中实施,其语义的含义也就完全确定下来了,因此,自然地就用语言的实施作为语言含义的定义,故称这种语义为操作语义。

当然,这种实施应该在一种标准的、抽象的机器上进行。

英国科学家ndin最早提出这种类型的一个抽象机器,称为“栈-环境-控制-外存”。

IBM公司提出了一种可描述程序设计语言语义的元语言:VDL。

后来,英国的爱丁堡大学提出了更一般的方法:在数据结构上用数学关系建立操作语义的解释系统。

这种方法的本质就是,用抽象机器的状态空间和最简单的基本指令来定义抽象语言的语义,将抽象语言的程序转换为一系列抽象机器的基本指令序列。

这种对应关是固定的,而且抽象机器的基本指令的含义是固定的,这样一个程序设计语言的程序就有了一个明确的、无二义的语义。

为了验证一个抽象程序的正确性,就必须在抽象计算机上执行其相应的基本指令序列。

基本指令序列的一次执行只能验证一组输入、输出状态之间的关系。

因此,用操作语义验证一个程序的正确性实质上是一种测试型的验证方式。

指称语义(Denotational Semantics)指称语义学认为,程序设计语言的语义是由其语言成份的语义决定的,而程序设计语言成份的语义应该是其本身固有的,与程序设计语言的个体实现无关。

指称语义的出发点是语言成份执行的最终结果,而不是其执行过程。

这种执行结果是由语言成份形式后面隐藏的所指物决定的,故这种方式也称为指称语义。

指称语义是由牛津大学的C.Strachey教授创立,D.Scott教授完善的,故指称语义也称为牛津语义。

IBM公司也创立了基于指称语义的VDM软件开发方法。

指称语义的指称物均为数学对象,如整数、集合和映射等。

指称物的集合称为论域。

一个语言的指称语义就是确定该语言的相关论域,并给出语法成份到论域上的语义映射。

一个抽象的程序设计语言程序的语义就是指称语义所指的数学对象在论域上的数学运算,其正确性证明就是指称语义相应的数学运算公式的特性(递归类型语言成份的数学运算公式特征就是其不动点的特征),这些性质是可严格推理和证明的。

公理语义(Axiomatic Semantics)公理语义是根据数学中的公理化方法形式化程序设计语言相关语法的语义。

赋以公理语义的程序设计语言,可推理出该程序设计语言的程序语义,也可用逻辑推理的方法证明该程序是否具有某种性质。

公理语义是最流行的程序证明方法。

这种方法最早是由Floyd在他的“Assigning Meanings to Programs”一文中提出的,后经C.A.Hoare在它的“An Axiomatic Basis for Computer Programming”一文中发展和完善的。

公理语义对程序设计语言中的每个成份(包括整个程序)定义了一对断言(assertoin):前置断言(Precondition)和后置断言(Postcondition)。

前置断言是某个语言成份在执行前满足的谓词,而后置断言则是该语言成份执行后应该满足的谓词。

有两种使用公理语义的方式,一种是所谓的自顶向下的方法,用前置和后置断言描述用户的需求,然后,将前置断言向后置断言转化的步骤逐步细化,直到每一步都能用计算机语言进行实施为止。

只要保证分解的步骤是正确的,那么最终的程序设计结果也是正确的。

这种方法的典型代表是唐稚松先生的XYZ系列语言[4]。

另一种方法是自底向上的,根据每个语言单元定义的前置断言和该成份本身的特征,推导出其后置断言。

一个语法单元的后置断言可作为下一个语法单元的前置断言,从而揄出整个程序的后置断言,以此可证明程序应满足的性质和程序的正确性。

二、公理系统:Hoare逻辑和时态逻辑公理系统是最流行的程序正确性证明和验证的方法,Hoare系统是公理系统中的典型代表,它用命题{Φ}P{Ψ}表法程序P的语义:如果程序执行前满足断言Φ,则当程序执行终止后,它一定满足断言Ψ。

下面通过一个经典的例子说明Hoare逻辑表述和其优缺点。

求n!的程序FAC(程序FAC的描述采用FLOW语言[2],以下其它程序的描述相同):1=>x; n=>y; (while≠(y,0) do (*(x,y)=>x; -(y,1)=>y))。

表示当n为任意自然数时,如果该程序执行终止,x的值为n!,这一性质可用{n N}FAC{x=n!}命题表示。

用命题还可表示程序FAC的其它性质,如:{tt}FAC{y=0}命题表示无论初值如何,当程序终止时,y的值为0。

由于命{Φ}P{Ψ}不能保证程序P一定能终止,因此,这种命题也称为程序的部分正确性证明的命题(因为证明程序是否结束是一个递归不可判定问题,即图灵机停机问题。

本文不深入讨论,以下所说的程序正确性证明均指部分正确性证明,在文章的最后再给出正确性证明的补充)。

这种程序正确性的命题如果为真,就称其为Hoare系统中的定理。

那么,如何用公理的方法进行推理呢?设D=(A,I)是一个演绎系统,其中,A=(A1,A2,……,A m)表示公理的集合;I=(I1,I2,……,I n)表示规则的集合。

公理是一个系统中不用证明、预先承认的事实。

如果,S是系统中一条合法的语句,那么,├S表示S为真,即S是系统中的一个定理。

├S1├S2┇├S P├S r表示系统中的一条规则,其含义是if (├S1 and ├S2 and …… and ├S P) then ├S r。

演绎系统中,一个定理的证明就是一个合法的语句序列(要用公理或规则说明为什么该语句是合法的)。

下面举一个著名的、最简单的演绎系统及其推理的例子。

设D g=(A g,I g),其中A g=(A1,A2,A3)为:A1:├最少由两个点。

A2:├如果P和Q是两个不同的点,那么经过P和Q的线只有一条。

A3:├假如L是一条线,那么存在一个不在L上的点。

I g=(I1,I2)为:I1:├ P├ if P then Q├ QI2:├ P├ Q├ P and Q下面是“├最少有三个点”的证明步骤:1.├最少由两个点 A12.├存在一条线 1,A2,I13.├在线外有一个点 2,A3,I14.├最少由三个点 1,2,I2程序的本质是状态的转换,程序的执行就是从满足前置条件的状态转换到满足后置条件的状态,程序的正确性证明即证明<2>。

由于结构化程序设计的任何语法单位均为单入口和单出口的,所以,任何一个结构化的程序设计语言写的程序均可表示为以下的形式:s1;s2;…;s n <4>对∀d0,存在一个状态转换序列:d1,d2,…,d n(d i表示执行语句s i后的状态)。

为了证明<2>,对每一对(s i, s i+1)定义一个谓词断言M i。

显然,可按下面的逻辑推理步骤证明(2):∀d0├Φ(d0)├Φ(d0)→M1(d1)├M1(d1)→M2(d2)┇├M n-1(d n-1)→Ψ(d n)而证明├M i(d i)→M i+1(d i+1)就是证明:∀d i(假如├M i(d i),执行语句s i后,├M i+1(d i+1))。

这样,程序的正确性证明就归结到每条语句的正确性证明。

下面的Hoare逻辑为验证程序中的语句提供了一般性的方法。

Hoare逻辑是这样的一个演绎系统D h=(A h,I h),A h是Hoare逻辑系统中的公理集(这里不再列出)。

I h除了包含一般逻辑系统中的推理规则外,还包括以下与FLOW语言有关的语法语义规则(公理系统中的一般推理规则详见[5]):(1)├{R} skip {R}(2)├{R[a/x]}a=>x {R}(3)├{R} S1 {O}├{O} S2 {Q}├{R}S1;S2{Q}(4)├{R∧B} S1 {Q}├{R∧⌝B} S2 {Q}├{R} if B then S1 else S2 {Q}(5)├{I∧B} S {I}├{I} while B do S {I∧⌝B}(6)├R→R1├{R1} S {Q1}├Q1→Q├{R} S {Q}要用Hoare逻辑验证一个程序,即所谓的程序正确性证明(证明Hoare系统中的定理),就是用前置条件、逻辑系统中的公理、定理以及上述语言成份所规定的语义规则,按程序的执行步骤推导出后置条件。

相关文档
最新文档