软件设计ZhouSu第4章需求建模：流程、模式与Web应用剖析.pptVIP

软件体系结构与设计 第4章 需求建模：流程、模式与Web应用 第4章 需求建模：流程、模式与Web应用 面向数据流建模 生成行为模型 需求建模的模式 Web应用系统的需求建模 第4章 需求建模：流程、模式与Web应用 需求建模有很多不同的维度。对于某种类型软件，用例可能是唯一可行的需求建模表示方法，而其他类型的软件，则需要选择面向对象的方法开发基于类的模型。但在另外一些情形下，复杂应用需求甚至必须做个检测，查看当数据对象在系统中移动时是如何转换的；查看作为外部事件的后果一个应用系统是如何工作的；查看现存知识领域能否解决当前问题；或者在基于Web系统和应用中，如何将内容和功能融合在一起，并提供给最终用户成功导向一个Web应用的能力，以便达到适用目标。 4.1 面向数据流建模 面向数据流建模仍然是当前使用最广泛的需求分析表达方式之一（在结构化分析中，数据建模是核心建模活动）。数据流图（Data Flow Diagram，DFD）及相关的图和信息不是UML的正式成分，但可以作为UML图的补充，来完善对系统需求和流程的认识。 4.1 面向数据流建模 DFD采取了系统的输入-处理-输出观点，也就是说，流入软件的数据对象，经由处理元素变换，最后以结果数据对象的形式流出软件。带标记的箭头表示数据对象，圆圈（也称作泡泡）表示转换。DFD使用分层的方式表示，即第一个数据流模型（有时也称作第0层DFD或环境图）表示整个系统，随后的数据流图改进环境图，在每个后续层提供更多的细节。 4.1.1 创建数据流模型 数据流图有助于软件工程师开发信息域的模型，并同时开发功能域的模型。当把DFD逐步细化时，分析师同时也就完成了系统功能分解。与此同时，当数据在应用系统的多个处理间流动时，DFD的细化结果导致了相应的数据细化。 4.1.1 创建数据流模型 导出数据流图时有一些简单而有用的指导原则：① 第0层的数据流图应将软件或系统描述为一个泡泡；② 应仔细标记主要的输入和输出；③ 通过把选定的处理、数据对象和数据存储分离为下一层表示而开始细化过程；④ 应使用有意义的名称标记所有的箭头和泡泡；⑤ 当从一个层转到另一个层时要保持信息流连续性，也就是说，流入系统或流入某一层变换的数据对象必须与流入更细化层的变换具有相同的数据对象（或其组成部分）；⑥ 一次细化一个泡泡。 4.1.1 创建数据流模型 图4-1显示了SafeHome安全功能的第0层DFD，主要的外部实体（方框）产生系统所使用的信息并使用系统产生的信息，带标记的箭头代表数据对象或数据对象类型的层次。例如，“用户指令和数据”包括了所有的配置命令、所有的激活或解除命令、所有各式各样的交互活动以及所有限定或扩展某命令的输入数据。 4.1.1 创建数据流模型 把第0层的DFD扩展到第1层数据流模型。根据语法解析，动词是SafeHome系统的处理，在后续的DFD中用泡泡表示；名词是外部实体（方框）、数据或控制对象（箭头）、数据存储（双横线），名词和动词之间可以互相连接起来。因此，在任何DFD层次中对某个泡泡的处理叙述文字进行语法解析，可以产生许多关于如何细化到下一个层次的有用信息。使用这些信息生成第1层的DFD如图4-2所示。 4.1.1 创建数据流模型 图4-1中显示环境层的处理被扩展为图4-2的6个处理，这些处理来自于语法解析检查。类似地，也通过解析获得第1层处理之间的信息流。此外，在第0层和第l层之间要保持信息流的连续性。 在DFD第1层中表示的处理可以被进一步细化到更低的层次。例如，细化监测传感器处理如图4-3所示的第2层DFD并保持信息流的连续性。 4.1.1 创建数据流模型 持续进行DFD的求精，努力细化DFD，直到每个泡泡都是“功能单一的”，并且该功能可以很容易地成为一个程序构件。 4.1.2 创建控制流模型 对于很多类应用问题来说，为了获得关于软件需求的有益理解，使用数据模型和数据流图是很有必要的。然而，有一大类应用问题是事件驱动而不是数据驱动的；这类问题产生控制信息而不是报告或显示信息，并且处理信息时非常关注时间和性能。因此，这样的应用系统除了数据流建模外还需要使用控制流建模。 4.1.2 创建控制流模型 事件或控制项可以实现为布尔值（例如，真或假、开或关、1或0）或条件的离散列表（空、拥挤、满）。为了选择潜在的候选事件，建议使用如下的指导原则： 列出所有被软件“读”的传感器。 列出所有的中断条件。 列出操作人员能够启动的所有“开关”。 列出所有的数据条件。 回顾对处理叙述所进行的名词或动词的语法解析，考察所有可能作为控制规格说明输入/输出的“控制项”。 4.1.2 创建控制流模型 通过标识其状态来描述系统的行为，标识如何达到这些状态，并定义状态间的迁移。 关注可能的疏