设计--UML组成

UML由视图(View)、图(Diagram)、模型元素(Model Element)和通用机制(General Mechanism)等几个部分组成。

a) 视图(View)： 是表达系统的某一方面的特征的UML建模元素的子集，由多个图构成，是在某一个抽象层上，对系统的抽象表示。

b) 图(Diagram)： 是模型元素集的图形表示，通常是由弧（关系）和顶点（其他模型元素）相互连接构成的。

c) 模型元素(Model Element)：代表面向对象中的类、对象、消息和关系等概念，是构成图的最基本的常用概念。

d) 通用机制(General Mechanism)：用于表示其他信息，比如注释、模型元素的语义等。另外，UML还提供扩展机制，使UML语言能够适应一个特殊的方法（或过程），或扩充至一个组织或用户。

 

2. UML视图的分类

UML是用来描述模型的，用模型来描述系统的机构或静态特征，以及行为或动态特征。从不同的视角为系统构架建模，形成系统的不同视图。

(1) 用例视图(Use Case View)，强调从用户的角度看到的或需要的系统功能，是被称为参与者的外部用户所能观察到的系统功能的模型图。

(2) 逻辑视图(Logical View)，展现系统的静态或结构组成及特征，也称为结构模型视图(Structural Model View)或静态视图(Static View)。

(3) 并发视图(Concurrent View)，体现了系统的动态或行为特征，也称为行为模型视图(Behavioral Model View)或动态视图(Dynamic View)。

(4) 组件视图(Component View)，体现了系统实现的结构和行为特征，也称为实现模型视图(Implementation Model View)。

(5) 配置视图(Deployment View)，体现了系统实现环境的结构和行为特征，也称为环境模型视图(Environment Model View)或物理视图(Physical View)。

 

视图是由图组成的，UML提供9种不同的图：

(1) 用例图(Use Case Diagram)，描述系统功能；

(2) 类图(Class Diagram)，描述系统的静态结构；

(3) 对象图(Object Diagram)，描述系统在某个时刻的静态结构；

(4) 组件图(Component Diagram)，描述了实现系统的元素的组织；

(5) 配置图(Deployment Diagram)，描述了环境元素的配置，并把实现系统的元素映射到配置上；

(6) 状态图(State Diagram)，描述了系统元素的状态条件和响应；

(7) 时序图(Sequence Diagram)，按时间顺序描述系统元素间的交互；

(8) 协作图(Collaboration Diagram)，按照时间和空间顺序描述系统元素间的交互和它们之间的关系；

(9) 活动图(Activity Diagram)，描述了系统元素的活动；

建模方法由建模语言和建模过程两部分构成。其中建模语言是用来表述设计方法的表示法，建模过程是对设计中所应采取的步骤的描述。UML是一种建模语言，它在很大程度上独立于建模过程。在实际建模中，建模人员最好把UML用于以用案驱动的、以体系机构为中心的、迭代的和渐增式的开发过程中。

一般而言，软件系统的体系结构给出了软件系统的组织、组成系统的构造元素及其接口的选择、系统的行为和体系结构风格等信息。也就是说，它不仅关心系统的结构和行为等功能性需求，而且也涉及系统的性能、易理解性、易复用性等非功能性需求。如下图所示，UML利用用户模型视图、结构模型视图、行为模型视图、实现模型视图和环境模型视图来描述软件系统的体系结构。

 

根据它们在不同架构视图的应用，可以把9种图分成：

(1) 用户模型视图：用例图；

(2) 结构模型视图：类图和对象；

(3) 行为模型视图：状态图、时序图、协作图和活动图（动态图）；

(4) 实现模型视图：组件图；

(5) 环境模型视图：配置图。

用户模型视图由专门描述最终用户、分析人员和测试人员看到的系统行为的用案组成，它实际上是从用户角度来描述系统应该具有的功能。用户模型视图所描述的系统功能依靠外部用户或者另外一个系统来激活，为用户或者另一系统提供服务，从而实现用户或另一系统与系统的交互。系统实现的最终目标是提供用户模型视图中所描述的功能。在UML中，用户模型视图是由用案图组成。

结构模型视图描述组成系统的类、对象以及它们之间的关系等静态结构，用来支持系统的功能需求，即描述系统内部功能是如何设计的。结构模型视图由类图和对象图构成，主要供设计人员和开发人员使用。

行为模型视图主要用来描述形成系统并发与同步机制的线程和进程，其关注的重点是系统的性能、易伸缩性和系统的吞吐量等非功能性需求。行为模型视图利用并发来描述资源的高效使用、并行执行和处理异步事件。除了讲系统划分为并发执行的控制线程之外，行为模型还必须处理通信和这些线程及进程之间的同步问题。行为模型视图主要供系统开发人员和系统集成人员使用，它由序列图、协作图、状态图和活动图组成。

实现模型视图用来描述系统的实现模块它们之间的依赖关系以及资源分配情况。这种视图主要用于系统的配置管理，它是由一些独立的构件组成的。实现模型视图由构件图组成。其中构件是代码模块，不同类型的代码模块形成不同的构件。实现模型视图主要供开发人员使用。

环境模型视图用来描述物理系统的硬件拓扑结构。例如，系统中的计算机和设备的分布情况以及它们之间的连接方式，其中计算机和设备统称为节点。在UML中环境模型视图是由部署图来表示的。系统部署图描述了系统构件在节点上的分布情况，即用来描述软件构件到物理节点的映射。部署图主要供开发人员、系统集成人员和测试人员使用。

上面每一种视图反映了系统的一个特定方面，不同人员可以单独的使用其中每一种视图，从而可以关注特定的体系结构问题。但在通常情况下，由于系统的最终目标是提供用户模型视图中描述的功能以及其它一些非功能性需求，因此，用户模型视图是其它视图的核心基础，其它视图的构造都依赖与用户模型视图中所描述的类容。

细心的读者已经发现，每一种UML图都是由多个图组成的，每一种图都是体系结构某个侧面的表示，各种图实际上是一致的，所有的图在一起组成了系统的完整视图。如下图所示，UML中总共提供了用案图、类图、对象图、序列图、协作图、状态图、活动图、构建图和部署图9种图。根据它们描述的是系统的静态结构还是动态行为，可以将它们分为静态图和动态图两类。再进一步介绍这9中UML图时，先了解下什么是模型元素：

 

3. UML的建模机制

UML有两套建模机制：静态建模机制和动态建模机制。静态建模机制包括用例图、类图、对象图、包、组件图和配置图。动态建模机制包括状态图、时序图、协作图、活动图。

(1) 用例图：用例的可视化工具，它提供计算机系统的高层次的用户视图，表示以外部活动者的角度来看系统将是怎样使用的。

用例图（用案图）是用于描述一组用案，参与者以及它们之间的连接关系。一个用案图描述了一组动作序列，每一个序列表示系统的外部设施（系统的参与者）与系统本身的交互。从一个特定参与者的角度看，一个用案完成对其有价值的工作。如图2.5所示，用案图仅仅是从参与者使用系统的角度来描述系统中的信息，即站在系统外部查看系统应该具有什么功能，而并不描述该功能在软件内部是如何实现的。用案可以应用于整个系统，也可以应用于系统的一个部分，包括子系统、单个的类或者接口。通常，用案不仅代表这些元素所期望的行为，而且还可以把这些元素用作开发过程中测试用案的基础。

用例图包括以下3方面内容：

(a) 用例(Use Case)

(b) 参与者(Actor)

(c) 依赖、泛化和关联关系

用例图示例：

(2) 类图：描述类、接口、协作以及它们之间关系的图。

类图是用于描述一组类、接口、协作以及它们之间的静态关系。在面向对象系统的建模中，类图是最为常用的图，它用来阐明系统的静态结构。事实上类是对一组具有相同属性、操作、关系和语义的对象的描述，其中对类的属性和操作进行描述时的一个最重要的细节就是它的可见性。

类可以以多种形式连接，例如关联、泛化、依赖和实现等。一个典型的系统中通常有若干个类图。一个类图不一定要包含系统中所有的类，一个类可以加到几个类图中。

类图示例：

(3) 对象图：表示在某一时间上一组对象以及它们之间的关系的图。对象图可以被看做是类图在系统某一时刻的实例。

对象图是类图的实例，用来描述特定运行时刻一组对象之间的关系。也就是说，对象用于描述交互的静态部分，它由参与协作的有关对象组成。但不包括在对象之间传递的任何消息。

在创建对象图时，建模人员并不需要用单个的对象图来描述系统中的每一个对象。事实上，绝大多数系统中都会包含成百上千的对象。用对象来描述系统的所有对象以及它们之间的关系一般是不太现实的。因此，建模人员可以选择所感兴趣的对象极其之间的关系来描述。

对象图中所使用的符号和类图中使用的符号几乎完全相同，区别仅在于对象图的对象名带有下划线，而且类与类之间关系的所有的实例都要画出来。

(4) 组件图：描述软件组件以及组件之间的关系，组件本身是代码的物理模块，组件图则显示了代码的结构。

组件图（构件图）是用于描述一组构件之间的组织和依赖关系，用于建模系统的静态实现视图。构件可以是可执行程序集、库、表、文件和文档等，它包含了逻辑类或者逻辑类的实现信息，因此结构模型视图和实现模型视图之间存在映射关系。

构建图中也可以包括包或子系统，它们都是用于将模型元素组成较大的组块。

组件图例图：

(5) 配置图：描述系统硬件的物理拓扑结构以及在此结构上执行的软件。配置图可以显示计算节点的拓扑结构和通信路径、结点上运行的软件组件、软件组件包含的逻辑单元（对象、类）等。配置图常常用于帮助理解分布式系统。

配置图（部署图）用来描述系统运行是进行处理的节点以及在节点上活动的构件的配置。部署图用来对系统的环境模型视图进行建模。在大多数情况下，部署图用来描述系统硬件的扩普结构。

在UML中，建模人员可以用类图来描述系统的静态结构，可以用序列图、协作图、状态图、活动图来描述系统的动态行为，而用部署图来描述软件所执行所需的处理器和设备的拓扑结构。

(6) 状态图：通过类对象的生命周期建立模型来描述对象随时间变化的动态行为。

状态图实际上是一种由状态、变迁、事件和活动组成的状态机。状态图描述从状态到状态的控制流，常用于系统的动态特性建模。在大多数情况下，它用来对反应型对象的行为建模。

在UML中，状态图可以用来对一个对象按事件排序的行为建模。一个状态图是强调从状态到状态的控制流的状态机的简单表示。一般而言，状态图是对类所描述的设施的补充说明，它描述了类的所有对象可能具有的状态以及引起状态变化的事件。

(7) 时序图：交互图描述了一个交互，它由一组对象和它们之间的关系组成，并且还包括在对象间传递的信息。交互图表达对象之间的交互，是描述一组对象如何协作完成某个行为的模型化工具。

序列图和协作图统称为交互图。其中，序列图用来描述对象之间消息发送的先后次序，阐明对象之间的交互过程以及在系统执行过程中的某一具体时刻将会发生什么事件。序列图是一种强调时间顺序的交互图，其中对象沿横轴方向排列，消息沿纵轴方向排列。

序列图中的对象生命线是一条垂直的虚线，它表示一个对象在一段时间内存在。由于序列图中大多数对象都存在于整个交互过程中，因此这些对象全部排列在图的顶部，它们的生命线从图的顶部画到图的底部。每个对象的下方有一个矩形条，它与对象的生命线重叠，它表示该对象的控制焦点。序列图中的消息可以有序号，但由于这种图上的消息已经从纵轴上按时间顺序排序，因此消息序号通常予以省略。

(8) 协作图：包含类元角色和关联角色，而不仅仅是类元和关联。协作图强调参加交互的各对象的组织。协作图只对相互间有交互作用的对象和这些对象间的关系建模，而忽略了其他对象和关联。协作图也是一种交互图，它强调收发消息的对象的组织结构。

协作图和序列图是协作的，它们可以互相转换。在多数情况下，协作图主要对单调的、顺序的控制流建模，但它也可以用来对包括迭代和分支在内的复杂控制流进行建模。

一般而言，建模人员可以创建多个协作图，其中一些是主要的，另外一些是可选择的路径或者异常条件。建模人员可以用包来组织这些协作图，并给每个图起一个合适的名字，以便与其它图区别开。

(9) 活动图：用于展现参与行为的类的活动或动作。

活动图是状态图的一种特殊情况，其中几乎所有或大多数状态都处于活动状态，而且几乎所有或者大多数变迁都是由源状态中活动的完成触发的。活动图本质上是一种流程图，它描述了从活动到活动的控制流。

可以把活动图看作是新样的交互图，但交互图观察的是传递消息的对象，而活动图观察到的是对象之间传送的消息。尽管两者在语义上的区别很细微，但它们使用不同的方式来看系统的。