软件工程中结构化设计方法

软件工程的基本思想是面对复杂的问题，让软件的开发按照工程的概念、原理、技术和方法模式来实施，有计划地按照要求分阶段实现。针对大型项目开发，为了保证软件产品质量，提高软件开发效率，在进行详细设计、程序设计之前，必须先确定软件总体结构。软件总体结构设计的方法主要有结构化设计、面向数据结构的设计和面向对象的设计，其中结构化设计方法是应用最广泛的一种，它是建立良好程序结构的方法，提出了衡量模块质量的标准是“高内聚、低耦合”。另外，结构化设计（StructuredDesign，SD）方法是一种面向过程的设计方法或面向数据流的设计方法，它可以与结构化分析（StructuredAnalysis，SA）方法、结构化程序设计（StructuredProgramming）方法前后呼应，形成了统一、完整的系列化方法。结构化设计方法以需求分析阶段获得的数据流图为基础，通过一系列映射，把数据流图变换为软件结构图。

本文引用地址：http://www.amcfsurvey.com/article/148151.htm

1数据流的类型

在需求分析阶段，用SA方法产生了数据流图。结构化的设计能方便地将数据流图（DataFlowDiagram，DFD）转换成软件结构图。DFD中从系统的输入数据流到系统的输出数据流的一连串连续变换形成了一条信息流。根据数据流类型不同，可分为变换型和事务型2类，事务型和变换型数据流的设计步骤基本是大同小异，它们之间主要差别就是从数据流图到软件结构的映射方法不同。因此，在进行软件结构设计时，首先对数据流图进行分析，然后判断属于那一种类型，根据不同的数据流类型，通过一系列映射，把数据流程图转换为软件结构图。基本流程见图1.

1.1变换型数据流

信息在沿着输入通路进入系统，同时由外部形式变换成内部形式进入系统的信息，通过变换中心经加工处理，以后再沿着输出通路变换成外部形式离开系统。当数据流具有了信息流的这种特征时这种信息流就叫作变换型数据流。变换型数据流的DFD可明显地分为三大部分：逻辑输入、变换中心（主加工）、逻辑输出。变换型数据流结构见图2.逻辑输入：可以从数据流图上的物理输入开始，一步一步向系统中间移动，一直到数据流不再被看作是系统的输入为止，则其前一个数据流就是系统的逻辑输入。可以认为逻辑输入就是离物理输入端最远的，且仍被看作是系统输入的数据流。变换中心：多股数据流汇集的地方往往是系统的中心变换部分。

逻辑输出：从物理输出端开始，一步一步地向系统中间移动，就可以找到离物理输出端最远，且仍被看作是系统输出的数据流。

图1数据流程图转换为软件结构图基本流程

图2变换型数据流结构

1.2事务型数据流

信息在沿着输入通路进入系统，由外部形成内部形式后到达事务中心。通常事务中心位于几条处理路径的起点，从数据流程图上很容易标识出来，因为事务处理中心一般会有“发射中心”的特征。因为事务流有明显的事务中心，所以各式各样活动流都以事务中心为起点呈辐射状流出。事务型数据流结构见图3.

图3事务型数据流结构

事务中心主要完成下述任务：接收输入数据（输入数据又称为事务）；分析每个事务以确定它的类型；根据事务类型选取一条活动通路。通常，事务中心前面的部分叫作接收路径，发射中心后面各条发散路径叫作事务处理路径。对于每条处理路径来讲，还应该确定它们自己的流特征。

2映射过程

任何一个设计过程都不是统一、固定不变的，设计的要求越高，往往需要设计者在方法上不但具有超强的判断能力还要有规则性的创造精神。根据不同类型，分析其映射过程。

2.1变换型数据流到软件结构图映射

（1）设计软件结构的顶层和第1层。设计一个主模块，并用系统的名字为它命名，作为系统的顶层。第1层为每个逻辑输入设计一个输入模块，它的功能是为主模块提供数据；为每一个逻辑输出设计一个输出模块，它的功能是将主模块提供的数据输出；为中心变换设计一个变换模块，它的功能是将逻辑输入转换成逻辑输出。主模块控制和协调第1层的输入模块、变换模块和输出模块的工作。

（2）设计软件结构的下层结构。每个逻辑输入模块有2个下属模块：一个接收数据；另一个把数据变换成上级模块所需要的数据格式。而接收数据模块又是输入模块，又要重复上述工作。如此循环下去，直到输入模块已经涉及到物理输入端为止。同样，每个逻辑输出模块有2个下属模块：一个是将上级模块提供的数据变换成输出的形式；另一个是将它们输出。对于每一个逻辑输出，在数据流程图上向物理输出端方向移动，遇到物理输出为止。设计中心变换模块的下层模块没有通用的方法，一般应参照数据流程图的中心变换部分和功能分解的原则来考虑如何对中心变换模块进行分解。

变换型数据流转换后的初始软件结构图见图4.

图4变换型数据流转换后的初始软件结构图

2.2事务型数据流到软件结构图映射

事务型数据处理问题的工作机理是接受一项事务，根据事务处理的特点和性质，选择分派一个适当的处理单元，然后给出结果。

（1）设计软件结构的顶层和第1层。软件结构图的顶层是系统的事务控制模块。第1层是由事务流输入分支和事务分类处理分支映射得到的程序结构。也就是说，第1层通常是由两部分组成：取得事务和处理事务。

（2）设计软件结构的下层结构。设计事务流输入分支的方法与变换分析中输入流的设计方法类似，从事务中心变换开始，沿输入路径向物理输入端移动。每个接收数据模块的功能是向调用它的上级模块提供数据，它需要有两个下属模块：一个接收数据；另一个把这些数据变换成它的上级模块所需要的数据格式。接收数据模块又是输入模块，也要重复上述工作。如此循环下去，直到输入模块已经涉及到物理输入端为止。

事务处理分支结构映射成一个分类控制模块，它控制下层的处理模块。对每个事务建立一个事务处理模块。如果发现在系统中有类似的事务，就可以把这些类似的事务组织成一个公共事务处理模块。但是，如果组合后的模块是低内聚的，则应该重新考虑组合问题。

事务中心模块按所接受的事务的类型，选择某一个事务处理模块执行。每个事务处理模块可能要调用若干个操作模块，而操作模块又可能调用若干个细节模块。不同的事务处理模块可以共享一些操作模块。不同的操作模块又可以共享一些细节模块。事务型数据流转换后的初始软件结构图见图5.

图5事务型数据流转换后的初始软件结构图

2.3变换－事务混合型的系统结构图

一般来讲，一个大型项目不可能是单一的数据变换型，也不可能是单一的事务型，通常是变换型数据流和事务型数据流的混合体。在具体的应用中一般以变换型为主，事务型为辅的方式进行软件结构设计。变换－事务混合型的系统结构图见图6.

图6变换－事务混合型的系统结构图

3软件结构设计的图形工具

结构化设计主要有两种图形工具：结构图和层次图。结构图和层次图基本上是大同小异，都是用来描述软件结构的图形工具，图中设有很多方框，一个方框就代表一个模块，框内注明模块的名字或主要功能；方框之间的箭头（或直线）用来表示模块的调用关系。二者描述重点不一样。

3.1结构图

结构图主要描述软件结构中模块之间的调用关系和信息传递问题。基本成分有模块、调用和数据。

在通常情况下会在结构图中用箭头注释一下表示模块在调用过程中信息的来回传递。可以根据箭头的尾部形状标明某种信息，认定一种形状作为一种信息符号，自己只要按箭头形状就可以区分传递的信息是数据还是控制信息了。比如：尾部是空心圆就表示传递的是数据，实心圆就表示传递的是控制信息。结构图不仅仅只是一些基本符号，其实还有不少附加符号，用来表示模块的选择调用或循环调用的。

3.2层次图

层次图主要描述软件系统的层次结构以及各个功能的隶属关系，特别适合于自顶向下设计使用。在层次图里除顶层之外，每个方框里都加编号，记录它所在的层次及在该层次的位置。一般最上层的模块含有退出、输入、处理、输出、查询和系统维护模块。根据系统的具体要求，下层再将功能进一步细化。

层次图和结构图对于模块调用次序方面要求的并不严格。在画模块方面，很多人习惯按调用次序从左到右的方法画模块，其实又没有规定一定要这样，出于其他方面的考虑（例如为了减少交叉线），完全可以不按这种次序画，还有就是在层次图和结构图中并不指明什么时候调用下层模块。一般情况下上层模块中除了调用下层模块的语句之外还有其他语句，到底是先执行调用下层模块的语句还是先执行其他语句，丝毫不在图中指明。事实上，层次图和结构图往往只表明一个模块用来调用哪些模块，对于一些模块内不含其他成分的根本就不作表示。

4软件结构设计优化规则

数据流程图转换为初始软件结构图后，按照高内聚低耦合、模块化、信息隐藏的原则，应该对初始软件结构图进行优化。考虑设计优化问题时应该记住，“一个不能工作的‘最佳设计’的价值是值得怀疑的”。软件设计人员应该致力于开发能够满足所有功能和性能要求，导出不同的软件结构，对它们进行评价和比较，力求得到“最佳”的效果，这种优化真正的优点，就是能够把软件结构设计和详细设计很好地分开。通常，用下述方法对初始化软件结构进行优化是合理的：在不考虑时间因素的前提下开发并精化软件结构。在得到初始的功能结构图之后，如果发现有几个模块有相似之处，可消除重复功能，改善软件结构；模块功能的完善化。一个完整的功能模块，不仅应能完成指定的功能，而且还应当能够告诉使用者完成任务的状态，以及不能完成的原因；模块的作用范围应在控制范围之内。模块的控制范围包括它本身及其所有的从属模块；模块的作用范围是指模块内一个判定的作用范围，凡是受这个判定影响的所有模块都属于这个判定的作用范围；尽可能减少高扇出结构。模块的扇出过大，将使得系统的模块结构图的宽度变大，宽度越大结构图越复杂。模块的扇出过小也不好，这样将使得系统的功能结构图的深度大大增加，不但增加了模块接口的复杂度，而且增加了调用和返回的时间开销，降低系统的工作效率。比较适当的模块扇出数目为2～5个，最多不要超过9个；模块的大小要适中。限制模块的大小是减少复杂性的手段之一，因而要求把模块的大小限制在一定的范围之内。模块的大小一般用模块的源代码数量来衡量，通常在设计过程中，将模块的源代码数量限制在50～100行左右，即一页纸的范围内，这样阅读比较方便；设计功能可预测的模块，避免过分受限制的模块。一个功能可预测的模块不论内部处理细节如何，但对相同的输入数据，总能产生同样的结果；软件包应满足设计约束和可移植性。一个仅处理单一功能的模块，由于具有高度的内聚性，而受到了设计人员的重视。