Download to read offline
![Woman[1]](https://cdn.slidesharecdn.com/ss_thumbnails/woman1-120406043510-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
软件工程 第五章
- 1. 软件设计的目标和任务 软件需求：解决“做什么” 软件设计：解决“怎么做” 软件设计的任务：以软件需求规格说明书 为依据，进行 数据设计 系统结构设计 过程设计
- 2. 软件设计的目标和任务 数据设计侧重于数据结构的定义 系统结构设计定义软件系统各主要成分之间的 关系 过程设计则是把结构成分转换成软件的过程性 描述。在编码步骤，根据这种过程性描述，生 成源程序代码，然后通过测试最终得到完整有 效的软件。 软件设计的重要性：是软件开发时期的第一个 步，最终影响软件实现的成败和软件维护的难 易程度。
- 3. 软件设计的两个阶段 从工程管理的角度来看，软件设 计分两步完成。 总体设计：将软件需求转化为数据结构和 软件的系统结构。 详细设计：即过程设计。通过对结构表示 进行细化，得到软件的详细的数据结构和 算法。
- 4.
- 5.
- 6. 第 5章 总体设计 5.1 设计过程 5.2 设计原理 5.3 启发规则 5.4 描绘软件结构的图形工具 5.5 面向数据流的设计方法 5.6 小结 习题
- 7.
- 8. 5.1 设计过 5.1 设计过程 程 总体设计的步骤 设想供选择的方案 选取合理的方案 系统流程图 组成系统的物理元素清单 成本 / 效益分析 实现这个系统的进度计划 推荐最佳方案 功能分解 设计软件结构（模块化思想）
- 9. 5.1 设计过程 总体设计的步骤 设计数据库 制定测试计划 书写文档 系统说明 用户手册 测试计划 详细的实现计划 数据库设计结果 审查和复审
- 10. 5.2 设计原 理 设计原理 模块化 抽象 逐步求精 信息隐藏和局部化 模块独立
- 11. 5.2 设计原 理 一. 模 块 化 模块：模块是由边界元素限定的相邻程序元素（例如，数据 说明，可执行的语句）的序列，而且有一个总体标识符代表 它。如： OO 的对象、方法。 模块化思想：模块化就是把程序划分成独立命名且可独立访 问的模块，每个模块完成一个子功能，把这些模块集成起来 构成一个整体，可以完成指定的功能满足用户的需求。 “ 分而治之 ” 是模块化思想的依据：把复杂的问题分解为若 干个易于处理的小问题。
- 12. 5.2 设计原 理 一. 模 块 化 令 C(X): 问题 X 的复杂程度， E(X): 解决 X 问 题所需的工作量 规律 1 ：若两个问题 P1 ， P2 C(P1) > C(P2) ，则 E(P1) > E(P2) 规律 2 ：某问题 P 可以分成 P1 ， P2 ， P ＝ P1 ＋ P2 则 : C(P1+P2) > C(P1)+C(P2)
- 13. 5.2 设计原 理 一. 模 块 化 结论：分而治之，各个击破 ？将模块无限分割下去？ 单个模块的开发成本小，几乎可忽略不计； 模块之间接口的开发成本呢？
- 14. 5.2 设计原 理 一. 模 块 化 模块数目与软件成本的关系 模块数目为 M 时，软件开发成本最小
- 15. 5.2 设计原 理 二. 抽 象 抽象：把一定事物、状态或过程中共性的方面 集中和概括起来，暂时忽略它们之间的差异。 抽象的思想：处理复杂系统的惟一有效的方法 是用层次的方式构造和分析它。 抽象层次： 最高抽象级别 — — 面向问题的语言 较低抽象级别 — — 面向问题和实现的语言 最低抽象级别 — — 面向实现的语言 软件设计中的两类抽象： 过程抽象：功能－ > 过程、函数 数据抽象：数据对象定义、描述－ > 数据类 型名
- 16. 5.2 设计原 理 二. 抽 象 例子：讨论一个在不同抽象级别上的软件设计所具 有 CAD 图形软件包可以画 的形式。 抽象 1 ．总体结构层次 各种直线和曲线，能完 的抽象 成所有几何图形的计算 图形软件包 软件任务 ．图形设计的结果存于 图形用户界面 图形文件中，图形文件 创建 二维图形任 可包含几何的、正文的 务 和其它各种设计信息。 显示 图形任务 管理 图形文件任 务
- 17. 5.2 设计原 理 二. 抽 象 抽象 2 ．过程层次的抽象（仅以管理图形文件任务为 例） PROCEDURE drawing file management task IF OpenFile THEN input filename ； open the file ； display the file ； ELSE IF SaveFile THEN input save filename ； save the file ； END IF END PROCEDURE. 抽象 3 ．实现层次的抽象（程序设计语言描述）
- 18. 5.2 设计原 理 二. 抽 象 CAD 软件中的数据抽象举例： STRUCT coordinate { int x; int y }; CLASS Drawing //parent class { PUBLIC : coordinate startpoint, endpoint; …… }; CLASS Line : PUBLIC Drawing { …… }; CLASS Curve : PUBLIC Line { …… }; CLASS StraightLine : PUBLIC Line { …… }; Curve objCurve1; //objCurve1 is a instance of Curve StraightLine objSL2 ; //objSL2 is a instance of StraightLine
- 19. 5.2 设计原 理 三. 逐 步 求 精 逐步求精： 为了能集中精力解决主要问题而尽量推迟 对问题细节的考虑。 逐步求精的思想： 对一个事物的认识是一个从高层次抽象向 低层次抽象逐步转化和过渡的过程。 Miller 法则： 一个人在任何时候都只能把注意力集中在 （ 7+2 ）个知识块上。
- 20. 5.2 设计原 理 三. 逐 步 求 精 求精实际上是细化过程 求精要求设计者细化原始陈述，随着每个后续 求精（即细化）步骤的完成而提供越来越多的 细节。 抽象与求精是一对互补的概念 抽象使得设计者能够说明过程和数据，同时却 忽略低层细节。事实上，可以把抽象看作是一 种通过忽略多余的细节同时强调有关的细节， 而实现逐步求精的方法。求精则帮助设计者在 设计过程中逐步揭示出低层细节。这两个概念 都有助于设计者在设计演化过程中创造出完整 的设计模型。
- 21. 5.2 设计原 理 四 . 信息隐藏和局部化 信息隐藏思想：模块应该设计得使其所含的信息（过程 和 数据）对那些不需要这些信息的模块不可访问，模 块之 间仅仅交换那些为完成系统功能所必需交换的信息 。 隐藏：模块的实现细节，而不是所有信息。 优点： 1. 模块的独立性更好 2. 支持模块的并行开发（设计和编码） 3. 便于测试和维护，减少错误向外传播 4. 便于增加新的功能，新增加的模块和原有的
- 22. 5.2 设计原 理 四 . 信息隐藏和局部化 局部化：把一些关系密切的软件元素在物 理上放得彼此靠近。 例如：在模块中使用局部数据元素 有助于信息隐藏
- 23. 5.2 设计原 理 五. 模 块 独 立 模块独立性：每个模块只完成系统要求的独 立的子功能，与其他模块的联系最少且接口简 单。 模块独立的概念是模块化、抽象、信息隐藏 和局部化三个基本原理的直接结果。 模块独立重要的理由： 有效的模块化的软件比较容易开发 独立的模块比较容易测试和维护 衡量模块独立程度的标准：耦合、内聚
- 24. 5.2 设计原 理 五 . 模块独立 — — 1. 耦合性 耦合：指模块之间联系的紧密程度。模块之间联系越 紧密，其耦合性越强，独立性就越差。 模块耦合度越低越好： 1. 独立性； 2. 减少错误传播 。 模块的耦合性从低到高可分为以下几种类型： 非直接耦合 (no direct coupling) ： 二个模块都不依赖对方而独立存在 数据耦合 (data coupling) ： 二个模块通过参数交换信息，而信息仅限于数 据 控制耦合 (control coupling) ： 二个模块通过参数交换信息，传递的信息中有
- 25. 5.2 设计原 理 五 . 模块独立 — — 1. 耦合性 标记耦合 / 特征耦合 (stamp coupling) ： 二个模块通过传递数据结构加以联系（数据结构 以参数形式进行交换），或都与一个数据结构有 关 当被调模块只使用数据结构中的一部分数据元素 时，产生标记耦合 . 被调模块 可使用的数据多于它所需要的数据 ， 从而导 致对数据的访问失去控制，给非法操作提供了机会。
- 26. 5.2 设计原 五 . 模块独立 — — 1. 耦合性 理 非直接耦合举例 两个模块之间 没有直接关系 ，它们之间的 联系完全是通 过主模块的控 制和调用来实 现的。 这种耦合的模 块独立性最强
- 27. 5.2 设计原 五 . 模块独立 — — 1. 耦合性 理 数据耦合举例 一模块调用另 开发票 一模块时，被调 单价 用模块的输入、 金额 ， 输出都是简单的 数量 数据 ( 若干参 数 )。 计算水费 属松散耦合
- 28. 5.2 设计原 理 五 . 模块独立 — — 1. 耦合性 标记 / 特征耦合举例 “ 住户情况 ” 是一个数据结构，图中模块都与之有关。 “ 计算水电费 ” 和 “ 计算水费 ” 传递的是数据结构 , 它们之间 是标记偶合。 “ 计算水费 ” 和 “ 计算电费 ” 本无关 , 由于引用了此数据结构 产生依赖关系 , 它们之间也是标记偶合。 计算水电费 住户情况 水费 住户情况 电费 计算水费 计算电费
- 29. 5.2 设计原 五. 模块独立 — — 1. 理 耦合性 标记 / 特征耦合举例 把标记耦合修改为：数据耦合 / 非直接 耦合 计算水电费 本月 本月 水费 用电量 用水量 电费 计算水费 计算电费
- 30. 5.2 设计原 理 五 . 模块独立 — — 1. 耦合性 控制耦合举例 控制耦合 二个模块通过参数交 换信息，传递的信息中 有控制信息 去除控制耦合的方法 ： (1) 将被调用模块内的 判定上移到调用模块 中进行 (2) 被调用模块分解成 若干单一功能模块
- 31. 5.2 设计原 理 五 . 模块独立 — — 1. 耦合性 公共耦合 (common coupling) ：二个模块通过公共 数据环境相互作用 全程变量、共享的通信区、内存的公共覆盖区、任何 存储介质上的文件、物理设备 如果两个模块共享的数据很多，都通过参数传递可能 很不方便
- 32. 5.2 设计原 五 . 模块独立 — — 1. 耦合性 理 公共耦合举例 公共数据耦合存在的问题： 软件可理解性降低 软件可维护性差 诊断错误困难 软件可靠性差 ( 公共数据区及全程变量无保护措施 ) 慎用公共数据区和全程变量 !!!
- 33. 5.2 设计原 理 五 . 模块独立 — — 1. 耦合性 内容耦合 (content coupling) ： 一个模块访问另一个模块的内部数据； 一个模块不通过正常入口而转到另一个模块的内部； 两个模块有一部分程序代码重叠 ( 只可能出现在汇编程序 中)； 一个模块有多个入口 ( 这意味着一个模块有几种功能 ) 。
- 34. 5.2 设计原 五 . 模块独立 — — 1. 耦合性 理 内容耦合举例 Entry1 …… A B A Entry2 …… B 一模块直接访问 另一模块的内部 模块代码重 多入口模块 信息 ( 程序代码 叠 （只可能在汇编 或数据） 中出现）
- 35. 5.2 设计原 五 . 模块独立 — — 1. 耦合性 理 耦合性：弱← — — — — — — — — — — — — — — — — → 强 模块独立性：强← — — — — — — — — — — — — — — → 弱 1 2 3 4 5 6 弱耦合 中耦合 较强耦合 强耦合 ⒈ 非直接耦合：无信息交换 ⒉ 数据耦合：简单数据以参数形式进行交换 ⒊ 特征耦合：数据结构以参数形式进行交换 ; 或共享数据结构 ⒋ 控制耦合：参与交换的数据内包含控制信息 ⒌ 公共耦合：一组模块使用同一个全局性数据结构 / 公共 区 ⒍ 内容耦合：一个模块可以直接访问另一个模块内部数 据
- 36. 5.2 设计原 理 五 . 模块独立 — — 1. 耦合性 例：试指出下述用 C 语言编写的函数声明 所代表的 模块的耦合的类型。 void fun0( ); 无耦合 数据耦合 void fun1(int); 标记耦合 公共耦合 void fun2(int*); typedef struct{}DF; *DF fun4(int); 内容耦合 void fun5(){static x;…fun6(x);} ： fun6 可 以访问 int fun6(int x){return ++x;} fun5 的内
- 37. 5.2 设计原 理 五 . 模块独立 — — 1. 耦合性 在软件设计中，提高模块的独立性，建立模块间 尽可能松散的系统，是模块化设计的目标。为了 降低模块间的耦合度，可以采取以下措施： (1) 在耦合方式上降低模块间接口的复杂性。 (2) 在传递信息类型时的设计原则： 尽量采用数据耦合，避免使用控制耦合，慎 用或有控制地使用公共耦合，完全不用内容耦 合。在实践中要根据实际情况综合考虑。
- 38. 5.2 设计原 理 五 . 模块独立 — — 2. 内聚性 内聚性：模块内部各个元素彼此结合的紧密程度。 它是信息隐藏和局部化概念的自然扩展。 高内聚往往以意味着模块间的低耦合。 内聚性 偶然内聚（ coincidental cohesion ） 低 低内聚 逻辑内聚（ logical cohesion ） 时间内聚（ time cohesion ） 过程内聚（ procedural cohesion ） 中内聚 通信内聚（ communicational cohesion ） 顺序内聚（ sequential cohesion ） 高内聚 高 功能内聚（ functional cohesion ）
- 39. 5.2 设计原 理 五 . 模块独立 — — 2. 内聚性 ( 1) 偶然内聚 偶然内聚 — — 一个 模块内的各处理元 素之间没有任何联 系。 如一个模块内各个 成分为完成一组功 能而结合在一起， 模块 M 中的三个 他们相互之间关系 语句没有任何联系 缺点： 可理解性差， 可修改性差 松散。
- 40. 5.2 设计原 五 . 模块独立— — 2. 内聚性 理 (2) 逻辑内聚 逻辑内聚 — — 一个模 块完成的任务在逻辑 上属于相同或相似的 一类。 如一个模块完成的诸 任务逻辑上是相关的 ；如一个模块产生各 种类型的全部输出。 缺点：增强了耦合程 度 ( 控制耦合 ) 不易 修改，效率低
- 41. 5.2 设计原 理 五 . 模块独立 — — 2. 内聚性 ( 3) 时间内聚 时间内聚 — — 一个模块内所包含的诸任务必 须在同一时间段内执行。 这些 功能只因素关联因时间在 一起。 例如 : 初始化系统模块 系统结束模块
- 42. 5.2 设计原 理 五 . 模块独立 — — 2. 内聚性 ( 4) 过程内聚 过程内聚 — — 模块内处理元素彼此 相关且必须按特定 的次序 执行。 使用程序流程图作为工具设计软件时，常常通过研究流程 图确定模块的划分，这样得到的往往是过程内聚的模块。 读入 审查 统 打印 成绩单 成绩单 计 成绩 成 绩 读入并审查 统计并打印 成绩单 成绩单
- 43. 5.2 设计原 理 五 . 模块独立 — — 2. 内聚性 ( 5) 通信内聚 通信内聚 — — 模块内所有元素都使用相同的输入数 据或者 产 生相同的输出数据。 例：产生职工工资报表并计算平均工资模块 职工工 职工工资报表 产生工资报 资记录 表 平均工资 计算平均工资
- 44. 5.2 设计原 理 五 . 模块独立 — — 2. 内聚性 ( 6) 顺序内聚 ( 7) 功能内聚 顺序内聚 — — 一个模块中各个处理元素都密切 相关于同一功能且必须顺序执行，前一处理元 素的输出数据就是下一处理元素的输入数据。 功能内聚 — — 模块内所有处理元素属于一个整 体，完成一个单一的功能。 （最强的内聚！）
- 45. 5.2 设计原 理 五 . 模块独立 — — 2. 内聚性 内聚性：弱← — — — — — — — — — — — — — — — → 强 模块独立性：弱← — — — — — — — — — — — — — → 强 1 2 3 4 5 6 7 低内聚 中内聚 高内聚 ⒈ 偶然内聚 0 分： ⒉ 逻辑内聚 1 分：合并处理、变换相同或相似的功能 ⒊ 时间内聚 3 分：将因时序相同或接近的操作合并 ⒋ 过程内聚 5 分：将存在因果关系的功能集成 ⒌ 通信内聚 7 分：因数据的共用而合并 ⒍ 顺序内聚 9 分：将存在因果关系的操作集成 ⒎ 功能内聚 10 分：将只完成一个明确功能的操作合并
- 46. 5.2 设计原 理 五 . 模块独立 — — 3. 总结 耦合性与内聚性是模块独立性的两个 定性标准，将软件系统划分模块时，尽量做到 高内聚，低耦合，提高模块的独立性。 内聚和耦合是密切相关的，模块内的高内 聚往往意味着模块间的松耦合。内聚和耦合都 是进行模块化设计的有力工具，但是实践表明 内聚更重要，应该把更多注意力集中到提高模 块的内聚程度上。
- 47. 5.3 启发规 则 七条启发式规则 1 、模块的划分：高内聚，低耦合，保持相对独立性 2 、模块的大小 : 模块规模应该适中 3 、形成的结构：深度、宽度、扇出和扇入都应适当 “ 顶层扇出较高，中间扇出较小，底层模块高扇 入” 4 、模块的控制：模块的作用域应该在控制域之内 5 、模块的接口：简单、清晰、含义明确 6 、设计单入口单出口的模块 7 、模块功能应该可以预测
- 48. 5.3 启发规 则 1. 改进软件结构提高模块独立性 分析初步设计结构，通过 合并 或 分解 以 降低模块之间的耦合 、 提高模块的内聚 。 例如，多个模块公有的一个子功能可以独 立成一个模块，由这些模块调用；有时可以通 过分解或合并模块以减少控制信息的传递及对 全程数据的引用，并且降低接口的复杂程度。
- 49. 5.3 启发式规则 1.改进软件结构提高模块独立性 软件结构图反映了整个系统的功能实现 ，控制层次体系 , 往往用树状或网状结构的图形 来表示。 A A A B C B C B C D E F G H I D D E (a) 树状结构 (b) 简单网状结构 (c) 复杂网状结
- 50. 5.3 启发规 则 2. 模块规模应该适中 模块规模过大，降低可理解程度；模块过小，模 块开销大于有效操作，且系统的接口复杂。 过大模块－ > 进一步分解（保证模块独立性） 过小模块－ > 几个合并（尤其只被一个模块调 用时） 每个模块最好控制在 60 行语句以内。 语句数超过 30 以后，模块可理解性迅速下降
- 51. 5.3 启发规 则 3. 深度、宽度、扇入、扇 出都应该适中 越大越好但不 扇出 ( 一个模块直接调 深 违背模块独立 主模块 用的模块数 ) 度 原理 平均扇出： 3 ( 模 ～ 4 个为宜 A B C 块 的 ) 层 D E F G H I 数 扇入 ( 调用一个给定模 J 块的模块个数 ) 宽度 ( 同一层最大模块数 )
- 52. 5.3 启发规 3. 深度、宽度、扇入、扇 则 出都应该适中 分解或合并模块以调整扇入、扇出数 A A1 A2 A A B B B B1 B2 减少扇入数 减少扇出数
- 53. 5.3 启发规 则 4. 模块的作用域应该在控制域之 内 A 的控制域为： {A, B, C, D, E, F} 作用域：受该模块 内的一个判定影响 的所有模块的集合 控制域：模块本身 及所有直接或间接 从属于它的模块的 集合
- 54. 4. 模块的作用域应该在控制域 之内 “ ◇ ” 表示判定条件，它可影响另一个模块中用到的 全局变量 或静态变量 例1： W 例2： ◇ W A B B C D G H G H ◇ E F I J I J 最差，作用域不在控制域内 控制路径过长
- 55. 5.3 启发规 4. 模块的作用域应该在控制域之 则 内 例 3： W W 例 4： ◇ A B C D G ◇ H E F I J 较好 最好
- 56. 5.3 启发规 4. 模块的作用域应该在控制域 则 之内 作用域不在控制域内的修改方法： 1. 将 判定点上移到 足够高的位置 A 上移 ◇ A’ A’=A+D 判定点 B C ◇D E F B C E F
- 57. 5.3 启发规 4. 模块的作用域应该在控制域 则 之内 2. 将那些在作用域内但不在控制域内的模块下移 到控制域内 。 X 移动 ◇A ◇A X
- 58. 5.3 启发规 则 5. 力争降低模块接口的复杂度 目标： 仔细设计模块接口，使得信息传递 简单并且和模块的功能一致 标记耦 合 数据耦 合
- 59. 5.3 启发规 则 6. 设计单入口单出口模块 每个模块只有唯一入口和唯一出口
- 60. 5.3 启发规 则 7. 模块的功能应该可以预测 同样的输入可以产生同样的输出 带有内部“存储器”（如：静态变量）的模块，其 输出可能取决于内部存储器的状态（当前值） 即： 静态变量的当前值 == 》 模块的功能不可预测 。 如上例： 在另一个类的方法中 创建一个 counter 类 的对象。这个方法的功能就不可预测 但不应过分强调功能的可预见性而使模块失去 灵活性（无法重用模块）
- 61. 5.4 描绘软件结构的图形工 具 一. 层 次 图 层次图用来描绘软件的层次结构， 图 矩形框代表模块， 5.3 方框之间的连线表示调用关系。 正 文 加 工 系 统 的 层 次 图
- 62. 5.4 描绘软件结构的图形工 具 一. 层 次 图 层次图 ‡ 层次方框图 层次图 : 模块方框之间的连线表示 调用关系。 用于设计阶段 层次方框图 : 模块方框之间的连线表示 组成关系。 用于需求分析阶段， 第 3.7 节
- 63. 5.4 描绘软件结构的图形工 二 . HIP O 具图（ Hie ra rc hy Inp ut- P ro c e s s - O utp ut D ia g ra m ） HIPO 图 = 层次图（ H 图） + IPO 图（输入 / 处理 / 输出） 除最顶层的方框外，所有的方框加编号（编号规则同 数 据流图 中的编号） 对层次图中的各个模块，采用 IPO 图的方式说明该模块 的处理功能。每张 IPO 图内应标出该模块在 H 图中的编 号。 I P O 旧文件 １． 检验主 有效主记 记录 录 事务文件 ２． 更新主 记录
- 64. 5.4 描绘软件结构的图形工 二 .HIP O 具图（ Hie ra rc hy Inp ut- P ro c e s s - O utp ut D ia g ra m ）
- 65. 5.4 描绘软件结构的图形工 具 三. 结 构 图 由 Yourdon 提出 结构图 ＝ 层次图 ＋ 调用信息 1. 方框：模块的名字或功能 2. 箭头 ( 或直线 ) ：模块的调用关系；通常用直 线 3. 带注释的箭头：模块调用过程中来回传递的信 息 4. 尾部是空心圆：传递的是数据 5. 尾部是实心圆：传递的是控制信息
- 66. 5.4 描绘软件结构的图形工 具 图 结构图的例子
- 67. 三. 结 构图 另外的附加符号－ > 模块的选择调用或循环调用 A A A 通信所需 的数据 通信传递 的状态 B B C D B C 顺序结构 选择结构 循环结构
- 68. 5.4 描绘软件结构的图形工 具 三. 结 构 图 结构图一般不入文档，仅用于检查设计的正确性 和模块的独立性。 若图上模块间的联系不容易解释，则应考虑设 • 计上是否有问题 入文档的通常为层次图。 • 再加上 IPO 图和数据字典，就可导出结构图 •
- 69. 5.5 面向数据流的设计方 法 需求分析阶段：结构化分析 SA （ Structural Analysis ）是面向数据流自 顶向下逐步求精进行需求分析的方法。 设计阶段：结构化设计 SD （ Structured Design ）是以需求分析阶段产生的数据流 图为基础，按一定的步骤映射成软件结构 ，也称为面向数据流的设计方法。 数据流图 面向数据流的 软件 （ DFD ） 总体结构 设计方 法
- 70. 5.5 面向数据流的设计方 法 一 . 信息流的类型 1. 变换流 信息流映射成软件结构 事实上所有信息流都可归结为变换流
- 71. 5.5 面向数据流的设计方 一. 信息流的类型 法 1. 变换流 输入流 变换中心 输出流 输入 正确 信息 结果 数据 格式 信息 加工 显示 检查 物理 逻辑 逻辑 物理 输入 输入 输出 输出 汇款单 数据 格式 合格 计算 核准后的 汇款单 汇费 打印 检查 汇款单
- 72. 5.5 面向数据流的设计方 a. 信息流的类型 法 2. 事务流 数据沿输入通路到达 事务中心 ，该中心根据 输入数据的类型在 若干个动作序列中选择一个 来对该数据进行处理。具有这种特征的数 据流称为 事务流 。 事务中心 活动通路 事务中心任务： ① 接收 输入数据。 T ② 分析 每个事务，确定类型。 ③ 根据事务类型 选取 一活动 通路 。
- 73.
- 74. 5.5 面向数据流的设计方 法 二 . 变换分析 变换分析的设计步骤 1. 复查基本系统模型 。 2. 复查并精化数据流图 3. 确定数据流图具有变换特性还是事务特性 4. 确定 输入流和输出流的边界 ，从而划分出变换 中心 5. 完成第一级分解 6. 完成第二级分解 7. 使用设计度量和启发式规则对第一次分割得 到的软件结构进行精化
- 75. 5.5 面向数据流的设计方 法 二 . 变换分析 1. 复查基本系统模型（指 0 层数据流图 和第 1 层数据流图） 确保系统的输入数据和输出数据符合 实际。 2. 复查并精化数据流图 确保给出了正确的逻辑模型，而且 每个处理都代表一个规模适中相对 独立的子功能。
- 76. 5.5 面向数据流的设计方 四. 实例分析 — — 实例 法 1 汽车数字仪表板的设计 主要功能： 1. 通过模数转换实现传感器和微处理机接口 ； 2. 在发光二级管面板上显示数据； 3. 指示每小时英里数 mph 、行驶的里程、每 加仑 油行驶的英里数 mpg ；
- 77.
- 78. 3. 确定数据流图具有变换特性还是事务特 性 一般来说所有数据流图都可认为具有变换 特性，但当具有明显的事务特性时采用事 务分析。
- 79. 5.5 面向数据流的设计方 法 二 . 变换分析 4. 确定 输入流和输出流的边界 ，从而划分出 变换中心 输入流 变换中心 输出流 A B F E H I J C D G
- 80.
- 81. 5.5 面向数据流的设计方 法 二 . 变换分析 5. 完成第一级分解：确定顶层模块和由顶层直接 控制的模块，通常分为输入模块、变换模块和 输出模块。 方法：设计三个模块 输入 变换 输出 部分 部分 部分 CI ：输入控制模块 CP ：变换控制模块 ：输出控制模块 CO顶层模块的基本功 M 能是控制，协调 输入模块、变换 模块、输出模块 CI CP CO
- 82. 5.5 面向数据流的设计方 法 二 . 变换分析 图 5.14 数字仪表板系统的第一级分解
- 83. 5.5 面向数据流的设计方 法 二 . 变换分析 6. 完成第二级分解：将数据流图 中的每个处理映射成软件结构中 M 的一个适当模块。 D I A C B C B I ：由边界向外回溯，将每个遇到 D 的处理映成相应的层模块 。 A P ：每个处理直接对应一个下层 模块
- 84. 未精化的数字仪表板 5.5 面向数据流的设计方 系统 的软件结构 数字仪表板 法 控制 接收传感器 数据转换 驱动仪表板 信号 控制 转换成 计算 确 计 计 计 加/ 显 显 显 发 rpm gph 定 算 算 算 减 示 示 示 出 加 / mp mp 里 速 mph mpg 里 铃 减 h g 程 显 程 声 收集 sps 读燃 速 示 料流 读旋转信号 发光二极管显示
- 85. 5.5 面向数据流的设计方 法 二 . 变换分析 模块的简要说明 进出该模块的信息 ( 接口描述 ) ； 模块内部的信息； 过程陈述，包括主要判定点及任务等； 对约束和特殊特点的简短讨论。 7 、根据设计度量和启发式规则对第一次分 割得到的软件结构进行精化。
- 86. 5.5 面向数据流的设计方 法 图 5.19 精化后的数字仪表板系统的软件结
- 87. 5.5 面向数据流的设计方 法 二 . 变换分析 整个过程并不复杂，画好后根据实 际情况对软件结构进行优化，也就是进行 必要的合并或分解。以求设计出高内聚低 耦合的模块组成的、具有良好特性的软件 结构。
- 88. 5.5 面向数据流的设计方 法 三 . 事务分析 1 、基本过程与变换分析类似，差别在于由数据流图到 软件结构的映射方法不同。 2 、事务型软件结构 一个顶层模块（总控模块 M ） 下一层包括 2 个分支： ① 接收分支：负责接收数据并根据设计要求的格式实 现输入数据的交流（同变换分析）。 ② 发送分支：包括一个调度模块，控制下层的所有的 事务处理模块（对应数据流图上的事务种类数目）。 功能：接收事务数据，根据事务类型调度相应处理模
- 89. 5.5 面向数据流的设计方 法 三 . 事务分析 I 总 控 R R S S A I A B C B C
- 92. 5.5 面向数据流的设计方 法 三 . 事务分析 变换分析是软件结构设计的主要 方法。一般，一个大型的软件系统是变换 型结构和事务型结构的混合结构。所以， 我们通常利用变换分析为主，事务分析为 辅的方式进行软件结构的设计。
- 94. 5.5 面向数据流的设计方 法 三 . 事务分析 注意 ！ 没有明显的事务特征，按变换分析进行 机械性遵循映射规则，可能会得到一些不必 要的控制模块，此时可将这些控制模块与下 层模块合并； 如果一个控制模块功能太复杂，可以分解成 两个或多个模块
- 95. 5.5 面向数据流的设计方 法 五 设计优化 “ 一个不能工作的 ‘ 最佳设计 ’ 的价值是值得怀疑的 ” 在有效的模块化的前提下使用最少量的模块； 在能够满足信息要求的前提下使用最简单的数据 结构。 对时间起决定性作用的软件进行优化的方法。 “ 先使它能工作，然后再使它快起来 ”
Editor's Notes
- #9 方法 ： 结构化设计方法 （ SD ）—— 面向数据流的设计方法 面向对象设计方法 （ OOD ） 面向数据结构的设计方法
- #16 一个复杂的动态系统首先可以用一些高级的抽象概念构造和理解，这些高级概念又可以用一些较低级的概念构造和理解，如此进行下去，直至最低层次的具体元素。
- #21 我们从在高抽象级别定义的功能陈述（或信息描述）开始，也就是说，该陈述仅仅概念性地描述了功能或信息，但是并没有提供功能的内部工作情况或信息的内部结构。
- #25 当下层模块只使用数据结构中的一部分时，产生标记耦合
- #26 当下层模块只使用数据结构中的一部分时，产生标记耦合
- #29 特征 / 标记耦合 ： 数据结构 以 参数形式 进行交换 ; 当把整个数据结构作为参数传递，而被调用模块 只需要使用其中一部分数据元素 时。 == 问题： 可使用的数据 多于 所需要的数据 ， 导致： 对数据的访问失去控制， 从而 给计算机犯罪提供机会
- #30 “ 计算水电费”和“计算水费” 是 数据偶合 。 “ 计算水费”和“计算电费” 是 非直接偶合 。
- #31 控制耦合增加了理解和编程的复杂性，调用模块必须知道被调模块的内部逻辑，增加了相互依赖。
- #32 两个（甚至多个）模块共享的数据很多 ，都用参数传递很不方便，就可以利用： 公共耦合 。
- #35 一个模块 不通过正常入口而进入 另一个模块内部 : 如 病毒 一个模块有多个入口：说明这个模块有多个功能 许多高级程序设计语言 已经设计成 不允许任何形式的 内容耦合
- #37 特征 / 标记耦合 ： 数据结构 以 参数形式 进行交换 ; 当把整个数据结构作为参数传递，而被调用模块 只需要使用其中一部分数据元素 时， 公共耦合 ： 一组模块 使用同一个 全局性数据结构
- #46 偶然性内聚 0 分 ：减少相同操作的重复编码 ？
- #49 多个模块 公有的一个子功能 ， 可 独立 成一个模块
- #50 一 . 用图形表示软件的结构
- #51 书： 语句数超过 30 以后，模块可理解性迅速下降
- #55 如： 此判定 影响一个 D 中用到的 全局变量 或静态变量
- #60 不要使模块间出现内容耦合。当从顶部进入模块并且从底部退出来时，软件是比较容易理解的，因此也是比较容易维护的。
- #61 即： 带有 内部“存储器”（如：静态变量） 的模块，其 输出可能取决于内部存储器的状态（当前值） -- 如： 静态变量的当前值 == 》 模块的功能不可预测。 如： 在 另一个类的方法 中 创建一个 counter 类的对象。这个方法的功能就不可预测
- #62 3 章描绘数据结构的 层次方框图 ： 连线表示 组成关系
- #70 结构化分析
- #71 信息沿输入通路进入系统，同时由外部形式变换成内部形式，进入系统的信息通过变换中心， 经加工处理以后再沿输出通路变换成外部形式离开软件系统
- #77 例如电子燃油喷射系统、制动防抱死控制、防滑控制、牵引力控制、电子控制悬架、电子控制自动变速器、电子动力转向等
- #78 ，起步或者加油提速时感觉车速 加速 缓慢，但发动机 转速 上升得较快， 车辆在 加速 的时候 转速 上升，
- #80 不同设计人员可能会在流内选取稍微不同的点作为边界的位置。 当然在确定边界时应该仔细认真， 但是把边界沿着数据流通路移动一个处理框的距离，通常对最后的软件结构只有很小的影响。
- #85 P101