第五章详细设计.doc

第五章 详细设计 5.1 详细设计的任务 5．1．1 目的 为SC中每个模块确定采用的算法和块内数据结构，用某种选定的表达工具给出详细清晰的过程描述（因此有的书中也称“详细设计”为“过程设计”）。 5．1．2 主要内容 1）为每个模块确定采用的算法；（表达算法的过程——写出模块详细的过程性描述） 2）确定每个模块使用的内部数据结构； 3）确定模块的接口细节；（系统外部/用户界面/系统内部/ 模块的输入输出/局部数据） 4）制定模块的测试计划。 5.2 模块的逻辑设计（模块的过程描述） 在上个“总体设计”阶段我们完成了“软件结构”设计，给出了系统中各个模块的功能和模块之间的联结（接口），即完成了系统中各个模块的“外部属性”的设计；其实，本阶段我们就是要完成模块的“内部属性”设计，即给出系统中各个模块的“运行程序”和“内部数据”；由此可见详细设计的结果基本上决定了最终软件的质量。因此，（根据软件质量特性）详细设计的目标不仅仅是逻辑上正确、性能上符合要求，等等，更重要的是要看它是否简明易懂（容易阅读容易理解），便于维护。 那么，怎样才能做到这一点呢？也即模块的逻辑设计应遵循什么样的理念呢？ 从效率第一到清晰第一 早在1965年，E.W.Dijkstra就公开提出了从高级语言中取消 GOTO语句的主张。他认为，一个程序中包含的GOTO语句愈多，其可读性愈差。时而GOTO过来，时而GOTO回去，会把程序搞成一团乱麻。有人称这种难读的程序为“通心面”程序（Bowl of Spaghetti,简称BS程序），使人联想起细面条在锅里结成块，“剪不断，理还乱”的尴尬情况。 E.W.Dijkstra的主张得到了许多人的支持，但也有人反对这种“一刀切”的做法，提出了不同的意见，经过近十年的激烈辩论，终于得出了一致的意见：“GOTO语句必须限制使用”，其实这场辩论的真正意义在于：改变了人们单纯强调程序效率的旧观念，认识到编写清晰易读程序的重要性。 除非使用特别频繁，或者对执行时间有严格要求的实时程序,仍需在效率与清晰度之间作出仔细的权衡外，在大多数情况下，应该优先考虑程序的清晰度，而把效率的考虑放在第二位。 结构化的控制结构 难道程序中使用的GOTO语句的多少是衡量这个程序清晰度的唯一标准吗？不是的！！！从根本上说，要想改善程序的清晰度，必须从改善每个（模块的）控制结构入手，（这就是结构程序设计的思想，也是详细设计阶段指导模块逻辑设计应遵循的原则。） （1）1966年，Bohm和Jacopini的证明：任何程序的逻辑均可用顺序、选择和循环（do－while）这三种控制结构或它们的组合来实现；（从而在理论上为结构化程序设计奠定了基础） （2）1968年，E.W.Dijkstra的建议：仅使用这三种控制结构来构成程序； （3）1972年，Mills的原则：每个控制结构只该有一个入口和一个出口。 图：三种基本的控制结构 上述三点综合在一起，向我们提示了一个重要事实：如果在详细设计中，所有模块都只使用单入口、单出口的三种基本控制结构，则不论一个程序包含多少个模块，也不论一个模块包含多少基本控制结构，整个程序将仍能保持一条清晰的线索——这就是我们说的“结构化”的控制结构。后来人们把遵循这三点来设计程序取了一个漂亮的名字——“结构化程序设计”。 [注] 结构化程序设计的缺点：需要的存储容量和运行时间估计增加10%到20%左右。 [注] 1）结构化程序设计=仅使用单入口单出口的三种基本控制结构； 2）扩展的结构化程序设计=结构化程序设计+do-until+do-case； 图：（a）do-until和（b）do-case控制结构 3）修正的结构化程序设计=扩展的结构化程序设计+undo； Do while C1 ………… If C2 undo ………… ENDDO [例] C语言中的 break；PowerBuilder中的 return 4)GOTO语句不应滥用，但也不必完全禁止。 逐步细化的实现方法 把给定的模块功能转变为它的详细过程性描述，通常可采用逐步细化的策略，大量的实践表明，逐步细化很适合于详细设计。 [例1] 在一组数中找出其中的最大数。 通过这一实例。可以把逐步细化的步骤归纳为： 由粗到细地对程序进行逐步细化，每一步可选择其中的一条至数条，将它们分解成更多更详细的程序步骤； 在细化程序的过程中，同时对数据的描述进行细化，换句话说，过程和数据结构的细化要并行地进行，在适当的时候要交叉穿插； 每一步细化均使用相同的结构化语言，最后一步直接用“程序设