第2章软件设计基本概念.pptVIP

* * 评价： 比时间内聚好，至少操作之间是过程关联的。 仍是弱连接，不太可能重用模块。 解决方案： 分割为单独的模块，每个模块执行一个操作。 (5) 通信内聚(communicational cohesion) 如果模块中所有元素都使用同一个输入数据和(或)产生同一个输出数据，则称为通信内聚。即在同一个数据结构上操作。 通信内聚举例 评价： 模块中各操作紧密相连，比过程内聚更好。 不能重用。 解决方案： 分成多个模块，每个模块执行一个操作。 (6) 顺序内聚(sequential cohesion) 如果一个模块内的处理元素和同一个功能密切相关，而且这些处理必须顺序执行，前一功能元素的输出就是下一功能元素的输入。则称为顺序内聚。 评价： 根据数据流图划分模块时，通常得到顺序内聚的模块，这种模块彼此间的连接往往比较简单。 顺序内聚举例：根据出生年份得出年龄，根据年龄得到退休时间 (7) 功能内聚(functional cohesion) 如果模块内所有处理元素属于一个整体，完成一个单一的功能，则称为功能内聚。功能内聚是最高程度的内聚。 评价： 模块可重用，应尽可能重用； 可隔离错误，维护更容易； 扩充产品功能时更容易。 七种内聚的优劣评分结果： 高内聚：功能内聚 10分 顺序内聚 9分 中内聚：通信内聚 7分 过程内聚 5分 低内聚：时间内聚 3分 逻辑内聚 1分 偶然内聚 0分 设计时力争做到高内聚，并且能够辨认出低内聚的模块。 2.3 启发规则 1. 改进软件结构提高模块独立性 通过模块分解或合并，降低耦合提高内聚。 两个方面： 模块功能完善化。一个完整的模块包含： 执行规定的功能的部分 出错处理的部分 返回一个“结束标志” 消除重复功能，改善软件结构。 完全相似 局部相似 例：若其中B、C、D之间存在内容耦合，可将它们合并为一个模块BCD，若E、F中有一个公共的子功能，可将该子功能独立成一个模块。 A B C D E F A BCD E′ F′ E′F′ 2. 模块规模应该适中 经验表明，一个模块的规模不应过大，最好能写在一页纸内。通常规定50~100行语句，最多不超过500行。数字只能作为参考，根本问题是要保证模块的独立性。 过大的模块往往是由于分解不充分，但是进一步分解必须符合问题结构，一般说来，分解后不应该降低模块独立性。 过小的模块开销大于有效操作，而且模块数目过多将使系统接口复杂。 3. 深度、宽度、扇出和扇入都应适当 深度：软件结构中控制的层数，它往往能粗略地标志一个系统的大小和复杂程度。 宽度：软件结构内同一个层次上的模块总数的最大值。 扇出：一个模块直接控制(调用)的模块数目。 扇入：有多少个上级模块直接调用它。 应尽量减少高扇出结构，特别是当深度增加时，力求扇入。 扇入过大则共享该模块的上级模块数目多，能够增加模块的利用率，防止设计冗余，但是，不能违背模块独立原则单纯追求高扇入。扇出过大意味着模块越复杂，需要控制和协调过多的下级模块 。 经验表明，一个设计得好的典型系统平均扇出通常是3或4（扇出的上限通常是5~9）。 举例：避免平铺结构 举例：避免平铺结构 改进-增加中间层降低扇出 4. 模块的作用域应该在控制域之内 模块的作用域：定义为受该模块内一个判定影响的所有模块的集合。 模块的控制域：是这个模块本身以及所有直接或间接从属于它的模块的集合。 在一个设计得很好的系统中，所有受判定影响的模块应该都从属于做出判定的那个模块，最好局限于做出判定的那个模块本身及它的直属下级模块。 举例1 举例2 举例3 举例3解决方案： 把模块A中的判定移到模块M中； 把模块G移到模块A下面，作为他的下级模块。 5. 力争降低模块接口的复杂程度 模块接口复杂是软件发生错误的一个主要原因。应该仔细设计模块接口，使得信息传递简单并且和模块的功能一致。 例：解一元二次方程的函数 QUAD_ROOT(TBL,X) 其中数组TBL传送方程的系数 数组X送回求得的根 QUAD_ROOT(A,B,C,ROOT1,ROOT2) 6. 设计单入口单出口的模块 警告软件工程师不要使模块间出现内容耦合。当从顶部进入模块并且从底部退出来时，软件是比较容易理解的，因此也是比较容易维护的。 7. 模块功能应该可以预测 模块的功能应该能够预测，但也要防止模块功能过分局限。 功能可预测：如果一个模块可以当做一个黑盒子，只要输入的数据相同就产生同样的输出，这个模块的功能就是可以预测的。 小结 总体设计阶段的基本目的 用