第五章    总体设计
经过需求分析阶段的工作，系统必须“做什么”已经清楚了，现在是决定“怎样做”的时候了。总体设计的基本目的就是回答“概括地说，系统应该如何实现?”这个问题，因此，总体设计又称为概要设计或初步设计。通过这个阶段的工作将划分出组成系统的物理元素——程序、文件、数据库、人工过程和文档等等，但是每个物理元隶仍然处于黑盒子级，这些黑盒子里的具体内容将在以后仔细设计。总体设计阶段的另一项重要任务是设计软件的结构，也就是要确定系统中每个程序是由哪些模块组成的，以及这些模块相互间的关系。
    总体设计过程首先寻实现目标系统的各种不同的方案，需求分析阶段得到的数据流图是设想各种可能方案的基础。然后分析员从这些供选择的方案中选取若干个合理的方案，为每个合理的方案都准备一份系统流程图，列出组成系统的所有物理元素，进行成本／效益分析，并且制定实现这个方案的进度计划。分析员应该综合分析比较这些合理的方案，从中选出一个最佳方案向用户和使用部门负责人推荐。如果用户和使用部门的负责人接受了推荐的方案，分析员应该进一步为这个最佳方案设计软件结构，通常，设计出初步的软件结构后还要多方改进，从而得到更合理的结构，进行必要的数据库设汁，确定测试要求并且制定测试计划。
    从上面的叙述中不难看出，在详细设计之前先进行总体设计的必要性：可以站在全局高度上，花较少成本，从较抽象的层次上分析对比多种可能的系统实现方案和软件结构，从中选出最佳方案和最合理的软件结构，从而用较低成本开发出较高质量的软件系统。
5.1  设计过程
总体设计过程通常由两个主要阶段组成：系统设计阶段，确定系统的具体实现方案；结构没计阶段，确定软件结构。典型的总体设计过程包括下述9个步骤：
1.设想代选择的方案
如何实现要求的系统呢，在总体设计阶段分析员应该考虑各种可能的实现方案，并且力求从中选出最佳方案。在总体设计阶段开始时只有系统的逻辑模型，分析员有充分的自由分析比较不同的物理实现方案，一旦选出了最佳的方案，将能大大提高系统的性能／价格比。
需求分析阶段得出的数据流图是总体设计的极好的出发点。
设想供选择的方案的一种常用的方法是，设想把数据流图中的处理分组的各种可能的方法，
抛弃在技术上行不通的分组方法(例如，组内不同处理的执行时间不相容)，余下的分组方法代表可能的实现策略，并且可以启示供选择的物理系统。
2.选取合理的方案
应该从前一步得到的一系列供选择的方案中选取若干个合理的方案，通常至少选取低成本、中等成本和高成本的三种方案。在判断哪些方案合理时应该考虑在问题定义和可行性研究阶段确定的工程规模和目标，有时可能还需要进一步征求用户的意见。
对每个合理的方案分析员都应该准备下列4份资料：
(1) 系统流程图；
(2) 组成系统的物理元素清单
(3) 成本／效益分析；
(4) 实现这个系统的进度计划
3. 推荐最佳方案 
分析员应该综合分析对比各种合理方案的利弊，推荐一个最佳的方案，并且为推荐的方案制定详细的实现计划。制定详细实现计划的关键技术是本书第13章中将要介绍的工程网络。
用户和有关的技术专家应该认真审查分析员所推荐的最佳系统，如果该系统确实符合用户的需要，并且是在现有条件下完全能够实现的，则应该提请使用部门负责人进一步审批。在使用部门的负责人也接受了分析员所推荐的方案之后，将进入总体设计过程的下一个重要阶段——结构设计。
4．功能分解
为了最终实现目标系统，必须设计出组成这个系统的所有程序和文件(或数据库)。对程序(特别是复杂的大型程序)的设计，通常分为两个阶段完成：首先进行结构设计，然后进行过程设计。结构设计确定程序由哪些模块组成，以及这些模块之间的关系；过程设计确定每个模块的处理过程。结构设计是总体设计阶段的任务，过程设计是详细设计阶段的任务。    为确定软件结构，首先需要从实现角度把复杂的功能进一步分解。分析员结合算法描述仔细分析数据流图中的每个处理，如果一个处理的功能过分复杂，必须把它的功能适当地分解成一系列比较简单的功能。一般说来，经过分解之后应该使每个功能对大多数程序员而言都是明显易
懂的。功能分解导致数据流图的进一步细化，同时还应该用IPO图或其他适当的工具简要描述细化后每个处理的算法。
5．设计软件结构
通常程序中的一个模块完成一个适当的子功能。应该把模块组织成良好的层次系统，顶层模块调用它的下层模块以实现程序的完整功能，每个下层模块再调用更下层的模块，从而完成程序的一个子功能，最下层的模块完成最具体的功能。软件结构(即由模块组成的层次系统)可以用层次图或结构图来描绘，第5．4节将介绍这些图形工具。
如果数据流图已经细化到适当的层次，则可以直接从数据流图映射出软件结构，这就是第5．5节中将要讲述的面向数据流的设计方法。
6．设计数据库
对于需要使用数据库的那些应用系统，软件工程师应该在需求分析阶段所确定的系统数据需求的基础上，进一步设计数据库。
在数据库课中已经详细讲述了设计数据库的方法，本书不再赘述。
7．制定测试计划
在软件开发的早期阶段考虑测试问题，能促使软件设计人员在设计时注意提高软件的可测试性。本书第7章将仔细讨论软件测试的目的和设计测试方案的各种技术方法。
8．书写文档
应该用正式的文档记录总体设计的结果，在这个阶段应该完成的文档通常有下述几种:
(1)系统说明 主要内容包括用系统流程图描绘的系统构成方案，组成系统的物理元素清单，成本／效益分析；对最佳方案的概括描述，精化的数据流图，用层次图或结构图描绘的软件结构，用IPO图或其他工具(例如，PDI。语言)简要描述的各个模块的算法，模块间的接口关系，以及需求、功能和模块三者之间的交叉参照关系等等。
(2)用户手册  根据总体设计阶段的结果，修改更正在需求分析阶段产生的初步的用户手册。
(3)测试计划 包括测试策略，测试方案，预期的测试结果，测试进度计划等等。
(4)详细的实现计划
(5)数据库设计结果
9．审查和复审   
最后应该对总体设计的结果进行严格的技术审查，在技术审查通过之后再由使用部门的负责人从管理角度进行复审。
5．2  设计原理
    本节讲述在软件设计过程中应该遵循的基本原理和相关概念。
5．2．1  模块化
模块是由边界元素限定的相邻程序元素(例如，数据说明，可执行的语句)的序列，而且有一个总体标识符代表它。像PASCAL或Ada这样的块结构语言中的Begin…End对，或者C、C++和Java语言中的{...}对，都是边界元素的例子。按照模块的定义，过程、函数、子程序和宏等，都可作为模块。面向对象方法学中的对象(见第9章)是模块，对象内的方法(或称为服务)也是模块。模块是构成程序的基本构件。
    模块化就是把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能满足用户的需求。
有人说，模块化是为了使一个复杂的大型程序能被人的智力所管理，软件应该具备的惟一属性。如果一个大型程序仅由一个模块组成，它将很难被人所理解。下面根据人类解决问题的一般规律，论证上面的结论。
设函数C(x)定义问题X的复杂程度，函数E(x)确定解决问题x需要的工作量(时间)。对于两个问题P1和P2，如果
C()>C()
显然      E()>E()
根据人类解决一般问题的经验，另一个有趣的规律是
    C(+)>C()+C()
也就是说，如果一个问题由P1和P2两个问题组合而成，那么它的复杂程度大于分别考虑每
个问题时的复杂程度之和。
综上所述，得到下面的不等式
    E(+)>E()+E()
模块化设计的目的这个不等式导致“各个击破”的结论——把复杂的问题分解成许多容易解决的小问题来的问题也就容易解决了。这就是模块化的根据。
由上面的不等式似乎还能得出下述结论：如果无限地分割软件，最后为了开发软件而需要的工作量也就小得可以忽略了。事实上，还有另一个因素在起作用，从而使得上述结论不能成立。参看图5．1，当模块数目增加时每个模块的规模将减小，开发单个模块需要的成本(工作量)确实减少了；但是，随着模块数目增加，设计模块间接口所需要的工作量也将增加。根据这两个因素，得出了图中的总成本曲线。每个程序都相应地有一个最适当的模块数目M，使得系统的开发成本最小。
虽然目前还不能精确地决定M的数值，但是在考虑模块化的时候总成本曲线确实是有用的指南。本书第6章将讲述的程序复杂程度的定量度量和第5．3节将介绍的启发式规则，可以在一定程度上帮助我们决定合适的模块数目。
采用模块化原理可以使软件结构清晰，不仅容易设计也容易阅读和理解。因为程序错误通常局限在有关的模块及它们之间的接口中，所以模块化使软件容易测试和调试，因而有助于提高软件的可靠性。因为变动往往只涉及少数几个模块，所以模块化能够提高软件的可修改性。模块化也有助于软件开发工程的组织管理，一个复杂的大型程序可以由许多程序员分工编写不同的模块，并且可以进一步分配技术熟练的程序员编写困难的模块。
5．2．2  抽象
人类在认识复杂现象的过程中使用的最强有力的思维工具是抽象。人们在实践中认识到，在现实世界中一定事物、状态或过程之间总存在着某些相似的方面(共性)。把这些相似的方面集中和概括起来，暂时忽略它们之间的差异，这就是抽象。或者说抽象就是抽出事物的本质特性而暂时不考虑它们的细节。
由于人类思维能力的限制，如果每次面临的因素太多，是不可能做出精确思维的。处理复杂系统的惟一有效的方法是用层次的方式构造和分析它。一个复杂的动态系统首先可以用一些高级的抽象概念构造和理解，这些高级概念又可以用一些较低级的概念构造和理解，如此进行下去，直至最低层次的具体元素。
这种层次的思维和解题方式必须反映在定义动态系统的程序结构之中，每级的一个概念将以某种方式对应于程序的一组成分。
当考虑对任何问题的模块化解法时，可以提出许多抽象的层次。在抽象的最高层次使用问题环境的语言，以概括的方式叙述问题的解法；在较低抽象层次采用更过程化的方法，把面向问题的术语和面向实现的术语结合起来叙述问题的解法；最后，在最低的抽象层次用可以直接实现的方式叙述问题的解法。
软件工程过程的每一步都是对软件解法的抽象层次的一次精化。在可行性研究阶段，软件作为系统的一个完整部件；在需求分析期间，软件解法是使用在问题环境内熟悉的方式描述的；当由总体设计向详细设计过渡时，抽象的程度也就随之减少了；最后，当源程序写出来以后，也就达到了抽象的最低层。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。