软件工程第5章总体设计.pptVIP

第五章总 体 设 计;;总体设计的任务;总体设计的必要性：可以站在全局高度上，花较少成本，从较抽象的层次上分析对比多种可能的系统实现方案和软件结构，从中选出最佳方案和最合理的软件结构，从而用较低成本开发出较高质量的软件系统。;5.1 设计过程;典型的总体设计过程包括:;3.推荐最佳方案 4.功能分解 5.设计软件结构 6.数据库设计 A．模式设计 B．子模式设计 C．完整性和安全性设计 D．优化 ;7.制定测试计划 8.书写文档 A．系统说明:包括用系统流程图描绘的系统构成方案，组成系统的物理元素清单，成本/效益分析；对最佳方案的概括描述，精化的数据流图，用层次图或结构图描绘的软件结构，用IPO图或其他工具简要描述的各个模块的算法，模块间的接口关系，以及需求、功能和模块三者之间的交叉参照关系等等。 B．用户手册:根据总体设计阶段的结果，修改更正在需求分析阶段产生的初步的用户手册。 C．测试计划:包括测试策略，测试方案，预期的测试结果，测试进度计划等等。 D．详细的实现计划 E．数据库设计结果 9.审查和复审 ;5.2 设计原理;5.2.1 模块化;这个不等式导致“各个击破”的结论—把复杂的问题分解成许多容易解决的小问题，原来的问题也就容易解决了。这就是模块化的根据。;模块数目;5.2.2 抽象;。 软件工程过程的每一步都是对软件解法的抽象层次的一次精化。 在可行性研究阶段，软件作为系统的一个完整部件；在需求分析期间，软件解法是使用在问题环境内熟悉的方式描述的；当由总体设计向详细设计过渡时，抽象的程度也就随之减少了；最后，当源程序写出来以后，也就达到了抽象的最低层。 ;5.2.3 逐步求精;5.2.4 信息隐藏和局部化;5.2.5 模块独立;1. 耦合;(1) 非直接耦合;(2) 数据耦合;(3) 标记耦合(特征耦合);(4) 控制耦合;控制耦合增加了理解和编程的复杂性，调用模块必须知道被调模块的内部逻辑，增加了相互依赖。 去除模块间控制耦合的方法： 将被调用模块内的判定移到调用模块中进行 被调用模块分解成若干单一功能模块;(5) 外部耦合;(6) 公共环境耦合(公共数据区耦合);(7) 内容耦合;以上给出了 7种耦合类型，这只是从耦合的机制上所做的分类，按耦合的强弱程度的排列只是相对的关系。但它给设计人员在设计程序结构时提供了一决策准则。实际上，开始时两个模块之间的耦合不只是一种类型，而是多种类型的混合。这就要求设计人员按照实际情况进行分析比较，逐步加以改进，以提高模块的独立性。;2. 内 聚 ;(1)功能内聚 (Functional Cohesion);(2)信息内聚(Informational Cohesion);(3)通信内聚(Communication Cohesion);(4)过程内聚（Procedural Cohesion）;(5)时间内聚（Classical Cohesion）;如图，在“紧急故障处理模块”中，“关闭文件”、“报警”、“保留现场”等任务都必须无中断地同时处理。;(6)逻辑内聚（Logical Cohesion）;(7)巧合内聚（Coincidental Cohesion）;内聚与耦合密切相关，同其它模块强耦合的模块意味者弱内聚，强内聚模块意味着与其它模块间松散耦合。 设计目标： 力争强内聚、弱耦合;5.3 启发规则;1. 改进软件结构提高模块独立性 设计出软件的初步结构以后，应该审查分析这个结构，通过模块分解或合并，力求降低耦合提高内聚。例如，多个模块公有的一个子功能可以独立成一个模块，由这些模块调用；有时可以通过分解或合并模块以减少控制信息的传递及对全程数据的引用，并且降低接口的复杂程度。;2. 模块规模应该适中 经验表明，一个模块的规模不应过大，最好能写在一页A4纸内(通常不超过60行语句)。有人从心理学角度研究得知，当一个模块包含的语句数超过30以后，模块的可理解程度迅速下降。 过大的模块往往是由于分解不充分，但是进一步分解必须符合问题结构，一般说来，分解后不应该降低模块独立性。 过小的模块开销大于有效操作，而且模块数目过多将使系统接口复杂。因此过小的模块有时不值得单独存在，特别是只有一个模块调用它时，通常可以把它合并到上级模块中去而不必单独存在。;3. 深度、宽度、扇出和扇入都应适当 深度：软件结构中控制的层数； 宽度：软件结构内同一个层次上的模块总数的最大值； 扇出：一个模块直接控制（调用）其它模块的数目； 扇入：一个模块被其它模块调用的数目。;深度往往能粗略地标志一个系统的大小和复杂程度。深度和程序长度之间应该有粗略的对应关系，当然这个对应关系是在