第 4章 软件工程
4,1 软件工程概述
4,2 软件工程模式
4,3 软件生存周期
4,4 面向对象的设计
4,5 软件维护
4.1 软件工程概述
1,软件发展
软件发展的几个阶段
1．程序设计时代（ 1946年 ~1955年）
2,软件时代（ 1955年 ~1970年）
3．软件工程时代（ 1970年现在）
软件工程是在 20世纪 60年代末期提出的。这一概念的提出，目的是倡导以工程的原理、原则和方法进行软件开发，以期解决当时出现的“软件危机”。
2,软件危机计算机系统硬件 /软件成本变化趋势
在开发一个新型计算机系统或修改一个现有系统的过程中，最大部分的资金是用在软件系统开发方面。
100
80
60
40
20
0
195 5 197 0 198 5
硬件软件总费用的百分比产生软件危机原因
①开发人员和用户之间的矛盾。
②缺乏开发大型软件系统的经验
③ 缺乏有力的方法学和工具方面的支持解决软件危机的途径
探索用工程的方法进行软件生产的可能性，即用工程的概念、原理、技术和方法进行软件的开发、管理、维护和更新。
诞生了计算机科学技术的一个领域,软件工程,。
3.软件工程软件工程学科是一门指导计算机软件开发和维护的工程学科 。 软件工程是一类求解软件的工程 。 它应用计算机科学,
数学及管理科学等原理,借鉴传统工程的原则,方法,创建软件以达到提高质量,降低成本的目的 。 其中,计算机科学,
数学用于构造模型与算法,工程科学用于制定规范,评估成本及确定权衡,管理科学用于计划,资源,质量,成本等管理 。
1983年 IEEE给出软件工程定义为：,软件工程是开发,运行,维护和修复软件的系统方法,；
其中,软件,的定义为,计算机程序,方法,规则,
相关的文档资料以及在计算机上运行时所必需的数据 。
软件工程的目标软件工程的目标可概括为：在给定成本,进度的前提下,开发出具有可修改性,有效性,可靠性,可理解性,可维护性,可重用性,可适应性,可移植性,
可追踪性和可互操作性并满足用户需要的软件产品 。
4,２ 软件工程模式
传统软件工程模式,
建立在软件生存周期方法学和结构化程序设计方法学的基础上
现代软件工程模式,
强调人在系统开发中的作用
4,3 软件生存周期软件生存周期表明软件从功能确定、设计，到开发成功投入使用，并在使用中不断地修改、增补和完善，直至被新的需要所替代而停止该软件的使用的全过程。
4,3,1 软件生存周期各阶段任务
软件生存周期被划分为 5个阶段：
系统定义
系统设计
系统编程
系统测试
系统维护图 2,1 软件生命周期退 役维 护调 试实 现详细设计需 求 分 析概要设计可 行 性 研 究系统定义 （做什么）,
可行性研究、需求分析系统设计 （如何做）：
概要设计、详细设计系统编程 （如何实现）
系统测试 （做的怎样）
单元测试、组装测试、确认测试系统维护 （不断完善）
4,3,2 软件开发模型软件开发模型是从软件项目需求定义直至软件经使用后废弃为止，跨越整个生存期的系统开发、
运作和维护所实施的全部过程、活动和任务的结构框架。
最早出现的软件开发模型是 1970年 W,Royce提出的 瀑布模型,而后随着软件工程学科的发展和软件开发的实践，相继提出了 原型模型,螺旋模型,
喷泉模型、智能模型 等。
可行性研究测试详细设计概要设计编码运行与维护需求分析
退役
1,带反馈的瀑布模型
2,原型模型需求采集细化快速设计建造原型用户评价原型原型对原型加工产品样本停止开始
3,螺旋模型需求计划风险分析风险分析风险分析原型 1
原型 2
原型 3
可运行原型风险分析,
评价方案识别风险消除风险累计成本指定计划,
决定目标方案限制提交线评审生存期计划开发计划组装测试 客户评价软件需求需求确认设计确认验证软件产品设计实现验收测试编码组装测试单元测试实施工程,
开发、验 证形成产品
4.喷泉模型喷泉模型对软件复用和生存周期中多项开发活动的集成提供了支持，主要支持面向对象的开发方法。
系统某个部分常常重复工作多次，相关功能在每次迭代中随之加入演进的系统。在开发活动中,由于对象概念的引入，使 分析、设计和编码之间不存在明显的边界。
5.智能模型
智能模型也称为基于知识的软件开发模型，它综合了上述若干模型，并与专家系统结合在一起。该模型应用基于规则的系统，采用归纳和推理机制，
帮助软件人员完成开发工作，并使维护在系统规格说明一级进行。
该模型在开发的各个阶段都利用相应的专家系统来帮助软件人员完成开发工作，使维护在系统需求说明阶段开始。该模型还处于研究实验阶段，还未达到实用阶段。
4.4 面向对象的设计
4.4.1 面向对象分析面向对象分析，就是抽取和整理用户需求并建立问题的过程。此方法的核心是识别出问题域内的对象，并分析它们相互间的相互关系，
最终建立起问题域的正确模型,
三个子模型与五个层次
需求陈述三个子模型与五个层次
三个子模型,静态结构（对象模型），交互次序
（动态模型）和数据变换（功能模型） 。
5个层次,主题层 （ 也称范围层）、类 — & —对象层、结构层、属性层和服务层。
4.4.2 面向对象的设计方法
P.COAD 和 E.yourdon的面向对象设计模型 OOD，
OOD把通常软件设计的三大活动 ----总体结构设计、数据设计和过 程设计结合为一体 。
OOD模型由 四部分构成。
（ 1）,主体部件 （ PDC）,；
（ 2）,用户界面部件 （ HIC）,；
（ 3）,任务管理部件 （ TMC）,；
（ 4）,数据管理部件 （ DMC）,。
每个部件由五层组成：
主题,对象与类,结构,属性和外部服务 。
五层分别对应五个活动：
定义主题,标识对象,标识对象所属的类,标识对象的属性和表示对象的行为 。
主题层 用户 主体 任务 数据对象与类层 问结构层 交互 题 管理 管理属性层 域服务层 部件 部件 部件 部件图 4.4 OOD模型图
4,4,3 基于对象的设计方法
1,设计步骤
OOD 方法由下述步骤组成：
（ 1） 定义问题；
（ 2） 开发一个非形式的策略；
（ 3） 策略形式化：标识对象及其属性；寻找子类消息特征,确立其他细节；
（ 4） 为每个对象属性确定数据结构；
（ 5）为每个 对象 操作确定过程细节。
（ 6） 建立对象间的界面；实现每个操作 。
（ 7） 反复使用 （ 3） 至 （ 6） 步；
2.详细设计
OOD详细设计主要工作包括：
（ 1） 详细描述界面；
（ 2） 细化并说明数据结构；
（ 3） 采用逐步求精,结构程序设计等基本设计技术为每个程序单元设计方法 。
OOD特点之一是整个设计呈迭代形式。每当考虑某个操作实现的细节之一，一旦发现码量过大，
则应立即将该操作的功能描述作为一个新问题，
继续用 OOD方法求解。
4.4.4 面向对象的实现
程序设计风格 准则
1.提高可重用性
2.提高可扩充性
3.提高健壮性
面向对象测试四个层次,算法层,类层,主题层,系统层软件测试补充：
任何产品都可以使用以下两种方法进行测试：
黑盒测试 白盒测试
（ 1）如果已知产品的功能，则可以对它的每一个功能进行测试，看是否都达到了预期的要求；
（ 2） 如果已知产品的内部工作过程,则可以对它的每种内部操作进行测试,看是否符合设计要求 。
第一种方法是黑盒测试,第二种方法是白盒测试 。
黑盒测试黑盒测试时完全不考虑程序内部的结构和处理过程,只按照规格说明书的规定来检查程序是否符合它的功能要求 。
黑盒测试是在程序接口进行的测试,又称为功能测试 。
黑盒测试检查的主要方面有：
程序的功能是否正确或完善；
数据的输入能否正确接收，输出是否正确；
是否能保证外部信息（如数据文件）的完整性等。
用黑盒法设计测试用例时，必须用所有可能的输入数据来检查程序是否都能产生正确的输出黑盒测试黑盒测试不可能实现穷尽测试：
假设有一个很简单的小程序,输入量只有两个,A和 B，
输出量只有一个,C。 如果计算机的字长为 32位,A和 B的数据类型都只是整数类型 。 利用黑盒法进行测试时,将 A和 B
的可能取值进行排列组合,输入数据的可能性有,232× 232
＝ 264种 。 假设这个程序执行一次需要 1毫秒,要完成所有的测试,计算机需要连续工作 5亿年 。 显然,这是不能容忍的,
而且,设计测试用例时,不仅要有合法的输入,而且还应该有非法的输入,在这个例子中,输入还应该包括实数,字符串等,这样,输入数据的可能性就更多了 。 所以说,穷尽测试是不可能实现的 。
白盒测试白盒测试时将程序看作是一个透明的盒子,也就是说测试人员完全了解程序的内部结构和处理过程 。 所以测试时按照程序内部的逻辑测试程序,检验程序中的每条通路是否都能按预定的要求正确工作 。 白盒测试又称为结构测试 。
利用白盒测试设计测试用例时,应包括以下三类测试：
（ 1） 语句测试：要求程序中的每个语句至少测试一次；
（ 2） 分支测试：要求程序中的每个分支至少测试一次；
（ 3） 路径测试：要求程序中的每条路径至少测试一次 。
左图所示的一个小程序的控制流程,其中每个圆圈代表一段源程序 （ 或语句块 ）,图中的曲线代表执行次数不超过 20的循环,循环体中共有 5条通路 。
这样,可能执行的路径有
520条,近似为 1014条可能的路径 。 如果完成一个路径的测试需要 1毫秒,那么整个测试过程需要 3170年 。
显然,这也是不能接受的 。
白盒测试
白盒测试也不能实现穷尽测试：
4.5 软件维护
软件维护是软件生存周期的最后一个阶段，也是非常重要的一个阶段。平均而言，大型软件的维护成本是开发成本的 4倍左右。国外许多软件开发组织把 60%以上的人力用于维护已投入运行的软件。
投入运行的软件需要变更的原因很多，但主要原因有：软件的原有功能和性能可能不再适应用户的要求； 软件的工作环境改变了 ； 软件运行中发现错误，需要修改。
由于这些原因而引发的维护活动可以归纳为 4种类型，如图 4.5所示。
适应性 校正性维护维护 17%~20%
18% ~25%
预防 性 维 护
4%
完善性维护
50~60%
其他开发活动
30~40%
维护活动
60~70%
(a)四种维护占总维护的比例 (b)维护在软件生存期所占比例图 4.5 软件维护
4,1 软件工程概述
4,2 软件工程模式
4,3 软件生存周期
4,4 面向对象的设计
4,5 软件维护
4.1 软件工程概述
1,软件发展
软件发展的几个阶段
1．程序设计时代（ 1946年 ~1955年）
2,软件时代（ 1955年 ~1970年）
3．软件工程时代（ 1970年现在）
软件工程是在 20世纪 60年代末期提出的。这一概念的提出，目的是倡导以工程的原理、原则和方法进行软件开发，以期解决当时出现的“软件危机”。
2,软件危机计算机系统硬件 /软件成本变化趋势
在开发一个新型计算机系统或修改一个现有系统的过程中，最大部分的资金是用在软件系统开发方面。
100
80
60
40
20
0
195 5 197 0 198 5
硬件软件总费用的百分比产生软件危机原因
①开发人员和用户之间的矛盾。
②缺乏开发大型软件系统的经验
③ 缺乏有力的方法学和工具方面的支持解决软件危机的途径
探索用工程的方法进行软件生产的可能性，即用工程的概念、原理、技术和方法进行软件的开发、管理、维护和更新。
诞生了计算机科学技术的一个领域,软件工程,。
3.软件工程软件工程学科是一门指导计算机软件开发和维护的工程学科 。 软件工程是一类求解软件的工程 。 它应用计算机科学,
数学及管理科学等原理,借鉴传统工程的原则,方法,创建软件以达到提高质量,降低成本的目的 。 其中,计算机科学,
数学用于构造模型与算法,工程科学用于制定规范,评估成本及确定权衡,管理科学用于计划,资源,质量,成本等管理 。
1983年 IEEE给出软件工程定义为：,软件工程是开发,运行,维护和修复软件的系统方法,；
其中,软件,的定义为,计算机程序,方法,规则,
相关的文档资料以及在计算机上运行时所必需的数据 。
软件工程的目标软件工程的目标可概括为：在给定成本,进度的前提下,开发出具有可修改性,有效性,可靠性,可理解性,可维护性,可重用性,可适应性,可移植性,
可追踪性和可互操作性并满足用户需要的软件产品 。
4,２ 软件工程模式
传统软件工程模式,
建立在软件生存周期方法学和结构化程序设计方法学的基础上
现代软件工程模式,
强调人在系统开发中的作用
4,3 软件生存周期软件生存周期表明软件从功能确定、设计，到开发成功投入使用，并在使用中不断地修改、增补和完善，直至被新的需要所替代而停止该软件的使用的全过程。
4,3,1 软件生存周期各阶段任务
软件生存周期被划分为 5个阶段：
系统定义
系统设计
系统编程
系统测试
系统维护图 2,1 软件生命周期退 役维 护调 试实 现详细设计需 求 分 析概要设计可 行 性 研 究系统定义 （做什么）,
可行性研究、需求分析系统设计 （如何做）：
概要设计、详细设计系统编程 （如何实现）
系统测试 （做的怎样）
单元测试、组装测试、确认测试系统维护 （不断完善）
4,3,2 软件开发模型软件开发模型是从软件项目需求定义直至软件经使用后废弃为止，跨越整个生存期的系统开发、
运作和维护所实施的全部过程、活动和任务的结构框架。
最早出现的软件开发模型是 1970年 W,Royce提出的 瀑布模型,而后随着软件工程学科的发展和软件开发的实践，相继提出了 原型模型,螺旋模型,
喷泉模型、智能模型 等。
可行性研究测试详细设计概要设计编码运行与维护需求分析
退役
1,带反馈的瀑布模型
2,原型模型需求采集细化快速设计建造原型用户评价原型原型对原型加工产品样本停止开始
3,螺旋模型需求计划风险分析风险分析风险分析原型 1
原型 2
原型 3
可运行原型风险分析,
评价方案识别风险消除风险累计成本指定计划,
决定目标方案限制提交线评审生存期计划开发计划组装测试 客户评价软件需求需求确认设计确认验证软件产品设计实现验收测试编码组装测试单元测试实施工程,
开发、验 证形成产品
4.喷泉模型喷泉模型对软件复用和生存周期中多项开发活动的集成提供了支持，主要支持面向对象的开发方法。
系统某个部分常常重复工作多次，相关功能在每次迭代中随之加入演进的系统。在开发活动中,由于对象概念的引入，使 分析、设计和编码之间不存在明显的边界。
5.智能模型
智能模型也称为基于知识的软件开发模型，它综合了上述若干模型，并与专家系统结合在一起。该模型应用基于规则的系统，采用归纳和推理机制，
帮助软件人员完成开发工作，并使维护在系统规格说明一级进行。
该模型在开发的各个阶段都利用相应的专家系统来帮助软件人员完成开发工作，使维护在系统需求说明阶段开始。该模型还处于研究实验阶段，还未达到实用阶段。
4.4 面向对象的设计
4.4.1 面向对象分析面向对象分析，就是抽取和整理用户需求并建立问题的过程。此方法的核心是识别出问题域内的对象，并分析它们相互间的相互关系，
最终建立起问题域的正确模型,
三个子模型与五个层次
需求陈述三个子模型与五个层次
三个子模型,静态结构（对象模型），交互次序
（动态模型）和数据变换（功能模型） 。
5个层次,主题层 （ 也称范围层）、类 — & —对象层、结构层、属性层和服务层。
4.4.2 面向对象的设计方法
P.COAD 和 E.yourdon的面向对象设计模型 OOD，
OOD把通常软件设计的三大活动 ----总体结构设计、数据设计和过 程设计结合为一体 。
OOD模型由 四部分构成。
（ 1）,主体部件 （ PDC）,；
（ 2）,用户界面部件 （ HIC）,；
（ 3）,任务管理部件 （ TMC）,；
（ 4）,数据管理部件 （ DMC）,。
每个部件由五层组成：
主题,对象与类,结构,属性和外部服务 。
五层分别对应五个活动：
定义主题,标识对象,标识对象所属的类,标识对象的属性和表示对象的行为 。
主题层 用户 主体 任务 数据对象与类层 问结构层 交互 题 管理 管理属性层 域服务层 部件 部件 部件 部件图 4.4 OOD模型图
4,4,3 基于对象的设计方法
1,设计步骤
OOD 方法由下述步骤组成：
（ 1） 定义问题；
（ 2） 开发一个非形式的策略；
（ 3） 策略形式化：标识对象及其属性；寻找子类消息特征,确立其他细节；
（ 4） 为每个对象属性确定数据结构；
（ 5）为每个 对象 操作确定过程细节。
（ 6） 建立对象间的界面；实现每个操作 。
（ 7） 反复使用 （ 3） 至 （ 6） 步；
2.详细设计
OOD详细设计主要工作包括：
（ 1） 详细描述界面；
（ 2） 细化并说明数据结构；
（ 3） 采用逐步求精,结构程序设计等基本设计技术为每个程序单元设计方法 。
OOD特点之一是整个设计呈迭代形式。每当考虑某个操作实现的细节之一，一旦发现码量过大，
则应立即将该操作的功能描述作为一个新问题，
继续用 OOD方法求解。
4.4.4 面向对象的实现
程序设计风格 准则
1.提高可重用性
2.提高可扩充性
3.提高健壮性
面向对象测试四个层次,算法层,类层,主题层,系统层软件测试补充：
任何产品都可以使用以下两种方法进行测试：
黑盒测试 白盒测试
（ 1）如果已知产品的功能，则可以对它的每一个功能进行测试，看是否都达到了预期的要求；
（ 2） 如果已知产品的内部工作过程,则可以对它的每种内部操作进行测试,看是否符合设计要求 。
第一种方法是黑盒测试,第二种方法是白盒测试 。
黑盒测试黑盒测试时完全不考虑程序内部的结构和处理过程,只按照规格说明书的规定来检查程序是否符合它的功能要求 。
黑盒测试是在程序接口进行的测试,又称为功能测试 。
黑盒测试检查的主要方面有：
程序的功能是否正确或完善；
数据的输入能否正确接收，输出是否正确；
是否能保证外部信息（如数据文件）的完整性等。
用黑盒法设计测试用例时，必须用所有可能的输入数据来检查程序是否都能产生正确的输出黑盒测试黑盒测试不可能实现穷尽测试：
假设有一个很简单的小程序,输入量只有两个,A和 B，
输出量只有一个,C。 如果计算机的字长为 32位,A和 B的数据类型都只是整数类型 。 利用黑盒法进行测试时,将 A和 B
的可能取值进行排列组合,输入数据的可能性有,232× 232
＝ 264种 。 假设这个程序执行一次需要 1毫秒,要完成所有的测试,计算机需要连续工作 5亿年 。 显然,这是不能容忍的,
而且,设计测试用例时,不仅要有合法的输入,而且还应该有非法的输入,在这个例子中,输入还应该包括实数,字符串等,这样,输入数据的可能性就更多了 。 所以说,穷尽测试是不可能实现的 。
白盒测试白盒测试时将程序看作是一个透明的盒子,也就是说测试人员完全了解程序的内部结构和处理过程 。 所以测试时按照程序内部的逻辑测试程序,检验程序中的每条通路是否都能按预定的要求正确工作 。 白盒测试又称为结构测试 。
利用白盒测试设计测试用例时,应包括以下三类测试：
（ 1） 语句测试：要求程序中的每个语句至少测试一次；
（ 2） 分支测试：要求程序中的每个分支至少测试一次；
（ 3） 路径测试：要求程序中的每条路径至少测试一次 。
左图所示的一个小程序的控制流程,其中每个圆圈代表一段源程序 （ 或语句块 ）,图中的曲线代表执行次数不超过 20的循环,循环体中共有 5条通路 。
这样,可能执行的路径有
520条,近似为 1014条可能的路径 。 如果完成一个路径的测试需要 1毫秒,那么整个测试过程需要 3170年 。
显然,这也是不能接受的 。
白盒测试
白盒测试也不能实现穷尽测试：
4.5 软件维护
软件维护是软件生存周期的最后一个阶段，也是非常重要的一个阶段。平均而言，大型软件的维护成本是开发成本的 4倍左右。国外许多软件开发组织把 60%以上的人力用于维护已投入运行的软件。
投入运行的软件需要变更的原因很多，但主要原因有：软件的原有功能和性能可能不再适应用户的要求； 软件的工作环境改变了 ； 软件运行中发现错误，需要修改。
由于这些原因而引发的维护活动可以归纳为 4种类型，如图 4.5所示。
适应性 校正性维护维护 17%~20%
18% ~25%
预防 性 维 护
4%
完善性维护
50~60%
其他开发活动
30~40%
维护活动
60~70%
(a)四种维护占总维护的比例 (b)维护在软件生存期所占比例图 4.5 软件维护
