软件开发的形式化方法

《软件开发的形式化方法》由会员分享，可在线阅读，更多相关《软件开发的形式化方法（55页珍藏版）》请在金锄头文库上搜索。

1、软件开发的形式化方法软件开发的形式化方法硕士研究生讲义硕士研究生讲义 周清雷周清雷 ieqlzhouzzu.eduieqlzhouzzu.edu郑州大学信息工程学院郑州大学信息工程学院课程参考教材课程参考教材u参考材料p软件开发的形式化方法，古天龙编，2005 ，高等教育出版社p软件可靠性方法，Doron A. Peled著，王 林章等译，2012，机械工业出版社-2-第第1 1章章 软件及其开发概述软件及其开发概述-4-内容安排内容安排u软件开发的历史u软件危机u软件工程u形式化开发方法-5-1.1 1.1 软件开发的历史软件开发的历史u软件u软件开发p把现实世界的需求反映成软件的模型化并予

2、以 实现的过程u软件及开发的三个阶段p程序设计阶段（1946年-1956年）科学计算、机器语言及汇编语言、个体编程编程技巧、程序效率没有文档、软件一词尚未出现1.1 1.1 软件开发的历史软件开发的历史u软件及开发的三个阶段p程序系统阶段（1956年-1968年）1956年，J.Backus(77) Fortran语言诞生 大量数据处理、小组开发 “软件”一词出现：程序及其说明 60年代中期，软件危机。IBM OS/360 P.Brooksp软件工程阶段（1968年以来）1968年NATO会议，提出“软件工程”术语 工程化方法、描述语言、团队开发u软件的定义 当它被执行时能够提供所要求的功能和

3、性能的指令或计算机程序使得该程序能够满意地处理信息的数据结构描述程序的功能需求以及程序的操作和使用文档-6-1.2 1.2 软件危机软件危机u1968年，NATO会议提出了“软件危机”一词u软件危机包含两方面问题如何开发软件，以满足不断增长、日趋复杂的需求；如何维护数量不断膨胀的软件产品。u软件危机主要表现如下几个方面开发成本昂贵项目进度难控质量无法保证修改维护困难 -7-开发成本昂贵开发成本昂贵u1968年，美国花费于软件的投资高达60亿美元，有些系统，特别是军 用系统，软费用要高出硬件费用好几倍，例如美国全球军事指挥控制 系统的计算机硬件费用为1亿美元，而软件费用高达7.2亿美元。u198

4、0年美国政府的财政年度当中，计算机系统方面(软，硬件与服务) 共耗资达570亿美元，其中320亿美元(占总数的56)用于计算机软件 方面(与同年的美国汽车行业进行简单的比较，美国是当时的世界第 一汽车生产大国，汽车的年销售量为900万辆，总的销售额仅为720亿 美元。u技术的进步使得计算机硬件的成本持续降低，而软件成本则不断增长 ，软件成本在计算机系统总成本中所占的比例呈现日益扩大的趋势 来自美国空军计算机系统的数据表明，1970年，软件费用约占总费用 的60，1975年达到72，1980年达到80，1985年计达到85。这 种增长的速度是惊人的。（1979年，美国的国防预算为1258亿美元，

5、 其中9%用于计算机领域，约113亿美元。在这113亿美元当中，91亿美 元（约占80）用于软件投资。仅有22亿美元用于硬件设备）。-8-项目进度难控项目进度难控u在研究大型系统时，遇到越来越多的困难。有的系绞干脆失败了，损失了大 量金钱和人力；有的系统虽然完成了，但性能不理想，或推迟了许多年，经 费大大超过预算。如一个大项目负责人所说： “软件人员太像皇帝新衣故事 中的裁缝了、当我来检查软件开发工作时；所得到的回答好像对我说我们正 忙于编织这件带有魔法的织物。只要等一会儿，你就会看到这件织物是极其 美丽的。但是我什么也看不到，什么也摸不到，也说不出任何一个有关的数 字；没有任何办法得到一些信

6、息说明事情确实进行的非常顺利，而且我已经 知道许多人最终已经编织了一大堆昂贵的废物而离去，还有下少人最终什么 也没有作出来。”u为软件开发制定进度是根困难的事情：通常我们对一个任务根据其复杂性、 工作量及进度要求安排人力。如有10人月的工作量，则由一个人完成需要10 个月，由10个入完成则需要一个月。但这种工作量估计方式仅对各部分工作 互下干扰的情况下才适用，例如当各部分工作尚能很好地划分时，安排由不 同人完成不同部分的工作。但作为整体，尚需讨论合作，这种讨论交流活动 就增加了工作量。软件系统的结构很复杂，各部分附加联系极大。增加更多 人工作，往往不是缩短时间进度，而是会延缓进度。 -9-项目

7、进度难控项目进度难控u对于一项复杂的任务，通常难于通过增加人力来缩短开发 时间。Brook提出的法则“在已拖延的软件项目上增加入 力只会使其更难按期完成” 。这对于一般的工业产品来 说是难于想象的！u1995年，美国共取消810亿美元的软件项目，其中31%未完 取消，53%的项目延长一半时间，9%按期完成且不超期。 1998年，美国企业应用项目不成功比率75%,其中28%的项 目取消，40%无限拖长且资金超出预赛u对于一项复杂的任务，通常难于通过增加人力来缩短开发 时间。Brook提出的法则“在已拖延的软件项目上增加入 力只会使其更难按期完成” 。这对于一般的工业产品来 说是难于想象的！-10

8、-质量无法保证质量无法保证u1985年11月21日,由于计算机软件的错误,造成纽约银行与美联储电子结算系统收支失衡,发 生了超额支付,而这个问题一直到晚上才被发现,纽约银行当日帐务出现了230亿的短款。uTherac-25是加拿大原子能公司AECL和一家法国公司CGR联合开发的一种医疗设备，它产生 的高能光束或电子流能够杀死人体毒瘤而不会伤害毒瘤附近的人体健康组织。在1985年6月 到1987年1月，因为软件缺陷引发了6起由于电子流或X-光束的过量使用的医疗事故，造成4 人死亡、2人重伤的严重后果。u美国Florida州的福利救济系统用于处理数百万受抚养儿童、食品券、医疗援助等受资助家 庭接受

9、者的资格认证，其基于巨型机系统，支持84个数据库、1390个程序、12000多个终端 和个人计算机。1992年，该系统的错误使得成千上万的人收到了他们无权收到的救济，而 其他成千上万急需食品券的人却排着长队等待了好几天。该错误导致了多支付2.6亿美元以 及少支付5800万美元医疗补助的后果。 u1996年，欧洲航天局阿丽亚娜5型（Ariane5）火箭在发射后40秒钟后发生爆炸，2名法国士 兵当场死亡，损耗资产达10亿美元之巨，历时9年的航天计划因此严重受挫。爆炸原因在于 惯性导航系统软件技术要求和设计的错误。 u2002年，美国商务部的国立标准技术研究所（NIST）的调查报告：“据推测，由于软

10、件缺 陷而引起的损失额每年高达595亿美元。这一数字相当于美国国内生产值的0.6%”-11-软件维护困难软件维护困难u软件的维护任务特别重。事实上，正式投入使用的商用软件，总是存 在着一定数量的错误。随着时间的延伸，在不同的运行条件下，软件 就会出现故障，就需要维护。这种维护与通常意义下的设备（硬件） 维护是完全不同的。因为软件是逻辑元件，不是一种实物。软件故障 是软件中的逻辑故障所造成的，不是硬件的“用旧”、“磨损”之类问题 。软件维护不是更换某种备件，而是要纠正逻辑缺陷。当软件系统变 得庞大，问题变得复杂时，常常会发生“纠正一个错误带来更多新的 错误！”的问题。 u新的错误发现、运行环境的

11、改变、用户提出新要求，软件需不断修改u没有遵循标准、没有准确的文档，维护困难巨大。-12-软件危机的原因：复杂性软件危机的原因：复杂性u复杂性p 规规模的复杂杂性p 结结构的复杂杂性p 环环境的复杂杂性 p 领领域的复杂杂性 p 交流的复杂杂性 -13-软件规模的复杂性软件规模的复杂性u随着计算机应用的日益广泛，需要开发的软件规模越来越庞大 。以美国宇航局的软件系统为例：1963年，水星计划的软件系 统约有 200万条指令；1967年，双子星座计划系统约为400万条 指令；1973年，阿波罗计划系统达到1000万条指令；1979年， 哥伦比亚航天飞机系统更是达到了4000万条指令。u软件庞大的

12、规模是引起技术上和心理上挫折的一个重要因素； 此外，规模的复杂性引起了大量学习和理解上的负担。由于在 需求分析及生成规格的阶段需要搜集和分析的信息数量非常巨 大，从而可能会使得信息不正确或不完整，并且在审查阶段也 未能检查出来。u正如Leveson 所认为的：几乎所有与计算机过程控制系统有关 的事故都是源于这类由软件规模因素所引起的错误。-14-结构的复杂性结构的复杂性u结构复杂性体现在管理和技术两个方面。p在管理方面，开发小组用来组织和管理开发活动时所采用的层次 的宽度和深度，决定了用来管理系统的结构的复杂性；此外，软 件开发机构内部的惯例和制度可能会改变各小组之间的信息流动 ，从而增加了结

13、构复杂性。p在技术方面，软件系统的模块结构愈加复杂，模块之间复杂的调 用关系以及接口信息往往超过了人们所能接受的程度。这种结构 的复杂性可以用模块之间的耦合度来衡量，耦合度反映了在需求 变化的情况下，相应所需修改的模块的数量。-15-环境的复杂性环境的复杂性u首先，运行中的软件总是受其所处环境的影响，在接收到 外界环境的触发事件时，软件应该做出正确的响应。为了 保证软件的可靠性，原则上必须对其所处环境有很好的理 解，对外界环境可能产生的所有事件进行考虑，但这往往 是难以办到的。u其次，对于许多软件系统来说，人们往往缺乏对其所运行 的环境特性的认识。许多系统只有当成功地运行于其环境 时，才能对其

14、环境进行很好的理解。u再次，软件运行环境的多样性和异构性给软件开发者带来 了更大的挑战。-16-领域的复杂性领域的复杂性 u软件中所操作的对象仅仅是对应用领域真实对象的模拟，因而 软件开发者需要从现实世界中抽象出软件模型所需的部分，并 以其为基础构建软件。但是对于有的应用领域来说，这些模拟 只能是近似的。其原因可能是由于对应用领域对象的认识不完 全，或者是由于该模型所具有的苛刻条件限制，或者两者兼而 有之。u对于一个应用工程来说，其中所使用的模型应该是具有合理的 科学理论支持，并且经过良好测试的。然而在某些软件应用领 域中，并不存在可以认知的模型，或者没有准确的模型来描绘 相应的物理对象的几何

15、、拓扑以及其它特征。在这种缺少准确 认识的情况下，应用领域的某些方面很可能在软件中不能体现 出来。同时，由于有的软件是根据近似的模型来构建的，因而 这些模型不一定能反映事实情况。-17-交流的复杂性交流的复杂性u由于软件庞大的规模、大量的内部结构、以及应用领域的不同 属性等因素，在开发一个大型软件系统时所参与的不仅仅是单 个的人，而是一个团队。该团队里的每个人参与开发过程中的 一个或多个活动。此时，对于参与不同开发阶段的人来说，彼 此之间明确的交流非常重要。u一方面，由于结构的复杂性以及开发团队的庞大等原因，团队 成员之间的交流非常困难；u另一方面，成员之间在进行交流时使用的媒介往往是自然语言

16、 、图、表等非形式化的方式，这些媒介很难准确地描述出所开 发的产品的基本属性，并且，由于这些媒介本身所具有的二义 性，往往会使开发人员产生错误的理解，这种错误将会随着开 发过程的进行而逐渐蔓延开来，最终导致灾难性的后果。 -18-软件危机？软件危机？u软件危机的原因缺乏指导或实施软件设计、开发、维护的有效 理论、方法及技术 或者缺乏有效解决软件设计 、开发、维护中相关实际问题的理论、方法及 技术 u解决方案软件工程：工程的方法组织和管理形式化方法：正确性和可靠性-19-1.3 1.3 软件工程软件工程NATO、软件工程的定义u1983年IEEE给软件工程下的定义是：“软件工程是开发、远行、维护 和修复软件的系统方法”。主要强调软件工程是系统方法而不是某种 神秘的个人技巧。 uFairly认为：“软件工程学是为了在成本限额以内按时完成开发和修 改软件产品所需要的系统生产和维护技术及管理学科。” 软件工程的 目标：成本限额、按时完成，软件工程包含技术和管理。 uFritz Bauer给出了下述定义