第三章 构建分析模型.ppt

软件工程 第7章 构建分析模型 主要内容 需求分析 分析建模的方法 数据建模概念 面向对象的分析 基于场景建模 面向流的建模 基于类的建模 生成行为模型 小结 分析模型 文字记录是极好的交流工具，但并不必然是表达计算机软件需求的最好方式。分析建模使用文字和图表的综合形式，以相对容易理解的方式描绘需求的数据、功能和行为，更重要的是，可以更直接地评审它们的正确性、完整性和一致性。 软件工程师使用从客户那里提取的需求构建模型。 分析模型 可以使用很多不同格式的图表为信息、功能和行为需求建模。基于场景的建模从用户的角度表现系统；面向流的建模在说明数据对象如何通过处理函数进行转换方面提供了指示；基于类的建模定义了对象、属性和关系；行为建模描述了系统状态、类和事件在这些类上的影响。一旦创建了模型的雏形，就将不断改进，并分析评估其清晰性、完整性和一致性。最终的分析模型将由所有的共利益者确认。 分析模型 必须评审分析建模工作产品的正确性、完整性和一致性，必须反映所有共利益者的要求并建立一个可以从中导出设计的基础。 分析模型 在技术层面上，软件工程开始于一系列的建模工作，最终生成待开发软件的需求规格说明和全面的设计表示。分析模型实际上是一组模型，是系统的第一个技术表示。 分析阶段的目标[DEM79] 分析的结果必须是高度可维护的，尤其是要将此结果应用于目标文档。 必须使用一种有效的分割方法解决规模问题。 尽可能使用图形符号。 考虑问题必须区分逻辑的和物理的。 需求分析 需求分析产生软件操作特征的规格说明，指明软件和其他系统元素的接口，建立软件必须满足的约束。需求分析让软件工程师细化在前期需求工程工作中建立的基础需求，并建立模型描述用户场景、功能活动、问题类和类之间的关系、系统和类行为以及数据流。 需求分析 在整个分析建模过程中，软件工程师的主要关注点集中在“做什么”而不是“怎么做”方面。包括：系统处理什么对象？系统必须执行什么功能？系统显示什么行为？定义什么接口？有什么约束？ 整体目标和原理 分析模型必须实现三个主要目标： 描述客户需要什么； 为软件设计奠定基础； 定义在软件完成后可以被确认的一组需求。 分析模型在系统级描述和软件设计的差距之间建立桥梁。 重要的是要注意到在系统描述中给出分析模型的某些元素，并且需求工程的工作实际上是作为系统工程的一部分开始的。此外，分析模型的所有元素都可以直接跟踪到设计模型。通常难以区分这两个重要的建模活动之间的设计和分析工作，有些设计总是作为分析的一部分进行，而有些分析将在设计中进行。 分析模型在系统描述和设计模型之间建立桥梁 分析的经验原则[ARL02] 模型应关注在问题域或业务域内可见的需求，抽象的级别应该相对高一些。 分析模型的每个元素都应能增加对软件需求的整体理解，并提供对信息域、功能和系统行为的深入理解。 关于基础结构和其他非功能的模型应推延到设计阶段再考虑。 最小化整个系统内的关联。 确认分析模型为所有共利益者都带来价值。 尽可能保持模型简洁。 域分析 分析模型通常在特定业务领域内的很多应用中重复发生。如果用一种方式对这些模式加以定义和分类，让软件工程师或分析师识别并复用这些模式，将促进分析模型的创建。更重要的是，应用可复用的设计模式和可执行的软件构件的可能性将显著增加。 域分析 软件域分析是识别、分析和详细说明来自某个特定应用领域的公共需求，特别是那些在该应用领域内被多个项目重复使用的……“面向对象的域分析”是在某个特定应用领域内，根据通用的对象、类、部件和框架、识别、分析和详细说明公共的、可复用的能力。 域分析的目标很简单，就是：查找或创建那些分析类和（或）能够广泛应用的、共有的功能和特点，这样就可以复用。 域分析的输入和输出 分析建模的方法 一种考虑数据和处理的分析建模方法被称作结构化分析，其中数据作为独立实体转换。数据对象建模定义了对象的属性和关系，操作数据对象的处理建模应表明当数据对象在系统内流动时处理如何转换数据。 分析建模的第二种方法称作面向对象的分析，这种方法关注于定义类和影响客户需求的类之间的协作方式。UML和统一过程主要是面向对象的。 分析建模的方法 软件团队往往选择一种方法并排斥另一种方法中的所有表示手段。问题不是哪一种方法最好，而是怎么组合这些表示手段才能够为共利益者提供最好的软件需求模型和过渡到软件设计的最有效方法。 分析模型将生成如图7-3所示的每个建模元素的派生类。然而，不同项目之间，每个元素的特定内容可能因项目而异。软件团队必须想办法保持模型的简单性。只有那些为模型增加价值的建模元素才能使用。 分析模型的元素 数据建模概念 分析建模通常开始于数据建模。软件工程师或分析师需要定义在系统内处理的所有数据对象、数据对象之间的关系以及其他与这些关系相关的信息。 数据对