05 第五章 总体设计.pptx

第1页：第5章 总体设计

第5章 总体设计

• 1.设想供选择的方案
• 2.选择合理的方案对每个合理的方案要提供
• 系统流程图B．组成系统的物理元素清单C．成本/效益分析D．实现这个系统的进度计划

第2页：总体设计过程（中）

总体设计过程（中）

• 3.推荐最佳方案
• 4.功能分解
• 5.设计软件结构
• 6.数据库设计A．模式设计B．子模式设计C．完整性和安全性设计D．优化

第3页：总体设计过程（下）

总体设计过程（下）

• 7.制定测试计划
• 8.书写文档A．系统说明B．用户手册C．测试计划D．详细的实现计划E．数据库设计结果
• 9.审查和复审

第4页：模块化原理

模块化原理：设计原理如果一个大型程序仅由一个模块组成，很难被人理解。设函数C(x)定义问题x的复杂程度，函数E(x)定义解决问题x需要的工作量（时间）。对于两个问题P1和P2，如果：C(P

• >C(P
• 那么E(P
• >E(P
• 根据解决问题的经验，有一个规律是：C(P1+P
• >C(P
• +C(P
• 于是有E(P1+P
• >E(P
• +E(P2)

第5页：模块化与软件成本

模块化与软件成本：模块数目接口成本成本/

第6页：抽象与模块独立

抽象与模块独立：抽象5.2.3逐步求精模块的独立性很重要，因为

• 有效的模块化的软件比较容易开发出来
• 独立的模块比较容易测试和维护。5.2.4信息隐蔽和局部化

第7页：耦合的定义

一、耦合耦合

指软件结构内不同模块彼此之间相互依赖（连接）的紧密程度。模块独立程度可以由两个定性标准度量：耦合与内聚

第8页：数据耦合

数据耦合：模块的偶合分四类

• 数据耦合两个模块之间只是通过参数交换信息，而且交换的信息仅仅是数据。数据耦合是最低程度的耦合。AB数据

第9页：控制耦合

控制耦合

• 控制耦合两个模块之间所交换的信息包含控制信息。控制耦合是中等程度的耦合。图中模块A的内部处理程序判断是执行C还是执行D，要取决于模块B传来的信息状态（Status）。BACD
• 控制耦合astatus

第10页：公用耦合

公用耦合：3）公用耦合两个或多个模块通过一个公共区相互作用时的耦合。公共区可以是：全程数据区、共享通信区、内存公共覆盖区、任何介质上的文件、物理设备等。软件结构中存在大量的公用耦合时会给诊断错误带来困难

第11页：公用耦合示例（一）

公用耦合示例（一）：图中存在公用耦合，假设模块A、C、E都存取全程数据区（如公用一个磁盘文件）中的一个数据项。如果A模块读取该项数据，然后调用C模块对该项重新计算，并进行数据更新。ABCDE全程数据区（3）

第12页：公用耦合示例（二）

公用耦合示例（二）：如果此时C模块错误地更新了该项数据，在往下的处理中模块E读该数据项时出现错误。表面上看，问题由模块E产生，实际上由模块C引起。ABCDE全程数据区（3）

第13页：内容耦合

内容耦合

• 内容耦合一个模块与另一个模块的内容直接发生联系。内容耦合对维护会带来严重的困难。模块A…LAB：MOVE1…模块B…GOTOLAB…内容耦合
• 内容耦合程序中如果一个模块直接把程序转移到另一个模块中，或一个模块使用另一个模块内部的数据，都会产生内容耦合。内容耦合是最高程度的耦合，应该避免采用

第14页：耦合的设计建议

耦合的设计建议：软件设计应追求尽可能松散耦合，避免强耦合，这样模块间的联系就越小，模块的独立性就越强，对模块的测试、维护就越容易。因此建议：尽量使用数据耦合，少用控制耦合，限制公用耦合，完全不用内容偶合

第15页：内聚的定义

内聚的定义：二、内聚内聚：一个模块内部各个元素彼此结合的紧密程度。它是衡量一个模块内部组成部分间整体统一性的度量。常见的内聚有七类

第16页：功能内聚

功能内聚：1）功能内聚（FunctionalCohesion）如果一个模块内所有处理元素完成一个，而且仅完成一个功能，则称为功能内聚。功能内聚是最高程度的内聚。但在软件结构中，并不是每个模块都能设计成一个功能内聚模块

第17页：顺序内聚

顺序内聚：2）顺序内聚（SequentialCohesion）如果一个模块内处理元素和同一个功能密切相关，而且这些处理元素必须顺序执行，则称为顺序内聚

第18页：顺序内聚示例

顺序内聚示例：如图，一个求一元二次方程根的模块由三个处理元素组成，该模块中存在顺序内聚。通常，顺序内聚中一个处理元素的输出是另一个处理元素的输入。求一元二次方程根模块1．输入方程系数2．求解3．

第19页：通信内聚

通信内聚：3）通信内聚（CommunicationalCohesion）如果一个模块中所有处理元素都使用同一个输入数据和（或）产生同一个输出数据，称为通信内聚

第20页：通信内聚示例

通信内聚示例：如图，模块A的处理单元将根据同一个数据文件FILE的数据产生不同的表格，因此它存在通信内聚。通信内聚有时也称为数据内聚。A从文件FILE中读出数据

• 1.由数据产生报表A
• 2.由数据产生报表B通信内聚示例

第21页：过程内聚

过程内聚：4）过程内聚（ProceduralCohesion）如果一个模块内的处理元素是相关的，而且必须以特定的次序执行，称为过程内聚。过程内聚与顺序内聚的区别是：顺序内聚中是数据流从一个处理单元流到另一个处理单元，而过程内聚是控制流从一个动作流向另一个动作

第22页：时间内聚

时间内聚：5）时间内聚（TemporalCohesion）如果一个模块包含的任务必须在同一段时间内执行，称为时间内聚。也称为瞬时内聚

第23页：时间内聚示例

时间内聚示例：例如，完成各种初始化工作的模块，或者处理故障的模块都存在时间内聚。如图，在“紧急故障处理模块”中，“关闭文件”、“报警”、“保留现场”等任务都必须无中断地同时处理。紧急故障处理模块1．关闭文件2．报警3．

第24页：逻辑内聚

逻辑内聚：6）逻辑内聚（LogicalCohesion）如果模块完成的任务在逻辑上属于相同或相似的一类，称为逻辑内聚

第25页：逻辑内聚示例

逻辑内聚示例：如图，A、B、C模块合并成ABC模块之后，ABC模块就是逻辑内聚模块。XYZA

第26页：逻辑内聚的缺点

逻辑内聚的缺点：对逻辑内聚模块的调用，常常需要有一个功能开关，由上层调用模块向它发出一个控制信号，在多个关联性功能中选择执行某一个功能。这种内聚较差，增加了模块之间的联系，不易修改

第27页：偶然内聚

偶然内聚：7）偶然内聚（CoincidentalCohesion）如果一个模块由完成若干毫无关系的功能处理元素偶然组合在一起的，就叫偶然内聚

第28页：偶然内聚的成因

偶然内聚的成因：偶然内聚是最差的一种内聚。常犯这种错误的一种情况是：有时在写完程序后，发现一组语句在多处出现，于是为了节省空间而将这些语句作为一个模块设计，就出现偶然内聚

第29页：偶然内聚示例

偶然内聚示例：如图，模块A、B、C出现公共代码段W，于是将W独立成一个模块，而W中这些语句并没有任何联系。如果在测试中发现模块A不需要做“X=Y+Z”，而应该做“X=Y*Z”，此时对W的维护就很困难了。ABCW模块X=Y+ZGETCARDIFI=5THENE=0…

第30页：内聚的设计原则

内聚的设计原则：软件设计中应该：力求做到高内聚，尽量少用中内聚，不用低内聚

第31页：启发式规则（一）

启发式规则（一）

• 1.改进软件结构提高模块独立性
• 2.模块规模应该适中
• 3.深度、宽度、扇出和扇入都应适当深度：软件结构中控制的层数；宽度：软件结构内同一个层次上的模块总数的最大值；扇出：一个模块直接控制（调用）其它模块的数目；扇入：一个模块被其它模块调用的数目。正文加工系统输入输出编辑加标题存储检索编目录格式化添加删除插入修改合并列表

第32页：扇出扇入过大的改进

扇出扇入过大的改进：对扇出、扇入过大的改进：（a）对扇入过大的改进（b）

第33页：作用域与控制域

作用域与控制域：模块的作用域应该在控制域之内MAGBCEDF图5.2模块的作用域和控制域作用域：受该模块内一个判定影响的所有模块的集合。控制域：模块本身以及所有从属于它的模块的集合

第34页：降低模块接口的复杂度

降低模块接口的复杂度：如：QUAD-ROOT（TBL,X）求一元二次方程的根的模块，其中TBL，X都为数组，分别代表方程的系数和方程的根。应该使接口更简单，如：QUAD-ROOT（A,B,C,ROOT1,ROOT

• B、C是方程的系数，ROOT1，ROOT2是方程的根
• 5.力争降低模块接口的复杂度

第35页：单入口单出口与功能可预测

单入口单出口与功能可预测

• 6.设计单入口、单出口的模块
• 7.模块功能应该可以预测

第36页：正文加工系统的层次图

正文加工系统的层次图：图形工具5.4.1层次图和HIPO图正文加工系统输入输出编辑加标题存储检索编目录格式化添加删除插入修改合并列表图

第37页：带编号的层次图H图

带编号的层次图H图：正文加工系统输入1.0输出2.0编辑3.0加标题4.0存储5.0检索6.0编目录7.0格式化8.0添加3.1删除3.2插入3.3修改3.4合并3.5列表3.6图5.4带编号的层次图（H图）HIPO图是：“层次图＋输入/处理/输出图”

第38页：结构图

结构图：产生最佳解得到好输入计算最佳解输出结果读输入编辑输入结果格式化显示结果图4.5结构图的例子—

第39页：结构图的调用表示

结构图的调用表示：MAB图5.6判定为真时调用A，为假时调用BMABC图5.7模块M循环调用模块A、B、C

第40页：面向数据流的设计方法

面向数据流的设计方法：面向数据流设计（DataFlow-OrientedDesign，DFOD）是与数据流分析（DFA）对应的结构化软件设计技术。面向数据流的设计将得到以数据流图为基础的软件模块结构图

第41页：变换流与事务流

变换流与事务流：数据流可以分为两种类型

• 变换型数据流
• 事务型数据流

第42页：变换型数据流图

变换型数据流图：一、变换流具有较明确的输入、变换（或称主加工）和输出界面的数据流图称为变换型数据流图。如图所示，该变换中心可以理解为数据的加工和处理程序。读入原始数据校验原始数据计算最优结果编辑打印最优结果输入变换中心输出

第43页：事务型数据流图

事务型数据流图：中存在一个事务中心（也就是数据处理、加工中心），它将输入分离成若干个发散的数据流，形成许多活动路径，并根据输入值选择其中一条路径。要求类别处理分房处理调房处理退房处理住房要求事务中心活动路径二

第44页：混合型数据流图

混合型数据流图：通常，一个实际系统的数据流图是变换型和事务型两种类型的混合体。如图所示，中间的子块属事务型数据流，如果把中间子块视为一个处理整体的话，整个程序属变换型程序。A（事务型，A为事务中心）

第45页：面向数据流设计的步骤（上）

面向数据流设计的步骤（上）：面向数据流设计软件结构的基本步骤有七步

• 复审并精化数据流图
• 确定数据处理流图的类型
• 确定变换中心或事务中心

第46页：面向数据流设计的步骤（下）

面向数据流设计的步骤（下）

• 将数据流图映射成软件模块结构图，设计出该数据流图对应的第一层模块结构
• 基于数据流图逐步分解，设计下层模块
• 运用模块设计和优化准则优化软件结构
• 描述模块的接口

第47页：面向数据流设计流程图

面向数据流设计流程图：复查、精化数据流图类型找出事务中心找出变换中心映射成事务结构映射成变换结构优化软件模块结构导出模块结构复查不满意变换事务变换

第48页：变换设计的概念

变换设计的概念：变换设计就是从变换型数据流图映射出软件模块结构的过程

第49页：变换设计的第一层模块结构

变换设计的第一层模块结构：变换设计的基本方法有两步：1）分解第一层模块结构就是把整个变换分解成输入控制模块Ci、输出控制模块Co和变换中心控制模块Ct，由主控模块控制。主控模块输出控制模块Co变换中心控制模块Ct输入控制模块Ci

第50页：变换设计的下层模块设计

变换设计的下层模块设计：2）分别设计输入、输出和处理的下层模块结构方法是：从变换中心边界向两侧移动，分别把输入通路和输出通路的每个处理映射成输入控制模块Ci和输出控制模块Co的下属模块。变换中心的下层模块，是把每个处理映射成变换中心控制模块Ct的一个直接下属模块

第51页：变换设计示例

变换设计示例：ABCDFEGHIJK变换中心输入输出主控模块输出控制模块Co变换中心控制模块Ct输入控制模块CiDCBAEFGIHJK

第52页：事务设计的概念

事务设计的概念：事务设计就是从事务型数据流图映射出软件模块结构的过程

第53页：事务设计的主控模块结构

事务设计的主控模块结构：事务设计的基本方法有两步：1）建立主控模块、接收输入类型分析模块和事务调度模块；主模块调度输入类型分析

第54页：事务设计的下层模块设计

事务设计的下层模块设计：2）分别设计输入类型分析模块和调度模块的下层模块结构。方法是：将输出的每条通路作为调度模块的一个判断分支，而输入类型分析模块的下层模块与变换设计类似

第55页：事务设计示例

事务设计示例：I2I3I1TCA1B1C1A2B2C2事务中心主模块调度输入类型分析I1I3I2A1A2B1B2C1C2

第56页：第5章小结

第5章小结：◇概要设计说明书该说明书是概要实际阶段的工作成果，它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计提供基础