形式化验证讲义

《形式化验证讲义》由会员分享，可在线阅读，更多相关《形式化验证讲义（50页珍藏版）》请在装配图网上搜索。

1、a1软件的形式化理论和方法a2主要内容l软件开发过程和问题l形式化方法简介l形式化方法历史l主要的形式化证明工具l形式化方法的应用举例l结论a3软件开发过程l一般来说，软件开发的主要步骤大致如下：提出问题并进行需求分析；设计：包括功能和结构设计；编码和构建；调试；发布，维护和升级。l常用的开发模型：如传统的瀑布模型，较新近的快速原型、迭代式开发模型等等a4软件开发的期望l软件质量稳定，可靠性高l尽量提高开发的效率l尽量降低开发的成本l问题：现在的情况怎么样？a5软件开发的实际情况l软件开发的实际情况并不乐观项目经常延误，预算经常超支开发的后续阶段常发现许多前期设计错误，更正的代价高昂发布运行的

2、软件中常常存在着许多错误，时常崩溃软件维护和更新工作的代价很高l问题：这样的实际情况会造成什么问题？a6软件缺陷造成的损失a7软件缺陷造成的损失（2）a8软件问题的本质l极端复杂规模：成万、成百万、甚至成千万行代码系统组成部分之间异常复杂的直接与间接相互作用静态结构与动态性质之间难以把握的复杂关系l多变性异常丰富多彩的应用需求需求的不断提升和变化l要求较低的开发成本和较短的开发周期l不可能长期集中一大批最优秀的技术人员a9软件问题的应对l对软件开发活动的良好管理和组织；l建立严格的工作规范，深入控制软件开发过程；l安排丰富的人际信息交流活动，以尽早发现软件需求、设计各阶段出现的错误和失误。l通

3、过不同层次的抽象技术，将复杂系统分解为相对独立的层次或部分，封装并提供清晰接口。如系统开发的层次模型，模块化技术，面向对象的技术等；l研究有效的程序开发模型及支持技术，设法屏蔽软件开发中的难点、解决共性问题。如图形用户界面技术，客户端服务器模型，中间件技术，Web服务模型等；a10软件问题的应对（2）l研究各种构件形式，以利用已有的开发成果，提高开发层次，降低开发代价：子程序库、类库、组件库等；l设计和开发好用的编程语言，研究编程中的规律性，以支持有效的良好编程过程：结构化、OO 及相关语言；l设计良好的描述形式，满足在各层次上描述软件及相关事物的需要：数据流图、控制流图、状态机、UML等；l

4、开发适用的工具，支持各阶段的不同活动，支持对开发结果的深入分析和检查：编辑器、调试器、程序分析工具、集成程序开发环境、UML支持工具等；l培训人员，提高开发参与者的认识能力和工作能力等。但是，仍然不足以解决软件的问题。为什么？a11原因在于l前期成果是自然语言编写的文档，最后成果是形式化的程序；l文档是非形式化的，只能由人阅读和理解，难以严格分析和推理；l形式化的程序有严格的形式和语义。程序的所有静态和动态性质都蕴藏在程序正文中。但程序包含过多语言细节和实现细节，进行验证的成本极高；l需求和设计以及最终实现的程序的一致性难以判定；l测试不可能完全，发现问题的能力很有限，不能成为评判标准。因此，

5、需要把前期的设计过程也形式化。a12形式化方法的引入l传统的软件设计方法：基于自然语言的思考、设计和描述。语义含糊，可能的歧义性，依赖于参与者的经验和理解。无法进行严格检查，只能通过人的交流活动进行分析。l形式化方法：基于严格定义的数学概念和语言。语义清晰，无歧义。可以用自动化或半自动化的工具进行检查和分析l半形式化的方法（例如UML 等）有较清晰定义的形式和部分的语义定义。其中的一些基本性质可能通过开发工具进行检查和分析l事实：软件开发正在从朴素的、非形式的设计方法，向着更加严格、更加形式化的方向转变a13形式化方法简介形式化方法研究如何把（具有清晰数学基础的）严格性（描述形式、技术和过程等

6、）引入软件开发的各阶段：lFormal Specification（形式化规格）：采用具有严格数学定义的形式和语义的记法形式，描述软件设计和实现;lFormal verification（形式化验证）：对形式化规范进行分析和推理，研究它的各种静态和动态性质是否一致并完整，有无矛盾或遗漏？找出并更正其中的错误和缺陷；运行中是否会出现不能容忍的状态（死锁、活锁等）。lFormal Refinement（精化）：从抽象的高层描述出发，严格地保语义地推导更接近实现的包含更多细节的规范；通过反复精化，最终得到正确的可运行程序。a14形式化规格l软件规格是指对软件系统对象及用来对系统对象进行操作的方法集合

7、，以及对所开发系统中的各对象在其生存期间里的集体行为的描述。l软件生命周期模型将整个软件开发过程分解为一系列的阶段，并为每个阶段赋予明确的任务。虽然在不同的模型中这些阶段的分界和顺序有所不同，但规格在每个阶段所产生的作用都使得对系统特征的定义更加准确。对系统中的每个对象来说，对象、对象的性质以及操作等都应该在系统演变的整个过程中当作一个整体来处理。所以，“规格”应当理解为一个多阶段的、而不是仅仅某一个阶段的行为。a15形式化规格(2)l规格可以采用非形式化的方式来描述，包括自然语言、图、表等，也可以采用形式化方式来描述。l非形式化方法本身所存在的矛盾、二义性、含糊性，以及描述规格时的不完整性、

8、抽象层次混杂等情况，使得所得到的规格不能准确地刻画系统模型，甚至会为后来的软件开发埋下出错的隐患。l而对于形式化方法来说，由于其基于严格的数学，具有严格的语法和语义定义，从而可以准确地描述系统模型，排除了矛盾、二义性、含糊性等情况；同时，在对系统进行严格地描述的过程中，将会帮助用户明确其原本模糊的需求，并发现用户所陈述的需求中存在的矛盾等情况，从而相对完整、正确地理解用户需求，最终得到一个完整、正确的系统模型。a16形式化规格(3)l形式规格精确地描述了用户的需求、软件系统的功能以及各种性质，其描述的是“做什么”，而不考虑“怎么做”。l在书写规格时应该注意的一个问题是如何描述得恰如其分，既不过

9、多也不过少。在规格中描述过多会导致“实现偏向”，给实现施加了不必要的限制，从而排除了一些原本是合理的实现；描述得过少又有容纳不合理实现的危险。l为了开发出良好的规格，除了应透彻理解、熟练掌握所使用的形式规格语言和方法外，更重要的是对所要描述的系统有全面深入的了解。a17形式化验证l形式化验证的主要技术包括模型检验和定理证明。l模型检验是一种基于有限状态模型并检验该模型的期望特性的技术。l模型检验就是对模型的状态空间进行搜索，以确认该系统模型是否具有某些性质。搜索的可终止性依赖于模型的有限性。l模型检验主要适用于有穷状态系统，其优点是完全自动化并且验证速度快；并且，模型检验可用于系统部分规格，即

10、对于只给出了部分规格的系统，通过搜索也可以提供关于已知部分正确性的有用信息；此外，当所检验的性质未被满足时，将终止搜索过程并给出反例，这种信息常常反映了系统设计中的细微失误，因而对于用户排错有极大的帮助。a18形式化验证（2）l模型检验方法的一个严重缺陷是“状态爆炸问题”，即随着所要检验的系统的规模增大，模型检验算法所需的时间/空间开销往往呈指数增长，因而极大限制了其实际使用范围。l定理证明采用逻辑公式来规格系统及其性质，其中的逻辑由一个具有公理和推理规则的形式化系统给出，进行定理证明的过程就是应用这些公理或推理规则来证明系统具有某些性质。不同于模型检验，定理证明可以处理无限状态空间问题。定理

11、证明系统又可以粗略地分为自动和交互式两种类型。自动定理证明系统是通用搜索过程，在解决各种组合问题中比较成功；交互式定理证明系统需要与用户进行交互，要求用户能提供验证中创造性最强部分（建立断言等）的工作，因而其效率较低，较难用于大系统的验证。a19形式化求精l形式化求精是Carroll Morgan（现为新南威尔士大学教授）在1990年提出来的，最初是基于程序设计的概念，但在之后逐步发展为一种通用的设计理论，也就是逐步细化的方式。l形式化求精是将自动推理和形式化方法相结合而形成的一门新技术，它研究从抽象的形式规格推演出具体的面向计算机的程序代码的全过程。l它的基本思想是用一个抽象程度低、过程性强

12、的程序去代替一个抽象程度高、过程性弱的程序，并保持它们之间功能的一致。a20形式化方法的发展l20世纪50年代后期，Backus提出了巴克斯范式（Backus normal formula，简称BNF），作为描述程序设计语言语法的元语言；l20世纪60年代，Floyd、Hoare和Manna等开展的程序正确性证明研究推动了形式化方法的发展，他们试图用数学方法来证明程序的正确性并发展成为了各种程序验证方法，但是受程序规模限制这些方法并未达到预期的应用效果；l20世纪80年代，在硬件设计领域形式化方法的工业应用结果，掀起了软件形式化开发方法的学术研究和工业应用的热潮，Pnueli提出了反应式系统规

13、格和验证的时态逻辑(temporal logic，简称TL)方法，Clarke和Emerson提出了有穷状态并发系统的模型检验(model checking)方法；a21形式化方法的发展l20世纪80年代，牛津大学和Hursley实验室于合作将Z用于IBM商用信息控制系统。IBM对整个开发所进行的测试表明：明显地改善了产品质量、大量地减少了错误和早期诊断错误。IBM估计使总体开发成本降低9。这一成果获皇家技术成就奖；l1992年，Praxis公司交付给英国民航局的信息显示系统是伦敦机场新空中交通管理系统的部分。在该系统的需求分析阶段，形式化规格和非形式结构化的需求概念相结合。在系统规格阶段，采

14、用了抽象的VDM模型。在设计阶段，抽象VDM细化为更为具体的模块化规格。项目开发的生产效率和采用非形式化技术相当、甚至更好。同时，软件质量得到了很大的提高，软件的故障率仅为0.75每千行代码，大大低于采用非形式化技术所提供的软件的故障率（约为220每千行代码）；a22形式化方法的发展l美国加州大学的安全关键系统研究组所开发的空中交通防碰撞系统的形式化需求规格TCASII，采用了基于Statecharts的需求状态机语言RSML，解决了开发过程中遇到的许多问题。TCASII项目表明：复杂过程控制系统软件开发采用形式化需求规格的可能性以及应用工程师们不经任何专门培训建立易读且易评判的形式化规格的可

15、行性。l其它方面的应用：数据库：用于存储病人监护信息的HP医用仪器实时数据库系统；电子仪器：Tektronix系列谐波发生器、Schlumberger家用电度计；硬件：INMOS浮点处理器、INMOS中T9000系列的虚拟信道处理器；医疗设备：核磁共振理疗系统；核反应堆系统：核反应器安全系统、核发电系统的切换装置；保密系统：NATO控制指挥和控制系统中的保密策略模型、Multinet网关系统的数据安全传输、美国国家标准和技术院的令牌访问控制系统；电信系统：AT&T的5ESS电话交换系统、德国电信的电话业务系统；运输系统：巴黎地铁的自动火车保护系统、英国铁路信号控制、以色列机载航空电子软件。a2

16、3模型检验工具l时态逻辑模型检验工具有EMC、CESAR、SMV、Mur、SPIN、UV、SVE、HyTech、Kronos等；行为一致检验工具有FDR、Cospan/Formal Check等；复合检验工具有HSIS、VIS、STeP、METAFrame等。l贝尔实验室对其高级数据链路控制器在FormalCheck下进行了模型检验功能验证，6个性能进行了规格，其中5个验证无误、另外一个失败，从而进一步发现了一个影响信道流量的Bug；l1019数目的状态。经过模型检验分析发现了影响主动控制效果的计时器设置错误；a24模型检验工具（2）l基于SMV输入语言建立了IEEE Futurebus+89

17、6.1-1991标准下cache一致协议的精确模型，通过SMV验证了模型满足cache一致性的规格。并发现了先前并未找到的潜在协议设计错误。该工作是第一次从IEEE标准中发现错误；lPhilips公司音响设备的控制协议通过HyTech得到了完全自动验证，这是一个具有离散和连续特征的混杂系统验证问题；lAT&T公司的7500条通信软件的SDL源代码进行了验证，从中发现112个错误，约55的初始设计需求在逻辑上不一致。a25定理证明工具l已有的定理证明器包括：用户导引自动推演工具有ACL2、Eves、LP、Nqthm、Reve和RRL；证明检验器有Coq、HOL、LEGO、LCF和Nuprl；复合

18、证明器Analytica、PVS和Step；l基于符号代数运算的自动定理证明用于证明Pentium中SRT算法的正确性，检查出了一个由故障商数字选择表引起的错误；lPowerPC和System/390中寄存器传输级、门级、晶体管级的硬件设计模拟为布尔状态转移函数，基于OBDD的算法用来检验不同设计级上状态转移函数的等价性；lNqthm用于Motorola 68020微处理器的规格，进而用来证明不同来源的二进制机器码的正确性；a26定理证明工具（2）lACL2用于AMD5K86的浮点除微代码的规格和机械证明，ACL2还用来检验浮点方根微的正确性，发现了其中的Bug，并对修改后的微代码进行了正确性

19、机械证明；lACL2用于Motorola复数算术处理器CSP的完全规格，同时对CSP的几个算法进行了验证；lPVS用于航空电子微处理器AAMP5的规格和验证，对209条AAMP5指令中的108条进行了规格，验证了11个有代表性的微代码。新的模型检验和定理证明工具仍在不断涌现！a27模型检测方法l考虑对一个简单的灯开关进行建模。利用有限自动机，通过执行一些原子动作进行状态间的变迁a28模型检测方法（2）l复杂一点儿的模型考虑一个能提供咖啡和茶的自动饮料机状态变迁与选择（choice）有关如果需要多次投入硬币？a29模型检测方法（3）l若考虑硬币的数量和饮料机的容量对状态机进行扩展添加变量添加前置

20、条件和后续动作状态需附加变量值(amount,capacity)，如（s0,5,10）a30模型检测方法（4）l继续考虑自动饮料机如果投入的硬币面值不对或者是假的呢？为模型添加内部状态和行为？代表输入，！代表输出（外部环境）a31时间自动机l还可考虑对自动机添加时钟，即成为时间自动机！l时间自动机是当前非常重要的一个研究热点，因为它非常适合自动验证实时系统。l时间自动机通过使用有限的真值时钟变量提供了一个简单而又全面的方法来表示有时间约束的状态转换图。时间自动机的所有时钟在系统开始时从0开始计时，并以同样的速度增加。时钟可以随时被检测值的大小，也可以被独立地复位零值。a32时间自动机（2）l定

21、义1（时钟约束）对于一个时钟变量集X，时钟约束的集合(X)定义为如下文法：:=x c|c x|xc|cx|12|这里，x是X中的一个时钟，c是一个常量值。l定义2（时钟解释）一个时钟集合X的一个时钟解释v是指给每个时钟分配一个实数值；即：它是一个从X到非负实数集R的一个映射。X的一个时钟解释v满足X上的一个时钟约束，当且仅当依照v给出的值，为真。对于R，v+表示一个时钟解释，它对每一个时钟x的赋值为v(x)+。对YX，v Y:=0表示X的一个时钟解释，它给每个xY复位零值，并使其余的时钟值保持增加。a33时间自动机（3）l定义3（时间自动机）一个时间自动机可以表示为一个六元组：L 是一个有穷位

22、置集合；L0L 是一个起始位置集合；是一个有穷符号集合；X 是一个有穷时钟集合；I 是一个映射，它给L中的每个位置s指定(X)中的一个时钟约束；EL2xL是一个转换的集合。a34时间自动机（4）l一个使用时间自动机的例子：train gatea35时间自动机（5）l模型分为三个部分Train：对火车的行为建模Gate：对闸门控制器进行建模（互斥资源）IntQueue：对控制器的队列进行建模a36时间自动机（6）l可利用基于时间自动机的自动验证工具UPPAAL来进行相关属性验证。lUPPAAL由瑞典的Uppsala大学和丹麦的Aalborg大学联合开发,是具有世界先进水平的实时系统模拟和验证工具

23、。lUPPAAL 工具主要由编辑器(Editor)、模拟器(Simulator)和验证器(Verifier)组成。编辑器用于创建和编辑要分析的系统。模拟器是一个确认工具，它用于检查所建系统模型可能的执行是否有错。验证器通过快速搜索系统的状态空间来验证时钟约束和可达性。a37时间自动机（7）l可验证通过的属性：A Train1.Cross+Train2.Cross+Train3.Cross+Train4.Cross=1.任何时间通过gate的火车不会超过一列l若我们在IntQueue模型中将e:=list0错写成e:=list1。UPPAAL就会给出一种错误情况的例子a38定理证明方法l定理证明

24、工具使用Coq8.2；lCoq 是目前国际上交互式定理证明领域的主流工具，它基于归纳构造演算，有着强大的数学模型基础和很好的扩展性，并有完整的工具集。lCoq 有一支强大的全职研发队伍，支持开源，这对于想学习和使用该系统的读者非常有益。a39定理证明方法（2）l考虑一个简单的定理。(A(BC)(AB)(AC)a40定理证明方法（3）l单次和连续使用intros命令，可见只要证明C即可。a41定理证明方法（4）l使用apply命令，可见现在需要证明两个子目标：即A和B都成立。（apply：应用某一个前提和要证明的目标来获得一个子目标）a42定理证明方法（5）l第一个目标其实就是HA，所以使用ex

25、act命令。要证明第二个子目标B成立，通过应用H，只要证明A成立就可以了。A之前已经证明过了，这时只要利用assumption命令使用前面的证明结果。a43苏格兰悖论的证明l一个私人俱乐部有如下规则.每一个非苏格兰成员都穿红袜子；每个成员穿苏格兰裙或者不穿红袜子；已婚成员周日不外出；一个成员周日外出当且仅当他是苏格兰人；每个穿苏格兰裙的成员是苏格兰人并且已婚；每个苏格兰成员都穿苏格兰裙。l结论：这个俱乐部没有成员。a44苏格兰悖论的证明（2）a45程序验证l验证程序正确性的重要方法是霍尔逻辑。l霍尔是一位伟大的英国计算机科学家。1980年获得美国计算机学会(ACM)设立的计算机界最高奖图灵奖，

26、2000年获得日本稻盛财团设立的国际大奖 京都奖(尖端技术领域)，同年，英国女王伊丽莎白二世授予Tony Hoare爵士爵位，以表彰他对计算机科学所做出的巨大贡献。目前受聘于微软公司。a46程序验证（2）lHoare 逻辑的中心特征是Hoare 三元组。这种三元组描述一段代码的执行如何改变计算的状态。lHoare 三元组有如下形式PCQl这里的 P 和 Q 是断言（Assertion）而 C 是命令。P 叫做前置条件而 Q 叫做后置条件。断言实际上就是谓词逻辑的公式。l这个三元组在直觉上读做:只要 P 在 C 执行前的状态下成立，则在执行之后 Q 也成立。注意如果 C 不终止，也就没有“之后”了，所以 Q 在根本上可以是任何语句。a47程序验证（3）l部分正确性（C不一定终止）l完全正确性（保证C终止）a48程序验证（4）l一个计算非负整数平方根的例子。a49程序验证（5）l利用霍尔逻辑证明a50结论l形式化理论和方法