04 第4章 总体设计.pptx

第1页：本章导言与目录

• 第4章总体设计
• 理解总体设计的目的与任务
• 掌握总体设计的设计原理
• 掌握总体设计的启发式规则
• 熟练掌握结构化设计方法

第2页：第4章总体设计 本节目录

• 第4章总体设计
• 4.1总体设计的目标及任务
• 4.2软件结构设计原理
• 4.3软件结构设计工具
• 4.4软件结构设计启发式规则
• 4.5结构化设计方法

第3页：第4章总体设计 本节目录

• 第4章总体设计
• 4.1总体设计的目标及任务
• 4.2软件结构设计原理
• 4.3软件结构设计工具
• 4.4软件结构设计启发式规则
• 4.5结构化设计方法

第4页：总体设计的目标及任务

总体设计

应用各种技术和原理，对设备、过程或系统做出足够详细的定义，使之能够在物理上得以实现。过程：将“做什么”的逻辑模型转变为“怎么做”的物理模型，即将前期工程中的软件需求转换为软件表示的过程。4.1总体设计的目标及任务

第5页：总体设计的基本目的

总体设计的基本目的：解决“系统应该如何实现”的问题总体设计的两个阶段：系统设计阶段：确定系统的具体实现方案结构设计阶段：确定系统的软件结构4.1总体设计的目标及任务

第6页：设计软件结构

• 1、设计软件结构
• （1）通过需求分析阶段得到的数据流图设想各种可能方案。将一个复杂的系统按功能划分为若干模块；
• （2）确定每个模块的功能；
• （3）确定模块之间的调用关系；
• （4）确定模块之间的接口，即模块之间传递的消息；
• （5）评价模块结构的质量。4.1总体设计的目标及任务

第7页：数据结构及数据库设计数据结构的设计采

2．数据结构及数据库设计数据结构的设计采用逐步细化的方法。

在需求分析阶段可通过数据字典对数据的组成、操作约束和数据之间的关系等方面进行描述，确定数据的结构特性。

在总体设计阶段要加以细化，详细设计阶段则规定具体的实现细节。

4.1总体设计的目标及任务

第8页：确定测试要求并制定测试计划软件开发早

3．确定测试要求并制定测试计划软件开发早期阶段考虑测试问题，能促使软件设计人员在设计时注意提高软件的可测试性。

4、编写总体设计文档《概要设计说明书》4.1总体设计的目标及任务

第9页：评审对设计部分是否完整地实现需求中规

5、评审对设计部分是否完整地实现需求中规定的功能、性能等要求，设计方案的可行性、关键的处理及内外部接口定义正确性、有效性，及各部分之间的一致性等进行评审。

4.1总体设计的目标及任务

第10页：第4章总体设计 本节目录

• 第4章总体设计
• 4.1总体设计的目标及任务
• 4.2软件结构设计原理
• 4.3软件结构设计工具
• 4.4软件结构设计启发式规则
• 4.5结构化设计方法

第11页：软件结构设计原理软件结构设计

• 4.2软件结构设计原理软件结构设计（结构化方法）：
• ①在系统设计中分析信息流程，绘制数据流程图；
• ②根据数据的规范，编制数据字典；
• ③根据概念结构的设计，确定数据文件的逻辑结构；
• ④选择系统执行的结构化语言，以及采用控制结构作为软件的设计工具。

第12页：软件结构设计原理

• 4.2软件结构设计原理4.2.1模块化“由大化小，各个击破”优点：
• 提高可靠性、可修改性
• 错误一般出现在模块或接口中

第13页：软件结构设计原理4.2.1模块化模块

4.2软件结构设计原理4.2.1模块化模块:数据说明、可执行语句等程序对象的集合，或者是单独命名和编址的元素（如函数、子程序）等。

模块化:解决一个复杂问题时自顶向下逐层把软件系统划分成若干模块的过程。

每个模块完成一个特定的子功能，所有的模块按某种方法组装起来，成为一个整体，完成整个系统所要求的功能。

第14页：软件结构设计原理

4.2软件结构设计原理4.2.1模块化模块的基本属性：接口：模块的输入与输出。

功能：模块实现什么功能。

逻辑：描述内部如何实现要求的功能及所需的数据。

状态：指该模块的运行环境，是模块的调用与被调用的关系。

功能、状态、接口反映模块的外部特性，逻辑反映它的内部特性。

第15页：具体（系统功能）（建模）（程序代码）

• 4.2软件结构设计原理4.2.2抽象抽出事物本质特性而不考虑细节软件设计：从抽象概括到具体实现的过程具体
• 抽象
• 具体（系统功能）（建模）（程序代码）

第16页：问题定义阶段

• 问题定义阶段：（具体）用户给出对目标系统的实际需求。
• 系统定义阶段：（抽象）软件可作为整个计算机系统的一个元素来看待。
• 软件需求分析阶段：（抽象）软件的解决方案是使用问题环境中的术语来描述。
• 总体设计—详细设计阶段：（抽象—具体）将面向问题的术语与面向实现的术语结合起来来描述解决方法，直到产生源程序时到达最低抽象层次。4.2软件结构设计原理

第17页：软件结构设计原理

4.2软件结构设计原理4.2.2逐步求精为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。

Miller法则：一个人在任何时候都只能把注意力集中在(7±2)个知识块上。

第18页：软件结构设计原理

4.2软件结构设计原理4.2.3信息隐藏和局部化信息隐藏原理：设计和确定模块时，使得一个模块内包含的信息对于不需要这些信息的模块来说，是不能访问的。

局部化：把一些关系密切的软件元素物理地放得彼此靠近。

优点：防止错误的扩大与传播。

第19页：软件结构设计原理

4.2软件结构设计原理4.2.4模块独立性模块独立是模块化、抽象、信息隐藏和局部化概念的直接结果。

模块独立：每个模块完成一个相对独立的特定子功能，并且和其他模块之间的关系很简单。

第20页：能使开发的软件具有较高的质量

• 4.2软件结构设计原理4.2.4模块独立性良好的模块独立性的重要性：
• 能使开发的软件具有较高的质量。
• 设计的模块可理解性、可维护性及可测试性好，必然导致软件的可靠性高。
• 接口简单、功能独立的模块易开发，且可并行工作，有效地提高了软件的生产率。

第21页：软件结构设计原理4.2.4模块独立性

• 4.2软件结构设计原理4.2.4模块独立性
• 耦合：软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密，其耦合性就越强，模块的独立性则越差。
• 模块间总是相互关联的，很少是相互独立的，完全独立的模块是无法构成系统的。
• 模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息。

第22页：软件结构设计原理4.2.4模块独立性

• 4.2软件结构设计原理4.2.4模块独立性
• 耦合类型无直接耦合—数据耦合—控制耦合—特征耦合—公共耦合—内容耦合低——————————————————————高

第23页：软件结构设计原理4.2.4模块独立性

• 4.2软件结构设计原理4.2.4模块独立性
• 无直接耦合：指两个模块之间没有直接的关系，它们分别从属于不同模块的控制与调用，它们之间不传递任何信息。
• 数据耦合：指两个模块之间有调用关系，传递的是简单的数据值，相当于高级语言中的值传递。这种耦合程度较低，模块的独立性较高。
• 控制耦合：指一个模块调用另一个模块时，传递的是控制变量(如开关、标志等)，被调模块通过该控制变量的值有选择地执行块内某一功能。

第24页：软件结构设计原理4.2.4模块独立性

• 4.2软件结构设计原理4.2.4模块独立性
• 特征耦合：当模块之间传递的是某些数据结构，但是目标模块只是使用了数据结构中的部分内容时，这种耦合方式称为特征耦合。
• 公共耦合：指通过一个公共数据环境相互作用的那些模块间的耦合。公共数据环境可以是全程变量或数据结构、共享的通信区、内存的公共覆盖区及存储介质上的文件和物理设备等。
• 内容耦合：当一个模块直接使用另一个模块的内部数据，或通过非正常入口而转入另一个模块内部时，这种模块之间的耦合便为内容耦合。

第25页：软件结构设计原理

4.2软件结构设计原理4.2.4模块独立性设计原则：尽量使用数据耦合，少用控制耦合和特征耦合，限制公共环境耦合的范围，完全不用内容耦合。

第26页：软件结构设计原理4.2.4模块独立性

• 4.2软件结构设计原理4.2.4模块独立性
• 内聚：一个模块内部各个元素彼此结合的紧密程度的度量。偶然内聚—逻辑内聚—时间内聚—过程内聚—通信内聚—顺序内聚—功能内聚低内聚————————中内聚——————高内聚

第27页：软件结构设计原理4.2.4模块独立性

• 4.2软件结构设计原理4.2.4模块独立性
• 偶然内聚：指一个模块内的各处理元素之间没有任何联系。
• 逻辑内聚：指模块内执行几个逻辑上相似的功能，通过参数确定该模块完成哪一个功能。
• 时间内聚：把需要同时执行的动作组合在一起形成的模块为时间内聚模块。时间内聚模块中的各部分都要在同一时间内完成。
• 过程内聚：如果一个模块内部的处理是相关的，而且这些处理必须以特定的次序执行，则称过程内聚。

第28页：软件结构设计原理4.2.4模块独立性

• 4.2软件结构设计原理4.2.4模块独立性
• 通信内聚：指模块内所有处理元素都在同一个数据结构上操作，或指各处理使用相同的输入数据或者产生相同的输出数据。
• 顺序内聚：指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行，前一功能元素的输出就是下一功能元素的输入。
• 功能内聚：最强的内聚形式，指模块内所有元素共同完成一个功能，缺一不可。模块不能再分割。

第29页：软件结构设计原理

4.2软件结构设计原理4.2.4模块独立性设计原则：力争做到高内聚，并且能辨认出低内聚的模块，通过修改设计提高模块的内聚程度并降低模块间的耦合程度。

【注】耦合性与内聚性是模块独立性的两个定性标准，将软件系统划分成模块时，尽量做到高内聚低耦合，提高模块的独立性，为设计高质量的软件结构奠定基础。

但也有内聚性与耦合性发生矛盾的时候，为了提高内聚性而可能使耦合性变差。

在这种情况下，建议给予内聚性以更高的重视。

第30页：第4章总体设计 本节目录

• 第4章总体设计
• 4.1总体设计的目标及任务
• 4.2软件结构设计原理
• 4.3软件结构设计工具
• 4.4软件结构设计启发式规则
• 4.5结构化设计方法

第31页：软件结构设计启发式规则

4.4软件结构设计启发式规则

• 1．模块独立性准则：通过模块分解或合并，力求做到降低耦合提高内聚，保持模块相对独立性。
• （1）如图4.13(a)所示，若多个模块公有的一个子功能（使用阴影部分表示），则可以将这个子功能独立成一个模块，由这些模块调用。

第32页：若有多个功能相关的模块

4.4软件结构设计启发式规则

（2）若有多个功能相关的模块，如图4.13(b)所示B、C、D三个模块耦合度较高，E、F两个模块耦合度较高，应考虑对它们进行合并以减少控制信息的传递，降低接口的复杂程度。

第33页：模块的作用域应该在控制域内作用域

4.4软件结构设计启发式规则

2．模块的作用域应该在控制域内作用域：指受该模块内一个判断影响的所有模块的集合。

控制域：指模块本身以及其所有直接或者间接从属于它的模块集合。

第34页：软件结构设计启发式规则

4.4软件结构设计启发式规则(a) (b) (c)图4.14模块的作用域和控制域(a)差的结构图(b)不理想的结构图(c)理想的结构图

第35页：软件结构设计启发式规则改进（方法）

• 4.4软件结构设计启发式规则改进方法：
• （1）上移判断点。如图4.14 (a)所示，将模块D中的判断点上移到它的上层模块B中，或者将整个模块D合并到模块B中，使该判断的层次升高，以扩大它的控制域。
• （2）下移受判断影响的模块。将受判断影响的模块下移到判断所在模块的控制域内，如图4.14 (a)所示，将模块C下移到模块D的下层。

第36页：（1）深度指软件结构中模块的层次数

• （1）深度指软件结构中模块的层次数，它表示控制的层数，一定意义上能粗略地反映系统的规模和复杂程度。
• （2）宽度指同一层次中最大的模块个数，它表示控制的总分布。
• （3）扇出指一个模块直接调用的模块数目。经验证明，良好的系统结构平均扇出数一般是3-4，不能超过5-9。
• （4）扇入指有多少个上级模块直接调用它。4.4软件结构设计启发式规则
• 3．软件结构的形态特征准则

第37页：深度能粗略地反映系统的规模和复杂程度

• （1）深度能粗略地反映系统的规模和复杂程度，宽度也能反映系统的复杂情况。宽度与模块扇出有关，若一个模块的扇出太多，说明本模块过分复杂，缺少中间层。
• （2）单一功能模块的扇入数大比较好，说明本模块为上层几个模块共享的公用模块，重用率高。
• （3）不能把彼此无关的功能凑在一起形成一个通用的超级模块，虽然它扇入高，但内聚低。因此非单一功能的模块扇入高时应考虑重新分解，以消除控制耦合的情况。4.4软件结构设计启发式规则

第38页：软件结构设计工具如图所示

4.3软件结构设计工具如图所示，结构图的深度为5；宽度为8；模块M的扇出为3；模块T的扇入为4。

第39页：模块大小准则在考虑模块的独立性时

4.4软件结构设计启发式规则

• 4．模块大小准则在考虑模块的独立性时，为了增加可理解性，模块的大小最好在50-150条语句左右，可以用1-2页纸打印，便于人们阅读与研究。
• 5．模块的接口准则
• （1）模块接口设计要简单，以降低复杂程度和冗余度。
• （2）设计功能可预测并能得到验证的模块。
• （3）适当划分模块规模，以保持其独立性。

第40页：第4章总体设计 本节目录

• 第4章总体设计
• 4.1总体设计的目标及任务
• 4.2软件结构设计原理
• 4.3软件结构设计工具
• 4.4软件结构设计启发式规则
• 4.5结构化设计方法

第41页：软件结构设计工具

4.3.1层次图4.3软件结构设计工具左图中，矩形框：模块连线：调用关系层次图：适于在自顶向下设计软件的过程中使用。

第42页：HIPO图=H图+每个模块的IPO图

4.3.2 HIPO图=H图+每个模块的IPO图（H图：带编号的层次图）4.3软件结构设计工具Note:和H图中每个方框相对应，应都有一张IPO图来描绘其代表的模块处理过程。

第43页：软件结构设计工具

4.3软件结构设计工具4.3.3软件结构图主要内容：模块——方框表示模块的调用关系——单向箭头或直线模块间的信息传递——带注释的短箭头选择调用——菱形循环调用——弧形箭头

第44页：软件结构设计工具

4.3软件结构设计工具

第45页：软件结构设计工具画结构图应注意的事项

• 4.3软件结构设计工具画结构图应注意的事项：
• （1）同一名字的模块在结构图中仅出现一次。
• （2）调用关系只能从上到下。
• （3）不严格规定模块的调用次序，习惯上从左到右。有时为了减少连线的交叉，可适当地调整同一层模块的左右位置，以保持结构图的清晰性。

第46页：结构化设计方法结构化设计（方法）

4.5结构化设计方法结构化设计方法（简称SD方法），就是基于数据流的设计方法。

基于数据流的设计方法：将数据流图变换成软件结构。

面向数据流的设计方法定义了一些不同的“映射”，利用这些映射可以把数据流图变换成软件结构。

因为任何软件系统都可以用数据流图表示，所以面向数据流的设计方法理论上可以用来设计任何软件的结构。

第47页：结构化设计（方法）

4.5.1数据流图的类型1.变换型数据流图变换型的数据流图是由输入、变换（或称处理）和输出三部分组成。

虚线为标出的流界。

变换型数据处理的工作过程一般分为取得数据、变换数据和输出数据。

这三步体现了变换型数据流图的基本思想。

逻辑输入

第48页：数据流图的类型

• 变换是系统的主加工，在输入端传递给变换中心中第一个变换的数据流称为系统输入端的逻辑输入，经过变换中心的最后一个变换得到的数据流称为输出端的逻辑输出。
• 直接从外部设备输入的数据称为物理输入，反之称为物理输出。
• 外部的输入数据一般要经过输入正确性和合理性检查、编辑及格式转换等预处理，这部分工作都由逻辑输入部分完成，它将外部形式的数据变成内部形式，送给变换中心。
• 逻辑输出部分把主变换产生的数据的内部形式转换成外部形式然后物理输出。因此，变换型的数据流图是一个顺序结构。4.5.1数据流图的类型

第49页：事务型数据流图若某个变换将它的输入流

2．事务型数据流图若某个变换将它的输入流分离成许多发散的数据流，形成许多平行的变换路径，并根据输入的值选择其中一个路径来执行，这种特征的数据流图则称为事务型数据流图，这个变换称为事务处理中心。

4.5.1数据流图的类型

第50页：结构化设计方法过程

• 1．复查并精化数据流图
• 2．确定数据流图类型
• ①一般情况下，系统中的所有信息流都可以认为是变换流。但是，当遇到有明显事务特性的信息流时，建议采用事务型分析方法进行设计。
• ②设计人员应该根据数据流图中占优势的属性，确定数据流的全局特性。此外还应该把具有和全局特性不同的特点的局部区域孤立出来，以后可以按照这些子数据流的特点来精化根据全局特点得出的软件结构。4.5.2结构化设计方法过程

第51页：确定数据流的边界对于变换流

• 3．确定数据流的边界对于变换流，分析确定输入流和输出流的边界，从而孤立出变换中心；对于事务流，分析确定输入流的边界，从而孤立出事务中心。
• 4．完成“第一级分解”软件结构代表对控制的自顶向下的分配，所谓分解就是分配控制的过程，而“第一级分解”就是分配顶层控制。4.5.2结构化设计方法过程

第52页：对于变换流

4.5.2结构化设计方法过程

• （1）对于变换流，位于软件结构最顶层的控制模块协调下述3个从属模块的控制功能：
• 输入信息处理控制模块：协调输入信息的产生过程；
• 变换中心控制模块：管理对内部形式的数据的所有操作；
• 输出信息处理控制模块：协调输出信息的产生过程。
• （2）对于事务流，位于软件结构最顶层的总控制模块管理下属的接收分支和发送分支的工作。接收分支由输入流映射而成；发送分支的顶层是一个调度模块，它根据输入数据的类型调用相应的活动分支。

第53页：完成“第二级分解”所谓“第二级分解”

4.5.2结构化设计方法过程

• 5．完成“第二级分解”所谓“第二级分解”就是把数据流图中的每个处理映射成软件结构中一个适当的模块。
• 6．优化对于第一次分割得到的软件结构，为了产生合理的分解，得到尽可能高的内聚，尽可能松散的耦合，总可以根据模块独立原理和启发式设计规则进行优化。最重要的是为了得到一个易于实现、易于测试和易于维护的软件结构，应该对初步分割得到的模块进行再分解或合并。

第54页：变换型分析设计1.确定DFD中的变换

• 4.5.3变换型分析设计1.确定DFD中的变换中心、逻辑输入和逻辑输出
• （1）逻辑输入端的确定：从物理输入端开始，沿着数据流方向向系统中心寻找，直到有这样的数据流，它不能再被看作是系统的输入，则它的前一个数据流就是系统的逻辑输入。
• （2）逻辑输出端的确定：从物理输出端开始，逆数据流方向向中间移动，可以确定系统的逻辑输出。介于逻辑输入和逻辑输出之间的加工就是变换中心。用虚线划分出流界，DFD的三部分就可以被确定了。

第55页：变换型分析设计2.设计软件结构的顶层

• 4.5.3变换型分析设计2.设计软件结构的顶层和第一层——变换结构
• 主模块确定之后，开始设计软件结构的第一层。第一层至少要有输入、输出和变换三种功能的模块。
• 为每个逻辑输入设计一个输入模块，其功能为向顶层模块提供相应的数据。
• 为每个逻辑输出设计一个输出模块，其功能为输出顶层模块的信息。
• 为变换中心设计一个变换模块，它的功能是将逻辑输入进行变换加工，然后逻辑输出。

第56页：f3f7f7f3主模块get f3将f3

f3f7f7f3主模块get f3将f3变换成f7put f74.5.3变换型分析设计从上图导出的初始结构图f2f3f8f7f5f6f4输入f1ABEDCF变换中心输出

第57页：变换型分析设计3.设计中、下层模块

• 4.5.3变换型分析设计3.设计中、下层模块
• (1)输入模块的下属模块的设计：输入模块的功能是向它的调用模块提供数据，所以必须要有数据来源。这样输入模块应由接收数据和转换成调用模块所需的信息两部分组成。
• (2)输出模块的下属模块的设计：输出模块的功能是将它的调用模块产生的结果送出。它由将数据转换成下属模块所需的形式和发送数据两部分组成。
• (3)变换模块的下属模块的设计：根据DFD中变换中心的组成情况，按照模块独立性的原则来组织其结构，一般对DFD中每个基本加工建立一个功能模块。

第58页：变换型分析设计

4.5.3变换型分析设计

第59页：

第60页：设计的优化根据设计准则对初始结构进行

4.5.3变换型分析设计

• 4．设计的优化根据设计准则对初始结构进行精细和改进，以下为常用的求精方法。
• (1)输入部分的求精：对每个物理输入设置专门模块，以体现系统的外部接口；其他输入模块并非真正输入，当它与转换数据的模块都很简单时，可将它们合并成一个模块。
• (2)输出部分的求精：为每个物理输出设置专门模块，同时注意把相同或类似的物理输出模块合并在一起，以减低耦合度。
• (3)变换部分的求精：根据设计准则，对模块进行合并或调整。

第61页：确定DFD中的事务中心和加工路径当D

4.5.4事务型分析设计

1．确定DFD中的事务中心和加工路径当DFD中的某个加工明显地将一个输入数据流分解成多个发散的输出数据流时，该加工就是事务中心。

从事务中心辐射出去的数据流则为各个加工路径。

第62页：事务型分析设计

• 2．设计软件结构的顶层和第一层——事务结构设计一个顶层模块，它是一个主模块，有两个功能，一是接收数据，二是根据事务类型调度相应的处理模块。事务型软件结构应包括接收分支和发送分支两部分。
• （1）接收分支：负责接收数据，它的设计与变换型DFD的输入部分设计方法相同。
• （2）发送分支：通常包含一个调度模块，它控制管理所有下层的事务处理模块。当事务类型不多时，调度模块可与主模块合并。4.5.4事务型分析设计

第63页：设计事务结构的中下层

• 3.设计事务结构的中下层
• 为每一种事务处理设计一个事务处理模块。为事务处理设计操作模块。为操作模块设计细节模块。某些操作模块和细节模块可以被它们的调用模块共享。4.对初始的事务结构优化工作同变换结构。
• 4.5.4事务型分析设计

第64页：事务型分析设计

4.5.4事务型分析设计

第65页：综合型数据流图一个大型系统DFD中

• 4.5.5综合型数据流图一个大型系统DFD中，既有变换流，又有事务流，属于综合的数据流图。
• 1．确定DFD整体上的类型事务型通常用于对高层数据流图的变换，其优点是把一个大而复杂的系统分解成若干较小而简单的子系统。变换型通常用于对较低层数据流图的转换。变换型具有顺序处理的特点，而事务型具有平行分别处理的特点，所以两种类型的DFD导出的软件结构有所不同。只要从DFD整体的主要功能处理分析其特点，就可区分出该DFD整体类型。

第66页：标出局部的DFD范围

4.5.5综合型数据流图

• 2．标出局部的DFD范围，确定其类型
• 3．按整体和局部的DFD特征，设计出软件结构

第67页：综合型数据流图主图是变换型

4.5.5综合型数据流图主图是变换型，子图是事务型的数据流图分析设计示意图

第68页：综合型数据流图主图是事务型

4.5.5综合型数据流图主图是事务型，子图是变换型的数据流图分析设计示意图

第69页：软件结构图后续设计工作

4.6软件结构图后续设计工作

• （1）为每个模块写一份处理说明，从设计的角度描述模块的主要处理任务、条件抉择等，以需求分析阶段产生的加工逻辑的描述为参考。
• （2）为每个模块提供一份接口说明，包括通过参数表传递的数据、外部的输入/输出和访问全局数据区的信息等，并指出它的下属模块与上属模块。对以上两个说明可用设计阶段常采用的图形工具——IPO图来表示。
• （3）数据结构说明。软件结构确定之后，必须定义全局的和局部的数据结构，因为它们对每个模块的过程细节有着深远的影响。数据结构的描述可用伪码（如PDL语言、类Pascal语言）或Warnier图、Jackson图等形式表达。
• （4）给出设计约束或限制，如数据类型和格式的限制，内存容量的限制，时间的限制，数据的边界值，个别模块的特殊要求等。
• （5）进行设计评审：软件设计阶段，不可避免地会引入人为的错误，如果不及时纠正，就会传播到开发的后续阶段中去，并在后续阶段引入更多的错误。

第70页：某企业销售事务处理的统计软件的功能要

• 例：某企业销售事务处理的统计软件的功能要求为根据顾客的订单记录进行各种销售统计分类：
• (1)根据销售日期分类；
• (2)根据顾客区域分类；
• (3)根据货物品种分类；
• (4)根据顾客名字分类。最后生成分类的统计报表。根据要求画出该问题的数据流图。习题：

第71页：

第72页：

第73页：本章结束页

The End