第三章 结构化方法

第三章 结构化方法

结构化方法作为一种“思想”工具，可用于定义需求，建立待建系统的功能模型；可用于定义满足需求的结构，给出一种特定的软件解决方案。

3.1 结构化需求分析

在进行软件系统/产品的需求工作中，通常面临三大挑战。

（1）问题空间理解。

（2）人与人之间的通信。

（3）需求的变化性。

为了应对以上三大挑战，支持需求工作目标的实现，一种好的需求技术应该具有以下基本特征：

1）提供方便通信的机制

2）鼓励需求分析人员使用问题空间的术语思考问题，编写文档

3）提供定义系统边界的方法

4）提供支持抽象的基本机制

5）为需求分析人员提供多种可供选择的方案

6）提供特定的技术，适应需求的变化等

3.1.1 基本术语

1.数据流

数据流是一类术语，用于表达在分析中所要使用的、用于表达“客体”的信息。在使用中一般要给出标识，该标识是一个名词或名词短语，并且往往直接使用实际问题空间中的概念。

2.加工

加工也是一类术语，用于表达在分析中使用的、用于表达“处理”的信息。在使用中一般也要给出标识。该标识一般采用动宾结构，并且往往直接使用实际问题空间中的概念，以便表达该加工的一定语义。

3.数据存储

数据存储也是一类术语，用于表达在分析中所使用的、表达“结构化客体”的信息。在使用中一般也要给出标识。

该标识是一个名词或名词短语，并且往往直接使用实际问题空间中的概念。这样的标识可以表达该结构化数据的“一定”语义。

4.数据源和数据潭

数据源是数据流的起点；数据潭是数据流的归宿地。数据源和数据潭是系统之外的实体，可以使人、物或其它软件系统。他们均用一个矩形表示。

引入数据源和数据潭这两个术语的目的是为了表示系统的环境，可以使用它们和相关的数据流来定义系统的边界。

与其他术语一样，在使用这两个术语来表达系统/产品“边界”的信息时，也要给出相应的标识。

该标识也是一个名词或名词短语，并且往往直接使用实际问题空间中的概念。这样的表示可以表达系统/产品边界的“一定”语义。

3.1.2 系统功能模型表示

需求分析的首要任务是建立系统功能模型，为此结构化分析方法给出了一种表达功能模型的工具，即数据流图（Dataflow Diagram），简称DFD图。

如果把任何软件系统都视为一个数据变换装置，它接受各种形式的输入，通过变换产生各种形式的输出，那么数据流图就是一种表达待建系统功能模型的工具。

3.1.3 建模过程

为了支持系统地使用信息来创建系统功能模型，结构化分析方法给出了建模的基本步骤。该过程属于“自顶向下，功能分解”形式。

1.建立系统环境图，确定系统语境

2.自顶向下，逐步求精，建立系统的层次数据流图

为了便于管理，从0层开始就要对数据流图以及其中的加工进行编号，并在整个系统中应是惟一的。一般按下述规则为分层数据流图和图中的加工进行编号的。

1）顶层数据流图以及其中惟一的加工均不必编号。

2）由于0层通常只有一个子图，因此，该子图的层号为0，而其中每一加工的编号分别为0.1，0.2，0.3……。

3）以后各层，其子图层号为上一层（父层）的加工号；而该层中加工编号为子图层号，后跟一个小数点，再加上该加工在子图中的顺序号，例如1.1，1.2，1.3……，即加工编号由相应的子图号、小数点、加工在子图中的顺序号组成。

由“父图”生成“子图”的一般步骤如下：

1）将“父图”的每一加工按其功能分解为若干个子加工。

2）将“父图”的输入流和输出流“分派”到相关的子加工

3）在各加工之间建立合理的关联，必要时引入数据存储，使之形成一个有机的整体

3.定义数据字典

该步的目标为依据系统的数据流图，定义其中包含的所有数据流和数据存储的数据结构，直到给出构成以上数据的各数据项的基本数据类型。

数据是客体的一种表示，而且已经证明，所有客体均可用以下3种基本结构表示，这3中结构分别为顺序结构、选择结构和重复结构。

表3-1 定义数据结构的符号

符号	描述	符号	描述
=	定义为	{  }	重复
+	顺序	m..n	子界
[ | ]	选择

在数据字典中，为了使定义的结构数据便于理解和阅读，一般按3中条目来组织，即数据流条目、数据存储条目和数据项条目。

其中数据流条目给出DFD图中所有数据流的结构定义；数据存储条目给出DFD图中所有数据存储的结构定义；数据项条目给出所有数据项的类型定义。

4.描述加工

该步的目标为依据系统的数据流图，给出其中每一加工的小说明。由于需求分析的目的是定义问题，因此对DFD图中的每一加工只需要给出加工的输入数据和输出数据之间的关系，即从外部来“视察”一个加工的逻辑。

描述加工采用的3种表达工具：

（1）结构化自然语言。

如果一个加工的输入数据和输出数据之间的逻辑关系比较简单，可以使用结构化自然语言予以表述。

结构化自然语言是介于形式语言和自然语言之间的一种语言。它虽然没有形式语言那样严格，但具有自然语言简单易懂的特点，同时又避免了自然语言结构松散的特点。

结构化自然语言的语法通常分为内外两层，外层语法描述操作的控制结构，如顺序、选择、循环等，这些控制结构将加工中的各个操作连接起来。内层语法没有什么限制，一般使用自然语言描述。

（2）判定表

如果一个加工的输入数据和输出数据之间的逻辑关系比较复杂，可以采用一定的表达工具，例如判定表或判定树等，以避免产生不一致的理解。

判定表是用以描述加工的一种工具，通常用来描述一些不易用自然语言表达清楚或需要很大篇幅才能表达清楚的加工。

当描述的加工由一组操作组成，而且是否执行某些操作或操作的执行情况又取决于一组条件时，用判定表来描述这样的加工就是比较合适的。

（3）判定树。判定树也是一种描述加工的工具。

3.1.4 应用中注意的问题

以上几种讲解了建立系统功能模型的结构化分析方法，但在实际应用中，必须按照数据流图中所有图形元素的用法正确使用。例如：一个加工必须既有输入又有输出；必须准确地定义数据流和数据存储；必须准确地描述每一个叶加工，说明输入数据流与输出数据流之间的逻辑关系。

另外还应注意下面的一些问题。

（1）模型平衡问题

1）系统DFD中每个数据流和数据存储都要在数据字典中予以定义，并且数据名一致。

2）系统DFD中最底层的加工必须在小说明中予以描述，并且加工名一致。

3）父图中某加工的输入/输出（数据流）和分解这个加工的子图的输入/输出（数据流）必须保持一致，特别是保持顶层输入数据流和输出数据流在个数上，在标识上均是一样的。

4）在加工小说明中，所使用的数据流必须是在数据字典中定义的，并且名字是一致的。

（2）信息复杂性控制问题

1）上层数据流可以打包，打包数据以*号做一特殊标记。上、下层数据流之间的对应关系通过数据字典予以描述。

2）为了便于人的理解，把一幅图中的图元个数尽量控制在7±2个以内

3）检查与每个加工相关的数据流，是否有太多的输入/输出数据流，并寻找可降低该加工接口复杂性的、对数据流进行划分的方法（有时一个加工有太多的输入/输出数据流与同一层得起头加工或抽象层次有关）。

4）分析数据内容，确定是否所有的输入信息都用于产生输出信息；相应地，由一个加工产生的所有信息是否都能由进入该加工的信息导入。

根据以上关于结构化分析方法的介绍和实例研究，我们可以得出以下几点：

1）该方法看待客观世界的基本观点是：信息系统是由一些信息流构成的，其功能表现为信息在不断地流动，并经过一系列的变换，最终产生人们需要的结果。

2）抽象和分解是结构化分析方法采用的两个基本手段

3.1.5 需求验证

大量统计数字表明，软件系统中15%的错误起源于错误的需求。

一般来说，需求验证应验证需求规格说明书中的每一单一需求是否满足5个性质，即必要性、无歧义性、可测性、可跟踪性、可测量行；验证需求规格说明是否满足4个性质，即重要性和稳定性程度、可修改性、完整性和一致性。

3.2 结构化设计

结构化设计的主要任务是在需求分析的基础上，定义满足需求所需要的结构，即针对给定的问题，给出该问题的软件解决方案，确定“怎么做”的问题。

为了控制软件设计的复杂性，结构化设计又进一步分为总体设计和详细设计。其总体设计的目标是建立系统的模块结构，及系统实现所需要的软件模块——系统中可标识的软件成分，以及这些模块之间的调用关系。

3.2.1 总体设计

1.总体设计的目标及其表示

结构化方法在总体设计中引入两个基本概念：一是模块，即指软件中具有特定标识的独立成分；二是模块调用，即指模块之间的一种使用关系。

总体设计阶段的基本任务是把系统的功能需求分配到一个特定的软件体系结构中。表达这一软件体系结构的工具很多，主要有以下几种。

（1）Yourdon提出的模块结构图。

（2）层次图。层次图主要用户描绘软件的层次结构。

（3）HIPO图，HIPO是由美国IBM公司提出的，其中HIPO是“层次图+输入/处理/输出”的英文缩写。

2.总体设计步骤

如何将需求分析所得到的系统DFD图映射为设计层面上的模块和模块调用，这是结构化设计方法所要回答的问题。为此，该方法在分类DFD的基础上，基于自顶向下、功能分解的设计原则，定义了两种不同的“映射”，即变换设计和事务设计。其基本步骤是，首先将系统的DFD图首先转化为初始的模块化结构图，再基于“高内聚低耦合”这一软件设计原理，通过模块化，将初始的模块结构图转换为最终的、可供详细设计使用的模块结构图（MSD）。

通过大量挼你安开发的实践，人们发现，无论待建系统的数据流图如何复杂，一般总可以把她们分成两种基本类型，即变换型数据流图和事务性数据流图。

（1）变换型数据流图。具有较明显的输入部分和变换（或称主加工）部分之间的界面变换部分和输出部分之间界面的数据流图，称为变换型数据流图。

（2）事务型数据流图。数据到达一个加工T，该加工T根据输入数据的值，在其后的若干动作序列（称为一个事务）中选一个来执行，这类数据流图称为事务型数据流图。

事务型数据流图所描述系统的数据处理模式为“集中-发散”式。

在实际应用中，任何软件系统从本质上来说都是信息的变换装置，因此，原则上所有的数据流图都可以归为变换型。但是，如果其中某些部分具有事务型数据流图的特征，那么就可以把这些部分按照事务型数据流图予以处理。

总体设计分为3个阶段。第一阶段为初始设计，在对给定的数据流图进行复审和精华的基础上，将其转换为初始的模块结构图。第二阶段为精化设计，依据模块“高内聚低耦合”的原则，精化初始的模块结构图，并设计其中的全局数据结构和每一模块的接口。第三阶段为复审阶段，对前两个阶段所得到的高层软件结构进行复审，必要时还可能需要对该软件结构做一些精化工作，这对软件的一些性质，特别是对软件质量的提高将产生非常大的影响。

下面分别介绍作为初始设计的变换设计和事务设计。

（1）变换设计。变换设计是在需求规约的基础上，经过一系列设计步骤，将变换型数据流图转换为系统的模块结构图。

（2）事务设计。尽管在任何情况下都可以使用变换设计奖一个系统的DFD图转换为模块结构图，但是，当数据流图具有明显的事务型特征时，也就是有一个明显的事务处理中心时，则比较适宜采用事务设计。

3.模块化及启发式规则

该步的目标是：基于模块“高内聚低耦合”的原则，提高模块的独立性。

（1）模块化。

模块是执行一个特殊任务的一个过程以及相关的数据结构。模块通常由两部分组成。一部分是接口，给出可由其他模块或例程访问的常量、变量、函数等。接口不但可用于刻画各个模块之间的连接，以体现其功能，而且还对其他模块的设计和使用者提供了一定的可见性，模块的另一部分是模块体，是接口的实现。因此，模块化自然涉及两个问题：一是如何将系统分解成软件模块，二是如何设计模块。

结构化软件设计是一种典型的模块化方法，即把一个待开发的软件分解成若干简单的、具有高内聚低耦合的模块，这一过程称为模块化。模块化是系统设计基本原理/原则之一。

1）耦合：耦合是指不同模块之间相互依赖程度的度量。高耦合（紧密耦合）是指两个模块之间存在着很强的依赖；低耦合（松散耦合）是指两个模块之间存在一定依赖；无耦合是指模块之间根本没有任何关系。

下面，按从强到弱的顺序给出几种常见的模块间耦合类型。

①　内容耦合：当一个模块之间修改或操作另一个模块的数据，或一个模块不通过正常入口而转入到另一个模块时，这样的耦合被称为内容耦合。

②　公共耦合：两个或两个以上的模块共同引用一个全局数据项，这种耦合方式被称为公共耦合。

③　控制耦合：一个模块通过接口向另一个模块传递一个控制信号，接收信号的模块根据信号值进行适当的动作，这种耦合被称为控制耦合。

④　标记耦合：若一个模块A通过接口向两个模块B和C传递一个公共参数，那么称模块B和C之间存在一个标记耦合。

⑤　数据耦合：模块之间通过参数来传递数据，则称为数据耦合。

在设计上采用以下原则：

如果模块之间必须存在耦合，就尽量使用数据耦合，少用控制耦合，限制公共耦合的范围，尽量避免使用使用内容耦合。

2）内聚：内聚是指一个模块内部各成分之间相互关联程度的度量。高内聚是指一个模块中各部分之间存在着很强的依赖；低内聚是指一个模块中各部分之间存在较少的依赖。

①　偶然内聚：如果一个模块的各成分之间基本不存在任何关系，则称为偶然内聚。

②　逻辑内聚：几个逻辑上相关的功能被放在同一模块中，则称为逻辑内聚。

③　时间内聚：如果一个模块完成的功能必须在同一时间内执行（例如，初始化系统或一组变量），但这些功能只是因为时间因素关联在一起，则称为时间内聚。

④　过程内聚：如果一个模块内部的处理成分是相关的，而且这些处理必须以特定的次序执行，则称过程内聚。

⑤　通信内聚：如果一个模块的所有成分都操作同一数据集或生成同一数据集，则称为通信内聚。

⑥　顺序内聚：如果一个模块的各成分和同一个功能密切相关，而且一个成分的输出作为另一个成分的输入，则称为顺序内聚。

⑦　功能内聚：最理想的内聚是功能内聚，模块的所有成分对于完成单一的功能都是基本的。功能内聚的模块对完成其功能而言是充分必要的。

（2）启发式原则。不论是变换设计还是事务设计，都涉及一个共同的问题，即“基于高内聚低耦合的原理，采用一些经验性的启发式规则，对初始的模块结构图进行精化，形成最终的模块结构图”。

人们通过长期的软件开发实践，总结出一些实现模块“高内聚，低耦合”的启发式规则，主要包含：

1）改进软件结构，提高模块独立性。

2）力求模块规模适中。

3）力求深度、宽度、扇出和扇入适中。

在一个软件结构中，深度表示其控制的层数。

在一个软件结构中，宽度是指同一个层次上模块总数的最大值。

模块扇出是指一个模块直接控制（调用）的下级模块数目。

如果一个模块的扇出过大，这意味着它需要控制和协调过多的下级模块，因而该模块往往具有较为复杂的语义。如果一个模块的扇出过小，则意味着该模块功能过分集中，往往是一个功能较大的模块，也会导致该模块具有复杂的语义。经验表明，一个典型的系统，其平均扇出通常是3或4（扇出的上限通常是5~9）。

一个模块的扇入表明有多少个上级模块直接调用它。扇入越大则表明共享该模块的上级模块数越多。

4）尽力使模块的作用域在其控制域之内。模块的控制域是指这个模块本身以及所有直接或间接从属于它的模块的集合。模块的作用域是指受该模块内一个判断所影响的所有模块的集合。

在一个设计很好的系统中，所有受判定影响的模块应该都从属于做出判定的那个模块，即在该模块的控制域之内。

5）尽力降低模块接口的复杂度。

6）力求模块功能可以预测。

3.2.2 详细设计

经过总体设计阶段的工作，已经确定了软件的模块结构和接口描述，可作为详细设计的一个重要输入。在此基础上，通过详细设计，具体描述模块结构图中的每一模块，即给出实现模块功能的实施机制，包括一组例程和数据结构，从而精确地定义了满足需求所规约的结构。

具体地说，详细设计又是一个相对独立的抽象层，使用的术语包括输入语句、赋值语句、输出语句、顺序语句、选择语句、重复语句等。

详细设计的目标是将总体设计阶段所产生的系统高层结构映射为以这些术语所表达的低层结构，也是系统的最终结构。

1.结构化程序设计

结构化程序设计方法是一种基于结构的编程方法，即采用顺序结构、选择结构以及重复结构进行编程，其中每一结构只允许一个入口和一个出口。

2.详细设计工具

详细设计工具通常分为图形、表格和语言3种，无论是哪类工具，对它们的基本要求都是能提供对设计的无歧义的描述，包括控制流程、处理功能、数据组织以及其他方面的实现细节等，以便在编码阶段能把这样的设计描述直接翻译为程序代码。

（1）程序流程图。程序流程图又称为程序框图。

程序流程图的主要缺点如下：

1）不是一种逐步求精的工具，它诱使程序员 过早地考虑程序的控制流程，而不去考虑程序的全局结构。

2）所表达的控制流，往往不受任何约束可随意转移，从而会影响设置破坏好的系统结构设计。

3）不易表示数据结构。

（2）盒图（N-S图）。早在20世纪70年代初，Nassi和Shneiderman出于不允许违背结构化程序设计的考虑提出了盒图，又称为N-S图。

（3）PAD图。PAD是英文“Problem Analysis Diagram”的缩写，是日本日立公司与1973年首先提出的，并得到一定程度的推广应用。PAD图采用二维树形结构来表示程序的控制流。

（4）类程序设计语言。类程序设计语言（Program Design Language，PDL）也称为伪码，在20世纪70年代至80年代，人们设计了多种PDL，它是一种用正文形式表示数据结构和处理过程的设计工具。

PDL是一种“混合”语言，一方面，PDL借用某种结构化设计语言的关键字作为语法框架，用于定义控制结构和数据结构；另一方面，PDL通常使用某种自然语言（如汉语或英语）的词汇，灵活自由地表示实际操作和判定条件。

另外，IPO图、判定树和判定表等也可以作为详细设计工具。

在完成软件设计后，应产生设计规约，完整准确地描述满足系统需求规约所要求的所有功能模块，以及伴随功能模块而出现的非功能机制。设计规约通常包括概要设计规约和详细设计规约，分别为相应设计过程的输出文档。

概要设计规约指明高层软件体系结构，其主要内容如下：

1）系统环境，包括硬件、软件接口、人机界面、外部定义的数据库及其与设计有关的限定条件等。

2）软件模块的结构，包括模块之间的接口及设计的数据流和主要数据结构等。

3）模块描述，包括模块接口定义、模块处理逻辑及必要的注释等。

4）文件结构和全局数据文件的逻辑结构，包括记录描述、访问方式以及交叉引用信息等。

5）测试需求等。

概要设计规约是面向软件开发者的文档，主要作为项目管理人员、系统分析人员与设计人员之间交流的媒体

详细设计规约是对软件各成分的内部属性的描述。它是概要设计的细化，即在概要设计规约的基础上，增加以下内容：

1）各处理过程的算法。

2）算法所涉及的全部数据结构的描述，特别是，对主要数据结构往往包括与算法实现有关的描述。

详细设计规约主要作为软件设计人员与程序员之间交流的媒体。