第六章
系 统 设 计
第一节 系统设计概述
系统设计是新系统的物理设计阶段，根据
系统分析阶段所确定的新系统的逻辑模型，
综合考虑各种约束，利用一切可用的技术手
段和方法，进行各种具体设计，提出一个能
在计算机上实现的新系统的实施方案，解决
,系统怎样做, 的问题。
系统设计概述
系统 设计概述
?目标和任务
?系统设计模型
?设计方法
?主要内容
解决系统,怎样做（ How to do）, 的
问题。
1 系统设计的目标
系统分析：解决, 做什么,
系统设计：解决, 怎么做,
一、系统设计的目标和任务
2 系统设计的任务
问题结构 (系统需求 ) 系统结构
从系统分析说明书出发，形成系统的
具体设计方案。
一、系统设计的目标和任务 (续 )
映射
数据
字典
数据
流图
E-R图
加工小说明
流 程
描
述
处理描述
数
据
对
描
述
象
数 据 设 计
模块结构设计
接口设计
过程设计
分析模型 设计模型
平 台 设 计
二、系统设计模型
二、系统设计模型 (续 )
上图中通过数据、功能模型展示的系统需
求被传送给设计阶段，运用某种设计方法，
设计阶段产生出：
? 数据设计,将分析时创建的数据模型变换成实现
系统所需的数据结构。
? 平台设计,将性能要求变换成对系统软硬件环境
的配置
? 模块结构设计,定义系统模块元素之间的关系。
?接口设计,描述了系统内部、系统和协作系统之
间的以及系统同人之间如何通信。
? 过程设计,将加工说明变换为对系统模块内部算
法的具体描述。
三 系统设计方法
?结构化设计方法 (SD)
?面向数据结构的设计方法 (JSD方法 )
?面向对象的设计方法 (OOD)
四 系统 设计主要内容
? 系统总体设计
? 系统详细设计
? 系统平台设计
? 代码设计
? 输入输出设计
? 对话设计
? 数据库或数据文件设计
? 模块内部的算法设计
? 写出系统设计报告
总体设计：
告诉用户系统具体将要做什么 。 一旦
用户同意了这个总体设计, 我们会将
这个总体设计转换为更加详细的文档 。
1 系统总体 设计
总体设计包括：
? 工具 — 如何描述系统的 总体结构
? 方法 — 用什么方法把问题结构导出系统
结构
? 评价准则 — 什么样的系统结构是, 最优
的,
1 系统总体 设计（续）
1 系统总体 设计（续）
总体结构：
? 系统的组成部分，即有哪些模块组成
? 系统的层次及调用关系
? 模块的处理功能
? 模块之间的界面，即模块间传递的数据
优秀的总体设计应该包含以下特征
? 不包括用户不熟悉的专业词汇
? 它描述系统功能
? 独立于实现过程
? 与系统分析文档相一致
2 系统详细 设计
详细设计：
让系统建设者了解要解决用户的问题所需
要的硬件和系统。主要描述系统的硬件配置
、系统代码、人机界面、输入和输出、数据
库和网络体系结构等。也就是说，详细设计
是系统说明的一个 技术层面 上的描述。
2 系统详细 设计（续）
详细设计包括：
? 系统平台设计
? 代码设计
? 数据库设计
? 对话（人机界面）设计
? 输入 /输出设计
? 模块内部的算法设计（处理流程设计）
第二节 结构化系统设计
结构化系统设计
结构化系统设计是, 用一组标准的准则
和工具帮助系统设计人员确定应该由哪些模
块，用什么方式联结在一起，才能构成一个
最好的系统结构, 。
即，结构化设计方法 (SD)是以数据流图
为基础的,采用 模块化、自顶向下逐步求精
的基本思想，以 数据流图为基础 构造出模块
结构图。
? 采用分解的方法,即把系统分解成由相对
独立的、功能单一的若干模块组成的结构
? 采用图形表达工具
? 有一组基本的设计原则
? 有一组基本的设计策略
? 有一组评价标准和优化技术
一 结构化系统设计的特点
二 结构化系统设计的基本工具
在系统设计阶段，我们采用 模块结
构图 来表达目标系统的物理模型，描
述系统的结构。
三 结构化系统设计原则
? 系统的观点
? 模块化结构
? 阶段性策略
? 模块的独立性
? 鼓励用户积极参与设计
第三节 系统总体设计
系统总体 设计（主要内容）
?系统的分解方法
?模块结构图
?基本设计原则 （模块耦合度与聚合度）
?设计策略 （变换型、事务型）
?设计优化技巧
一 系统的分解方法
? 系统分解的方法是把一个复杂的问题分解
成简单的要素，把一个统一的整体分解为
各个组成部分，然后对各个要素和组成部
分分别进行研究。
? 借助于目标系统的逻辑模型 (DFD)并根据
部门机构设置情况进行系统分解
1.系统分解的原则
? 明确系统分解前、后的功能尽量一致
? 每次分解的结果是可以独立开发的子系
统 (或模块 )
? 各子系统 (或模块 )间的关联尽量少
? 制定子系统 (或模块 )间的约束规范
? 区别稳定的和易变的子系统 (或模块 )
2.系统分解的方法
(一 )按企业业务管理部门划分
如：生产、销售、供应管理等；按部门设置
(二 )按完成功能的类型来划分
如：顾客服务、技术与生产数据管理；按实际职
能设置
二 模块结构图
结构化设计方法的基本思想就是模块
化。即对每一个系统按功能逐步由顶向
下，由抽象到具体的逐层分解，将系统
分解成为多层次的独立功能模块，一直
分解到能简单地用程序实现为止。
总体设计任务
（一） 模块
? 模块的定义,
模块是可以组成、分解、更换的系统，是
易于处理的基本单位，具有四种属性的一
组程序语句称为一个模块，这四种属性分
别是输入输出、逻辑功能； （ 外部特性 ）
内部数据、程序代码。 （ 内部特性 ）
（一） 模块 (续 )
? 模块的例子,
int max( int x,int y)
{ int z;
z=x>y? x,y;
return(z);
}
模块名
数
据
内部
数据
内部
语句
模块化思想：
?模块化是好的系统设计的一个基本准
则
从整体上把握
问题,暂不考虑细节
?复杂问题 较小问题
分解
可减小解题所需的总的工作
分解
模块和子系统的区别
模块和子系统的概念是有所区别的。子系
统仍具有系统的特征（ 更大 ），模块则是指
为完成某项功能的程序集合体（ 较小 ），它
是一个不可分割的整体，但模块和子系统的
概念有时又是兼容和不可绝对区分的。在日
常工作中我们常将完成一个管理功能的程序
集称为模块，而它常常由多个很小的程序子
模块组成，所以有的地方可称为子系统。
(二 ) 模块结构图 sc
1,结构图的产生
程序流程图 系统流程图和功
能图 HIPO技术 (功能图和 IPO
图 ) 结构图 (Structure Chart)。
2.结构图的主要成分
? 模块 ——用方框表示，方框中写上模块
名字，反映了这个模块的功能
? 调用 ——从调用模块指向被调用模块的
箭头
? 数据 ——调用箭头旁的小箭头，表示从
一个模块向另一个模块传送的数据，也
指出了传送的方向
3.结构图基本符号及表示法
编辑学生记录
读学生记录
学生数据
无此学生
学号
不加区分的数据
数据信息
控制信息
? 模块调用的例子,
int max( int x,int y)
{ int z;
z=x>y? x,y;
return(z);
}
Main( )
{,
:
max( 3,4)
:
}
Main()
求最大值
Zx
y
SC中的四种模块
传入模块
(a) (b)
A
A
传出模块
B
B
变换模块
(c)
C D
协调模块
E
(d)
E F F
SC中的简单调用
B
A
C
x,y z
(a)表示法一 (b)表示法二
z B
A
C
1 2
入 出1
2
x,y
z
zA调用 B和 C
SC中的选择调用
A
CB D
A根据内
部判断决
定是否调
用 B
A按另一判
定结果选择
调用 C或 D
SC中的循环调用
A
B C
A根据循环条件重复调
用 B,C等模块
? 选择调用的例子,
A( )
{,
if (条件,.)
B( )
else
C( )
:
}
A
B C
? 循环调用的例子,
A( )
{,
while (条件,.)
{
B( );
,;
}
:
}
A
B
4.模块结构类型
内导结构：是结构图中数据以最低层模块
输入，并逐级向高层传递，高一层模块接
收低一层模块的输入。
主模块
A1
A4A3
A2
外导结构：结构图中低一层模块接收上
一层模块的数据信息，并把它们转换给
下一级模块，直到输出给使用者。
w u
子模块 1
v
主模块
子模块 2
子模块 2.1
转换结构：数据要在模块内经过一定的
处理，下层模块从相应的上层模块接收
数据，经转换后返回同一上层模块中去。
w u
子模块 1
v
主模块
子模块 2
子模块 2.1
X M
Y
4.结构图与数据流图的差别
? 数据流程图是从数据流着眼，而结构图从程序模
块着眼 ;
? 数据流程图描述的是系统的逻辑模型，而结构图
是描述系统的物理模型 ;
? 数据流程图是用不同的图来表示不同的层次，是
“平面图”，而结构图能反映系统的层次结构，
是“立体图” ;
? 数据流程图是从具体到抽象，描述系统的要求，
而结构图是从抽象到具体，描述系统的实现方法。
（三） 模块设计的原则
系统的 可维护性 是系统评价的一个重要因素
可维护性 局部修改
模块间的联系尽可能的少 （耦合）
而模块内的联系尽可能多 （聚合）
1.模块的独立性
模块独立的含义：
?模块完成独立、单一的功能
?符合信息隐蔽和信息局部化原则
?模块间关连和依赖程度尽量小
2.模块独立性的度量
模块独立性取决于模块的内部和外部特
性。
SD方法提出的定性的度量标准：
? 模块之间的 耦合性（块间联系）
? 模块自身的 聚合性（块内联系）
3.模块独立性的度量之一：耦合度
? 耦合度 是模块间的联结关系，衡量
不同模块间的相互依赖的紧密密程度，
耦合的强弱取决于模块间接口的复杂程
度；进入或访问一个模块的入口点；以
及通过接口的数据。
? 耦合度越高，模块独立性越弱
无耦合－没有依赖关系
松散耦合－有
少量依赖关系
紧密耦合－有
很多依赖关系
模块耦合度（续 ）
耦合度强弱的因素：
?一模块对另一模块的引用
?一模块向另一模块传递的数据量
?一模块施加到另一模块的控制的数量
?模块间接口的复杂程度
模块间耦合的类型：
低 非直接耦合
耦 数据耦合
合 标记耦合
性 控制耦合
高 内容耦合
模
块
独
立
性
弱
(低耦合 ) 强
(中耦合 )
(较强耦合 )
(强耦合 )
公共耦合
(1) 非直接耦合
两个模块没有直接关系 (模块 1和
模块 2)，模块独立性最强。
模块 1 模块 2
模块 3 模块 4
(2) 数据耦合
一模块调用另一模块时，被调
用模块的输入、输出都是简单
的数据。
属松散耦合。
数据耦合举例
开发票
计算水费
单价
数量 金额
数据耦合举例
计算水电费
计算水费 计算电费
用水量 用电量水费
电费
(3) 标记耦合 (特征耦合 )
如两个模块通过传递数据结构
(不是简单数据，而是记录、数组
等 )加以联系，或都与一个数据
结构有关系,则称这两个模块
间存在标记耦合。
标记耦合举例
计算水电费
计算水费 计算电费
住户情况 水费
电费
住户情况
,住户情况, 是一个数据结构,图中模块都
与此数据结构有关,
,计算水费, 和, 计算电费, 本无关,由于
引用了此数据结构产生依赖关系,它们之间
也是标记偶合,
将标记耦合修改为数据耦合举例
计算水电费
计算水费 计算电费
本月
用水量
本月
用电量水费
电费
(4) 控制耦合
一模块通过开关量、标志、
名字等控制信息，明显地控
制另一模块的功能。
控制耦合举例
A
计算平均分
或最高分
B
平均 /最高 成绩
设想一下 A( )函数中调用 B( )的语句是怎样的？
? 这个问题与前面的调用 MAX( )的例子不同。
在 MAX( )函数中，我们很清楚地看到：形式
参数表是两个整数，表示要比较的两个数。
函数说明为,MAX( int x,int y)
函数处理后，返回的结果为较大的那个数。
所以，在主调函数中，我们只需以两个被比
较的数作为 实际参数，所以就可写出形如：
..=MAX( 25,36) 的调用语句。
设想一下 A( )函数中调用 B( )的语句是怎样的？
? 但在 B( )函数中，我们虽然知道：形式参数表是
一个整数，表示要取得的成绩类型是平均或最高。
函数说明为,B( int x)
函数处理后，返回的结果为取出的成绩数据 (平
均或最高 )。
可是，在主调函数中，我们仍不知道以什么
作为实际参数，是 0？ 1？ 2？还是其他值，取决
于 B()中用什么值表示平均 /最高标记。因此，就
要去了解 B()内部的语句，而不能仅凭函数说明
就写出调用语句。所以 B()就成为灰箱 /白箱，而
非黑箱。
控制耦合举例
读入分数
输出结果
计算平均分 计算最高分
平均 /最高?
调用逻辑性模块
B时，须先传递
控制信号 (平均分
/最高分 )，以选
择所需的操作。
控制模块必须知
道被控模块的内
部逻辑，增强了
相互依赖,
B
控制耦合增加了模块之间的复杂性，
调用模块必须知道被调模块的内部逻
辑，增加了相互依赖。
去除模块间控制耦合的方法：
(1)将被调用模块内的判定上移到调
用模块中进行
控制耦合增加了理解和编程的复
(2)被调用模块分解成若干单一功
能模块
改控制耦合为数据耦合举例
A
计算平均分
B1
平均成绩 最高成绩
计算最高分
B2
控制耦合举例
A
发奖牌
名次
(开关量 )
奖牌
控制耦合
被调用模块内
处理逻辑模式
功能 A 功能 B
判别
改控制耦合为数据耦合举例
A
发金牌 发银牌 发铜牌
金牌
银牌
铜牌
A
取口令并核对B
用户名、
口令 对 /不对
控制耦合举例
A
取口令B
用户名 口令
将 B中核对口令功能划分到 A
(5) 公共耦合 (公共数据区耦合 )
一组模块引用同一个公用数据区
(也称全局数据区、公共数据环境 )。
公共数据区 指：
? 全局数据结构
? 共享通讯区
? 内存公共覆盖区等
公共耦合举例
Ａ
ｃｏｍｍｏｎ
公共数据区
松散的公共耦合
Ｂ Ａ
ｃｏｍｍｏｎ
公共数据区
紧密的公共耦合
Ｂ
公共耦合举例
Ａ
公共数据区
CB
模块 A,B,C间存在错综复杂的联系
公共耦合举例
所有的公共
耦合关系
A
EB
C
D
6个模块共享一
个 公共数据区
F
(1)系统可理解性降低
(模块间存在错综复杂的连系 )
(2)系统可维护性差
(修改变量名或属性困难 )
(3)系统可靠性差
(公共数据区及全程变量无保护措施 )
慎用公共数据区和全程变量 !!!
公共耦合存在的问题：
(6) 内容耦合
一模块直接访问另一模块的
内部信息 (程序代码或数据 )
最不好内容耦合形式 !!!
发生内容耦合的情形：
(1)一模块直接访问另一模块的
内部数据
(2)一模块不通过正常入口转到
另一模块内
(3)两模块有一部分代码重叠
(4)一模块有多个入口
模块化设计对耦合度的要求：
耦合是影响系统复杂程度和设计
质量的重要因素
目标,建立模块间耦合度尽可能
松散的系统
如何降低模块间耦合度：
(1) 如模块必须存在耦合，
选择适当的耦合类型
原则,尽量使用数据耦合
少用控制耦合
限制公共耦合的范围
坚决避免使用内容耦合
如何降低模块间耦合度：
(2) 降低模块间接口的复
杂性
接口复杂性与耦合类型的关系：
接
口
复
杂
性
接口方式
接口数据
的复杂性
无接口关系
直接引用
过程调用语句
数据项作参数
数据结构，变
量名作参数
内容耦合
其它耦合
开关量，起
控制变量作用
公用数据区
全程变量，
数据耦合
标记耦合
控制耦合
公共耦合
非直接耦合
4,模块独立性的度量之二：聚合度
衡量一个模块内部各成分之间彼
此结合的紧密程度
设计目标：高聚合 (一模块的所有
成分都直接参与并且
对于完成同一功能来
说都是最基本的 )
模块的聚合性类型：
低 偶然聚合
内 逻辑聚合
聚 时间聚合
性 过程聚合
通信聚合
顺序聚合
高 功能聚合
模
块
独
立
性
弱 (功能分散 )
强 (功能单一 )
(1) 功能聚合
一个模块内的所有成分的处理
动作全部为完成某个功能，且
只执行一个功能，缺一不可，
称为功能聚合。
聚合性最强
如, 计算实发工资，打印发票等
(2) 顺序聚合
一个模块能完成多个操作，前
一个操作处理的输出数据是下
一个操作处理的输入数据，模
块中各成份的工作是有次序的，
各成份的关系也较紧密，则称
为顺序聚合。
顺序聚合模块例
读 入
存 贮
打 印
累 加
读 数
模块 1 模块 2
(3) 通信聚合
模块内各部分使用相同的输
入数据，或产生相同的输出
结果,称为通信聚合
通信聚合模块例
产生工
资报表
计算平
均工资
职工工
资记录
职工工
资报表
平均
工资
产生职工工资报表并计算平均工资模块
通信聚合模块例
开领
书单
登记
售书
发票
领书单
售 书
登记表
文件
删除
修改
(4) 过程聚合
一个模块内各处理成分的动
作各不相同，彼此也没什么
关系，但它们都受一个 控制
流 的支配，且决定了它们的
执行次序。
过程聚合模块
建立方程组系数矩阵
全部任务纳入一个
模块，得到一过程
性模块
高斯消去法
回 代
高斯消去法解题流程
(5) 时间聚合
模块完成的功能必须在 同一时间
内执行，这些功能只因时间因素
关联在一起。
例如,初始化系统模块、
系统结束模块、
紧急故障处理模块等均是时间性聚合
模块,
(6) 逻辑聚合
把几种相关功能 (逻辑上相似
的功能 )组合在一模块内,每次
调用由传给模块的参数确定执
行哪种功能。
逻辑聚合模块例
A B C
E F G
A B C
EFG
A1 B1 C1
EFG模块内部逻辑
E,F,G逻辑
功能相似，组
成新模块 EFG
缺点, 增强了耦合程度 (控制耦合 )
不易修改，效率低
公用代码段
公用代码段
逻辑聚合缺点：
不易修改
增强了耦合程度 (控制耦合 )
效率低
(7) 偶然聚合
模块内各部分间无联系
A B C
M MOVE O TO R
READ FILE F
MOVE S TO T
模块 M中的三个语句没有任何联系
缺点：可理解性差,可修改性差
例,
?做杂事 ’
模块聚合性的判断
Y
N
Y
Y
该
模
块
功
能
单
一
各
功
能
关
系
如
何
功能聚合
通讯聚合
顺序聚合
逻辑相似
次序重要
次序重要
过程聚合
时间聚合
逻辑聚合
偶然聚合
N
N
N
Y
数据流
控制流
两者皆非
5,耦合、聚合与模块独立性关系
耦合与聚合都是模块独立性的
定性标准，都反映模块独立性
的良好程度。但耦合是直接的
主导因素，聚合则辅助耦合共
同对模块独立性进行衡量。
控制耦合举例
A
计算平均分
或最高分
B
平均 /最高 成绩
逻辑聚合
改控制耦合为数据耦合举例
A
计算平均分
B1
平均成绩 最高成绩
计算最高分
B2
功能聚合
A
取口令并核对B
用户名、
口令 对 /不对
控制耦合举例
顺序聚合
A
取口令B
用户名 口令
将 B中核对口令功能划分到 A
功能聚合
聚合与耦合密切相关，同其它模块
强耦合的模块意味着弱聚合，强聚
合模块意味着与其它模块间松散耦
合,
设计目标,力争 强聚合,
弱耦合
5,耦合、聚合与模块独立性关系
(续 )
三 数据流图导出初始结构图
从数据流程图导出系统的初始结构图，
首先要区分数据流程图的结构类型，然
后根据不同的类型采用不同的方法把数
据流图映象成相应的模块结构。
(一 )数据流程图 DFD的结构类型
1．变换型 DFD
一个数据流程图可以明显地分成输入、
处理和输出三部分。
2．事务型 DFD
事务型数据流程图一般呈束状形。
(1) 变换型结构
由输入、变换中心 (或称主
加工 )和输出三部分组成。
基本模型：
变换
中心
输入
路径
输出
路径
变换流示意图
信息
时间
信息流
输入流 输出流
变换流
外部
表示
内部
表示
变换型数据流图
输入
信息
物理
输入
格式
检查 处理 显示
正确
信息 结果
物理
输出
数据
变换中心 输出
逻辑
输入
逻辑
输出
输入
(2) 事务型结构
特征, 具有在多种事物中选择
执行某类事物的能力
基本模型：
事务
中心
接受路径 动作
路径
(3)大型系统 DFD中,变换型和事
务型结构往往共存,
T
事务中心
传入 变换 传出
(二 )DFD导出初始 SC的过程
? 两种转换策略 /技术
? 变换分析
? 事务分析
? 一般过程
? 先设计模块结构顶端的主模块
? 然后, 由顶向下逐步细化,
? 最后得到一个 与数据流图相对应 的程序结构
SD方法的两种转换方法
变换型 DFD
事务型 DFD
初始 SC
初始 SC
变换分析
事务分析
“由顶向下逐步细化, 的思想
? 找出, 顶, 在哪里，设计一个相应的主控模块
? 每创建一个新的模块时，必须决定该模块的外部特征
? 该模块的功能，即该模块, 做什么,
? 该模块同其调用模块的界面，即调用时传送的参数
? 对已创建的模块进行细化，考虑这个模块应该, 怎样做,
才能完成它的功能,于是又要创建下一层的新模块,再回
到上一步
通过这样, 先决定做什么,再考虑怎样
做,,循环往复,设计过程就有序地进行,
直至获得整个完整的结构层次。
变
换
型
事
务
型
（三）变换分析设计方法
(Transform Analysis)
步骤：
1 找出主加工、逻辑输入和逻辑输
出
2 设计模块结构的顶层和第一层
3 设计中、下层模块
1 区分输入、主加工、输出部分，在
DFD上标明分界线
(1)确定 逻辑输入 ——离物理输入端最远
的，但仍可被看作系统输入的那个数据
流
方法,从物理输入端开始，一步步向系
统的中间移动，直至达到这样一个数据
流：它已不能再被看作为系统的输入，
则其前一个数据流就是系统的逻辑输入。
1 区分输入、主加工、输出部分，在
DFD上标明分界线
(2)确定 逻辑输出 ——离物理输出端最远
的，但仍可被看作系统输出的那个数据
流
方法,从物理输出端开始，一步步向系
统的中间反方向移动，直至达到这样一
个数据流：它已不能再被看作为系统的
输出，则其后一个数据流就是系统的逻
辑输出。
1 区分输入、主加工、输出部分，在
DFD上标明分界线 (续 )
(3)对系统的每一股输入和输出，都用上
面的方法找出相应的逻辑输入、输出
(4)确定 主加工 ——位于逻辑输入和逻辑
输出之间的加工，就是系统的主加工
1 区分输入、主加工、输出部分，在
DFD上标明分界线 (续 )
(5)几点说明：
?有的系统只有输入和输出两部分，没有
主加工
?根据经验，几股数据流的汇合处往往是
系统的主加工
?每个人都可以有自己的看法，找出来的
主加工可能也不同，但一般不会相差太
远。
1 2
3 4
5 6
7
a b
c
ed
r
p u
w
v
变换中心
输入
部分
输出
部分
输入 输出 加工
2 设计 SC的顶层和第一层模块：
(1) 设计一个顶层模块 (主模块 )，它的功能是完成整个
程序要做的工作。
(2) 设计结构的第一层：
? 为逻辑输入设计一个输入模块，它的功能是向主模块
提供数据
? 为逻辑输出设计一个输出模块，它的功能是输出主模
块提供的数据
? 为主加工设计一个变换模块，它的功能是将逻辑输入
变换成逻辑输出
第一层模块同顶层主模块之间传送的数据应与数据流图相对
应。这里主模块控制并协调一层的输入、变换、输出模块的工
作，注意识别出选择或循环调用以及调用条件。
第一级分解后的 SC
MC
MTMA ME 第一层
顶层
c,e c,e u,w u,w
传送信息
第一级分解后的 SC(另一种画法 )
MC
MA1
c e
u,w
c,p
MA2 4 5 6 ME1 ME2
e
p
r
r
w,u w
3 第二级分解 (分解 SC各分支 )自顶向下
分解，设计出每个分支 (输入、加工、输
出 )的中、下层模块,
(1)为每一个输入模块设计两个下层模块，一个是
输入模块，接受数据来源；另一个是变换模块，
模块调用时传送的参数应同数据流图相对应
(2)输出模块也有两部分组成，一部分是变换模块，
将数据变换成输出的形式；另一部分是输出模块
上述设计过程由顶向下递归进行，直至达到系
统的输入端或输出端
(3) 变换模块的下层模块，根据数据流图中相应
加工的组成情况而定。
输
入
分
支
的
分
解
MA
Get Cb
a
c
Read D
d
e
c,e
B to C
b c d e
a b
Get E
Get B D to E
A to BRead A DFD图
输
出
分
支
的
分
解
ME
Write V
u
u
w,u
v v
Put U
U to V
Write W
w
DFD图
加工分支的分解
MT
54 6
e
c,p r
u,wp
r
DFD图
任何情况下都可使用变换
分析方法设计软件结构，
但如数据流具有明显的事
务特点时 (有一个明显的事
务中心 )，以采用事务分析
方法为宜。
(四 ) 事务分析设计方法
事务分析设计方法步骤：
(1)在 DFD上确定事务中心。
(2)为 DFD上的事务中心设计主模块，再为每
一种类型的事务处理设计一个事务处理模
块。
(3)为每个事务处理模块设计下面的操作模
块，再为操作模块设计细节模块。某些操
作模块和细节模块可以被几个上一层模块
共用。
事务型 DFD的划分
T
事务
中心 传入 变换 传出接收部分
发
送
部
分
a
事务型 SC的上层结构 (1)
事务控制
Get a
顶层
第一层
a
事务 1
事务型 SC的上层结构 (2)
事务控制
事务
分析 发送
动作分支的典型结构
P
T 2T 1 T i
A 2
D 2
A 1
D 1
A 3 A j
D k
事务层
操作层
细节层
处理层
变换分析举例 -DFD
1
格式
检查
3
产生
收据
2
计算
汇费
4
记账
汇款单
合格的
汇款单
处理后的
汇款单 收据
明细账
变换中心 输出输入
业务
数据
变换分析举例 -转换后的 SC
汇款处理系统
取得合格
汇款单 计算汇费 记账
输出处理后
的汇款单
输入
汇款单
格式检查 产生收据 打印收据
合格的
汇款单
处理后的
汇款单
合格的
汇款单 业务数据
处理后的
汇款单
汇款单 合格的汇款单汇款单
处理后的
汇款单 收据 收据
业务数据
要求类
型处 理
图书管理
要求
无效输入
1.1
新书入库
1.2
还
入库单
罚款单
1.5
注销图书
1.3
还书
1.4
目录文件
借书单
书 单
注销单
借书 借书文件
罚款单
事务分析举例 -DFD
事务
中心
事务分析举例 -转换后的 SC
图书处理系统
取得图书
处理要求
修改目
录文件操作层
细节层
新书入库 注销图书借书 还书
打印
罚款单
修改借
书文件……
…… ……
图书管
理要求 入库单
借书单 还书单
注销单
练习一：将 DFD用变换分析和事务型
分析导出初始 SC
A
C1
C2
C3B
D G
E J
F
K
L
c1
c2
b2b1
b3b
a
c3
d
g
f j
he
k
l
m
*
*
初始 SC
系统
主加工 Put kGet d
DGet c Put lKFE JG
Write mL
B to cGet b
ARead a C1 C3C2
Ac 1 ……Ac 2
Dt 1 Dt 3Dt 2
Ac N
……
操作层
细节层
d
k
k
d
m
ml
l lkdc
c
b
b
c
a a b b1
b2
c3
c1 c2 b3
e,f
d
g,j
f
e,g h h,j k
练习二：将 DFD用变换分析和事务型
分析导出初始 SC
A
C1
C2
C3B
D G
E J
F
K
L
c1
c2
b2b1
b3b
a
c3
d
g
f j
he
k
l
m
+
+
初始 SC
系统
主加工 Put kGet d
Put lKFE JG
Write mL
Get b
ARead a C1 C3C2
Ac 1 ……Ac 2
Dt 1 Dt 3Dt 2
Ac N
……
操作层
细节层
d
k
k
d
m
ml
l lk
b
a a b
b1
b2
c3
c1
c2
b3
e,f
d
g,j
f
e,g h h,j k
四 设计优化
将初始 SC根据模块独立性原则进
行精化,对模块进行合并、分解
修改、调整，得到 高内聚、低耦
合模块,得到易于实现、易于测
试和易于维护的软件结构，产生
设计文档的最终 SC。
改进软件结构设计的指导原则
(1)程序结构尽可能与问题结构相对应
(2)模块功能的完整
(3)消除重复功能
(4)作用范围应在控制范围内
(5)减少高扇出争取高扇入
(6)模块大小适中
(7)降低模块接口的复杂性
(8)模块功能可预测
(1)程序结构尽可能与问题结构
相对应
两种典型的程序结构：
? 变换型程序
? 事务型程序
(1)程序结构尽可能与问题结构
相对应 (续 )
两种程序结构的共同特征：
? 上层模块只负责控制、协调
? 下层模块完成具体的操作
变换型程序
变换型 (即输入、加工、输出
型，或称 IPO型 )的功能是从某
输入设备（如键盘）获得数据，
再对这些数据作处理，然后将
结果送出（如屏幕显示）。
这类程序的标准 SC图形如下
图所示。
变
换
型
程
序
结
构
MAIN
Get c
b
a
c
dtoe
d
d
btoc
b c e e
a b
PUT d
Get b Writee
atobRead a
ctod
c d
事务型程序
事务型程序的功能是接受一项事务，然
后根据事务的不同类型，选择进行某一类事
务的处理。这里，模块结构有三个层次：事
务层、操作层和细节层。主模块按接受的事
务类型，选择调用某个事务处理模块。不同
类型的事务处理模块可能含有一些相同的操
作，所以可能共用一些操作模块；不同的操
作又可能含有一些共同的细节，所以某些操
作模块又可能共用一些细节模块。
这类程序的标准 SC图形如下图所示。
事务型程序结构
MAIN
T 2GetT T i
A 2
D 2
A 1
D 1
A 3 A j
D k
事务层
操作层
细节层
处理层
T 1
(2)模块功能的完整
完整的模块应包括三部分：
?执行规定功能部分
?出错处理部分
?需返回一系列数据时，应返回
是否正确结束 (即, 文件完
/EOF”)标志。
(3)消除重复功能
几个模块中含有重复的部分，应设法
消去。因为同一功能重复多处，不仅浪
费编程、测试时间，还会给修改带来麻
烦。
但消除重复功能并不是简单的合并。
正确的方法 是：先分析几个模块中相同
功能的部分；然后把这个功能分离出来，
构成它们的一个公共的下层模块。
例子：消除重复功能
A
C
B
C
A′ B′
C
改进前 改进后
例子：消除重复功能
X Y
A BC C
改进前图 1
说明,如果 A,B抽去公共部分 C之后余下的模块 A ′,
B ′ 比较简单，则可以同它们的调用模块 X,Y合并，
所以改进后图 2、图 3都有可能。
B′
Y
C
X′
改进后图 2
X′ Y′
C
改进后图 3
(4) 作用范围应在控制范围内
(作用域应在控制域内 )
? 模块的控制范围 (控制域 ),
包括模块本身和其下属模块的集合。
? 模块的作用范围 (作用域 ):
指受该模块内一个条件判定影响的所有模块的集合。
只要模块中含有一些依赖于这个判定的语句，那么就
称该模块在这个判定的作用范围内。
? 控制域是从结构方面考虑的；作用域是从功能
方面考虑的
A
F
B C
E
M
D
G
模块的控制范围和作用范围 (例 )
:条件判定
模块 A的控制范围,
A,B,C、
D,E,F
A的作用范围：
A,C,F
:受判定影响
的模块
把一个条件判定的作用范围限制在判
定所在模块的控制范围之内，且判定
所在位置不能太高。
(作用域是控制域的子集 )
图 A——图 D画出了作用范围和控制范
围的四种情况。
作用范围 /控制范围原则：
图 A：判定位置违反作用范围 /控制范围原则
TOP
A B
C D
GE 条件判定
判定的作用范
围有一部分
(模块 C)
越出了判定所
在模块 G的控
制范围
G D B C
1)将判定所需的数据从 G向上传送到 D、
B，再向下传给 C,C用这些数据再次作
出判定。从而增加块间数据量。
思考,图 A中模块 C怎么知道模块
G中的判定结果
2)将判定的结果（是 /不是）从 G向上传
送到 D,B，再向下传给 C,C用这些开关
量决定执行那些操作。这样也增加块间
数据量，而且传送控制信息。
图 B:符合作用范围 /控制范围原则，但判
定位置太高
TOP
A B
C D
GE
条件
判定
TOP B D G
TOP B C
图 C:符合作用范围 /控制范围原则，判定
位置适中
TOP
A
G
C D
B
E
条件
判定
B D G
B C
图 D:符合作用范围 /控制范围的理想判
定位置
TOP
A
GE
B
DC 条件判定
D G
D E
?将包含条件判定的模块合并到它的
调用模块中，使判定处于较高位置
?将接受判定影响的模块下移到控制
范围内
?把判定上移到足够的位置
可以归结为：
使判定同受其影响的操作尽可能靠近。
修改模块结构方法：
(5)减少高扇出，争取高扇入
? 模块调用的直接下层模块的个数，称为扇出
(Fan out)
? 模块被其他各模块调用的个数，称为扇入 (Fan
in)
? 原则：扇出不宜过大,<=7；扇入尽可能大些。
但 CASE(分类 )型模块扇出可 >7,因为属自然分
类情况,易理解
(4,0)
(3,1)(5,1)
(0,2)
符号,
(扇出,扇入 )
(5)减少高扇出，争取高扇入 (续 )
清真寺型
不够好,底层模块复用度低
金字塔型
(5)减少高扇出，争取高扇入 (续 )
相关技巧：
?良好的结构图往往呈, 清真状,,即
,顶为尖 —下 层逐渐加宽 —底层收窄,
?结构图的形态应该均衡，即从顶到底
层的路径长短不该过于悬殊
(6) 模块大小适中
?模块过大：可理解程度下降
考虑对该模块分解
?模块过小：开销大于有效操作，
系统接口复杂
考虑是否同它的调用模块合并
(6) 模块大小适中 (续 )
几种情况下的小模块不合并：
?模块具有独立的功能
?模块功能可能会发生变化
?模块的复用性好，或者其调用模
块很复杂
(7)降低模块接口的复杂性
接口传递信息应简单且和
模块功能一致。
例：求一元二次方程的根
设求根模块调用形式为：
(1) QUAD－ ROOT(TBL,X)
传递系数的数组 存放根的数组
(2) QUAD－ ROOT(A,B,C,ROOT1,ROOT2)
A,B,C为方程系数
ROOT1,ROOT2是两个根
(8) 模块功能可预测
?可将模块看成黑盒子，相同输入可
产生相同输出，称其功能为可预测
的。
?模块带有内部状态，其功能可能是
不可预测的。这样的模块难理解、
难测试、难维护。
实例 1——银行贷款文件管理
实例 1——银行贷款文件管理
本实例说明用 SA方法进行分析，并用 SD
方法设计总体结构的过程。
?问题描述
?系统分析
?系统设计
1 问题描述
本系统 MFUP是银行贷款文件管理的
一部分,对贷款文件进行修改 。其主要
功能是：根据对贷款账户的修改信息修
改贷款文件中相应账户的记录内容，这
些修改信息记在一叠按账号排列的修改
卡片上。系统将被修改的记录打印一份
报告，并报告修改中出现的错误信息。
1 问题描述 (续 )
贷款文件格式：
每个账户在贷款文件中有一个记录，每个
记录由 14个数据项组成。（见下表）
贷款文件按账号递增排列，文件存放在 磁
带（顺序文件！） 上。每个账户的地址、电
话、邮政编码、负责与账户联系的银行信贷
员等都有可能发生变化。
序号 内 容 长度 (位 ) 数据类型 可否修改
1
2
3
4
5
6
7
8
9
10
11
12
13
14
账号
户名
地址
省
市
邮政编码
电话
类型
信贷员号
最近一次业务日期
最近一次付息日期
余额
业务总量
限额
5
30
30
10
15
5
7
1
5
6
6
8
8
6
数字
数字字母
数字字母
字母
字母
数字
数字
字母
数字
数字
数字
数字
数字
数字
否
可
可
可
可
可
可
否
可
否
否
否
否
否
1 问题描述 (续 )
修改卡片格式：
卡片的第 1-5位指出要修改的记录的账号，第 6-9位
为空，从第 10位开始为如下格式：
xx abcd…pqr*xx abc…stu*xx abc…uvw**
xx是两位数字，指出要修改的数据项序号，后面的
abcd…pqr 是这个数据项的修改值,*表示数据项的
结束，每张卡片的最后一个数据项结束是 **。
例,68371 07 2692386* 02 HUADA XINXI01**
表示要修改账号为 68371的记录，第 7项改为 2692386，第 2 项
改为 HUADA XINXI01。
1 问题描述 (续 )
修改规定：
? 修改值的长度小于数据项的指定长度时，如
果该项是数字项，则在其左边补零；否则在
右边补空格。
? 修改值的长度超过数据项的指定长度时，则
需截短
? 第 6 项邮政编码的修改值必须是 5 位
修改卡片按账号递增排列
1 问题描述 (续 )
基本过程：
? MFUP读入一叠修改卡片，检查卡片的排列次序以
及卡片上的修改信息是否合理，然后对旧文件作修
改，产生一个修改后的新文件，并将被修改的记录
打印成一份报告。
? MFUP将拒绝以下不合理的修改信息，并报告错误：
?修改卡片的账号没有按递增次序排列，或贷款文
件中没有这个帐号
?数据项序号不在 1-14之间
?数据类型不符
?企图修改不准修改的数据项
2 系统分析
0
银行贷款
文件修改
MFUP
0层图
修改卡片
(旧记录 )
(新记录 )
报告
未修改的
文件记录
修改后的
文件记录
2 系统分析 (续 )
1
检查
顺序
1层图
修改卡片
旧记录
新记录
报告
2
编辑
卡片
3
账号
相等?
4
修改
记录
5
写
记录
顺序
卡片
要修改的记录
不要修改
的记录
已修改
的记录
错误 修改信息
6
产生
报告
已修改
的记录
修改信息，
错误
2 系统分析 (续 )
2.1
抽出
修改项
2层图 ( 加工 2 的子图 )
顺序卡片 修改信息
错误
2.2
第 1项
错误
2.3
第 2项
2.4
第 3项
2.15
第 14项
2.16
收集
修改项
错误
……
3 系统设计
1）转换策略：
本系统结构是总体 ——变换型
局部 ——事务型
(“编辑卡片”子加工 )
所以采用的转换方法为对整个系统使用
“变换分析”，对系统的局部用“事务分析”
的方法。
3 系统设计 (续 ) ——方案 1
1
检查
顺序
1层图 ——变换型
修改卡片
旧记录
新记录
报告
2
编辑
卡片
3
账号
相等?
4
修改
记录
5
写
记录
顺序
卡片
要修改的记录
不要修改
的记录
已修改
的记录
错误 修改信息
6
产生
报告
已修改
的记录
修改信息，
输入部分
主加工部分
输出部分
错误
3 系统设计 (续 )——方案 2
1
检查
顺序
1层图 ——变换型
修改卡片
旧记录
新记录
报告
2
编辑
卡片
3
账号
相等?
4
修改
记录
5
写
记录
顺序
卡片
要修改的记录
不要修改
的记录
已修改
的记录
错误 修改信息
6
产生
报告
已修改
的记录
修改信息，
输入部分
主加工部分
输出部分
错误
3 系统设计 (续 )
说明：
变换分析设计方法的第一步，首先要将 DFD中的
所有处理划分成主加工、输入和输出三个部分。这
是根据 DFD中的处理所完成的功能 来确定的。
? DFD中的处理，如果“流入”和“流出”的数据流
的内容没有发生改变，只是性质（即正确与否）或
状态（格式的调整）等发生改变，则这个处理是属
于输入处理或输出处理的部分。
? 如果“流入”和“流出”的数据流的内容发生改变，
则这个处理是属于主加工的部分。
每个人对 DFD中每个处理所作功能的理解都可以
有自己的看法，找出来的主加工可能也不同，但一
般不会相差太远。
3 系统设计 (续 )
说明 (续 ):
处理数据 a 数据 b
数据 a->b改变的是,处理属于：
状态 /性质 输入 /输出处
理部分
内容 主加工部分
检查
正确性
入库单 正确的入库单
计算电费用电量 电费
例如：
流进 -流出的数据流内容没变，
所以是 输入处理 部分
流进 -流出的数据流内容变了，
所以属于 主加工 部分
3 系统设计 (续 )
说明（续）,
例如，本例就可能有两种划分结果，得出了不同
的“输入 -主加工 -输出”边界，都有道理。但是应注
意的是，作了不同划分后，接下来 产生的初始模块结
构图 就会有所不同。但是经过结构图的改进步骤后，
得出的最终系统模块结构图也是差不多的。
接下来以第一种划分方案，讲解转换策略及结构图
的调整。第二种划分方案的转换怎么做，大家可作为
课后思考。
3 系统设计 (续 ) ——方案 1
2.1
抽出
修改项
2层子图 ——事务型
修改信息
错误
2.2
第 1项
错误
2.3
第 2项
2.4
第 3项
2.15
第 14项
2.16
收集
修改项
错误
……
事务
中心
3 系统设计 (续 )
2)系统初始模块
结构图,主模块 MFUP
取得
旧记录
取得修
改信息
记录
匹配判断
(账号相等?)
修改
记录
输出修
改后的
记录
写记录
修改
信息
记录
修改信息
记录
修改信息
记录
记录
编辑
卡片
取得顺
序卡片
卡片 卡片 修改信息
检查顺序读卡片
打印报告产生报告
卡片 卡片 ok
记录
报告
报告
3 系统设计 (续 )
2)系统初始模块结构图, (“编辑卡片”分支 )
编辑卡片
抽出
修改项
编辑
第 1项
卡片
编辑
第 2项
修改项
调整
项 2
第 1项
编辑
第 3项
编辑
第 14项… …
第 2项 第 3项
第 14项
调整
项 3
okok
ok
ok
卡片 修改信息
3 系统设计 (续 )
3) 改进优化模块结构图,
? 消除重复的功能 (共同的操作 )
? 作用范围应是控制范围的子集
3 系统设计 (续 )
分析 1——共同的操作：
在对各个修改项的处理动作是类
似的。
3 系统设计 (续 )
修改 1-1：把逻辑上相似的模块合并起来，
会形成“逻辑型”模块。
如 1,6,9 项合并处理，但又各有不同。 1
项不允许改,6项必须 5位,9项可补零等。
模块中必须设开关量来区分不同的情况，且
可维护性差。
3 系统设计 (续 )
修改 1-1：简单合并，形成,逻辑型,模块。
编辑卡片
抽出
修改项
编辑第
1,6,9项
卡片
编辑第
2,3项
修改项
调整
项 2,3
第 1,6,
9项
编辑
第 4项
编辑第
12,13项… …
第 2,3
项
第 4项
第 12,
13项
调整
项 4
okok
ok
ok
卡片 修改信息
3 系统设计 (续 )
修改 1-2：不合并“编辑卡片”的各个下层模块，
但运用“消除重复操作”的技巧，抽出共同的
操作，形成操作层和细节层。
操作层如,拒绝非字母项”,,拒绝非数字
项”,调整修改项的长度” (在数字项前补零、
在字母项后补空格、截去过长的修改项等 )，它
们可以由事务层的 14个模块中的几个模块共用。
操作层的模块又包含共同的细节，如“查字符
类型”,“查字符串长度”、“显示出错信息”
等。
3 系统设计 (续 )
修改 1-2：
抽出共同操作。 编辑卡片
抽出
修改项
编辑
第 1项
卡片
编辑
第 2项
修改项
第 1项
编辑
第 3项
编辑
第 14项… …
第 2项 第 3项 第 14项
ok
卡片 修改信息
… …
…
拒绝非
N非 C项
拒绝
非 N项
拒绝
非 C项
调整
长度
拒绝
过长项
拒绝
过短项
检查字
符类型
检查字符
串长度
操作层
细节层 报告错误信息
… …
3 系统设计 (续 )
分析 2——模块大小：
抽出共同操作模块后，模块“处理修改
项 1,8,10 …” 等的功能都只是显示出错
信息，因此非常简单。
修改 2：将它们合并到上层模块‘编辑修
改项’中。
3 系统设计 (续 )
修改 2：将小模块合并到上层模块。 (界面略 )
编辑卡片
抽出
修改项
编辑
第 2项
卡片
编辑
第 3项
修改项
编辑
第 4项
编辑
第 9项
卡片 修改信息
编辑
第 5项
编辑
第 6项
编辑
第 7项
包含, 修改
1,8,10,11-14 项
” 的功能语句
… … … … …
3 系统设计 (续 )
分析 3——作用范围：
MATCH模块中的判定影响到‘ GET
记录’和‘ GET卡片’模块。
修改 3：将判定往上层移动。
3 系统设计 (续 )
修改 3：将判定往上层移动。
主模块 MFUP
取得
旧记录
取得修
改信息
记录
包含 (账号相等?)
的匹配判断
修改记录 输出报告写记录
修改
信息
记录
修改信息
记录
报告
卡片 卡片 修改信息
记录
报告
报告
… … … …
实例 2——病人监护系统
实例 2——病人监护系统
本实例说明改进模块结构图的过程，
在改进过程中运用了一些 SC优化技巧。
?问题描述
?初始 SC
?SC的改进
?进一步优化
?总结
1 问题描述
本系统 MNPA是某医院的一个病人监护系统,
其功能如下：
所有的病人都由专门的设备进行监视，设备同病
床相连，这些设备可以测量病人的脉搏、体温、血压、
呼吸 …… 等项目（下面称这些项目为因素）。系统每
过一定的时间间隔从监视设备读入上述因素,并把它
们存入数据库中。医生为每个病人指定了各种因素的
安全范围（如 312号病人的体温安全范围是 36。 C~38.5。
C)，如果系统发现某个因素值越出安全范围,或发现
某个监视部件有故障,则向护理站发出通知：如果是
因素越限则报告病人号；如果是监视部件故障则报告
床位号。
1 问题描述 (续 )
监视部件故障：
? 两种可能的设备故障
监视设备读出的数据由七个因素值及一个硬
件故障标志字组成。
1)硬件故障标志字：七个二进制位，说明测量
这七个因素的硬件是否有效（如：某个硬件
单元是否已接入电路中）
如,1110101 表示第 4,6个硬件故障，其
测出的因素值无效 1-有效 0-无效
1 问题描述 (续 )
监视部件故障 (续 )：
2)设备软件故障：即监视设备测出的因素值不
合理（如：体温测出 52。 C的不合理值等）。
? 故障处理
?在硬件故障标志字指出硬件无效或软件检
查出因素值不合理时，都应 作为监视设备
故障向护理站报告
?将这些因素值 存入数据库时应加上标志,
指出它们是无效的
1 问题描述 (续 )
数据存储：
数据库中的数据应该 可以按病人号进行
检索 。各因素是相互无关的，其格式和
长度均不相同。在数据库中,不必标出
个因素值是否安全 。
注：因素值无效与因素值安全是两个概念。
比如体温为 39。 C是有效的，却是不安全的。
病人监护系统
处理因素值检查因素值获得因素值
检查不合理
因素值
读取病床
因素值
读取病
人信息
检查
不安全
因素
读取安全
值范围
存入
数据库
报告错
误设备
报告
不安全
因素
Pn,
Factors,EOF
Error Flags
Factors,
Safe Ranges
Error Flags
Unsafe Flags,
Error Flags
Pn,Factors,
Error Flags
Pn,
Factors,
Error Flags,
Unsafe Flags
Pn,Bednum
EOF
Factors,
Error Flags
Pn,Factors
Error FlagsBednum
PnFactors
Error
Flags2
Unsafe
Flags
Safe
Ranges
Pn,Factors
Unsafe FlagsPn,
Error
Flags
参数说明,Pn-病人号 Bednum-病床号 Factors-七个因素值
SafeRanges-因素安全值范围 EOF-本次巡视已处理过最后一个病人信息
Error Flags2-各因素值是否合理 UnsafeFlags-因素值是否安全
* ErrorFlags-硬件故障标志字；设备故障标志字
2 初始结构图
2 初始结构图 (续 )
? 模块,检查因素值,调用三个下层模块分别
完成三个功能：
1）查出不合理的因素值（‘ 检查因素值 ’模
块中再将 Error Flags2和硬件故障标志字合并
成设备故障标志 Error Flags)
2)查出某病人的因素安全值范围
3)决定病人的因素值是否安全
? 模块,处理因素值,将数据存入数据库，并
在发现不安全因素或设备故障时通知护理站
3 结构图的改进
使用技巧,
? 减少块间联系，主要是减少模块之间传送的
参数个数
? 消除“管道性”模块
? 消除重复的功能
? 如果一个模块篇幅较大，可考虑分解
? 如果一个模块篇幅较小，可考虑同其调用模
块合并
? 要考虑将来可能发生的变化和扩充
3 结构图的改进 (续 )
病人监护系统
处理因素值检查因素值获得因素值
检查不合理
因素值
读取病床
因素值
读取病
人信息
检查
不安全
因素
读取安全
值范围
存入
数据库
报告错
误设备
报告
不安全
因素
Pn,
Factors,EOF
Error Flags
Factors,
Safe Ranges
Error Flags
Unsafe Flags,
Error Flags
Pn,Factors,
Error Flags
Pn,
Factors,
Error Flags,
Unsafe Flags
Pn,Bednum
EOF
Factors,
Error Flags
Pn,Factors
Error FlagsBednum
PnFactors
Error
Flags2
Unsafe
Flags
Safe
Ranges
Pn,Factors
Unsafe FlagsPn,
Error
Flags
缺少
Bednum
3 结构图的改进 (续 )
改进一：
减少块间联系，主要是减少模块之间传送的
参数个数，简化模块之间的界面
分析：,病人监护系统” ——“处理因素值”的界面
1),处理因素值”接收的参数 unsafe flags，除了“报
告不安全因素”要用到，其另两个下层模块不必用
到这一参数；且“报告不安全因素”不返回任何参
数给“处理因素值” ；“报告不安全因素”所需的
参数在主模块“病人监护系统”中都有；所以将它
改成由主模块直接调用。这样又可简化 unsafe flags
这一参数。
3 结构图的改进 (续 )
分析：,病人监护系统” ——“处理因素值”的界面
2) 同理，主模块可以直接调用“存入数据库”，这样，
主模块“病人监护系统”与“处理因素值”的界面
又可以消去 Factors这一参数。
3 结构图的改进 (续 )
分析：,病人监护系统” ——“处理因素值”的界面
3) 现在,“处理因素值”的功能仅仅是调用“报告错
误设备”，所以它可以合并到主模块中去。
3 结构图的改进 (续 )
分析：,病人监护系统” ——“处理因素值”的界面
说明 ——
“处理因素值”模块并没有做什么实质性的工作，
而只是像“管道”一样，将一些参数从主模块传送
到它的几个下层模块,而这些模块完全可以由主模
块直接调用。
3 结构图的改进 (续 )
改进二,消除重复的功能
分析：,报告错误设备”模块
1),报告错误设备”模块应该向护理站报告故障设备
的床位号而不是病人号，所以应该在这个模块中包
含从病人号查出床位号的功能。而模块“读取病人
信息”已经含有这个功能。所以可把它提供的
BedNum参数回送给主模块，再由主模块传送给
“报告错误设备”模块，但这样增加了块间联系。
如果改为由“读取病人信息”直接调用“报告错误
设备”，则可将传送给主模块的参数 BedNum消去，
可减少块间联系。
3 结构图的改进 (续 )
分析：,报告错误设备”模块
2) 又因为无论是硬件故障或者测得的因素值不合理，
都应作为设备故障通知护理站，所以应在通知护理
站之前调用“检查不合理因素值”，于是改为由
“读取病人信息”直接调用“检查不合理因素值” 。
这样一来，也简化了“检查因素值”的界面，因为
它不必再回送 Error Flags了。
3 结构图的改进 (续 )
病人监护系统
检查因素值获得因素值
检查不合理
因素值
读取病床
因素值
读取病
人信息
检查
不安全
因素
读取安全
值范围
存入
数据库
报告错
误设备
报告
不安全
因素
Pn,
Factors,EOF
Error Flags
Factors,
Safe Ranges
Error Flags
Unsafe Flags,
Error Flags
Pn,Factors,
Error Flags
Pn,Bednum
EOF
Factors,
Error Flags
Pn,Factors
Error Flags
Bednum
Pn
Factors Error Flags2
Unsafe
Flags
Safe
Ranges
Pn,Factors
Unsafe Flags
Bednum,
Error Flags
3 结构图的改进 (续 )
检查因素值获得因素值
检查不合理
因素值
读取病床
因素值
读取病
人信息
检查
不安全
因素
读取安全
值范围
存入
数据库
报告错
误设备
报告
不安全
因素
Factors,
Safe Ranges
Error FlagsPn,BednumEOF Factors,Error Flags
Bednum
Pn
Factors
Error
Flags2
Unsafe
Flags
Safe
Ranges
Bednum,
Error Flags
产生一
行通知
在设备上
输出一行
从病人
号查
床位号
Bednum
Pn
Pn
改为‘获得
病人因素值’
独立出来形成
‘获得病床因素
值’
3 结构图的改进 (续 )
检查因素值获得因素值
获得病床
因素信息
获得病人
因素值
读取病
人信息
检查
不安全
因素
读取安全
值范围
存入
数据库
报告错
误设备
报告
不安全
因素
Factors,
Safe Ranges
Error FlagsPn,EOF Factors,Error Flags Pn
Bednum
Unsafe
Flags
Safe
Ranges
Factors,
Error Flags
产生一
行通知
在设备上
输出一行
从病人
号查
床位号
Bednum
Pn
Pn
Bednum,
Error Flags
Line
Line Line
Unsafe
Factor,
Factor Type
检查不合理
因素值
Factors Error Flags2
篇幅小，
可往上
层合并
3 结构图的改进 (续 )
分析：,报告错误设备”模块
3),报告错误设备”和“报告不安全因素”都需要为
护理站打印一些信息。为了消除重复的功能，也为
了在将来护理站或打印设备情况有改变的时候不必
牵涉到两个模块的修改，可以将这一功能抽出,形
成一个新的模块“在设备上输出一行”,使得“报
告错误设备”和“报告不安全因素”都调用此模块。
3 结构图的改进 (续 )
改进三,模块的分解
分析：,报告不安全因素”模块
考虑到该模块的篇幅可能较大，可以把“产生一行
通知”的功能单独抽出来，形成其调用的一个下层
模块。
3 结构图的改进 (续 )
改进四：模块独立性的考虑 ( 简化联系、
分解、模块复用、合并 )
分析：,读取病床因素值”模块
1)简化联系 ——考虑使“读取病床因素值”包括从
病人号查床位号的功能，则“读取病人信息”的界
面中就可以消去 BedNum这个参数，从而减少块间
联系。
3 结构图的改进 (续 )
分析：,读取病床因素值”模块
2)分解 ——考虑到“读取病床因素值”这个模块本
身的篇幅已不小，所以将“从病人号查床位号”的
功能由它的一个下层模块来完成。此外，为了使模
块名恰当地反映模块的功能，应将“读取病床因素
值”改名为“获得病人因素值”。
说明：病人信息指基本信息，如姓名、性别等
病人因素值指病人疾病信息，如血压、体温等。
3 结构图的改进 (续 )
分析：,读取病床因素值”模块
3)功能模块的独立性与复用 ——现在，根据某个床
位号从监视设备读入相应因素的一段程序是隐含在
模块“获得病人因素值”中的，但是设备检修人员
可能要在其他系统中使用这段程序（ 模块复用 ），
他们关心的是某床位的设备如何，而不管床上是否
有病人，或病人是谁。所以这段程序还是抽出来，
单独组成一个模块“获得病床因素信息”较好。
3 结构图的改进 (续 )
分析：,读取病床因素值”模块
4) 模块的合并 ——现在,“获得病床因素信息”和
“检查不合理因素值” 篇幅都不长，可以将后者合
并到前者。
3 结构图的改进
(续 )
检查因素值获得因素值
获得病床
因素信息
获得病人
因素值
读取病
人信息
检查
不安全
因素
读取安全
值范围
存入
数据库
报告错
误设备
报告
不安全
因素
Factors,
Safe Ranges
Error FlagsPn,EOF
Factors,
Error Flags Pn
Bednum
Unsafe
Flags
Safe
Ranges
Factors,
Error Flags
产生一
行通知
在设备上
输出一行
从病人
号查
床位号
Bednum
Pn
Pn
Bednum,
Error Flags
Line
Line
Line
Unsafe
Factor,
Factor Type
病人监护系统
Pn,
Factors,EOF
Error Flags Unsafe
Flags
Pn,Factors,
Error Flags
Pn,
Factors,
Error Flags
Pn,
Factors,
Unsafe Flags
检查因素值获得因素值
获得病床
因素信息
获得病人
因素值
读取病
人信息
检查
不安全
因素
读取安全
值范围
存入
数据库
报告错误设备
报告
不安全
因素
Factors,
Safe Ranges
Error FlagsPn,EOF Factors,Error Flags Pn
Bednum
Unsafe
Flags
Safe
Ranges
Factors,
Error Flags
产生一
行通知
在设备上
输出一行
从病人
号查
床位号
Bednum
Pn
Pn
Bednum,
Error Flags
Line
Line Line
Unsafe
Factor,
Factor Type
Unsafe Flags Pn,Factors,
Unsafe Flags
3 结构图的改进 (续 )
改进五,简化联系
分析：,检查因素值”和“报告不安全因素”模块
改为由“检查因素值”直接调用“报告不安全因
素”，则可以消去参数 Unsafe Flags。这又可以减
少块间联系。此时，将“检查因素值”改名为“输
出不安全因素值”。
3 结构图的改进 (续 )
改进六：其他 (一种典型的改进情况 )
分析：,报告错误设备”模块
考虑由“获得病床因素信息”来调用“报告错误设
备”。在某个故障设备的修理期间，这个程序模块将
重复地向护理站报告该设备已坏。这是令人讨厌的。
如果改由,获得病人因素值”调用“报告错误设备”
模块，则会灵活一些。
这种情况是 较典型 的：
如果一个模块检测出错误后，
1)要报告错误信息； 2)要将一个出错标志回送给它
的调用模块
不如改为由调用模块按出错标志的值决定是否要报
告错误信息更灵活、更清楚些。
3 结构图的改进
(续 )
检查因素值获得因素值
获得病床
因素信息
获得病人
因素值
读取病
人信息
检查
不安全
因素
读取安全
值范围
存入
数据库
报告错
误设备
报告
不安全
因素
Factors,
Safe Ranges
Error Flags
Pn,EOF
Factors,
Error Flags Pn
Bednum
Unsafe
Flags
Safe
Ranges
Factors,
Error Flags
产生一
行通知
在设备上
输出一行
从病人
号查
床位号
Bednum
Pn
Pn
Bednum,
Error Flags
Line
Line Line
Unsafe
Factor,
Factor Type
病人监护系统
Pn,
Factors,EOF
Error Flags Pn,Factors,
Error Flags
Pn,
Factors,
Unsafe Flags
Pn,
Factors,
Error Flags
4 结构图的进一步优化
改进七：考虑系统将来的变化与扩充
结构图中许多模块界面都带有参数 Factors和
Error Flags，这两个参数表示了七个不同类型、
不同长度、相互无关的因素及它们的错误标志，
共 14个数据项。因此，多个模块中均包含与因
素的个数、格式、长度有关的程序。 一旦将来
增加了监视的因素个数,或改变因素的格式、
次序,所有这些模块都必须作修改。
4 结构图进一步优
化 (续 )
检查因素值获得因素值
获得病床
因素信息
获得病人
因素值
读取病
人信息
检查
不安全
因素
读取安全
值范围
存入
数据库
报告错
误设备
报告
不安全
因素
Factors,
Safe Ranges
Error Flags
Pn,EOF
Factors,
Error Flags Pn
Bednum
Unsafe
Flags
Safe
Ranges
Factors,
Error Flags
产生一
行通知
在设备上
输出一行
从病人
号查
床位号
Bednum
Pn
Pn
Bednum,
Error Flags
Line
Line Line
Unsafe
Factor,
Factor Type
病人监护系统
Pn,
Factors,EOF
Error Flags Pn,Factors,
Error Flags
Pn,
Factors,
Unsafe Flags
Pn,
Factors,
Error Flags
篇幅小，
可往上
层合并
4 结构图的进一步优化 (续 )
改进七：考虑系统将来的变化与扩充 (续 )
因此，改为每次传送一个因素、一个因素类型及一
个错误标志,则每个界面将只传送三个数据项。
“获得病床因素值”就成为唯一一个与因素个数、
格式有关的模块。这样,其他原来有关的模块中控
制处理七个因素的循环就可取消，各模块的名字也
应相应修改一下，体现它们的功能是处理 一个 因素。
另外,“获得病床因素值”应在回送一个参数给
“获得病人因素值”说明最后一个因素已处理完
(FEOF)，而“获得病人因素值”应再将 FEOF回送
到上一级。
4 结构图的进一步优化 (续 )
改进七：考虑系统将来的变化与扩充 (续 )
现在“检查不安全因素”只是检查一个因素是否
安全，因而很简单,可以同它的调用模块“输出
不安全因素值”合并。
检查单因素值获得单因素值
获得病床
单因素 信息
获得病人
单因素 值
读取病
人信息
读取安全
值范围
存入
数据库
报告错
误设备
报告
不安全
因素
Pn,EOF
Factor,
Type,
FEOF
Pn,
Type
Bednum
Safe
Range
Factor,Type
Error,FEOF
产生一
行通知
在设备上
输出一行
从病人
号查
床位号
Bednum
Pn
Pn
Bednum,
Type
Line
Line Line
Type,
Unsafe Factor
病人监护系统
Pn,
Factor,EOF
Type Pn,Factor,
Type
Pn,
Type,
Unsafe Factor
Pn,
Factor,
Type
4 结构图进一步优
化 (续 )
5 总结
? 改进的过程有很强的试探性,需对各种可
能的方案作比较和权衡。
? 运用 DFD->SC的转换策略，可以得到质量
较好、结构较合理的初始模块结构图。
思考
1）根据“银行贷款文件修改系统”的问
题描述画出 DFD图，运用转换方法画出
相应的模块结构图，并进行优化。
2）根据结构图优化原则对“病人监护系
统”的初始模块结构图进行改进。
系 统 设 计
第一节 系统设计概述
系统设计是新系统的物理设计阶段，根据
系统分析阶段所确定的新系统的逻辑模型，
综合考虑各种约束，利用一切可用的技术手
段和方法，进行各种具体设计，提出一个能
在计算机上实现的新系统的实施方案，解决
,系统怎样做, 的问题。
系统设计概述
系统 设计概述
?目标和任务
?系统设计模型
?设计方法
?主要内容
解决系统,怎样做（ How to do）, 的
问题。
1 系统设计的目标
系统分析：解决, 做什么,
系统设计：解决, 怎么做,
一、系统设计的目标和任务
2 系统设计的任务
问题结构 (系统需求 ) 系统结构
从系统分析说明书出发，形成系统的
具体设计方案。
一、系统设计的目标和任务 (续 )
映射
数据
字典
数据
流图
E-R图
加工小说明
流 程
描
述
处理描述
数
据
对
描
述
象
数 据 设 计
模块结构设计
接口设计
过程设计
分析模型 设计模型
平 台 设 计
二、系统设计模型
二、系统设计模型 (续 )
上图中通过数据、功能模型展示的系统需
求被传送给设计阶段，运用某种设计方法，
设计阶段产生出：
? 数据设计,将分析时创建的数据模型变换成实现
系统所需的数据结构。
? 平台设计,将性能要求变换成对系统软硬件环境
的配置
? 模块结构设计,定义系统模块元素之间的关系。
?接口设计,描述了系统内部、系统和协作系统之
间的以及系统同人之间如何通信。
? 过程设计,将加工说明变换为对系统模块内部算
法的具体描述。
三 系统设计方法
?结构化设计方法 (SD)
?面向数据结构的设计方法 (JSD方法 )
?面向对象的设计方法 (OOD)
四 系统 设计主要内容
? 系统总体设计
? 系统详细设计
? 系统平台设计
? 代码设计
? 输入输出设计
? 对话设计
? 数据库或数据文件设计
? 模块内部的算法设计
? 写出系统设计报告
总体设计：
告诉用户系统具体将要做什么 。 一旦
用户同意了这个总体设计, 我们会将
这个总体设计转换为更加详细的文档 。
1 系统总体 设计
总体设计包括：
? 工具 — 如何描述系统的 总体结构
? 方法 — 用什么方法把问题结构导出系统
结构
? 评价准则 — 什么样的系统结构是, 最优
的,
1 系统总体 设计（续）
1 系统总体 设计（续）
总体结构：
? 系统的组成部分，即有哪些模块组成
? 系统的层次及调用关系
? 模块的处理功能
? 模块之间的界面，即模块间传递的数据
优秀的总体设计应该包含以下特征
? 不包括用户不熟悉的专业词汇
? 它描述系统功能
? 独立于实现过程
? 与系统分析文档相一致
2 系统详细 设计
详细设计：
让系统建设者了解要解决用户的问题所需
要的硬件和系统。主要描述系统的硬件配置
、系统代码、人机界面、输入和输出、数据
库和网络体系结构等。也就是说，详细设计
是系统说明的一个 技术层面 上的描述。
2 系统详细 设计（续）
详细设计包括：
? 系统平台设计
? 代码设计
? 数据库设计
? 对话（人机界面）设计
? 输入 /输出设计
? 模块内部的算法设计（处理流程设计）
第二节 结构化系统设计
结构化系统设计
结构化系统设计是, 用一组标准的准则
和工具帮助系统设计人员确定应该由哪些模
块，用什么方式联结在一起，才能构成一个
最好的系统结构, 。
即，结构化设计方法 (SD)是以数据流图
为基础的,采用 模块化、自顶向下逐步求精
的基本思想，以 数据流图为基础 构造出模块
结构图。
? 采用分解的方法,即把系统分解成由相对
独立的、功能单一的若干模块组成的结构
? 采用图形表达工具
? 有一组基本的设计原则
? 有一组基本的设计策略
? 有一组评价标准和优化技术
一 结构化系统设计的特点
二 结构化系统设计的基本工具
在系统设计阶段，我们采用 模块结
构图 来表达目标系统的物理模型，描
述系统的结构。
三 结构化系统设计原则
? 系统的观点
? 模块化结构
? 阶段性策略
? 模块的独立性
? 鼓励用户积极参与设计
第三节 系统总体设计
系统总体 设计（主要内容）
?系统的分解方法
?模块结构图
?基本设计原则 （模块耦合度与聚合度）
?设计策略 （变换型、事务型）
?设计优化技巧
一 系统的分解方法
? 系统分解的方法是把一个复杂的问题分解
成简单的要素，把一个统一的整体分解为
各个组成部分，然后对各个要素和组成部
分分别进行研究。
? 借助于目标系统的逻辑模型 (DFD)并根据
部门机构设置情况进行系统分解
1.系统分解的原则
? 明确系统分解前、后的功能尽量一致
? 每次分解的结果是可以独立开发的子系
统 (或模块 )
? 各子系统 (或模块 )间的关联尽量少
? 制定子系统 (或模块 )间的约束规范
? 区别稳定的和易变的子系统 (或模块 )
2.系统分解的方法
(一 )按企业业务管理部门划分
如：生产、销售、供应管理等；按部门设置
(二 )按完成功能的类型来划分
如：顾客服务、技术与生产数据管理；按实际职
能设置
二 模块结构图
结构化设计方法的基本思想就是模块
化。即对每一个系统按功能逐步由顶向
下，由抽象到具体的逐层分解，将系统
分解成为多层次的独立功能模块，一直
分解到能简单地用程序实现为止。
总体设计任务
（一） 模块
? 模块的定义,
模块是可以组成、分解、更换的系统，是
易于处理的基本单位，具有四种属性的一
组程序语句称为一个模块，这四种属性分
别是输入输出、逻辑功能； （ 外部特性 ）
内部数据、程序代码。 （ 内部特性 ）
（一） 模块 (续 )
? 模块的例子,
int max( int x,int y)
{ int z;
z=x>y? x,y;
return(z);
}
模块名
数
据
内部
数据
内部
语句
模块化思想：
?模块化是好的系统设计的一个基本准
则
从整体上把握
问题,暂不考虑细节
?复杂问题 较小问题
分解
可减小解题所需的总的工作
分解
模块和子系统的区别
模块和子系统的概念是有所区别的。子系
统仍具有系统的特征（ 更大 ），模块则是指
为完成某项功能的程序集合体（ 较小 ），它
是一个不可分割的整体，但模块和子系统的
概念有时又是兼容和不可绝对区分的。在日
常工作中我们常将完成一个管理功能的程序
集称为模块，而它常常由多个很小的程序子
模块组成，所以有的地方可称为子系统。
(二 ) 模块结构图 sc
1,结构图的产生
程序流程图 系统流程图和功
能图 HIPO技术 (功能图和 IPO
图 ) 结构图 (Structure Chart)。
2.结构图的主要成分
? 模块 ——用方框表示，方框中写上模块
名字，反映了这个模块的功能
? 调用 ——从调用模块指向被调用模块的
箭头
? 数据 ——调用箭头旁的小箭头，表示从
一个模块向另一个模块传送的数据，也
指出了传送的方向
3.结构图基本符号及表示法
编辑学生记录
读学生记录
学生数据
无此学生
学号
不加区分的数据
数据信息
控制信息
? 模块调用的例子,
int max( int x,int y)
{ int z;
z=x>y? x,y;
return(z);
}
Main( )
{,
:
max( 3,4)
:
}
Main()
求最大值
Zx
y
SC中的四种模块
传入模块
(a) (b)
A
A
传出模块
B
B
变换模块
(c)
C D
协调模块
E
(d)
E F F
SC中的简单调用
B
A
C
x,y z
(a)表示法一 (b)表示法二
z B
A
C
1 2
入 出1
2
x,y
z
zA调用 B和 C
SC中的选择调用
A
CB D
A根据内
部判断决
定是否调
用 B
A按另一判
定结果选择
调用 C或 D
SC中的循环调用
A
B C
A根据循环条件重复调
用 B,C等模块
? 选择调用的例子,
A( )
{,
if (条件,.)
B( )
else
C( )
:
}
A
B C
? 循环调用的例子,
A( )
{,
while (条件,.)
{
B( );
,;
}
:
}
A
B
4.模块结构类型
内导结构：是结构图中数据以最低层模块
输入，并逐级向高层传递，高一层模块接
收低一层模块的输入。
主模块
A1
A4A3
A2
外导结构：结构图中低一层模块接收上
一层模块的数据信息，并把它们转换给
下一级模块，直到输出给使用者。
w u
子模块 1
v
主模块
子模块 2
子模块 2.1
转换结构：数据要在模块内经过一定的
处理，下层模块从相应的上层模块接收
数据，经转换后返回同一上层模块中去。
w u
子模块 1
v
主模块
子模块 2
子模块 2.1
X M
Y
4.结构图与数据流图的差别
? 数据流程图是从数据流着眼，而结构图从程序模
块着眼 ;
? 数据流程图描述的是系统的逻辑模型，而结构图
是描述系统的物理模型 ;
? 数据流程图是用不同的图来表示不同的层次，是
“平面图”，而结构图能反映系统的层次结构，
是“立体图” ;
? 数据流程图是从具体到抽象，描述系统的要求，
而结构图是从抽象到具体，描述系统的实现方法。
（三） 模块设计的原则
系统的 可维护性 是系统评价的一个重要因素
可维护性 局部修改
模块间的联系尽可能的少 （耦合）
而模块内的联系尽可能多 （聚合）
1.模块的独立性
模块独立的含义：
?模块完成独立、单一的功能
?符合信息隐蔽和信息局部化原则
?模块间关连和依赖程度尽量小
2.模块独立性的度量
模块独立性取决于模块的内部和外部特
性。
SD方法提出的定性的度量标准：
? 模块之间的 耦合性（块间联系）
? 模块自身的 聚合性（块内联系）
3.模块独立性的度量之一：耦合度
? 耦合度 是模块间的联结关系，衡量
不同模块间的相互依赖的紧密密程度，
耦合的强弱取决于模块间接口的复杂程
度；进入或访问一个模块的入口点；以
及通过接口的数据。
? 耦合度越高，模块独立性越弱
无耦合－没有依赖关系
松散耦合－有
少量依赖关系
紧密耦合－有
很多依赖关系
模块耦合度（续 ）
耦合度强弱的因素：
?一模块对另一模块的引用
?一模块向另一模块传递的数据量
?一模块施加到另一模块的控制的数量
?模块间接口的复杂程度
模块间耦合的类型：
低 非直接耦合
耦 数据耦合
合 标记耦合
性 控制耦合
高 内容耦合
模
块
独
立
性
弱
(低耦合 ) 强
(中耦合 )
(较强耦合 )
(强耦合 )
公共耦合
(1) 非直接耦合
两个模块没有直接关系 (模块 1和
模块 2)，模块独立性最强。
模块 1 模块 2
模块 3 模块 4
(2) 数据耦合
一模块调用另一模块时，被调
用模块的输入、输出都是简单
的数据。
属松散耦合。
数据耦合举例
开发票
计算水费
单价
数量 金额
数据耦合举例
计算水电费
计算水费 计算电费
用水量 用电量水费
电费
(3) 标记耦合 (特征耦合 )
如两个模块通过传递数据结构
(不是简单数据，而是记录、数组
等 )加以联系，或都与一个数据
结构有关系,则称这两个模块
间存在标记耦合。
标记耦合举例
计算水电费
计算水费 计算电费
住户情况 水费
电费
住户情况
,住户情况, 是一个数据结构,图中模块都
与此数据结构有关,
,计算水费, 和, 计算电费, 本无关,由于
引用了此数据结构产生依赖关系,它们之间
也是标记偶合,
将标记耦合修改为数据耦合举例
计算水电费
计算水费 计算电费
本月
用水量
本月
用电量水费
电费
(4) 控制耦合
一模块通过开关量、标志、
名字等控制信息，明显地控
制另一模块的功能。
控制耦合举例
A
计算平均分
或最高分
B
平均 /最高 成绩
设想一下 A( )函数中调用 B( )的语句是怎样的？
? 这个问题与前面的调用 MAX( )的例子不同。
在 MAX( )函数中，我们很清楚地看到：形式
参数表是两个整数，表示要比较的两个数。
函数说明为,MAX( int x,int y)
函数处理后，返回的结果为较大的那个数。
所以，在主调函数中，我们只需以两个被比
较的数作为 实际参数，所以就可写出形如：
..=MAX( 25,36) 的调用语句。
设想一下 A( )函数中调用 B( )的语句是怎样的？
? 但在 B( )函数中，我们虽然知道：形式参数表是
一个整数，表示要取得的成绩类型是平均或最高。
函数说明为,B( int x)
函数处理后，返回的结果为取出的成绩数据 (平
均或最高 )。
可是，在主调函数中，我们仍不知道以什么
作为实际参数，是 0？ 1？ 2？还是其他值，取决
于 B()中用什么值表示平均 /最高标记。因此，就
要去了解 B()内部的语句，而不能仅凭函数说明
就写出调用语句。所以 B()就成为灰箱 /白箱，而
非黑箱。
控制耦合举例
读入分数
输出结果
计算平均分 计算最高分
平均 /最高?
调用逻辑性模块
B时，须先传递
控制信号 (平均分
/最高分 )，以选
择所需的操作。
控制模块必须知
道被控模块的内
部逻辑，增强了
相互依赖,
B
控制耦合增加了模块之间的复杂性，
调用模块必须知道被调模块的内部逻
辑，增加了相互依赖。
去除模块间控制耦合的方法：
(1)将被调用模块内的判定上移到调
用模块中进行
控制耦合增加了理解和编程的复
(2)被调用模块分解成若干单一功
能模块
改控制耦合为数据耦合举例
A
计算平均分
B1
平均成绩 最高成绩
计算最高分
B2
控制耦合举例
A
发奖牌
名次
(开关量 )
奖牌
控制耦合
被调用模块内
处理逻辑模式
功能 A 功能 B
判别
改控制耦合为数据耦合举例
A
发金牌 发银牌 发铜牌
金牌
银牌
铜牌
A
取口令并核对B
用户名、
口令 对 /不对
控制耦合举例
A
取口令B
用户名 口令
将 B中核对口令功能划分到 A
(5) 公共耦合 (公共数据区耦合 )
一组模块引用同一个公用数据区
(也称全局数据区、公共数据环境 )。
公共数据区 指：
? 全局数据结构
? 共享通讯区
? 内存公共覆盖区等
公共耦合举例
Ａ
ｃｏｍｍｏｎ
公共数据区
松散的公共耦合
Ｂ Ａ
ｃｏｍｍｏｎ
公共数据区
紧密的公共耦合
Ｂ
公共耦合举例
Ａ
公共数据区
CB
模块 A,B,C间存在错综复杂的联系
公共耦合举例
所有的公共
耦合关系
A
EB
C
D
6个模块共享一
个 公共数据区
F
(1)系统可理解性降低
(模块间存在错综复杂的连系 )
(2)系统可维护性差
(修改变量名或属性困难 )
(3)系统可靠性差
(公共数据区及全程变量无保护措施 )
慎用公共数据区和全程变量 !!!
公共耦合存在的问题：
(6) 内容耦合
一模块直接访问另一模块的
内部信息 (程序代码或数据 )
最不好内容耦合形式 !!!
发生内容耦合的情形：
(1)一模块直接访问另一模块的
内部数据
(2)一模块不通过正常入口转到
另一模块内
(3)两模块有一部分代码重叠
(4)一模块有多个入口
模块化设计对耦合度的要求：
耦合是影响系统复杂程度和设计
质量的重要因素
目标,建立模块间耦合度尽可能
松散的系统
如何降低模块间耦合度：
(1) 如模块必须存在耦合，
选择适当的耦合类型
原则,尽量使用数据耦合
少用控制耦合
限制公共耦合的范围
坚决避免使用内容耦合
如何降低模块间耦合度：
(2) 降低模块间接口的复
杂性
接口复杂性与耦合类型的关系：
接
口
复
杂
性
接口方式
接口数据
的复杂性
无接口关系
直接引用
过程调用语句
数据项作参数
数据结构，变
量名作参数
内容耦合
其它耦合
开关量，起
控制变量作用
公用数据区
全程变量，
数据耦合
标记耦合
控制耦合
公共耦合
非直接耦合
4,模块独立性的度量之二：聚合度
衡量一个模块内部各成分之间彼
此结合的紧密程度
设计目标：高聚合 (一模块的所有
成分都直接参与并且
对于完成同一功能来
说都是最基本的 )
模块的聚合性类型：
低 偶然聚合
内 逻辑聚合
聚 时间聚合
性 过程聚合
通信聚合
顺序聚合
高 功能聚合
模
块
独
立
性
弱 (功能分散 )
强 (功能单一 )
(1) 功能聚合
一个模块内的所有成分的处理
动作全部为完成某个功能，且
只执行一个功能，缺一不可，
称为功能聚合。
聚合性最强
如, 计算实发工资，打印发票等
(2) 顺序聚合
一个模块能完成多个操作，前
一个操作处理的输出数据是下
一个操作处理的输入数据，模
块中各成份的工作是有次序的，
各成份的关系也较紧密，则称
为顺序聚合。
顺序聚合模块例
读 入
存 贮
打 印
累 加
读 数
模块 1 模块 2
(3) 通信聚合
模块内各部分使用相同的输
入数据，或产生相同的输出
结果,称为通信聚合
通信聚合模块例
产生工
资报表
计算平
均工资
职工工
资记录
职工工
资报表
平均
工资
产生职工工资报表并计算平均工资模块
通信聚合模块例
开领
书单
登记
售书
发票
领书单
售 书
登记表
文件
删除
修改
(4) 过程聚合
一个模块内各处理成分的动
作各不相同，彼此也没什么
关系，但它们都受一个 控制
流 的支配，且决定了它们的
执行次序。
过程聚合模块
建立方程组系数矩阵
全部任务纳入一个
模块，得到一过程
性模块
高斯消去法
回 代
高斯消去法解题流程
(5) 时间聚合
模块完成的功能必须在 同一时间
内执行，这些功能只因时间因素
关联在一起。
例如,初始化系统模块、
系统结束模块、
紧急故障处理模块等均是时间性聚合
模块,
(6) 逻辑聚合
把几种相关功能 (逻辑上相似
的功能 )组合在一模块内,每次
调用由传给模块的参数确定执
行哪种功能。
逻辑聚合模块例
A B C
E F G
A B C
EFG
A1 B1 C1
EFG模块内部逻辑
E,F,G逻辑
功能相似，组
成新模块 EFG
缺点, 增强了耦合程度 (控制耦合 )
不易修改，效率低
公用代码段
公用代码段
逻辑聚合缺点：
不易修改
增强了耦合程度 (控制耦合 )
效率低
(7) 偶然聚合
模块内各部分间无联系
A B C
M MOVE O TO R
READ FILE F
MOVE S TO T
模块 M中的三个语句没有任何联系
缺点：可理解性差,可修改性差
例,
?做杂事 ’
模块聚合性的判断
Y
N
Y
Y
该
模
块
功
能
单
一
各
功
能
关
系
如
何
功能聚合
通讯聚合
顺序聚合
逻辑相似
次序重要
次序重要
过程聚合
时间聚合
逻辑聚合
偶然聚合
N
N
N
Y
数据流
控制流
两者皆非
5,耦合、聚合与模块独立性关系
耦合与聚合都是模块独立性的
定性标准，都反映模块独立性
的良好程度。但耦合是直接的
主导因素，聚合则辅助耦合共
同对模块独立性进行衡量。
控制耦合举例
A
计算平均分
或最高分
B
平均 /最高 成绩
逻辑聚合
改控制耦合为数据耦合举例
A
计算平均分
B1
平均成绩 最高成绩
计算最高分
B2
功能聚合
A
取口令并核对B
用户名、
口令 对 /不对
控制耦合举例
顺序聚合
A
取口令B
用户名 口令
将 B中核对口令功能划分到 A
功能聚合
聚合与耦合密切相关，同其它模块
强耦合的模块意味着弱聚合，强聚
合模块意味着与其它模块间松散耦
合,
设计目标,力争 强聚合,
弱耦合
5,耦合、聚合与模块独立性关系
(续 )
三 数据流图导出初始结构图
从数据流程图导出系统的初始结构图，
首先要区分数据流程图的结构类型，然
后根据不同的类型采用不同的方法把数
据流图映象成相应的模块结构。
(一 )数据流程图 DFD的结构类型
1．变换型 DFD
一个数据流程图可以明显地分成输入、
处理和输出三部分。
2．事务型 DFD
事务型数据流程图一般呈束状形。
(1) 变换型结构
由输入、变换中心 (或称主
加工 )和输出三部分组成。
基本模型：
变换
中心
输入
路径
输出
路径
变换流示意图
信息
时间
信息流
输入流 输出流
变换流
外部
表示
内部
表示
变换型数据流图
输入
信息
物理
输入
格式
检查 处理 显示
正确
信息 结果
物理
输出
数据
变换中心 输出
逻辑
输入
逻辑
输出
输入
(2) 事务型结构
特征, 具有在多种事物中选择
执行某类事物的能力
基本模型：
事务
中心
接受路径 动作
路径
(3)大型系统 DFD中,变换型和事
务型结构往往共存,
T
事务中心
传入 变换 传出
(二 )DFD导出初始 SC的过程
? 两种转换策略 /技术
? 变换分析
? 事务分析
? 一般过程
? 先设计模块结构顶端的主模块
? 然后, 由顶向下逐步细化,
? 最后得到一个 与数据流图相对应 的程序结构
SD方法的两种转换方法
变换型 DFD
事务型 DFD
初始 SC
初始 SC
变换分析
事务分析
“由顶向下逐步细化, 的思想
? 找出, 顶, 在哪里，设计一个相应的主控模块
? 每创建一个新的模块时，必须决定该模块的外部特征
? 该模块的功能，即该模块, 做什么,
? 该模块同其调用模块的界面，即调用时传送的参数
? 对已创建的模块进行细化，考虑这个模块应该, 怎样做,
才能完成它的功能,于是又要创建下一层的新模块,再回
到上一步
通过这样, 先决定做什么,再考虑怎样
做,,循环往复,设计过程就有序地进行,
直至获得整个完整的结构层次。
变
换
型
事
务
型
（三）变换分析设计方法
(Transform Analysis)
步骤：
1 找出主加工、逻辑输入和逻辑输
出
2 设计模块结构的顶层和第一层
3 设计中、下层模块
1 区分输入、主加工、输出部分，在
DFD上标明分界线
(1)确定 逻辑输入 ——离物理输入端最远
的，但仍可被看作系统输入的那个数据
流
方法,从物理输入端开始，一步步向系
统的中间移动，直至达到这样一个数据
流：它已不能再被看作为系统的输入，
则其前一个数据流就是系统的逻辑输入。
1 区分输入、主加工、输出部分，在
DFD上标明分界线
(2)确定 逻辑输出 ——离物理输出端最远
的，但仍可被看作系统输出的那个数据
流
方法,从物理输出端开始，一步步向系
统的中间反方向移动，直至达到这样一
个数据流：它已不能再被看作为系统的
输出，则其后一个数据流就是系统的逻
辑输出。
1 区分输入、主加工、输出部分，在
DFD上标明分界线 (续 )
(3)对系统的每一股输入和输出，都用上
面的方法找出相应的逻辑输入、输出
(4)确定 主加工 ——位于逻辑输入和逻辑
输出之间的加工，就是系统的主加工
1 区分输入、主加工、输出部分，在
DFD上标明分界线 (续 )
(5)几点说明：
?有的系统只有输入和输出两部分，没有
主加工
?根据经验，几股数据流的汇合处往往是
系统的主加工
?每个人都可以有自己的看法，找出来的
主加工可能也不同，但一般不会相差太
远。
1 2
3 4
5 6
7
a b
c
ed
r
p u
w
v
变换中心
输入
部分
输出
部分
输入 输出 加工
2 设计 SC的顶层和第一层模块：
(1) 设计一个顶层模块 (主模块 )，它的功能是完成整个
程序要做的工作。
(2) 设计结构的第一层：
? 为逻辑输入设计一个输入模块，它的功能是向主模块
提供数据
? 为逻辑输出设计一个输出模块，它的功能是输出主模
块提供的数据
? 为主加工设计一个变换模块，它的功能是将逻辑输入
变换成逻辑输出
第一层模块同顶层主模块之间传送的数据应与数据流图相对
应。这里主模块控制并协调一层的输入、变换、输出模块的工
作，注意识别出选择或循环调用以及调用条件。
第一级分解后的 SC
MC
MTMA ME 第一层
顶层
c,e c,e u,w u,w
传送信息
第一级分解后的 SC(另一种画法 )
MC
MA1
c e
u,w
c,p
MA2 4 5 6 ME1 ME2
e
p
r
r
w,u w
3 第二级分解 (分解 SC各分支 )自顶向下
分解，设计出每个分支 (输入、加工、输
出 )的中、下层模块,
(1)为每一个输入模块设计两个下层模块，一个是
输入模块，接受数据来源；另一个是变换模块，
模块调用时传送的参数应同数据流图相对应
(2)输出模块也有两部分组成，一部分是变换模块，
将数据变换成输出的形式；另一部分是输出模块
上述设计过程由顶向下递归进行，直至达到系
统的输入端或输出端
(3) 变换模块的下层模块，根据数据流图中相应
加工的组成情况而定。
输
入
分
支
的
分
解
MA
Get Cb
a
c
Read D
d
e
c,e
B to C
b c d e
a b
Get E
Get B D to E
A to BRead A DFD图
输
出
分
支
的
分
解
ME
Write V
u
u
w,u
v v
Put U
U to V
Write W
w
DFD图
加工分支的分解
MT
54 6
e
c,p r
u,wp
r
DFD图
任何情况下都可使用变换
分析方法设计软件结构，
但如数据流具有明显的事
务特点时 (有一个明显的事
务中心 )，以采用事务分析
方法为宜。
(四 ) 事务分析设计方法
事务分析设计方法步骤：
(1)在 DFD上确定事务中心。
(2)为 DFD上的事务中心设计主模块，再为每
一种类型的事务处理设计一个事务处理模
块。
(3)为每个事务处理模块设计下面的操作模
块，再为操作模块设计细节模块。某些操
作模块和细节模块可以被几个上一层模块
共用。
事务型 DFD的划分
T
事务
中心 传入 变换 传出接收部分
发
送
部
分
a
事务型 SC的上层结构 (1)
事务控制
Get a
顶层
第一层
a
事务 1
事务型 SC的上层结构 (2)
事务控制
事务
分析 发送
动作分支的典型结构
P
T 2T 1 T i
A 2
D 2
A 1
D 1
A 3 A j
D k
事务层
操作层
细节层
处理层
变换分析举例 -DFD
1
格式
检查
3
产生
收据
2
计算
汇费
4
记账
汇款单
合格的
汇款单
处理后的
汇款单 收据
明细账
变换中心 输出输入
业务
数据
变换分析举例 -转换后的 SC
汇款处理系统
取得合格
汇款单 计算汇费 记账
输出处理后
的汇款单
输入
汇款单
格式检查 产生收据 打印收据
合格的
汇款单
处理后的
汇款单
合格的
汇款单 业务数据
处理后的
汇款单
汇款单 合格的汇款单汇款单
处理后的
汇款单 收据 收据
业务数据
要求类
型处 理
图书管理
要求
无效输入
1.1
新书入库
1.2
还
入库单
罚款单
1.5
注销图书
1.3
还书
1.4
目录文件
借书单
书 单
注销单
借书 借书文件
罚款单
事务分析举例 -DFD
事务
中心
事务分析举例 -转换后的 SC
图书处理系统
取得图书
处理要求
修改目
录文件操作层
细节层
新书入库 注销图书借书 还书
打印
罚款单
修改借
书文件……
…… ……
图书管
理要求 入库单
借书单 还书单
注销单
练习一：将 DFD用变换分析和事务型
分析导出初始 SC
A
C1
C2
C3B
D G
E J
F
K
L
c1
c2
b2b1
b3b
a
c3
d
g
f j
he
k
l
m
*
*
初始 SC
系统
主加工 Put kGet d
DGet c Put lKFE JG
Write mL
B to cGet b
ARead a C1 C3C2
Ac 1 ……Ac 2
Dt 1 Dt 3Dt 2
Ac N
……
操作层
细节层
d
k
k
d
m
ml
l lkdc
c
b
b
c
a a b b1
b2
c3
c1 c2 b3
e,f
d
g,j
f
e,g h h,j k
练习二：将 DFD用变换分析和事务型
分析导出初始 SC
A
C1
C2
C3B
D G
E J
F
K
L
c1
c2
b2b1
b3b
a
c3
d
g
f j
he
k
l
m
+
+
初始 SC
系统
主加工 Put kGet d
Put lKFE JG
Write mL
Get b
ARead a C1 C3C2
Ac 1 ……Ac 2
Dt 1 Dt 3Dt 2
Ac N
……
操作层
细节层
d
k
k
d
m
ml
l lk
b
a a b
b1
b2
c3
c1
c2
b3
e,f
d
g,j
f
e,g h h,j k
四 设计优化
将初始 SC根据模块独立性原则进
行精化,对模块进行合并、分解
修改、调整，得到 高内聚、低耦
合模块,得到易于实现、易于测
试和易于维护的软件结构，产生
设计文档的最终 SC。
改进软件结构设计的指导原则
(1)程序结构尽可能与问题结构相对应
(2)模块功能的完整
(3)消除重复功能
(4)作用范围应在控制范围内
(5)减少高扇出争取高扇入
(6)模块大小适中
(7)降低模块接口的复杂性
(8)模块功能可预测
(1)程序结构尽可能与问题结构
相对应
两种典型的程序结构：
? 变换型程序
? 事务型程序
(1)程序结构尽可能与问题结构
相对应 (续 )
两种程序结构的共同特征：
? 上层模块只负责控制、协调
? 下层模块完成具体的操作
变换型程序
变换型 (即输入、加工、输出
型，或称 IPO型 )的功能是从某
输入设备（如键盘）获得数据，
再对这些数据作处理，然后将
结果送出（如屏幕显示）。
这类程序的标准 SC图形如下
图所示。
变
换
型
程
序
结
构
MAIN
Get c
b
a
c
dtoe
d
d
btoc
b c e e
a b
PUT d
Get b Writee
atobRead a
ctod
c d
事务型程序
事务型程序的功能是接受一项事务，然
后根据事务的不同类型，选择进行某一类事
务的处理。这里，模块结构有三个层次：事
务层、操作层和细节层。主模块按接受的事
务类型，选择调用某个事务处理模块。不同
类型的事务处理模块可能含有一些相同的操
作，所以可能共用一些操作模块；不同的操
作又可能含有一些共同的细节，所以某些操
作模块又可能共用一些细节模块。
这类程序的标准 SC图形如下图所示。
事务型程序结构
MAIN
T 2GetT T i
A 2
D 2
A 1
D 1
A 3 A j
D k
事务层
操作层
细节层
处理层
T 1
(2)模块功能的完整
完整的模块应包括三部分：
?执行规定功能部分
?出错处理部分
?需返回一系列数据时，应返回
是否正确结束 (即, 文件完
/EOF”)标志。
(3)消除重复功能
几个模块中含有重复的部分，应设法
消去。因为同一功能重复多处，不仅浪
费编程、测试时间，还会给修改带来麻
烦。
但消除重复功能并不是简单的合并。
正确的方法 是：先分析几个模块中相同
功能的部分；然后把这个功能分离出来，
构成它们的一个公共的下层模块。
例子：消除重复功能
A
C
B
C
A′ B′
C
改进前 改进后
例子：消除重复功能
X Y
A BC C
改进前图 1
说明,如果 A,B抽去公共部分 C之后余下的模块 A ′,
B ′ 比较简单，则可以同它们的调用模块 X,Y合并，
所以改进后图 2、图 3都有可能。
B′
Y
C
X′
改进后图 2
X′ Y′
C
改进后图 3
(4) 作用范围应在控制范围内
(作用域应在控制域内 )
? 模块的控制范围 (控制域 ),
包括模块本身和其下属模块的集合。
? 模块的作用范围 (作用域 ):
指受该模块内一个条件判定影响的所有模块的集合。
只要模块中含有一些依赖于这个判定的语句，那么就
称该模块在这个判定的作用范围内。
? 控制域是从结构方面考虑的；作用域是从功能
方面考虑的
A
F
B C
E
M
D
G
模块的控制范围和作用范围 (例 )
:条件判定
模块 A的控制范围,
A,B,C、
D,E,F
A的作用范围：
A,C,F
:受判定影响
的模块
把一个条件判定的作用范围限制在判
定所在模块的控制范围之内，且判定
所在位置不能太高。
(作用域是控制域的子集 )
图 A——图 D画出了作用范围和控制范
围的四种情况。
作用范围 /控制范围原则：
图 A：判定位置违反作用范围 /控制范围原则
TOP
A B
C D
GE 条件判定
判定的作用范
围有一部分
(模块 C)
越出了判定所
在模块 G的控
制范围
G D B C
1)将判定所需的数据从 G向上传送到 D、
B，再向下传给 C,C用这些数据再次作
出判定。从而增加块间数据量。
思考,图 A中模块 C怎么知道模块
G中的判定结果
2)将判定的结果（是 /不是）从 G向上传
送到 D,B，再向下传给 C,C用这些开关
量决定执行那些操作。这样也增加块间
数据量，而且传送控制信息。
图 B:符合作用范围 /控制范围原则，但判
定位置太高
TOP
A B
C D
GE
条件
判定
TOP B D G
TOP B C
图 C:符合作用范围 /控制范围原则，判定
位置适中
TOP
A
G
C D
B
E
条件
判定
B D G
B C
图 D:符合作用范围 /控制范围的理想判
定位置
TOP
A
GE
B
DC 条件判定
D G
D E
?将包含条件判定的模块合并到它的
调用模块中，使判定处于较高位置
?将接受判定影响的模块下移到控制
范围内
?把判定上移到足够的位置
可以归结为：
使判定同受其影响的操作尽可能靠近。
修改模块结构方法：
(5)减少高扇出，争取高扇入
? 模块调用的直接下层模块的个数，称为扇出
(Fan out)
? 模块被其他各模块调用的个数，称为扇入 (Fan
in)
? 原则：扇出不宜过大,<=7；扇入尽可能大些。
但 CASE(分类 )型模块扇出可 >7,因为属自然分
类情况,易理解
(4,0)
(3,1)(5,1)
(0,2)
符号,
(扇出,扇入 )
(5)减少高扇出，争取高扇入 (续 )
清真寺型
不够好,底层模块复用度低
金字塔型
(5)减少高扇出，争取高扇入 (续 )
相关技巧：
?良好的结构图往往呈, 清真状,,即
,顶为尖 —下 层逐渐加宽 —底层收窄,
?结构图的形态应该均衡，即从顶到底
层的路径长短不该过于悬殊
(6) 模块大小适中
?模块过大：可理解程度下降
考虑对该模块分解
?模块过小：开销大于有效操作，
系统接口复杂
考虑是否同它的调用模块合并
(6) 模块大小适中 (续 )
几种情况下的小模块不合并：
?模块具有独立的功能
?模块功能可能会发生变化
?模块的复用性好，或者其调用模
块很复杂
(7)降低模块接口的复杂性
接口传递信息应简单且和
模块功能一致。
例：求一元二次方程的根
设求根模块调用形式为：
(1) QUAD－ ROOT(TBL,X)
传递系数的数组 存放根的数组
(2) QUAD－ ROOT(A,B,C,ROOT1,ROOT2)
A,B,C为方程系数
ROOT1,ROOT2是两个根
(8) 模块功能可预测
?可将模块看成黑盒子，相同输入可
产生相同输出，称其功能为可预测
的。
?模块带有内部状态，其功能可能是
不可预测的。这样的模块难理解、
难测试、难维护。
实例 1——银行贷款文件管理
实例 1——银行贷款文件管理
本实例说明用 SA方法进行分析，并用 SD
方法设计总体结构的过程。
?问题描述
?系统分析
?系统设计
1 问题描述
本系统 MFUP是银行贷款文件管理的
一部分,对贷款文件进行修改 。其主要
功能是：根据对贷款账户的修改信息修
改贷款文件中相应账户的记录内容，这
些修改信息记在一叠按账号排列的修改
卡片上。系统将被修改的记录打印一份
报告，并报告修改中出现的错误信息。
1 问题描述 (续 )
贷款文件格式：
每个账户在贷款文件中有一个记录，每个
记录由 14个数据项组成。（见下表）
贷款文件按账号递增排列，文件存放在 磁
带（顺序文件！） 上。每个账户的地址、电
话、邮政编码、负责与账户联系的银行信贷
员等都有可能发生变化。
序号 内 容 长度 (位 ) 数据类型 可否修改
1
2
3
4
5
6
7
8
9
10
11
12
13
14
账号
户名
地址
省
市
邮政编码
电话
类型
信贷员号
最近一次业务日期
最近一次付息日期
余额
业务总量
限额
5
30
30
10
15
5
7
1
5
6
6
8
8
6
数字
数字字母
数字字母
字母
字母
数字
数字
字母
数字
数字
数字
数字
数字
数字
否
可
可
可
可
可
可
否
可
否
否
否
否
否
1 问题描述 (续 )
修改卡片格式：
卡片的第 1-5位指出要修改的记录的账号，第 6-9位
为空，从第 10位开始为如下格式：
xx abcd…pqr*xx abc…stu*xx abc…uvw**
xx是两位数字，指出要修改的数据项序号，后面的
abcd…pqr 是这个数据项的修改值,*表示数据项的
结束，每张卡片的最后一个数据项结束是 **。
例,68371 07 2692386* 02 HUADA XINXI01**
表示要修改账号为 68371的记录，第 7项改为 2692386，第 2 项
改为 HUADA XINXI01。
1 问题描述 (续 )
修改规定：
? 修改值的长度小于数据项的指定长度时，如
果该项是数字项，则在其左边补零；否则在
右边补空格。
? 修改值的长度超过数据项的指定长度时，则
需截短
? 第 6 项邮政编码的修改值必须是 5 位
修改卡片按账号递增排列
1 问题描述 (续 )
基本过程：
? MFUP读入一叠修改卡片，检查卡片的排列次序以
及卡片上的修改信息是否合理，然后对旧文件作修
改，产生一个修改后的新文件，并将被修改的记录
打印成一份报告。
? MFUP将拒绝以下不合理的修改信息，并报告错误：
?修改卡片的账号没有按递增次序排列，或贷款文
件中没有这个帐号
?数据项序号不在 1-14之间
?数据类型不符
?企图修改不准修改的数据项
2 系统分析
0
银行贷款
文件修改
MFUP
0层图
修改卡片
(旧记录 )
(新记录 )
报告
未修改的
文件记录
修改后的
文件记录
2 系统分析 (续 )
1
检查
顺序
1层图
修改卡片
旧记录
新记录
报告
2
编辑
卡片
3
账号
相等?
4
修改
记录
5
写
记录
顺序
卡片
要修改的记录
不要修改
的记录
已修改
的记录
错误 修改信息
6
产生
报告
已修改
的记录
修改信息，
错误
2 系统分析 (续 )
2.1
抽出
修改项
2层图 ( 加工 2 的子图 )
顺序卡片 修改信息
错误
2.2
第 1项
错误
2.3
第 2项
2.4
第 3项
2.15
第 14项
2.16
收集
修改项
错误
……
3 系统设计
1）转换策略：
本系统结构是总体 ——变换型
局部 ——事务型
(“编辑卡片”子加工 )
所以采用的转换方法为对整个系统使用
“变换分析”，对系统的局部用“事务分析”
的方法。
3 系统设计 (续 ) ——方案 1
1
检查
顺序
1层图 ——变换型
修改卡片
旧记录
新记录
报告
2
编辑
卡片
3
账号
相等?
4
修改
记录
5
写
记录
顺序
卡片
要修改的记录
不要修改
的记录
已修改
的记录
错误 修改信息
6
产生
报告
已修改
的记录
修改信息，
输入部分
主加工部分
输出部分
错误
3 系统设计 (续 )——方案 2
1
检查
顺序
1层图 ——变换型
修改卡片
旧记录
新记录
报告
2
编辑
卡片
3
账号
相等?
4
修改
记录
5
写
记录
顺序
卡片
要修改的记录
不要修改
的记录
已修改
的记录
错误 修改信息
6
产生
报告
已修改
的记录
修改信息，
输入部分
主加工部分
输出部分
错误
3 系统设计 (续 )
说明：
变换分析设计方法的第一步，首先要将 DFD中的
所有处理划分成主加工、输入和输出三个部分。这
是根据 DFD中的处理所完成的功能 来确定的。
? DFD中的处理，如果“流入”和“流出”的数据流
的内容没有发生改变，只是性质（即正确与否）或
状态（格式的调整）等发生改变，则这个处理是属
于输入处理或输出处理的部分。
? 如果“流入”和“流出”的数据流的内容发生改变，
则这个处理是属于主加工的部分。
每个人对 DFD中每个处理所作功能的理解都可以
有自己的看法，找出来的主加工可能也不同，但一
般不会相差太远。
3 系统设计 (续 )
说明 (续 ):
处理数据 a 数据 b
数据 a->b改变的是,处理属于：
状态 /性质 输入 /输出处
理部分
内容 主加工部分
检查
正确性
入库单 正确的入库单
计算电费用电量 电费
例如：
流进 -流出的数据流内容没变，
所以是 输入处理 部分
流进 -流出的数据流内容变了，
所以属于 主加工 部分
3 系统设计 (续 )
说明（续）,
例如，本例就可能有两种划分结果，得出了不同
的“输入 -主加工 -输出”边界，都有道理。但是应注
意的是，作了不同划分后，接下来 产生的初始模块结
构图 就会有所不同。但是经过结构图的改进步骤后，
得出的最终系统模块结构图也是差不多的。
接下来以第一种划分方案，讲解转换策略及结构图
的调整。第二种划分方案的转换怎么做，大家可作为
课后思考。
3 系统设计 (续 ) ——方案 1
2.1
抽出
修改项
2层子图 ——事务型
修改信息
错误
2.2
第 1项
错误
2.3
第 2项
2.4
第 3项
2.15
第 14项
2.16
收集
修改项
错误
……
事务
中心
3 系统设计 (续 )
2)系统初始模块
结构图,主模块 MFUP
取得
旧记录
取得修
改信息
记录
匹配判断
(账号相等?)
修改
记录
输出修
改后的
记录
写记录
修改
信息
记录
修改信息
记录
修改信息
记录
记录
编辑
卡片
取得顺
序卡片
卡片 卡片 修改信息
检查顺序读卡片
打印报告产生报告
卡片 卡片 ok
记录
报告
报告
3 系统设计 (续 )
2)系统初始模块结构图, (“编辑卡片”分支 )
编辑卡片
抽出
修改项
编辑
第 1项
卡片
编辑
第 2项
修改项
调整
项 2
第 1项
编辑
第 3项
编辑
第 14项… …
第 2项 第 3项
第 14项
调整
项 3
okok
ok
ok
卡片 修改信息
3 系统设计 (续 )
3) 改进优化模块结构图,
? 消除重复的功能 (共同的操作 )
? 作用范围应是控制范围的子集
3 系统设计 (续 )
分析 1——共同的操作：
在对各个修改项的处理动作是类
似的。
3 系统设计 (续 )
修改 1-1：把逻辑上相似的模块合并起来，
会形成“逻辑型”模块。
如 1,6,9 项合并处理，但又各有不同。 1
项不允许改,6项必须 5位,9项可补零等。
模块中必须设开关量来区分不同的情况，且
可维护性差。
3 系统设计 (续 )
修改 1-1：简单合并，形成,逻辑型,模块。
编辑卡片
抽出
修改项
编辑第
1,6,9项
卡片
编辑第
2,3项
修改项
调整
项 2,3
第 1,6,
9项
编辑
第 4项
编辑第
12,13项… …
第 2,3
项
第 4项
第 12,
13项
调整
项 4
okok
ok
ok
卡片 修改信息
3 系统设计 (续 )
修改 1-2：不合并“编辑卡片”的各个下层模块，
但运用“消除重复操作”的技巧，抽出共同的
操作，形成操作层和细节层。
操作层如,拒绝非字母项”,,拒绝非数字
项”,调整修改项的长度” (在数字项前补零、
在字母项后补空格、截去过长的修改项等 )，它
们可以由事务层的 14个模块中的几个模块共用。
操作层的模块又包含共同的细节，如“查字符
类型”,“查字符串长度”、“显示出错信息”
等。
3 系统设计 (续 )
修改 1-2：
抽出共同操作。 编辑卡片
抽出
修改项
编辑
第 1项
卡片
编辑
第 2项
修改项
第 1项
编辑
第 3项
编辑
第 14项… …
第 2项 第 3项 第 14项
ok
卡片 修改信息
… …
…
拒绝非
N非 C项
拒绝
非 N项
拒绝
非 C项
调整
长度
拒绝
过长项
拒绝
过短项
检查字
符类型
检查字符
串长度
操作层
细节层 报告错误信息
… …
3 系统设计 (续 )
分析 2——模块大小：
抽出共同操作模块后，模块“处理修改
项 1,8,10 …” 等的功能都只是显示出错
信息，因此非常简单。
修改 2：将它们合并到上层模块‘编辑修
改项’中。
3 系统设计 (续 )
修改 2：将小模块合并到上层模块。 (界面略 )
编辑卡片
抽出
修改项
编辑
第 2项
卡片
编辑
第 3项
修改项
编辑
第 4项
编辑
第 9项
卡片 修改信息
编辑
第 5项
编辑
第 6项
编辑
第 7项
包含, 修改
1,8,10,11-14 项
” 的功能语句
… … … … …
3 系统设计 (续 )
分析 3——作用范围：
MATCH模块中的判定影响到‘ GET
记录’和‘ GET卡片’模块。
修改 3：将判定往上层移动。
3 系统设计 (续 )
修改 3：将判定往上层移动。
主模块 MFUP
取得
旧记录
取得修
改信息
记录
包含 (账号相等?)
的匹配判断
修改记录 输出报告写记录
修改
信息
记录
修改信息
记录
报告
卡片 卡片 修改信息
记录
报告
报告
… … … …
实例 2——病人监护系统
实例 2——病人监护系统
本实例说明改进模块结构图的过程，
在改进过程中运用了一些 SC优化技巧。
?问题描述
?初始 SC
?SC的改进
?进一步优化
?总结
1 问题描述
本系统 MNPA是某医院的一个病人监护系统,
其功能如下：
所有的病人都由专门的设备进行监视，设备同病
床相连，这些设备可以测量病人的脉搏、体温、血压、
呼吸 …… 等项目（下面称这些项目为因素）。系统每
过一定的时间间隔从监视设备读入上述因素,并把它
们存入数据库中。医生为每个病人指定了各种因素的
安全范围（如 312号病人的体温安全范围是 36。 C~38.5。
C)，如果系统发现某个因素值越出安全范围,或发现
某个监视部件有故障,则向护理站发出通知：如果是
因素越限则报告病人号；如果是监视部件故障则报告
床位号。
1 问题描述 (续 )
监视部件故障：
? 两种可能的设备故障
监视设备读出的数据由七个因素值及一个硬
件故障标志字组成。
1)硬件故障标志字：七个二进制位，说明测量
这七个因素的硬件是否有效（如：某个硬件
单元是否已接入电路中）
如,1110101 表示第 4,6个硬件故障，其
测出的因素值无效 1-有效 0-无效
1 问题描述 (续 )
监视部件故障 (续 )：
2)设备软件故障：即监视设备测出的因素值不
合理（如：体温测出 52。 C的不合理值等）。
? 故障处理
?在硬件故障标志字指出硬件无效或软件检
查出因素值不合理时，都应 作为监视设备
故障向护理站报告
?将这些因素值 存入数据库时应加上标志,
指出它们是无效的
1 问题描述 (续 )
数据存储：
数据库中的数据应该 可以按病人号进行
检索 。各因素是相互无关的，其格式和
长度均不相同。在数据库中,不必标出
个因素值是否安全 。
注：因素值无效与因素值安全是两个概念。
比如体温为 39。 C是有效的，却是不安全的。
病人监护系统
处理因素值检查因素值获得因素值
检查不合理
因素值
读取病床
因素值
读取病
人信息
检查
不安全
因素
读取安全
值范围
存入
数据库
报告错
误设备
报告
不安全
因素
Pn,
Factors,EOF
Error Flags
Factors,
Safe Ranges
Error Flags
Unsafe Flags,
Error Flags
Pn,Factors,
Error Flags
Pn,
Factors,
Error Flags,
Unsafe Flags
Pn,Bednum
EOF
Factors,
Error Flags
Pn,Factors
Error FlagsBednum
PnFactors
Error
Flags2
Unsafe
Flags
Safe
Ranges
Pn,Factors
Unsafe FlagsPn,
Error
Flags
参数说明,Pn-病人号 Bednum-病床号 Factors-七个因素值
SafeRanges-因素安全值范围 EOF-本次巡视已处理过最后一个病人信息
Error Flags2-各因素值是否合理 UnsafeFlags-因素值是否安全
* ErrorFlags-硬件故障标志字；设备故障标志字
2 初始结构图
2 初始结构图 (续 )
? 模块,检查因素值,调用三个下层模块分别
完成三个功能：
1）查出不合理的因素值（‘ 检查因素值 ’模
块中再将 Error Flags2和硬件故障标志字合并
成设备故障标志 Error Flags)
2)查出某病人的因素安全值范围
3)决定病人的因素值是否安全
? 模块,处理因素值,将数据存入数据库，并
在发现不安全因素或设备故障时通知护理站
3 结构图的改进
使用技巧,
? 减少块间联系，主要是减少模块之间传送的
参数个数
? 消除“管道性”模块
? 消除重复的功能
? 如果一个模块篇幅较大，可考虑分解
? 如果一个模块篇幅较小，可考虑同其调用模
块合并
? 要考虑将来可能发生的变化和扩充
3 结构图的改进 (续 )
病人监护系统
处理因素值检查因素值获得因素值
检查不合理
因素值
读取病床
因素值
读取病
人信息
检查
不安全
因素
读取安全
值范围
存入
数据库
报告错
误设备
报告
不安全
因素
Pn,
Factors,EOF
Error Flags
Factors,
Safe Ranges
Error Flags
Unsafe Flags,
Error Flags
Pn,Factors,
Error Flags
Pn,
Factors,
Error Flags,
Unsafe Flags
Pn,Bednum
EOF
Factors,
Error Flags
Pn,Factors
Error FlagsBednum
PnFactors
Error
Flags2
Unsafe
Flags
Safe
Ranges
Pn,Factors
Unsafe FlagsPn,
Error
Flags
缺少
Bednum
3 结构图的改进 (续 )
改进一：
减少块间联系，主要是减少模块之间传送的
参数个数，简化模块之间的界面
分析：,病人监护系统” ——“处理因素值”的界面
1),处理因素值”接收的参数 unsafe flags，除了“报
告不安全因素”要用到，其另两个下层模块不必用
到这一参数；且“报告不安全因素”不返回任何参
数给“处理因素值” ；“报告不安全因素”所需的
参数在主模块“病人监护系统”中都有；所以将它
改成由主模块直接调用。这样又可简化 unsafe flags
这一参数。
3 结构图的改进 (续 )
分析：,病人监护系统” ——“处理因素值”的界面
2) 同理，主模块可以直接调用“存入数据库”，这样，
主模块“病人监护系统”与“处理因素值”的界面
又可以消去 Factors这一参数。
3 结构图的改进 (续 )
分析：,病人监护系统” ——“处理因素值”的界面
3) 现在,“处理因素值”的功能仅仅是调用“报告错
误设备”，所以它可以合并到主模块中去。
3 结构图的改进 (续 )
分析：,病人监护系统” ——“处理因素值”的界面
说明 ——
“处理因素值”模块并没有做什么实质性的工作，
而只是像“管道”一样，将一些参数从主模块传送
到它的几个下层模块,而这些模块完全可以由主模
块直接调用。
3 结构图的改进 (续 )
改进二,消除重复的功能
分析：,报告错误设备”模块
1),报告错误设备”模块应该向护理站报告故障设备
的床位号而不是病人号，所以应该在这个模块中包
含从病人号查出床位号的功能。而模块“读取病人
信息”已经含有这个功能。所以可把它提供的
BedNum参数回送给主模块，再由主模块传送给
“报告错误设备”模块，但这样增加了块间联系。
如果改为由“读取病人信息”直接调用“报告错误
设备”，则可将传送给主模块的参数 BedNum消去，
可减少块间联系。
3 结构图的改进 (续 )
分析：,报告错误设备”模块
2) 又因为无论是硬件故障或者测得的因素值不合理，
都应作为设备故障通知护理站，所以应在通知护理
站之前调用“检查不合理因素值”，于是改为由
“读取病人信息”直接调用“检查不合理因素值” 。
这样一来，也简化了“检查因素值”的界面，因为
它不必再回送 Error Flags了。
3 结构图的改进 (续 )
病人监护系统
检查因素值获得因素值
检查不合理
因素值
读取病床
因素值
读取病
人信息
检查
不安全
因素
读取安全
值范围
存入
数据库
报告错
误设备
报告
不安全
因素
Pn,
Factors,EOF
Error Flags
Factors,
Safe Ranges
Error Flags
Unsafe Flags,
Error Flags
Pn,Factors,
Error Flags
Pn,Bednum
EOF
Factors,
Error Flags
Pn,Factors
Error Flags
Bednum
Pn
Factors Error Flags2
Unsafe
Flags
Safe
Ranges
Pn,Factors
Unsafe Flags
Bednum,
Error Flags
3 结构图的改进 (续 )
检查因素值获得因素值
检查不合理
因素值
读取病床
因素值
读取病
人信息
检查
不安全
因素
读取安全
值范围
存入
数据库
报告错
误设备
报告
不安全
因素
Factors,
Safe Ranges
Error FlagsPn,BednumEOF Factors,Error Flags
Bednum
Pn
Factors
Error
Flags2
Unsafe
Flags
Safe
Ranges
Bednum,
Error Flags
产生一
行通知
在设备上
输出一行
从病人
号查
床位号
Bednum
Pn
Pn
改为‘获得
病人因素值’
独立出来形成
‘获得病床因素
值’
3 结构图的改进 (续 )
检查因素值获得因素值
获得病床
因素信息
获得病人
因素值
读取病
人信息
检查
不安全
因素
读取安全
值范围
存入
数据库
报告错
误设备
报告
不安全
因素
Factors,
Safe Ranges
Error FlagsPn,EOF Factors,Error Flags Pn
Bednum
Unsafe
Flags
Safe
Ranges
Factors,
Error Flags
产生一
行通知
在设备上
输出一行
从病人
号查
床位号
Bednum
Pn
Pn
Bednum,
Error Flags
Line
Line Line
Unsafe
Factor,
Factor Type
检查不合理
因素值
Factors Error Flags2
篇幅小，
可往上
层合并
3 结构图的改进 (续 )
分析：,报告错误设备”模块
3),报告错误设备”和“报告不安全因素”都需要为
护理站打印一些信息。为了消除重复的功能，也为
了在将来护理站或打印设备情况有改变的时候不必
牵涉到两个模块的修改，可以将这一功能抽出,形
成一个新的模块“在设备上输出一行”,使得“报
告错误设备”和“报告不安全因素”都调用此模块。
3 结构图的改进 (续 )
改进三,模块的分解
分析：,报告不安全因素”模块
考虑到该模块的篇幅可能较大，可以把“产生一行
通知”的功能单独抽出来，形成其调用的一个下层
模块。
3 结构图的改进 (续 )
改进四：模块独立性的考虑 ( 简化联系、
分解、模块复用、合并 )
分析：,读取病床因素值”模块
1)简化联系 ——考虑使“读取病床因素值”包括从
病人号查床位号的功能，则“读取病人信息”的界
面中就可以消去 BedNum这个参数，从而减少块间
联系。
3 结构图的改进 (续 )
分析：,读取病床因素值”模块
2)分解 ——考虑到“读取病床因素值”这个模块本
身的篇幅已不小，所以将“从病人号查床位号”的
功能由它的一个下层模块来完成。此外，为了使模
块名恰当地反映模块的功能，应将“读取病床因素
值”改名为“获得病人因素值”。
说明：病人信息指基本信息，如姓名、性别等
病人因素值指病人疾病信息，如血压、体温等。
3 结构图的改进 (续 )
分析：,读取病床因素值”模块
3)功能模块的独立性与复用 ——现在，根据某个床
位号从监视设备读入相应因素的一段程序是隐含在
模块“获得病人因素值”中的，但是设备检修人员
可能要在其他系统中使用这段程序（ 模块复用 ），
他们关心的是某床位的设备如何，而不管床上是否
有病人，或病人是谁。所以这段程序还是抽出来，
单独组成一个模块“获得病床因素信息”较好。
3 结构图的改进 (续 )
分析：,读取病床因素值”模块
4) 模块的合并 ——现在,“获得病床因素信息”和
“检查不合理因素值” 篇幅都不长，可以将后者合
并到前者。
3 结构图的改进
(续 )
检查因素值获得因素值
获得病床
因素信息
获得病人
因素值
读取病
人信息
检查
不安全
因素
读取安全
值范围
存入
数据库
报告错
误设备
报告
不安全
因素
Factors,
Safe Ranges
Error FlagsPn,EOF
Factors,
Error Flags Pn
Bednum
Unsafe
Flags
Safe
Ranges
Factors,
Error Flags
产生一
行通知
在设备上
输出一行
从病人
号查
床位号
Bednum
Pn
Pn
Bednum,
Error Flags
Line
Line
Line
Unsafe
Factor,
Factor Type
病人监护系统
Pn,
Factors,EOF
Error Flags Unsafe
Flags
Pn,Factors,
Error Flags
Pn,
Factors,
Error Flags
Pn,
Factors,
Unsafe Flags
检查因素值获得因素值
获得病床
因素信息
获得病人
因素值
读取病
人信息
检查
不安全
因素
读取安全
值范围
存入
数据库
报告错误设备
报告
不安全
因素
Factors,
Safe Ranges
Error FlagsPn,EOF Factors,Error Flags Pn
Bednum
Unsafe
Flags
Safe
Ranges
Factors,
Error Flags
产生一
行通知
在设备上
输出一行
从病人
号查
床位号
Bednum
Pn
Pn
Bednum,
Error Flags
Line
Line Line
Unsafe
Factor,
Factor Type
Unsafe Flags Pn,Factors,
Unsafe Flags
3 结构图的改进 (续 )
改进五,简化联系
分析：,检查因素值”和“报告不安全因素”模块
改为由“检查因素值”直接调用“报告不安全因
素”，则可以消去参数 Unsafe Flags。这又可以减
少块间联系。此时，将“检查因素值”改名为“输
出不安全因素值”。
3 结构图的改进 (续 )
改进六：其他 (一种典型的改进情况 )
分析：,报告错误设备”模块
考虑由“获得病床因素信息”来调用“报告错误设
备”。在某个故障设备的修理期间，这个程序模块将
重复地向护理站报告该设备已坏。这是令人讨厌的。
如果改由,获得病人因素值”调用“报告错误设备”
模块，则会灵活一些。
这种情况是 较典型 的：
如果一个模块检测出错误后，
1)要报告错误信息； 2)要将一个出错标志回送给它
的调用模块
不如改为由调用模块按出错标志的值决定是否要报
告错误信息更灵活、更清楚些。
3 结构图的改进
(续 )
检查因素值获得因素值
获得病床
因素信息
获得病人
因素值
读取病
人信息
检查
不安全
因素
读取安全
值范围
存入
数据库
报告错
误设备
报告
不安全
因素
Factors,
Safe Ranges
Error Flags
Pn,EOF
Factors,
Error Flags Pn
Bednum
Unsafe
Flags
Safe
Ranges
Factors,
Error Flags
产生一
行通知
在设备上
输出一行
从病人
号查
床位号
Bednum
Pn
Pn
Bednum,
Error Flags
Line
Line Line
Unsafe
Factor,
Factor Type
病人监护系统
Pn,
Factors,EOF
Error Flags Pn,Factors,
Error Flags
Pn,
Factors,
Unsafe Flags
Pn,
Factors,
Error Flags
4 结构图的进一步优化
改进七：考虑系统将来的变化与扩充
结构图中许多模块界面都带有参数 Factors和
Error Flags，这两个参数表示了七个不同类型、
不同长度、相互无关的因素及它们的错误标志，
共 14个数据项。因此，多个模块中均包含与因
素的个数、格式、长度有关的程序。 一旦将来
增加了监视的因素个数,或改变因素的格式、
次序,所有这些模块都必须作修改。
4 结构图进一步优
化 (续 )
检查因素值获得因素值
获得病床
因素信息
获得病人
因素值
读取病
人信息
检查
不安全
因素
读取安全
值范围
存入
数据库
报告错
误设备
报告
不安全
因素
Factors,
Safe Ranges
Error Flags
Pn,EOF
Factors,
Error Flags Pn
Bednum
Unsafe
Flags
Safe
Ranges
Factors,
Error Flags
产生一
行通知
在设备上
输出一行
从病人
号查
床位号
Bednum
Pn
Pn
Bednum,
Error Flags
Line
Line Line
Unsafe
Factor,
Factor Type
病人监护系统
Pn,
Factors,EOF
Error Flags Pn,Factors,
Error Flags
Pn,
Factors,
Unsafe Flags
Pn,
Factors,
Error Flags
篇幅小，
可往上
层合并
4 结构图的进一步优化 (续 )
改进七：考虑系统将来的变化与扩充 (续 )
因此，改为每次传送一个因素、一个因素类型及一
个错误标志,则每个界面将只传送三个数据项。
“获得病床因素值”就成为唯一一个与因素个数、
格式有关的模块。这样,其他原来有关的模块中控
制处理七个因素的循环就可取消，各模块的名字也
应相应修改一下，体现它们的功能是处理 一个 因素。
另外,“获得病床因素值”应在回送一个参数给
“获得病人因素值”说明最后一个因素已处理完
(FEOF)，而“获得病人因素值”应再将 FEOF回送
到上一级。
4 结构图的进一步优化 (续 )
改进七：考虑系统将来的变化与扩充 (续 )
现在“检查不安全因素”只是检查一个因素是否
安全，因而很简单,可以同它的调用模块“输出
不安全因素值”合并。
检查单因素值获得单因素值
获得病床
单因素 信息
获得病人
单因素 值
读取病
人信息
读取安全
值范围
存入
数据库
报告错
误设备
报告
不安全
因素
Pn,EOF
Factor,
Type,
FEOF
Pn,
Type
Bednum
Safe
Range
Factor,Type
Error,FEOF
产生一
行通知
在设备上
输出一行
从病人
号查
床位号
Bednum
Pn
Pn
Bednum,
Type
Line
Line Line
Type,
Unsafe Factor
病人监护系统
Pn,
Factor,EOF
Type Pn,Factor,
Type
Pn,
Type,
Unsafe Factor
Pn,
Factor,
Type
4 结构图进一步优
化 (续 )
5 总结
? 改进的过程有很强的试探性,需对各种可
能的方案作比较和权衡。
? 运用 DFD->SC的转换策略，可以得到质量
较好、结构较合理的初始模块结构图。
思考
1）根据“银行贷款文件修改系统”的问
题描述画出 DFD图，运用转换方法画出
相应的模块结构图，并进行优化。
2）根据结构图优化原则对“病人监护系
统”的初始模块结构图进行改进。
