第四章 总体设计.ppt

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
(7)内容耦合 如果出现以下情形,两个模块之间就发生了内容耦合: 一个模块访问另一个模块的内部数据。 一个模块不通过正常入口转到另一个模块的内部。 两个模块有一部分代码重叠(只可能出现在汇编程序中)。 一个模块有多个入口(这意味着一个模块有几种功能)。 模块化的原则 模块化设计的最终目标,是希望建立模块间耦合尽可能松散的系统。 在这样一个系统中,我们设计、编码、测试和维护其中任何一个模块,就不需要对系统中其他模块有很多的了解。 此外,由于模块间联系简单,发生在某一处的错误传播到整个系统的可能性很小。 5.2 软件设计原理 ** 内聚性(Cohesion) 内聚性标志一个模块内各个元素彼此结合的紧密程度。 模块内的高内聚往往意味着模块间的松耦合。内聚和耦合都是模块化设计的有力工具,但是实践表明内聚更重要,应该把更多注意力集中到提高模块的内聚程度上。 5.2 软件设计原理 ** (1)巧合内聚 巧合内聚又称为偶然内聚。 当模块内各部分之间没有联系,或者即使有联系,这种联系也很松散,则称这种模块为巧合内聚模块,它是内聚程度最低的模块。 这种模块的缺点 首先是不易修改和维护。 其次是这种模块的内容不易理解,很难描述它所完成的功能,增加了程序的模糊性。 5.2 软件设计原理 ** (2)逻辑内聚 这种模块把几种相关的功能组合在一起,每次调用时,由传送给模块的判定参数来确定该模块应执行哪一种功能。 这种模块是单入口多功能模块。类似的有错误处理模块。它接收出错信号,对不同类型的错误打印出不同的出错信息。 逻辑内聚模块比巧合内聚模块的内聚程度要高 。 逻辑内聚的缺点 它所执行的不是一种功能,而是执行若干功能中的一种,因此它不易修改。 另外,当调用时需要进行控制参数的传递,这就增加了模块间的耦合程度。 而将未用的部分也调入内存,这就降低了系统的效率。 5.2 软件设计原理 ** (3)时间内聚 时间内聚又称为经典内聚。 这种模块大多为多功能模块,但模块的各个功能的执行与时间有关,通常要求所有功能必须在同一时间段内执行。 例如初始化模块和终止模块。初始化模块要为所有变量赋初值,对所有介质上的文件置初态,初始化寄存器和栈等,因此要求在程序开始执行的最初一段时间内,模块中所有功能全部执行一遍。 5.2 软件设计原理 ** (4)过程内聚 如果一个模块内的处理是相关的,而且必须以特定次序执行,则称这个模块为过程内聚模块。 使用流程图做为工具设计程序的时候,常常通过流程图来确定模块划分。把流程图中的某一部分划出组成模块,就得到过程内聚模块。 例如,我们把流程图中的循环部分、判定部分、计算部分分成三个模块,这三个模块都是过程内聚模块。 5.2 软件设计原理 ** (5)通信内聚 如果一个模块内各功能部分都使用了相同的输入数据,或产生了相同的输出数据,则称之为通信内聚模块。 通信内聚模块是通过数据流图来定义的。 5.2 软件设计原理 ** (6)信息内聚 这种模块完成多个功能,各个功能都在同一数据结构上操作,每一项功能有一个唯一的入口点。 5.2 软件设计原理 ** (8)功能内聚 一个模块中各个部分都是完成某一具体功能必不可少的组成部分,或者说该模块中所有部分都是为了完成一项具体功能而协同工作,紧密联系,不可分割的。则称该模块为功能内聚模块。 功能内聚模块的优点是它们容易修改和维护,因为它们的功能是明确的,模块间的耦合是简单的。 5.2 软件设计原理 ** (7) 顺序内聚 如果一个模块内的处理元素和同一个功能密切相关,而且这些处理必须顺序执行(通常一个处理元素的输出数据作为下一个处理元素的输入数据) 5.3 启发式规则 *** 启发式规则多数是经验规律,对改进设计,提高软件质量,往往有重要的参考价值; 但是,它们既不是设计的目标也不是设计时普遍遵循的原则。 1 改进软件结构提高模块独立性 设计出软件的初步结构以后,应该审查分析这个结构,通过模块分解或合并,力求降低耦合提高内聚。 例如,多个模块公有的一个子功能可以独立成一个模块,由这些模块调用; 有时可以通过分解或合并模块以减少控制信息的传递及对全局数据的引用,并且降低接口的复杂程度。 5.3 启发式规则 *** 2 模块规模应该适中 经验表明,一个模块的规模不应过大。过大的模块往往是由于分解不充分,但是分解后不应该降低模块独立性。 过小的模块开销大于有效操作,而且模块数目过多将使系统接口复杂。因此过小的模块有时不值得单独存在,特别是只有一个模块调用它时,通常可以把它合并到上级模块中去而不必单独存在。 5.3 启发式规则 *** 3 深度、宽度、扇入和扇出都应适当 深度表示软件结构中控制的层数,它往往能粗略地标志一个系统的大小和复杂程度。 如果层数过多则应

文档评论(0)

勤能补拙 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档