需求建模流程行为和模式.ppt

1、第6章 需求建模：流程、行为和模式,主要内容,需求建模策略 面向流程建模 生成行为模型 需求建模的模式 小结,需求建模,面向流程的建模提供了一种如何利用处理功能转换数据对象的表示方法。行为建模描述了系统及其类的状态，以及事件对这些类的影响。基于模式的建模利用现有领域的知识使得需求分析更为容易。,需求建模策略,一种考虑数据和处理的分析建模方法被称作结构化分析，其中数据作为独立实体转换。数据对象建模定义了对象的属性和关系，操作数据对象的处理建模应表明当数据对象在系统内流动时处理如何转换数据。 分析建模的第二种方法称作面向对象的分析，这种方法关注于定义类和影响客户需求的类之间的协作方式。UML和统一

2、过程主要是面向对象的。,面向流程的建模,面向流的数据建模至今仍是广泛使用的分析表达法之一。尽管数据流图及相关的图和信息不是UML的正式组成部分，但是它们可以补充UML图并提供对系统需求和流的补充认识。 DFD采取了系统的输入-处理-输出观点。流入软件的数据对象，经由处理元素转换，最后以结果数据对象的形式流出软件。数据对象由带标记的箭头表示，转换由圆圈（也称作泡泡）表示。DFD使用分层的方式表示，即第一个数据流模型从整体上表现系统，随后的数据流图改进环境图，提供每个后续层增加的细节。,创建数据流模型,数据流图有助于软件工程师开发信息域的模型，并同时开发功能域的模型。当DFD被改进到非常详细的程度

3、时，分析师同时也就完成了系统功能分解。,创建数据流模型,导出数据流图时有一些很有用的简单的指导原则： 第0层的数据流图应将软件或系统描述为一个泡泡 ； 应仔细标记主要的输入和输出； 通过把在下一层表示的候选处理过程、数据对象和数据存储分离，开始求精过程； 应使用有意义的名称标记所有的箭头和泡泡； 当从一个层转到另一个层时要保持信息流连续性； 一次精化一个泡泡。 Safehome安全功能的DFD如图6-1所示,SafeHome安全功能的DFD图,图6-1 SafeHome安全功能的DFD图,创建数据流模型,第0层的DFD现在要扩展到第1层。 有个简单而有效的方法是对描述环境层泡泡的叙述进行“语法

4、分析”，即将第一次需求收集会议中获得的SafeHome处理叙述中的所有名词与动词分离开来。,SafeHome实例25,创建数据流模型,这里提到的语法分析，开始形成一种模式。动词是SafeHome处理，它们最终将被表示为后来的DFD中的泡泡；名词是外部实体（方框）、数据或控制对象（箭头）、数据存储（双横线）。通过对任何DFD层次中某个泡泡的处理叙述文字进行语法分析，可以产生许多关于如何精化到下一个层次的有用信息。使用这些信息，第1层DFD如图6-2所示。在第0层和第1层之间要保持信息流的连续性。,SafeHome安全功能的第1层DFD图,图6-2 SafeHome安全功能的第1层DFD图,创建数

5、据流模型,在DFD第1层中表示的处理可以被进一步精化到更低的层次。例如，监测传感器处理可以被精化为如图6-3所示的第2层DFD。在这两层之间保持了信息流的连续性。 DFD的求精持续地进行，直到每个泡泡都执行一个简单的操作，即直至每个泡泡所代表的处理都执行一个功能，并且该功能可以很容易地被程序实现。,精化监测传感器处理的第2层DFD图,图6-3 精化监测传感器处理的第2层DFD图,创建控制流模型,有一大类应用问题是事件驱动的而不是数据驱动的；这类问题产生控制信息而不是报告或显示信息，并且，处理信息时非常关注时间和性能。这样的应用除了数据流建模外还需要使用控制流建模。,创建控制流模型,事件或控制项

6、可以实现为布尔值(例如，true或false，on或off，1或0)或条件的离散列表(空、拥挤、满)。为了选择潜在的候选事件，建议使用如下的指导原则： 列出所有被软件“读”的传感器。 列出所有的中断条件。 列出操作人员能够启动的所有“开关”。 列出所有的数据条件。 回顾对处理叙述所进行的名词/动词语法分析，考察所有可能作为控制流输入/输出的“控制项”。 通过标识其状态来描述系统的行为，标识这些状态是如何达到的，并定义状态间的迁移。 关注可能的疏忽刻画控制中非常普遍的错误；例如，提问“有什么其他途径可以达到或离开这个状态吗？”,控制规格说明,控制规格说明(CSPEC)使用两种不同的方式表现系统的

7、行为。CSPEC包含一个状态图，该图是行为的序列说明；也可能包括处理激活表行为的组合说明。 图6-4为SafeHome的第1层控制流模型描述了一个初步的状态图，图中显示了当系统在这个层次上定义的四个状态之间来回移动的时候，系统如何对事件作出响应。,SafeHome安全功能的状态图,图6-4 SafeHome安全功能的状态图,控制规格说明,状态图(图6-4)指明：当系统被重置、激活或断电时，可能会发生Idle（空闲）状态的转换；如果系统被激活（即打开报警系统），将会转换到MonitoringSystemStatus状态(监测系统状态)，显示信息也将变化，并调用处理monitorAndContro

8、lSystem。源自MonitoringSystemStatus状态的转换有两种：(1)当系统撤销激活时，发生回到idle状态的转换；(2)当传感器被触发时，发生到ActingOnAlarm状态的转换。,控制规格说明,行为表达的一种非常不同的模式是处理激活表(PAT)，它表示了在状态图中处理环境所包含的信息，不包括状态。这张表指出了当有事件发生时会引入流程模型中哪个处理（泡泡）。 SafeHome第1层流程模型的处理激活表如图6-5所示。,SafeHome安全功能的状态图,图6-5 SafeHome安全功能的处理激活表,处理规格说明,处理规格说明(PSPEC)用于描述出现在求精过程中最终层次的

9、所有流模型的处理。处理规格说明的内容可以包括叙述性正文、处理算法的程序设计语言描述、数学方程、表、图或图表。通过为流模型中的每个泡泡提供PSPEC，软件工程师创建了“小规格说明”，小规格说明可以作为实现处理的软件构件的设计指南。,SafeHome实例26,生成行为模型,行为模型显示了软件如何对外部事件或激励作出响应。要生成模型，分析师必须按如下步骤进行： 评估所有的用例，以保证完全理解系统内的交互序列。 识别驱动交互序列的事件，并理解这些事件如何和特定的对象相互关联。 为每个用例生成序列。 创建系统状态图。 评审行为模型以验证准确性和一致性。,识别用例事件,用例表现了涉及的参与者和系统的活动顺

10、序。一般而言，只要系统和参与者之间交换了信息就发生事件。 一旦确定了所有的事件，这些事件将被分配到所涉及的对象，对象负责生成事件或识别已经在其他地方发生的事件。,SafeHome实例27,状态表现,在行为建模的场合下，必须考虑两种不同的状态描述：(1)系统执行其功能时每个类的状态；(2)系统执行其功能时从外部观察到的系统状态。 类状态具有被动和主动两种特征。被动状态很简单，是某个对象所有属性的当前状态。一个对象的主动状态指的是对象进行持续变换和处理时的当前状态。必须发生事件才能迫使对象做出从一个活动状态到另一个活动状态的转移。,分析类的状态图,行为模型的组成之一是UML状态图，UML状态图为每

11、个类表现活动状态和导致这些活动状态变化的事件（触发器）。图7-20说明了SafeHome安全功能中ControlPanel类的状态图。,分析类的状态图,图7-20 ControlPanel类的状态图,分析类的状态图,除了说明导致转换发生的事件外，分析师还可以说明保护和动作。保护是为了保证转变发生而必须满足的一个布尔条件。一般而言，导致状态转移的保护通常依赖于某个对象的一个或多个属性值。即保护依赖于对象的被动状态。 动作和状态转移同时发生或作为状态转移的结果，而且通常动作包含对象的一个或多个操作。,顺序图,第二种表现行为的方式在UML中称作顺序图，说明事件如何引发一个对象到另一个对象的转移。一旦通过检查用例确认了事件，建模人员就创建了一个顺序图用时间函数表现事件如何引发流从一个对象到另一个对象。它表现了导致行为从一个类流到另一个类的关键类和事件。 图6-7列举了SafeHome安全功能的部分顺序图。 一旦完成了完整的顺序图，所有导致系统对象之间转移的事件都可以被整理为输入事件集合和输出事件集合。,顺序图,图6-7 SafeHome安全功能的顺序图(部分),需求建模的模式,软件模式是获取领域知识的一种机制从而遇到新问题时可以反复使用。在某些情况下，领域知识在同一应用领域中用于解决新问题。在另外一些情况下，通过模式获取的领域知识可借助模拟用于完全不同的应用领