第四章 总体设计
? 总体设计的过程
? 软件设计的概念和原理
? 启发式规则
? 图形工具
? 面向数据流的设计方法
总体设计的过程
? 设想供选择的方案
? 选取合理的方案
? 功能分解
? 设计软件结构
? 数据库设计
? 制定测试计划
? 书写文档
? 审查和复查
总体设计的过程
? 设想供选择的方案
? 选取合理的方案
? 系统流程图
? 组成系统的物理元素清单
? 成本 /效益分析
? 进度计划
? 确定最佳方案
? 功能分解
? 设计软件结构 （模块化思想）
? 数据库设计
? 制定测试计划
总体设计的过程
? 书写文档
? 系统说明
? 用户手册
? 测试计划
? 详细的实现计划
? 数据库设计结果
? 审查和复查
软件设计的概念和原理
? 模块化
? 抽象
? 信息屏蔽和局部化
? 模块独立
软件设计的概念和原理
? 模块化的概念
? 软件系统的模块化是指整个软件被划分成若干单独
命名和可编址的部分，称之为模块。这些模块可以
被组装起来以满足整个问题的需求。
? 把问题／子问题的分解与软件开发中的系统／子系
统或系统／模块对应起来，就能够把一个大而复杂
的软件系统划分成易于理解的比较单纯的模块结构。
? 公式
?E(P1+P2)>E(P1)+E(P2)
软件设计的概念和原理
成
本
成本 / 模块
最小成本区
接口成本
软件总成本
模块数目
模块化和软件成本
软件设计的概念和原理
? 抽象
? 软件系统进行模块设计时，可有不同的抽象层次。
? 在最高的抽象层次上，可以使用问题所处环境的语
言概括地描述问题的解法。
? 在较低的抽象层次上，则采用过程化的方法。
? 过程的抽象
? 数据的抽象
软件设计的概念和原理
? 过程的抽象 （ 在软件工程中，从系统定义到实现，每
进展一步都可以看做是对软件解决方法的抽象化过程的一
次细化）
? 在软件需求分析阶段，用“问题所处环境的为大
家所熟悉的术语”来描述软件的解决方法。
? 在从概要设计到详细设计的过程中，抽象化的层
次逐次降低。当产生源程序时到达最低抽象层次。
? 数据抽象 （在不同层次上描述数据对象的细节，定义
与该数据对象相关的操作）
软件设计的概念和原理
? 信息屏蔽和局部化
? 模块中所包含的信息（包括数据和过程）不允许其
它不需要这些信息的模块使用。
? 模块独立
? 是模块化、抽象、信息屏蔽和局部化概念的直接结
果
? 每个模块完成一个相对独立的子功能，并且与其它
模块间的接口简单。
? 衡量模块独立程度的定性标准 ----内聚、耦合
软件设计的概念和原理
? 耦合 （模块之间的互相连接的紧密程度的度量）
? 控制耦合
? 数据耦合
? 公共环境耦合
? 内容耦合
? 尽量用数据耦合，少用控制耦合，限制公共环境耦
合的范围，完全不用内容耦合
耦
合
程
度
越
高
软件设计的概念和原理
? 控制耦合 ?环境公共耦合
软件设计的概念和原理
? 内容耦合
软件设计的概念和原理
? 内聚
? 模块功能强度 (一个模块内部各个元素彼此结合
的紧密程度 )的度量。
功能 顺序 通信 过程 时间 逻辑 偶然
内聚 内聚 内聚 内聚 内聚 内聚 内聚
?模块独立性比较强的模块 --高内聚低耦合
启发式规则
? 改进软件结构提高模块独立性
? 模块规模应该适中
? 深度,宽度,扇出和扇入都应适当
? 模块的作用域应该在控制域之内
? 力争降低模块接口的复杂程度
? 设计单入口单出口的模块
? 模块功能应该可以预测
软件设计的概念和原理
? 启发式规则
? 争取低耦合、高内聚（增加内聚 > 减少耦合）
? 模块规模适中：
? 过大不易理解；太小则接口开销过大。注意分解后不应
降低模块的独立性。
? 适当控制深度、宽度、扇出、扇入
? 深度 分层的层数。过大表示分工过细。
? 宽度 同一层上模块数的最大值。过大表示系统复杂度
大。
? 扇出 (fan-out) 一个模块直接调用 \控制的模块数
? 3 ? fan-out ? 9
? 扇入 (fan-in) 直接调用该模块的模块数
? 在不破坏独立性的前提下,fan-in 大的比较好。
软件设计的概念和原理
? 启发式规则
? 作用域在控制域内
M
A C
B
M的控制域为 {M,A,B,C}
作用域,M中的一个判定所影响的模块
A:
…………
if ……
then goto B1
…………
…………
B:
…………
…………
B1:
…………
…………
作用域在控制域内
A:
…………
if ……
then gotoM1
…………
…………
M:
…………
…………
M1,goto C1
…………
…………
作用域超出了控制域
软件设计的概念和原理
? 启发式规则
? 作用域在控制域内
? 上例中 A的作用超出了控制域。改进方法之一，可以把 A
中的 if 移到 M中；方法之二，可以把 C移到 A下面。
? 降低接口的复杂程度
? 接口复杂可能表明模块的独立性差。
? 单出单入，避免内容耦合。
? 模块功能可预测
? 相同输入必产生相同输出。反例：模块中使用全局变量
或静态变量，则可能导致不可预测。
图形工具
? 层次图和 HIPO图
? 结构图
图形工具
? 层次图
? 描绘软件的层次结构
? 矩形代表模块，连线代表调用
? HIPO图
? 层次图加 IPO图
? 对除最顶层的方框外的所有方框加编号（ 编号规则
同数据流图）
图形工具
? 结构图
? 反映程序中模块之
间的层次调用关系
和联系
循
环
调
用
图形工具
? 程序系统结构图
面向数据流的设计方法
? 概念
? 交换分析
? 事务分析
? 设计优化
面向数据流的设计方法
? 概念 （把信息流映射成软件结构）
? 变换流
内部表示
变换流
输出流输入流外部表示
时间
面向数据流的设计方法
? 概念
? 事务流
? T称为事物中心
? 接收输入数据
? 分析事务确定类型
? 根据类型取通道
…
…T
事物
…
活动通路
…
…
面向数据流的设计方法
? 变换分析
? 设计步骤
? 复查基本系统模型
? 复查并精化数据流图
? 确定数据流图具有变换特性还是事务特性
? 确定输入流和输出流的边界，从而孤立出变换中心
? 完成第一级分解
? 完成第二级分解
? 使用设计度量和启发式规则对第一次分割得到的软
件结构进一步精化
面向数据流的设计方法
? 事务分析
? 与变换分析的步骤相似，但从数据流图到软件结构
的映射方法不同
? 设计优化
? 先使它能工作，然后再使它快起来
? 总体设计的过程
? 软件设计的概念和原理
? 启发式规则
? 图形工具
? 面向数据流的设计方法
总体设计的过程
? 设想供选择的方案
? 选取合理的方案
? 功能分解
? 设计软件结构
? 数据库设计
? 制定测试计划
? 书写文档
? 审查和复查
总体设计的过程
? 设想供选择的方案
? 选取合理的方案
? 系统流程图
? 组成系统的物理元素清单
? 成本 /效益分析
? 进度计划
? 确定最佳方案
? 功能分解
? 设计软件结构 （模块化思想）
? 数据库设计
? 制定测试计划
总体设计的过程
? 书写文档
? 系统说明
? 用户手册
? 测试计划
? 详细的实现计划
? 数据库设计结果
? 审查和复查
软件设计的概念和原理
? 模块化
? 抽象
? 信息屏蔽和局部化
? 模块独立
软件设计的概念和原理
? 模块化的概念
? 软件系统的模块化是指整个软件被划分成若干单独
命名和可编址的部分，称之为模块。这些模块可以
被组装起来以满足整个问题的需求。
? 把问题／子问题的分解与软件开发中的系统／子系
统或系统／模块对应起来，就能够把一个大而复杂
的软件系统划分成易于理解的比较单纯的模块结构。
? 公式
?E(P1+P2)>E(P1)+E(P2)
软件设计的概念和原理
成
本
成本 / 模块
最小成本区
接口成本
软件总成本
模块数目
模块化和软件成本
软件设计的概念和原理
? 抽象
? 软件系统进行模块设计时，可有不同的抽象层次。
? 在最高的抽象层次上，可以使用问题所处环境的语
言概括地描述问题的解法。
? 在较低的抽象层次上，则采用过程化的方法。
? 过程的抽象
? 数据的抽象
软件设计的概念和原理
? 过程的抽象 （ 在软件工程中，从系统定义到实现，每
进展一步都可以看做是对软件解决方法的抽象化过程的一
次细化）
? 在软件需求分析阶段，用“问题所处环境的为大
家所熟悉的术语”来描述软件的解决方法。
? 在从概要设计到详细设计的过程中，抽象化的层
次逐次降低。当产生源程序时到达最低抽象层次。
? 数据抽象 （在不同层次上描述数据对象的细节，定义
与该数据对象相关的操作）
软件设计的概念和原理
? 信息屏蔽和局部化
? 模块中所包含的信息（包括数据和过程）不允许其
它不需要这些信息的模块使用。
? 模块独立
? 是模块化、抽象、信息屏蔽和局部化概念的直接结
果
? 每个模块完成一个相对独立的子功能，并且与其它
模块间的接口简单。
? 衡量模块独立程度的定性标准 ----内聚、耦合
软件设计的概念和原理
? 耦合 （模块之间的互相连接的紧密程度的度量）
? 控制耦合
? 数据耦合
? 公共环境耦合
? 内容耦合
? 尽量用数据耦合，少用控制耦合，限制公共环境耦
合的范围，完全不用内容耦合
耦
合
程
度
越
高
软件设计的概念和原理
? 控制耦合 ?环境公共耦合
软件设计的概念和原理
? 内容耦合
软件设计的概念和原理
? 内聚
? 模块功能强度 (一个模块内部各个元素彼此结合
的紧密程度 )的度量。
功能 顺序 通信 过程 时间 逻辑 偶然
内聚 内聚 内聚 内聚 内聚 内聚 内聚
?模块独立性比较强的模块 --高内聚低耦合
启发式规则
? 改进软件结构提高模块独立性
? 模块规模应该适中
? 深度,宽度,扇出和扇入都应适当
? 模块的作用域应该在控制域之内
? 力争降低模块接口的复杂程度
? 设计单入口单出口的模块
? 模块功能应该可以预测
软件设计的概念和原理
? 启发式规则
? 争取低耦合、高内聚（增加内聚 > 减少耦合）
? 模块规模适中：
? 过大不易理解；太小则接口开销过大。注意分解后不应
降低模块的独立性。
? 适当控制深度、宽度、扇出、扇入
? 深度 分层的层数。过大表示分工过细。
? 宽度 同一层上模块数的最大值。过大表示系统复杂度
大。
? 扇出 (fan-out) 一个模块直接调用 \控制的模块数
? 3 ? fan-out ? 9
? 扇入 (fan-in) 直接调用该模块的模块数
? 在不破坏独立性的前提下,fan-in 大的比较好。
软件设计的概念和原理
? 启发式规则
? 作用域在控制域内
M
A C
B
M的控制域为 {M,A,B,C}
作用域,M中的一个判定所影响的模块
A:
…………
if ……
then goto B1
…………
…………
B:
…………
…………
B1:
…………
…………
作用域在控制域内
A:
…………
if ……
then gotoM1
…………
…………
M:
…………
…………
M1,goto C1
…………
…………
作用域超出了控制域
软件设计的概念和原理
? 启发式规则
? 作用域在控制域内
? 上例中 A的作用超出了控制域。改进方法之一，可以把 A
中的 if 移到 M中；方法之二，可以把 C移到 A下面。
? 降低接口的复杂程度
? 接口复杂可能表明模块的独立性差。
? 单出单入，避免内容耦合。
? 模块功能可预测
? 相同输入必产生相同输出。反例：模块中使用全局变量
或静态变量，则可能导致不可预测。
图形工具
? 层次图和 HIPO图
? 结构图
图形工具
? 层次图
? 描绘软件的层次结构
? 矩形代表模块，连线代表调用
? HIPO图
? 层次图加 IPO图
? 对除最顶层的方框外的所有方框加编号（ 编号规则
同数据流图）
图形工具
? 结构图
? 反映程序中模块之
间的层次调用关系
和联系
循
环
调
用
图形工具
? 程序系统结构图
面向数据流的设计方法
? 概念
? 交换分析
? 事务分析
? 设计优化
面向数据流的设计方法
? 概念 （把信息流映射成软件结构）
? 变换流
内部表示
变换流
输出流输入流外部表示
时间
面向数据流的设计方法
? 概念
? 事务流
? T称为事物中心
? 接收输入数据
? 分析事务确定类型
? 根据类型取通道
…
…T
事物
…
活动通路
…
…
面向数据流的设计方法
? 变换分析
? 设计步骤
? 复查基本系统模型
? 复查并精化数据流图
? 确定数据流图具有变换特性还是事务特性
? 确定输入流和输出流的边界，从而孤立出变换中心
? 完成第一级分解
? 完成第二级分解
? 使用设计度量和启发式规则对第一次分割得到的软
件结构进一步精化
面向数据流的设计方法
? 事务分析
? 与变换分析的步骤相似，但从数据流图到软件结构
的映射方法不同
? 设计优化
? 先使它能工作，然后再使它快起来
