软件工程第4章软件总体设计终.docx
《软件工程第4章软件总体设计终.docx》由会员分享，可在线阅读，更多相关《软件工程第4章软件总体设计终.docx（38页珍藏版）》请在冰豆网上搜索。
软件工程第4章软件总体设计终
第4章软件总体设计
案例4：
家政服务平台建设
家政服务平台是为了规范家政行业健康发展、服务民生、促进就业、为构建和谐社会提出的重要举措。
也是近几年发展起来的新的服务行业，通过这个平台，我们可以了解到公司的服务标准和模式，清晰地管理经验和流程，将所有的服务内容彰显在客户面前，也可以提供更加便捷的服务，更贴近老百姓的生活。
通过该平台，客户同样可以更精确地找到从事需求工作的人士，为客户解决问题，方便广大老百姓的要求。
软件概要设计范围是：
软件系统总体结构设计、全局数据库和数据结构设计、外部接口设计、主要部件功能分配设计、部件之间的接口设计等方面的内容。
图4-1
家政服务平台总体结构图
【知识导入】
如上图是一个非常简单的总体设计结构图，项目开发到此阶段，也就进入到了核心阶段。
这一阶段设计的好坏对项目影响到项目后期的编码编译。
因此，我们说总体设计是整个软件设计的核心阶段。
在软件发展过去的几十年里，出现了各种各样非常丰富的实用性很强的软件设计技术。
其中包括完整的原理、概念和实践，来指导开发高质量的系统或产品。
同时软件设计也建立了自己的重要原则，用于指导设计工作。
在设计本身会产生各种软件设计表示，这些软件设计表示将指导以后软件的实现活动。
经过需求分析阶段的工作，系统必须“做什么”已经清楚了，现在是决定“怎样做”的时候了。
总体设计的基本目的就是回答“概括地说，系统应该如何实现?
”这个问题，因此，总体设计又称为概要设计或初步设计。
通过这个阶段的工作将划分出组成系统的物理元素——程序、文件、数据库、人工过程和文档等等，但是每个物理元素仍然处于黑盒子级，这些黑盒子里的具体内容将在以后仔细设计。
总体设计阶段的另一项重要任务是设计软件的结构，也就是要确定系统中每个程序是由哪些模块组成的，以及这些模块相互间的关系。
总体设计过程首先寻找实现目标系统的各种不同的方案，需求分析阶段得到的数据流图是设想各种可能方案的基础。
然后分析员从这些供选择的方案中选取若干个合理的方案，为每个合理的方案都准备一份系统流程图，列出组成系统的所有物理元素，进行成本／效益分析，并且制定实现这个方案的进度计划。
分析员应该综合分析比较这些合理的方案，从中选出一个最佳方案向用户和使用部门负责人推荐。
如果用户和使用部门的负责人接受了推荐的方案，分析员应该进一步为这个最佳方案设计软件结构，通常，设计出初步的软件结构后还要多方改进，从而得到更合理的结构，进行必要的数据库设汁，确定测试要求并且制定测试计划。
从上面的叙述中不难看出，在详细设计之前先进行总体设计的必要性：
可以站在全局高度上，花较少成本，从较抽象的层次上分析对比多种可能的系统实现方案和软件结构，从中选出最佳方案和最合理的软件结构，从而用较低成本开发出较高质量的软件系统。
所以，我们评价一个“设计”的标准可以从以下几个方面来：
①有明确的设计步骤。
②良好的设计方法。
③鉴别优劣的准则。
④好的设计表示。
4.1设计过程
一般认为，软件开发阶段由设计、编码和测试三个基本活动组成，其中“设计”活动是获取高质量、低消耗、易维护软件的一个最重要的环节。
需求分析阶段获取到的软件规格说明书包括欲实现系统的信息、功能和行为方面的描述，这是软件设计的基础。
基于这一基础，选择一种软件设计方法完成系统的总体设计、系统的数据设计和系统的过程设计（如图4-2所示）。
采用不同的软件设计方法会产生不同的设计形式。
总体设计宗旨在确定程序各主部件间的关系；数据设计把信息描述转换为实现软件所要求的数据结构；过程设计完成每一部分的过程化描述。
根据设计结果编制代码，然后提交给测试人员测试。
在设计阶段所作种种决策直接影响软件的质量，没有良好的设计，就不可能有稳定的目标系统，也不会有易于维护的软件。
统计表明，设计、编码和测试三个活动一般占用整个软件开发费用的75%以上。
图4-2软件开发阶段信息流
软件设计过程实际上就是将需求规格说明逐步转化为软件的源代码的过程。
作为设计阶段的前期，概要设计任务包括以下内容：
①系统分析员审查软件需求分析所提供的文档，选择最佳方案，并对这些方案进行评审。
②确定模块结构，划分功能模块，将软件功能分配到所划分的最小单元模块，确定模块
间的联系，确定数据结构、文件结构、数据库模式和测试方法。
③编写概要设计说明书，选择相关的软件工具描述软件结构，选择分解功能与划分模块的设计原则。
④对概要设计说明书进行评审，为详细设计提供可靠的输入。
从工程管理的角度来看，软件设计分两步完成，首先做概要设计，将软件需求转化为数据结构和软件的系统结构，并建立接口。
然后是详细设计，即过程设计，通过对软件结构进行细化，得到各功能模块的详细数据结构和算法。
从管理和技术两个不同的角度对设计的认识。
概要设计将软件需求转化为数据结构和软件的系统功能结构。
详细设计即过程设计，通过对系统结构设计进行细化，得到软件的详细的数据结构和算法。
总体设计过程通常由两个主要阶段组成：
（1）系统设计:
确定系统的具体实现方案。
（2）结构设计:
确定软件结构。
典型的总体设计过程有以下9个步骤：
（1）设想供选择的方案
（2）选取合理的方案
（3）推荐最佳方案
（4）功能分解
（5）设计软件结构
（6）设计数据库
（7）制定测试计划
（8）书写文档
（9）审查和复审
4.1.1设想供选择的方案
在总体设计阶段分析员应该考虑各种可能的实现方案，并且力求从中选出最佳方案。
需
求分析阶段得出的数据流图是总体设计的极好的出发点。
数据流图中的某些处理可以逻辑地归并在一个自动化边界内作为一组，另一些处理可以放在另一个自动化边界内作为另一组。
这些自动化边界通常意味着某种实现策略。
设想把数据流图中的处理分组的各种可能的方法，抛弃在技术上行不通的分组方法（例如，组内不同处理的执行时间不相容），余下的分组方法代表可能的实现策略，并且可以启示供选择的物理系统。
在总体设计的该步骤中分析员仅仅一个边界一个边界地设想并且列出供选择的方案，并不评价这些方案.
4.1.2选取若干个合理的方案
至少选取低成本、中等成本和高成本三种方案。
每种方案准备四份资料：
（1）系统流程图；
（2）组成系统的物理元素清单；
（3）成本/效益分析；
（4）实现这个系统的进度计划
4.1.3推荐最佳方案
分析员应该综合分析对比各种合理方案的利弊，推荐一个最佳的方案，并且为推荐的方案制定详细的实现计划。
在使用部门的负责人接受了分析员所推荐的方案之后，将进入总体设计过程的下一个重要阶段——结构设计。
4.1.4功能分解
程序（特别是复杂的大型程序）的设计，通常分为两个阶段完成：
（1）结构设计：
结构设计是总体设计阶段的任务。
结构设计确定程序由哪些模块组成，
以及这些模块之间的关系。
（2）过程设计：
过程设计是详细设计阶段的任务。
过程设计确定每个模块的处理过程。
为确定软件结构，首先需要从实现角度把复杂的功能进一步分解。
一般说来，经过分解之后应该使每个功能对大多数程序员而言都是明显易懂的。
功能分解导致数据流图的进一步细化，同时还应该用IPO图或其他适当的工具简要描述细化后每个处理的算法
4.1.5设计软件结构
通常程序中的一个模块完成一个适当的子功能。
应该把模块组织成良好的层次系统，顶层模块调用它的下层模块以实现程序的完整
功能，每个下层模块再调用更下层的模块，从而完成程序的一个子功能，最下层的模块完成最具体的功能。
软件结构（即由模块组成的层次系统）可以用层次图或结构图来描绘
4.1.6数据库设计
如需使用数据库，分析员应该在需求分析阶段对系统数据要求所做的分析的基础上进
一步设计数据库。
包括下述四个步骤：
（1）模式设计：
模式设计的目的是确定物理数据库结构。
（2）子模式设计：
子模式是用户使用的数据视图。
（3）完整性和安全性设计。
（4）优化：
主要目的是改进模式和子模式以优化数据的存取
4.1.7制定测试计划
在软件开发的早期阶段考虑测试问题，能促使软件设计人员在设计时注意提高软件的可测试性。
4.1.8书写文档
（1）系统说明
用系统流程图描绘的系统构成方案；组成系统的物理元素清单；成本／效益分析；对最佳方案的概括描述；精化的数据流图；用层次图或结构图描绘的软件结构；用IPO图或其他工具（例如，PDL语言）简要描述的各个模块的算法；模块间的接口关系；需求、功能和模块三者之间的交叉参照关系等等。
（2）用户手册
修改更正在需求分析阶段产生的初步的用户手册。
（3）测试计划
包括测试策略，测试方案，预期的测试结果，测试进度计划等等。
（4）详细的实现计划
（5）数据库设计结果
4.1.9审查和复审
最后应该对总体设计的结果进行严格的技术审查，在技术审查通过之后再由使用部门的负责人从管理角度进行复审。
4.2设计原理
在软件设计过程中应该遵循的基本原理和相关概念有：
（1）模块化
（2）抽象
（3）逐步求精
（4）信息隐蔽和局部化
（5）模块独立
4.2.1模块化
（1）模块是数据说明、可执行语句等程序对象的集合，它是单独命名的而且可通过名字来访问，例如，过程、函数、子程序、宏等等都可作为模块。
（2）模块化就是把程序划分成若干个模块，每个模块完成一个子功能，把这些模块集中起来组成一个整体，可以完成指定的功能，满足问题的要求。
（3）不等式
C（P1＋P2）＞C（P1）＋C（P2）
E（P1＋P2）＞E（P1）＋E（P2）
（4）“各个击破”的结论——把复杂的问题分解成许多容易解决的小问题，原来的问题也就容易解决了:
模块化的优点:
（1）可以使软件结构清晰，不仅容易设计也容易阅读和理解；
（2）可以使软件容易测试和调试，因而有助于提高软件的可靠性；
（3）能够提高软件的可修改性；
（4）有助于软件开发工程的组织管理。
4.2.2抽象
抽象就是抽出事物的本质特性而暂时不考虑它们的细节。
处理复杂系统的唯一有效的方法是用层次的方式构造和分析它。
一个复杂的动态系统首先可以用一些高级的抽象概念构造和理解，这些高级概念又可以
用一些较低级的概念构造和理解，如此进行下去，直至最低层次的具体元素
4.2.3逐步求精
逐步求精是许多软件工程技术（如规格说明技术、设计和实现技术）的基础－－为了
能集中精力解决主要问题而尽量延迟对问题细节的考虑．
抽象和求精是一对互补的概念．抽象使得设计者能够说明过程和数据、同时却忽略底
层细节．可以把抽象看成一种通过忽略多余的细节同时强调有关的细节，而实现逐步求精的方法。
图4-3软件模块与软件成本
4.2.4信息隐蔽和局部化
信息隐蔽原理：
应该这样设计和确定模块，使得一个模块内包含的信息（过程和数
据）对于不需要这些信息的模块来说，是不能访问的。
（1）“隐蔽”意味着模块彼此间仅仅交换那些为了完成系统功能而必须交换的信息。
（2）“局部化”是指把一些关系密切的软件元素物理地放得彼此靠近。
局部化有助于实现信息隐蔽。
信息隐蔽和局部化的优点
（1）测试期间和软件维护期间需要修改软件，使用信息隐蔽原理作为模块化系统设计的标准就会带来极大好处。
（2）因为绝大多数数据和过程对于软件的其他部分而言是隐蔽的（也就是“看”不见的），在修改期间由于疏忽而引入的错误就很少可能传播到软件的其他部分。
4.2.5模块独立
模块独立的概念是模块化、抽象、信息隐蔽和局部化概念的直接结果。
为什么模块的独立性很重要呢？
（1）有效的模块化（即具有独立的模块）的软件比较容易开发出来。
（2）独立的模块比较容易测试和维护。
模块的独立程度可以由两个定性标准度量，这两个标准分别称为耦合和内聚。
4.2.6耦合性
耦合性是对一个软件结构中不同模块之间互连程度的度量耦合强弱取决于模块间接口的复杂程度，进入或访问一个模块的点，以及通过接口的数据。
在软件设计中应该追求尽可能松散耦合的系统。
在这样的系统中可以研究、测试或维护任何一个模块，而不需要对系统的其他模块有很多了解。
此外，由于模块间联系简单，发生在一处的错误传播到整个系统的可能性就很小。
因此，模块间的耦合程度强烈影响系统的可理解性、可测试性、可靠性和可维护性。
怎样具体区分模块间耦合程度的强弱呢?
如果两个模块中的每一个都能独立地工作而不需要另一个模块的存在，那么它们彼此完全独立，这意味着模块间无任何连接，耦合程度最低。
但是，在一个软件系统中不可能所有模块之间都没有任何连接。
如果两个模块彼此间通过参数交换信息，而且交换的信息仅仅是数据，那么这种耦合称为数据耦合。
如果传递的信息中有控制信息（尽管有时这种控制信息以数据的形式出现），则这种耦合称为控制耦合。
数据耦合是低耦合。
系统中至少必须存在这种耦合，因为只有当某些模块的输出数据作为另一些模块的输人数据时，系统才能完成有价值的功能。
一般说来，一个系统内可以只包含数据耦合。
控制耦合是中等程度的耦合，它增加了系统的复杂程度。
控制耦合往往是多余的，在把模块适当分解之后通常可以用数据耦合代替它。
如果被调用的模块需要使用作为参数传递进来的数据结构中的所有元素，那么，把整个数据结构作为参数传递就是完全正确的。
但是，当把整个数据结构作为参数传递而被调用的模块只需要使用其中一部分数据元素时，就出现了特征耦合。
在这种情况下，被调用的模块可以使用的数据多于它确实需要的数据，这将导致对数据的访问失去控制，从而给计算机犯罪提供了机会。
当两个或多个模块通过一个公共数据环境相互作用时，它们之间的耦合称为公共环境耦合。
公共环境可以是全程变量、共享的通信区、内存的公共覆盖区、任何存储介质上的文件、物理设备等等。
公共环境耦合的复杂程度随耦合的模块个数而变化，当耦合的模块个数增加时复杂程度显著增加。
如果只有两个模块有公共环境，那么这种耦合有下面两种可能：
（1）一个模块往公共环境送数据，另一个模块从公共环境取数据。
这是数据耦合的一种形式，是比较松散的耦合。
（2）两个模块都既往公共环境送数据又从里面取数据，这种耦合比较紧密，介于数据耦合和控制耦合之间。
如果两个模块共享的数据很多，都通过参数传递可能很不方便，这时可以利用公共环境耦合。
最高程度的耦合是内容耦合。
如果出现下列情况之一，两个模块间就发生了内容耦合：
．一个模块访问另一个模块的内部数据；
．一个模块不通过正常人口而转到另一个模块的内部；
.两个模块有一部分程序代码重叠（只可能出现在汇编程序中）；
．一个模块有多个人口（这意味着一个模块有几种功能）。
应该坚决避免使用内容耦合。
事实上许多高级程序设计语言已经设计成不允许在程序中出现任何形式的内容耦合。
总之，耦合是影响软件复杂程度的一个重要因素。
应该采取下述设计原则：
尽量使用数据耦合，少用控制耦合和特征耦合，限制公共环境耦合的范围，完全不用内容耦合。
模块间的耦合程度强烈影响系统的可理解性、可测试性、可靠性和可维护性。
软件耦合性如图4-4所示：
图4-4软件耦合性示意图
非直接耦合
如果两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用
来实现的，这就是非直接耦合。
这种耦合的模块独立性最强。
（1）数据耦合
如果一个模块访问另一个模块时，彼此之间是通过数据参数（不是控制参数、公共
数据结构或外部变量）来交换输入、输出信息的，则称这种耦合为数据耦合。
按数据耦合开发的程序界面简单、安全可靠。
数据耦合是松散的耦合，模块之间的独立性比较强。
在软件程序结构中至少必须有
这类耦合。
（2）标记耦合
如果一组模块通过参数表传递记录信息，就是标记耦合。
事实上，这组模块共享了这个记录，它是某一数据结构的子结构，而不是简单变量。
这要求这些模块都必须清楚该记录的结构，并按结构要求对此记录进行操作。
如果采取“信息隐蔽”的方法，把在数据结构上的操作全部集中在一个模块中，就可以消除这种耦合。
（4）控制耦合
如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能，就是控制耦合。
这种耦合的实质是在单一接口上选择多功能模块中的某项功能。
对所控制模块的任何修改，都会影响控制模块。
另外，控制耦合也意味着控制模块必须知道所控制模块内部的一些逻辑关系，这些都会降低模块的独立性。
（5）外部耦合
一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息，则称之为外部耦合。
外部耦合引起的问题类似于公共耦合，区别在于在外部耦合中不存在依赖于一个数据结构内部各项的物理安排。
（6）公共耦合
若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。
公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。
这种耦合会引起下列问题：
（1）所有公共耦合模块都与某一个公共数据环境内部各项的物理安排有关，若修改某个数据的大小，将会影响到所有的模块。
（2）无法控制各个模块对公共数据的存取，严重影响软件模块的可靠性和适应性。
（3）公共数据名的使用，明显降低了程序的可读性。
（7）内容耦合
如果出现以下情形，两个模块之间就发生了内容耦合：
①一个模块访问另一个模块的内部数据。
②一个模块不通过正常入口转到另一个模块的内部。
③两个模块有一部分代码重叠（只可能出现在汇编程序中）。
一个模块有多个入口（这意味着一个模块有几种功能）。
4.2.7模块化的原则
1模块化设计的最终目标，是希望建立模块间耦合尽可能松散的系统。
2在这样一个系统中，我们设计、编码、测试和维护其中任何一个模块，就不
需要对系统中其他模块有很多的了解。
③此外，由于模块间联系简单，发生在某一处的错误传播到整个系统的可能性很
小。
4.2.8内聚性
内聚标志一个模块内各个元素彼此结合的紧密程度，它是信息隐藏和局部化概念的自然扩展。
简单地说，理想内聚的模块只做一件事情。
设计时应该力求做到高内聚，通常中等程度的内聚也是可以采用的，而且效果和高内聚相差不多；但是，低内聚很坏，不要使用。
内聚和耦合是密切相关的，模块内的高内聚往往意味着模块间的松耦合。
内聚和耦合都是进行模块化设计的有力工具，但是实践表明内聚更重要，应该把更多注意力集中到提高模块的内聚程度上。
低内聚有如下几类，如果一个模块完成一组任务，这些任务彼此间即使有关系，关系也是很松散的，就叫做偶然内聚。
有时在写完一个程序之后，发现一组语句在两处或多处出现，于是把这些语句作为一个模块以节省内存，这样就出现了偶然内聚的模块。
如果一个模块完成的任务在逻辑上属于相同或相似的一类（例如，一个模块产生各种类型的全部输出），则称为逻辑内聚。
如果一个模块包含的任务必须在同一段时间内执行（例如，模块完成各种初始化工作），就叫时间内聚。
在偶然内聚的模块中，各种元素之间没有实质性联系，很可能在一种应用场合需要修改这个模块，在另一种应用场合又不允许这种修改，从而陷入困境。
事实上，偶然内聚的模块出现修改错误的概率比其他类型的模块高得多。
在逻辑内聚的模块中，不同功能混在一起，合用部分程序代码，即使局部功能的修改有时也会影响全局。
因此，这类模块的修改也比较困难。
时间关系在一定程度上反映了程序的某些实质，所以时间内聚比逻辑内聚好一些。
中内聚主要有两类：
如果一个模块内的处理元素是相关的，而且必须以特定次序执行，则称为过程内聚。
使用程序流程图作为工具设计软件时，常常通过研究流程图确定模块的划分，这样得到的往往是过程内聚的模块。
如果模块中所有元素都使用同一个输入数据和（或）产生同一个输出数据，则称为通信内聚。
高内聚也有两类：
如果一个模块内的处理元素和同一个功能密切相关，而且这些处理必须顺序执行（通常一个处理元素的输出数据作为下一个处理元素的输人数据），则称为顺序内聚。
根据数据流图划分模块时，通常得到顺序内聚的模块，这种模块彼此间的连接往往比较简单。
如果模块内所有处理元素属于一个整体，完成一个单一的功能，则称为功能内聚。
功能内聚是最高程度的内聚。
耦合和内聚的概念是Constantine，Yourdon，Myers和Stevens等人提出来的.按照他们的观点，如果给上述七种内聚的优劣评分，将得到如下结果：
功能内聚10分时间内聚3分
顺序内聚9分逻辑内聚1分
通信内聚7分偶然内聚0分
过程内聚5分
事实上，没有必要精确确定内聚的级别。
重要的是设计时力争做到高内聚，并且能够辨认出低内聚的模块，有能力通过修改设计提高模块的内聚程度降低模块间的耦合程度，从而获得较高的模块独立性。
模块内的高内聚往往意味着模块间的松耦合。
内聚和耦合都是模块化设计的有力工
具，但是实践表明内聚更重要，应该把更多注意力集中到提高模块的内聚程度上。
软件内聚性如图4-5所示：
图4-5软件内聚示例图
（1）巧合内聚
①巧合内聚又称为偶然内聚。
②当模块内各部分之间没有联系，或者即使有联系，这种联系也很松散，则称这种模块为巧合内聚模块，它是内聚程度最低的模块。
③这种模块的缺点
Ⅰ首先是不易修改和维护。
Ⅱ其次是这种模块的内容不易理解，很难描述它所完成的功能，增加了程序的模糊性。
（2）逻辑内聚
这种模块把几种相关的功能组合在一起，每次调用时，由传送给模块的判定参数来确定该模块应执行哪一种功能。
这种模块是单入口多功能模块。
类似的有错误处理模块。
它接收出错信号，对不同类型的错误打印出不同的出错信息。
逻辑内聚模块比巧合内聚模块的内聚程度要高。
逻辑内聚的缺点
①它所执行的不是一种功能，而是执行若干功能中的一种，因此它不易修改。
②另外，当调用时需要进行控制参数的传递，这就增加了模块间的耦合程度。
而将未用的部分也调入内存，这就降低了系统的效率。
（3）时间内聚
时间内聚又称为经典内聚。
这种模块大多为多功能模块，但模块的各个功能的执行与时间有关，通常要求所有功能必须在同一时间段内执行。
例如初始化模块和终止模块。
初始化模块要为所有变量赋初值，对所有介质上的文件置初态，初始化寄存器和栈等，因此要求在程序开始执行的最初一段时间内，模块中所有功能全部执行一遍。
（4）过程内聚
如果一个模块内的处理是相关的，而且必须以特定次序执行，则称这个模块为过程内聚模块。
使用流程图做为工具设计程序的时候，常常通过流程图来确定模块划分。
把流程图中的某一部分划出组成模块，就得到过程内聚模块。
例如，我们把流程图中的循环部分、判定部分、计算部分分成三个模块，这三个模块都
是过程内聚模块。
（5）通信内聚
如果一个模块内各功能部分都使用了相同的输入数据，或产生了相同的输出数据，
则称之为通信内聚模块。
通信内聚模块是通过数据流图来定义的。
图4-6计算机修改文件的数据流图
（6）信息内聚
这种模块完成多个功能，各个功能都在同一数据结构上操作，每一项功能有一个唯一的入口点。
如图4-7所示
图4-7功能唯一对应入口示例图
（7）顺序内聚
如果一个模块内的处理元素和同一个功能密切相关，而且这些处理必须顺序执行（通常一个处理元素的输出数据作为下一个处理元素的输入数据）
（8）功能内聚
一个模块中各个部分都是完成某一具体功能必不可少的组成部分，或者说该模块
中所有部分都是为了完成一项具体功能而协同工作，紧密联系，不可分割的。
则称该模块为功能内聚模块。
功能内聚模块的优点是它们容易修改和维护，因为它们的功能是明确的，模块间的耦合是简单的
4.3面向数据流的设计方法
升级会员 