5系统设计-模块设计原则new.ppt

* * * * * * * * * * * * （1）消除重复的功能 同一功能的程序多次出现会浪费编码时间，并不易调试和维护，应予以合并。 Y X Q Q Q1 Q2 Y X Q Q Q1 Q2 Y X Q Y X Q Q1* Q2* Q X* Y* 正确的合并 错误的合并 (2)减少高扇出，争取高扇入 模块调用的直接下层模块的个数，称为扇出(Fan out) 模块被其他各模块调用的个数，称为扇入(Fan in) 原则：扇出不宜过大，=7；扇入尽可能大些。但CASE(分类)型模块扇出可7 ,因为属自然分类情况,易理解 (5,1) (4,0) (3,1) (0,2) 符号: (扇出,扇入) 扇入表明有多少个上级模块直接调用该模块，扇入越大，则共享该模块的上级模块数目越多，这是有好处的。 扇出是指某模块直接控制或调用的模块数目，扇出过大意味着模块过分复杂，需要控制和协调过多的下级模块，这时应适当增加中间层次的控制模块。扇出太小时应把下级模块进一步分解成若干个子功能模块或合并到上级模块。 如果一个规模很小的底层模块的扇入数为1，则可把它合并到它的上层模块中，但扇入数较大时则不能向上合并（否则将导致对该模块做多次编码和排错）。如果一个模块具有多种功能（扇出数较大），应当考虑做进一步分解，使模块的扇出数控制在7以内。 设计的较好的系统结构通常是顶层扇出较高，中层扇出较小，底层扇入较大。 清真寺型 不够好,底层模块复用度低 金字塔型 相关技巧： 良好的结构图往往呈“清真状”，即“顶为尖—下层逐渐加宽—底层收窄” 结构图的形态应该均衡，即从顶到底层的路径长短不该过于悬殊 (3) 模块大小适中 模块过大：可理解程度下降 考虑对该模块分解 模块过小：开销大于有效操作， 系统接口复杂 考虑是否同它的调用模块合并 几种情况下的小模块不合并： 模块具有独立的功能 模块功能可能会发生变化 模块的复用性好，或者其调用模块很复杂 (4)降低模块接口的复杂性 接口传递信息应简单且和模块功能一致。 例：求一元二次方程的根 设求根模块调用形式为： (1) QUAD－ROOT(TBL，X) TBL传递系数的数组 X存放根的数组 (2) QUAD－ROOT(A,B,C,ROOT1, ROOT2) A,B,C为方程系数 ROOT1,ROOT2是两个根 (5) 模块功能可预测 可将模块看成黑盒子，相同输入可产生相同输出，称其功能为可预测的。 模块带有内部状态，其功能可能是不可预测的。这样的模块难理解、难测试、难维护。 * * * * * * * * * * * * * * * * * * * * 公共耦合的缺点是：在使用同一全局数据域的模块中，如果其中一个模块出现错误，则很可能该错误也出现在使用该数据域的其它模块中；如果要修改一个模块，则很难确定哪些数据必须进行相应的修改；同样，如果要修改某一个数据，也很难确定哪些模块必须予以修改。 * * 公共耦合举例 Ａ 公共数据区 C B 模块A、B、C间存在错综复杂的联系 公共耦合举例 所有的公共 耦合关系 A E B C D 6个模块共享一 个公共数据区 F (1)系统可理解性降低 (模块间存在错综复杂的连系) (2)系统可维护性差 (修改变量名或属性困难) (3)系统可靠性差 (公共数据区及全程变量无保护措施) 慎用公共数据区和全程变量!!! 公共耦合存在的问题： (6) 内容耦合 如果两个模块之一和另一个模块的内部属性有关（一个模块直接调用另一个模块的内容），则称这两个模块为内容耦合，也称之为病态耦合（pathological coupling），这是一种最高程度的耦合，应避免使用。 最不好内容耦合形式 !!! 发生内容耦合的情形： (1)一模块直接访问另一模块的内部数据 (2)一模块不通过正常入口转到另一模块内 (3)两模块有一部分代码重叠 (4)一模块有多个入口 模块化设计对耦合度的要求： 耦合是影响系统复杂程度和设计质量的重要因素 目标：建立模块间耦合度尽可能松散的系统 如何降低模块间耦合度： (1) 如模块必须存在耦合，选择适当的耦合类型 原则：尽量使用数据耦合 　　　少用控制耦合 　　　限制公共耦合的范围 　　　坚决避免使用内容耦合 (2) 降低模块间接口的复杂性 接口复杂性与耦合类型的关系： 接 口 复 杂 性 接口方式 接口数据 的复杂性 无接口关系 直接引用 过程调用语句 数据项作参数 数据结构，变 量名作参数 内容耦合 其它耦合 开关量，起 控制变量作用 公用数据区 全程变量 数据耦合 标记耦合 控制耦合 公共耦合 非直接