第1部分 软件工程基本教程

第1章

软件工程概述

软件工程（Software Engineering，SE）概念是在20世纪60年代末期提出的。这一概念的提出，目的是倡导以工程的原理、原则和方法进行软件开发，用于解决当时出现的“软件危机”。

1.1 关于软件

软件工程的主旨是以工程化的思想进行软件开发，从而生产高质量和高效率的软件。也即是说，软件工程研究的基础就是软件。

1.1.1 软件及其特性

软件是一系列程序、数据及其相关文档的集合，其中，程序是按照特定顺序组织的指令的集合；数据是程序操作的对象；文档是与程序的开发、维护和使用有关的图文资料。计算机软件的核心是程序。

软件具有下列几个特征。

（1）复杂性。软件是一个庞大的逻辑系统，主要依靠人脑的“智力”构造出来。多种人为因素使得软件难以实现统一化，增加了其复杂性。软件的复杂性使得软件产品难以理解、生产和维护，更难以对生产过程进行管理。

（2）一致性。软件必须和运行软件的硬件保持一致，这是由软件对硬件的依赖所决定的。如果硬件系统是“现存”的，则软件必须和现有硬件系统接口，也可用软件替代硬件接口的功能。

（3）磨损和老化。与一般的器械设备不同，软件不存在磨损和老化的问题，但会退化，需要进行多次维护，如图1-1中的理想曲线是软件实际故障模型粗略的简化。

（4）易变性。软件在生产过程中，甚至在投入运行之后，也还可以改变。软件必须适应这种变化，因为改变软件比更换硬件容易。软件的易变性使得软件易维护、易移植、易复用。但是，这种动态的变化不仅难以预测，难以控制，而且可能对软件的质量产生负面影响。

（5）移植性。软件的运行受计算机系统的影响，可能导致软件在不同的计算机系统平台上出现不兼容的问题，这就涉及软件的可移植性。好的软件在设计时就考虑到软件如何应用到不同的系统平台。

（6）高成本。软件的开发是一个复杂的过程，因此其成本非常昂贵。

1.1.2 软件的演化

软件的发展经历了一个演化的过程，自从20世纪40年代产生了世界第1台计算机后，伴随而生的就是程序。纵观前后的几十年间，软件的演化大致经历了以下4个阶段。

第1阶段（程序设计阶段）：从1946年到20世纪60年代初，计算机软件发展的初期，其主要特征是程序生产方式为个体手工方式。

第2阶段（程序系统阶段）：从20世纪60年代初到70年代初，软件工程学科诞生。程序的规模发展得已经很大了，需要多人分工协作。软件的开发方式由个体生产发展成为小组生产。但是由于小组生产的开发方式基本上沿用软件发展早期所形成的个体化的开发方式，软件的开发与维护费用以惊人的速度增加。因此许多软件产品根本不能维护，最终导致出现严重的软件危机。

第3阶段（软件工程阶段）：从20世纪70年代中期至80年代中期，软件工程师把工程化的思想加入到软件的开发过程中，用工程化的原则、方法和标准开发和维护软件。

第4阶段（面向对象阶段）：从20世纪80年代中期至今，面向对象的方法学受到人们的重视，从而促进了软件业的飞速发展，软件产业在世界经济中已经占有举足轻重的地位。

随着计算机的普及，程序的稳健性和易读性受到广泛的关注，于是，程序从按个人意图创造的“艺术品”转变成能被广大用户接受的工程化产品。由于外部环境和用户需求不断变化，以及软件开发技术不断发展，注定了软件系统只有不断地演化才能适应用户新的需求。

从整个系统的角度看，开发软件系统的目的是为了满足用户的需求，提高生产力。因此，软件的需求仍是软件发展的动力。早期的程序开发者只是为了满足自己的需要，这种自给自足的生产方式是低级阶段的表现。进入软件工程阶段以后，软件的开发具有社会属性，软件要在市场中流通以满足更多用户的需要。

软件演化过程的各个阶段有不同的特征，在这些阶段中，软件工作的范围从只考虑程序的编写扩展到涉及整个软件生存周期。

1.1.3 软件危机

在软件技术发展的第2阶段，随着计算机硬件技术的不断进步，人们要求软件能与之相适应。然而，软件技术的进步一直未能满足形势发展所提出的要求。致使问题积累起来，形成了日益尖锐的矛盾，这就导致了软件危机。

软件危机的主要表现是软件的规模越来越大，复杂度不断增加，软件需求量也日益增大，且价格昂贵，供需差日益增大。软件的开发过程是一种高密集度的脑力劳动，软件开发常常受挫，质量差，很难按照制订的进度表完成指定的任务。软件的研制过程很难管理，即软件的研制往往失去控制。软件开发的模式及技术已经不能适应软件发展的需要，因此导致大量低质量的软件涌向市场。部分软件花费了大量的人力财力，有的软件甚至在开发过程中就夭折了。例如，伦敦股票交易系统预算4.5亿英镑，后来追加到7.5亿。历时五年，但最终还是失败，导致伦敦股票市场声誉下跌。软件开发和维护过程中所遇到的这种严重问题称为“软件危机”，伦敦救护服务系统是另一个软件危机的例子。

【案例1.1】 伦敦救护服务系统

伦敦救护服务系统覆盖伦敦市区600平方千米的地域和大约680万的救护人口，成为世界上最大的救护服务中心。该服务中心拥有318辆事故与应急救护车和445病人运输救护车，一个摩托车接应团队和一架直升机。中心的工作人员达到2746人，他们分布在伦敦市区70个救护站，每个救护站又分成4个运营部门。

伦敦救护服务系统的目的是自动化转发呼叫请求和处理紧急救护需要，通过计算机系统处理人工系统的所有任务。呼叫999和请求救护服务将呼叫者和派遣者连接起来，派遣者记录呼叫细节和分派合适的车辆。分派者将选择救护车，并将救护信息转发给车载系统。

伦敦救护服务系统包括以下3个组成部分。

（1）计算机辅助派遣系统：包括软硬件基础设施、事故记录保存系统、无线电通信系统和无线电系统接口。

（2）计算机地图显示系统：包括复杂地域地形分析软件。

（3）自动化车辆定位系统：具有车辆自动定位能力，以便以最短的时间到达指定位置，并跟踪分析系统的性能。系统包括无线电系统和移动数据终端。

伦敦救护服务系统项目于1987年4月启动，前期投资250万英镑用于开发一个有限功能的派遣系统。1989年设计规格被重新修改，增加了移动数据终端和声讯转换系统。1990年10月，项目经过两次峰值负载性能测试失败而被迫终止。截至项目被取消，该项目已经花费了750万英镑，超过预算的300%。

1992年2月，伦敦救护服务系统新的需求重新完成，1991年8月项目重新启动。为了保证项目的顺利进行，合作方定期举行会议协调项目进度和解决存在的问题。但是到项目截止日期，1992年1月，项目还是被延期。派遣系统没有完全实现和测试，无线电接口系统未能交付，救护车数据终端设计和定位系统需求还需进一步完善，车载定位跟踪系统没有完成安装调试。

1992年10月26日，整个新系统全部运转。但是过载问题仍然没有很好地解决，存在呼叫丢失和响应不及时等问题。1992年10月27日，系统不得不改为半自动化方式。1992年11月，系统运行性能开始全面下降，并最终导致系统锁死。由于没有对系统存在的故障及时响应，导致发生病人死亡的事件。工作人员试图切换和重启系统，但均告失败。由于系统没有备份系统，所以操作人员被迫恢复到完全人工过程。

伦敦救护服务系统的失败是由于一系列软件工程中的错误，特别是项目管理中的缺陷造成的，导致1992年秋天出现了两次故障。该系统失败是由于系统的复杂和庞大，系统需求不准确和经常变更，以及管理不到位等导致的。

1.2 软件工程

关于软件工程的定义目前还没有统一的标准，B.W.Boehm为软件工程定义为：“运用现代科学技术知识设计并构造计算机程序，以及为开发、运行和维护这些程序所必需的相关文件资料”。Fritz Bauer为软件工程下的定义是：“软件工程是为了经济地获得能够在实际机器上有效运行的可靠软件而建立和使用的一系列完善的工程化原则”。美国《IEEE软件工程标准术语》对软件工程下的定义为：“软件工程是开发、运行、维护和修复软件的系统方法”。其中“软件”的定义为：“与计算机程序、方法和规则相关的文档资料，以及在计事机上运行时所必需的数据”。

尽管软件工程的具体定义不尽相同，并且又有一些学者提出更完善的定义，但其主要思想都是强调在软件开发的过程中需要应用工程化思想的重要性。

1.2.1 软件工程基本原理

本节介绍几个软件工程活动的通用思想和原理。

1.工程化的观点

软件工程化思想的核心是把软件看做是一个工程产品，这种产品需要通过需求分析、设计、实现、测试、管理和维护等几个阶段。用完善的工程化原理研究软件生产的规范方法，使得软件的开发不仅在指定的期限内完成，还可以节约成本，保证软件的质量。

软件工程化思想主要体现在软件项目管理方面，软件项目管理的作用一方面是提高质量，降低成本；另一方面则是为软件的工程化开发提供保障。与其他项目相比，软件项目还是一种比较新兴的领域。在软件行业的迅猛发展中，一些问题和危机逐渐暴露出来，如项目时间总是推迟、项目结果不能令客户满意、项目预算成倍超标，以及项目人员不断流动等，这都是软件开发商不断面临的一些问题。

软件工程学家分析认为，导致上述情况的主要原因是缺乏软件过程控制能力。开发过程随心所欲、时间计划和费用估算缺乏现实的基础；管理者主要在应付突发事件、对产品质量缺乏客观基础，以及软件开发的成败建立在个人能力基础上等。

如今，软件开发的工程化管理思想已经得到认可，软件的开发管理已经不再过分依赖软件个人能力。运用项目管理的经验和方法是软件项目成功的前提和保证，这已是今天的软件业内人士的共识。随着信息技术的飞速发展，软件产品的规模也越来越庞大，个人单打独斗的作坊式开发方式已经越来越不适应发展的需要。尤其是近几年，随着网络技术的快速发展，项目管理也随之快速发展，各软件企业都在积极将软件项目管理引入开发活动中，并对开发实行有效的管理，从而并取得了各自不同的成绩。

2.推迟实现的观点

推迟实现是软件方法学的一条基本指导思想，软件开发过程应该理性地“推迟实现”。即把逻辑设计与物理设计清楚地划分开，尽可能推迟软件的物理实现。这样就避免了在软件开发过程中遇到大中型的软件项目时，过早且仓促地考虑程序的具体实现，由于考虑不周而导致大量返工。

为了正确高效地进行软件开发，必须在开发的前期安排好问题定义、需求分析和设计等环节，进行周密、细致的软件实现的前期工作。并明确规定这些环节只考虑目标系统的逻辑模型，不涉及软件的物理实现。尽可能地把逻辑设计与物理设计分开，推迟软件的物理实现，是软件开发方法学中的一条基本指导思想。

3.逐步求精的观点

逐步求精也称为“逐步细化”，是基于承认人类思维能力的局限性（认为人类思维能力仅有7±2信息量子的局限性）。求解一个复杂问题采用有条理，并从抽象到具体的逐步分解和细化，逐步解决，这是人类把复杂问题趋于简单化控制和管理的有效策略。

逐步求精解决复杂问题的策略是软件工程方法学中的一项通用技术，并且与分解、抽象和信息隐蔽等概念紧密相关。

4.分解的观点

分解是把复杂问题趋于简单化处理的有效策略，论证分解即论证“分而治之”的有效性。若把一个复杂问题分解成若干容易解决的小问题，就能够减少解决问题所需要的总工作量。分解必须是科学且合理的，否则反而可能会增加解决问题的难度和工作量。

5.抽象的观点

抽象是把一些事物（状态或过程）中存在相似的方面（忽略它们的差异）概括成“共性”的。抽象的主要思想是抽取出事物的本质特性，而暂不考虑它们的细节，即抓“大”放“小”。这是一种分层次的渐进过程，软件工程方法学中广泛采用分层次的从抽象到具体的逐步求精技术。建立模型是软件工程最常用的方法和技术之一。模型是一个方法或过程的合理而规范的框架。研究和建立模型必须运用抽象概括和创造性思维，进行综观全局（即“由树见林”）的科学总结。抽象是人类在认识或求解复杂问题的过程中，科学而合理地进行复杂系统分解的基本策略之一。

软件开发过程的每一步都是对软件产品求解过程抽象层次的一次求精，在软件定义期间，软件系统被看做一个最抽象的完整部件；在需求分析期间，软件解法给出用某个方式的抽象描述；当软件解法由总体设计向详细设计过渡时，抽象程度随之继续减少；最后，当源程序编出来时，也就达到了抽象的底层（具体层），软件求解过程结束。

6.信息隐蔽的观点

科学而合理的分解，还表现在得到的是一个个最简单、最清晰的“独立”部分。即这些部分的交互接口简单而清晰，不仅便于维护，而且利于复用。信息隐蔽是指“局部化”的信息（关系密切的软件元素，如实现过程、数据等），对于不需要了解这些信息的其他“局部”来说是不可访问（隐蔽）的。

信息隐蔽意味着把一些关系密切的软件元素物理地放置得彼此靠近，使信息最大限度地局部化，软件模块中使用局部数据元素就是局部化的一个例子。

信息隐蔽的指导思想始终贯穿在软件工程的面向过程、面向功能和面向对象的软件开发方法的发展中。

7.质量保证的观点

质量保证是为了保证产品和服务能够充分满足消费者要求的质量，从而进行有计划、有组织的活动。所以质量保证是面向消费者的活动，是为了使产品实现用户要求的功能，站在用户立场上掌握产品质量。同样道理，这种观点也适用于软件的质量保证。

确保软件质量的目的是为了客观地核实软件项目的实施行动，以及开发中的产品都遵从于对应的需求、过程描述、标准及规程。质量保证的基本思路是提倡“预防”，而不是事后“补救”，强调“全过程控制”和“全员参与”。软件质量就是“软件与明确和隐含地定义的需求相一致的程度”，更具体地说，软件质量是软件与明确叙述的功能和性能需求、文档中明确描述的开发标准，以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度。

1.2.2 软件工程基本原则

自从1968年提出“软件工程”术语以来，研究软件工程的专家学者们陆续提出100多条关于软件工程的准则或信条。美国著名的软件工程专家B.W.Boehm综合这些专家的意见，并总结多家公司的开发软件的经验，于1983年提出软件工程的7条基本原则。Boehm认为，这7条原则是确保软件产品质量和开发效率的原则的最小集合，它们是相互独立的，是缺一不可的最小集合；同时，它们又是相当完备的。以下简要介绍软件工程的7条原则。

1.分阶段的软件生存周期

根据这条基本原则，可以把软件生命周期划分为若干个阶段，并相应地制订出切实可行的计划，然后严格按照计划对软件开发与维护进行管理。在软件开发与维护的漫长生命周期中，需要完成许多性质各异的工作。Boehm 认为，在整个软件生命周期中应指定并严格执行6类计划，即项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划和运行维护计划。

2.坚持进行阶段评审

统计结果显示，在软件生命周期各阶段中，编码阶段之前的错误约占63%，而编码错误仅占37%。并且错误发现得越晚，更正错误所付出的代价就越高，有时要增长2～3个数量级，甚至更高。因此软件的质量保证工作不能等到编码结束以后再进行，必须坚持严格的阶段评审，以便尽早地发现错误。

3.实行严格的产品控制

改动需求是让开发人员很头疼的一件事，由实践可知，需求的改动往往是不可避免的，这就要求开发人员采用科学的产品控制技术顺应这种需求。其中，主要是实行基准配置管理（又称为“变动控制”）。凡是修改软件的建议，尤其是涉及基本配置的修改建议都必须按规定进行严格的评审，评审通过后才能实施。“基准配置”指的是经过阶段评审后的软件配置成分，以及各阶段产生的文档或程序代码等。当需求变动时，其他各个阶段的文档或代码都要随之相应变动，以保证软件的一致性。

4.采用现代程序设计技术

采用先进的程序涉及技术既可以提高软件开发与维护的效率，又可以提高软件的质量，还可以减少维护的成本。

5.明确责任

软件是一种逻辑产品。软件开发小组的工作进展情况可见性差，难以评价和管理。为了更好地进行管理，应根据软件开发的总目标及完成期限，尽量明确规定开发小组的责任和产品标准，从而使所得到的标准能清楚地审查。

6.开发人员应少而精

开发人员的素质和数量是影响软件质量和开发效率的重要因素，应该少而精。事实上，高素质开发人员的工作效率比低素质开发人员的工作效率要高几倍到几十倍，开发工作中犯的错误也要少的多。当开发人员增加时，可能的通信信道随着人数的增加而增大，通信开销将急剧增大。

7.不断改进开发过程

在软件的工程化生产中，不仅要积极采纳新的软件开发技术，还要注意不断总结经验，收集进度和消耗等数据，进行出错类型和问题报告统计。这些数据不仅可以用于评估新的软件技术的效果，还可以用于指明必须着重注意的问题，以及应该优先进行研究的工具和技术。

1.2.3 软件危机的解决途径

在软件危机相当严重的背景下，软件工程产生了。在引入工程化的思想后，人们总结出导致软件危机的原因并相应提出了解决的对策。

如果在软件开发的初期阶段需求提得不够明确，或是未能得到确切的表达，软件开发工作开始后，工作人员又不和客户及时地交换意见，就有可能导致开发后期矛盾无法解决。如果前期的需求分析不到位，且认为软件的开发仅是编写程序，则很有可能导致后期开发的软件达不到客户的要求，还很有可能导致软件的二次开发。

完成需求分析后，要做好软件定义时期的工作，这样可以在一定程度上降低软件开发成本；同时又无形中提高了软件的质量。毕竟软件是一种商品，提高质量是软件开发过程中的重中之重。

开发过程要有统一、公认的方法论和规范指导，参加软件开发的人员必须按照规定的方法论进行开发。重视设计和实现过程的资料，不要忽视每个人与其他人的接口，以便进行软件维护。由于软件是逻辑部件，开发阶段的质量较难衡量，开发质量较难评价，开发过程管理和控制较难，所以需要开发人员必须要有统一的软件工程理论指导。

必须在测试阶段做好充分的检测工作，才能提交给客户高质量的软件。要借鉴软件开发的经验，并注意有关软件开发数据的积累，确保开发工作按时完成，在规定期限内完成软件开发。

1.3 软件工程基本活动

在软件工程概念被提出来之前，开发人员错误地认为软件就是开发活动，或者极端地认为就是编码，至于分析和设计等都是次要的。随着软件规模不断增大，软件开发暴露出很多问题。软件工程是人们为克服这些问题（软件危机）而提出的一种概念，并在实践中不断探索它的原理、技术和方法。软件工程的工程化思想让开发人员看到软件活动不仅是开发活动，还有重要的管理活动，进而发展了过程改进活动。

1.开发活动

开发活动是软件人员生产软件的活动，是软件工程的核心过程活动。软件工程提供一整套工程化的方法，用于指导软件人员的工作。开发活动有一系列的阶段，如需求、设计、编码、测试、提交和维护等。这些阶段需要采用一定的控制流程将各个阶段连接起来，并需要规范的操作方式，这就形成了软件生命周期模型。

软件开发活动是随着开发技术的演化而改进的，如从早期的瀑布模型和螺旋模型，到当今兴起的敏捷开发方法和流行的统一过程，展示出在不同的时代软件产业对于开发活动的不同认识，以及对于不同类型项目的理解方法。

2.维护活动

软件开发完成并交付用户使用后，进入软件的运行和维护阶段。软件维护是在软件交付运行后，为保证软件正常运行、适应新变化等需要而进行的一系列修改活动。软件维护主要工作是在软件运行和维护阶段，对软件产品进行必要的调整和修改。

软件维护是软件生存周期的最后一个阶段，也是持续时间最长、工作量最大的一项不可避免的过程。软件维护的基本目标和任务是改正错误，增加功能，提高质量，优化软件，延长软件寿命，以及提高软件产品价值。

3.管理活动

当今的软件开发活动是一个非常复杂的过程。项目涉及几十、几百，甚至几千个人员，项目周期少则几个月，多则几年，项目费用越来越高，因此这样的项目就需要很好的管理活动。著名的项目管理专家James P.Lewis指出，项目是一次性、多任务的工作，具有明确的开始和结束日期、特定的工作范围、预算和要达到的特定性能水平。项目涉及到预期的目标、费用、进度和工作范围4个要素。

软件项目管理活动是指如何管理好项目的范围、进度和成本等。为此需要制订一个好的项目计划，然后跟踪与控制好这个计划。实际上，要做到项目计划切合实际是一个非常高的要求，需要对项目进行详细的需求分析、制订合理的计划、安排好进度、资源调配、经费使用等，并不断地跟踪和调整。为了降低风险，要进行必要的风险分析并制订风险管理计划。

4.过程改进活动

要完成一个软件项目，项目经理需要完全了解项目的过程，确定项目需要经历的几个步骤，每个步骤要完成的任务，以及需要哪些资源和技术等。对于同一个项目，不同的开发团队可能采取不同的开发过程。结果导致开发的产品质量不同，质量的好坏取决于个人的素质和能力。

如果将项目的关注点放在项目的开发过程，无论哪个组织来做都采用统一的开发过程，同样可以通过不断提高过程的质量，从而提高产品的质量。这个过程体现了组织的整体能力，它不依赖于个人能力。

软件过程不仅是软件开发的活动序列，还是软件开发的最佳实践，包括流程、技术、产品、关系、角色和工具等。在软件过程管理中，首先要定义过程。然后合理地描述过程，进而建立企业过程库，并成为企业可以重复使用的资源。对于过程，要不断地进行改进。从而不断地改善和规范过程，帮助提高企业的生产力。

软件过程改进是极其复杂的，需要不断总结以往项目的过程经验，形成有形的过程描述（成为最佳实践），并不断地完善并在以后的项目中重复利用。过程管理的主要内容是过程定义和过程改进，过程定义是对最佳实践加以总结，以便形成一套稳定的、可重复的软件过程；过程改进是对过程使用中存在的偏差或不切实际的地方进行优化的活动。通过实施过程管理，软件开发组织可以逐步提高软件过程能力，从根本上提高软件生产能力。

1.4 软件工程两大范型

范型的意思是指模型或模式，在软件工程学科中，范型用于表示一套涵盖整个软件生产过程的技术的集合。目前，使用最广泛的软件工程方法学分别是结构化范型和面向对象范型。

1.4.1 结构化范型

结构化范型自1968年被提出，经过近20多年的发展，形成了一套完整的体系。构成结构化范型的技术包括结构化分析、结构化设计、结构化编程和结构化测试，这些技术在以数据为主的系统或小型系统中得到广泛应用。采用结构化技术完成软件开发的各项任务，并使用适当的软件工具或软件工程环境支持结构化技术的运用。这种范型把软件的生命周期依次划分为若干个阶段，然后顺序地完成每个阶段的任务。采用这种范型开发软件的时候，从对问题的抽象逻辑分析开始，一个阶段接一个阶段地进行开发，从而降低了整个软件开发工程的困难程度。引入结构化范型所带来的主要改进体现在软件工业上，在工业领域的运用是软件工程被大规模采纳的主要原因。

结构化范型已经获得成功的原因是结构化技术要么面向行为，要么面向数据，但不能既面向数据又面向行为。软件的基本组成部分包括产品的行为和这些行为操作的数据。有些结构化技术，如数据流分析是面向行为的。这些技术集中处理产品的行为，数据则是次要的；反之，有些技术，如JSP系统开发技术是面向数据的。这些技术以数据为中心，数据操作的行为则是次要的。

1.4.2 面向对象范型

随着软件产品规模不断增大，结构化范型有时不能应付。也就是说，结构化技术处理5000行或5万行代码是有效的。然而当今的软件产品通常包含5万行或500万行代码，甚至更多行代码的产品非常普遍。维护阶段是结构化范型不能满足人们期望的第2个方面，结构化范型得以发展的主要动力是软件维护的费用占到软件费用的2/3，然而结构化范型未能很好地解决这一问题。

面向对象范型把数据和行为看成同等重要，即将对象视做一个融合了数据及在数据上操作行为的统一软件组件。对象的概念符合业务或领域的客观实际，反映了实际存在的事物，也符合人们分析业务本质的习惯。

面向对象技术自20世纪90年代提出以来得到快速发展，并被应用到各种各样的软件开发中。该技术将数据和数据上的操作封装在一起，通过对外封闭实现信息隐藏的目的。使用对象的用户只需要知道其暴露的方法，通过这些方法完成各种各样的任务。完全不需要知道对象内部的细节，从而保证相对独立性。

面向对象的优势主要体现在维护阶段。相对于结构化技术，无论对象的内部细节如何变化，只要对象提供的方法即接口保持不变，则整个软件产品的其他部分就不会受到影响，所以不需要了解对象内部的变化。因此面向对象范型使维护更快、更容易，同时产生回归的机会也大大降低了。

面向对象范型使开发变得相对容易。大多数情况下，一个对象对应物理世界一个事物。软件产品中的对象和现实世界的同等对应物之间的密切对应关系，促进了更优化的软件开发。对象是独立的实体，因此面向对象促进了复用，降低了开发维护的时间和费用。

目前，传统范型仍然是人们在开发软件时使用得十分广泛的软件工程方法学。广大软件工程师对这种范性型比较熟悉，而且在开发某些类型的软件时使用这种范型也比较有效，因此在相当长一段时期内这种方法学还会有生命力；此外，如果没有完全理解传统范型，也就不能深入理解这种范型与面向对象范型的差别及面向对象范型为何优于传统范型。在使用结构化范型时，分析阶段和设计阶段过渡太快。而面向对象范型是一种迭代的从一个阶段向另一个阶段的过渡，比结构化范型平滑得多，从而降低了开发过程中的故障数目。

1.5 小结

软件工程是由于软件危机的出现而被提出。软件工程的主旨是以工程化的思想进行软件开发，从而生产高质量和高效率的软件。软件是计算机系统中与硬件相对应的另一部分，是包括一系列程序、数据及其相关文档的集合。

软件工程化思想的核心是把软件看做是一个工程产品，这种产品的生产过程需要通过需求分析、设计、实现、测试、管理和维护。

软件工程的基本原理包括工程化、推迟实现、逐步求精、分解、抽象、信息隐蔽和质量保证等原理。

目前使用最广泛的软件工程方法学分别是传统结构化范型和面向对象范型，软件工程活动包括开发活动、维护活动、管理活动和过程改进等。

习题

1.什么是软件工程化？软件和软件生产有哪些固有的特征？

2.说明伦敦救护车系统存在的问题。

3.软件工程设计软件生产的哪些方面？为什么说软件工程是一门综合学科？

4.软件工程的两大范型分别是什么？它们有什么不同？

5.软件工程的基本原理是什么？

6.软件工程有哪些基本思想？

7.请举例说明软件中存在的软件危机。

8.分解与抽象的关系是什么？

9.软件工程有哪些活动？它们之间的关系是什么？