软件工程-第13章第3节

13.3统一过程的模型

13.3.1模型概述1.模型的含义模型是对系统的一种抽象，从某个视点、在某种抽象层次上详细说明被建模的系统。如一种视点是系统的功能需求视图或设计视图等。模型是对构架设计师和开发人员构造的系统的抽象。对功能需求建模的开发人员来说，认为用户处于系统之外，而认为用例处于系统之内，只关心用户能做什么，而不管系统内部的结构。对设计建模的人员来说，只考虑结构元素如何协同工作来为用例提供功能。13.3.1模型概述2.模型的重要性在统一过程中最引人注目的制品是模型。因此，构造系统就是一个构造模型的过程，即采用不同的模型来描述系统所有不同视角的过程。为系统选择模型是开发组所要做的最重要的决定之一。统一过程给出了经过仔细选择的模型集合，并用它来启动过程。模型集合向所有人员阐明了该软件系统的功能、重要特征和各种结构。13.3.1模型概述3.自包含的视图模型是系统的语义闭合的抽象，即它是一个自包含的视图，用户不需要其他信息(从其他模型)就可以解释该模型。自包含的概念意味着当触发一个用该模型描述的事件时，开发人员希望在系统中产生的结果只能有一种解释。。13.3.2主要模型1.用例模型用例模型包含系统的所有用例、参与者以及它们之间的联系。它是通过需求工作流中的活动来建立的。该模型建立了系统的功能需求。2.分析模型分析模型由用例实现以及参与用例实现的分析类组成。用例实现是协作的构造型，而分析类是参与者。13.3.2主要模型在UML中，协作的定义：为一组由类、接口和其他元素组成的群体命名，它们共同工作，提供比各组成部分功能总和更强的合作行为。协作的图符用虚线椭圆来表示(参见图13.2)。分析模型有两方面的作用：可以更详细地提炼用例；将系统的行为初步分配给提供行为的一组对象。这组对象是分析类的对象。13.3.2主要模型

引入三种分析类：边界类、控制类和实体类，它们是类的构造型。边界类用于表示系统与参与者的交互，它的图形符号是用一条短横线把一条短竖线和一个圆连接起来。控制类用于表示协调、排序、事务处理以及对其他对象的控制，它的图形符号是用一个圆在其上部加一个向左的箭头来表示。实体类用于建立长期且持久的信息模型，它的图形符号是用一个圆在其底部加一条短横线来表示。这些分析类的图形符号在图13.2中出现。

分析模型可以通过分析工作流的活动得到，分析模型用于建立概念设计，该模型是统一过程对UML的扩展。13.3.2主要模型3.设计模型设计模型将系统的静态结构定义为子系统、类和接口，并定义由子系统、类和接口之间的协作所实现的用例实现。在分析模型和设计模型中都涉及用例实现，为了区分这两者，在分析模型中称为用例实现－分析，在设计模型中称为用例实现－设计。在不混淆时，也可省略后缀。13.3.2主要模型4.实现模型实现模型包括构件和类到构件的映射。5.实施模型实施模型定义计算机的物理结点和构件到这些结点的映射。6.测试模型测试模型用于描述测试用例和测试规程。7.其他模型系统可能还包括描述系统业务的领域模型或业务模型。13.3.3模型之间的关系一个系统包含了不同模型中模型元素之间的所有关系和约束。所以，一个系统不仅是其模型的集合，也是模型间关系的集合。1.用例模型和其他模型的依赖关系用例模型的用例可详细说明为分析模型的用例实现－分析，可具体体现为设计模型的用例实现－设计，因此它们之间存在依赖关系。13.3.3模型之间的关系2.模型之间的跟踪关系用例模型的用例与分析模型的用例实现－分析存在跟踪关