下一页
计算机软件基础
The software basic of computer
主讲,赵英良
第 16单元
传统程序设计方法
下一页上一页 停止放映 第 2 页
本讲内容
? 一,结构化开发方法
? 二、软件需求定义
? 三、系统设计（软件的设计）
? 四、程序编码
? 五,系统测试
? 六、软件维护
下一页上一页 停止放映 第 3 页
教学目标
? 了解传统程序设计方法,
– 基本概念
– 方法及特点
– 步骤及准则
下一页上一页 停止放映 第 4 页
本单元涉及内容
? 第 10章 传统的软件开发方法
– 10.1 结构化开发方法概述
– 10.2 系统分析与定义
– 10.3 系统设计
– 10.4 系统编程
– 10.5 系统测试
– 10.6 系统维护
? P273~P333
下一页上一页 停止放映 第 5 页
一,结构化开发方法
? 结构化开发方法是传统的软件系统开发方法 。
? 结构化开发方法的基本思想：
把一个复杂问题的求解过程分阶段进行, 每个阶
段处理的问题都控制在人们容易理解和处理的范
围内 。
? 基本要点是,
– 自顶向下
– 逐步求精
– 模块化设计
– 结构化编码
– 主程序员组织
– 结构化设计 SD
下一页上一页 停止放映 第 6 页
“自顶向下”
? 将复杂的大问题分解为小问题, 找出问题的关
键, 重点所在, 同时找出技术难点来 。 然后用
精确的思维定性, 定量地描述问题 。
? 问题的核心是, 分解, 。 如何划分？ 准则是什
么？
? 实现的手段是, 子程序,,, 函数,, 即模块
化 。 要 点：将大问题化为小问题，
找出关键、难点，定量描述
核心是：分解
手段是：模块化（函数、子程序）
下一页上一页 停止放映 第 7 页
“逐步求精”
? 将现实世界的问题经抽象转化为逻辑空间或求
解空间的问题 。 复杂问题经抽象化处理变为相
对较简单的问题 。 经几次抽象 （ 精化 ） 处理,
最后到求解域中只是非常简单的编程问题 。
? 求解 （ 抽象 ） 过程可以划分为若干个阶段, 在
不同阶段用不同工具来描述 。 实现细则在前期
阶段可以不去管它 。 在每个阶段有不同的规划
和标准, 产生出不同阶段的文档资料 。
将现实问题抽象为逻辑空间问题，
几经抽象化为简单的编程问题。
下一页上一页 停止放映 第 8 页
模块化处理
? 模块化就是 把程序划分为若干个模块, 而每个
模块完成一个子功能, 把这些模块汇总起来构
成一个有机整体, 即可完成指定的功能 。
? 模块化的目的 是为了降低软件复杂度, 使软件
设计, 调试和维护等操作变得简易 。
下一页上一页 停止放映 第 9 页
结构化编码
? SP编码的方法强调 清晰简洁, 它是一种构造
程序的技术, 有利于提高软件生产率及降低
软件维护代价 。
? 1966年 Bohm和 Jacopin就证明了只要用三中基
本结构, 就足以表示所有形式的程序控制结
构 。
? 1978年 Kernihan和 Plauger对一些编码风格进
行归纳, 提出了 16种具体方法 。
下一页上一页 停止放映 第 10页
结构化编码风格
?尽量使用标准库函数
?程序讲究清晰, 避免过于精
巧
?对重复使用的表达式尽量调
用公共函数代替
?使用括号, 以避免二义性
?用逻辑表达式代替分支嵌套
?使用缩排格式
?避免使用 IF THEN 和空 ELSE
?注意计算机运算特点, 如
10.0乘 0.1很少等于 1.0
? 使用有意义的变量名
? 对输入进行错误判别
? 注释勿用太滥
? 模块化功能专一,模块间
偶合清晰
? 递归定义的 DS尽量采用
递归过程访问
? 把大程序分成小块去编
写和测试
? 勿追求不必要的效率,尽
量采用基本控制结构
? 避免循环多个出口
下一页上一页 停止放映 第 11 页
主程序员组织
? 是一种人员的组织形式
? 主程序员 组织负责人,全权负责,包括解决技术难题,
有时一些关键性技术问题,主程序员应亲自动手遍程去
解决；他必须是技术高手, 是程序生产过程中的总体
设计师 。
? 程序员 按任务书要求编程；是程序生产线上的, 工
人, 。
? 测试工程师 具有较高遍程水准和经验, 负责系统测
试；是程序生产过程中的检验员 。
? 文档人员 自始至终参加程序生产活动, 负责编写一
切有关文档资料 。
下一页上一页 停止放映 第 12页
结构化方法的体系结构
? 结构化方法的体系结构是,
– 结构化分析
（ SA— Structured Analysis）
– 结构化设计
（ SD— Structured Design）
– 结构化程序设计
（ SP— Structured Programming）
下一页上一页 停止放映 第 13页
结构化分析 SA
? SA方法是 建立在自顶向下, 逐步求精思想基础
上的 分析方法,
? SA方法是分析方法, 基础 是自顶向下, 逐步求精
? 要点, 分解和抽象,
– 把复杂问题自顶向下逐层分解, 再从分解
出的对象中抽象出相对简单的子问题 。
– 经过一系列分解和抽象, 到最底层的问题
已经是很容易求解的了 。
下一页上一页 停止放映 第 14页
结构化设计 SD
? SD方法是由 IBM公司的 Constentine等人花了十
几年时间研究出来的一种程序设计方法, 发表
于 1974年 。
? 简述,SD是一种用于概要设计的方法, 与 SA方
法配合使用 。 （ SD是用于概要设计的方法 ）
? 目标,建立一个结构良好的软件系统 。
? SD方法的基础,是数据流程图, 因此也称为面
向数据流的设计方法 。
? 问题,SA方法用于软件开发的哪个阶段？
下一页上一页 停止放映 第 15页
结构化程序设计 SP
? SP的思想最早是由著名计算机科学家 E.W.Dijkstra提
出的 。
? 1966年 Bohm和 Jacopin证明了只用三种基本结构就能
实现任何 一个入口, 一个出口 的程序；
? 1977年 IBM公司的 Mills又进一步提出：, 程序应该只
有一个入口和一个出口 。
? 在长期程序设计的实践中, SP方法不断得以
完善, 使之成为开发传统应用领域应用系统
的主要方法之一 。
下一页上一页 停止放映 第 16页
关于 SP的定义
? 北大王选院士认为：
– 没有 GOTO语句
– 一个入口、一个出口
– 自顶向下，逐步求精的分解
– 主程序员组
? 谭浩强认为：
– 自顶向下
– 逐步求精
– 模块化设计
– 结构化编码
下一页上一页 停止放映 第 17页
关于 SP的定义（续）
? 另一种说法：
– 自顶向下, 逐步求精
– 程序结构按功能划分为模块
– 模块功能单一, 简单
– 模块由三种基本结构组成
– 程序由函数, 子程序来实现
下一页上一页 停止放映 第 18页
二、软件需求定义
?概 述, 软件需求分析就是 明确 软件系
统将来达到的目标。
?基本任务,准确地回答系统,做什么？”
?目 标,规定项目必须满足的 总目标 ；
确定项目的 可行性 ；拟定完成项目各个
目标的 策略,制定项目资源 成本和进度 。
下一页上一页 停止放映 第 19页
1、软件需求定义的任务
? 理解和表达用户要求，制定软件开发
计划，编写要求说明书。
下一页上一页 停止放映 第 20页
（ 1）软件需求定义的特点
? （ 1）它是软件生存周期中最容易出错的一个阶段，
? （ 2）也是软件工程中最困难的一个阶段。
? （ 3）它是其它阶段的基础，十分重要的阶段。
? 困难在于,
– 不能准确地理解和清楚地描述
– 软件系统非常复杂，以致用户和软件人员都不
能完整、精确地理解它或不能清楚地表达出来；
软件人员和用户缺乏共同语言 。
– 用户熟悉业务，但不了解计算机；而软件人员
则相反； 这种隔阂使双方不能进行交流。
下一页上一页 停止放映 第 21页
（ 2）确定对系统的综合要求
? 系统功能要求
找出系统必须完成的所有功能。
? 系统性能要求
例如，联机系统的响应时间，系统需要的存储容量
以及后援存储，重新启动和安全性等问题。
? 运行要求（环境要求）
对系统运行环境的要求。例如，什么样的硬件环境？
采用哪种 DBMS？ OS平台是什么？需要什么样的
外存储器和数据通信接口等。
? 将来可能提出的要求
为系统将来可能的扩充和修改预做准备。
下一页上一页 停止放映 第 22页
（ 3）软件需求定义的工作流程
系统定义
用户要求 软件功能 范围 功能说
明书
软件计划 软件定义
软件功能 费用、资源进度
下一页上一页 停止放映 第 23页
2、需求分析过程
? 基本过程示意图
? 沿数据流回溯
? 用户复查
? 细化数据流图
? 修改开发计划
? 书写文档资料
? 审查和复审
下一页上一页 停止放映 第 24页
需求分析的基本过程
用户 分析员 程序员
软件开发计划 软件需求说明书
分析追踪
数据流图 用户复查
细化数据
流图
无补充
修改
需要分解
不要分解
有补充修改
交换意见
作出贡献
下一页上一页 停止放映 第 25页
沿数据流回溯
? 通常从数据流图的输出端着手分析，要搞清楚：
– 数据元素从哪儿来？
– 每个输出数据元素又是从哪儿来的？
有时对用户具体的数据元素还搞不清楚，则需要和用
户探讨、商量解决。
? 通常把分析过程中得到的有关部门数据元素信息记录
到数据字典 DD中。把对算法的简明描述记录在 IPO
（输入 |处理 |输出图）图中。
? 通过分析而补充的数据流、数据存储和处理，应该添
加到 DFD的适当位置上。
? 数据字典（ DD）、输入处理输出图（ IPO）
? 数据流图（ DFD）
下一页上一页 停止放映 第 26页
用户复查
? 经分析将在数据流图回溯过程中找出的数据
元素，并由此定义的 DD和算法是否正确？
这只能由最有发言权的用户来复查。
? 在复查过程中反映出新的问题，应及时修改、
补充 DFD,DD和 IPO图，并将对系统的新认
识及时记录下来。实际上，追踪 DFD和复查
系统的逻辑模型这两个步骤是交替进行的循
环过程。
下一页上一页 停止放映 第 27页
细化数据流图
? 在反复循环的分析过程中，不断细化
DFD（即把数据流图扩展到更低的层
次）。通过功能分解可以完成 DFD的
细化，即将一些处理比较复杂的功能
再划分为若干个子功能。
下一页上一页 停止放映 第 28页
修改开发计划
? 在分析过程中可能会不断地修改原拟
定的开发计划，这是正常的。
下一页上一页 停止放映 第 29页
书写文档资料
? 本阶段应完成 4份文档资料：
– 系统规格说明 描述目标系统的概貌、功能
要求、性能、运行及将来可能提出的要求。
– 用户系统描述 从用户角度描述系统，类似
一份用户手册初稿。
– 数 据 要 求 包括 DD、数据结构的层次框
图等。
– 修改的开发计划 包括成本估计、进度计划
表、资源使用计划等。
下一页上一页 停止放映 第 30页
说明
? 需求说明书主要内容,
– 概 述 开发系统的意义、目的、背景及技术术语；
– 现行系统的概况 业务流程、范围、存在的问题等；
– 需求说明
? 功能描述：
? 信息描述, DFD,DD,DS,IPO、接口等
? 性能描述
– 运行环境
– 系统限制
? 用户系统描述
– 系统功能和性能的描述
– 使用系统的主要步骤和方法
– 系统用户的责任等
下一页上一页 停止放映 第 31页
审查和复审
? 分析阶段最后一步是 按结束标准 对该阶
段的工作成果进行正式的技术 审查和管
理审查 。
下一页上一页 停止放映 第 32页
3、需求分析的原则
1,能够表达和理解问题的信息域 信息域反映的是用户
业务系统中数据的流向和对数据进行加工的处理过程,
因此信息域是解决, 做什么？, 的关键因素 。
2,要建立描述系统信息, 功能和行为的模型 建立模型
的过程是, 由粗到精, 的分析综合的过程 。
3,能够对所建模型按一定形式进行分解 分解是为了降
低问题的复杂性, 增加问题的可解性和可描述性 。
4,分清系统的逻辑视图和物理视图
– 软件需求的逻辑视图描述的是系统要达到的功能和要处理的
信息之间的关系, 这与实现细节无关；
– 而物理视图描述的是处理功能和信息结构的实际表现形式,
这与实现细节是有关的
– 需求分析只研究软件系统, 做什么？,, 而不考虑, 怎样
做？, 。
下一页上一页 停止放映 第 33页
4、需求分析的图形工具
? 图形工具在描述复杂关系时比文字叙述要优越。
在系统需求分析过程中为了准确描述需求，常采
用一些简单的描述工具，例如：
数据流图（ DFD,Data Flow Diagram）、
数据字典（ DD,Data Dictionary）、
结构化分析语言（ Language of Structured Analysis）、
判定表 (Decision Table)
判定树等 (Decision Tree)
下一页上一页 停止放映 第 34页
（ 1）数据流图 DFD
? 数据流图（ DFD—— Data Flow Diagram ）以图
形的方式表达数据处理系统中信息的变换和传递
过程。它有四种基本符号：
S
P
X
数据源及数据终点
加工 对数据进行的加工或变换，指向加工的数据流
是输入数据；离开的是输出数据。
数据流 具有名字且有流向的数据
文件 存放数据的场所
下一页上一页 停止放映 第 35页
数据流图举例 ——宾馆管理系统
客人
预订
登录 房管
客人信息库 可售房库 售出房库
客帐库
公安
预付
款 财务
IDD
下一页上一页 停止放映 第 36页
数据流图的结构
? 一个实际问题的数据加工流程是非常复
杂的。如果绘制在一个平面图上就显的
太乱了。
? 因此，通常采用 分层次结构 。把一个复
杂的问题，分解为一些相互独立的子问
题，再绘出分层 DFD。
? 数据流图的组成成分：
数据流、加工、文件、源终点
下一页上一页 停止放映 第 37页
结构图分层举例
宾馆
管理
DFD/L0顶层图
第 2层图
DFD/L1
A
D
C
E
第 3层图
DFD/L2.2DFD/L2.1A1 A2
A3
E1 E2
B
下一页上一页 停止放映 第 38页
（ 2）数据字典 DD（ Data Dictionary）
? DD对数据流程图中出现的所有元素给出逻辑定义 ;即给出
DFD中的数据流、加工和文件、及及数据项等的详细解释。
? 数据字典的条目解释通常采用规范的 定义形式,
客帐 =帐号 +房租 +IDD费 +餐饮费 +洗衣费 +娱乐费 +日期 +经
办人
? 内容
数 据 流, 编号、名称、简述、别名、构成、来源、去向、流量
数据项目, 编号、名称、简述、别名、类型、长度、位数
数据文件, 编号、名称、简述、别名、构成、关键字、存取要求
处理（加工）,编号、名称、简述、别名、处理条件、
I/O内容、处理逻辑
下一页上一页 停止放映 第 39页
（ 3）结构化语言
? 例如，选择结构的描述语句 (IF THEN ELSE)、
循环结构的描述语句等。
? 例如：
DO CASE
CASE 时间 <=12
R_rent=0;
CASE 时间 >12 AND 时间 <=18
R_rent=rent*0.5;
CASE 时间 >18
R-rent=rent;
注意：这不是程序！！
下一页上一页 停止放映 第 40页
（ 4）判定表
? 采用判定表能把加工逻辑表示的更加清楚。
? 判定表中,纵向各列给出的是不同的 条件,
? 横向各行则表示在各条件下相应的 处理 。
条件 结 帐 时 间 12点前 12~18点 18点后
处理 不收费
收半费
收全费
?
?
?
下一页上一页 停止放映 第 41页
（ 5）判定树
? 用树的形式表示条件分枝
? 判定树比判定表更家直观，它用来描述具有多个条件
的数据加工更容易被用户接受。树状的分支表示多种
不同的条件。例如，
结帐时间 =？
12点前 12~18点间 18点后
不收费 收半费 收全费
下一页
下一页上一页 停止放映 第 42页
5、用于需求分析的软件工具
? 为保证软件需求的正确性和需求的一致性，需
要采用适当的软件工具支持需求分析工作。软
件工具应满足下列要求：
– 必须有形式化的语法（可让计算机自动处理）
– 能够导出详细的文档
– 必须提供分析（测试）规格说明书的不一致
性和冗余性的手段，并能产生指明对完整性
分析结果的报告。
– 能够改进通信状况
下一页上一页 停止放映 第 43页
已有的需求分析的软件工具
? RSL（ Request Statement Language）需求陈述语言 ；
其语句是计算机可以处理的，并将处理结果集中存放在
ASSM（抽象系统语义模型）的 DB中。 1977年。
? PSL/PSA (Problem Statement Language /Problem
Statement Analysis System)问题陈述语言 /问题陈述
分析程序系统 。它是 CADSAT（计算机辅助设计和规格说
明分析工具）的一部分。 PSL是用来描述系统的形式语
言,PSA是处理 PSL描述的分析程序。 1997年。
? PSL/PSA有 4种主要功能：
– 描述任何应用领域的信息系统
– 创建一个 DB保存对该信息系统的描述符
– 对描述符可执行增、删、改等操作
– 产生格式化文档及规格说明书的各种分析报告
? PSL/PSA的主要优点是改进了文档质量、使之具有完整
性、一致性和无二义性，从而减少管理维护费用。
下一页上一页 停止放映 第 44页
超高级语言和第 4代语言
? 超高级语言的语句功能很强，用少数语句就可以实现一个系统。但这种
语言需要的系统资源开销也大。
? APL 是一种处理矩阵运算的、功能强大的超高级语言。 它非常简洁，
用它书写程序所化时间很少。用它来开发一个原型系统所需要的时间通
常只相当于实现最终系统所用时间的一小部分。但这类语言不适合用来
写大型系统（语法结构不易读）。
? Shell 是 UNIX系统的命令解释语言,在 Shell中可以使用 UNIXOS的所
有命令。如果开发的系统中使用的基本数据是正文行和文件，适合用
Shell描述算法。用 Shell语言开发适于用该种语言书写的程序时，所需
的成本比用普通 PL开发时低得多。
? PROLOG 是 开发原型系统使用最普遍的语言,具有极强的知识表达、推
理和查询功能，在表达知识和快速建立软件原型方面具有明显优势 。它
只有事实、规则和询问三种语句，语法比其它 PL简单，又具有交互性，
使用十分方便。但它表达算法类知识的能力较弱，不善于解决计算问题；
效率较低。
? 第 4代语言具有非过程性、交互性、可视性、智能化缺省设置、易使用、
高生产率、易调试、易维护,OO及基于 DBMS等，是快速构造软件原
型的高效软件工具。
下一页上一页 停止放映 第 45页
6、结构分析方法 (SA方法 )
? 结构化分析方法的背景 (形成 )
– 早期 无系统分析方法 (凭经验 )
– 60年代 美国的科学家提出一种理论,
SP SD SA
– 目前 研究的新热点是,
OOP OOD OOA
即面向对象的程序设计技术 (OO-Object
Oriented )
下一页上一页 停止放映 第 46页
SA的一般步骤
1,建立当前系统的物理模型 即理解并描述当前系统是怎样
进行工作的 。 通过调研, 了解把当前系统的业务工作流
程 （ 看到的, 听到的, 收集到的信息 ） 用流程图的形式
描述出来 。
2,建立当前系统的逻辑模型 逻辑模型是指系统的功能模型,
反映了数据处理系统的本质 。 对物理模型进行分析, 区
别本质因素和非本质因素, 去掉非本质因素, 就成为逻
辑模型 （ 本质因素是固有的, 不依赖于环境变化而变化
的因素 ） 。
3,建立目标系统的逻辑模型 这是 SA方法实质性的一步,
是 SA的最终目标 。 目标系统是指将来由计算机处理的
软件系统, 它是在分析当前系统逻辑模型与目标系统逻
辑模型的差别基础上建立起来的 。
下一页上一页 停止放映 第 47页
SA的基本特点：分析与抽象
? 采用用户容易理解的图形工具
? 从全局认识系统,采用自顶向下,逐级分析的方式
销售 MIS
销售 MIS
经营 库存 财务
1）
2）
3） 销售 MIS
经营 库存 财务
市
场
分
析
统
计
分
析
客
户
档
案
盘
点
结
存
订
货
管
理
工
资
核
算
采
购
计
划
工
资
核
算
成
本
核
算
面向用户,强调逻辑而非实现 (在该阶段,不考虑系统的实现问题 )
以获取分离数据和加工为动机 (这点很重要 )。
下一页上一页 停止放映 第 48页
三、系统设计（软件的设计）
? 系统设计概述
– 目标和任务
– 设计方法和步骤
– 文档
– 设计复审
下一页上一页 停止放映 第 49页
软件设计流程图
概要设计 复审要求说明书
软件
结构 可接收 详细设计
模块
描述
设计
说明书
复审
修改 修改
下一页上一页 停止放映 第 50页
1、软件设计概述
? （ 1）目标和任务
– 任务 依据分析结果, 明确系统, 如何
做？,, 建立实现方案 。
– 目标 提高软件系统的：
?可维护性, 可扩充, 可修改
?可理解性, 对软件人员要易读易理解；
对用户要易使用, 易维护
?可靠性, 包括正确性和健壮性
下一页上一页 停止放映 第 51页
（ 2）设计方法和步骤
? 概要设计
定义系统的逻辑结构, 包括：系统的模
块划分, 建立模块的层次结构, 逻辑关
系, 设计全局 DS及 DB；
? 详细设计
根据每个模块的功能描述, 设计模块内
部的实现算法, 模块所需要的局部数据
结构 。
下一页上一页 停止放映 第 52页
设计方法和步骤 ——设计方法：
? 概要设计方法
早期,模块化方法, 功能分解法；
典型,面向数据流, 面向数据结构 （ SP） 的
设计方法
近期,面向对象 （ OO） 的设计方法
SD(面向数据流的方法 )；
Jackson(JSD),Warnier(LCP)(面向数据结构的方法 )
? 详细设计方法
主要是结构化程序设计方法
? 详细设计的表示工具
图形工具, 程序流程图, 程序分析图 （ PAD） 和 NS图
语言工具, 伪码和程序设计语言 （ PDL）
下一页上一页 停止放映 第 53页
（ 3）软件设计原则
? 软件设计的重要性表现在软件的质量 。 如何设计才能
保证质量？ 一般原则：
1) 要有分层的组织结构, 便于对软件各个构件进行控制；
2) 应形成具有独立功能特征的模块 （ 模块化 ）
3) 应有性质不同, 可区分的数据和过程描述 （ 表达式 ）
4) 应使模块间和与外部环境间接口的复杂性尽量地减小
5) 应利用软件需求分析中得到的信息和可重复的方法 。
? 要想得到一个满意的设计结果, 不光要有基本设计原
则的指导, 还要有系统化的设计方法和科学严格的评
审机制相结合才能达到预想的目的 。
下一页上一页 停止放映 第 54页
（ 4）、软件设计准则
? 如何度量软件设计的标准, 计算机业界
对该问题还处于初期认识阶段 。
? 不分模块的程序是无法理解, 管理和维
护的程序 。 凡是使用计算机编程的人均
自觉不自觉地将程序划分为模块 。 但有
这样一个实际问题, 一个系统到底划分
为多少个模块好呢？
? 如何度量模块化的程度呢？
下一页上一页 停止放映 第 55页
经典设计准则
– 软件结构准则
– 模块化准则
– 模块独立性准则
– 模块的耦合性
– 模块的内聚性
下一页上一页 停止放映 第 56页
软件结构准则
? （ 1） 结构形态准则 好的软件结构应具有 倒置水缸形 ；
? 顶部宽度最小, 中间宽度最大, 底部宽度小于中间宽度 。
? 在顶部有较高的扇出数 （ 一个模块直接下属的子模块
数 ）,
? 在底部有较高的扇入数 （ 模块的直接上属模块的个数 ） 。
? （ 2） 判断的影响范围应该是控制范围的一个子集
影响范围 指在一个模块中有一个判别条件, 所有受该判
别条件影响的模块的集合称为影响范围；
控制范围 指一个模块本身及所有下属模块构成的集合 。
不满足该准则时的处理方法,就将判别条件移到上属模
块中去, 使其影响范围在控制范围内, 或者将受影响的
模块移入控制范围内 。
下一页上一页 停止放映 第 57页
结构形态准则示意图
深
度
宽度
扇出
扇入
下一页上一页 停止放映 第 58页
控制、影响范围示意图
? B模块的控制范围是 B、
D,E,F,G,H；
? 假设 E中有一个判别条件,
受其影响的模块有 F,G,H，
则 E的影响范围是 F,G,H。
M
E
A B C
D
F G H
下一页上一页 停止放映 第 59页
模块化准则
? 设 C(X） 是关于问题 X的复杂性, E(X） 是完成问题 X的工
作量, 有两个问题 P1和 P2：
若 C(P1） > C(P2),(即 P1比 P2复杂 )
E(P1) > E(P2),(即 P1比 P2用的工作量多 )
而 C(P1+P2) > C(P1) + C(P2),
(即组合问题比单个问题复杂 )
则 E(P1+P2) > E(P1) + E(P2)
(组合问题的工作量大于单个问题的工作量之和 )
? 这说明, 软件分解为若个模块后,则总的工作量减少,
但并不是说, 模块分解的越多, 工作量就一定越少 。 因
为分解到一定程度后, 模块之间的接口工作量就上升,
从而使总的代价上升 。
下一页上一页 停止放映 第 60页
模块化准则示意图
代价
模块数
模块代价
接口代价
总代价
M
下一页上一页 停止放映 第 61页
模块化准则讨论
? 软件系统模块化数目存在一个最佳值 M。
? 根据心理学研究表明, 一个模块的语句
数量以 30~50句为宜 （ 在一张打印纸上可
完整地输出 ） 。
? 模块太大, 难于阅读和理解；编程和测
试的效率也不高 。
? 模块太小, 又会使系统过于零碎, 接口
的工作量增加 。
下一页上一页 停止放映 第 62页
模块独立性准则
? 模块独立性,是指开发具有功能专一、模块之间
无过多相互作用的模块。
? 具有独立性的模块，开发容易、能减少错误的传
播，使模块重组、分解方便，容易调试和维护。
? 度量模块的独立性标准：
– 内聚性 模块内部各部分之间联系紧密程度的
度量；
– 藕合性 模块之间联系紧密程度的度量。
– 显然,独立性强的模块，耦合性越小越好，内
聚性越大越好。
下一页上一页 停止放映 第 63页
模块的藕合性及其分类
? 无直接藕合 模块之间无调用关系
? 数据藕合 通过参数调用在模块之间传递简单数据 。
传递参数可以是,加工的数据或控制用数据
（ 这是推荐和常用的藕合方法 ）
? 标记藕合 通过参数传递一种数据结构值 。
? 控制藕合 通过参数传递逻辑变量，起控制作用
? 外部藕合 指模块受软件的外部环境的约束 。
? 内容藕合 指一个模块使用另一个模块状内的数据或
控制信息；或直接转移到另一个模块的内
部 。
? 公用藕合 几个模块公用一个全程数据区；这种问题就
比较复杂 。 如果是动态并发程序, 情况就更复杂了 。 不光是
模块间数据引用的冲突问题, 还有时间差数据变更问题 。
低藕合，
经常被
采用
中等藕合
高藕合
下一页上一页 停止放映 第 64页
关于耦合的讨论
? 设计时应：
– 尽量使用数据耦合,
– 少用控制耦合,
– 限制公用耦合的范围,
– 完全不用内容耦合 。
下一页上一页 停止放映 第 65页
内聚性问题
? 一个程序主要由两部分组成：数据和对数据的
加工处理 。
? 内聚性,是指一个模块内部各种数据和各种处
理之间联系的紧密程度 。
? 它 是 模块执行任务的整体统一性的度量, 是模
块相对功能强弱的度量 。
? 在 理想的系统 中, 每个模块执行一个明确, 单
一的任务 。 但现实情况是一个模块往往执行若
干个结合在一起的任务, 这些任务组合方式不
同就构成不同的内聚性 。
下一页上一页 停止放映 第 66页
内聚性分类：
? 共存内聚 几个无关的任务组合在一起
? 逻辑内聚 将几个逻辑上相关的任务组合在一起
? 时态 （ 时间 ） 内聚 将在某一时刻同时要执行的
任务组合在一起
? 过程内聚 指几个相关联的任务组合在一起
? 通讯内聚 指在同一 DS上进行操作的几个任务
组合在一起
? 顺序内聚 指模块的几个任务总是前者的输出即为
后者的输入, 表现出按一定顺序执行 。
? 功能内聚 指模块只包含完成单一功能的任务 。
弱
强
下一页上一页 停止放映 第 67页
内聚性问题的讨论
? 从使用角度分析, 能否用一个短句完
整地描述该模块做什么；若这个短句
是复合句, 或有若干个动词, 则该模
块是非功能性模块 。
? 在设计时, 尽量采用功能性模块 。
下一页上一页 停止放映 第 68页
（ 5）文档资料
? 设计阶段要交付的文档是设计说明书 。 它可对编程和测
试提供指南服务, 还可在系统交付使用后, 为维护人员
提供帮助 。 内容包括：
– 概述 描述设计工作总的范围；系统目标, 功能, 接
口等；
– 系统结构 包括：系统的模块划分, 每个模块的功
能简介, 各个模块之间的逻辑关系；
– DS及 DB设计 用图表把设计结果描述出来；
– 接口设计 包括：人机界面设计, 软, 硬件之间的
接口设计, 本系统与外界以及与支持软件之间的接口
关系；
– 模块设计 根据模块的功能, 用相应的工具描述每
个模块的流程, 以及每个模块用到的数据结构 。
下一页上一页 停止放映 第 69页
2、概要设计
? 概要设计,是为软件系统定义一个逻辑上一致
的结构：进行模块划分，建立模块层次结构、
调用关系，设计全局数据结构及数据库，设计
系统接口及人机界面等。
? 概要设计的方法有许多种,
– 在早期有 模块化方法,功能分解方法，这都
是人们一般常用的方法；
– 在 60年代后期提出了 面向数据流的设计方法,
面向数据结构的设计方法；
– 近年来又提出 面向对象的设计方法 等。
下一页上一页 停止放映 第 70页
概要设计主要步骤
1）精细化数据流程图，确定数据流程
图的类型；
2）指出各种信息流的流界；
3）将数据流程图映射为软件结构；
4）精细化软件结构；
5）开发接口描述和全程数据描述。
下一页上一页 停止放映 第 71页
数据流程图分类
? 变换流, 事务流
? 变换流
加工
中心输入加工
输出
加工
输入 输出
内部
结果
内部
数据
输入流 输出流变换流
加工结果
下一页上一页 停止放映 第 72页
事物流
事物
中心
T
数据流
事物中心
t1
t2
t3
t4
事物路径
事物流
一个数据流经过某个加工后，有若干个平行的数据流
流出，将这种变换称为事物流。
?当事物流中的
事物流到事物
中心后，事物
中心分析每个
事物，确定其
类型；并根据
事物类型选择
一个事物路径
继续进行处理。
下一页上一页 停止放映 第 73页
设计过程
流 类型？
区分事物中心和
数据接受路径
区分输入和
输出分支
”事物,”变换“
映射成事物结构 映射成变换结构
用启发式设计规则精化软件结构
导出接口描述和
全程数据结构
详细设计
下一页上一页 停止放映 第 74页
变换分析技术
? 变换分析技术是从典型的变换型数据流程
图 （ DFD） 中推导出相应的结构图 。
? 变换分析是一组设计步骤, 可把 DFD映射
为一种标准结构 。 有了标准结构, 再根据
软件结构度量, 模块化度量, 模块独立性
度量来精细改善结构图, 从而得到良好的
软件结构 。
? （ 变换流的变换分析 ）
下一页上一页 停止放映 第 75页
变换分析的步骤
? 确定 DFD及其类型
? 确定输入流, 中心加工, 输出流的流界；
? 第一级分解；设计上层模块；
? 第二级分解, 设计中, 下层模块；
? 进一步精细化 。
下一页上一页 停止放映 第 76页
举例 ——设计汽车仪表盘
? 设计一个, 智能, 产品 —— 汽车数字仪表盘,
实现的功能为：
– 通过模 -数转换实现传感器和微处理器的接
口；
– 在发光二级管面板上显示数据；
– 指示 mph（ 每小时英里数 ）, 行驶里程, 每
加仑汽油行驶的英里数 （ mpg） 等；
– 指示加速 |减速
– 超速警告；车速超过 55英里 /小时, 则发出
超速警告铃声 。
下一页上一页 停止放映 第 77页
汽车数字仪表系统的 DFD
旋转
信号 读旋
转信号
信号 /秒
SPS
读旋和
求均值
燃料流
信号 读和
校对
燃料流 计算
gph
转换为
转 /分
rpm
SPS rpm mph计算
mph和
超速值
mph
显示
产生
mph
显示
gph mpg mpg
显示
计算
燃料
消耗
产生
mpg
显示
mph
SPS rpm 超速值
发出
铃声
铃声
产生
里程
里程
计算
里程
英里
确定加
减速
产生加
减速显
示箭头
指示
水平线
下箭头
上箭头
输入流
变换流
输出流?SPS
下一页上一页 停止放映 第 78页
设计步骤（一）
? 第 1步,确定 DFD及其类型 。
认真分析 DFD,可知有 2个输入流 （ 旋转信号, 燃料流
传感器信号 ）, 5个输出流 （ 加, 减速显示, 里程显
示, 发出铃声, mph显示, mpg显示 ）, 输出流显然是
把输入流经计算而产生的 。 由此可见, 这是一个典型
的变换流类型 。
– rpm 每分钟转数
– gph 每小时加仑数
– mph 每小时英里数
– mpg 每加仑英里数
下一页上一页 停止放映 第 79页
设计步骤（二）
? 确定流界 （ 输入流, 变换流和输出流 ）
– 输入流 读旋转信号, 收集求和平均值,
转换成 rpm,读和校对, 计算 gph
– 变换流 确定加, 减速度, 计算里程,
计算 mph和超速值, 计算燃料消耗
– 输出流 产生加, 减速显示, 里程显示,
发出铃声, 产生 mph和 mpg显示
下一页上一页 停止放映 第 80页
设计步骤（三）
? 第 1级分解, 产生顶层模块
第 1级分解过程实际上是对 DFD自顶向下的控制进行分
配 。 DFD被映射为一个特殊的软件结构：输入控制,
变换控制和输出控制, 再人为地为它们加一个主控
模块 。 再根据实际问题为每个模块命名 。
Cm
Ci Ct Co
数字仪表板
控制系统
接收传感
器信号
数据转换
控制
驱动仪表
板面
下一页上一页 停止放映 第 81页
设计步骤（四）
? 第 2级分解，建立中下层模块
由顶向下，逐步精细，设计中、下层模块。
– 为每个逻辑输入设计一个输入模块,向上属模块提
供输入信息； 而该模块又需要两个下属模块，分别
称为, 取模块, 和, 转换模块, 。沿每条逻辑输入
分支，按此办法一直分解到物理输入为止。
– 同理为每一个逻辑输出设计一个输出模块,它要输
出上属模块送来的信息,而该模块又需要两个下属
模块；一个转换送来的信息，另一个把转换的信息
送走。
– 转换模块的设计无规律性，一般可根据中心加工的
子加工来建立模块。
下一页上一页 停止放映 第 82页
第 2级分解举例
? 将数字仪表盘控制系统继续分解：
读旋转信号
接收传感器
信号rpm
sps
sps 收集 sps
转换成 rpm
信号均值
信号 /秒
计算 gph
读燃料流
燃烧流 计算 mph
数字转换
控制?sps
确定加减速
里程
计算里程
计算 mpg
rpm
箭头
指示
rpm mph
mpg
mph
gph
gph
变换处理输入模块
下一页上一页 停止放映 第 83页
第 2级分解举例（续）
? 输出模块
驱动仪表盘
加减速显示 显示里程显示 mph 发出铃声
发光二极管显示
显示 mpg
下一页上一页 停止放映 第 84页
设计步骤（五）
? 进一步精化
数字仪表板
控制系统
发出
铃声
计算
里程
显示
mph
显示
mpg
显示
里程
显示
加减速 发光二极管显示
精化后的数字仪表盘
系统的软件结构
驱动仪表板面数据转换控制
读旋转
信号
计算
gph
计算
mph
计算
mpg
确定加减速
读燃料
流
接收传感器信号
转换成
rpm
下一页上一页 停止放映 第 85页
事务分析技术
? 事务分析技术也是 将相应的数据流程图
（ DFD） 映射为对应的的软件结构图 。
? 事务分析的组设计步骤同变换分析,
– 确定数据流图的类型
– 确定流界
– 第 1级分解
– 第 2级分解
– 设计后处理
下一页上一页 停止放映 第 86页
3、详细设计方法
? 详细设计的概念,是根据每个模块的功能设计其逻辑描
述, 实现算法以及实现这些算法的逻辑控制流程, 并设
计这些模块所需的局部数据结构 。
? 详细设计的方法,主要是用结构程序设计 SP方法,
? 详细设计的表示工具,有图形工具和语言工具 。
? 图 形 工 具, 有 程 序 流 程 图 (p296),PAD（ Problem
Analysis Diagram） 图, NS（ 由 Nassi和 Shneidermen
开发 ） 图,
? 语 言 工具,有 伪码 和过 程设 计 语言 PDL（ Program
Design Language） 等 。
下一页上一页 停止放映 第 87页
SP中的基本结构
? 顺序结构
? 选择结构
– IF THEN ELSE 结构
– IF THEN 结构
– IF OR IF ELSE 结构
– CASE 结构
? 重复结构
– 当型结构
– 直到型结构
? 出口结构
? 可用判定表, 判定树表示
下一页上一页 停止放映 第 88页
N-S图（盒图）
下一页上一页 停止放映 第 89页
PAD图
下一页上一页 停止放映 第 90页
SP中的优点
? 自顶向下, 逐步求精方法符合人们解决复杂问题的普遍
规律 ；抽象, 分解, 找出关键问题所在 。 将重点, 技术
难点找出来, 便于精确描述和求解 。 模块化设计便于协
同开发, 因而 可以显著提高软件系统的成功率和生产率 。
? 用先全局后局部, 先整体后细节, 先抽象后具体的逐步
求精过程开发的程序有清晰的层次结构, 容易理解和阅
读 。 采用划整为零的开发技术, 便于各层次人员发挥各
自的创造性劳动 。
? 不使用 GOTO语句, 使程序静态结构和程序动态执行情况
一致, 容易理解和阅读, 开发出的程序容易修改和维护 。
? 程序只采用三种基本结构, 有确定的逻辑结构, 可读性
好 。
? 共用模块可重用 。
下一页上一页 停止放映 第 91页
SP中的缺点
? SP方法的模块化设计的子程序, 函数的 可重用性很小 。 可
重用的只是一些标准库函数或基于某个 OS的 I/O函数 。 其
它模块的可重用性很小 。
? 数据和过程的分离 。 程序员在编程时必须随时考虑要处理
的数据的格式：
– 不同格式的数据, 即使做相同的处理, 也要编写不同
的代码；
– 数据格式一样, 但处理不同, 也要用不同的代码；
– 相容性问题 。 当程序和数据相对独立时, 程序员要始
终考虑保持程序和数据的一致性 （ 用错误数据调用正
确的程序, 或用正确的数据调用错误的程序 ）, 这已
成为程序员的沉重负担 。
? 这些问题都是 SP方法本身解决不了的 。
下一页上一页 停止放映 第 92页
四、程序编码
? 程序设计语言的特点
? 选择语言
? 写程序的风格
? 程序设计方法论
下一页上一页 停止放映 第 93页
1.程序设计语言的特点
? 软件工程师应该了解程序设计语言各方面的特点,
以及这些特点对软件质量的影响, 以便在一个特定
的开发项目选择语言时, 能够作出合理的选择 。
? 程序设计语言的特点是,
– 名字说明
– 类型说明
– 初始化
– 程序对象的局部性
– 程序模块
– 循环控制结构
– 分支控制结构
– 异常处理
– 独立编译
下一页上一页 停止放映 第 94页
程序设计语言的特点（一）
? 名字说明 预先说明程序中使用的变量名, 这是许多编译系
统所要求的, 目的是检查变量名的合法性, 使错误能消除在
语义, 语法检查阶段 。
? 类型说明 用于定义对象在计算机中的存储单元的长度 。 确
定了类型也就确定了该对象的使用方式 。 编译系统能发现程
序中对某个特定类型的对象使用不当的错误, 有助于减少程
序错误 。
? 初始化 变量在没使用前是何种状态 （ 值 ）, 在不同语言中
是不确定的 。 因此, 在使用前进行必要的初始化处理, 以减
少发生的可能性 。
? 程序对象的局部性 提倡使用 局部变量, 这不仅有助于提
高可读性, 而且有助于减少差错和提高程序的可修改性 。
下一页上一页 停止放映 第 95页
程序设计语言的特点（二）
? 程序模块 为了控制程序对象名字的可见性, 一些块结构语言
提供了保护控制机制：
类程 （ CLASS） SIMULA语言 段 （ Segment） ALGOL60 语言
模块 （ Module） Modula语言 包 （ Package） Ada语言
这些保护机制有些很好的特性, 例如 Ada语言中的, 包,, 可用来
构造抽象数据类型等, 因此, 这类语言适合于较大型软件工程项
目 。
? 循环控制结构 常见的循环结构有三种,FOR 循环, WHILE… 循
环, REPEAT … UNTIL循环 ;在实际应用中, 往往在循环体内加设
测试循环结束条件, 以便决定是否继续循环 。 为此, 有些语言中
增加了诸如,exit,break,loop,escape等语句, 改善了程序
结构的可读性 。
下一页上一页 停止放映 第 96页
程序设计语言的特点（三）
? 分支控制结构 主要是 CASE结构容易出现两类问题,
– 若 CASE表达式取值在指定范围之外, 则不能确定执行
何种操作；
– 由 CASE表达式选定执行的语句, 有选择排序的问题；
如果排序有错, 编译和运行时检查不出来, 而发生逻
辑错误 。
– 有些语言做了相应的处理, 例如, C中增加了 default
语句 。
? 异常处理 大多数语言没有提供检测和处理异常情况的有
效帮助机制 。 一旦发生异常, 只能通过调试手段去追踪,
解决 。 而有些语言 （ 例如 PL/1,Ada） 则考虑了异常情况
的处理问题 。
? 独立编译 便于程序的开发和调试, 提高开发, 维护效率 。
下一页上一页 停止放映 第 97页
2.选择语言
? 开发软件系统时必须根据实际情况选择使用的程序
设计语言 。
? 程序设计语言分, 汇编语言, 和, 高级语言, ； 汇
编语言 的程序执行效率高, 但生产效率低； 高级语
言 的程序执行效率不如汇编语言, 但编程效率则要
高得多, 同时还有可读性, 可维护性好等优点 。
? 因此, 除了在一些特殊应用领域 （ 例如, 对程序执
行时间, 存储空间都有很严格限制的情况；需要产
生任意的, 甚至非法的指令序列等 ） 之外, 其他程
序一律使用高级语言编程 。
? 选择语言时, 不仅要考虑理论上的标准, 还必须同
时考虑使用方面的各种限制 。
下一页上一页 停止放映 第 98页
选择语言的重要实用标准（一）
? 系统用户的要求 使用用户熟悉的语言, 因为系统要由用户
自己来维护 。
? 可以使用的编译程序 运行目标系统的环境中可以提供的编
译程序, 往往限制了可选用语言的范围 。 例如, 在 MS-DOS下,
就不能使用 Visual C++语言 。
? 可以得到的软件工具 好的开发工具, 将有利于系统的实现
和验证 。
? 工程规模 对规模庞大的工程而言, 若没有完全合适的程序
设计语言, 则专为本工程设计一种专用语言也是值得的 。
? 程序员知识 学习和掌握一门语言是两个完全不同的标准,
应尽可能选用程序员熟悉的语言 。
? 软件可移植性要求 若目标系统将在几个不同大环境下运行,
或使用寿命很长的话, 应该选择标准化程度高, 可移植性好
的语言 。
下一页上一页 停止放映 第 99页
选择语言的重要实用标准（二）
? 软件的应用领域 选择语言时应充分考虑目标系
统的应用范围：
FORTRAN 科学计算首选语言
COBOL 适合于商业应用
C和 Ada 适合于系统和实时应用
LISP 适合于组合问题的应用
PROLOG 适合于表达知识和推理应用
做什么事, 用什么工具
下一页上一页 停止放映 第 100页
3.写程序的风格
? 定义,指程序员在编程时所表现出来的特点,
逻辑思路, 结构等 。
? 可以体现在下列各个方面,
– 源代码文件 （ 程序内部的文档 ）
– 数据说明
– 语句构造
– 输入 |输出
– 提高程序质量的技巧
– 效率
– 例如：写出 10中好的程序编码风格
下一页上一页 停止放映 第 101页
源代码文件（程序内部的文档）
? 包括程序中使用的标识符, 适当的注释以及程序
的视觉组织 。
? 标识符 命名要有一定的规则；用拼音或英文字符 。
? 注释行 通常在源程序中用大量篇幅 （ 最多占到
1/3） 加入注释行, 在开发者和读者间进行钩通,
说明程序的功能, 标识符的含义, 主要算法等 。
特别在维护阶段, 对理解程序提供了指导 。
? 程序书写格式 各控制结构的层次应呈锯齿形, 同
一层次对齐, 下一层退缩几格 。
下一页上一页 停止放映 第 102页
数据说明
? 为使数据定义更容易看懂, 更容易维护, 要建立一
些指导原则：
– 数据说明顺序标准化, 最好按照类型说明, 公用
变量, 局部变量, 文件说明的顺序 ；
– 一个语句说明若干个变量时, 名字最好按字典排
序；
– 对复杂的 DS,要加注释, 说明固有特性 。
下一页上一页 停止放映 第 103页
语句构造
? 语句构造的原则是：
– 简单直接 不应追求效率而使代码复杂化；
– 为了便于阅读和理解, 不要一行写多个语句,
不同层次的语句应呈锯齿形；
– 不用复杂的测试条件, 不用或少用, 非条件, ；
– 避免使用大量嵌套循环及条件循环；
– 使用条件来简化表达式 。
下一页上一页 停止放映 第 104页
输入 /输出
? 在编码时要考虑下列 I/O风格的规则：
– 对所有的输入数据进行 检验
– 检查重要的输入项组合的 合法性
– 保持输入 格式的简单
– 使用数据 结束标记, 不要要求用户指定数据的数目
– 明确提示 交互式输入的请求, 详细说明可用的选择
或边界数值；
– 当程序设计语言对格式有严格要求时, 保持输入 格
式一致
– 设计良好的输出 报表
– 给所有的输出加标志
下一页上一页 停止放映 第 105页
提高程序质量的技巧
? B.Kernighan和 P.Plauger在, 编程风格要点,
一书中讨论了 提高程序质量的种种技巧,
– 避免使用过于相似的变量名
– 变量名中尽量不含数字
– 同一变量名不要具有多种意义
– 显式说明所有变量
– 注意浮点运算的误差
– 注意整数运算的特点
– 避免不必要的 GOTO语句
– 尽量少用语句标号
下一页上一页 停止放映 第 106页
效率
? 程序运行时间 源程序的效率由算法的效率决定, 但写程序
的风格也能对程序的执行速度和存储器要求产生影响, 可应
用下述规则, （ 语句, 变量类型, 数组 ）
– 写程序前先简化算术和逻辑表达式
– 尽量避免使用多维数组, 尽量避免使用指针和复杂的表
– 使用时间短的算术运算
– 不要混合使用不同的数据类型
– 尽量使用整数运算和布尔表达式
? 存储器效率 提高存储器效率的 关键是, 简单,
? I/O效率 简单清晰是提高人 -机通信效率的关键, 应采用：
– 所有 I/O都应该有缓冲, 以减少用于通信的额外开销
– 对二级存储器 （ 磁盘 ） 应选用最简单的访问方法
– 二级存储器的 I/O应该以信息组为单位进行 。
下一页上一页 停止放映 第 107页
4.程序设计方法论
? 通常有两种方法：自顶向下和自底向上
– 自顶向下 （ 特点 ）,
? 程序可读性好
? 可靠性较高
– 自底向上 （ 特点 ）
? 程序往往局部是优化的, 系统整体结构较差；
? 可极早发现关键算法是否可行, 可较好地避免
较大的返工 。
下一页上一页 停止放映 第 108页
五,系统 测试
? 软件测试概述
? 测试用例的设计
? 测试实施方法
? 软件的调试
测试的目的是什么？
？ 成功的测试是什么？
下一页上一页 停止放映 第 109页
1.软件测试概述
? 测试的重要性 软件测试的重要性及其与可靠性
的密切联系怎样强调也不过分。这是一个典型
事例：在美国的一次飞往火星的火箭发射中，
因控制程序中的一个循环语句,DO 5 I=1,3”被
误认为是赋值语句,DO 5 I=1.3”,一点之差,使火
箭发生爆炸,损失一千万美元。
? 目的 发现软件中隐藏的各种差错。要纠正一种
错误的看法：认为“测试是为了说明程序没有
问题”。恰恰相反，没有找出错误的测试被认
为是失败的测试；而” 成功的测试是能够发现
隐藏的差错的测试“。
下一页上一页 停止放映 第 110 页
? 如果为了证实程序是正确的而进行测试, 就会设
计一些不易暴露错误的测试方案；
? 如果为了发现程序中的错误而进行测试, 就会力
求设计最能暴露错误的测试方案 。
? 结论 由于测试目标是为了找出程序中的错误, 因
此, 由程序设计者本人进行测试是不明智的 。 通
常, 测试分两个阶段 ；程序模块编好后, 程序员
本人对该程序进行必要的测试, 称为, 单元测
试,, 在整个系统都完成后, 由专职测试人员对
整个系统进行的测试称为, 系统综合测试, 。
测试心理学分析
下一页上一页 停止放映 第 111 页
? 测试 为了发现错误而执行程序的过程
? 调试 找出程序中的错误原因, 位置并加以纠正
? 可靠性 在给定时间内, 软件不发生错误的概率
? 黑盒测试法 不考虑程序的内部结构和处理过程
的测试, 也称为 功能测试, 数据驱动测试 。 只
检查程序功能是否满足系统功能和规格说明书
的要求, 不管内部如何处理和如何实现 。
? 白盒测试法 按程序的内部逻辑结构和处理过程
进行的测试, 称为 结构测试, 逻辑驱动测试 。
测试基本概念
下一页上一页 停止放映 第 112 页
2.测试用例
? 测试的关键问题是 如何设计测试用例；它的组成：
测试用例 = 指定功能 +测试数据 +预期效果
? 测试的基本原则,
1） 在执行程序前应该对期望的结果有明确的描述，
测试后应对输出进行仔细的检查。 （正确？）
2） 不仅要选择合理的输入数据作为测试用例，还应
选用 不合理的输入数据 作为测试用例。
3） 除了检查程序是否做了应做的工作之外，还应检
查程序 是否做了不应做的事 。
4） 应该长期 保留 所有的 测试用例,直到该系统被废
弃不用为止。
下一页上一页 停止放映 第 113 页
测试用例的设计
? 设计测试用例的 基本目标 是,确定一组最有可能发现某个
错误或某类错误的测试数据。
? 设计测试数据的技术有许多种 ；通常的做法是用黑盒法设
计基本的测试用例，再用白盒法设计一些补充用例。
? 测试方法,
? 逻辑覆盖
– 语句覆盖
– 判定覆盖
– 条件覆盖
– 判定 /条件覆盖
– 条件组合覆盖
? 等价类划分
? 边值分析
下一页上一页 停止放映 第 114 页
逻辑（路径）覆盖（白盒法）
? 按程序的内部逻辑结构进行测试，为了衡
量测试的覆盖程度，建立下列标准（从低
到高）：
– 语句覆盖,每个语句都至少执行一次
– 判定覆盖,对判别语句的每个分支至少要经过一次
– 条件覆盖,每个条件可能的值至少出现一次，及条
件表达式中各个条件取两个不同的值
– 判定 /条件覆盖,使判定的, 真,,, 假, 各执
行一次，还要使判定中每个条件取两种不同的值
– 条件组合覆盖,使每个判定中的条件的各种组合
都出现一次
下一页上一页 停止放映 第 115 页
举例
有一要测试的程序如下：
sub （ a, b，ｘ）
float a,b，ｘ；
{ float y;
if（ a>1 && b=0)
y=x/a;
if(a=2||x＞ 1）
ｘ＝ｘ＋１；
｝
结束
程序逻辑结构图
开始
a>1&&b=0？
a=2||x>1?
y=x/a
x=x+1
A
B
C
D
E
下一页上一页 停止放映 第 116 页
逻辑覆盖分析 ——语句覆盖
? 执行程序中的每个语句。为使程序中的
每个语句都至少执行一次,只需设计一
个通过路径ＡＣＥ的输入数据即可。选
择输入数据为：
ａ＝２，ｂ＝０，ｘ＝３
就可达到, 语句覆盖, 的标准。
下一页上一页 停止放映 第 117 页
逻辑覆盖分析 ——判定覆盖
? 对判别语句的每个分支至少要经过一次,为
达到, 判定覆盖, 的标准，则要经过路径：
Ａ CＤ和Ａ BＥ，为此，选用输入数据为：
ａ＝３，ｂ＝０，ｘ＝０，走ＡＣＤ路径
ａ＝２，ｂ＝１，ｘ＝３，走ＡＢＥ路径
? 判定覆盖比语句覆盖严格。但还比较弱，例
如,ABD路径就没走到。若把, X>1”错写成
,X<1”,还是检查不出来，它只有 50%的机会
去检查 X的值。
下一页上一页 停止放映 第 118 页
逻辑覆盖分析 ——条件覆盖
? 使判别中 每个条件可能的值至少出现一次，及条件表达式中各个
条件取两个不同的值 。
? 程序中有 4个条件, A>1,B=0,A=2,X>1
。为达到, 条件覆盖, 标准，需选用数据,使得
在 A点有 A>1,A<=1,B=0,B<>0
在 B点有 A=2,A<>2,X>1,X<=1
为此选择下列两组测试数据：
ａ＝２，ｂ＝０，ｘ＝４ 走ＡＣＥ路径
ａ＝１，ｂ＝１，ｘ＝１ 走ＡＢＤ路径
?, 条件覆盖, 比, 判定覆盖, 强,因为要使每个条件都取到两个不
同的结果,而判定覆盖不能保证这一点。
? 有时判定覆盖和条件覆盖不能互为包含。
下一页上一页 停止放映 第 119 页
逻辑覆盖分析 ——判别／条件覆盖
? 使判定的, 真,,, 假, 各执行一次，还要使判
定中每个条件取两种不同的值 。选择下列输入数
据可满足这一标准：
ａ＝２，ｂ＝０，ｘ＝４ 走ＡＣＥ路径
ａ＝１，ｂ＝１，ｘ＝１ 走ＡＢＤ路径
? 在含有 AND和 OR的逻辑表达式中,某些条件将抑制
其它条件 ;例如,表达式 A AND B,如果 A为假,则
就不再检查 B了。因此在实际应用中要设计更多
的用例来测试未走过、而可能隐藏错误的路径。
下一页上一页 停止放映 第 120页
逻辑覆盖分析 ——判别组合覆盖
? 使每个判定中的条件的各种组合都出现一次。 满足条件组合覆
盖的测试数据一定满足判定、条件、条件／判定覆盖。
? 各种可能的组合共有八种：
?ａ＞１，ｂ＝０ ? ａ＞１，ｂ＜＞０
?ａ＜＝１，ｂ＝０ ? Ａ＜＝１，ｂ＜＞０
? ａ＝２，ｘ＝１ ? ａ＝２，ｘ＜＝１
?ａ＜＞２，ｘ＞１ ? ａ＜＞２，ｘ＜＝１
? 下面４组测试数据可以覆盖上面８种条件组合：
ａ＝２，ｂ＝０，ｘ＝４ 覆盖 ? ?
ａ＝２，ｂ＝１，ｘ＝１ 覆盖 ? ?
ａ＝１，ｂ＝０，ｘ＝２ 覆盖 ? ?
ａ＝１，ｂ＝０，ｘ＝１ 覆盖 ? ?
注：这４组数据并
不能覆盖程序中的
每条路径，ａｃｄ
就没执行。说明条
件组合覆盖标准仍
不彻底。
下一页上一页 停止放映 第 121页
等价类划分（黑盒法）
? 把所有可能的输入数据（有效和无效）划分为若干个等价类，每
类中一个典型数据在测试中起的作用和这一类数据的作用是相同
的。因此，可以从每个等价类中只选取一组数据作为测试数据 。
? 使用等价类划分法首先要划分输入数据的等价类，确定输入数据
的有效等价类和无效等价类。
? 划分等价类需要经验，以下是一些启发性原则：
– 若输入条件规定了输入值的范围，则可能划分一个有效的等价
类和两个无效的等价类（小于 MIN或大于 MAX）；
– 如果规定输入数据必须遵循的规则，则可划分出一个有效的等
价类（符合规则）和若干个无效的等价类（不符合规则）。
– 若规定了输入数据为整型，则可划分出整数、零和负整数三个
有效等价类。
下一页上一页 停止放映 第 122页
等价类划分 （黑盒法）
? 例如，若规定输入数据为整数，等价类划分表为：
输入条件 有效等价类 无效等价类
整数 正整数
１到３２７６７
零 ０
负整数
－１到
－３２７６８
符合规则 不符合规则
正整数
大于３２７６７
零 非法 －０
负整数
小于－３２７６８
下一页上一页 停止放映 第 123页
边界值分析法
? 经验证明，在边界处，程序最容易出问题。例如，在下标、
数据结构、数组、循环等的边界附近。
? 使用 边值分析方法 设计测试用例首先应确定边界情况，这需
要经验和创造性。 选取测试数据应刚好等于、刚好小于和刚
好大于边界值。
? 有下列启发式规则：
– 若输入条件规定值的个数,则分别选取值的最大个数、
最小个数以及接近最大、最小的个数作为测试用例；
– 对输入条件规定有值的范围,则选用范围边界数及刚超
出范围的无效数作为测试用例；
– 若输入／输出是有序集,则注意第一个和最后一个；
– 对三角函数的自变量,注意特殊角度的值。
? 通常设计测试用例总是将等价法和边值法结合使用。
下一页上一页 停止放映 第 124页
3.测试实施方法
? 这里有两个基本概念：驱动模块和存根模块。
驱动模块 启动被测试模块的模块
存根模块 也称模拟子程序，用于代替被测试模块所
调用的模块。
? 模块测试 由程序设计人员在完成模块设计后自己进行的测
试。用于检验模块本身的错误。
? 组装测试 按设计要求将某个功能子系统的所有模块组装到
一起的测试，用于发现与接口有关的问题。
? 确认测试 以用户为主，使用实际业务数据进行有关测试。
用于发现系统需求分析、定义阶段的错误。
下一页上一页 停止放映 第 125页
模块测试
? 可先用白盒法测试模块的内部逻辑，再用黑盒法测
试外部预期的结果。程序交出后，由测试工程师再
以黑盒法为主进行测试。
? 模块测试 测试评价模块的下述特征,
?模块接口
?局部数据结构
?重要的执行通路
?出错处理通道
?影响上述各方面特征的边界条件
下一页上一页 停止放映 第 126页
组装测试
? 组装测试分为,渐增式 和 非渐增式 。
– 渐增式 逐渐将要测试的下一个模
块加进到已测试好的模块中进行的
测试。
– 非渐增式 先测试每个模块，再把
所有模块按设计要求组装在一起的
测试。
下一页上一页 停止放映 第 127页
组装测试两种方法的优缺点
? 称” 非渐增式“为Ａ方法,称” 渐增式“为Ｂ方法 。
?Ａ方法工作量大,Ｂ方法工作量较小 ；因为要编写
用于测试的驱动模块和存根模块。
?Ｂ可较早发现模块间的接口错误 ； 而Ａ则发现较晚；
?Ａ发现错误难于诊断定位 ；Ｂ则容易诊断错误的位
置 ；
?Ｂ可使已测试好的模块在新条件下接受新的测试，
这种测试更彻底。
?Ｂ占用较多的机器时间 ；
?Ａ可并行测试所有模块,因此可充分利用人力，加
速工程进度。
? 前４条是Ｂ的优点，后２条是Ｂ的缺点； Ｂ方法总
体较好。
下一页上一页 停止放映 第 128页
渐增方法的使用方式
? 自顶向下 从主控模块开始，沿软件控制层自上而下、
逐渐把各个模块组装到已测试结构中的一种方法。在
具体实施中可采用深度优先或广度优先策略。
? 自底向上 从底层模块开始测试和组装的一种策略。
? 优缺点分析,
自顶向下
– 优点, 不要驱动模块,能较早地实现并验证系统的
主要功能，较早的发现接口错误。
– 缺点, 需要存根模块,可能遇到与此相联系的测试
困难，底层关键模块中的错误发现较晚。
而 自底向上 方法的优缺点正好与自顶向下相反。
下一页上一页 停止放映 第 129页
确认测试
? 测试的目的,是验证系统是否能满足用户的需
要。
? 平行运行 即手工系统和计算机系统同时运行，
用对比的方法验证新系统的正确性。
下一页上一页 停止放映 第 130页
4.程序调试
? 程序调试的任务 经过测试暴露出问
题，还必须进一步 诊断错误的原因和
位置，进而改正程序中的错误 。
? 要讨论三方面的问题：
– 调试技术
– 调试策略
– 调试的启发性原则
下一页上一页 停止放映 第 131页
调试技术
? 输出存储器内容
特点：效率低、难定位、输出的是静止状
态的程序内容。
? 加打印语句
特点：显示的是程序的动态信息，大量的
输出，时间慢，可能引出新的问题。
? 用调试工具
特点：动态调试，可自动执行，是现代程
序调试的有效工具。
下一页上一页 停止放映 第 132页
调试策略
? 试探法 大概分析、估计错误的位置；
? 回溯法 确定最先出现”症状“的地方，然后
沿程序的控制流程往回追踪源程序，直到找出
错误源为止。
? 对分查找法 若已知程序中若干个关键点的正
确值，然后用调试工具在关键点附近处输入正
确值；若输出正确，则故障在前半部分；否则，
再查后半部分。
? 归纳法 从线索出发，通过分析线索之间的关
系而找出故障。主要步骤为：收集有关数据，
组织数据，导出假设，证明假设。
下一页上一页 停止放映 第 133页
调试的启发性原则
? 这部分内容，大多是心理学问题：
?要思考,不要盲目地修改程序，至使错误越
来越多； （动脑）
?如陷入困境,放到第２天去解决 ； （冷处理）
?陷入绝境后，要 与别人交谈你的问题,或许
对你有所启发； （交流）
?避免用试验法。 不要在问题没有搞清楚之前，
就改动程序,这样对找出错误不利，程序越改
越乱，以致于面目全非。 （慎重）
下一页上一页 停止放映 第 134页
六、软件维护
? 一个软件产品投入使用后, 通常由于各种理由
需要对它作适当的变更, 完全不变的情况是很
少见的 。 把软件交付使用后的变更称为维护 。
? 维护是软件生存周期最后一个阶段,由于维护工
作的重要性往往被人们忽视, 这更增加了维护
工作的困难 。 平均而言, 大型软件的维护成本
是开发成本的 4倍左右 。 国外许多软件开发组织
把 60%以上的人力用于维护已投入运行的软件 。
这个比例随着软件数量增多和使用寿命延长,
还在继续上升 。 学习软件工程学的主要目的之
一就是研究如何减少花费在软件维护上的工作
量, 降低维护成本 。
下一页上一页 停止放映 第 135页
1.维护活动的类型
（ 1） 校正性维护 。 把诊断, 校正软件错误的过程称之为
校正性维护 。 这部分维护工作约占全部维护活动的
17%～ 21%。 （ 改错 ）
（ 2） 适应性维护 。 由于计算机技术的飞速发展, 外部设
备和其他系统元素经常改进和变化, 为适应变化的环
境而修改软件的活动称之为适应性维护 。 它占总维护
活动的 18%～ 25%。 （ 环境 ）
（ 3） 完善性维护 。 指在使用软件系统的过程中为满足用
户提出的新功能和性能要求而进行的维护活动 。 它约
占总维护活动的 50%～ 60%。 （ 功能 ）
（ 4） 预防性维护 。 为进一步改进可维护性, 可靠性而进
行的维护活动, 约占 4%。 （ 防未然 ）
下一页上一页 停止放映 第 136页
2.维护的代价
? 70年代用于维护软件的费用只占软件总预算的
35%～ 40%,80年代上升为 40%～ 60%,到了 90年代
则上升为 70%～ 80%。
? 软件维护的代价包括 有形 和 无形 两个部分：有
形代价就是上面所提到的那些统计数字；无形代
价包括：
? 当看起来合理的有关变更要求不能及时满足时,
将引起用户的不满；
? 由于维护时的改动, 在软件中引入潜在的故障,
从而降低了软件的质量；
? 当必须把软件开发工程师调去从事维护工作时,
对开发过程造成的影响 。
下一页上一页 停止放映 第 137页
3.维护问题（困难）
（ 1） 理解别人写的程序通常非常困难, 而且困难程度随
着软件配置成分的减少而迅速增加 。 如果仅有源程序代
码而没有说明文档, 问题会更加严重 。
（ 2） 严格按规范化方法开发的软件系统一般不需要大的
维护活动, 而需要维护的软件系统却往往因为没有必需
的文档或 文档残缺不全, 使得维护活动进展非常艰难 。
（ 3） 当需要对软件进行维护时, 很难指望熟悉软件系统
的原开发人员能全力以赴地亲临现场参与维护活动 。
（ 4） 绝大多数软件在 设计时没有考虑将来的修改 。
（ 5） 软件维护不是一项吸引人的工作 。 最出色的, 成功
的维护也只不过是保证他人开发的系统的正常运行, 而
且维护别人开发的软件经常受挫, 使得维护人员无成就
感 。
下一页上一页 停止放映 第 138页
4.软件的可维护性
? 软件可维护性的 定义：维护人员理解, 修改
该软件的难易程度 。
软件生存周期每个阶段的工作都和软件的可维
护性有密切的关系, 实际上, 软件的可维护
性是软件开发各个阶段的关键目标 。
? 软件的可维护性,
– 可维护性因素
– 提高可维护性方法
– 文档
下一页上一页 停止放映 第 139页
(1)可维护性因素
（ 1） 可理解性 。表明维护人员通过阅读源代码程序和有关文档，了解
程序功能、内部逻辑结构、数据结构，以及模块间接口等的难易程
度。按 SA,SD和 SP技术开发的软件，具有模块化、详细的设计文档
等结构化特征，从而使软件具有较好的可理解性。
（ 2） 可测试性 。是诊断和测试的难易程度的度量。软件结构设计合理，
模块具有高内聚性和低耦合性，模块内部算法简单，就可以提高软
件的可测试性。
（ 3） 可修改性 。表明软件容易修改的程度。一个可修改的软件应当是
可理解的、通用的、简单的软件。耦合性、内聚性等都影响软件的
可修改性。
（ 4） 可靠性 。表明在规定条件、时间内，软件不引起系统失效的 概率。
软件可靠性的度量标准主要有：平均失效间隔时间、平均修复时间
和有效性。
（ 5） 可使用性 。从用户观点出发，度量软件使用方便与否的 难易程度 。
一个可使用的程序应该是容易操作、用户按操作手册指导应能排除
因操作失误造成后果的程序。
下一页上一页 停止放映 第 140页
(2)提高可维护性的方法
? 软件生存周期每个阶段的工作都和软件
可维护性有密切的关系 。 提高软件的可
维护性必须从软件生存周期各个阶段的
工作入手 。
下一页上一页 停止放映 第 141页
（ a）问题定义阶段
? 为得到可维护的系统模型，就要 使开发人
员、用户和使用单位管理人员 对问题的性
质、工程的目标和规模 取得完全一致的看
法 。考虑到开始时，双方对要求解的问题
相互不太了解，这就要求系统必须是易于
扩充、完善的系统。
下一页上一页 停止放映 第 142页
（ b）可性行研究阶段
? 可行性研究实质上是在高层以抽象方式进
行的系统分析和设计的过程。该过程必然
会对未来系统的可维护性产生巨大影响。
这是因为：
① 被推荐的系统是已经实现的、经过实用检
验的系统，具有较好的可维护性；
② 选用的技术是成熟的技术，同时要求这些
技术要有较强的维护手段。
下一页上一页 停止放映 第 143页
（ c）需求分析阶段
? 该阶段的任务是准确地描述系统, 做什
么, 。同时，还要确定系统的运行环境，
要考虑系统将来可能的变化，对系统的可
扩充性和可修改性预先做好准备,从而提
高系统的可维护性。
下一页上一页 停止放映 第 144页
（ d）概要设计阶段
? 该阶段的目的是用比较抽象概括的方式描
述系统, 怎样做,, 确定系统的物理配置
以及系统的软件结构和模块结构 。 在制定
方案时, 要充分考虑组成系统的各个物理
元素 （ 如程序, 数据库, 文档等 ） 对可维
护性的影响 。
? 在设计系统的软件结构和模块化时, 要充
分运用结构化设计技术和模块技术, 尽量
减小模块间的耦合性, 提高模块的内聚性,
获得较高的模块独立性 。 这是影响可维护
性的基本要素 。
下一页上一页 停止放映 第 145页
（ e）详细设计阶段
? 该阶段的目标是具体实现系统, 怎样做,, 在
该阶段结束时, 应得到目标系统精确的模块描
述和实现算法 。 为使未来系统便于维护, 模块
设计不仅要求逻辑上的正确性, 还必须强调可
理解性 。
? 设计实现过程中要采用结构化程序设计技术,
使设计出的模块突出结构化特征, 这样的程序
具有统一的静态结构和动态状况, 程序结构清
晰, 便于阅读理解, 同时也便于程序的调试和
测试 。 这些措施都将对软件的可维护性起巨大
的作用 。
下一页上一页 停止放映 第 146页
（ f）编码阶段
? 在该阶段要具体实现模块描述和算法, 选择
PL和编程风格都会对软件的可维护性产生极
大的影响 。
? 选择 PL时, 特别注重所选语言对软件可维护
性的影响 。 一般来说, 选用高级语言而不用
汇编语言；所选语言要具有良好的模块化机
制, 可读性好的控制结构和数据结构, 应用
自动生成和报表自动生成功能, 功能强大的
开发工具和开发环境等 。
? 现在流行的 OOPL具有上述要求的性能, 用这
种语言开发的程序具有较好的可维护性 。
下一页上一页 停止放映 第 147页
（ g）测试阶段
? 在该阶段必须保持 实际系统和软件配置中描述系
统的完全一致性 。 测试过程必须置于可控操作规
程和操作范围之内, 以保证错误确实被消除, 修
改的副作用在允许的范围内, 软件配置的版本更
新与软件一致, 从而保证软件的可维护性 。
下一页上一页 停止放映 第 148页
（ h）维护阶段
? 维护过程本质上是集修改, 系统定义和开发为
一体的过程, 对于适应性维护和完善性维护来
说更是如此 。 要严格按照有关规程进行维护活
动, 在完成每一项维护工作之后, 都要对维护
工作进行仔细认真的复查, 要采取有效措施避
免和减少修改代码, 数据结构和有关文档可能
带来的副作用, 以保证维护后的软件仍具有较
好的可维护性 。
下一页上一页 停止放映 第 149页
(3)文档
? 文档是影响软件可维护性的决定因素 。 由
于需要维护的系统一般都是经过长期实际
运行考验的系统, 人们感兴趣的并不是系
统可运行否, 而是在特殊情况下如何使系
统也能正常地运行, 所以对于维护人员来
说文档比程序代码更为重要 。
? 文档分为用户文档和系统文档两类 ；
? 用户文档,主要描述系统功能和使用方法；
系统文档,描述系统设计, 实现和测试等
各方面的内容 。
下一页上一页 停止放映 第 150页
（ a）用户文档
? 用户最初往往是通过用户文档了解系统功能, 它
包括下述 五方面的内容：
① 功能描述 。 说明系统能做什么, 有哪些主要功能；
② 安装手册 。 说明安装系统的操作步骤以及怎样根据
用户特定的硬件配置设置系统环境；
③ 使用手册 。 手册中应该通过丰富的例子说明怎样使
用常用的系统功能, 还应该说明用户因操作失误
时怎样恢复系统, 以及如何处理异常情况；
④ 参考手册 。 详尽描述用户可以使用的所有系统设施
（ 包括, 调试工具, 故障分析工具, 系统维护工
具等 ） 以及它们的使用方法；
⑤ 操作员指南 。 如果需要有系统操作员的话, 说明操
作员应该如何处理使用中出现的各种情况 。
下一页上一页 停止放映 第 151页
（ b）系统文档
? 系统文档描述的是从问题定义, 需求说明,
模块算法说明, 系统设计, 实现到系统测
试用例, 测试方案等软件配置的所有系统
内部特征的文档 。 （ 阶段文档 ）
? 系统文档中应该更详细地说明系统各部分
实现之间的联系, 使用的方法和算法, 错
误恢复方法, 系统主要参数的范围等与系
统具体实现有关的一切技术方面的信息数
据 。 （ 算法文档 ）
下一页上一页 停止放映 第 152页
作业、思考题
思考：
第 10章
1—25
下一页上一页 停止放映 第 153页
结束语
? 欢迎参加到中心网站, 软件基础, 课程的学习
讨论中来。
? 中心网址：
http,//ctec.xjtu.edu.cn
? 课件下载地址,
ftp,//ctec.xjtu.edu.cn
? E-mail:
xjtuzhao@sina.com
谢谢，再见！
计算机软件基础
The software basic of computer
主讲,赵英良
第 16单元
传统程序设计方法
下一页上一页 停止放映 第 2 页
本讲内容
? 一,结构化开发方法
? 二、软件需求定义
? 三、系统设计（软件的设计）
? 四、程序编码
? 五,系统测试
? 六、软件维护
下一页上一页 停止放映 第 3 页
教学目标
? 了解传统程序设计方法,
– 基本概念
– 方法及特点
– 步骤及准则
下一页上一页 停止放映 第 4 页
本单元涉及内容
? 第 10章 传统的软件开发方法
– 10.1 结构化开发方法概述
– 10.2 系统分析与定义
– 10.3 系统设计
– 10.4 系统编程
– 10.5 系统测试
– 10.6 系统维护
? P273~P333
下一页上一页 停止放映 第 5 页
一,结构化开发方法
? 结构化开发方法是传统的软件系统开发方法 。
? 结构化开发方法的基本思想：
把一个复杂问题的求解过程分阶段进行, 每个阶
段处理的问题都控制在人们容易理解和处理的范
围内 。
? 基本要点是,
– 自顶向下
– 逐步求精
– 模块化设计
– 结构化编码
– 主程序员组织
– 结构化设计 SD
下一页上一页 停止放映 第 6 页
“自顶向下”
? 将复杂的大问题分解为小问题, 找出问题的关
键, 重点所在, 同时找出技术难点来 。 然后用
精确的思维定性, 定量地描述问题 。
? 问题的核心是, 分解, 。 如何划分？ 准则是什
么？
? 实现的手段是, 子程序,,, 函数,, 即模块
化 。 要 点：将大问题化为小问题，
找出关键、难点，定量描述
核心是：分解
手段是：模块化（函数、子程序）
下一页上一页 停止放映 第 7 页
“逐步求精”
? 将现实世界的问题经抽象转化为逻辑空间或求
解空间的问题 。 复杂问题经抽象化处理变为相
对较简单的问题 。 经几次抽象 （ 精化 ） 处理,
最后到求解域中只是非常简单的编程问题 。
? 求解 （ 抽象 ） 过程可以划分为若干个阶段, 在
不同阶段用不同工具来描述 。 实现细则在前期
阶段可以不去管它 。 在每个阶段有不同的规划
和标准, 产生出不同阶段的文档资料 。
将现实问题抽象为逻辑空间问题，
几经抽象化为简单的编程问题。
下一页上一页 停止放映 第 8 页
模块化处理
? 模块化就是 把程序划分为若干个模块, 而每个
模块完成一个子功能, 把这些模块汇总起来构
成一个有机整体, 即可完成指定的功能 。
? 模块化的目的 是为了降低软件复杂度, 使软件
设计, 调试和维护等操作变得简易 。
下一页上一页 停止放映 第 9 页
结构化编码
? SP编码的方法强调 清晰简洁, 它是一种构造
程序的技术, 有利于提高软件生产率及降低
软件维护代价 。
? 1966年 Bohm和 Jacopin就证明了只要用三中基
本结构, 就足以表示所有形式的程序控制结
构 。
? 1978年 Kernihan和 Plauger对一些编码风格进
行归纳, 提出了 16种具体方法 。
下一页上一页 停止放映 第 10页
结构化编码风格
?尽量使用标准库函数
?程序讲究清晰, 避免过于精
巧
?对重复使用的表达式尽量调
用公共函数代替
?使用括号, 以避免二义性
?用逻辑表达式代替分支嵌套
?使用缩排格式
?避免使用 IF THEN 和空 ELSE
?注意计算机运算特点, 如
10.0乘 0.1很少等于 1.0
? 使用有意义的变量名
? 对输入进行错误判别
? 注释勿用太滥
? 模块化功能专一,模块间
偶合清晰
? 递归定义的 DS尽量采用
递归过程访问
? 把大程序分成小块去编
写和测试
? 勿追求不必要的效率,尽
量采用基本控制结构
? 避免循环多个出口
下一页上一页 停止放映 第 11 页
主程序员组织
? 是一种人员的组织形式
? 主程序员 组织负责人,全权负责,包括解决技术难题,
有时一些关键性技术问题,主程序员应亲自动手遍程去
解决；他必须是技术高手, 是程序生产过程中的总体
设计师 。
? 程序员 按任务书要求编程；是程序生产线上的, 工
人, 。
? 测试工程师 具有较高遍程水准和经验, 负责系统测
试；是程序生产过程中的检验员 。
? 文档人员 自始至终参加程序生产活动, 负责编写一
切有关文档资料 。
下一页上一页 停止放映 第 12页
结构化方法的体系结构
? 结构化方法的体系结构是,
– 结构化分析
（ SA— Structured Analysis）
– 结构化设计
（ SD— Structured Design）
– 结构化程序设计
（ SP— Structured Programming）
下一页上一页 停止放映 第 13页
结构化分析 SA
? SA方法是 建立在自顶向下, 逐步求精思想基础
上的 分析方法,
? SA方法是分析方法, 基础 是自顶向下, 逐步求精
? 要点, 分解和抽象,
– 把复杂问题自顶向下逐层分解, 再从分解
出的对象中抽象出相对简单的子问题 。
– 经过一系列分解和抽象, 到最底层的问题
已经是很容易求解的了 。
下一页上一页 停止放映 第 14页
结构化设计 SD
? SD方法是由 IBM公司的 Constentine等人花了十
几年时间研究出来的一种程序设计方法, 发表
于 1974年 。
? 简述,SD是一种用于概要设计的方法, 与 SA方
法配合使用 。 （ SD是用于概要设计的方法 ）
? 目标,建立一个结构良好的软件系统 。
? SD方法的基础,是数据流程图, 因此也称为面
向数据流的设计方法 。
? 问题,SA方法用于软件开发的哪个阶段？
下一页上一页 停止放映 第 15页
结构化程序设计 SP
? SP的思想最早是由著名计算机科学家 E.W.Dijkstra提
出的 。
? 1966年 Bohm和 Jacopin证明了只用三种基本结构就能
实现任何 一个入口, 一个出口 的程序；
? 1977年 IBM公司的 Mills又进一步提出：, 程序应该只
有一个入口和一个出口 。
? 在长期程序设计的实践中, SP方法不断得以
完善, 使之成为开发传统应用领域应用系统
的主要方法之一 。
下一页上一页 停止放映 第 16页
关于 SP的定义
? 北大王选院士认为：
– 没有 GOTO语句
– 一个入口、一个出口
– 自顶向下，逐步求精的分解
– 主程序员组
? 谭浩强认为：
– 自顶向下
– 逐步求精
– 模块化设计
– 结构化编码
下一页上一页 停止放映 第 17页
关于 SP的定义（续）
? 另一种说法：
– 自顶向下, 逐步求精
– 程序结构按功能划分为模块
– 模块功能单一, 简单
– 模块由三种基本结构组成
– 程序由函数, 子程序来实现
下一页上一页 停止放映 第 18页
二、软件需求定义
?概 述, 软件需求分析就是 明确 软件系
统将来达到的目标。
?基本任务,准确地回答系统,做什么？”
?目 标,规定项目必须满足的 总目标 ；
确定项目的 可行性 ；拟定完成项目各个
目标的 策略,制定项目资源 成本和进度 。
下一页上一页 停止放映 第 19页
1、软件需求定义的任务
? 理解和表达用户要求，制定软件开发
计划，编写要求说明书。
下一页上一页 停止放映 第 20页
（ 1）软件需求定义的特点
? （ 1）它是软件生存周期中最容易出错的一个阶段，
? （ 2）也是软件工程中最困难的一个阶段。
? （ 3）它是其它阶段的基础，十分重要的阶段。
? 困难在于,
– 不能准确地理解和清楚地描述
– 软件系统非常复杂，以致用户和软件人员都不
能完整、精确地理解它或不能清楚地表达出来；
软件人员和用户缺乏共同语言 。
– 用户熟悉业务，但不了解计算机；而软件人员
则相反； 这种隔阂使双方不能进行交流。
下一页上一页 停止放映 第 21页
（ 2）确定对系统的综合要求
? 系统功能要求
找出系统必须完成的所有功能。
? 系统性能要求
例如，联机系统的响应时间，系统需要的存储容量
以及后援存储，重新启动和安全性等问题。
? 运行要求（环境要求）
对系统运行环境的要求。例如，什么样的硬件环境？
采用哪种 DBMS？ OS平台是什么？需要什么样的
外存储器和数据通信接口等。
? 将来可能提出的要求
为系统将来可能的扩充和修改预做准备。
下一页上一页 停止放映 第 22页
（ 3）软件需求定义的工作流程
系统定义
用户要求 软件功能 范围 功能说
明书
软件计划 软件定义
软件功能 费用、资源进度
下一页上一页 停止放映 第 23页
2、需求分析过程
? 基本过程示意图
? 沿数据流回溯
? 用户复查
? 细化数据流图
? 修改开发计划
? 书写文档资料
? 审查和复审
下一页上一页 停止放映 第 24页
需求分析的基本过程
用户 分析员 程序员
软件开发计划 软件需求说明书
分析追踪
数据流图 用户复查
细化数据
流图
无补充
修改
需要分解
不要分解
有补充修改
交换意见
作出贡献
下一页上一页 停止放映 第 25页
沿数据流回溯
? 通常从数据流图的输出端着手分析，要搞清楚：
– 数据元素从哪儿来？
– 每个输出数据元素又是从哪儿来的？
有时对用户具体的数据元素还搞不清楚，则需要和用
户探讨、商量解决。
? 通常把分析过程中得到的有关部门数据元素信息记录
到数据字典 DD中。把对算法的简明描述记录在 IPO
（输入 |处理 |输出图）图中。
? 通过分析而补充的数据流、数据存储和处理，应该添
加到 DFD的适当位置上。
? 数据字典（ DD）、输入处理输出图（ IPO）
? 数据流图（ DFD）
下一页上一页 停止放映 第 26页
用户复查
? 经分析将在数据流图回溯过程中找出的数据
元素，并由此定义的 DD和算法是否正确？
这只能由最有发言权的用户来复查。
? 在复查过程中反映出新的问题，应及时修改、
补充 DFD,DD和 IPO图，并将对系统的新认
识及时记录下来。实际上，追踪 DFD和复查
系统的逻辑模型这两个步骤是交替进行的循
环过程。
下一页上一页 停止放映 第 27页
细化数据流图
? 在反复循环的分析过程中，不断细化
DFD（即把数据流图扩展到更低的层
次）。通过功能分解可以完成 DFD的
细化，即将一些处理比较复杂的功能
再划分为若干个子功能。
下一页上一页 停止放映 第 28页
修改开发计划
? 在分析过程中可能会不断地修改原拟
定的开发计划，这是正常的。
下一页上一页 停止放映 第 29页
书写文档资料
? 本阶段应完成 4份文档资料：
– 系统规格说明 描述目标系统的概貌、功能
要求、性能、运行及将来可能提出的要求。
– 用户系统描述 从用户角度描述系统，类似
一份用户手册初稿。
– 数 据 要 求 包括 DD、数据结构的层次框
图等。
– 修改的开发计划 包括成本估计、进度计划
表、资源使用计划等。
下一页上一页 停止放映 第 30页
说明
? 需求说明书主要内容,
– 概 述 开发系统的意义、目的、背景及技术术语；
– 现行系统的概况 业务流程、范围、存在的问题等；
– 需求说明
? 功能描述：
? 信息描述, DFD,DD,DS,IPO、接口等
? 性能描述
– 运行环境
– 系统限制
? 用户系统描述
– 系统功能和性能的描述
– 使用系统的主要步骤和方法
– 系统用户的责任等
下一页上一页 停止放映 第 31页
审查和复审
? 分析阶段最后一步是 按结束标准 对该阶
段的工作成果进行正式的技术 审查和管
理审查 。
下一页上一页 停止放映 第 32页
3、需求分析的原则
1,能够表达和理解问题的信息域 信息域反映的是用户
业务系统中数据的流向和对数据进行加工的处理过程,
因此信息域是解决, 做什么？, 的关键因素 。
2,要建立描述系统信息, 功能和行为的模型 建立模型
的过程是, 由粗到精, 的分析综合的过程 。
3,能够对所建模型按一定形式进行分解 分解是为了降
低问题的复杂性, 增加问题的可解性和可描述性 。
4,分清系统的逻辑视图和物理视图
– 软件需求的逻辑视图描述的是系统要达到的功能和要处理的
信息之间的关系, 这与实现细节无关；
– 而物理视图描述的是处理功能和信息结构的实际表现形式,
这与实现细节是有关的
– 需求分析只研究软件系统, 做什么？,, 而不考虑, 怎样
做？, 。
下一页上一页 停止放映 第 33页
4、需求分析的图形工具
? 图形工具在描述复杂关系时比文字叙述要优越。
在系统需求分析过程中为了准确描述需求，常采
用一些简单的描述工具，例如：
数据流图（ DFD,Data Flow Diagram）、
数据字典（ DD,Data Dictionary）、
结构化分析语言（ Language of Structured Analysis）、
判定表 (Decision Table)
判定树等 (Decision Tree)
下一页上一页 停止放映 第 34页
（ 1）数据流图 DFD
? 数据流图（ DFD—— Data Flow Diagram ）以图
形的方式表达数据处理系统中信息的变换和传递
过程。它有四种基本符号：
S
P
X
数据源及数据终点
加工 对数据进行的加工或变换，指向加工的数据流
是输入数据；离开的是输出数据。
数据流 具有名字且有流向的数据
文件 存放数据的场所
下一页上一页 停止放映 第 35页
数据流图举例 ——宾馆管理系统
客人
预订
登录 房管
客人信息库 可售房库 售出房库
客帐库
公安
预付
款 财务
IDD
下一页上一页 停止放映 第 36页
数据流图的结构
? 一个实际问题的数据加工流程是非常复
杂的。如果绘制在一个平面图上就显的
太乱了。
? 因此，通常采用 分层次结构 。把一个复
杂的问题，分解为一些相互独立的子问
题，再绘出分层 DFD。
? 数据流图的组成成分：
数据流、加工、文件、源终点
下一页上一页 停止放映 第 37页
结构图分层举例
宾馆
管理
DFD/L0顶层图
第 2层图
DFD/L1
A
D
C
E
第 3层图
DFD/L2.2DFD/L2.1A1 A2
A3
E1 E2
B
下一页上一页 停止放映 第 38页
（ 2）数据字典 DD（ Data Dictionary）
? DD对数据流程图中出现的所有元素给出逻辑定义 ;即给出
DFD中的数据流、加工和文件、及及数据项等的详细解释。
? 数据字典的条目解释通常采用规范的 定义形式,
客帐 =帐号 +房租 +IDD费 +餐饮费 +洗衣费 +娱乐费 +日期 +经
办人
? 内容
数 据 流, 编号、名称、简述、别名、构成、来源、去向、流量
数据项目, 编号、名称、简述、别名、类型、长度、位数
数据文件, 编号、名称、简述、别名、构成、关键字、存取要求
处理（加工）,编号、名称、简述、别名、处理条件、
I/O内容、处理逻辑
下一页上一页 停止放映 第 39页
（ 3）结构化语言
? 例如，选择结构的描述语句 (IF THEN ELSE)、
循环结构的描述语句等。
? 例如：
DO CASE
CASE 时间 <=12
R_rent=0;
CASE 时间 >12 AND 时间 <=18
R_rent=rent*0.5;
CASE 时间 >18
R-rent=rent;
注意：这不是程序！！
下一页上一页 停止放映 第 40页
（ 4）判定表
? 采用判定表能把加工逻辑表示的更加清楚。
? 判定表中,纵向各列给出的是不同的 条件,
? 横向各行则表示在各条件下相应的 处理 。
条件 结 帐 时 间 12点前 12~18点 18点后
处理 不收费
收半费
收全费
?
?
?
下一页上一页 停止放映 第 41页
（ 5）判定树
? 用树的形式表示条件分枝
? 判定树比判定表更家直观，它用来描述具有多个条件
的数据加工更容易被用户接受。树状的分支表示多种
不同的条件。例如，
结帐时间 =？
12点前 12~18点间 18点后
不收费 收半费 收全费
下一页
下一页上一页 停止放映 第 42页
5、用于需求分析的软件工具
? 为保证软件需求的正确性和需求的一致性，需
要采用适当的软件工具支持需求分析工作。软
件工具应满足下列要求：
– 必须有形式化的语法（可让计算机自动处理）
– 能够导出详细的文档
– 必须提供分析（测试）规格说明书的不一致
性和冗余性的手段，并能产生指明对完整性
分析结果的报告。
– 能够改进通信状况
下一页上一页 停止放映 第 43页
已有的需求分析的软件工具
? RSL（ Request Statement Language）需求陈述语言 ；
其语句是计算机可以处理的，并将处理结果集中存放在
ASSM（抽象系统语义模型）的 DB中。 1977年。
? PSL/PSA (Problem Statement Language /Problem
Statement Analysis System)问题陈述语言 /问题陈述
分析程序系统 。它是 CADSAT（计算机辅助设计和规格说
明分析工具）的一部分。 PSL是用来描述系统的形式语
言,PSA是处理 PSL描述的分析程序。 1997年。
? PSL/PSA有 4种主要功能：
– 描述任何应用领域的信息系统
– 创建一个 DB保存对该信息系统的描述符
– 对描述符可执行增、删、改等操作
– 产生格式化文档及规格说明书的各种分析报告
? PSL/PSA的主要优点是改进了文档质量、使之具有完整
性、一致性和无二义性，从而减少管理维护费用。
下一页上一页 停止放映 第 44页
超高级语言和第 4代语言
? 超高级语言的语句功能很强，用少数语句就可以实现一个系统。但这种
语言需要的系统资源开销也大。
? APL 是一种处理矩阵运算的、功能强大的超高级语言。 它非常简洁，
用它书写程序所化时间很少。用它来开发一个原型系统所需要的时间通
常只相当于实现最终系统所用时间的一小部分。但这类语言不适合用来
写大型系统（语法结构不易读）。
? Shell 是 UNIX系统的命令解释语言,在 Shell中可以使用 UNIXOS的所
有命令。如果开发的系统中使用的基本数据是正文行和文件，适合用
Shell描述算法。用 Shell语言开发适于用该种语言书写的程序时，所需
的成本比用普通 PL开发时低得多。
? PROLOG 是 开发原型系统使用最普遍的语言,具有极强的知识表达、推
理和查询功能，在表达知识和快速建立软件原型方面具有明显优势 。它
只有事实、规则和询问三种语句，语法比其它 PL简单，又具有交互性，
使用十分方便。但它表达算法类知识的能力较弱，不善于解决计算问题；
效率较低。
? 第 4代语言具有非过程性、交互性、可视性、智能化缺省设置、易使用、
高生产率、易调试、易维护,OO及基于 DBMS等，是快速构造软件原
型的高效软件工具。
下一页上一页 停止放映 第 45页
6、结构分析方法 (SA方法 )
? 结构化分析方法的背景 (形成 )
– 早期 无系统分析方法 (凭经验 )
– 60年代 美国的科学家提出一种理论,
SP SD SA
– 目前 研究的新热点是,
OOP OOD OOA
即面向对象的程序设计技术 (OO-Object
Oriented )
下一页上一页 停止放映 第 46页
SA的一般步骤
1,建立当前系统的物理模型 即理解并描述当前系统是怎样
进行工作的 。 通过调研, 了解把当前系统的业务工作流
程 （ 看到的, 听到的, 收集到的信息 ） 用流程图的形式
描述出来 。
2,建立当前系统的逻辑模型 逻辑模型是指系统的功能模型,
反映了数据处理系统的本质 。 对物理模型进行分析, 区
别本质因素和非本质因素, 去掉非本质因素, 就成为逻
辑模型 （ 本质因素是固有的, 不依赖于环境变化而变化
的因素 ） 。
3,建立目标系统的逻辑模型 这是 SA方法实质性的一步,
是 SA的最终目标 。 目标系统是指将来由计算机处理的
软件系统, 它是在分析当前系统逻辑模型与目标系统逻
辑模型的差别基础上建立起来的 。
下一页上一页 停止放映 第 47页
SA的基本特点：分析与抽象
? 采用用户容易理解的图形工具
? 从全局认识系统,采用自顶向下,逐级分析的方式
销售 MIS
销售 MIS
经营 库存 财务
1）
2）
3） 销售 MIS
经营 库存 财务
市
场
分
析
统
计
分
析
客
户
档
案
盘
点
结
存
订
货
管
理
工
资
核
算
采
购
计
划
工
资
核
算
成
本
核
算
面向用户,强调逻辑而非实现 (在该阶段,不考虑系统的实现问题 )
以获取分离数据和加工为动机 (这点很重要 )。
下一页上一页 停止放映 第 48页
三、系统设计（软件的设计）
? 系统设计概述
– 目标和任务
– 设计方法和步骤
– 文档
– 设计复审
下一页上一页 停止放映 第 49页
软件设计流程图
概要设计 复审要求说明书
软件
结构 可接收 详细设计
模块
描述
设计
说明书
复审
修改 修改
下一页上一页 停止放映 第 50页
1、软件设计概述
? （ 1）目标和任务
– 任务 依据分析结果, 明确系统, 如何
做？,, 建立实现方案 。
– 目标 提高软件系统的：
?可维护性, 可扩充, 可修改
?可理解性, 对软件人员要易读易理解；
对用户要易使用, 易维护
?可靠性, 包括正确性和健壮性
下一页上一页 停止放映 第 51页
（ 2）设计方法和步骤
? 概要设计
定义系统的逻辑结构, 包括：系统的模
块划分, 建立模块的层次结构, 逻辑关
系, 设计全局 DS及 DB；
? 详细设计
根据每个模块的功能描述, 设计模块内
部的实现算法, 模块所需要的局部数据
结构 。
下一页上一页 停止放映 第 52页
设计方法和步骤 ——设计方法：
? 概要设计方法
早期,模块化方法, 功能分解法；
典型,面向数据流, 面向数据结构 （ SP） 的
设计方法
近期,面向对象 （ OO） 的设计方法
SD(面向数据流的方法 )；
Jackson(JSD),Warnier(LCP)(面向数据结构的方法 )
? 详细设计方法
主要是结构化程序设计方法
? 详细设计的表示工具
图形工具, 程序流程图, 程序分析图 （ PAD） 和 NS图
语言工具, 伪码和程序设计语言 （ PDL）
下一页上一页 停止放映 第 53页
（ 3）软件设计原则
? 软件设计的重要性表现在软件的质量 。 如何设计才能
保证质量？ 一般原则：
1) 要有分层的组织结构, 便于对软件各个构件进行控制；
2) 应形成具有独立功能特征的模块 （ 模块化 ）
3) 应有性质不同, 可区分的数据和过程描述 （ 表达式 ）
4) 应使模块间和与外部环境间接口的复杂性尽量地减小
5) 应利用软件需求分析中得到的信息和可重复的方法 。
? 要想得到一个满意的设计结果, 不光要有基本设计原
则的指导, 还要有系统化的设计方法和科学严格的评
审机制相结合才能达到预想的目的 。
下一页上一页 停止放映 第 54页
（ 4）、软件设计准则
? 如何度量软件设计的标准, 计算机业界
对该问题还处于初期认识阶段 。
? 不分模块的程序是无法理解, 管理和维
护的程序 。 凡是使用计算机编程的人均
自觉不自觉地将程序划分为模块 。 但有
这样一个实际问题, 一个系统到底划分
为多少个模块好呢？
? 如何度量模块化的程度呢？
下一页上一页 停止放映 第 55页
经典设计准则
– 软件结构准则
– 模块化准则
– 模块独立性准则
– 模块的耦合性
– 模块的内聚性
下一页上一页 停止放映 第 56页
软件结构准则
? （ 1） 结构形态准则 好的软件结构应具有 倒置水缸形 ；
? 顶部宽度最小, 中间宽度最大, 底部宽度小于中间宽度 。
? 在顶部有较高的扇出数 （ 一个模块直接下属的子模块
数 ）,
? 在底部有较高的扇入数 （ 模块的直接上属模块的个数 ） 。
? （ 2） 判断的影响范围应该是控制范围的一个子集
影响范围 指在一个模块中有一个判别条件, 所有受该判
别条件影响的模块的集合称为影响范围；
控制范围 指一个模块本身及所有下属模块构成的集合 。
不满足该准则时的处理方法,就将判别条件移到上属模
块中去, 使其影响范围在控制范围内, 或者将受影响的
模块移入控制范围内 。
下一页上一页 停止放映 第 57页
结构形态准则示意图
深
度
宽度
扇出
扇入
下一页上一页 停止放映 第 58页
控制、影响范围示意图
? B模块的控制范围是 B、
D,E,F,G,H；
? 假设 E中有一个判别条件,
受其影响的模块有 F,G,H，
则 E的影响范围是 F,G,H。
M
E
A B C
D
F G H
下一页上一页 停止放映 第 59页
模块化准则
? 设 C(X） 是关于问题 X的复杂性, E(X） 是完成问题 X的工
作量, 有两个问题 P1和 P2：
若 C(P1） > C(P2),(即 P1比 P2复杂 )
E(P1) > E(P2),(即 P1比 P2用的工作量多 )
而 C(P1+P2) > C(P1) + C(P2),
(即组合问题比单个问题复杂 )
则 E(P1+P2) > E(P1) + E(P2)
(组合问题的工作量大于单个问题的工作量之和 )
? 这说明, 软件分解为若个模块后,则总的工作量减少,
但并不是说, 模块分解的越多, 工作量就一定越少 。 因
为分解到一定程度后, 模块之间的接口工作量就上升,
从而使总的代价上升 。
下一页上一页 停止放映 第 60页
模块化准则示意图
代价
模块数
模块代价
接口代价
总代价
M
下一页上一页 停止放映 第 61页
模块化准则讨论
? 软件系统模块化数目存在一个最佳值 M。
? 根据心理学研究表明, 一个模块的语句
数量以 30~50句为宜 （ 在一张打印纸上可
完整地输出 ） 。
? 模块太大, 难于阅读和理解；编程和测
试的效率也不高 。
? 模块太小, 又会使系统过于零碎, 接口
的工作量增加 。
下一页上一页 停止放映 第 62页
模块独立性准则
? 模块独立性,是指开发具有功能专一、模块之间
无过多相互作用的模块。
? 具有独立性的模块，开发容易、能减少错误的传
播，使模块重组、分解方便，容易调试和维护。
? 度量模块的独立性标准：
– 内聚性 模块内部各部分之间联系紧密程度的
度量；
– 藕合性 模块之间联系紧密程度的度量。
– 显然,独立性强的模块，耦合性越小越好，内
聚性越大越好。
下一页上一页 停止放映 第 63页
模块的藕合性及其分类
? 无直接藕合 模块之间无调用关系
? 数据藕合 通过参数调用在模块之间传递简单数据 。
传递参数可以是,加工的数据或控制用数据
（ 这是推荐和常用的藕合方法 ）
? 标记藕合 通过参数传递一种数据结构值 。
? 控制藕合 通过参数传递逻辑变量，起控制作用
? 外部藕合 指模块受软件的外部环境的约束 。
? 内容藕合 指一个模块使用另一个模块状内的数据或
控制信息；或直接转移到另一个模块的内
部 。
? 公用藕合 几个模块公用一个全程数据区；这种问题就
比较复杂 。 如果是动态并发程序, 情况就更复杂了 。 不光是
模块间数据引用的冲突问题, 还有时间差数据变更问题 。
低藕合，
经常被
采用
中等藕合
高藕合
下一页上一页 停止放映 第 64页
关于耦合的讨论
? 设计时应：
– 尽量使用数据耦合,
– 少用控制耦合,
– 限制公用耦合的范围,
– 完全不用内容耦合 。
下一页上一页 停止放映 第 65页
内聚性问题
? 一个程序主要由两部分组成：数据和对数据的
加工处理 。
? 内聚性,是指一个模块内部各种数据和各种处
理之间联系的紧密程度 。
? 它 是 模块执行任务的整体统一性的度量, 是模
块相对功能强弱的度量 。
? 在 理想的系统 中, 每个模块执行一个明确, 单
一的任务 。 但现实情况是一个模块往往执行若
干个结合在一起的任务, 这些任务组合方式不
同就构成不同的内聚性 。
下一页上一页 停止放映 第 66页
内聚性分类：
? 共存内聚 几个无关的任务组合在一起
? 逻辑内聚 将几个逻辑上相关的任务组合在一起
? 时态 （ 时间 ） 内聚 将在某一时刻同时要执行的
任务组合在一起
? 过程内聚 指几个相关联的任务组合在一起
? 通讯内聚 指在同一 DS上进行操作的几个任务
组合在一起
? 顺序内聚 指模块的几个任务总是前者的输出即为
后者的输入, 表现出按一定顺序执行 。
? 功能内聚 指模块只包含完成单一功能的任务 。
弱
强
下一页上一页 停止放映 第 67页
内聚性问题的讨论
? 从使用角度分析, 能否用一个短句完
整地描述该模块做什么；若这个短句
是复合句, 或有若干个动词, 则该模
块是非功能性模块 。
? 在设计时, 尽量采用功能性模块 。
下一页上一页 停止放映 第 68页
（ 5）文档资料
? 设计阶段要交付的文档是设计说明书 。 它可对编程和测
试提供指南服务, 还可在系统交付使用后, 为维护人员
提供帮助 。 内容包括：
– 概述 描述设计工作总的范围；系统目标, 功能, 接
口等；
– 系统结构 包括：系统的模块划分, 每个模块的功
能简介, 各个模块之间的逻辑关系；
– DS及 DB设计 用图表把设计结果描述出来；
– 接口设计 包括：人机界面设计, 软, 硬件之间的
接口设计, 本系统与外界以及与支持软件之间的接口
关系；
– 模块设计 根据模块的功能, 用相应的工具描述每
个模块的流程, 以及每个模块用到的数据结构 。
下一页上一页 停止放映 第 69页
2、概要设计
? 概要设计,是为软件系统定义一个逻辑上一致
的结构：进行模块划分，建立模块层次结构、
调用关系，设计全局数据结构及数据库，设计
系统接口及人机界面等。
? 概要设计的方法有许多种,
– 在早期有 模块化方法,功能分解方法，这都
是人们一般常用的方法；
– 在 60年代后期提出了 面向数据流的设计方法,
面向数据结构的设计方法；
– 近年来又提出 面向对象的设计方法 等。
下一页上一页 停止放映 第 70页
概要设计主要步骤
1）精细化数据流程图，确定数据流程
图的类型；
2）指出各种信息流的流界；
3）将数据流程图映射为软件结构；
4）精细化软件结构；
5）开发接口描述和全程数据描述。
下一页上一页 停止放映 第 71页
数据流程图分类
? 变换流, 事务流
? 变换流
加工
中心输入加工
输出
加工
输入 输出
内部
结果
内部
数据
输入流 输出流变换流
加工结果
下一页上一页 停止放映 第 72页
事物流
事物
中心
T
数据流
事物中心
t1
t2
t3
t4
事物路径
事物流
一个数据流经过某个加工后，有若干个平行的数据流
流出，将这种变换称为事物流。
?当事物流中的
事物流到事物
中心后，事物
中心分析每个
事物，确定其
类型；并根据
事物类型选择
一个事物路径
继续进行处理。
下一页上一页 停止放映 第 73页
设计过程
流 类型？
区分事物中心和
数据接受路径
区分输入和
输出分支
”事物,”变换“
映射成事物结构 映射成变换结构
用启发式设计规则精化软件结构
导出接口描述和
全程数据结构
详细设计
下一页上一页 停止放映 第 74页
变换分析技术
? 变换分析技术是从典型的变换型数据流程
图 （ DFD） 中推导出相应的结构图 。
? 变换分析是一组设计步骤, 可把 DFD映射
为一种标准结构 。 有了标准结构, 再根据
软件结构度量, 模块化度量, 模块独立性
度量来精细改善结构图, 从而得到良好的
软件结构 。
? （ 变换流的变换分析 ）
下一页上一页 停止放映 第 75页
变换分析的步骤
? 确定 DFD及其类型
? 确定输入流, 中心加工, 输出流的流界；
? 第一级分解；设计上层模块；
? 第二级分解, 设计中, 下层模块；
? 进一步精细化 。
下一页上一页 停止放映 第 76页
举例 ——设计汽车仪表盘
? 设计一个, 智能, 产品 —— 汽车数字仪表盘,
实现的功能为：
– 通过模 -数转换实现传感器和微处理器的接
口；
– 在发光二级管面板上显示数据；
– 指示 mph（ 每小时英里数 ）, 行驶里程, 每
加仑汽油行驶的英里数 （ mpg） 等；
– 指示加速 |减速
– 超速警告；车速超过 55英里 /小时, 则发出
超速警告铃声 。
下一页上一页 停止放映 第 77页
汽车数字仪表系统的 DFD
旋转
信号 读旋
转信号
信号 /秒
SPS
读旋和
求均值
燃料流
信号 读和
校对
燃料流 计算
gph
转换为
转 /分
rpm
SPS rpm mph计算
mph和
超速值
mph
显示
产生
mph
显示
gph mpg mpg
显示
计算
燃料
消耗
产生
mpg
显示
mph
SPS rpm 超速值
发出
铃声
铃声
产生
里程
里程
计算
里程
英里
确定加
减速
产生加
减速显
示箭头
指示
水平线
下箭头
上箭头
输入流
变换流
输出流?SPS
下一页上一页 停止放映 第 78页
设计步骤（一）
? 第 1步,确定 DFD及其类型 。
认真分析 DFD,可知有 2个输入流 （ 旋转信号, 燃料流
传感器信号 ）, 5个输出流 （ 加, 减速显示, 里程显
示, 发出铃声, mph显示, mpg显示 ）, 输出流显然是
把输入流经计算而产生的 。 由此可见, 这是一个典型
的变换流类型 。
– rpm 每分钟转数
– gph 每小时加仑数
– mph 每小时英里数
– mpg 每加仑英里数
下一页上一页 停止放映 第 79页
设计步骤（二）
? 确定流界 （ 输入流, 变换流和输出流 ）
– 输入流 读旋转信号, 收集求和平均值,
转换成 rpm,读和校对, 计算 gph
– 变换流 确定加, 减速度, 计算里程,
计算 mph和超速值, 计算燃料消耗
– 输出流 产生加, 减速显示, 里程显示,
发出铃声, 产生 mph和 mpg显示
下一页上一页 停止放映 第 80页
设计步骤（三）
? 第 1级分解, 产生顶层模块
第 1级分解过程实际上是对 DFD自顶向下的控制进行分
配 。 DFD被映射为一个特殊的软件结构：输入控制,
变换控制和输出控制, 再人为地为它们加一个主控
模块 。 再根据实际问题为每个模块命名 。
Cm
Ci Ct Co
数字仪表板
控制系统
接收传感
器信号
数据转换
控制
驱动仪表
板面
下一页上一页 停止放映 第 81页
设计步骤（四）
? 第 2级分解，建立中下层模块
由顶向下，逐步精细，设计中、下层模块。
– 为每个逻辑输入设计一个输入模块,向上属模块提
供输入信息； 而该模块又需要两个下属模块，分别
称为, 取模块, 和, 转换模块, 。沿每条逻辑输入
分支，按此办法一直分解到物理输入为止。
– 同理为每一个逻辑输出设计一个输出模块,它要输
出上属模块送来的信息,而该模块又需要两个下属
模块；一个转换送来的信息，另一个把转换的信息
送走。
– 转换模块的设计无规律性，一般可根据中心加工的
子加工来建立模块。
下一页上一页 停止放映 第 82页
第 2级分解举例
? 将数字仪表盘控制系统继续分解：
读旋转信号
接收传感器
信号rpm
sps
sps 收集 sps
转换成 rpm
信号均值
信号 /秒
计算 gph
读燃料流
燃烧流 计算 mph
数字转换
控制?sps
确定加减速
里程
计算里程
计算 mpg
rpm
箭头
指示
rpm mph
mpg
mph
gph
gph
变换处理输入模块
下一页上一页 停止放映 第 83页
第 2级分解举例（续）
? 输出模块
驱动仪表盘
加减速显示 显示里程显示 mph 发出铃声
发光二极管显示
显示 mpg
下一页上一页 停止放映 第 84页
设计步骤（五）
? 进一步精化
数字仪表板
控制系统
发出
铃声
计算
里程
显示
mph
显示
mpg
显示
里程
显示
加减速 发光二极管显示
精化后的数字仪表盘
系统的软件结构
驱动仪表板面数据转换控制
读旋转
信号
计算
gph
计算
mph
计算
mpg
确定加减速
读燃料
流
接收传感器信号
转换成
rpm
下一页上一页 停止放映 第 85页
事务分析技术
? 事务分析技术也是 将相应的数据流程图
（ DFD） 映射为对应的的软件结构图 。
? 事务分析的组设计步骤同变换分析,
– 确定数据流图的类型
– 确定流界
– 第 1级分解
– 第 2级分解
– 设计后处理
下一页上一页 停止放映 第 86页
3、详细设计方法
? 详细设计的概念,是根据每个模块的功能设计其逻辑描
述, 实现算法以及实现这些算法的逻辑控制流程, 并设
计这些模块所需的局部数据结构 。
? 详细设计的方法,主要是用结构程序设计 SP方法,
? 详细设计的表示工具,有图形工具和语言工具 。
? 图 形 工 具, 有 程 序 流 程 图 (p296),PAD（ Problem
Analysis Diagram） 图, NS（ 由 Nassi和 Shneidermen
开发 ） 图,
? 语 言 工具,有 伪码 和过 程设 计 语言 PDL（ Program
Design Language） 等 。
下一页上一页 停止放映 第 87页
SP中的基本结构
? 顺序结构
? 选择结构
– IF THEN ELSE 结构
– IF THEN 结构
– IF OR IF ELSE 结构
– CASE 结构
? 重复结构
– 当型结构
– 直到型结构
? 出口结构
? 可用判定表, 判定树表示
下一页上一页 停止放映 第 88页
N-S图（盒图）
下一页上一页 停止放映 第 89页
PAD图
下一页上一页 停止放映 第 90页
SP中的优点
? 自顶向下, 逐步求精方法符合人们解决复杂问题的普遍
规律 ；抽象, 分解, 找出关键问题所在 。 将重点, 技术
难点找出来, 便于精确描述和求解 。 模块化设计便于协
同开发, 因而 可以显著提高软件系统的成功率和生产率 。
? 用先全局后局部, 先整体后细节, 先抽象后具体的逐步
求精过程开发的程序有清晰的层次结构, 容易理解和阅
读 。 采用划整为零的开发技术, 便于各层次人员发挥各
自的创造性劳动 。
? 不使用 GOTO语句, 使程序静态结构和程序动态执行情况
一致, 容易理解和阅读, 开发出的程序容易修改和维护 。
? 程序只采用三种基本结构, 有确定的逻辑结构, 可读性
好 。
? 共用模块可重用 。
下一页上一页 停止放映 第 91页
SP中的缺点
? SP方法的模块化设计的子程序, 函数的 可重用性很小 。 可
重用的只是一些标准库函数或基于某个 OS的 I/O函数 。 其
它模块的可重用性很小 。
? 数据和过程的分离 。 程序员在编程时必须随时考虑要处理
的数据的格式：
– 不同格式的数据, 即使做相同的处理, 也要编写不同
的代码；
– 数据格式一样, 但处理不同, 也要用不同的代码；
– 相容性问题 。 当程序和数据相对独立时, 程序员要始
终考虑保持程序和数据的一致性 （ 用错误数据调用正
确的程序, 或用正确的数据调用错误的程序 ）, 这已
成为程序员的沉重负担 。
? 这些问题都是 SP方法本身解决不了的 。
下一页上一页 停止放映 第 92页
四、程序编码
? 程序设计语言的特点
? 选择语言
? 写程序的风格
? 程序设计方法论
下一页上一页 停止放映 第 93页
1.程序设计语言的特点
? 软件工程师应该了解程序设计语言各方面的特点,
以及这些特点对软件质量的影响, 以便在一个特定
的开发项目选择语言时, 能够作出合理的选择 。
? 程序设计语言的特点是,
– 名字说明
– 类型说明
– 初始化
– 程序对象的局部性
– 程序模块
– 循环控制结构
– 分支控制结构
– 异常处理
– 独立编译
下一页上一页 停止放映 第 94页
程序设计语言的特点（一）
? 名字说明 预先说明程序中使用的变量名, 这是许多编译系
统所要求的, 目的是检查变量名的合法性, 使错误能消除在
语义, 语法检查阶段 。
? 类型说明 用于定义对象在计算机中的存储单元的长度 。 确
定了类型也就确定了该对象的使用方式 。 编译系统能发现程
序中对某个特定类型的对象使用不当的错误, 有助于减少程
序错误 。
? 初始化 变量在没使用前是何种状态 （ 值 ）, 在不同语言中
是不确定的 。 因此, 在使用前进行必要的初始化处理, 以减
少发生的可能性 。
? 程序对象的局部性 提倡使用 局部变量, 这不仅有助于提
高可读性, 而且有助于减少差错和提高程序的可修改性 。
下一页上一页 停止放映 第 95页
程序设计语言的特点（二）
? 程序模块 为了控制程序对象名字的可见性, 一些块结构语言
提供了保护控制机制：
类程 （ CLASS） SIMULA语言 段 （ Segment） ALGOL60 语言
模块 （ Module） Modula语言 包 （ Package） Ada语言
这些保护机制有些很好的特性, 例如 Ada语言中的, 包,, 可用来
构造抽象数据类型等, 因此, 这类语言适合于较大型软件工程项
目 。
? 循环控制结构 常见的循环结构有三种,FOR 循环, WHILE… 循
环, REPEAT … UNTIL循环 ;在实际应用中, 往往在循环体内加设
测试循环结束条件, 以便决定是否继续循环 。 为此, 有些语言中
增加了诸如,exit,break,loop,escape等语句, 改善了程序
结构的可读性 。
下一页上一页 停止放映 第 96页
程序设计语言的特点（三）
? 分支控制结构 主要是 CASE结构容易出现两类问题,
– 若 CASE表达式取值在指定范围之外, 则不能确定执行
何种操作；
– 由 CASE表达式选定执行的语句, 有选择排序的问题；
如果排序有错, 编译和运行时检查不出来, 而发生逻
辑错误 。
– 有些语言做了相应的处理, 例如, C中增加了 default
语句 。
? 异常处理 大多数语言没有提供检测和处理异常情况的有
效帮助机制 。 一旦发生异常, 只能通过调试手段去追踪,
解决 。 而有些语言 （ 例如 PL/1,Ada） 则考虑了异常情况
的处理问题 。
? 独立编译 便于程序的开发和调试, 提高开发, 维护效率 。
下一页上一页 停止放映 第 97页
2.选择语言
? 开发软件系统时必须根据实际情况选择使用的程序
设计语言 。
? 程序设计语言分, 汇编语言, 和, 高级语言, ； 汇
编语言 的程序执行效率高, 但生产效率低； 高级语
言 的程序执行效率不如汇编语言, 但编程效率则要
高得多, 同时还有可读性, 可维护性好等优点 。
? 因此, 除了在一些特殊应用领域 （ 例如, 对程序执
行时间, 存储空间都有很严格限制的情况；需要产
生任意的, 甚至非法的指令序列等 ） 之外, 其他程
序一律使用高级语言编程 。
? 选择语言时, 不仅要考虑理论上的标准, 还必须同
时考虑使用方面的各种限制 。
下一页上一页 停止放映 第 98页
选择语言的重要实用标准（一）
? 系统用户的要求 使用用户熟悉的语言, 因为系统要由用户
自己来维护 。
? 可以使用的编译程序 运行目标系统的环境中可以提供的编
译程序, 往往限制了可选用语言的范围 。 例如, 在 MS-DOS下,
就不能使用 Visual C++语言 。
? 可以得到的软件工具 好的开发工具, 将有利于系统的实现
和验证 。
? 工程规模 对规模庞大的工程而言, 若没有完全合适的程序
设计语言, 则专为本工程设计一种专用语言也是值得的 。
? 程序员知识 学习和掌握一门语言是两个完全不同的标准,
应尽可能选用程序员熟悉的语言 。
? 软件可移植性要求 若目标系统将在几个不同大环境下运行,
或使用寿命很长的话, 应该选择标准化程度高, 可移植性好
的语言 。
下一页上一页 停止放映 第 99页
选择语言的重要实用标准（二）
? 软件的应用领域 选择语言时应充分考虑目标系
统的应用范围：
FORTRAN 科学计算首选语言
COBOL 适合于商业应用
C和 Ada 适合于系统和实时应用
LISP 适合于组合问题的应用
PROLOG 适合于表达知识和推理应用
做什么事, 用什么工具
下一页上一页 停止放映 第 100页
3.写程序的风格
? 定义,指程序员在编程时所表现出来的特点,
逻辑思路, 结构等 。
? 可以体现在下列各个方面,
– 源代码文件 （ 程序内部的文档 ）
– 数据说明
– 语句构造
– 输入 |输出
– 提高程序质量的技巧
– 效率
– 例如：写出 10中好的程序编码风格
下一页上一页 停止放映 第 101页
源代码文件（程序内部的文档）
? 包括程序中使用的标识符, 适当的注释以及程序
的视觉组织 。
? 标识符 命名要有一定的规则；用拼音或英文字符 。
? 注释行 通常在源程序中用大量篇幅 （ 最多占到
1/3） 加入注释行, 在开发者和读者间进行钩通,
说明程序的功能, 标识符的含义, 主要算法等 。
特别在维护阶段, 对理解程序提供了指导 。
? 程序书写格式 各控制结构的层次应呈锯齿形, 同
一层次对齐, 下一层退缩几格 。
下一页上一页 停止放映 第 102页
数据说明
? 为使数据定义更容易看懂, 更容易维护, 要建立一
些指导原则：
– 数据说明顺序标准化, 最好按照类型说明, 公用
变量, 局部变量, 文件说明的顺序 ；
– 一个语句说明若干个变量时, 名字最好按字典排
序；
– 对复杂的 DS,要加注释, 说明固有特性 。
下一页上一页 停止放映 第 103页
语句构造
? 语句构造的原则是：
– 简单直接 不应追求效率而使代码复杂化；
– 为了便于阅读和理解, 不要一行写多个语句,
不同层次的语句应呈锯齿形；
– 不用复杂的测试条件, 不用或少用, 非条件, ；
– 避免使用大量嵌套循环及条件循环；
– 使用条件来简化表达式 。
下一页上一页 停止放映 第 104页
输入 /输出
? 在编码时要考虑下列 I/O风格的规则：
– 对所有的输入数据进行 检验
– 检查重要的输入项组合的 合法性
– 保持输入 格式的简单
– 使用数据 结束标记, 不要要求用户指定数据的数目
– 明确提示 交互式输入的请求, 详细说明可用的选择
或边界数值；
– 当程序设计语言对格式有严格要求时, 保持输入 格
式一致
– 设计良好的输出 报表
– 给所有的输出加标志
下一页上一页 停止放映 第 105页
提高程序质量的技巧
? B.Kernighan和 P.Plauger在, 编程风格要点,
一书中讨论了 提高程序质量的种种技巧,
– 避免使用过于相似的变量名
– 变量名中尽量不含数字
– 同一变量名不要具有多种意义
– 显式说明所有变量
– 注意浮点运算的误差
– 注意整数运算的特点
– 避免不必要的 GOTO语句
– 尽量少用语句标号
下一页上一页 停止放映 第 106页
效率
? 程序运行时间 源程序的效率由算法的效率决定, 但写程序
的风格也能对程序的执行速度和存储器要求产生影响, 可应
用下述规则, （ 语句, 变量类型, 数组 ）
– 写程序前先简化算术和逻辑表达式
– 尽量避免使用多维数组, 尽量避免使用指针和复杂的表
– 使用时间短的算术运算
– 不要混合使用不同的数据类型
– 尽量使用整数运算和布尔表达式
? 存储器效率 提高存储器效率的 关键是, 简单,
? I/O效率 简单清晰是提高人 -机通信效率的关键, 应采用：
– 所有 I/O都应该有缓冲, 以减少用于通信的额外开销
– 对二级存储器 （ 磁盘 ） 应选用最简单的访问方法
– 二级存储器的 I/O应该以信息组为单位进行 。
下一页上一页 停止放映 第 107页
4.程序设计方法论
? 通常有两种方法：自顶向下和自底向上
– 自顶向下 （ 特点 ）,
? 程序可读性好
? 可靠性较高
– 自底向上 （ 特点 ）
? 程序往往局部是优化的, 系统整体结构较差；
? 可极早发现关键算法是否可行, 可较好地避免
较大的返工 。
下一页上一页 停止放映 第 108页
五,系统 测试
? 软件测试概述
? 测试用例的设计
? 测试实施方法
? 软件的调试
测试的目的是什么？
？ 成功的测试是什么？
下一页上一页 停止放映 第 109页
1.软件测试概述
? 测试的重要性 软件测试的重要性及其与可靠性
的密切联系怎样强调也不过分。这是一个典型
事例：在美国的一次飞往火星的火箭发射中，
因控制程序中的一个循环语句,DO 5 I=1,3”被
误认为是赋值语句,DO 5 I=1.3”,一点之差,使火
箭发生爆炸,损失一千万美元。
? 目的 发现软件中隐藏的各种差错。要纠正一种
错误的看法：认为“测试是为了说明程序没有
问题”。恰恰相反，没有找出错误的测试被认
为是失败的测试；而” 成功的测试是能够发现
隐藏的差错的测试“。
下一页上一页 停止放映 第 110 页
? 如果为了证实程序是正确的而进行测试, 就会设
计一些不易暴露错误的测试方案；
? 如果为了发现程序中的错误而进行测试, 就会力
求设计最能暴露错误的测试方案 。
? 结论 由于测试目标是为了找出程序中的错误, 因
此, 由程序设计者本人进行测试是不明智的 。 通
常, 测试分两个阶段 ；程序模块编好后, 程序员
本人对该程序进行必要的测试, 称为, 单元测
试,, 在整个系统都完成后, 由专职测试人员对
整个系统进行的测试称为, 系统综合测试, 。
测试心理学分析
下一页上一页 停止放映 第 111 页
? 测试 为了发现错误而执行程序的过程
? 调试 找出程序中的错误原因, 位置并加以纠正
? 可靠性 在给定时间内, 软件不发生错误的概率
? 黑盒测试法 不考虑程序的内部结构和处理过程
的测试, 也称为 功能测试, 数据驱动测试 。 只
检查程序功能是否满足系统功能和规格说明书
的要求, 不管内部如何处理和如何实现 。
? 白盒测试法 按程序的内部逻辑结构和处理过程
进行的测试, 称为 结构测试, 逻辑驱动测试 。
测试基本概念
下一页上一页 停止放映 第 112 页
2.测试用例
? 测试的关键问题是 如何设计测试用例；它的组成：
测试用例 = 指定功能 +测试数据 +预期效果
? 测试的基本原则,
1） 在执行程序前应该对期望的结果有明确的描述，
测试后应对输出进行仔细的检查。 （正确？）
2） 不仅要选择合理的输入数据作为测试用例，还应
选用 不合理的输入数据 作为测试用例。
3） 除了检查程序是否做了应做的工作之外，还应检
查程序 是否做了不应做的事 。
4） 应该长期 保留 所有的 测试用例,直到该系统被废
弃不用为止。
下一页上一页 停止放映 第 113 页
测试用例的设计
? 设计测试用例的 基本目标 是,确定一组最有可能发现某个
错误或某类错误的测试数据。
? 设计测试数据的技术有许多种 ；通常的做法是用黑盒法设
计基本的测试用例，再用白盒法设计一些补充用例。
? 测试方法,
? 逻辑覆盖
– 语句覆盖
– 判定覆盖
– 条件覆盖
– 判定 /条件覆盖
– 条件组合覆盖
? 等价类划分
? 边值分析
下一页上一页 停止放映 第 114 页
逻辑（路径）覆盖（白盒法）
? 按程序的内部逻辑结构进行测试，为了衡
量测试的覆盖程度，建立下列标准（从低
到高）：
– 语句覆盖,每个语句都至少执行一次
– 判定覆盖,对判别语句的每个分支至少要经过一次
– 条件覆盖,每个条件可能的值至少出现一次，及条
件表达式中各个条件取两个不同的值
– 判定 /条件覆盖,使判定的, 真,,, 假, 各执
行一次，还要使判定中每个条件取两种不同的值
– 条件组合覆盖,使每个判定中的条件的各种组合
都出现一次
下一页上一页 停止放映 第 115 页
举例
有一要测试的程序如下：
sub （ a, b，ｘ）
float a,b，ｘ；
{ float y;
if（ a>1 && b=0)
y=x/a;
if(a=2||x＞ 1）
ｘ＝ｘ＋１；
｝
结束
程序逻辑结构图
开始
a>1&&b=0？
a=2||x>1?
y=x/a
x=x+1
A
B
C
D
E
下一页上一页 停止放映 第 116 页
逻辑覆盖分析 ——语句覆盖
? 执行程序中的每个语句。为使程序中的
每个语句都至少执行一次,只需设计一
个通过路径ＡＣＥ的输入数据即可。选
择输入数据为：
ａ＝２，ｂ＝０，ｘ＝３
就可达到, 语句覆盖, 的标准。
下一页上一页 停止放映 第 117 页
逻辑覆盖分析 ——判定覆盖
? 对判别语句的每个分支至少要经过一次,为
达到, 判定覆盖, 的标准，则要经过路径：
Ａ CＤ和Ａ BＥ，为此，选用输入数据为：
ａ＝３，ｂ＝０，ｘ＝０，走ＡＣＤ路径
ａ＝２，ｂ＝１，ｘ＝３，走ＡＢＥ路径
? 判定覆盖比语句覆盖严格。但还比较弱，例
如,ABD路径就没走到。若把, X>1”错写成
,X<1”,还是检查不出来，它只有 50%的机会
去检查 X的值。
下一页上一页 停止放映 第 118 页
逻辑覆盖分析 ——条件覆盖
? 使判别中 每个条件可能的值至少出现一次，及条件表达式中各个
条件取两个不同的值 。
? 程序中有 4个条件, A>1,B=0,A=2,X>1
。为达到, 条件覆盖, 标准，需选用数据,使得
在 A点有 A>1,A<=1,B=0,B<>0
在 B点有 A=2,A<>2,X>1,X<=1
为此选择下列两组测试数据：
ａ＝２，ｂ＝０，ｘ＝４ 走ＡＣＥ路径
ａ＝１，ｂ＝１，ｘ＝１ 走ＡＢＤ路径
?, 条件覆盖, 比, 判定覆盖, 强,因为要使每个条件都取到两个不
同的结果,而判定覆盖不能保证这一点。
? 有时判定覆盖和条件覆盖不能互为包含。
下一页上一页 停止放映 第 119 页
逻辑覆盖分析 ——判别／条件覆盖
? 使判定的, 真,,, 假, 各执行一次，还要使判
定中每个条件取两种不同的值 。选择下列输入数
据可满足这一标准：
ａ＝２，ｂ＝０，ｘ＝４ 走ＡＣＥ路径
ａ＝１，ｂ＝１，ｘ＝１ 走ＡＢＤ路径
? 在含有 AND和 OR的逻辑表达式中,某些条件将抑制
其它条件 ;例如,表达式 A AND B,如果 A为假,则
就不再检查 B了。因此在实际应用中要设计更多
的用例来测试未走过、而可能隐藏错误的路径。
下一页上一页 停止放映 第 120页
逻辑覆盖分析 ——判别组合覆盖
? 使每个判定中的条件的各种组合都出现一次。 满足条件组合覆
盖的测试数据一定满足判定、条件、条件／判定覆盖。
? 各种可能的组合共有八种：
?ａ＞１，ｂ＝０ ? ａ＞１，ｂ＜＞０
?ａ＜＝１，ｂ＝０ ? Ａ＜＝１，ｂ＜＞０
? ａ＝２，ｘ＝１ ? ａ＝２，ｘ＜＝１
?ａ＜＞２，ｘ＞１ ? ａ＜＞２，ｘ＜＝１
? 下面４组测试数据可以覆盖上面８种条件组合：
ａ＝２，ｂ＝０，ｘ＝４ 覆盖 ? ?
ａ＝２，ｂ＝１，ｘ＝１ 覆盖 ? ?
ａ＝１，ｂ＝０，ｘ＝２ 覆盖 ? ?
ａ＝１，ｂ＝０，ｘ＝１ 覆盖 ? ?
注：这４组数据并
不能覆盖程序中的
每条路径，ａｃｄ
就没执行。说明条
件组合覆盖标准仍
不彻底。
下一页上一页 停止放映 第 121页
等价类划分（黑盒法）
? 把所有可能的输入数据（有效和无效）划分为若干个等价类，每
类中一个典型数据在测试中起的作用和这一类数据的作用是相同
的。因此，可以从每个等价类中只选取一组数据作为测试数据 。
? 使用等价类划分法首先要划分输入数据的等价类，确定输入数据
的有效等价类和无效等价类。
? 划分等价类需要经验，以下是一些启发性原则：
– 若输入条件规定了输入值的范围，则可能划分一个有效的等价
类和两个无效的等价类（小于 MIN或大于 MAX）；
– 如果规定输入数据必须遵循的规则，则可划分出一个有效的等
价类（符合规则）和若干个无效的等价类（不符合规则）。
– 若规定了输入数据为整型，则可划分出整数、零和负整数三个
有效等价类。
下一页上一页 停止放映 第 122页
等价类划分 （黑盒法）
? 例如，若规定输入数据为整数，等价类划分表为：
输入条件 有效等价类 无效等价类
整数 正整数
１到３２７６７
零 ０
负整数
－１到
－３２７６８
符合规则 不符合规则
正整数
大于３２７６７
零 非法 －０
负整数
小于－３２７６８
下一页上一页 停止放映 第 123页
边界值分析法
? 经验证明，在边界处，程序最容易出问题。例如，在下标、
数据结构、数组、循环等的边界附近。
? 使用 边值分析方法 设计测试用例首先应确定边界情况，这需
要经验和创造性。 选取测试数据应刚好等于、刚好小于和刚
好大于边界值。
? 有下列启发式规则：
– 若输入条件规定值的个数,则分别选取值的最大个数、
最小个数以及接近最大、最小的个数作为测试用例；
– 对输入条件规定有值的范围,则选用范围边界数及刚超
出范围的无效数作为测试用例；
– 若输入／输出是有序集,则注意第一个和最后一个；
– 对三角函数的自变量,注意特殊角度的值。
? 通常设计测试用例总是将等价法和边值法结合使用。
下一页上一页 停止放映 第 124页
3.测试实施方法
? 这里有两个基本概念：驱动模块和存根模块。
驱动模块 启动被测试模块的模块
存根模块 也称模拟子程序，用于代替被测试模块所
调用的模块。
? 模块测试 由程序设计人员在完成模块设计后自己进行的测
试。用于检验模块本身的错误。
? 组装测试 按设计要求将某个功能子系统的所有模块组装到
一起的测试，用于发现与接口有关的问题。
? 确认测试 以用户为主，使用实际业务数据进行有关测试。
用于发现系统需求分析、定义阶段的错误。
下一页上一页 停止放映 第 125页
模块测试
? 可先用白盒法测试模块的内部逻辑，再用黑盒法测
试外部预期的结果。程序交出后，由测试工程师再
以黑盒法为主进行测试。
? 模块测试 测试评价模块的下述特征,
?模块接口
?局部数据结构
?重要的执行通路
?出错处理通道
?影响上述各方面特征的边界条件
下一页上一页 停止放映 第 126页
组装测试
? 组装测试分为,渐增式 和 非渐增式 。
– 渐增式 逐渐将要测试的下一个模
块加进到已测试好的模块中进行的
测试。
– 非渐增式 先测试每个模块，再把
所有模块按设计要求组装在一起的
测试。
下一页上一页 停止放映 第 127页
组装测试两种方法的优缺点
? 称” 非渐增式“为Ａ方法,称” 渐增式“为Ｂ方法 。
?Ａ方法工作量大,Ｂ方法工作量较小 ；因为要编写
用于测试的驱动模块和存根模块。
?Ｂ可较早发现模块间的接口错误 ； 而Ａ则发现较晚；
?Ａ发现错误难于诊断定位 ；Ｂ则容易诊断错误的位
置 ；
?Ｂ可使已测试好的模块在新条件下接受新的测试，
这种测试更彻底。
?Ｂ占用较多的机器时间 ；
?Ａ可并行测试所有模块,因此可充分利用人力，加
速工程进度。
? 前４条是Ｂ的优点，后２条是Ｂ的缺点； Ｂ方法总
体较好。
下一页上一页 停止放映 第 128页
渐增方法的使用方式
? 自顶向下 从主控模块开始，沿软件控制层自上而下、
逐渐把各个模块组装到已测试结构中的一种方法。在
具体实施中可采用深度优先或广度优先策略。
? 自底向上 从底层模块开始测试和组装的一种策略。
? 优缺点分析,
自顶向下
– 优点, 不要驱动模块,能较早地实现并验证系统的
主要功能，较早的发现接口错误。
– 缺点, 需要存根模块,可能遇到与此相联系的测试
困难，底层关键模块中的错误发现较晚。
而 自底向上 方法的优缺点正好与自顶向下相反。
下一页上一页 停止放映 第 129页
确认测试
? 测试的目的,是验证系统是否能满足用户的需
要。
? 平行运行 即手工系统和计算机系统同时运行，
用对比的方法验证新系统的正确性。
下一页上一页 停止放映 第 130页
4.程序调试
? 程序调试的任务 经过测试暴露出问
题，还必须进一步 诊断错误的原因和
位置，进而改正程序中的错误 。
? 要讨论三方面的问题：
– 调试技术
– 调试策略
– 调试的启发性原则
下一页上一页 停止放映 第 131页
调试技术
? 输出存储器内容
特点：效率低、难定位、输出的是静止状
态的程序内容。
? 加打印语句
特点：显示的是程序的动态信息，大量的
输出，时间慢，可能引出新的问题。
? 用调试工具
特点：动态调试，可自动执行，是现代程
序调试的有效工具。
下一页上一页 停止放映 第 132页
调试策略
? 试探法 大概分析、估计错误的位置；
? 回溯法 确定最先出现”症状“的地方，然后
沿程序的控制流程往回追踪源程序，直到找出
错误源为止。
? 对分查找法 若已知程序中若干个关键点的正
确值，然后用调试工具在关键点附近处输入正
确值；若输出正确，则故障在前半部分；否则，
再查后半部分。
? 归纳法 从线索出发，通过分析线索之间的关
系而找出故障。主要步骤为：收集有关数据，
组织数据，导出假设，证明假设。
下一页上一页 停止放映 第 133页
调试的启发性原则
? 这部分内容，大多是心理学问题：
?要思考,不要盲目地修改程序，至使错误越
来越多； （动脑）
?如陷入困境,放到第２天去解决 ； （冷处理）
?陷入绝境后，要 与别人交谈你的问题,或许
对你有所启发； （交流）
?避免用试验法。 不要在问题没有搞清楚之前，
就改动程序,这样对找出错误不利，程序越改
越乱，以致于面目全非。 （慎重）
下一页上一页 停止放映 第 134页
六、软件维护
? 一个软件产品投入使用后, 通常由于各种理由
需要对它作适当的变更, 完全不变的情况是很
少见的 。 把软件交付使用后的变更称为维护 。
? 维护是软件生存周期最后一个阶段,由于维护工
作的重要性往往被人们忽视, 这更增加了维护
工作的困难 。 平均而言, 大型软件的维护成本
是开发成本的 4倍左右 。 国外许多软件开发组织
把 60%以上的人力用于维护已投入运行的软件 。
这个比例随着软件数量增多和使用寿命延长,
还在继续上升 。 学习软件工程学的主要目的之
一就是研究如何减少花费在软件维护上的工作
量, 降低维护成本 。
下一页上一页 停止放映 第 135页
1.维护活动的类型
（ 1） 校正性维护 。 把诊断, 校正软件错误的过程称之为
校正性维护 。 这部分维护工作约占全部维护活动的
17%～ 21%。 （ 改错 ）
（ 2） 适应性维护 。 由于计算机技术的飞速发展, 外部设
备和其他系统元素经常改进和变化, 为适应变化的环
境而修改软件的活动称之为适应性维护 。 它占总维护
活动的 18%～ 25%。 （ 环境 ）
（ 3） 完善性维护 。 指在使用软件系统的过程中为满足用
户提出的新功能和性能要求而进行的维护活动 。 它约
占总维护活动的 50%～ 60%。 （ 功能 ）
（ 4） 预防性维护 。 为进一步改进可维护性, 可靠性而进
行的维护活动, 约占 4%。 （ 防未然 ）
下一页上一页 停止放映 第 136页
2.维护的代价
? 70年代用于维护软件的费用只占软件总预算的
35%～ 40%,80年代上升为 40%～ 60%,到了 90年代
则上升为 70%～ 80%。
? 软件维护的代价包括 有形 和 无形 两个部分：有
形代价就是上面所提到的那些统计数字；无形代
价包括：
? 当看起来合理的有关变更要求不能及时满足时,
将引起用户的不满；
? 由于维护时的改动, 在软件中引入潜在的故障,
从而降低了软件的质量；
? 当必须把软件开发工程师调去从事维护工作时,
对开发过程造成的影响 。
下一页上一页 停止放映 第 137页
3.维护问题（困难）
（ 1） 理解别人写的程序通常非常困难, 而且困难程度随
着软件配置成分的减少而迅速增加 。 如果仅有源程序代
码而没有说明文档, 问题会更加严重 。
（ 2） 严格按规范化方法开发的软件系统一般不需要大的
维护活动, 而需要维护的软件系统却往往因为没有必需
的文档或 文档残缺不全, 使得维护活动进展非常艰难 。
（ 3） 当需要对软件进行维护时, 很难指望熟悉软件系统
的原开发人员能全力以赴地亲临现场参与维护活动 。
（ 4） 绝大多数软件在 设计时没有考虑将来的修改 。
（ 5） 软件维护不是一项吸引人的工作 。 最出色的, 成功
的维护也只不过是保证他人开发的系统的正常运行, 而
且维护别人开发的软件经常受挫, 使得维护人员无成就
感 。
下一页上一页 停止放映 第 138页
4.软件的可维护性
? 软件可维护性的 定义：维护人员理解, 修改
该软件的难易程度 。
软件生存周期每个阶段的工作都和软件的可维
护性有密切的关系, 实际上, 软件的可维护
性是软件开发各个阶段的关键目标 。
? 软件的可维护性,
– 可维护性因素
– 提高可维护性方法
– 文档
下一页上一页 停止放映 第 139页
(1)可维护性因素
（ 1） 可理解性 。表明维护人员通过阅读源代码程序和有关文档，了解
程序功能、内部逻辑结构、数据结构，以及模块间接口等的难易程
度。按 SA,SD和 SP技术开发的软件，具有模块化、详细的设计文档
等结构化特征，从而使软件具有较好的可理解性。
（ 2） 可测试性 。是诊断和测试的难易程度的度量。软件结构设计合理，
模块具有高内聚性和低耦合性，模块内部算法简单，就可以提高软
件的可测试性。
（ 3） 可修改性 。表明软件容易修改的程度。一个可修改的软件应当是
可理解的、通用的、简单的软件。耦合性、内聚性等都影响软件的
可修改性。
（ 4） 可靠性 。表明在规定条件、时间内，软件不引起系统失效的 概率。
软件可靠性的度量标准主要有：平均失效间隔时间、平均修复时间
和有效性。
（ 5） 可使用性 。从用户观点出发，度量软件使用方便与否的 难易程度 。
一个可使用的程序应该是容易操作、用户按操作手册指导应能排除
因操作失误造成后果的程序。
下一页上一页 停止放映 第 140页
(2)提高可维护性的方法
? 软件生存周期每个阶段的工作都和软件
可维护性有密切的关系 。 提高软件的可
维护性必须从软件生存周期各个阶段的
工作入手 。
下一页上一页 停止放映 第 141页
（ a）问题定义阶段
? 为得到可维护的系统模型，就要 使开发人
员、用户和使用单位管理人员 对问题的性
质、工程的目标和规模 取得完全一致的看
法 。考虑到开始时，双方对要求解的问题
相互不太了解，这就要求系统必须是易于
扩充、完善的系统。
下一页上一页 停止放映 第 142页
（ b）可性行研究阶段
? 可行性研究实质上是在高层以抽象方式进
行的系统分析和设计的过程。该过程必然
会对未来系统的可维护性产生巨大影响。
这是因为：
① 被推荐的系统是已经实现的、经过实用检
验的系统，具有较好的可维护性；
② 选用的技术是成熟的技术，同时要求这些
技术要有较强的维护手段。
下一页上一页 停止放映 第 143页
（ c）需求分析阶段
? 该阶段的任务是准确地描述系统, 做什
么, 。同时，还要确定系统的运行环境，
要考虑系统将来可能的变化，对系统的可
扩充性和可修改性预先做好准备,从而提
高系统的可维护性。
下一页上一页 停止放映 第 144页
（ d）概要设计阶段
? 该阶段的目的是用比较抽象概括的方式描
述系统, 怎样做,, 确定系统的物理配置
以及系统的软件结构和模块结构 。 在制定
方案时, 要充分考虑组成系统的各个物理
元素 （ 如程序, 数据库, 文档等 ） 对可维
护性的影响 。
? 在设计系统的软件结构和模块化时, 要充
分运用结构化设计技术和模块技术, 尽量
减小模块间的耦合性, 提高模块的内聚性,
获得较高的模块独立性 。 这是影响可维护
性的基本要素 。
下一页上一页 停止放映 第 145页
（ e）详细设计阶段
? 该阶段的目标是具体实现系统, 怎样做,, 在
该阶段结束时, 应得到目标系统精确的模块描
述和实现算法 。 为使未来系统便于维护, 模块
设计不仅要求逻辑上的正确性, 还必须强调可
理解性 。
? 设计实现过程中要采用结构化程序设计技术,
使设计出的模块突出结构化特征, 这样的程序
具有统一的静态结构和动态状况, 程序结构清
晰, 便于阅读理解, 同时也便于程序的调试和
测试 。 这些措施都将对软件的可维护性起巨大
的作用 。
下一页上一页 停止放映 第 146页
（ f）编码阶段
? 在该阶段要具体实现模块描述和算法, 选择
PL和编程风格都会对软件的可维护性产生极
大的影响 。
? 选择 PL时, 特别注重所选语言对软件可维护
性的影响 。 一般来说, 选用高级语言而不用
汇编语言；所选语言要具有良好的模块化机
制, 可读性好的控制结构和数据结构, 应用
自动生成和报表自动生成功能, 功能强大的
开发工具和开发环境等 。
? 现在流行的 OOPL具有上述要求的性能, 用这
种语言开发的程序具有较好的可维护性 。
下一页上一页 停止放映 第 147页
（ g）测试阶段
? 在该阶段必须保持 实际系统和软件配置中描述系
统的完全一致性 。 测试过程必须置于可控操作规
程和操作范围之内, 以保证错误确实被消除, 修
改的副作用在允许的范围内, 软件配置的版本更
新与软件一致, 从而保证软件的可维护性 。
下一页上一页 停止放映 第 148页
（ h）维护阶段
? 维护过程本质上是集修改, 系统定义和开发为
一体的过程, 对于适应性维护和完善性维护来
说更是如此 。 要严格按照有关规程进行维护活
动, 在完成每一项维护工作之后, 都要对维护
工作进行仔细认真的复查, 要采取有效措施避
免和减少修改代码, 数据结构和有关文档可能
带来的副作用, 以保证维护后的软件仍具有较
好的可维护性 。
下一页上一页 停止放映 第 149页
(3)文档
? 文档是影响软件可维护性的决定因素 。 由
于需要维护的系统一般都是经过长期实际
运行考验的系统, 人们感兴趣的并不是系
统可运行否, 而是在特殊情况下如何使系
统也能正常地运行, 所以对于维护人员来
说文档比程序代码更为重要 。
? 文档分为用户文档和系统文档两类 ；
? 用户文档,主要描述系统功能和使用方法；
系统文档,描述系统设计, 实现和测试等
各方面的内容 。
下一页上一页 停止放映 第 150页
（ a）用户文档
? 用户最初往往是通过用户文档了解系统功能, 它
包括下述 五方面的内容：
① 功能描述 。 说明系统能做什么, 有哪些主要功能；
② 安装手册 。 说明安装系统的操作步骤以及怎样根据
用户特定的硬件配置设置系统环境；
③ 使用手册 。 手册中应该通过丰富的例子说明怎样使
用常用的系统功能, 还应该说明用户因操作失误
时怎样恢复系统, 以及如何处理异常情况；
④ 参考手册 。 详尽描述用户可以使用的所有系统设施
（ 包括, 调试工具, 故障分析工具, 系统维护工
具等 ） 以及它们的使用方法；
⑤ 操作员指南 。 如果需要有系统操作员的话, 说明操
作员应该如何处理使用中出现的各种情况 。
下一页上一页 停止放映 第 151页
（ b）系统文档
? 系统文档描述的是从问题定义, 需求说明,
模块算法说明, 系统设计, 实现到系统测
试用例, 测试方案等软件配置的所有系统
内部特征的文档 。 （ 阶段文档 ）
? 系统文档中应该更详细地说明系统各部分
实现之间的联系, 使用的方法和算法, 错
误恢复方法, 系统主要参数的范围等与系
统具体实现有关的一切技术方面的信息数
据 。 （ 算法文档 ）
下一页上一页 停止放映 第 152页
作业、思考题
思考：
第 10章
1—25
下一页上一页 停止放映 第 153页
结束语
? 欢迎参加到中心网站, 软件基础, 课程的学习
讨论中来。
? 中心网址：
http,//ctec.xjtu.edu.cn
? 课件下载地址,
ftp,//ctec.xjtu.edu.cn
? E-mail:
xjtuzhao@sina.com
谢谢，再见！
