《软件开发的形式化方法.ppt》由会员分享，可在线阅读，更多相关《软件开发的形式化方法.ppt（55页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、软件开发的形式化方法软件开发的形式化方法硕士研究生讲义周清雷 ieqlzhouzzu.eduieqlzhouzzu.edu郑州大学信息工程学院郑州大学信息工程学院郑州大学信息工程学院郑州大学信息工程学院课程参考教材课程参考教材u参考材料参考材料p软件开发的形式化方法软件开发的形式化方法，古天龙古天龙编，编，2005，高等教育，高等教育出版社出版社p软件可靠性方法软件可靠性方法，Doron A.Peled著，王著，王林章等译，林章等译，2012，机械工业出版社，机械工业出版社-2-第第1章章 软件及其开发概述软件及其开发概述-4-内容安排内容安排u软件开发的历史软件开发的历史u软件危机软件危机u
2、软件工程软件工程u形式化开发方法形式化开发方法-5-1.1 1.1 软件开发的历史软件开发的历史u软件软件u软件开发软件开发p把现实世界的需求反映成软件的模型化并予以把现实世界的需求反映成软件的模型化并予以实现的过程实现的过程u软件及开发的三个阶段软件及开发的三个阶段p程序设计阶段（程序设计阶段（19461946年年-1956-1956年）年）科学计算、机器语言及汇编语言、个体编程科学计算、机器语言及汇编语言、个体编程编程技巧、程序效率编程技巧、程序效率没有文档、软件一词尚未出现没有文档、软件一词尚未出现1.1 1.1 软件开发的历史软件开发的历史u软件及开发的三个阶段软件及开发的三个阶段p程
3、序系统阶段（程序系统阶段（19561956年年-1968-1968年）年）19561956年，年，J.Backus(77)FortranJ.Backus(77)Fortran语言诞生语言诞生大量数据处理、小组开发大量数据处理、小组开发“软件软件”一词出现：程序及其说明一词出现：程序及其说明6060年代中期，软件危机。年代中期，软件危机。IBM OS/360 IBM OS/360 P.BrooksP.Brooksp软件工程阶段（软件工程阶段（19681968年以来）年以来）19681968年年NATONATO会议，提出会议，提出“软件工程软件工程”术语术语工程化方法、描述语言、团队开发工程化方法
4、、描述语言、团队开发u软件的定义软件的定义 当它被执行时能够提供所要求的功能和性能的指令或计算机程序当它被执行时能够提供所要求的功能和性能的指令或计算机程序 使得该程序能够满意地处理信息的数据结构使得该程序能够满意地处理信息的数据结构 描述程序的功能需求以及程序的操作和使用文档描述程序的功能需求以及程序的操作和使用文档-6-1.2 1.2 软件危机软件危机u19681968年，年，NATONATO会议提出了会议提出了“软件危机软件危机”一词一词u软件危机包含两方面问题软件危机包含两方面问题如何开发软件，以满足不断增长、日趋复杂的需求；如何开发软件，以满足不断增长、日趋复杂的需求；如何维护数量不
5、断膨胀的软件产品。如何维护数量不断膨胀的软件产品。u软件危机主要表现如下几个方面软件危机主要表现如下几个方面开发成本昂贵开发成本昂贵项目进度难控项目进度难控质量无法保证质量无法保证修改维护困难修改维护困难-7-开发成本昂贵开发成本昂贵u19681968年，美国花费于软件的投资高达年，美国花费于软件的投资高达6060亿美元，有些系统，特别是军亿美元，有些系统，特别是军用系统，软费用要高出硬件费用好几倍，例如美国全球军事指挥控制用系统，软费用要高出硬件费用好几倍，例如美国全球军事指挥控制系统的计算机硬件费用为系统的计算机硬件费用为1 1亿美元，而软件费用高达亿美元，而软件费用高达7.27.2亿美元
6、。亿美元。u19801980年美国政府的财政年度当中，计算机系统方面年美国政府的财政年度当中，计算机系统方面(软，硬件与服务软，硬件与服务)共耗资达共耗资达570570亿美元，其中亿美元，其中320320亿美元亿美元(占总数的占总数的5656)用于计算机软件用于计算机软件方面方面(与同年的美国汽车行业进行简单的比较，美国是当时的世界第与同年的美国汽车行业进行简单的比较，美国是当时的世界第一汽车生产大国，汽车的年销售量为一汽车生产大国，汽车的年销售量为900900万辆，总的销售额仅为万辆，总的销售额仅为720720亿亿美元。美元。u技术的进步使得计算机硬件的成本持续降低，而软件成本则不断增长，技
7、术的进步使得计算机硬件的成本持续降低，而软件成本则不断增长，软件成本在计算机系统总成本中所占的比例呈现日益扩大的趋势来软件成本在计算机系统总成本中所占的比例呈现日益扩大的趋势来自美国空军计算机系统的数据表明，自美国空军计算机系统的数据表明，19701970年，软件费用约占总费用的年，软件费用约占总费用的6060，19751975年达到年达到7272，19801980年达到年达到8080，19851985年计达到年计达到8585。这种。这种增长的速度是惊人的。（增长的速度是惊人的。（19791979年，美国的国防预算为年，美国的国防预算为12581258亿美元，其亿美元，其中中9%9%用于计算机
8、领域，约用于计算机领域，约113113亿美元。在这亿美元。在这113113亿美元当中，亿美元当中，9191亿美元亿美元（约占（约占8080）用于软件投资。仅有）用于软件投资。仅有2222亿美元用于硬件设备）。亿美元用于硬件设备）。-8-项目进度难控项目进度难控u在研究大型系统时，遇到越来越多的困难。有的系绞干脆失败了，损失了大在研究大型系统时，遇到越来越多的困难。有的系绞干脆失败了，损失了大量金钱和人力；有的系统虽然完成了，但性能不理想，或推迟了许多年，经量金钱和人力；有的系统虽然完成了，但性能不理想，或推迟了许多年，经费大大超过预算。如一个大项目负责人所说：费大大超过预算。如一个大项目负责人
9、所说：“软件人员太像皇帝新衣故事软件人员太像皇帝新衣故事中的裁缝了、当我来检查软件开发工作时；所得到的回答好像对我说我们正中的裁缝了、当我来检查软件开发工作时；所得到的回答好像对我说我们正忙于编织这件带有魔法的织物。只要等一会儿，你就会看到这件织物是极其忙于编织这件带有魔法的织物。只要等一会儿，你就会看到这件织物是极其美丽的。但是我什么也看不到，什么也摸不到，也说不出任何一个有关的数美丽的。但是我什么也看不到，什么也摸不到，也说不出任何一个有关的数字；没有任何办法得到一些信息说明事情确实进行的非常顺利，而且我已经字；没有任何办法得到一些信息说明事情确实进行的非常顺利，而且我已经知道许多人最终已
10、经编织了一大堆昂贵的废物而离去，还有下少人最终什么知道许多人最终已经编织了一大堆昂贵的废物而离去，还有下少人最终什么也没有作出来。也没有作出来。”u为软件开发制定进度是根困难的事情：通常我们对一个任务根据其复杂性、为软件开发制定进度是根困难的事情：通常我们对一个任务根据其复杂性、工作量及进度要求安排人力。如有工作量及进度要求安排人力。如有1010人月的工作量，则由一个人完成需要人月的工作量，则由一个人完成需要1010个月，由个月，由1010个入完成则需要一个月。但这种工作量估计方式仅对各部分工作个入完成则需要一个月。但这种工作量估计方式仅对各部分工作互下干扰的情况下才适用，例如当各部分工作尚能
11、很好地划分时，安排由不互下干扰的情况下才适用，例如当各部分工作尚能很好地划分时，安排由不同人完成不同部分的工作。但作为整体，尚需讨论合作，这种讨论交流活动同人完成不同部分的工作。但作为整体，尚需讨论合作，这种讨论交流活动就增加了工作量。软件系统的结构很复杂，各部分附加联系极大。就增加了工作量。软件系统的结构很复杂，各部分附加联系极大。增加更多增加更多人工作，往往不是缩短时间进度，而是会延缓进度。人工作，往往不是缩短时间进度，而是会延缓进度。-9-项目进度难控项目进度难控u对于一项复杂的任务，通常难于通过增加人力来缩短开发对于一项复杂的任务，通常难于通过增加人力来缩短开发时间。时间。BrookB
12、rook提出的法则提出的法则“在已拖延的软件项目上增加入在已拖延的软件项目上增加入力只会使其更难按期完成力只会使其更难按期完成”。这对于一般的工业产品来。这对于一般的工业产品来说是难于想象的！说是难于想象的！u19951995年，美国共取消年，美国共取消810810亿美元的软件项目，其中亿美元的软件项目，其中31%31%未完未完取消，取消，53%53%的项目延长一半时间，的项目延长一半时间，9%9%按期完成且不超期。按期完成且不超期。19981998年，美国企业应用项目不成功比率年，美国企业应用项目不成功比率75%,75%,其中其中28%28%的项的项目取消，目取消，40%40%无限拖长且资金
13、超出预赛无限拖长且资金超出预赛u对于一项复杂的任务，通常难于通过增加人力来缩短开发对于一项复杂的任务，通常难于通过增加人力来缩短开发时间。时间。BrookBrook提出的法则提出的法则“在已拖延的软件项目上增加入在已拖延的软件项目上增加入力只会使其更难按期完成力只会使其更难按期完成”。这对于一般的工业产品来。这对于一般的工业产品来说是难于想象的！说是难于想象的！-10-质量无法保证质量无法保证u19851985年年1111月月2121日日,由于计算机软件的错误由于计算机软件的错误,造成造成纽约银行与美联储电子结算系统纽约银行与美联储电子结算系统收支失衡收支失衡,发发生了超额支付生了超额支付,而
14、这个问题一直到晚上才被发现而这个问题一直到晚上才被发现,纽约银行当日帐务出现了纽约银行当日帐务出现了230230亿的短款。亿的短款。uTherac-25Therac-25是加拿大原子能公司是加拿大原子能公司AECLAECL和一家法国公司和一家法国公司CGRCGR联合开发的一种医疗设备，它产生联合开发的一种医疗设备，它产生的高能光束或电子流能够杀死人体毒瘤而不会伤害毒瘤附近的人体健康组织。在的高能光束或电子流能够杀死人体毒瘤而不会伤害毒瘤附近的人体健康组织。在19851985年年6 6月月到到19871987年年1 1月，因为软件缺陷引发了月，因为软件缺陷引发了6 6起由于电子流或起由于电子流或
15、X-X-光束的过量使用的医疗事故，造成光束的过量使用的医疗事故，造成4 4人死亡、人死亡、2 2人重伤的严重后果。人重伤的严重后果。u美国美国FloridaFlorida州的福利救济系统州的福利救济系统用于处理数百万受抚养儿童、食品券、医疗援助等受资助家用于处理数百万受抚养儿童、食品券、医疗援助等受资助家庭接受者的资格认证，其基于巨型机系统，支持庭接受者的资格认证，其基于巨型机系统，支持8484个数据库、个数据库、13901390个程序、个程序、1200012000多个终端多个终端和个人计算机。和个人计算机。19921992年，该系统的错误使得成千上万的人收到了他们无权收到的救济，而年，该系统
16、的错误使得成千上万的人收到了他们无权收到的救济，而其他成千上万急需食品券的人却排着长队等待了好几天。该错误导致了多支付其他成千上万急需食品券的人却排着长队等待了好几天。该错误导致了多支付2.62.6亿美元以亿美元以及少支付及少支付58005800万美元医疗补助的后果。万美元医疗补助的后果。u19961996年，欧洲航天局年，欧洲航天局阿丽亚娜阿丽亚娜5 5型（型（Ariane5Ariane5）火箭在发射后火箭在发射后4040秒钟后发生爆炸，秒钟后发生爆炸，2 2名法国士名法国士兵当场死亡，损耗资产达兵当场死亡，损耗资产达1010亿美元之巨，历时亿美元之巨，历时9 9年的航天计划因此严重受挫。爆
17、炸原因在于年的航天计划因此严重受挫。爆炸原因在于惯性导航系统软件技术要求和设计的错误。惯性导航系统软件技术要求和设计的错误。u20022002年，美国商务部的国立标准技术研究所（年，美国商务部的国立标准技术研究所（NISTNIST）的调查报告：的调查报告：“据推测，由于软件缺据推测，由于软件缺陷而引起的损失额每年高达陷而引起的损失额每年高达595595亿美元。这一数字相当于美国国内生产值的亿美元。这一数字相当于美国国内生产值的0.6%0.6%”-11-软件维护困难软件维护困难u软件的维护任务特别重。软件的维护任务特别重。事实上，正式投入使用的商用软件，总是存事实上，正式投入使用的商用软件，总是
18、存在着一定数量的错误。随着时间的延伸，在不同的运行条件下，软件在着一定数量的错误。随着时间的延伸，在不同的运行条件下，软件就会出现故障，就需要维护。这种维护与通常意义下的设备（硬件）就会出现故障，就需要维护。这种维护与通常意义下的设备（硬件）维护是完全不同的。因为软件是逻辑元件，不是一种实物。软件故障维护是完全不同的。因为软件是逻辑元件，不是一种实物。软件故障是软件中的逻辑故障所造成的，不是硬件的是软件中的逻辑故障所造成的，不是硬件的“用旧用旧”、“磨损磨损”之类之类问题。软件维护不是更换某种备件，而是要纠正逻辑缺陷。当软件系问题。软件维护不是更换某种备件，而是要纠正逻辑缺陷。当软件系统变得庞
19、大，问题变得复杂时，常常会发生统变得庞大，问题变得复杂时，常常会发生“纠正一个错误带来更多纠正一个错误带来更多新的错误！新的错误！”的问题。的问题。u新的错误发现、运行环境的改变、用户提出新要求，软件需不断修改新的错误发现、运行环境的改变、用户提出新要求，软件需不断修改u没有遵循标准、没有准确的文档，维护困难巨大。没有遵循标准、没有准确的文档，维护困难巨大。-12-软件危机的原因：复杂性软件危机的原因：复杂性u复杂性复杂性p 规规模的复模的复杂杂性性p 结结构的复构的复杂杂性性p 环环境的复境的复杂杂性性 p 领领域的复域的复杂杂性性 p 交流的复交流的复杂杂性性 -13-软件规模的复杂性软件
20、规模的复杂性u随着计算机应用的日益广泛，需要开发的软件规模越来越庞大。随着计算机应用的日益广泛，需要开发的软件规模越来越庞大。以美国宇航局的软件系统为例：以美国宇航局的软件系统为例：19631963年，年，水星计划水星计划的软件系统的软件系统约有约有 200 200万条指令；万条指令；19671967年，年，双子星座计划系统双子星座计划系统约为约为400400万条指万条指令；令；19731973年，年，阿波罗计划系统阿波罗计划系统达到达到10001000万条指令；万条指令；19791979年，年，哥哥伦比亚航天飞机系统伦比亚航天飞机系统更是达到了更是达到了40004000万条指令。万条指令。u
21、软件庞大的规模是引起技术上和心理上挫折的一个重要因素；软件庞大的规模是引起技术上和心理上挫折的一个重要因素；此外，规模的复杂性引起了大量学习和理解上的负担。由于在此外，规模的复杂性引起了大量学习和理解上的负担。由于在需求分析及生成规格的阶段需要搜集和分析的信息数量非常巨需求分析及生成规格的阶段需要搜集和分析的信息数量非常巨大，从而可能会使得信息不正确或不完整，并且在审查阶段也大，从而可能会使得信息不正确或不完整，并且在审查阶段也未能检查出来。未能检查出来。u正如正如LevesonLeveson 所认为的：所认为的：几乎所有与计算机过程控制系统有关几乎所有与计算机过程控制系统有关的事故都是源于这
22、类由软件规模因素所引起的错误。的事故都是源于这类由软件规模因素所引起的错误。-14-结构的复杂性结构的复杂性u结构复杂性体现在管理和技术两个方面。结构复杂性体现在管理和技术两个方面。p在管理方面，开发小组用来组织和管理开发活动时所采用的在管理方面，开发小组用来组织和管理开发活动时所采用的层次层次的宽度和深度的宽度和深度，决定了用来管理系统的结构的复杂性；此外，软，决定了用来管理系统的结构的复杂性；此外，软件开发机构内部的件开发机构内部的惯例和制度惯例和制度可能会改变各小组之间的信息流动，可能会改变各小组之间的信息流动，从而增加了结构复杂性。从而增加了结构复杂性。p在技术方面，软件系统的模块结构
23、愈加复杂，在技术方面，软件系统的模块结构愈加复杂，模块之间复杂的调模块之间复杂的调用关系以及接口信息用关系以及接口信息往往超过了人们所能接受的程度。这种结构往往超过了人们所能接受的程度。这种结构的复杂性可以用模块之间的的复杂性可以用模块之间的耦合度耦合度来衡量，耦合度反映了在需求来衡量，耦合度反映了在需求变化的情况下，相应所需修改的模块的数量。变化的情况下，相应所需修改的模块的数量。-15-环境的复杂性环境的复杂性u首先，运行中的软件总是受其所处环境的影响，在接收到首先，运行中的软件总是受其所处环境的影响，在接收到外界环境的触发事件外界环境的触发事件时，软件应该做出正确的响应。为了时，软件应该
24、做出正确的响应。为了保证软件的可靠性，原则上必须对其所处环境有很好的理保证软件的可靠性，原则上必须对其所处环境有很好的理解，对外界环境可能产生的所有事件进行考虑，但这往往解，对外界环境可能产生的所有事件进行考虑，但这往往是难以办到的。是难以办到的。u其次，对于许多软件系统来说，人们往往其次，对于许多软件系统来说，人们往往缺乏对其所运行缺乏对其所运行的环境特性的认识的环境特性的认识。许多系统只有当成功地运行于其环境。许多系统只有当成功地运行于其环境时，才能对其环境进行很好的理解。时，才能对其环境进行很好的理解。u再次，软件运行环境的再次，软件运行环境的多样性和异构性多样性和异构性给软件开发者带来
25、给软件开发者带来了更大的挑战。了更大的挑战。-16-领域的复杂性领域的复杂性 u软件中所操作的对象仅仅是对应用领域真实对象的模拟，因而软件中所操作的对象仅仅是对应用领域真实对象的模拟，因而软件开发者需要从现实世界中抽象出软件模型所需的部分，并软件开发者需要从现实世界中抽象出软件模型所需的部分，并以其为基础构建软件。但是对于有的应用领域来说，这些模拟以其为基础构建软件。但是对于有的应用领域来说，这些模拟只能是近似的。其原因可能是由于对应用领域对象的只能是近似的。其原因可能是由于对应用领域对象的认识不完认识不完全全，或者是由于该模型所具有的，或者是由于该模型所具有的苛刻条件限制苛刻条件限制，或者两
26、者兼而，或者两者兼而有之。有之。u对于一个应用工程来说，其中所使用的模型应该是具有合理的对于一个应用工程来说，其中所使用的模型应该是具有合理的科学理论支持科学理论支持，并且经过良好测试的。然而在某些软件应用领，并且经过良好测试的。然而在某些软件应用领域中，并不存在可以认知的模型，或者没有准确的模型来描绘域中，并不存在可以认知的模型，或者没有准确的模型来描绘相应的物理对象的几何、拓扑以及其它特征。在这种缺少准确相应的物理对象的几何、拓扑以及其它特征。在这种缺少准确认识的情况下，应用领域的某些方面很可能在软件中不能体现认识的情况下，应用领域的某些方面很可能在软件中不能体现出来。同时，由于有的软件是
27、根据近似的模型来构建的，因而出来。同时，由于有的软件是根据近似的模型来构建的，因而这些这些模型不一定能反映事实模型不一定能反映事实情况。情况。-17-交流的复杂性交流的复杂性u由于软件庞大的规模、大量的内部结构、以及应用领域的不同由于软件庞大的规模、大量的内部结构、以及应用领域的不同属性等因素，在开发一个大型软件系统时所参与的不仅仅是单属性等因素，在开发一个大型软件系统时所参与的不仅仅是单个的人，而是一个团队。该团队里的每个人参与开发过程中的个的人，而是一个团队。该团队里的每个人参与开发过程中的一个或多个活动。此时，对于参与不同开发阶段的人来说，彼一个或多个活动。此时，对于参与不同开发阶段的人
28、来说，彼此之间此之间明确的交流非常重要明确的交流非常重要。u一方面，由于结构的复杂性以及开发一方面，由于结构的复杂性以及开发团队的庞大团队的庞大等原因，团队等原因，团队成员之间的交流非常困难；成员之间的交流非常困难；u另一方面，成员之间在进行交流时使用的媒介往往是自然语言、另一方面，成员之间在进行交流时使用的媒介往往是自然语言、图、表等非形式化的方式，这些媒介很难准确地描述出所开发图、表等非形式化的方式，这些媒介很难准确地描述出所开发的产品的基本属性，并且，由于这些的产品的基本属性，并且，由于这些媒介本身所具有的二义性媒介本身所具有的二义性，往往会使开发人员产生错误的理解，这种错误将会随着开发
29、过往往会使开发人员产生错误的理解，这种错误将会随着开发过程的进行而逐渐蔓延开来，最终导致灾难性的后果。程的进行而逐渐蔓延开来，最终导致灾难性的后果。-18-软件危机？软件危机？u软件危机的原因软件危机的原因缺乏指导或实施软件设计、开发、维护的有效缺乏指导或实施软件设计、开发、维护的有效理论、方法及技术理论、方法及技术 或者缺乏有效解决软件设计、或者缺乏有效解决软件设计、开发、维护中相关实际问题的理论、方法及技开发、维护中相关实际问题的理论、方法及技术术 u解决方案解决方案软件工程：工程的方法组织和管理软件工程：工程的方法组织和管理形式化方法：正确性和可靠性形式化方法：正确性和可靠性-19-1.
30、3 1.3 软件工程软件工程NATONATO、软件工程的定义、软件工程的定义u19831983年年IEEEIEEE给给软软件件工工程程下下的的定定义义是是：“软软件件工工程程是是开开发发、远远行行、维维护护和和修修复复软软件件的的系系统统方方法法”。主主要要强强调调软软件件工工程程是是系系统统方方法法而而不不是是某某种种神秘的个人技巧。神秘的个人技巧。uFairlyFairly认认为为：“软软件件工工程程学学是是为为了了在在成成本本限限额额以以内内按按时时完完成成开开发发和和修修改改软软件件产产品品所所需需要要的的系系统统生生产产和和维维护护技技术术及及管管理理学学科科。”软软件件工工程程的目
31、标：成本限额、按时完成，软件工程包含技术和管理。的目标：成本限额、按时完成，软件工程包含技术和管理。uFritz Fritz BauerBauer给给出出了了下下述述定定义义：“软软件件工工程程是是为为了了经经济济地地获获得得可可靠靠的的且且能能在在实实际际机机器器上上有有效效运运行行的的软软件件，而而建建立立和和使使用用的的完完善善的的工工程程化化原原则则。”不不仅仅指指出出软软件件工工程程的的目目标标是是经经济济地地开开发发出出高高质质量量的的软软什什，而而且且强调了软件工程是一门工程学科，应建立并使用完善的工程化原则。强调了软件工程是一门工程学科，应建立并使用完善的工程化原则。u1993
32、1993年年IEEEIEEE进进一一步步给给出出了了一一个个更更全全面面的的定定义义“软软件件工工程程是是：把把系系统统化化的的、规规范范的的、可可度度量量的的途途径径应应用用于于软软件件并并发发、运运行行和和维维护护的的过过程程，也就是把工程化应用于软件中；也就是把工程化应用于软件中；研究研究中提到的途径。中提到的途径。”-20-软件工程目标、内容软件工程目标、内容u目标目标成功地生产具有正确性、可用性以及开销合宜的产品。成功地生产具有正确性、可用性以及开销合宜的产品。u三要素三要素方法：构造软件的技术方法：构造软件的技术工具：自动化、半自动化的支持工具：自动化、半自动化的支持过程：综合运用
33、方法和工具分步过程：综合运用方法和工具分步u内容内容软件工程过程、生命周期、开发模型、开发方法、工具软件工程过程、生命周期、开发模型、开发方法、工具开发环境、计算机辅助软件工程、软件工程经济学开发环境、计算机辅助软件工程、软件工程经济学-21-软件工程过程软件工程过程u规定了获取、供应、开发、操作以及维护软件时，所需要规定了获取、供应、开发、操作以及维护软件时，所需要实施的过程、活动和任务。实施的过程、活动和任务。u包括：包括：开发过程：分析、设计、编码、集成、测试、安装和验收开发过程：分析、设计、编码、集成、测试、安装和验收管理过程：范围定义、计划、实施和控制、评审评价、完成管理过程：范围定
34、义、计划、实施和控制、评审评价、完成供应过程：供方按合同提供系统、软件、服务供应过程：供方按合同提供系统、软件、服务获取过程：需方获取过程：需方操作过程：运行系统操作过程：运行系统维护过程：修改维护过程：修改支持过程：生命周期的支持支持过程：生命周期的支持-22-软件生命周期软件生命周期u五个活动五个活动需求分析和规格需求分析和规格软件设计：逻辑模型软件设计：逻辑模型转换转换为软件方案，总体结构、模为软件方案，总体结构、模块算法块算法代码编写代码编写软件测试：模块测试、组装测试、确认测试软件测试：模块测试、组装测试、确认测试运行维护运行维护-23-软件开发模型软件开发模型组织软件生命周期内的各
35、种活动：组织软件生命周期内的各种活动：次序、任务、准则次序、任务、准则u瀑布模型（瀑布模型（Winston Royce 1970)Winston Royce 1970)计划任务书、需求规格、设计规格、程序、测试、维护计划任务书、需求规格、设计规格、程序、测试、维护缺点：需求分析的准确性问题、错误反馈不及时、进度难以控制缺点：需求分析的准确性问题、错误反馈不及时、进度难以控制u原型模型原型模型快速成型、评估、反馈、改进快速成型、评估、反馈、改进缺点：用户不理解、开发人员的惰性不愿意优化缺点：用户不理解、开发人员的惰性不愿意优化-24-软件开发模型软件开发模型u螺旋模型螺旋模型 （Barry W.
36、Boehm,1988Barry W.Boehm,1988）制定计划、风险评估、实施工程、用户评价制定计划、风险评估、实施工程、用户评价-演化演化缺点：丰富的评估经验和专业知识，要求高缺点：丰富的评估经验和专业知识，要求高u构件模型构件模型 即插即用编程即插即用编程标识、选用、组装，构件库标识、选用、组装，构件库优点：生产率、可靠、灵活、可维护优点：生产率、可靠、灵活、可维护-25-软件开发模型软件开发模型u四代技术模型（四代技术模型（4GT)4GT)基于一系列软件工具的开发基于一系列软件工具的开发核心：规格软件的能力核心：规格软件的能力不支持软件开发的全过程不支持软件开发的全过程侧重：设计阶段
37、、实现阶段、支持界面侧重：设计阶段、实现阶段、支持界面缺点：维护问题缺点：维护问题u变换模型变换模型基于形式化规格及程序变换的开发模型，自动程序设计模型或形基于形式化规格及程序变换的开发模型，自动程序设计模型或形式化方法模型式化方法模型三个核心活动：规格生成、形式化验证、计算机辅助程序求精三个核心活动：规格生成、形式化验证、计算机辅助程序求精高效、可靠、可控，但要求高高效、可靠、可控，但要求高-26-软件开发方法软件开发方法u软件开发方法是指在某种思想的指导下使软件开发方法是指在某种思想的指导下使用已经定义好的一系列技术和表示工具来用已经定义好的一系列技术和表示工具来组织软件开发过程的方法组织
38、软件开发过程的方法u一般表述成一系列步骤一般表述成一系列步骤u典型的传统软件开发方法：典型的传统软件开发方法：结构化方法结构化方法面向数据结构方法面向数据结构方法面向对象的开发方法面向对象的开发方法-27-软件工具软件工具u辅助软件开发、维护和管理的一系列软件辅助软件开发、维护和管理的一系列软件u种类繁多种类繁多管理工具、配置工具、分析设计工具、编码工具、测试工具管理工具、配置工具、分析设计工具、编码工具、测试工具测试工具：数据获取、静态分析、动态测试、模拟、测试管理测试工具：数据获取、静态分析、动态测试、模拟、测试管理维护工具：版本控制、文档分析、开发信息库、逆向过程等维护工具：版本控制、文
39、档分析、开发信息库、逆向过程等-28-软件开发环境软件开发环境u支持软件产品生产的软件系统，由软件工支持软件产品生产的软件系统，由软件工具和集成机制组成。具和集成机制组成。软件工具软件工具集成机制：为工具集成和软件的开发、管理，以及维护提供统一集成机制：为工具集成和软件的开发、管理，以及维护提供统一的支持。的支持。前端开发环境、后端开发环境、软件维护环境、逆向工程环境前端开发环境、后端开发环境、软件维护环境、逆向工程环境-29-计算机辅助软件工程计算机辅助软件工程u实现软件生命周期各个环节的自动化实现软件生命周期各个环节的自动化整个生命周期的支持，解决生产效率整个生命周期的支持，解决生产效率软
40、件工程经济学软件工程经济学u从经济学的观点来研究、分析如何有效地从经济学的观点来研究、分析如何有效地开发、发布软件产品和支持用户使用开发、发布软件产品和支持用户使用成本估算技术、模型、效益分析、多目标决策、不确成本估算技术、模型、效益分析、多目标决策、不确定性的处理、风险分析、工期估计定性的处理、风险分析、工期估计-30-1.4 形式化方法形式化方法u形式化方法概念形式化方法概念u发展发展u目的目的u形式化方法软件开发形式化方法软件开发 变换模型变换模型u形式化规格形式化规格u形式化验证形式化验证u程序求精程序求精u形式化方法的应用形式化方法的应用-31-形式化方法概念形式化方法概念u形形式式
41、化化方方法法是是渗渗透透在在软软件件生生命命期期中中各各个个环环节节（如如：需需求求、设设计计、实实现现、测测试试等等）的的数数学学方方法法 或或者者 具具有有严严格格数数学学基基础础的的软件开发方法软件开发方法u形形式式化化方方法法的的基基本本含含义义是是借借助助数数学学的的方方法法来来研研究究计计算算机机科科学学中的有关问题。中的有关问题。uEncyclopedia Encyclopedia of of Software Software EngineeringEngineering对对形形式式化化方方法法定定义义为为：“用用于于开开发发计计算算机机系系统统的的形形式式化化方方法法是是基基
42、于于数数学学的的用用于于描描述述系系统统性性质质的的技技术术。这这样样的的形形式式化化方方法法提提供供了了一一个个框框架架，人人们们可可以以在在该该框框架架中中以以系系统统的的方方式式刻刻画画、开开发发和和验验证证系系统统”。-32-形式化方法概念形式化方法概念u在在软软件件开开发发的的全全过过程程中中，凡凡是是采采用用严严格格的的数数学学语语言言，具具有有精确的数学语义的方法，都称为形式化方法。精确的数学语义的方法，都称为形式化方法。从从广广义义角角度度，形形式式化化方方法法是是软软件件开开发发过过程程中中分分析析、设设计计及及实实现现的的系统工程方法。系统工程方法。狭狭义义地地，形形式式化
43、化方方法法是是软软件件规规格格（specificationspecification）和和验验证证（verificationverification）的方法。的方法。u形式化方法又分为形式化方法又分为形式化规格方法形式化规格方法和和形式化验证方法形式化验证方法。形形式式化化规规格格是是通通过过具具有有明明确确数数学学定定义义的的文文法法和和语语义义的的方方法法或或语语言言对软件的期望特性或者行为进行的精确、简洁描述。对软件的期望特性或者行为进行的精确、简洁描述。形形式式化化验验证证是是基基于于已已建建立立的的形形式式化化规规格格，对对软软件件的的相相关关特特性性进进行行评价的数学分析和证明。评
44、价的数学分析和证明。-33-发展历史发展历史u2020世世纪纪5050年年代代后后期期，BackusBackus（7777）提提出出了了巴巴克克斯斯范范式式（Backus Backus normal normal formulaformula，简称简称BNFBNF），），作为描述程序设计语言语法的元语言；作为描述程序设计语言语法的元语言；u2020世世纪纪6060年年代代，FloydFloyd（7878）、HoareHoare（8080）和和MannaManna等等开开展展的的程程序序正正确确性性证证明明研研究究推推动动了了形形式式化化方方法法的的发发展展，他他们们试试图图用用数数学学方方法法
45、来来证证明明程程序序的的正正确确性性并并发发展展成成为为了了各各种种程程序序验验证证方方法法，但但是是受受程程序序规规模模限限制制这这些些方方法并未达到预期的应用效果；法并未达到预期的应用效果；u2020世世纪纪8080年年代代，在在硬硬件件设设计计领领域域形形式式化化方方法法的的工工业业应应用用结结果果，掀掀起起了了软软件件形形式式化化开开发发方方法法的的学学术术研研究究和和工工业业应应用用的的热热潮潮，Pnueli(Pnueli(9696)提提出出了了反反应应式式系系统统规规格格和和验验证证的的时时态态逻逻辑辑(temporal temporal logiclogic，简简称称TL)TL)
46、方方法法，ClarkeClarke、EmersonEmerson、Sifakis(Sifakis(0707)提提出出了了有有穷穷状状态态并并发发系系统统的的模模型型检检验验(model checking)model checking)方法；方法；u近近十十年年来来，建建立立了了易易于于理理解解的的规规格格概概念念和和术术语语、形形式式化化规规格格方方法法及及语语言言、形式化验证技术形式化验证技术:模型检测和定理证明，开发了支撑工具和环境模型检测和定理证明，开发了支撑工具和环境-34-形式化方法主要目标形式化方法主要目标u形式化方法用于软件开发的主要目的是保证软件的正确性。形式化方法用于软件开发
47、的主要目的是保证软件的正确性。u形形式式化化方方法法基基于于严严格格的的数数学学，而而在在软软件件开开发发过过程程中中使使用用数数学学具具有有如如下下优优点点：数数学学是是准准确确的的建建模模媒媒体体，能能够够对对现现象象、对对象象、动动作作等等进进行行简简洁洁、准准确确的的描描述述；数数学学支支持持抽抽象象，它它使使得得规规格格的的本本质质可可以以被被展展示示出出来来，并并且且还还可可以以以以一一种种有有组组织织的的方方式式来来表表示示系系统统规规格格中中的的抽抽象象层层次次；数数学学提提供供了了高高层层确确认认的的手手段段，可可以以使使用用数数学学证证明明来来揭揭示示规规格格中中的的矛矛盾
48、盾性性和和不不完整性、以及用来展示设计和规格之间的一致情况等。完整性、以及用来展示设计和规格之间的一致情况等。u（从从软软件件工工程程知知识识体体角角度度）20042004年年5 5月月，IEEE-CSIEEE-CS和和ACMACM联联合合任任务务组组提提交交了了CCSECCSE（ComputingComputing Curriculum-Software Curriculum-Software EngineeringEngineering）最最终终报报告告，在在 该该 报报 告告 给给 出出 的的 SEEKSEEK（SoftwareSoftware Engineering Engineeri
49、ng Education Education KnowledgeKnowledge）中中，“软软件件的的形形式式化化方方法法（Formal Formal Methods Methods in in Software Software EngineeringEngineering）”被单列为一门被单列为一门必修课程（序列号为必修课程（序列号为SE313SE313）。-36-形式化方法软件开发形式化方法软件开发u变化模型：把现实世界的需求反映成软件的模型化过程变化模型：把现实世界的需求反映成软件的模型化过程u模型化涉及：现实世界、模型表示、计算机系统模型化涉及：现实世界、模型表示、计算机系统u开发
50、过程的任务分为：模型获取、模型验证、模型变换开发过程的任务分为：模型获取、模型验证、模型变换模型获取：模型获取：从现实世界向模型表示转换，对应软件生命周期中的从现实世界向模型表示转换，对应软件生命周期中的需求分析、规格、设计活动需求分析、规格、设计活动模型验证：模型验证：是否满足需求及具有所期望的特性是否满足需求及具有所期望的特性模型变换：模型变换：从模型表示向计算机系统变换的过程。关键任务是一从模型表示向计算机系统变换的过程。关键任务是一致性测试，对应软件生命周期中的实现和测试致性测试，对应软件生命周期中的实现和测试u这些任务对应三方面的活动：这些任务对应三方面的活动：形式化规格、形式化验证