实例 —— 银行贷款文件管理

1. 实例——银行贷款文件管理

2. 实例1——银行贷款文件管理 本实例说明用SA方法进行分析，并用SD方法设计总体结构的过程。 • 问题描述 • 系统分析 • 系统设计

3. 1 问题描述 本系统MFUP是银行贷款文件管理的一部分：对贷款文件进行修改。其主要功能是：根据对贷款账户的修改信息修改贷款文件中相应账户的记录内容，这些修改信息记在一叠按账号排列的修改卡片上。系统将被修改的记录打印一份报告，并报告修改中出现的错误信息。

4. 1 问题描述(续) 贷款文件格式： 每个账户在贷款文件中有一个记录，每个记录由14个数据项组成。（见下表） 贷款文件按账号递增排列，文件存放在磁带（顺序文件）上。每个账户的地址、电话、邮政编码、负责与账户联系的银行信贷员等都有可能发生变化。

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。

7. 1 问题描述(续) 修改规定： • 修改值的长度小于数据项的指定长度时，如果该项是数字项，则在其左边补零；否则在右边补空格。 • 修改值的长度超过数据项的指定长度时，则需截短 • 第6 项邮政编码的修改值必须是6 位 修改卡片按账号递增排列

8. 1 问题描述(续) 基本过程： • MFUP读入一叠修改卡片，检查卡片的排列次序以及卡片上的修改信息是否合理，然后对旧文件作修改，产生一个修改后的新文件，并将被修改的记录打印成一份报告。 • MFUP将拒绝以下不合理的修改信息，并报告错误： • 修改卡片的账号没有按递增次序排列，或贷款文件中没有这个帐号 • 数据项序号不在1-14之间 • 数据类型不符 • 企图修改不准修改的数据项

9. 修改后的文件记录 修改卡片 (新记录) 0 银行贷款 文件修改 MFUP 未修改的文件记录 报告 (旧记录) 0层图 2 系统分析

10. 2 系统分析(续) 修改卡片 顺序卡片 2 编辑 卡片 1 检查 顺序 错误 错误 修改信息 修改信息， 4 修改 记录 旧记录 3 账号 相等? 要修改的记录 已修改的记录 报告 6 产生 报告 已修改的记录 不要修改的记录 5 写 记录 1层图 新记录

11. 错误 2.2 第1项 2.3 第2项 2.4 第3项 2.1 抽出 修改项 顺序卡片 2.16 收集 修改项 修改信息 …… 错误 2.15 第14项 错误 2层图( 加工2 的子图) 2 系统分析(续)

12. 3 系统设计 1）转换策略： 本系统结构是总体——变换型 局部——事务型 (“编辑卡片”子加工) 所以采用的转换方法为对整个系统使用“变换分析”，对系统的局部用“事务分析”的方法。

13. 修改卡片 顺序卡片 输入部分 2 编辑 卡片 1 检查 顺序 错误 错误 主加工部分 修改信息 输出部分 修改信息， 4 修改 记录 旧记录 3 账号 相等? 要修改的记录 已修改的记录 报告 6 产生 报告 已修改的记录 不要修改的记录 5 写 记录 1层图——变换型 新记录 3 系统设计(续) ——方案1

14. 修改卡片 顺序卡片 输入部分 2 编辑 卡片 1 检查 顺序 错误 错误 修改信息 主加工部分 输出部分 修改信息， 4 修改 记录 旧记录 3 账号 相等? 要修改的记录 已修改的记录 报告 6 产生 报告 已修改的记录 不要修改的记录 5 写 记录 1层图——变换型 新记录 3 系统设计(续)——方案2

15. 3 系统设计(续) 说明： 变换分析设计方法的第一步，首先要将DFD中的所有处理划分成主加工、输入和输出三个部分。这是根据DFD中的处理所完成的功能来确定的。 • DFD中的处理，如果“流入”和“流出”的数据流的内容没有发生改变，只是性质（即正确与否）或状态（格式的调整）等发生改变，则这个处理是属于输入处理或输出处理的部分。 • 如果“流入”和“流出”的数据流的内容发生改变，则这个处理是属于主加工的部分。 每个人对DFD中每个处理所作功能的理解都可以有自己的看法，找出来的主加工可能也不同，但一般不会相差太远。

16. 3 系统设计(续) 数据a->b改变的是： 处理属于： 状态/性质 输入/输出处 理部分 内容 主加工部分 数据b 数据a 处理 说明(续): 例如： 入库单 检查 正确性 正确的入库单 流进-流出的数据流内容没变，所以是输入处理部分 流进-流出的数据流内容变了，所以属于主加工部分 用电量 计算电费 电费

17. 3 系统设计(续) 说明（续）: 例如，本例就可能有两种划分结果，得出了不同的“输入-主加工-输出”边界，都有道理。但是应注意的是，作了不同划分后，接下来产生的初始模块结构图就会有所不同。但是经过结构图的改进步骤后，得出的最终系统模块结构图也是差不多的。 接下来以第一种划分方案，讲解转换策略及结构图的调整。第二种划分方案的转换怎么做，大家可作为课后思考。

18. 错误 2.2 第1项 事务中心 2.3 第2项 2.4 第3项 2.1 抽出 修改项 2.16 收集 修改项 修改信息 …… 错误 2.15 第14项 错误 2层子图 ——事务型 3 系统设计(续) ——方案1

19. 3 系统设计(续) 主模块MFUP 记录 记录 记录 记录 修改信息 2)系统初始模块结构图： 记录 修改信息 修改信息 输出修改后的记录 修改记录 取得旧记录 取得修改信息 匹配判断 (账号相等?) 写记录 修改信息 记录 报告 卡片 卡片 报告 编辑卡片 取得顺序卡片 打印报告 产生报告 卡片 ok 卡片 读卡片 检查顺序

20. 卡片 修改信息 编辑卡片 卡片 第3项 第1项 第2项 修改项 ok ok ok 调整项3 抽出修改项 调整项2 ok 第14项 编辑第3项 编辑 第14项 编辑 第1项 编辑第2项 …… 3 系统设计(续) 2)系统初始模块结构图: (“编辑卡片”分支)

21. 3 系统设计(续) 3) 改进优化模块结构图: • 消除重复的功能 (共同的操作) • 作用范围应是控制范围的子集

22. 3 系统设计(续) 分析1——共同的操作： 在对各个修改项的处理动作是类似的。

23. 3 系统设计(续) 修改1-1：把逻辑上相似的模块合并起来，会形成“逻辑型”模块。 如1、6、9 项合并处理，但又各有不同。1项不允许改，6项必须6位，9项可补零等。 模块中必须设开关量来区分不同的情况，且可维护性差。

24. 卡片 修改信息 编辑卡片 卡片 第1,6, 9项 第4项 第2,3项 ok ok 修改项 ok 调整项4 抽出修改项 调整项2,3 ok 第12, 13项 编辑第4项 编辑第2,3项 编辑第12,13项 编辑第1,6,9项 …… 3 系统设计(续) 修改1-1：简单合并，形成“逻辑型”模块。

25. 3 系统设计(续) 修改1-2：不合并“编辑卡片”的各个下层模块，但运用“消除重复操作”的技巧，抽出共同的操作，形成操作层和细节层。 操作层如 “拒绝非字母项” 、 “拒绝非数字项” “调整修改项的长度” (在数字项前补零、在字母项后补空格、截去过长的修改项等)，它们可以由事务层的14个模块中的几个模块共用。 操作层的模块又包含共同的细节，如“查字符类型”、 “查字符串长度”、“显示出错信息” 等。

26. 修改信息 卡片 编辑卡片 第1项 卡片 ok 第3项 修改项 第2项 第14项 编辑第3项 编辑 第14项 抽出修改项 编辑 第1项 编辑第2项 …… 3 系统设计(续) 修改1-2： 抽出共同操作。 … … … 拒绝过长项 调整长度 拒绝过短项 拒绝非N项 拒绝非N非C项 拒绝非C项 操作层 …… 检查字符串长度 检查字符类型 报告错误信息 细节层

27. 3 系统设计(续) 分析2——模块大小： 抽出共同操作模块后，模块“处理修改项1、8、10 …”等的功能都只是显示出错信息，因此非常简单。 修改2：将它们合并到上层模块‘编辑修改项’中。

28. 3 系统设计(续) 修改2：将小模块合并到上层模块。(界面略) 卡片 修改信息 包含“修改1,8,10,11-14 项”的功能语句 编辑卡片 卡片 修改项 抽出修改项 编辑第7项 编辑第6项 编辑第4项 编辑第3项 编辑第9项 编辑第5项 编辑第2项 …… ………

29. 3 系统设计(续) 分析3——作用范围： MATCH模块中的判定影响到‘GET 记录’和‘GET卡片’模块。 修改3：将判定往上层移动。

30. 3 系统设计(续) 包含(账号相等?)的匹配判断 修改3：将判定往上层移动。 主模块MFUP 报告 记录 记录 记录 修改信息 修改信息 输出报告 取得旧记录 取得修改信息 修改记录 写记录 记录 报告 修改信息 卡片 卡片 报告 …… ……