结构化设计软件

第5章结构化软件设计通过软件设计将用户的需求变为实现软件的“蓝图”。蓝图只描述软件的整体框架，也叫做总体设计。总体设计之后，就要对软件进行详细设计，通过对软件设计的不断细化，形成一个可以实施的设计方案。软件设计的最终目标是要取得最佳方案。“最佳”是指在所有候选方案中，能够以最低的成本，在最短的时间内，生产出可靠性和可维护性俱佳软件的方案。

5.1软件设计过程软件设计是以总体框架设计为起始点，根据用户的需求先确定软件系统的总体结构和总的设计原则，用户对总体设计满意后，对软件的实现算法和数据结构进行细节设计。用户从总体设计中只能知道系统做什么，而不能获得有关系统如何工作的细节。详细设计详细设计是解决系统具体怎样做的问题。与总体设计相比，详细设计主要描述软件功能的具体实现方法、人机界面、输入和输出，以及软件元素在网络上的布局等。也就是说，详细设计是系统说明的一个技术层面上的描述，详细设计的结果可以直接由程序员在实现阶段将它翻译成具体的程序语句。典型总体设计过程（1）（1）设想供选择的方案。需求分析得到的数据流程图是总体设计的出发点，设计者根据数据流程图中某些处理的逻辑关系，将相关的处理归并在一起，形成子系统。不同的子系统组合产生不同的系统实现方案，对每种合理的方案都应该准备下列四份资料：系统流程图、组成系统的元素清单、成本／效益分析、实现这个方案的进度计划。设计人员给出对每种方案的评价。典型总体设计过程（2）（2）推荐最佳方案。（3）功能分解，确定软件结构。设计人员结合算法描述仔细分析数据流程图中的每个处理，如果一个处理的功能过于复杂，应该把它适当地分解成比较简单的功能，功能分解导致数据流程图的进一步细化。细化之后，通常一个模块只完成一个适当的功能，每个模块对大多数程序员而言都是易于理解的。典型总体设计过程（3）（4）设计软件结构。设计人员把模块组织成层次结构，顶层模块调用它的下层模块，每个下层模块再调用更下层的模块，最下层的模块完成最具体的功能。这样自顶向下实现一个完整的功能。（5）数据设计。确定实现系统所必须的数据、数据之间的关系、存储数据的实体。（6）制定测试计划。典型总体设计过程（4）（7）书写文档。总体设计规格说明书：包括系统实现方案，软件结构设计，简要的模块说明，模块间的接口关系说明，数据和数据结构说明、文件设计说明和数据库设计说明。需求、功能和模块三者之间的交叉参照关系表等等。用户手册：根据总体设计结果，完善需求分析阶段编写的用户手册。测试计划：包括测试策略，测试方案，预期的测试结果，测试进度、计划等等。典型总体设计过程（5）（8）设计审查和复审。对总体设计的结果进行技术审查，在技术审查通过之后再由使用部门的负责人从管理角度进行复审。详细设计过程：详细设计每个软件模块的实现算法和内部数据结构。详细设计每个用户界面，包括操作命令。详细设计输入输出数据的内容和格式。详细设计程序的错误处理方法，并且列出一个错误处理清单表。上述内容构成了详细设计文档。典型总体设计过程（6）（9）评审详细设计。主要检查算法的正确性、易理解和可实现性；数据结构的简洁性、灵活性。

开发阶段的信息流程序模块总体结构设计设计编码信息描述功能描述行为描述其他需求过程设计数据设计集成并确认的软件测试5.2软件设计原则

和影响设计的因素软件设计是一项创造性工作，以往的设计经验和良好的设计灵感、以及对质量的深刻理解都会对设计产生影响。软件设计过程是一系列迭代的步骤，设计者自顶向下、由粗至细逐步构造系统。设计人员的理解力和喜好、文化背景、信仰、价值观等其他方面的问题影响软件设计。如果没有一致的规范约束，有可能导致设计的系统无法满足要求。软件设计原则（1）（1）多样化设计。一名好的设计师应该考虑设计的替代方案，通常应该提供多种设计方案可供评审和选择。（2）设计可回溯到需求。软件设计中的每个元素可能会对应到多个需求，也可能一个需求对应多个软件元素。为了使软件满足用户的需求，设计师一定要保证设计的可回溯性。（3）充分利用已有的模块。一个复杂的软件通常是由一系列模块组成，很多模块可能在以前的系统中已经开发过了，如果这些模块设计的好，具有良好的可复用性，那么，在设计新软件时应该尽可能使用已有的模块。软件设计原则（2）（4）设计应该表现出一致性和规范性。在设计开始之前，设计小组应该定义设计风格和设计规范，保证不同的设计人员设计出风格一致的软件。（5）设计的易修改性。软件开发的整个过程中都存在着变化，变化是永恒的，因此，软件设计时必须要考虑到设计的易修改性。（6）容错性设计。不管多么完善的软件都可能有潜在的问题，所以，设计人员应该为软件进行容错性设计，当软件遇到异常数据、事件或操作时，软件不至于彻底崩溃。软件设计原则（3）（7）设计的粒度要适当。设计不是编码，即使在详细设计阶段，设计模型的抽象级别也比源代码要高，它涉及的是模块内部的实现算法和数据结构。因此，不要用具体的程序代码取代设计。（8）在设计时就要开始评估软件的质量。软件的质量属性需要在设计时考虑如何实现，不要等全部设计结束之后再考虑软件的质量。（9）设计评审。总体设计评审主要是评审软件的总体框架结构，详细设计评审是检查模块内部实现算法的正确性。设计评审的目的是减少设计引入的错误。影响设计的因素多人合作的配合问题；每个设计人员的经验、水平等；软件使用者的文化背景、价值观等5.3软件设计的概念

模块模块化独立性抽象信息隐藏5.3.1模块一般把用一个名字就可调用的一段程序称为“模块”。模块具有三个基本属性：功能：即指该模块要完成的任务。逻辑：即描述模块为了完成任务，模块内部怎么做。状态：即使用该模块时的环境和条件。

按模块的外部特性和内部特性来分别描述。外部特性：指模块名、模块的输入/输出参数内部特性：完成功能的程序代码和尽供该模块内部使用的数据。5.3.2模块化模块化就是把整个系统划分成若干个模块，每个模块完成一个子功能，将多个模块组织起来实现整个系统的功能。模块化设计方法强调的是清楚地定义每个模块的功能和它的输入/输出参数，而模块的实现细节隐藏在各自的模块之中，与其它模块之间的关系可以是调用关系，因此，模块化程序易于调试和修改。随着模块规模的减小，模块的开发成本减少，但是模块之间的接口变得复杂起来，使得模块的集成成本增加。

5.3.3模块独立性

耦合：指模块间相互关联的程度。它取决于:（1）一个模块对另一个模块的调用；

（2）一个模块向另一个模块传递的数据量；

（3）一个模块施加到另一个模块的控制的多少；

（4）模块之间接口的复杂程度。在设计软件时应追求尽可能松散耦合的系统。因为对这类系统中任一模块的设计、测试和维护相对独立。由于模块间联系较少，错误在模块间传播的可能性也随之变小。（1）内容耦合(ContentCoupling)

如果发生下列情形，两个模块之间就发生了内容耦合

(1)一个模块直接访问另一个模块的内部数据;

(2)一个模块不通过正常入口转到另一模块内部;

(3)两个模块有一部分程序代码重迭

(只可能出现在汇编语言中);

(4)一个模块有多个入口。

c

（2）公共耦合的复杂程度随耦合模块的个数增加而显著增加。若只是两模块间有公共数据环境，则公共耦合有两种情况。松散公共耦合和紧密公共耦合。

公共耦合（CommonCoupling）

若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。（3)外部耦合（ExternalCoupling）

一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息，则称之为外部耦合。(4)控制耦合(ControlCoupling)

如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能，就是控制耦合。(5)数据结构耦合一个模块访问另一个模块时，彼此之间是通过传递控制参数、公共数据结构或外部变量来交换输入、输出信息的，则称这种耦合为数据结构耦合。

(6)数据耦合(DataCoupling)

如果一个模块访问另一个模块时，彼此之间是通过简单数据参数

(不是控制参数、公共数据结构或外部变量)来交换输入、输出信息的，则称这种耦合为数据耦合。

(7)非直接耦合(NondirectCoupling)

如果两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的，这就是非直接耦合。这种耦合的模块独立性最强。降低耦合度的方法1、少使用类的继承，多用接口隐藏实现的细节。java面向对象编程引入接口除了支持多态外，隐藏实现细节也是其中一个目的。

2、模块的功能化分尽可能的单一，道理也很简单，功能单一的模块供其它模块调用的机会就少。

3、遵循一个定义只在一个地方出现。

4、少使用全局变量。

5、类属性和方法的声明少用public，多用private关键字。

6、多用设计模式，比如采用MVC的设计模式就可以降低界面与业务逻辑的耦合度。

7、尽量不用“硬编码”的方式写程序，同时也尽量避免直接用SQL语句操作数据库。

8、最后当然就是避免直接操作或调用其它模块或类（内容耦合）；如果模块间必须存在耦合，原则上尽量使用数据耦合，少用控制耦合，限制公共耦合的范围，避免使用内容耦合。模块内聚内聚：衡量一个模块内部各个元素彼此结合的紧密程度。一般说来模块的内聚度越紧密越好,以保证模块功能的单一性,模块的独立性好。（1）功能内聚(FunctionalCohesion)

一个模块中各个部分都是完成某一具体功能必不可少的组成部分，或者说该模块中所有部分都是为了完成一项具体功能而协同工作，紧密联系，不可分割的。则称该模块为功能内聚模块。（2）信息内聚(InformationalCohesion)

这种模块完成多个功能，各个功能都在同一数据结构上操作，每一项功能有一个唯一的入口点。这个模块将根据不同的要求，确定该执行哪一个功能。由于这个模块的所有功能都是基于同一个数据结构（符号表），因此，它是一个信息内聚的模块。信息内聚模块可以看成是多个功能内聚模块的组合，并且达到信息的隐蔽。即把某个数据结构、资源或设备隐蔽在一个模块内，不为别的模块所知晓。（3）通信内聚(CommunicationCohesion)

如果一个模块内各功能部分都使用了相同的输入数据，或产生了相同的输出数据，则称之为通信内聚模块。通常，通信内聚模块是通过数据流图来定义的。（4）过程内聚（ProceduralCohesion）

使用流程图做为工具设计程序时，把流程图中的某一部分划出组成模块，就得到过程内聚模块。例如，把流程图中的循环部分、判定部分、计算部分分成三个模块，这三个模块都是过程内聚模块。（5）时间内聚（ClassicalCohesion）

时间内聚又称为经典内聚。这种模块大多为多功能模块，但模块的各个功能的执行与时间有关，通常要求所有功能必须在同一时间段内执行。例如初始化模块和终止模块。（6）逻辑内聚（LogicalCohesion）

这种模块把几种相关的功能组合在一起，每次被调用时，由传送给模块的判定参数来确定该模块应执行哪一种功能。（7）巧合内聚（CoincidentalCohesion）

巧合内聚又称为偶然内聚。当模块内各部分之间没有联系，或者即使有联系，这种联系也很松散，则称这种模块为巧合内聚模块，它是内聚程度最低的模块。5.3.4抽象所谓抽象就是将事物的相似方面集中和概括起来，暂时忽略它们之间的差异。或者说抽象就是抽出事物的本质特性而暂时不考虑它们的细节。Wasserman抽象思想（1）功能分解法：将功能分配到各个软件模块上。自顶向下，逐层分解。（2）面向数据的分解法：基于数据结构的，顶层是整体结构，底层描述具体的元素和他们之间的关系。（3）面向事件的分解法：基于系统必须处理的事件。讨论触发的事件的条件，事件发生后引起的系统状态变化，新状态触发的事件等。Wasserman抽象思想（4）由外向内的设计：这种黑盒方法是基于系统的输入/输出。顶层列出所有可能的输入/输出，而较低层次描述的是对于这些输入及可能产生的输出，系统要做什么。（5）面向对象的设计：将对象、类和之间的相互关系关联起来。顶层是每一个对象类型的描述，而较低层次上描述对象的属性、行为，以及对象之间的关系。5.3.5信息隐藏应用模块化原理时，一个重要原则就是将信息尽量隐藏在相应的处理模块中。信息隐藏的技术最早是由Parnas提出的。核心内容是：一个模块中所包含的信息，不允许其他不需要这些信息的模块访问。通常有效的模块化可以通过定义一组相互独立的模块来实现，这些独立的模块彼此间仅仅交换那些为完成相应功能而必须交换的信息。

局部化局部化是指把一些关系密切的软件元素物理地彼此靠近放置在一个局部的环境中。局部化概念有助于实现信息隐藏，例如，通过在模块内部定义局部数据结构，使得模块内的数据结构及其定义在该数据结构上的处理对其它模块来说是不可见的。

5.3.6设计复用在设计一个新系统时会发现有一些功能与以前建立的系统中的功能很相似。有许多项目小组在设计和开发软件时，将一些公共的、常用的功能设计成独立的模块，当进行下一个类似的系统开发时，就可以复用这些设计结构。

5.4软件结构图

该图常用来表示系统的软件结构。利用它可以清楚地表达软件结构中模块间的层次调用关系和模块之间的联系。目标系统的DFDSD目标系统的SC结构图的主要元素(1)模块——表明功能。用矩形表示模块，用双边矩形表示现成的模块。（2）模块的调用关系和接口——用单向箭头表示。

(a)模块调用关系 b)模块间接口的表示（3）模块间的信息传递——数据和控制信息，尾端带有菱形的短箭头表示数据信息，尾端带有实心圆的短箭头表示控制信息。（4）两个辅助信号——有条件调用时，在箭头尾部标以一个菱形号，多次调用时在箭头尾部标以弧线。结构图的主要元素结构图的形态特征软件的深度（depth）—控制的层数；软件的宽度（width）—其控制的层数和跨度；模块的“扇出数”（fan‑out）—该模块直接控制的其他模块数；模块的“扇入数”（fan‑in）指能直接控制该模块的模块数。下图深度5，宽度7，模块M扇出数3，模块T扇入数4.图书管理系统软件结构图5.5结构化设计方法结构化设计方法:把数据流图变换成软件结构。（1）研究、分析和审查数据流图。（2）根据数据流图决定问题类型是变换型还是事务型。（3）由数据流图推导出系统的初始结构图（4）利用以下启发式原则来改进系统的初始结构图，直到得到符合要求的结构图为止。（5）修改和补充数据字典（6）制定测试计划。5.5.1数据流的类型

4种类型的模块：传入模块、传出模块，变换模块和协调模块。变换模块─它从上级模块取得数据，进行特定的处理，转换成其它形式，再传送回上级模块。它加工的数据流叫做变换数据流。协调模块─对所有下属模块进行协调和管理的模块。

4种类型的模块1.变换流变换型数据处理问题的工作过程大致分为三步，即取得数据，变换数据和给出数据。相应地，变换型系统结构图由逻辑输入、中心变换和逻辑输出等三部分组成。输出E取得AIPO1A变换成BIPO3计算IPO4D变换成EIPO2B变换成C2.事务流它接受一项事务，根据事务处理的特点和性质，选择分派一个适当的处理单元，然后给出结果。在事务型系统结构图中，事务中心模块按所接受的事务的类型，选择某一事务处理模块执行。各事务处理模块并列。每个事务处理模块可能要调用若干个操作模块，而操作模块又可能调用若干个细节模块。5.5.2变换分析1.重画数据流图。从物理输入、物理输出及变换中心进行由顶向下的分解得出各个分支的所有组成模块2.再数据流图上区分系统的逻辑输入、逻辑输出及中心变换部分。3.进行一级分解，设计上层模块和第1层关键是找出树形结构图的根或者顶层模块。方法：顶层模块：其功能就是整个系统的功能；输入控制模块：接收所有的输入数据；变换控制模块：实现输入到输出的变换；输出控制模块：产生所有的输出数据。顶层模块输出控制变换控制输入控制变换分析的第一级分解4.设计软件结构的第2层进行二级分解，设计输入、输出和中心变换部分的中、下层模块。二级分解的任务是把数据流图中每个处理框映射为结构图中的一个模块。过程是从变换中心的边界开始沿输入、输出通道向外移动；从变换中心的输入(出)边界向外移动，把遇到的每个处理框映射为结构图中相应控制模块下的一个模块。

变换型软件结构图

5.5.3事务分析事务分析也是从分析数据流图开始，自顶向下，逐步分解，建立系统结构图。所不同的是由数据流图映射成的系统结构图不同。事务分析的步骤1：复审基本系统模型。

2：复审和细化软件的数据流图。

3：确定数据流图中含有变换流特征还是含有事务流特征。以上三步与变换分析中的相应工作相同。4：识别事务中心和每一条操作路径上的流特征。事务中心通常位于几条操作路径的起始点上，可以从数据流图上直接找出来。输入路径必须与其他所有操作路径区分开来。

5.6图书管理信息系统软件结构设计我们仔细研究这些数据流程图，发现一个图书管理信息系统可以分为五个子系统设计：读者信息管理子系统借书子系统还书子系统采编子系统和系统维护子系统进入设计阶段后，要从软件设计的角度重审数据流程图。（1）首先应该为流通组设计一个方便的工作环境，在这个工作环境之中包含了流通组日常要做的所有工作，为此，应该增加一个“还书工作环境”的处理，编号IPO320。（2）“还书工作环境”处理之后应该是流通组门的业务分发处理，所以增加一个“事务分发”处理，编号为IPO321。（3）在处理完某个具体的还书业务之后，有可能导致“通知预约”处理的执行，而“催还”和“通知预约”两个处理之中都隐含了一个共同的处理“发送邮件”，因此，应该将具有相同功能的处理独立成为一个“发送邮件”的处理，编号为IPO324。（4）丢失、破损、超期处罚操作属于性质相同的处理，应该将它们归并在一起。每种处罚的规则和处理不同，因此，增加了一个“处罚事务分发”处理，这个处理中首先判断不同的处罚类型，根据用户选择的类型转去执行相应的处理。（5）每种处罚处理的用户界面不同，因此，分别为三种处罚类型设计了不同的用户界面。接下来是各自的处罚处理操作，最终的处罚结果是保存在一个数据库表中，因此，调用同一个“保存处罚记录”处理。在整个处罚的处理部分，基本上是按照逻辑输入、处理、逻辑输出划分的。另外增加了两个界面处理，这是为了将用户界面与业务处理分开来设计和实现，便于系统的维护和修改。下面是修改后的数据流程图：

还书数据流程图5.6.2整理数据流图将从数据存储读的数据流可视为逻辑输入从处理写入数据存储的数据流视为逻辑输出。整理后的数据流图如图5-16所示。5.6.3确定事务中心还书子系统的事务处理中心为“事务分发”。从它引出两条处理线路，每条事务处理线路都包括信息输入和事务处理。5.6.4确定软件结构首先画出系统的顶层和第1层还书子系统第2层设计还书子系统部分结构设计还书子系统结构图后台程序5.7优化软件设计

软件结构优化

优化有时间要求的软件

走查软件结构图

用快速原型法修正设计

关于设计的说明

5.7.1软件结构优化规则一：模块功能完善化。一个完整的功能模块，不仅能够完成指定的功能，而且还应当能够向调用者返回完成任务的状态，以及失败的原因。上述所有内容，都应当看做是一个模块的有机组成部分，不应分离到其他模块中去，否则将会增大模块间的耦合程度。软件结构优化续规则二：设计功能单一和结果可预测的模块。一个功能单一和结果可预测的模块可以被看成是一个“黑箱”，不论内部处理细节如何，对于相同的输入数据，总能产生同样的结果。但是，如果模块内部蕴藏有一些特殊的鲜为人知的功能时，其模块的结果可能无法预测。软件结构优化续规则三：消除重复功能，改善软件结构。应当认真审查初始的软件结构图，如果发现几个模块的功能有相似之处，应该加以改进。但是，如果两个模块的功能只是局部相似时，最好不要简单地合二为一，因为这种简单的并后会造成模块内部设置许多判断开关，模块的接口参数势必会传递一些控制信息，造成模块内聚降低。通常的处理办法是分析两个相似的模块，找出相同的部分，然后将相同的部分从分离出去组成一个新的模块。

软件结构优化续规则四：模块的作用范围应在控制范围之内。首先定义一个模块的控制范围是：是这个模块及其所有下属模块。例如图中模块E的控制范围是I、H、J。一个模块的作用范围是：这个模块内判定的作用范围，凡是受这个判定影响的模块都属于这个判定的作用范围。例如图中模块J的一个判定传递给E模块，然后再传递给I和H模块，这时模块J的作用范围是模块E、I、J。显然，这种设计是不好的，因为模块I和H不是模块J的控制范围，这样就导致模块之间传递的是控制参数，使模块之间的耦合增加。J软件结构优化续如果在设计过程中，发现作用范围不在控制范围内，可采用如下办法把作用范围移到控制范围之内：１）提高控制模块的层次。将判定所在模块合并到父模块中，使判定处于较高层次。２）将受判定影响的模块下移到控制范围内；３）将判定上移到层次中较高的位置。但是要注意，判定所在的模块最好不要太高，模块之间的控制参数传递路径太长，增加了模块之间的耦合。比较好的方案是将判定提到模块E中。软件结构优化续规则五：模块的大小要适中。模块的大小一般用模块的源代码数量来衡量，通常在设计过程中，将模块的源代码数量限制在５０～１００左右，即一页纸的范围内，这样阅读比较方便。实际上，规模大的模块往往是由于分解不充分造成的，应该对其进一步分解，生成一些下级模块或同层模块。软件结构优化续有些模块规模非常小，这种情况下要区别对待，如果该模块是公共模块或者是高内聚模块，则一定不要把它合并到其他模块中去；否则可以考虑将规模很小的模块合并到其它相关的模块中。

软件结构优化续规则六：尽可能减少高扇出和高扇入的结构。规则七：将模块中相对变化较大的部分剥离出去。为了加强模块的可复用性，在设计时将模块中相对稳定的部分与可能变化的部分分离，在分离的两个模块之间加一个接口模块对模块之间传递的参数进行整理，这对保持模块的稳定性和可重用性有很大作用。5.7.2优化有时间要求的软件

对于有时间要求的软件结构，在整个设计阶段和编码阶段都必须进行优化，优化的方法如下：1)

首先改进软件的结构。2)

在细节设计的过程中，挑出那些有可能占用过多时间的模块，并为这