Transcript 内聚和耦合（续）
第4章 结构化软件设计 6 学时 引言— 设计人员把分析的结果设计图纸 程序员拿着设计图纸编写代码 采编部 IPO1 DS5 预订记录 订图 书 预定 读者 IPO2 DS2 DS6 IPO4 图书编目 新书发布 图书信息 查询 DS1 IPO3 DS3 概要设计 读者 IPO5 借还书信息 还书 系统参数 借书 IPO9 IPO7 IPO8 系统参数 读者管理 处罚管理 流通部 DS4 模块 3 模块 1 IPO6 读者信息 设计图纸-软件结构图 模 块 罚款信息 模块 5 4 办公室 模块 2 名字：读者信息 编号：DS01 描述：记录读者的基本信息 定义：读者信息= 姓名 + 单位 + 读者类型 + 职称 + 电话 位置：数据库的读者信息表 输 入 处理说明 读 者 输入读者 模块 6 详细设计 模块4设计 输出 开始 还书处理模块 输入：读者号，图书号 DS102 备注： 需求规 格说明 书 按读者号和图书号检索借书记录表 无 发现记录？ 有 提示没有借书记录 在原记录上填写还书日期 图书信息中的在库册数+1 需求分析成果 结束 第4章 结构化软件设计 1）结构化设计的基本概念 2）方法和步骤 2）详细设计的方法。 3）软件设计的原则。 4）影响软件设计的主要因素。 要求 掌握 掌握 掌握 理解 了解 通过软件设计将用户的需求变为实现软件的“蓝 图”。蓝图只描述软件的整体框架，也叫做概要设 计。概要设计之后，就要对软件进行详细设计，通 过对软件设计的不断细化，形成一个可以实施的设 计方案。 软件设计的最终目标是要取得最佳方案。“最佳” 是指在所有候选方案中，能够以最低的成本，在最 短的时间内，生产出可靠性和可维护性俱佳软件的 方案。 4.1 软件设计的概念 4.1.1模块和模块化 一般把用一个名字就可调用的一段程序称为 “模块”。模块具有如下三个基本属性。 功能：指该模块要完成的任务。 逻辑：模块内部执行过程。 状态：使用该模块时的环境和条件。 4.1.1模块和模块化（续） 把整个系统划分成若干个模块，每个模块完成一个 子功能，将多个模块组织起来实现整个系统的功能。 模块化设计方法强调清楚地定义每个模块的功能和 它的输入/输出参数，而模块的实现细节隐藏在各 自的模块之中，与其它模块之间的关系可以是调用 关系，因此模块化程序易于调试和修改。 随着模块规模的减小，模块的开发成本减少，但是 模块之间的接口变得复杂起来，使得模块的集成成 本增加。 4.1.2内聚和耦合 在软件设计中应该保持模块的独立性原则。 反映模块独立性的有两个标准：内聚和耦合。 内聚衡量一个模块内部各个元素彼此结合的紧 密程度 耦合衡量模块之间彼此依赖的程度。 4.1.2内聚和耦合（续） 模块间相互关联的程度取决于下面几点： 一个模块对另一个模块的访问，比如模块A可能 要调用模块B来完成一个功能。 模块间传递的数据量。 模块间接口的复杂程度。 Independent Great deal of dependence Highly coupled Loosely coupled Uncoupled 7种耦合的独立性 模块耦合性 低 高 内容耦合 弱 公共耦合 外部耦合 模块独立性 控制耦合 数据结 构耦合 数据耦合 非直接耦合 强 4.1.2内聚和耦合（续） 内容耦合：如果一个模 块直接引用另一个模块 的内容。 例1：A访问C的内部数 据或不通过正常入 口而转入C的内部。 …… A A: ………… ………… goto C1 ………… ………… B C C: ………… ………… C1: …… …… D 公共耦合——多个模块都访问同一个公共数据环境，则称它 们是公共耦合。 Global:V1, V2 A: A1=V1+V2 ………… B: V1=B1 ………… Global:V1,V2 A: V1++ ………… B: V2=B1+V1 ………… 问题：公共部分的改动将影响所有调用它的模块； 公共部分的数据存取无法控制； 复杂程度随耦合模块的个数增加而增加 控制耦合——模块A向模块B传递一个控制信息，称这两个模 块是控制耦合的。 B Fn …… Flag A Flag F2 …… F1 B模块的具体功能取决于控制信息Flag 数据耦合——如果两个模块传递的是数据 项，则这两个模块是数据耦合。 A模块 参数 B模块 7种内聚的独立性 内聚：模块内部各个元素彼此结合的紧密程度 内聚和耦合（续） 功能内聚 ：一个模块中各个部分都 是完成某一具体功能必不可少的组成 部分，或者说该模块中所有部分都是 为了完成一项具体功能而协同工作， 紧密联系，不可分割的。则称该模块 为功能内聚模块。 内聚和耦合（续） 顺序内聚——如果一个模块中的处理元素和 同一个功能密切相关，并且这些处理必须是 顺序执行的，那么这个模块具有顺序内聚。 内聚和耦合（续） 通信内聚:一个模块内各功能部分 都针对相同输入/输出数据进行处 理。 内聚和耦合（续） 过程内聚：模块执行的若干动作，相互关联并且有顺 序关系。例如，从录入界面读取数据，然后更新数据 库记录。它仍然是将多个相关的功能放在一个模块中 实现。 内聚和耦合（续） 时间内聚：模块的各个功能的执 行与时间有关，通常要求所有功 能必须在同一时间段内执行。例 如初始化模块和终止模块。 内聚和耦合（续） 逻辑内聚：一个模块 完成的任务在逻辑上 相同/相似。 from disk from tape from …… A: 读磁盘 读磁带 读光盘 内聚和耦合（续） 巧合内聚又称为偶 然内聚。当模块内 各部分之间没有联 系，或者即使有联 系，这种联 系也 很松散。 4.1.3抽象 所谓抽象就是将事务的相似方面集中和概括起来， 暂时忽略它们之间的差异。或者说，抽象就是抽出 事务的本质特性而暂时不考虑它们的细节。 在最高的抽象层次上，用自然语言，配合面向问题 的专业术语，概括地描述问题的解法。 在中间的抽象层次上，采用过程化的描述方法。 在最底层，使用能够直接实现的方式来描述问题的 解。 4.1.4信息隐藏 核心内容是：一个模块中所包含的信息，不允许其 他不需要这些信息的模块访问。 模块化可以通过定义一组相互独立的模块来实现， 这些独立的模块彼此间仅仅交换那些为完成相应功 能而必须交换的信息。 信息隐蔽对模块的过程细节和局部数据结构进行了 屏蔽。 在设计模块时采取信息隐藏，使得大多数处理细节 对软件的其他部分是隐蔽的。在将来修改软件时偶 然引入错误所造成的影响就可以局限在一个或几个 模块内部，不至于波及到软件其他部分。 4.1.5软件结构图 Yourdon提出的软件结构图非常适合表示软 件的结构。图中的每个方框代表一个模块， 框内注明模块的名称、主要功能，方框之间 的箭头线表示模块间的调用关系。 结构图中还可以标注模块之间传递的数据和 控制信息。 查询 读者查询 查询 结果 书 图 号 编 读者 编号 查询 结果 图书查询 结构图说明 模块的名字应当能够反映该模块的功能，如:查询。 模块的调用关系和接口：两个模块之间用单向箭头 连接。箭头从调用模块指向被调用模块，当被调用 模块执行结束后，控制又返回到调用模块。 模块间的信息传递：当一个模块调用另一个模块时， 调用模块把数据或控制信息传送给被调用模块，以 使被调用模块能够运行。被调用模块执行过程中又 把它产生的数据或控制信息回送给调用模块。为了 区别在模块之间传递的是数据还是控制信息,用 表示数据信息,用 表示控制信息。通常在短箭头 附近注有信息的名字。 结构图说明（续） 两个辅助符号：用符号◆表示一个模块有条 件地调用另一个模块；用符号表示模块循环 调用它的各下属模块。图中模块A下加一个 菱形表示控制模块A按条件选择调用模块B、 模块C、模块D。 A A B C D B C D 结构图说明（续） 结构图的形态特征：上层模块调用下层模块，模块 自上而下“主宰”，自下而上“从属”。同一层的 模块之间并没有这种主从关系。 结构图的深度：在多层次的结构图中，模块结构的 层数称为该结构图的深度。下面结构图的深度为7。 结构图的深度在一定意义上反映了程序结构的规模 和复杂程度。对于中等规模的程序，结构图的深度 约为10左右。对于一个大型程序，深度可以有几 十层。 结构图的宽度：结构图中模块数最多的那层的模块 个数称为结构图的宽度，下图的宽度为6。 A C B D E J G F 扇出4 H I K M N L 深 度 7 R S T 宽度6 P 扇入3 结构图说明（续） 模块的扇入和扇出：扇出表示一个模块直接 调用的其他模块数目。扇入则定义为调用一 个给定模块的模块个数。多扇出意味着需要 控制和协调许多下属模块。而多扇入的模块 通常是公用模块。 4.2软件设计原则和影响设计的因素 设计可回溯到需求。软件设计中的每个元素都可 以对应到需求，保证设计使用户需要的。 充分利用已有的模块。一个复杂的软件通常是由 一系列模块组成，很多模块可能在以前的系统中 已经开发过了，如果这些模块设计得好，具有良 好的可复用性，那么在设计新软件时应该尽可能 使用已有的模块。 软件模块之间应该遵循高内聚、低耦合和信息隐 藏的设计原则。 设计应该表现出一致性和规范性。在设计开始之 前，设计小组应该定义设计风格和设计规范，保 证不同的设计人员设计出风格一致的软件。 软件设计原则和影响设计的因素（续） 容错性设计。不管多么完善的软件都可能有潜在的 问题，所以设计人员应该为软件进行容错性设计， 当软件遇到异常数据、事件或操作时，软件不至于 彻底崩溃。 设计的粒度要适当。设计不是编码，即使在详细设 计阶段，设计模型的抽象级别也比源代码要高，它 涉及的是模块内部的实现算法和数据结构。因此， 不要用具体的程序代码取代设计。 在设计时就要开始评估软件的质量。软件的质量属 性需要在设计时考虑如何实现，不要等全部设计结 束之后再考虑软件的质量。 软件设计原则和影响设计的因素（续） 由多人共同设计一个软件时的协调问题； 设计人员的设计经验、理解力和喜好的差别; 一致的设计规范约束; 设计者的文化背景、信仰、价值观等其他方 面的问题，这些都是影响软件设计的因素。 4.3 结构化设计方法 结构化设计方法通常也叫做面向数据流的设计或面 向过程的设计。 结构化设计是基于模块化的、自顶向下、逐步求精 等技术基础上的设计方法。 结构化设计与结构化分析和结构化编程方法前后呼 应，形成了统一、完整的系列化方法。 结构化设计方法以需求分析阶段获得的数据流程图 为基础，通过一系列映射，把数据流程图变换为软 件结构图。 结构化设计方法4步骤 1）分析数据流的类型。数据流的类型有变换型和事 务型两种，不同类型的数据流程图映射的软件结 构有所不同。 2）将数据流程图映射为程序结构图。 3）优化设计结构。 4）评审软件结构。 变换型数据流 在变换型的 数据流程图 上划分逻辑 输入、中心 变换、逻辑 输出的边界； 初始数据 中心变换 已格式化1 IPO 4 格式1 有效 IPO 2 数据 检测 IPO 1 编辑 已编辑 数据 计算值1 IPO 3 计算 计算值2 IPO 5 格式2 逻辑输入 IPO 6 已格 式化2 逻辑输出 格式3 已格式化3 变换型数据流程软件结构图 1）重画数据流程图,重画数据流程图应注意以下 几个要点： 从物理输入到物理输出。 当数据流进入和离开一个处理时，要仔细地标记 它们，不要重名。 数据流程图中的数据存储先略去，造成的数据开 链视为数据的物理输入或输出。 2）在数据流程图上区分系统的逻辑输入、逻辑输出和 中心变换部分。 从数据流程图的物理输入端开始，向系统的中间移动， 一直到某个数据流不再被看作是系统的输入为止，这个 数据流的前一个数据流就是系统的逻辑输入。从物理输 入端到逻辑输入，构成软件的输入部分。 同理从物理输出端开始，向系统的中间移动，就可以找 到软件的逻辑输出。 在输入部分和输出部分之间的就是中心变换部分。 3）设计软件结构的顶层和第1层。 设计一个主模块，并用系统的名字为它命名， 做为系统的顶层。 第1层：为每个逻辑输入设计一个输入模块，它 的功能是为主模块提供数据；为每一个逻辑输 出设计一个输出模块，它的功能是将主模块提 供的数据输出；为中心变换设计一个变换模块， 它的功能是将逻辑输入转换成逻辑输出。 主模块控制和协调第1层的输入模块、变换模块 和输出模块的工作。 4）设计软件结构的下层结构。 每个逻辑输入模块有两个下属模块：一个接收数据；另 一个把数据变换成上级模块所需要的数据格式。而接收 数据模块又是输入模块，又要重复上述工作。如此循环 下去，直到输入模块已经涉及到物理输入端为止。 同样，每个逻辑输出模块有两个下属模块：一个是将上 级模块提供的数据变换成输出的形式；另一个是将它们 输出。对于每一个逻辑输出，在数据流程图上向物理输 出端方向移动，遇到物理输出为止。 设计中心变换模块的下层模块没有通用的方法，一般应 参照数据流程图的中心变换部分和功能分解的原则来考 虑如何对中心变换模块进行分解。 转换后的初始软件结构图 系统名 第一层 有效性检查 第二层 已编辑 数据录入 编辑 检测 计算 计算1输出 格式1 输出1 计算2输出 格式2 计算3输出 格式3 输出3 事务型数据流 在事务型流程图 上划分接收分支 和发送分支的边 界，见右图。 注意：两种类型 的数据流有时会 同时出现在一个 流程图中，例如 右图中的路径L是 变换型数据流。 DS02 IPO 3 读参数 中心事务 IPO 1 读命令 命令 类型 IPO 2 系统配置文件 原配置 数据 IPO 8 更新文件 参数 计算 判断命令 IPO 4 计算 结果 IPO 9 显示结果 统计 密码 IPO 7 IPO 6 IPO 5 读密码 4位 密码 比较密码 验证结果 校验结果 路径L DS01 密码文件 事务型数据流程软件结构图 1）重画数据流程图,重画数据流程图应注意以下 几个要点： 从物理输入到物理输出。 当数据流进入和离开一个处理时，要仔细地标记 它们，不要重名。 数据流程图中的数据存储先略去，造成的数据开 链视为数据的物理输入或输出。 2）标识事务中心、事务接收路径和事务处理路径。 通常事务中心位于几条处理路径的起点，从数据流程图 上很容易标识出来，因为事务处理中心一般会有“发射 中心”的特征。例如，上图中的“判断命令”处理就是 一个事务中心，它有三条发射路径。 事务中心前面的部分叫做接收路径，发射中心后面各条 发散路径叫做事务处理路径。对于每条处理路径来讲， 还应该确定它们自己的流特征。 3）设计软件结构的顶层和第1层。 软件结构图的顶层是系统的事务控制模块。 第1层是由事务流输入分支和事务分类处理分支 映射得到的程序结构。也就是说，第1层通常是 由两部分组成：取得事务和处理事务。 4）设计软件结构的下层结构。 设计事务流输入分支的方法与变换分析中输入流的设计 方法类似，从事务中心变换开始，沿输入路径向物理输 入端移动。每个接收数据模块的功能是向调用它的上级 模块提供数据，它需要有两个下属模块：一个接收数据； 另一个把这些数据变换成它的上级模块所需要的数据格 式。接收数据模块又是输入模块，也要重复上述工作。 如此循环下去，直到输入模块已经涉及到物理输入端为 止。 事务处理分支结构映射成一个分类控制模块，它控制下 层的处理模块。对每个事务建立一个事务处理模块。如 果发现在系统中有类似的事务，就可以把这些类似的事 务组织成一个公共事务处理模块。但是，如果组合后的 模块是低内聚的，则应该重新考虑组合问题 。 转换后的初始软件结构图 事务控制 读命令 Get命令 判断命令 命令 转换 密码 计算统计 读密码 比较密码 读系统数 据 校验结果 更新配 置文件 读数据 统计 Get 密码 密码 转换 转换 结果 输出 结果 转换 格式 显示结果 Geu数据 输出 结果 转换 数据 4.4 优化软件结构设计 数据流程图转换为软件结构图，应该对软件 结构图进行优化。使其符合高内聚低耦合的、 模块化、信息隐藏的原则。 4.4 优化软件结构设计（续） 规则一：模块功能完善化。一个完整的功能模块， 不仅能够完成指定的功能，而且还应当能够向调用 者返回完成任务的状态，以及失败的原因。因此要 求功能模块除了应该执行规定的功能外，还应该具 有出错处理的内容，当模块不能完成规定的功能时， 必须回送出错标志，向它的调用者报告失败的原因。 如果模块正确结束，应该返回正确结束的标志。上 述所有内容，都应当看做是一个模块的有机组成部 分，不应分离到其他模块中去，否则将会增大模块 间的耦合程度。 4.4 优化软件结构设计（续） 规则二：设计功能单一和结果可预测的模块。一个 功能单一和结果可预测的模块可以被看成是一个 “黑箱”，不论内部处理细节如何，对于相同的输 入数据，总能产生同样的结果。但是，如果模块内 部蕴藏有一些特殊的鲜为人知的功能时，其模块的 结果可能无法预测。例如，如果在模块内部有一个 局部控制变量Ｍ，在运行过程中模块的处理由这个 控制变量确定，由于这个局部控制变量对于调用模 块来说是隐蔽的，所以调用模块无法控制这个模块 的执行，也不能预知将会引起什么后果，有可能造 成混乱。 4.4 优化软件结构设计（续） 规则三：消除重复功能，改善软件结构。应当认真审 查初始的软件结构图，如果发现几个模块的功能有相 似之处，应该加以改进。例如，当两个模块的功能完 全相似，而只是所处理的数据类型不一致时，应该合 并模块，同时修改模块的数据类型和变量定义。但是， 如果两个模块的功能只是局部相似时，最好不要简单 地合二为一，因为这种简单的并后会造成模块内部设 置许多判断开关，模块的接口参数势必会传递一些控 制信息，造成模块内聚降低。通常的处理办法是分析 两个相似的模块，找出相同的部分，然后将相同的部 分从分离出去组成一个新的模块。 4.4 优化软件结构设计（续） 规则四：模块的作用范围应在控制范围之内。首先定义 一个模块的控制范围是：是这个模块及其所有下属模块。 例如图中模块E的控制范围是I、H、J。 一个模块的作用范围是：这个模块内判定的作用范围， 凡是受这个判定影响的模块都属于这个判定的作用范围。 例如图中模块J的一个判定传递给E模块，然后再传递给 I和H模块，这时模块J的作用范围是模块E、I、J。显然， 这种设计是不好的，因为模块I和H不是模块J的控制范 围，这样就导致模块之间传递的是控制参数，使模块之 间的耦合增加。 A B F G C D E I H IJ 4.4 优化软件结构设计（续） 如果在设计过程中，发现作用范围不在控制范围内， 可采用如下办法把作用范围移到控制范围之内： １）提高控制模块的层次。将判定所在模块合并到父 模块中，使判定处于较高层次。 ２）将受判定影响的模块下移到控制范围内； ３）将判定上移到层次中较高的位置。但是要注意， 判定所在的模块最好不要太高，模块之间的控制参数 传递路径太长，增加了模块之间的耦合。比较好的方 案是将判定提到模块E中。 4.4 优化软件结构设计（续） 规则五：模块的大小要适中。模块的大小一般用模 块的源代码数量来衡量，通常在设计过程中，将模 块的源代码数量限制在５０～１００左右，即一页 纸的范围内，这样阅读比较方便。实际上，规模大 的模块往往是由于分解不充分造成的，应该对其进 一步分解，生成一些下级模块或同层模块。有些模 块规模非常小，这种情况下要区别对待，如果该模 块是公共模块或者是高内聚模块，则一定不要把它 合并到其他模块中去；否则可以考虑将规模很小的 模块合并到其它相关的模块中。 4.4 优化软件结构设计（续） 规则六：尽可能减少高扇出和高扇入的结构。 规则七：将模块中相对变化较大的部分剥离出去。 为了加强模块的可复用性，在设计时将模块中相对 稳定的部分与可能变化的部分分离，在分离的两个 模块之间加一个接口模块对模块之间传递的参数进 行整理，这对保持模块的稳定性和可重用性有很大 作用。 4.4 优化软件结构设计（续） 对于有时间要求的软件结构，在整个设计阶 段和编码阶段都必须进行优化，优化的方法 如下： 首先改进软件的结构。 在详细设计时，挑出那些有可能占用过多时间的 模块，为这些模块精心设计时间效率更高的处理 算法。 检测软件，分离出占用大量处理机资源的模块。 如果有必要，用汇编语言或其它较低级的语言重 新设计、编码，以提高软件的效率。 4.5 图书馆图书信息管理系统设计案例 仔细研究这些数据流程图，发现一个图书管 理信息系统可以分为五个子系统设计，它们 是读者信息管理子系统、借书子系统、还书 子系统、采编子系统和系统维护子系统。将 一个复杂的系统划分为多个简单的子系统， 有利于系统设计和实现。 进入设计阶段后，要从软件设计的角度重审数据流程图。 首先应该为流通组设计一个方便的工作环境，在这个工 作环境之中包含了流通组日常要做的所有工作,应该增加 一个“还书工作环境”的处理,编号IPO320。 “还书工作环境”处理之后应该是流通组门的业务分发 处理，所以增加一个“事物分发”处理，编号为IPO321。 在处理完某个具体的还书业务之后，有可能导致“通知 预约”处理的执行，而“催还”和“通知预约”两个处 理之中都隐含了一个共同的处理“发送邮件”，因此， 应该将具有相同功能的处理独立成为一个“发送邮件” 的处理，编号为IPO324。 在重画数据流程图时发现,处罚操作属于性质相同的 处理，应该将它们归并在一起。每种处罚的规则和处 理不同,增加了一个“处罚事物分发”处理,判断不同 的处罚类型,每种处罚处理的用户界面不同，为三种 处罚类型设计不同的用户界面。最终的处罚结果是保 存在一个数据库表中，因此调用同一个“保存处罚记 录”处理。在整个处罚的处理部分，基本上是按照逻 辑输入、处理、逻辑输出划分的。 另外增加了两个界面处理，这是为了将用户界面与业 务处理分开来设计和实现，便于系统的维护和修改。 下面是修改后的数据流程图： 还书数据流程图 处罚 还书部 还书 IPO 300 IPO 320 催还 DS104 借还书记录 IPO 327 IPO 302 丢失处罚 界面 丢失处罚 还书工作 环境 DS302 DS101 读者库 读者 处罚规则 IPO 324 IPO 301 IPO 326 还书处理 还书界面 IPO 321 发送邮件 事物分发 IPO 325 IPO 328 IPO 303 IPO 322 处罚事物 分发 破损处罚 界面 破损处罚 保存处罚 信息 IPO 329 IPO 304 超期处罚 界面 超期处罚 IPO 306 通知预约 DS100 书库 DS300 DS103 预约记录 DS301 期限处罚表 处罚记录 还书子系统 还书子系统 还书工作环境 还书事务分发 还书工作环境 还书事务分发 还书 还书子系统 还书工作环境 还书事务分发 还书 获得还书信息 还书界面 还书信息 验证 处罚 还书处理 处罚 还书子系统 还书工作环境 还书子系统结构图 还书事务分发 还书 获得还书信息 还书界面 还书处理 还书信息 验证 处罚事 务分发 处罚界面 丢失处罚 获得丢失 信息 丢失信息 界面 处罚 丢失信息 验证 处罚信息 保存 破损处罚 获得破 损信息 丢失处罚 破损信息 界面 延期处罚 破损处罚 破损信息 验证 获得延 期信息 延期信息 界面 延期处罚 延期信息 验证 后台程序 预约通知 还书触发器 获取信息 获取预约 记录 催还图书 发送邮件 时间触发器 获取读者 信息 获取信息 获取借书 信息 走查软件结构图 软件结构图中的模块关系体现的是调用关系， 模块之间的接口参数在软件结构图上表现出 来。 设计者根据调用关系在纸上对系统进行初步 的试运行，方法是从软件结构图的最顶层按 深度优先原则调用下级模块，直到图的最底 层。在纸上试运行过程中，填写一张功能模 块对照表。 数据结构与程序模块对照表 软件功能需求与程序模块对照表 功能 模块1 功能需求1 Module name 功能需求2 Module name …… 功能需求n Module name 模块2 …… 模块n Module name Module name 第1列是分析阶段确定的 软件功能编号,通常一个功 能可能需要多个模块实现, 如果模块超过5个，往往 说明该功能太大,应该将其 细分。每个功能都应该有 一条自上而下的模块调用 通路，如果发现某条通路 走下来不能实现需要的功 能，就要重新检查数据流 程图到软件结构图的转换 是否正确。在走查模块时 不要进入模块内部的具体 处理算法，只是检查接口 参数和分配的功能即可 用快速原型法修正设计 在设计时，有些问题很难确定是否能够实现，可以先开 发一个原型，通过开发原型来发现设计中存在的问题， 以便在编码之前解决很多棘手的问题。另外，原型可以 促进开发人员之间、以及开发人员与用户之间的沟通。 开发原型时，通常忽略功能上的很多细节，只是将注意 力放在系统的某个或某几个特定方面。例如，界面方面、 性能方面、还有安全方面等等，这种原型肯定会存在许 多漏洞，但是，如果一个原型仅仅是要证明设计的可行 性时，就不必太多的关注这些漏洞。这种原型属于抛弃 型原型，意思是，开发的原型仅仅是为了证明系统某些 特征的可行性,它不是最终的产品。 关于设计的说明 在程序结构被设计和优化后，应该对设计进行一些必要的 说明。每个模块写一份处理说明;为模块之间的接口提供 一份接口说明;确定全局数据结构;指出所有的设计约束和 限制。 处理说明应该清楚地描述模块的主要处理任务、条件抉择 和输人／输出。注意概要设计阶段不要对模块的内部处理 过程进行详细描述，这项工作是详细设计的任务。 接口说明要给出一张表格，列出所有进入模块和从模块输 出的数据。接口说明中应包括通过参数表传递的信息、对 外界的输入／输出信息、访问全局数据区的信息等等。此 外还要指出其下属的模块和上级模块。 模块说明表 模块名称： 编号： 主要功能： 输入参数及类型： 上级调用模块： 向下调用模块： 局部数据结构： 约束条件和设计限制： 输出参数及类型： 4.6设计复查 采用概要设计复查的方法来检查在概念上的 设计； 在关键设计审查中，向其它开发者描述关键 技术上的设计细节； 进行程序设计的复查，程序设计的复查属于 详细设计阶段。复查的目标是确保软件设计 与实现正是用户想要的。 4.7数据设计 尽量使用简单的数据结构。简单的数据结构通常伴随着 简单的操作，有些人喜欢使用复杂的工具完成一些简单 的事情，这在软件开发中是比较忌讳的。 在设计数据结构时要注意数据之间的关系，特别要平衡 数据冗余与数据关联的矛盾。有时，为了减少信息的冗 余，需要增加更多的关联，使程序处理比较复杂；如果 一味的降低数据之间的关联，可能会造成大量的数据冗 余，难以保证数据的一致性。 为了加强数据设计的可复用性，应该针对常用的数据结 构和复杂的数据结构设计抽象类型，并且将数据结构与 操纵数据结构的操作封装在一起。同时要清楚地描述调 用这个抽象数据结构的接口说明。 4.7数据设计(续) 4) 尽量使用经典的数据结构，因为，对它 们的讨论比较普遍，容易被大多数开发人员 理解，同时，也能够获得更多的支持。 5）在确定数据结构时一般先考虑静态结构， 如果不能满足要求，再考虑动态结构。 4.7数据设计(续) 文件设计是指对数据存储文件的设计，主要工作是 根据使用要求、处理方式、存储的信息量、数据的 使用频率和文件的物理介质等因素，来确定文件的 类别、文件的组织方式。设计文件记录的格式，估 计文件的容量。 文件的设计过程包括文件的逻辑设计和文件的物理 设计两个阶段，文件的逻辑设计在概要设计阶段进 行，文件的物理设计在详细设计阶段进行。 4.7数据设计(续) 整理必须的数据元素：分析文件中要存储的数据 元素，确定每个数据元素的类型、长度，并且给 每个数据元素定义一个容易理解的、有意义的名 字。 分析数据间的关系：根据业务处理逻辑确定数据 元素之间的关系，有时一个文件记录中可能包含 多个子数据结构。例如，考生成绩文件的记录中 可能包含：考生编号、姓名、学校、（语文、数 学、英语、物理、化学）、总成绩。其中，括号 部分是一个子结构，描述各科的成绩，这些数据 元素可能需要同时处理。 4.7数据设计(续) 3) 确定文件的存储介质。目前，文件的存储介质主要有磁带、 软盘、磁盘、光盘、可移动快速闪存。选择文件存储介质是 主要考虑下面一些原则： a) 数据量 b) 处理方式 c) 存储时间 d) 处理时间 e) 数据结构 f) 操作要求 g) 费用要求 4.7数据设计(续) 确定文件的记录格式。文件的记录格式通常 分为无格式的字符流和用户定义的记录格式 两种。并且还可以设计为定长记录和不定长 记录。 估算记录的存取时间。根据文件的存储介质 和类型，计算平均访问时间和最坏情况下的 访问时间。 估算文件的存储量。根据一条记录的大小估 算整个文件的存储量，然后，考虑文件的增 长速度，确定文件的存储介质的规格型号， 以及设计文件备份转储的周期 4.7数据设计(续) 数据库模式设计：模式设计是在物理层和逻辑层面上描 述的数据库设计。 第三范式形式的实体及关系数据模型是模式设计过程的 输入，模式设计的主要问题是处理具体的数据库管理系 统的结构约束。 子模式设计：子模式是用户使用的数据视图。 完整性和安全性设计 优化 4.8详细设计 详细设计也叫过程设计，应该在软件结构设计、数 据设计之后进行，主要是设计模块内的算法实现细 节。 任务不是编写程序，而是要为编写程序代码设计 “图纸”，由程序员按“图纸”用某种高级程序设 计语言编写程序代码。因此，详细设计的结果基本 上决定了最终的程序代码质量。 衡量程序代码的质量不仅要看它的逻辑是否正确， 性能是否满足要求，更主要的要看它是否容易阅读 和理解。因此，详细设计的目标不仅仅是保证所设 计的模块功能正确，更重要的是保证所设计的处理 过程简明易懂。 4.8详细设计（续） 结构化程序的特征： 程序模块只有一个入口和一个出口。 程序中只包含顺序、条件和循环三种控制结构。 程序流程图 ：程 序流程图也称为 输入及验证模块 输出参数：读者 程序框图，是使 号，图书号 用最广泛的详细 设计方法。流程 提示重新输入 图画起来很简单， 方框表示处理步 骤，菱形表示逻 辑判断，箭头表 示控制流。 开始 输入读者号/图书号 无 输入数据有效？ 有 用读者号和图书号查借 还书记录表 结束 判定表 有时一个模块内部的实现算法中常常包含着 多重嵌套的条件选择，这类算法如果完全用 文字表达可能令人费解，因此可以采用判定 表。 判定表由四个部分组成，左上部列出了所有 的条件，左下部列出了所有可能的动作，右 半部构成了一个矩阵，表示条件的组合以及 特定条件组合下应执行的操作。 例子 某航空公司的行李收费标准：乘客免费行李 不超过30公斤。超出部分国内客头等舱4/ 每公斤，国内客其他舱6/每公斤，国外客是 国内客的2倍，残疾客是正常客的一半。 1 国内旅客 头等舱 残疾客 行李重 ≤30 T 免费 √ 2 3 T T T F F F F F (W-30)*2 (W-30)*6 (W-30)*8 (W-30)*12 5 T F T F 6 F T F F 7 F F F F 8 F T T F 9 F F T F √ (W-30)*3 (W-30)*4 4 T T T F √ √ √ √ √ √ √ 过程设计语言(PDL) 也称为结构化的英语或伪码，它是一种混合 语言，通常采用英语（或中文）的词汇，采 用某种结构化程序设计语言的语法。 过程设计语言的特征： PDL过程设计语言使用自然语言的词汇描述处理过程，使设计 更加易于理解。 PDL具有顺序、选择、循环控制结构和数据说明。 每种不同的PDL都有不同的关键字，这些关键字被用于不同的 控制结构之中，增强了设计的清晰性，例如，if …endif 关键 字。 数据声明机制既可以说明简单数据结构（例如标量和数组）， 也可以声明复杂数据结构（例如链表和树）。 具有子程序定义和调用描述功能，提供各种接口定义模式。 使用PDL作为详细设计工具的优点是：可以将设计时产生的 PDL语句直接作为程序注释插入到源程序代码之中；修改源程 序时直接就修改了PDL，由此保证设计与结果的一致性。 模块开发文件夹 随着详细设计过程的进行，每个软件模块相关的文档 资料的数量也不断增长。模块开发文件夹是组织和保 存在软件开发过程中不断产生出来的文档资料的一种 有效方法，用这种方法保存和管理文档既方便又容易 查阅。 每个开发文件夹中包含一个或多个模块的全部文档， 文件夹的封皮上列出工程项目的名称、模块名字、程 序员名字，完成的日期、修改的日期，源程序行数， 目标代码长度、对模块的简要描述。以及设计、编码、 单元测试和集成测试等阶段的起止时间 本章要点 软件设计的主要原则：模块独立性和信息隐藏。反映模块独立性 的有两个标准：内聚和耦合。内聚衡量一个模块内部各个元素彼 此结合的紧密程度，耦合衡量模块之间彼此依赖的程度。信息隐 藏的核心内容是：一个模块中所包含的信息，不允许其他不需要 这些信息的模块访问。 结构化设计是基于模块化的、自顶向下、逐步求精等概念上的设 计方法。 结构化方法的流程：首先分析数据流的类型，将数据流程图映射 为软件结构图，然后根据优化规则对于软件结构图进行设计优化。 数据设计包括：数据结构设计、文件设计和数据库设计。 详细设计是对模块内部的处理过程进行设计，常用的方法有程序 流程图、判定树、PDL。