软件工程导论第4版第1章概述

第5章 总体设计5.1 设计过程 5.2 设计原理 5.3 启发规则 5.4 描绘软件结构的图形工具 5.5 面向数据流的设计方法 5.6 小结 习题

软件工程导论第4版第1章概述

总体设计的基本目的就是回答“概括地说， 系统应该如何实现?”这个问题，因此，总体 设计又称为概要设计或初步设计。通过这个阶 段的工作将划分出组成系统的物理元素——程 序、文件、数据库、人工过程和文档等等，但 是每个物理元素仍然处于黑盒子级，这些黑盒 子里的具体内容将在以后仔细设计。总体设计 阶段的另一项重要任务是设计软件的结构，也 就是要确定系统中每个程序是由哪些模块组成 的，以及这些模块相互间的关系。

软件工程导论第4版第1章概述

总体设计过程首先寻找实现目标系统的各种不同 的方案，需求分析阶段得到的数据流图是设想各种可 能方案的基础。然后分析员从这些供选择的方案中选 取若干个合理的方案，为每个合理的方案都准备一份 系统流程图，列出组成系统的所有物理元素，进行成 本/效益分析，并且制定实现这个方案的进度计划。 分析员应该综合分析比较这些合理的方案，从中 选出一个最佳方案向用户和使用部门负责人推荐。如 果用户和使用部门的负责人接受了推荐的方案，分析 员应该进一步为这个最佳方案设计软件结构，通常， 设计出初步的软件结构后还要多方改进，从而得到更 合理的结构，进行必要的数据库设计，确定测试要求 并且制定测试计划。

软件工程导论第4版第1章概述

从上面的叙述中不难看出，在详细设 计之前先进行总体设计的必要性：可以站 在全局高度上，花较少成本，从较抽象的 层次上分析对比多种可能的系统实现方案 和软件结构，从中选出最佳方案和最合理 的软件结构，从而用较低成本开发出较高 质量的软件系统。

软件工程导论第4版第1章概述

5.1 设计过程总体设计过程通常由两个主要阶段组成： 系统设计阶段，确定系统的具体实现方案；结 构设计阶段，确定软件结构。典型的总体设计 过程包括下述9个步骤： 1. 设想供选择的方案 在总体设计阶段分析员应该考虑各种可能 的实现方案，并且力求从中选出最佳方案。在 总体设计阶段开始时只有系统的逻辑模型，分 析员有充分的自由分析比较不同的物理实现方 案，一旦选出了最佳的方案，将能大大提高系 统的性能/价格比。

软件工程导论第4版第1章概述

需求分析阶段得出的数据流图是总体设计 的极好的出发点。 设想供选择的方案的一种常用的方法是， 设想把数据流图中的处理分组的各种可能的方 法，抛弃在技术上行不通的分组方法(例如，组 内不同处理的执行时间不相容),余下的分组方 法代表可能的实现策略，并且可以启示供选择 的物理系统。

软件工程导论第4版第1章概述

2. 选取合理的方案应该从前一步得到的

一系列供选择的方案中选取若 干个合理的方案，通常至少选取低成本、中等成本和高 成本的三种方案。在判断哪些方案合理时应该考虑在问 题定义和可行性研究阶段确定的工程规模和目标，有时 可能还需要进一步征求用户的意见。 对每个合理的方案分析员都应该准备下列4份资料： (1) 系统流程图； (2) 组成系统的物理元素清单； (3) 成本/效益分析； (4) 实现这个系统的进度计划。

软件工程导论第4版第1章概述

3. 推荐最佳方案 分析员应该综合分析对比各种合理方案的利 弊，推荐一个最佳的方案，并且为推荐的方案制 定详细的实现计划。制定详细实现计划的关键技 术是本书第13章中将要介绍的工程网络。 用户和有关的技术专家应该认真审查分析员 所推荐的最佳系统，如果该系统确实符合用户的 需要，并且是在现有条件下完全能够实现的，则 应该提请使用部门负责人进一步审批。在使用部 门的负责人也接受了分析员所推荐的方案之后， 将进入总体设计过程的下一个重要阶段——结构 设计。

软件工程导论第4版第1章概述

4. 功能分解 为了最终实现目标系统，必须设计出组成 这个系统的所有程序和文件(或数据库)。对程 序(特别是复杂的大型程序)的设计，通常分为 两个阶段完成：首先进行结构设计，然后进行 过程设计。结构设计确定程序由哪些模块组成， 以及这些模块之间的关系；过程设计确定每个 模块的处理过程。结构设计是总体设计阶段的 任务，过程设计是详细设计阶段的任务。

软件工程导论第4版第1章概述

5. 设计软件结构 通常程序中的一个模块完成一个适当的子功 能。应该把模块组织成良好的层次系统，顶层模 块调用它的下层模块以实现程序的完整功能，每 个下层模块再调用更下层的模块，从而完成程序 的一个子功能，最下层的模块完成最具体的功能。 软件结构(即由模块组成的层次系统)可以用层次 图或结构图来描绘，第5.4节将介绍这些图形工具。 如果数据流图已经细化到适当的层次，则可 以直接从数据流图映射出软件结构，这就是第5.5 节中将要讲述的面向数据流的设计方法。

软件工程导论第4版第1章概述

6. 设计数据库 对于需要使用数据库的那些应用系统，软 件工程师应该在需求分析阶段所确定的系统数 据需求的基础上，进一步设计数据库。 在数据库课中已经详细讲述了设计数据库 的方法，本书不再赘述。 7. 制定测试计划 在软件开发的早期阶段考虑测试问题，能 促使软件设计人员在设计时注意提高软件的可 测试性。本书第7章将仔细讨论软件测试的目 的和设计测试方案的各种技术方法。

软件工程导论第4版第1章概述

8. 书写文档 应该用正式的文档记录总体设计的结果，在 这个阶段应该完成的文档通常有下述几种： (1) 系统说明书：主要内容包括

用系统流程图描 绘的系统构成方案，组成系统的物理元素清单， 成本/效益分析，对最佳方案的概括描述，精化 的数据流图，用层次图或结构图描绘的软件结构， 用IPO图或其他工具简要描述的各个模块的算法， 模块间的接口关系等。 (2) 用户手册：根据总体设计阶段的结果，修改 更正在需求分析阶段产生的初步的用户手册。

软件工程导论第4版第1章概述

(3) 测试计划：包括测试策略，测试方案， 预期的测试结果，测试进度计划等等。 (4) 详细的实现计划 (5) 数据库设计结果 9. 审查和复审 最后应该对总体设计的结果进行严格的技 术审查，在技术审查通过之后再由使用部门的 负责人从管理角度进行复审。

软件工程导论第4版第1章概述

5.2 设计原理5.2.1 模块化模块是由边界元素限定的相邻程序元素(例如， 数据说明，可执行的语句)的序列，而且有一个总体标 识符代表它。按照模块的定义，过程、函数、子程序和 宏等，都可作为模块。面向对象方法学中的对象是模块， 对象内的方法(或称为服务)也是模块。模块是构成程 序的基本构件。 模块化就是把程序划分成独立命名且可独立访问的 模块，每个模块完成一个子功能，把这些模块集成起来 构成一个整体，可以完成指定的功能满足用户的需求。

软件工程导论第4版第1章概述

有人说，模块化是为了使一个复杂的大型 程序能被人的智力所管理，软件应该具备的惟 一属性。如果一个大型程序仅由一个模块组成， 它将很难被人所理解。也就是说，如果一个问 题由P1和P2两个问题组合而成，那么它的复杂 程度大于分别考虑每个问题时的复杂程度之和。 由此得到下面的不等式 E(P1+P2)>E(P1)+E(P2) 这个不等式导致“各个击破”的结论—— 把复杂的问题分解成许多容易解决的小问题， 原来的问题也就容易解决了。这就是模块化的 根据。

软件工程导论第4版第1章概述

由上面的不等式似乎还能得出下述结论： 如果无限地分割软件，最后为了开发软件而需 要的工作量也就小得可以忽略了。事实上，还 有另一个因素在起作用，从而使得上述结论不 能成立。参看图5.1,当模块数目增加时每个 模块的规模将减小，开发单个模块需要的成本 (工作量)确实减少了；但是，随着模块数目增 加，设计模块间接口所需要的工作量也将增加。 根据这两个因素，得出了图中的总成本曲线。 每个程序都相应地有一个最适当的模块数目M, 使得系统的开发成本最小。

软件工程导论第4版第1章概述

图5.1 模块化和软件成本

软件工程导论第4版第1章概述

虽然目前还不能精确地决定M的数值，但是 在考虑模块化的时候总成本曲线确实是有用的指 南。 采用模块化原理可以使软件结构清晰，不仅 容易设计也容易阅读和理解。因为程序错误通常 局限在有关的模块及它们之间的接口中，所以模 块

化使软件容易测试和调试，因而有助于提高软 件的可靠性。因为变动往往只涉及少数几个模块， 所以模块化能够提高软件的可修改性。模块化也 有助于软件开发工程的组织管理，一个复杂的大 型程序可以由许多程序员分工编写不同的模块， 并且可以进一步分配技术熟练的程序员编写困难 的模块。

软件工程导论第4版第1章概述

5.2.2 抽象人类在认识复杂现象的过程中使用的最强 有力的思维工具是抽象。人们在实践中认识到， 在现实世界中一定事物、状态或过程之间总存 在着某些相似的方面(共性)。把这些相似的方 面集中和概括起来，暂时忽略它们之间的差异， 这就是抽象。或者说抽象就是抽出事物的本质 特性而暂时不考虑它们的细节。

软件工程导论第4版第1章概述

由于人类思维能力的限制，如果每次面临 的因素太多，是不可能做出精确思维的。处理 复杂系统的惟一有效的方法是用层次的方式构 造和分析它。一个复杂的动态系统首先可以用 一些高级的抽象概念构造和理解，这些高级概 念又可以用一些较低级的概念构造和理解，如 此进行下去，直至最低层次的具体元素。 这种层次的思维和解题方式必须反映在定 义动态系统的程序结构之中，每级的一个概念 将以某种方式对应于程序的一组成分。

软件工程导论第4版第1章概述

考虑对任何问题的模块化解法时，可以提出许多抽 象的层次。在抽象的最高层次使用问题环境的语言，以 概括的方式叙述问题的解法；在较低抽象层次采用更过 程化的方法，把面向问题的术语和面向实现的术语结合 起来叙述问题的解法；最后在最低的抽象层次用可直接 实现的方式叙述问题的解法。 软件工程过程的每一步都是对软件解法的抽象层次 的一次精化。在可行性研究阶段，软件作为系统的一个 完整部件；在需求分析期间，软件解法是使用在问题环 境内熟悉的方式描述的；当由总体设计向详细设计过渡 时，抽象的程度也就随之减少了；最后，当源程序写出 来以后，也就达到了抽象的最低层。