总体设计含例子.docx
《总体设计含例子.docx》由会员分享，可在线阅读，更多相关《总体设计含例子.docx（36页珍藏版）》请在冰豆网上搜索。
总体设计含例子
第四章总体设计
需求分析阶段的工作是确定系统必须做什么，而总体设计阶段的工作是决定怎么来实现系统。
总体设计也称黑盒设计，它的任务是划分出组成系统的物理元素——程序、文件、数据库、人工过程和文档等，至于每个物理元素的具体内容将在详细设计阶段完成。
总体设计的目标是设计出软件的结构，确定系统由哪些模块组成及它们之间的关系。
4.1总体设计的一般过程
总体设计过程一般分为两个阶段，系统设计阶段——确定系统的物理实现方案，结构设计阶段——确定软件的结构，总体设计的一般过程如下所述。
1.设想供选择的方案
分析员以需求分析阶段得出的数据流图为出发点，将数据流图中某些处理逻辑地归并在一个自动化边界内作为一组（可能可以），另一些处理放在另一个自动化边界内作为另一组。
这样不同的自动化边界就形成了不同的实现策略，也就提供了多种实现系统的方案。
例如，图2-13和图2-14就是由于不同的划分边界形成了不同的物理系统。
分析员只需比较这些物理实现方案，抛弃在技术上行不通的分组方法，并不评价每个方案。
2.选取合理方案
从前一步可供选择的若干种方案中，选取几种合理的方案（例如，从各种方案的成本角度
出发，依低、中、高三种成本各选一种），按照软件计划书来衡量判断哪些方案最能实现工
程规模和目标，也可以征求用户意见，共同分析确定合理方案。
在此基础上分析员对每种方案准备四份文档：
（1）系统流程图；
（2）组成系统的物理元素清单；
（3）成本/效益分析；
（4）实现这个系统的进度计划。
3.推荐最佳方案
分析员综合分析对比各种合理方案的利弊，从中选出一种自认为是最理想的方案作为推荐的最佳方案，并为此方案制定详细的实现计划。
最佳方案的确定需经用户和有关专家及使用部门负责人进一步审批，在使用部门的负责人接受了分析员推荐的方案后，方可进入总体设计的第二个阶段——结构设计。
4.功能分解
目标系统的实现一般要分两步进行。
首先是进行结构设计，确定系统是由哪些模块组成的，
以及这些模块之间的关系。
其次是过程设计，确定每个模块的处理过程。
结构设计是总体设
计阶段的任务，而过程设计是详细设计阶段的任务。
为了确定软件结构，我们要从实现角度把复杂的功能进一步分解。
然而功能分解将导致数据
流图的进一步细化，一般来说应使每个功能分解到对于大多数程序员而言是明显易懂时为止。
5设计软件结构
模块确定以后，每个模块的功能也就随之确定下来。
把这些模块自顶向下组成一种良好的层次调用关系，就完成了软件结构设计的任务。
如果数据流图已经细化到适当的层次，那么我们便可以从数据流图映射成软件结构图，这是
以后我们将要介绍的面向数据流的设计方法。
6设计数据库
数据库的设计一般包括如下几步：
（1）模式设计。
确定数据库的逻辑结构，处理具体数据库管理系统的结构约束。
常见的数据
库形式有关系的、层次的或网状的等。
（2）子模式设计。
为系统中各用户设计出各自的数据视图。
（3）存储模式设计。
确定数据库的空间需求、存储格式、索引组成等，优化数据的存取性能
，规定各用户对数据库的访问权限和保密机制，确定保证数据正确性和一致性的完整性约束
条件。
7制定测试计划
在总体设计阶段就考虑对系统功能和特性的可测试性问题是十分必要的，这是系统可靠性的
保证，在第七章我们将详细介绍软件的测试目的、测试方法、测试技术等内容。
8书写文档
总体设计阶段的文档包括以下内容：
（1）系统说明。
含系统流程图，组成系统的物理元素清单，成本/效益分析，最佳方案的概
括描述，精化的数据流图，用层次图或结构图描绘的软件结构，各个模块的算法描述，模块
间的接口关系等。
（2）用户手册。
根据总体设计阶段的结果，修正前一阶段产生的用户手册。
（3）测试计划。
含测试策略、测试方案、预期的测试结果、测试进度计划等。
（4）详细的实现计划。
（5）数据库设计结果。
含数据库管理系统的选择、模式、子模式、存储模式的设计结果等。
9复审
对总体设计的结果进行严格的技术审查，然后再由用户负责人从管理角度进行复审。
4.2软件结构和程序过程
1软件结构
软件结构表示程序的系统结构，它意味着一种控制层次体系，指出了需求分析中确定的某一
问题中各元素（模块）之间的相互关系。
软件结构类似于人员组织机构，图4-1给出了某公司的人员组织机构示意图。
由于在人员组织上分成不同的管理层次，则把控制权进行了分配，使一些决定可在工作点附近作出。
具体的说，总经理裁决对于整个公司有影响的问题，具体抓管几个副总经理。
各副总经理又分
管不同的部门。
在底层则进行生产或业务处理。
我们把具有这种特征的组织机构叫做“分层
”结构或称为可分解结构。
软件结构类似于人员组织机构，它是一种可分解结构，按照自顶向下方式把控制分散配置
之后，软件的设计与实现就简单化了，软件的可测试性将提高，软件的维护将更加方便而有
效。
图4-1人员组织机构
图42列出了几种常见的软件结构。
对于具体问题，究竟采用哪种结构，取决于问题本身
采用何种设计方法学，以后我们还要在第五章详述这些问题。
图4-2软件结构
2软件结构中的概念
参见图4-3，我们介绍几个在软件结构中经常使用的术语。
深度：
表示软件结构中控制的层数，它往往能粗略地标志一个系统的大小和复杂程度，深度
和程序长度之间有粗略的对应关系。
宽度：
表示软件结构中控制的总跨度，即同一个层次上的模块总数的最大值，宽度越大系统
越复杂。
扇出：
表示一个模块直接控制（调用）的模块数目。
扇出过大意味着模块过分复杂，需要控
制和协调过多的下级模块，扇出过小也不好，通常平均扇出为3～4，上限扇出为5～9。
扇入：
表示有多少个上级模块直接调用该模块，扇入越大则共享该模块的上级模块数目越多。
软件结构一般要求顶层扇出较大，中层扇出较少，底层扇入较大为好。
图4-3软件结构量度
图4-4在一个模块内的程序过程
3程序过程
软件结构是在不考虑处理和判定顺序情况下用来表达整个软件系统构造的一种方法。
程序过
程则着重于各个模块的处理细节。
程序过程必须提供精确的处理说明，包括顺序、选择、重
复等操作，如图4-4所示。
4.3结构化设计的概念与原理
4.3.1模块化
模块是数据说明、可执行语句等程序对象的集合，它是单独命名的，而且可通过名字来进行
访问。
例如，汇编语言中的子程序，Pascal语言中的过程，C语言中的函数等。
模块化就是把程序划分成若干个模块，每个模块完成一个子功能，把这些模块集总起来组成
一个整体，可以完成指定的功能，满足问题的要求。
模块化是软件的重要属性，它使得一个
程序易于为人理解和处理。
下面根据人类解决问题的一般规律，我们来解释模块化的原理。
设函数C（x）为定义问题x的复杂程度，函数E（x）为确定解决问题x需要的工作量（时间）。
对于两个问题P1和P2，如果有
C（P1）>C（P2）
则有E（P1）>E（P2）
根据人们解决问题的实践，发现了另一个有趣的特性，即
C（P1+P2）>C（P1）+C（P2）
也就是说将P1和P2合并起来组成一个问题的复杂程度大于分别单独考虑每个问题时的复杂程度之和，从而有下列不等式成立
E（P1+P2）>E（P1）+E（P2）
这就揭示了把一个复杂问题划分成许多容易解决的小问题，则原来问题将容易解决，这便
是模块化思想的由来。
图4-5模块化和软件成本
由上面的不等式似乎还能得出下述结论：
如果无限地分割软件，最后为了开发软件而需要的
工作量也就小得可以忽略了。
事实上，还有另一个因素在起作用，从而使得上述结论不能成
立，如图4-5所示。
当模块数目增加时，每个模块的规模将减小，开发单个模块需要的成本（工作量）确实减少了，但随着模块数目的增加，设计模块间接口所需的工作量也将增加。
依据这两个因素，得出了图中的总成本曲线。
每个程序都相应地有一个最适当的模块数目M，
使得系统的开发成本最小。
虽然目前我们还不能准确地确定M的数值，但它却是考虑模块化
时总成本的一个重要参数。
4.3.2抽象化
当我们对任何问题考虑一种模块化解决办法时，可以有不同等级的抽象。
在最高的抽象级上，我们使用问题所处的环境语言，以概括的方式描述问题的解法。
而在较低的抽象级上，采用更加过程化的方法，把面向问题的术语和面向实现的术语结合起来描述问题的解法。
在最低的抽象级上，用可以直接实现的方式描述问题的解法。
例如，在可行性研究阶段，软件作为系统的一个完整部件；在需求分析阶段，软件解法是使用在问题环境内熟悉的方式描述；
当进入总体设计向详细设计过渡阶段，抽象的程度将随之减少；最后当源程序被写出以后，
抽象则达到最低层。
抽象是人类在认识复杂现象过程中使用的一种有效的思维工具。
软件工程过程的每一步都是对软件解法在抽象层次上的一次精化。
在软件结构每一层中的模块，表示了对软件抽象层次的一次细化。
事实上，软件结构顶层的模块，控制了系统的主要功能并且影响全局；在软件结构的底层模块，完成对数据的一个具体的处理。
这种自顶向下由抽象到具体的方式分配控制权限，可以使软件设计过程简化，实现容易，提高软件的可理解性与可测试性，有利于软件产品的维护。
4.3.3信息隐蔽和局部化
模块化的概念向每个软件设计者提出了一个必须回答的问题，即“我们应该如何分解一个软
件，以得到最佳的模块组合呢?
”信息隐蔽原理指出：
应该这样设计和确定模块，使得一个
模块内包含的信息（过程或数据）对于不需要这些信息的模块来说，是不能访问的。
这就充分
说明了模块的特点在于每个模块的设计与决策别的模块是看不到的。
局部化是把一些关系密切的软件元素物理地放得彼此靠近。
过程中的局部数据就是局部化的
一个例子。
抽象、信息隐蔽、局部化都是模块的重要特征。
抽象帮助定义软件过程的实体，信息隐蔽实
施对过程细节的存取约束，局部化是对信息隐蔽的具体实现细节的要求。
“隐蔽”意味着有效的模块化可以通过定义一组独立的模块来实现，这些独立的模块彼此间
仅仅交换那些为了完成系统功能而必须交换的信息。
使用信息隐蔽原理作为模块化系统设
计的标准，会给软件测试和维护带来方便，也可使在修改期间由于疏忽而引入的错误尽可能
少的传播到软件的其他部分。
4.3.4模块独立性
模块独立性的概念是模块化、抽象化、信息隐蔽概念的一个直接产物。
开发具有独立功能而且和其他模块之间没有过多的相互作用的模块，就可以做到模块独立。
换句话说，希望这样设计软件，使每个模块只涉及软件需求的一个具体的相对独立的子功能
，而且与软件结构其他部分的关系或接口是简单的。
我们之所以强调模块的独立性，有两个重要原因。
其一，模块化程度较高的软件容易编制。
其二，独立的模块比较容易维护和测试。
关于模块的独立性我们通常以如下二个指标来衡量
，下面分别介绍其内容。
1块间联系——耦合
耦合是对一个软件结构内不同模块之间互连程度的度量。
耦合有五种，我们按从低到高分别
加以叙述。
（1）两个模块之间完全独立
如果两个模块中的每一个都能独立地工作，而不存在彼此间的联系与制约，这种块间无任何
连接的形式，耦合程度最低。
如图4-6所示，C块与D块之间没有任何联系。
（2）数据耦合
两个模块只通过数据进行交换。
例如，某些
图4-6C，D无关
模块的输出数据作为另一些模块的输入数据，高级语言程序设计中的哑实结合（有参数）等都
属于数据耦合。
如图4-7所示，模块A与模块B间存在数据传递。
图4-7A，B数据耦合
图4-8A，B控制耦合
升级会员 