3.7 面向数据流建模
面向数据流建模仍然是当前使用最广泛的需求分析表达方式之一(在结构化分析中,数据建模是核心建模活动)。数据流图(Data Flow Diagram,DFD)及相关的图和信息不是UML的正式成分,但可以作为UML图的补充来完善对系统需求和流程的认识。
DFD采取了系统的输入-处理-输出观点,也就是说,流入软件的数据对象,经过处理元素变换,最后以结果数据对象的形式流出软件。带标记的箭头表示数据对象,圆圈(也称为泡泡)表示转换。DFD使用分层的方式表示,即第一个数据流模型(有时也称为第0层DFD或环境图)表示整个系统,随后的数据流图改进环境图,在每个后续层提供更多的细节。
3.7.1 创建数据流模型
数据流图有助于软件工程师开发信息域的模型,并同时开发功能域的模型。当把DFD逐步细化时,分析师同时也就完成了系统功能分解。与此同时,当数据在应用系统的多个处理间流动时,DFD的细化结果导致了相应的数据细化。
导出数据流图时有一些简单而有用的指导原则:①第0层的数据流图应将软件或系统描述为一个泡泡;②应仔细标记主要的输入和输出;③通过把选定的处理、数据对象和数据存储分离为下一层表示而开始细化过程;④应使用有意义的名称标记所有的箭头和泡泡;⑤当从一个层转到另一个层时要保持信息流连续性,也就是说,流入系统或流入某一层变换的数据对象必须与流入更细化层的变换具有相同的数据对象(或其组成部分);⑥一次细化一个泡泡。
图3-15显示了SafeHome安全功能的第0层DFD,主要的外部实体(方框)产生系统所使用的信息并使用系统产生的信息,带标记的箭头代表数据对象或数据对象类型的层次。例如,“用户指令和数据”包括了所有的配置命令、所有的激活或解除命令、所有各式各样的交互活动,以及所有限定或扩展某命令的输入数据。
图3-15 SafeHome安全功能的环境层DFD
把第0层的DFD扩展到第1层数据流模型。根据语法解析,动词是SafeHome系统的处理,在后续的DFD中用泡泡表示;名词是外部实体(方框)、数据或控制对象(箭头)、数据存储(双横线),名词和动词之间可以互相连接起来。因此,在任何DFD层次中对某个泡泡的处理叙述文字进行语法解析,可以产生许多关于如何细化到下一个层次的有用信息。使用这些信息生成第1层的DFD如图3-16所示。
图3-16 SafeHome安全功能的第1层DFD
图3-15中显示环境层的处理被扩展为图3-16的6个处理,这些处理来自语法解析检查。类似地,也通过解析获得第1层处理之间的信息流。此外,在第0层和第l层之间要保持信息流的连续性。
在DFD第1层中表示的处理可以被进一步细化到更低的层次。例如,细化监测传感器处理如图3-17所示的第2层DFD并保持信息流的连续性。
持续进行DFD的求精,努力细化DFD,直到每个泡泡都是“功能单一的”,并且该功能可以很容易地成为一个程序构件。
图3-17 细化监测传感器处理的第2层DFD
3.7.2 创建控制流模型
对于很多类应用问题来说,为了获得关于软件需求的有益理解,使用数据模型和数据流图是很有必要的。然而,有一大类应用问题是事件驱动而不是数据驱动的;这类问题产生控制信息而不是报告或显示信息,并且处理信息时非常关注时间和性能。因此,这样的应用系统除了数据流建模外,还需要使用控制流建模。
事件或控制项可以实现为布尔值(如真或假、开或关、1或0)或条件的离散列表(空、拥挤、满)。为了选择潜在的候选事件,建议使用如下的指导原则。
●列出所有被软件“读”的传感器。
●列出所有的中断条件。
●列出操作人员能够启动的所有“开关”。
●列出所有的数据条件。
●回顾对处理叙述所进行的名词或动词的语法解析,考察所有可能作为控制规格说明输入/输出的“控制项”。
●通过标识其状态来描述系统的行为,标识如何达到这些状态,并定义状态间的迁移。
●关注可能的疏忽,即关注那些描述控制中非常普遍的错误。例如,提问“有什么其他
途径可以达到或离开这个状态吗?”
3.7.3 控制规格说明
控制规格说明使用两种方式表现系统的行为,包含一个行为序列说明的状态图,也可能包括程序激活表,即行为的组合说明。
图3-18所示为SafeHome的第l层控制流模型描述了一个初步的状态图,图中显示了当系统在这个层次上定义的4个状态之间来回移动时,如何对事件做出响应。通过考察状态图,软件工程师可以确定系统的行为,而且更重要的是可以确定所描述的行为中是否存在“空洞”(holes)。
例如,状态图(见图3-18)指明:当系统重置、激活或电源关闭时,可能会发生Idle(空闲)状态的转换;如果激活系统(也就是打开报警系统),将会转换到MonitoringSystemStatus状态(监测系统状态),显示信息也将发生变化,并调用处理monitorAndControlSystem。源自MonitoringSystemStatus状态的转换有两种:①当系统撤销激活时,转换回到Idle空闲状态;②当触发传感器时,转换到ActingOnAlarm状态。在评审中将考虑所有的转换和所有的内容。
图3-18 SafeHome安全功能的状态图
行为表达的一种非常不同的模式是处理激活表(Process Activation Table,PAT),它表示了在状态图中处理环境所包含的信息,不包括状态。因此这张表指出了当有事件发生时会引入流程模型中哪个处理(泡泡)。处理激活表可以作为设计人员的指南,建立在这一级上可以执行的处理控制。SafeHome第1层流程模型的处理激活表如图3-19所示。
图3-19 SafeHome安全功能的处理激活表
控制规格说明描述了系统的行为,但是没有提供关于处理的内部工作信息,其实,这些处理激活了行为的结果。
3.7.4 处理规格说明
处理规格说明(Process Specification,PSPEC)用于描述出现在求精过程中最终层次的所有流程模型的处理。处理规格说明的内容可以包括叙述性正文、处理算法的程序设计语言(Program Design Language,PDL)描述、数学方程、表或UML活动图。通过为流模型中的每个泡泡提供PSPEC,软件工程师创建了“小型规格说明”,小型规格说明可以作为软件构件实现处理的设计指南。
为了说明如何使用PSPEC,考虑在SafeHome的流程模型中表示“处理密码”变换(见图3-16),该功能的PSPEC可能采用如下形式。
处理规格说明:处理密码控制面板上。在SafeHome安全功能中“处理密码”变换完成控制面板上的密码确认。“处理密码”从“与用户交互”功能接收4位密码,将该密码首先与存储在系统中的主密码进行比较,如果与主密码匹配,则向“显示消息和状态”功能传送有效信息<valid id message=true>。如果与主密码不匹配,则把4位密码与次密码表比较(这些密码可能会授予房子的客人和(或)在房主不在家时需要进入房子的工人)。如果密码和表中的某项匹配,将向“显示消息和状态”功能传送有效信息<valid id message=true>;如果不匹配,则向“显示消息和状态”功能传送无效信息<valid id message=false>。
如果在此阶段需要更多的算法细节,程序设计语言描述也可以作为PSPEC的一部分包含在其中。然而,很多人认为,PDL版本应该推迟到构件设计开始时才确定。