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

和功能分解的原则来考虑如何对中心变换模块进行分解。

变换型数据流转换后的初始软件结构图见图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行左右，即一页纸的范围内，这样阅读比较方便；设计功能可预测的模块，避免过分受限制的模块。一个功能可预测的模块不论内部处理细节如何，但对相同的输入数据，总能产生同样的结果；软件包应满足设计约束和可移植性。一个仅处理单一功能的模块，由于具有高度的内聚性，而受到了设计人员的重视。