软件工程中的结构化分析方法

结构化分析最初由Douglas Ross在20世纪60年代后期提出，由Tom De Marco进行了推广。在20世纪80年代中期由Ward和Mellor以及后来的Hatley和Pirbhai引入了实时“扩展”，形成了今天的结构化分析方法的框架。

结构化分析是一种建立模型的活动，通过数据、功能和行为模型来描述必须被建立的要素。它建立的分析模型如图3-6所示。结构化分析方法能够很好地向系统设计过渡，而且它提供的向导和支持可以帮助经验和技巧不足的人员开发高质量的系统模型。

分析模型要达到3个主要目标：描述客户的需求，建立软件设计的基础，定义在软件完成后可被确认的一组需求。

图3-6　分析模型的结构

模型的核心是数据词典，它包含了在目标系统中使用或生成的所有数据对象的描述的中心存储库。围绕这个核心有3种图：“实体-关系”图（ERD），描述数据对象及数据对象之间的关系；数据流图（DFD），指明数据在系统中移动时如何被变换，以及描述对数据流进行变换的功能（和子功能）；状态变迁图（STD），指明系统对外部事件如何响应、如何动作。

因此，ERD用于数据建模，DFD用于功能建模，STD用于行为建模。

1.数据建模

ERD使软件工程师可以使用图形符号来标识数据对象及它们之间的关系。在结构化分析的语境中，ERD定义了应用中输入、存储、变换和产生的所有数据，因此，它只关注于数据，对于数据及其之间关系比较复杂的应用特别有用。

数据模型包括3种互相关联的信息：数据对象、描述数据对象的属性、描述对象间相互连接的关系。

（1）数据对象。几乎可以表示任何被软件理解的复合信息（复合信息是指具有若干不同特征或属性的事物）。数据对象可以是外部实体、事物、角色、行为或事件、组织单位、地点或结构。它描述对象及其所有属性，只封装数据而没有包含指向作用于数据的操作的引用。这与面向对象范型中的类或对象不同。具有相同特征的数据对象组成的集合仍然称为数据对象，其中的某一个对象叫作该数据对象的一个实例。

（2）属性。定义了数据对象的特征。它可以为数据对象的实例命名，描述这个实例以及建立对另一个表中的另一个实例的引用。另外，还应把数据对象中的一个或多个属性定义为标识符以唯一标识数据对象的某一个实例。标识符属性称为键（Key）或者关键码，书写为_id，例如在“学生”数据对象中用“学号”做关键码，可唯一地标识一个“学生”数据对象中的实例。

（3）关系。数据对象可通过多种不同方式互相连接。如一个学生“刘宇”选修“数据挖掘”与“系统仿真导论”两门课程，学生与课程的实例通过“选修”关联起来。实例的关联有3种：一对一（1∶1）、一对多（1∶N）和多对多（M∶N）。这种实例的关联称为“基数”。基数是关于一个对象可以与另一个对象相关联的出现次数的规约，它表明了“重复性”。如1位教师带一个班的50位同学，就是1：N的关系，但也有1位教师带0位同学的情形，所以实例关联有“可选”和“必须”之分，用“O”表示关系是可选的，用“|”表示关系必须出现1次，三叉表示多次，如图3-7所示，该图表明了关系的“参与性”：教师是必须参与教学的，而学生则未必一定会选听某位教师的课。

图3-7　基数与参与性

基数定义了可以在一个关系中参与的对象关联的最大数目，但它没有指出一个特定的数据对象是否必须参与在关系中。为此，数据模型在“对象-关系”对中引入了形态（Modality）的概念。

（4）形态。如果对关系的出现没有显示的需要或关系是可选的，关系的形态是0。如果关系必须有一次出现，则形态是1。例如，某电信公司的区域服务软件，对于一个客户指出的一个问题，如果诊断出此问题相对简单，只进行一次简单的修理行为；如果问题很复杂，则需要多个修理行为。图3-8说明了基数和形态，以及数据对象“客户”和“修理行为”间的关系。

图3-8　基数和形态

与图3-7类似，图3-8中也建立了一个“一对多”的关系，可以向一个客户提供0个或多个修理行为。在关系连接上距数据对象矩形最近的符号指示基数：短竖线“|”表示1，三叉表示多。形态用距离数据对象矩形较远的记号表示，左边的第二个短竖线指示发生一次修理行为必须有一个客户，右边的圆圈指示对客户报告的问题类型可能不需要修理行为。

（5）“实体-关系”图（ERD）。通过ERD以图形方式表示的“实体-关系”对是数据模型的基础。ERD的主要目的是表示数据对象及其关系，它识别了一组基本成分：数据对象、属性、关系和各种类型指示符。图3-9给出学生选修课程的ERD及描述学生属性的实体对象表。

图3-9　简单的ERD和数据对象表

在图3-9中，带标记的矩形表示数据对象，连接对象的带标记的线表示关系，在有些变种中连接线还包含一个标记有关系的菱形。数据对象的连接和关系使用各种指示基数和形态的代数符号来建立。

数据模型和“实体-关系”图向分析员提供了一种简明的符号体系，以便在数据处理应用的语境中考察数据。多数情况下，数据建模方法用来创建一部分分析模型，但它也可用于数据库设计，并支持任何其他的需求分析方法。

2.功能建模和信息流

结构化分析最初是作为信息流建模基数的，基于计算机的目标系统被表示成如图3-10所示的信息变换模型。矩形用于表示外部实体，即产生被软件变换的信息或接收被软件生产的信息的系统元素或另一个系统；圆圈表示被应用到数据（或控制）并以某种方式改变它的加工或变换；箭头表示一个或多个数据项（数据对象）；双线表示数据存储，即存储软件使用的信息。

系统的功能体现在核心的数据变换中。需要注意，该图中一直隐含着处理顺序或条件逻辑，通常直到系统设计时才出现显式的逻辑细节。

功能建模的思想就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止。根据DeMarco的论述，功能模型使用了数据流图来表达系统内数据的运动情况，而数据流的变换则用结构化英语、判定表与判定树来描述。

（1）数据流图（DFD）。数据流图是描述信息流和数据从输入移动到输出时被应用的、变换的图形化技术，其基本形式如图3-10所示。

图3-10　信息变换模型

如图3-11所示的数据流图描述了储户携带存折去银行办理取款手续的过程。从图中可以看到，数据流图的基本图形元素有4种，如图3-12所示。

图3-11　办理取款手续的数据流图

图3-12　DFD的基本图形符号

在数据流图中，如果有两个以上数据流指向一个加工，或是从一个加工中引出两个以上的数据流，这些数据流之间往往存在一定的关系。为表达这些关系，在这些数据流的加工可以标上不同的标记符号。所用符号及其含义在图3-13中给出。

图3-13　表明多个数据流与加工之间关系的符号

数据流图可以在任何抽象级别上表示系统或软件，而且它可以划分为多个级别来表示信息流和功能细节的逐渐增加。因此，DFD既提供了功能建模的机制，也提供了信息流建模的机制。

要注意，数据流图是描述信息在系统中的流动和处理，在数据流图中不能反映控制流。控制性的流程属于程序流程图描述的内容，不要放入数据流图中。

（2）分层数据流图。为了表达数据处理过程数据加工的更多细节，用一个数据流图是不够的。稍微复杂的实际问题，在数据流图上常常出现十几个甚至几十个加工，这样的数据流图就会看起来很不清楚。使用层次结构的数据流图能很好地解决这一问题。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚表达并容易理解整个系统。

图3-14给出了分层数据流图的示例。数据处理S包括3个子系统1、2、3。顶层下面的第一层数据流图为DFD/L1，第二层数据流图DFD/L2.1，DFD/L2.2及DFD/L2.3分别是子系统1、2和3的细化。对于任何一层数据流图来说，它的上层图称为父图，在它下一层的图则称为子图。

图3-14　分层数据流图

第0层的DFD也称为基本系统模型或语境模型，将整个软件元素表示为一个个由进入箭头和离开箭头分别表示输入和输出数据的圆圈。为了揭示更多的细节，对第0层的DFD进一步划分出许多附加的加工（圆圈）和信息流路径，表示在第一层的每个加工是在语境模型中的整个系统的子功能，每个加工又可以被精确化或层次化以描述更多的细节。

画数据流图的基本步骤概括为：自外向内、自顶向下、逐层细化、完善求精。检查和修改的原则如下：

①数据流图上所有图形符号只限于前述4种基本图形元素。

②顶层数据流图必须包括前述4种基本元素，缺一不可。

③顶层数据流图上的数据流必须封闭在外部实体之间。

④每个加工至少有一个输入数据流和一个输出数据流。

⑤在数据流图中，需按层给加工框编号。编号表明该加工处在哪一层，以及上下层的父图与子图的对应关系。

⑥规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。

⑦可以在数据流图中加入物质流，帮助用户理解数据流图。

⑧图中每个元素都必须有名字。数据流和数据文件的名字应当是“名词”或“名词性短语”，表明流动的数据是什么；加工的名字应当是“名词＋宾语”，表明做什么事情。

⑨数据流图中不可夹带控制流。

⑩初画时可以忽略琐碎的细节，以集中精力于主要数据流。

但是，使用DFD的基本表达符号并不能充分描述软件的需求。例如，DFD中箭头可以代表输入加工中或从加工中输出的数据对象，数据存储表示有组织的数据的聚集，但是没说明白箭头所意味或存储所描述的数据“内容”是什么，如果箭头（或存储）代表数据的聚集，那么数据又是什么？这些问题可以使用结构化分析的另一个工具——数据词典来回答。

（3）针对实时系统的Ward&Mellor扩展。Ward和Mellor对基本的结构化分析符号体系进行扩展以适应实时系统提出的以下要求：在时间连续的基础上接收或产生信息流；贯穿整个系统的控制信息和相关的控制处理；有时在多任务的情况下可能会遇到同一个加工的（变换）多个实例；系统具有状态以及导致系统状态迁移的机制。(www.xing528.com)

图3-15给出的扩展的图形符号可以让分析员在描述信息流和加工的同时，描述控制流和控制加工。这些符号可与原来的数据流图的图形符号一起使用。

图3-15　Ward&Mellor开发的针对实时系统的扩展的结构化分析符号

例如，一个汽油涡轮发动机的实时测试监控系统，需要监控涡轮速度、燃烧室温度和连续探测到的各种压力。图3-16是对基本结构化分析符号体系的一个扩展，提供了表示时间连续的数据流的机制，双头箭头表示时间连续的流，单头箭头表示离散的数据流。

图3-16　时间连续的数据流与普通数据流

区分离散的数据流和时间连续的数据流，对于系统工程师和软件设计者都有重要影响。在创建系统模型时，系统工程师最好能分离出性能关键的加工（通常时间连续的输入数据和输出数据对性能很敏感），创建物理或实现模型时，设计者必须建立机制来收集时间连续的数据。

在传统的数据流图中，控制或事件流没有显式地表现出来，但在实际应用中使用了代表事件流和控制加工的特殊符号，如图3-15中数据流继续使用传统的数据流图中的实线箭头；控制流表示为虚线箭头或阴影箭头；只处理控制流的加工称为控制加工，用虚线圆圈表示。

控制流可以直接输入一个传统加工或控制加工。图3-17给出了一个生产车间的数据和控制流的顶层视图。

（4）Hatley和Pirbhai对结构化分析技术的扩展。Ward&Pirbhai方法主要关注的不是创建新的图形符号，而是面向控制方面的表示和规约，通过定义控制流图（CFD）以区别于数据流图（DFD）。在控制流图中仍然用虚线来表示控制流和事件流。CFD的加工与数据流图中相同，但显示的是控制流而不是数据流。在控制流图中通过实短线“|”表示对控制规约（CSPEC）的引用，而CSPEC用来指明当发现事件或控制信号时软件如何响应，以及事件发生后哪些加工被激活。加工规约用来描述在流图中表示的加工的内部工作。

图3-17　使用Ward& Mellor符号的数据流和控制流

使用如图3-16和图3-17所示的符号，以及包含在PSPEC和CSPEC中的附加信息，Hatley和Pirbhai创建了实时系统模型。用数据流图表示对数据和操作数据的加工；用控制流图表示事件在加工之间如何流动，说明导致各个加工被激活的外部事件。图3-18显示了加工和控制模型的相互关系：加工模型通过数据条件连接到控制模型；控制模型通过包含在CSPEC中的加工激活信息连接到加工模型。

图3-18　数据与控制之间的关系

控制规约（CSPEC）包括一个状态变迁图（STD）作为行为的“顺序规约”，在它被引用的两个不同层次上表示系统的行为。STD依赖于一组“系统状态”的定义，还包括程序激活表（PAT）作为行为的“组合规约”。

CSPEC描述系统的行为，但它没有提供关于作为行为的结果被激活的加工的内部工作的任何信息。

（5）加工规约（PSPEC）。加工规约用来说明DFD中数据加工隐含的加工细节，包括出现在求精过程最终层次的所有流模型加个。它描述了功能的输入、施加于输入的算法以及产生的输出，另外还指示了加工（功能）的约束和限制、与加工相关的性能特性以及影响加工实现方式的设计约束。其内容包括叙述性正文、加工算法的程序设计语言（PDL）描述、数学议程、表、图或图表。必须注意，写加工规约的主要目的是要表达“做什么”，而不是“怎样做”，所以它应描述实现加工的策略而不是实现加工的细节。

为流模型中的每个圆圈提供一个PSPEC，软件工程师就可创建出一个“小规约”，以此开始创建软件需求规约，并对实现加工的程序元素进行设计。

目前用于写加工规约的工具有结构化英语、判定表和判定树。

3.行为建模

行为建模给出需求分析方法的所有操作原则，但只有结构化分析方法的扩充版本才提供这种建模符号。

（1）“状态-迁移”图。利用如图3-19所示的“状态-迁移”图（STD）或“状态-迁移”表来描述系统或对象的状态，以及导致系统或对象的状态改变的事件，进而描述系统的行为。

图3-19　“状态-迁移”图和与其等价的“状态-迁移”表

每一个状态代表系统或对象的一种行为模式。“状态-迁移”图指明系统的状态如何响应外部的信号（事件）进行推移。在“状态-迁移”图中，圆圈“O”表示可得到的系统状态，箭头“→”表示从一种状态向另一种状态的迁移。在箭头上要写上导致迁移的信号或事件的名字。如图3-19（a）所示，系统中可取得的状态有S 1，S 2和S 3，事件有t 1，t 2，t 3和t 4。事件t 1将引起系统状态S 1向状态S 3迁移，事件t 2将引起系统状态S 3向状态S 2迁移。图3-19（b）是与图3-19（a）等价的“状态-迁移”表。

另外，“状态-迁移”图指明了作为特定事件的结果（状态）。在状态中包含可能执行的行为（活动或加工）。

如果系统比较复杂，可把“状态-迁移”图分层表示。例如，在确定了图3-19所示的状态S 1，S 2和S 3之后，接下来就可把它们细化（图3-20中对状态S 1进行了细化，将状态S 1分解为S 1.1和S 1.2）。此外，在“状态-迁移”图中，由一个状态和一个事件所决定的下一状态可能会有多个，实际会迁移到哪一个，是由更详细的内部状态和更详细的事件信息来决定的。此时可采用一种状态迁移图的变形（如图3-21），使用加判断框和处理框的标记法。

图3-20　“状态-迁移”图的网

图3-21　“状态迁移”图的变形

Petri网，简称：PNG（Petri Net Graph），适用于描述相互独立、协同操作的处理系统，即并发执行的处理系统，可以用在软件需求分析与设计阶段。

Petri网是一种有向图，用“O”表示系统的状态，“—”或“|”表示系统中的事件。有向边表示对事件的输入或从事件输出：“→|”表示对事件的输入，“|→”表示从事件的输出，即事件的结果。

图3-22用Petri网描述了在一个多任务系统中的两个进程“进程1”和“进程2”使用一个公共资源R时，利用原语LOCK（对资源加锁）和UNLOCK（对资源解锁）控制R的使用、保证进程间的同步的例子。

图3-22　进程同步机制的PNG

图中每个进程是一个数据对象，它有3个状态：等待资源（p1或p 4）、占用资源执行的处理（p2和p 5）、不占用资源执行的处理（p3或p 6）。另外，系统有一个状态：资源空闲（p7）。在有些状态中有一个黑点“⊙”，称为标记或令牌，表明系统或对象当前正在处于此状态。当具备了一个事件的输入的所有状态或持有令牌时，才能“激发”该事件（fire），此时系统和对象的状态向前推移，完成系统和对象的某些行为。

分析模型中包含了对数据对象、功能和控制的表示。在每一种表示中，数据对象和控制项都扮演一定的角色，通过数据词典这种组织方式可以表示每个数据对象和控制项的特性。

数据词典是为描述在结构化分析中定义对象的内容，而作为半形式化的语法被提出的。它精确地、严格地定义了每一个与系统相关的数据元素，并以有序列表形式将它们组织起来，使得用户和系统分析员对所有的输入、输出、存储成分和中间计算都有共同的理解。

（2）词条描述。在数据词典的每一个词条中应包含以下信息：

·名称。数据对象或控制项、数据存储或外部实体的主要名称。

·别名。第一项的其他名字。

·何处使用/如何使用。使用该词条（数据或控制项）的加工列表，以及如何使用。

·内容描述。表示内容的符号。

·补充信息。关于数据类型、预设值、限制或者局限等的其他信息。

（3）内容描述。在数据词典的编写中，分析员最常用的描述内容或数据结构的符号如表3-6所示。

表3-6　数据词典定义式中的符号

软件工程师使用表3-6的符号体系，可以通过3种基本构造方式来表示复合数据。

①作为数据项的序列。

②作为从一组数据项中的选择。

③作为数据项的重复的组合。

每个数据项中的项可以表示为顺序、选择和重复的一部分，而其本身又是另一个复合数据项，需要在字典中进一步细化。

内容描述需要一直扩展到所有的复合数据项（数据对象）都被表示为元素项，或者所有的数据对象用对大家都没有歧义的方式表示为止。

数据词典明确地定义了以上各种信息项。随着系统规模的增大，数据词典的规模和复杂性将迅速增加，可以使用CASE工具来维护数据词典。

上面描述的系统建模方法只是需求工程中所用到的建模方法的一个子集，表3-7对这些方法进行了总结。在结构化系统分析中有两种主要的建模方法：基于DFD图的传统功能反诘方法和面向对象方法。

表3-7　建模技术小结