第五章详细设计.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）Do while C1 ………… If C2 undo ………… ENDDO [例] C语言中的 break；PowerBuilder中的 return 4)GOTO语句不应滥用，但也不必完全禁止。 逐步细化的实现方法 把给定的模块功能转变为它的详细过程性描述，通常可采用逐步细化的策略，大量的实践表明，逐步细化很适合于详细设计。 [例1] 在一组数中找出其中的最大数。 通过这一实例。可以把逐步细化的步骤归纳为： 由粗到细地对程序进行逐步细化，每一步可选择其中的一条至数条，将它们分解成更多更详细的程序步骤； 在细化程序的过程中，同时对数据的描述进行细化，换句话说，过程和数据结构的细化要并行地进行，在适当的时候要交叉穿插； 每一步细化均使用相同的结构化语言，最后一步直接用“程序设计语言”来描述，以便编码时直接翻译成源程序。 逐步细化的优点： 先后有序，主次分明，可避免全面开花，顾此失彼； 易于验证程序的正确性；（其实质是要求在每步细化中确保实现前一步的要求，不要等程序写完后再来验证。形式化的程序正确性证明采用公理化的证明规则，方法十分繁琐。） 用“结构化”保证程序的清晰易读，用“逐步细化”实现程序的正确可靠，它们导致了一条自然的结论：模块的逻辑设计必须用结构化程序设计的原理来指导。 5.3 详细设计工具 描述程序处理过程的工具称为详细设计工具，可分为：图形工具，表格工具和语言工具，不论是哪类工具，对它们的基本要求都是能提供对设计的无歧义性描述，也就是应该能指明控制流程、处理功能、数据组织等方面的实现细节，从而能在编码阶段把对设计的描述直接翻译成程序代码。 5.3.1 程序流程图(流程图) 流程图（flow diagram）））））……也许这就是它迅速流传的原因。 [例2] 分别用N-S图和PAD图描述： “在一组数中找出其中的最大数”的程序过程。 PAD图的特点： 使用PAD图设计出的程序必定是结构化程序； PAD图所表达的程序其结构十分清晰：图中最左边的纵线是程序的主干