第五章 软件设计.pptVIP

软件工程 - 2011 - 第六章 详细设计 第六章详细设计 详细设计阶段的根本目标是确定应该怎样具体地实现所要求的系统。 详细设计的目标不仅仅是逻辑上正确地实现每个模块的功能，更重要的是设计出的处理过程应该尽可能的简明易懂。 结构程序设计是实现上述目标的关键技术，是详细设计的逻辑基础。 结构程序设计的概念最早由E.W.Dijkstra在1965年提出，他指出：“可以从高级语言中取消GOTO语句”，“程序的质量与程序中所包含的GOTO语句的数量成反比”。 1966年Bohm和Jacopini证明了，只用3种基本的控制结构就能实现任何单入口单出口的程序。这3种基本的控制结构是“顺序”、“选择”和“循环”。 1968年Dijkstra再次建议，1971年IBM成功地应用结构程序设计在纽约时报信息库管理系统和美国宇航局飞行模拟实验中 结构程序设计的经典定义如下所述：“如果一个程序的代码块仅仅通过顺序、选择和循环这3种基本控制结构进行连接，并且每个代码块只有一个入口和一个出口，则称这个程序是结构化的。” 对经典定义的扩充“结构程序设计是尽可能少用GOTO语句的程序设计方法。最好仅在检测出错误时才使用GOTO语句，而且应该总是使用前向GOTO语句。” 经典的结构程序设计：如果只允许使用顺序、IF-THEN-ELSE型分支和DO-WHILE型循环这3种基本控制结构实现单入口单出口的程序 扩展的结构程序设计：如果除了上述3种基本控制结构之外，还允许使用DO-CASE型多分支结构和DO-UNTIL型循环结构 修正的结构程序设计：如果再加上允许使用LEAVE(或BREAK)结构 系统响应时间 用户帮助设施 出错信息处理 命令交互 系统响应时间：指从用户完成某个控制动作(例如，按回车键或点击鼠标)，到软件给出预期的响应(输出信息或做动作)之间的这段时间 两个属性 长度 易变性 帮助设施分为集成的和附加的两类 具体设计帮助设施时，必须解决的问题 在用户与系统交互期间，是否在任何时候都能获得关于系统任何功能的帮助信息?（提供部分功能的帮助信息和提供全部功能的帮助信息） 用户怎样请求帮助?（帮助菜单、特殊功能键和HELP命令） 怎样显示帮助信息?（在独立的窗口中、指出参考某个文档和在屏幕固定位置显示简短提示） 用户怎样返回到正常的交互方式中?（屏幕上的返回按钮和功能键） 怎样组织帮助信息?（平面结构，信息的层次结构和超文本结构） 交互式系统给出的出错信息或警告信息，应具备的属性： 信息应该用用户可以理解的术语描述问题。 信息应该提供有助于从错误中恢复的建设性意见。 信息应该指出错误可能导致哪些负面后果 信息应该伴随着听觉上或视觉上的提示 信息不能带有指责色彩 在提供命令交互方式时，必须考虑的设计问题： 是否每个菜单选项都有对应的命令 采用何种命令形式（控制序列(例如，Ctrl+P)，功能键和键入命令） 学习和记忆命令的难度有多大 用户是否可以定制或缩写命令 一般交互指南 保持一致性 提供有意义的反馈 在执行有较大破坏性的动作之前要求用户确认 允许取消绝大多数操作 减少在两次操作之间必须记忆的信息量 提高对话、移动和思考的效率 允许犯错误 按功能对动作分类，并据此设计屏幕布局 提供对用户工作内容敏感的帮助设施 用简单动词或动词短语作为命令名 信息显示指南 只显示与当前工作内容有关的信息 不要用数据淹没用户 使用一致的标记、标准的缩写和可预知的颜色 允许用户保持可视化的语境 产生有意义的出错信息 使用大小写、缩进和文本分组以帮助理解 使用窗口分隔不同类型的信息 使用“模拟”显示方式表示信息 高效率地使用显示屏 数据输入指南 尽量减少用户的输入动作 保持信息显示和数据输入之间的一致性 允许用户自定义输入 交互应该是灵活的，并且可调整成用户最喜欢的输入方式 使在当前动作语境中不适用的命令不起作用 让用户控制交互流 对所有输入动作都提供帮助 消除冗余的输入 表达过程规格说明的工具叫做详细设计工具： 图形工具 表格工具 语言工具 程序流程图（Program Flow Chart） 程序流程图本质上不是逐步求精的好工具，它诱使程序员过早地考虑程序的控制流程，而不去考虑程序的全局结构。 程序流程图中用箭头代表控制流，因此程序员不受任何约束，可以完全不顾结构程序设计的精神，随意转移控制。 程序流程图不易表示数据结构。 必须限制程序流程图只能使用五种基本的控制结构 需要对流程图所用的符号做出确切的规定 盒图（Box-Diagram）（N-S图） Nassi和Shneiderman提出 盒图有下述特点： 功能域(即某个特定控制结构的作用域)明确，可以从盒图上一眼就看出来。 不可能任意转移控制。 很容易确定局部和全程数据的作用域。 很容易表现嵌套关系，也