UML 各种图汇总

UML

统一建模语言（Unified Modeling Language）为面向对象软件设计提供统一的、标准的、可视化的建模语言。
UML语义：UML对语义的描述使开发者能在语义上去的一致认识，消除因人而异的表达方法所造成的影响。（消除二义性）
UML表示法：定义UML符号的表示法，为开发者和开发工具使用这些图形符号和文本语法。

UML建模语言包含五类图：用例图、静态图、行为图、交互图、实现图。

UML 特点

语言

• 软件蓝图，注重于对系统进行概念上和物理上描述

可视化的语言

• 广泛利用可视化元素描述系统

用于详细描述的语言

• 所建的模型是精确的，无歧义的，完整的

构造语言

• 构造语言 <===> 编程语言

文档化语言

• 适于建立系统体系结构及其所有的细节文档

UML 功能

• 为软件系统的产出建立可视化模型
• 规约软件系统的产出
• 构造软件系统的产出

UML 组成

分为元素、关系、图

元素：结构元素、行为元素、分组元素、注释元素

结构元素： UML模型的静态部分，描述概念或物理元素

它包括以下几种：

• 类：具有相同属性相同操作 相同关系相同语义的对象的描述
• 接口：描述元素的外部可见行为，即服务集合的定义说明
• 协作：描述了一组事物间的相互作用的集合
• 用例：代表一个系统或系统的一部分行为，是一组动作序列的集合
• 组件：系统中物理存在，可替换的部件
• 节点：运行时存在的物理元素

另外，参与者、信号应用、文档库、页表等都是上述基本事物的变体

行为元素：UML模型图的动态部分，描述跨越空间和时间的行为

• 交互：实现某功能的一组构件事物之间的消息的集合，涉及消息、动作序列、链接
• 状态机：描述事物或交互在生命周期内响应事件所经历的状态序列

分组元素： UML模型图的组织部分，描述事物的组织结构

• 包： 把元素组织成组的机制

注释元素： UML模型的解释部分，用来对模型中的元素进行说明，解释

• 注解 ：对元素进行约束或解释的简单符号

关系

关系是另一个最重要的构建块UML，它显示元素是如何彼此相关联，此关联描述的一个应用程序的功能，UML中定义了四种关系：

依赖:

依赖(dependency)是两个事物之间的语义关系，其中一个事物(独立事物)发生变化，会影响到另一个事物(依赖事物)的语义
【绘图方式】虚线箭头，箭头指向被使用者

关联:

关联(association)是一种结构关系，它指明一个事物的对象与另一个事物的对象间的联系
【绘图方式】实线箭头，双向箭头或无箭头(公司&雇员、用户&密码)

关联一般又分为聚集关系和组合关系。

聚集

描述的是部分与整体关系，描述了“has a”的关系，部分离开整体可以单独存在。
【绘图方式】空菱形的实线，头部指向整体

组合（组成）

一种更强形式的关联，在整体中拥有管理部分特有的职责，也被称为强聚合关系，部分不能脱离整体存在。
【绘图方式】实菱形的实线，头部指向整体

泛化:

泛化(generalization)是一种特殊/一般的关系。也可以看作是常说的继承关系
【绘图方式】实线空心三角箭头，箭头指向父类

实现:

实现(realization)是类元之间的语义关系，其中的一个类元指定了由另一个类元保证执行的契约。
【绘图方式】封闭空箭头的虚线，箭头指向接口

UML语法描述

各类图详解

类图

UML 类图概述:

类图（Class Diagram）是面向对象系统建模中最常用和最重要的图，是定义其它图的基础。
类图主要是用来显示系统中的类、接口以及它们之间的静态结构和关系的一种静态模型。
类图不仅用于可视化描述和记录系统的不同方面，也为构建可执行代码的软件应用程序。
类图描述一类的属性和操作，也对系统的约束。被广泛应用于类图的建模的面向对象的系统中，因为它们是唯一的，可以直接映射到面向对象的语言的 UML 图。
类图显示集合的类，接口，关联，协作和约束，它也被称为作为结构图。
类图中的“类”与面向对象语言中的“类”的概念是对应的，是对现实世界中的事物的抽象

UML 类图的目的:

类图的目的是表示一个逻辑类或实现类，逻辑类通常是用户的业务所涉及的事物；实现类是程序员处理的实体

类图中的事务以及解释：

接口

• 一组操作的集合，只有操作的声明而没有实现

抽象类

• 不能被实例化的类，一般至少包含一个抽象操作

模版类

• 一种参数化的类，在编译时把模版参数绑定到不同的数据类型，从而产生不同的类

如何画类图？

绘制类图时需要考虑的属性较多，这里的图将被视为从顶层视图。
类图基本上是一个系统的静态视图的图形表示，代表不同方面的应用。因此，集合类图表示整个系统。
在画类图时要牢记以下几点：

• 类图中的名称应该是有意义的描述，并且是面向系统的。
• 画类图前应先确定每个元素之间的关系。
• 类图中的每个类职责（属性和方法）应该清晰标明。
• 对于每个类的属性的最小数量应符合规定，不必要的属性将使图表复杂。
• 使用了以下注释有否要求来描述图中的某些方面。因为上面的附图，它应该是可以理解的开发者/编码器。
• 最后，在最终版本之前，该图应绘制在普通纸上尽可能多次，使其纠正和返工。
  下图是一个二阶系统的一个应用程序的一个例子，它描述了整个应用程序的一个特定方面：
  因此，下面的类图已经绘就考虑到所有上述提到的几点：
  

用例图

角色模型

在说用例图之前我们先来简要说明一下角色模型
角色模型： 确定最重要的用户角色是什么。确定谁将使用这个系统和他们使用系统的目的是什么。

用例图

用例图（Use Case Diagrame）：描述了人们希望如何使用一个系统，将相关用户、用户需要系统提供的服务以及系统需要用户提供的服务更清晰的显示出来，以便使系统用户更容易理解这些元素的用途，也便于开发人员最终实现这些元素。之所以说用例图至关重要，是由于用户并不关心系统的实现和内部结构，只关心产品所呈现出来的外部特征动态。而用例图恰好就是描述软件产品外部特性的视图，它从用户的角度而不是从开发者的角度来描述需求，分析产品的功能和动态行为。
用例图包括三方面内容：用例（Use Case）; 参与者（Actor）; 参与者、用例之间的关系。 用例图模型如下图所示，参与者用人形图标显示，用例用椭圆形表示，连线描述之间的关系。

一、参与者（Actor）

参与者是系统外部的一个实体，它以某种方式参与了用例的执行过程，在UML中，通常用名字写在下面的人形图标表示。

值得注意的是：参与者不一定是人，也可以是任何的事。

参与者间的关系

对于一些参与者来说，它既扮演者自己的角色，同时也扮演更一般的角色。如一般的系统用户可以分为普通用户、VIP用户以及SVIP用户

在确定参与者当中，如果不考虑客户是如何与系统接触的，就使用一般角色参与者，即父类；如果强调接触发生的形式，则必须采用实际的参与者，即子类。

二、用例（Use Case）

用例：是对系统的用户需求（主要是功能需求）的描述，用例表达了系统的功能和所提供的服务，描述了活动者与系统交互中的对话。
每个用例都必须有一个唯一的名字以示区别，用例名字是一个字符串，包括简单名（simple）和路径名（path name），这和类图中的类名是相同的。

三、参与者、用例之间的关系

1. 关联关系
   这是最常使用的关系，用带箭头的实线来描述。
   

2. 泛化关系（Generalization）
   一个用例可以被列举为多个子用例，这就被成为用例泛化，这与类间的泛化关系类似。在用例泛化中，子用例表示父用例的特殊形式，可从父用例处继承行为和属性。泛化关系的图形用空心实线箭头表示，箭头指向父类。
   

3. 包含关系（Include）
   包含：指的是其中一个用例（称为基础用例）的行为包含了另一个用例（称为包含用例）。
   基础用例包含用例并依赖包含用例的执行结果。但是二者不能访问对方的属性。包含关系的图形为虚线箭头加<<include>>，箭头指向包含用例。
   
   例如，用户下单前都需要用户登录。
   

4. 扩展关系（Extend）
   扩展用例可以被定义为：基础用例的增量扩展，它俩之间为扩展关系。
   简单来说，就是当某特定条件出现时，该扩展用例的行为才会被执行。
   扩展关系的图形为虚线箭头加上 << extend >> ，箭头指向基础用例。
   例如，用户下单超时就会出现订单取消的情况。其中 “ 超时 ” 为特定条件，只有该条件出现，才执行 “ 订单取消 ”用例行为。“下单” 和 “ 订单取消 ” 就是扩展关系。
   
   包含和扩展：
   

活动图

一、活动图概述

活动图类似于流程图，但它支持并行活动。
活动图用于描述操作的步骤、业务工作流、多线程。
活动图用于描述类的操作
活动图用于描述用力、对象内部的工作过程
活动图和程序流程图的区别
程序流程图用在编码时表达程序的执行过程，是在低层次上的精细表达。
活动图用在分析业务工作过程时表达抽象程度较高的业务工作过程，是在高层次上的粗犷表达。
在活动图上仅仅列出了那些需要做的事情以及那些必需的、不得不遵守的工作顺序。

二、活动图的组成元素

开始
在活动图当中，活动图的开始由一个实心球表示。

结束
结束分为活动终止节点（activity final nodes）和流程终止节点（flow final nodes）

活动终止节点：
活动终止节点表示整个活动的结束。

流程终止节点
流程终止节点表示是子流程的结束。

动作状态
动作状态是指原子的，不可中断的动作，并在此动作完成后通过完成转换转向另一个状态。特点如下：

• 动作状态是原子的，它是构造活动图的最小单位。
• 动作状态是不可中断的。
• 动作状态是瞬时的行为。
• 动作状态可以有入转换，入转换既可以是动作流，也可以是对象流。动作状态至少有一条出转换，这条转换以内部的完成为起点，与外部事件无关。
• 动作状态与状态图中的状态不同，它不能有入口动作和出口动作，更不能有内部转移。
  在一张活动图中，动作状态允许多处出现。

活动状态
活动状态用于表达状态机中的非原子的运行，特点如下：

• 活动状态可以分解成其他子活动或者动作状态。
• 活动状态的内部活动可以用另一个活动图来表示。
• 和动作状态不同，活动状态可以有入口动作和出口动作，也可以有内部转移。
• 动作状态是活动状态的一个特例，如果某个活动状态只包括一个动作，那么它就是一个动作状态。

动作流
动作之间的转换称之为动作流活动图的转换，通常用实线箭头表示。

分支判断
分支判断描述了一个触发事件在不同的触发条件下引起多个不同的转移，通常用菱形表示。
以简易登录（仅输入密码）为例：

对象和对象流
简单来说，对象就是活动所输出或者输入的，一般是名词，比如：在顾客在购买东西时会进入商品购买工作流，其中账单便是报价活动输出的对象，同时也是付款活动输入的对象，通常用矩形表示。

对象流连接对象和动作，通常用虚线箭头表示。

分叉和汇合
在UML中，可以使用分叉将路径分成两个或多个并发流，然后使用结合，同步这些并流。分叉和汇合通常都用同步条表示，同步条是一条粗的水平线。有水平和垂直两种方向

以购买商品为例：

泳道
泳道将活动图中的活动划分为若干组，并把每一组指定给负责这组活动的业务组织，即对象。
在活动图中，泳道区分了负责活动的对象，它明确地表示了哪些活动是由哪些对象进行的。在包含泳道的活动图中，每个活动只能明确地属于一个泳道。
泳道是用垂直实线绘出，垂直线分隔的区域就是泳道。在泳道的上方可以给出泳道的名字或对象的名字，该对象负责泳道内的全部活动。泳道没有顺序，不同泳道中的活动既可以顺序进行也可以并发进行，动作流和对象流允许穿越分隔线。
以考试活动为例：

状态图

状态图用于显示状态机（它指定对象所在的状态序列）、使对象达到这些状态的事件和条件、以及达到这些状态时所发生的操作。
状态图表现从一个状态到另一个状态的控制流。
精确地描述对象的行为:

• 对象在其生命期间所有状态的序列。
• 对象对接受到的事件所产生的反应。

状态图的组成

状态图由状态的节点和状态之间转换箭头线条组成。
组成元素：

状态（State）
状态是对象执行某项活动或等待某个事件时的条件。对象可能会在有限的时间长度内保持某一状态。状态具有以下几项特征：

• 名称：将一个状态与其他状态区分开来的文本字符串；状态也可能是匿名的，这表示它没有名称。
• 进入/退出操作：在进入和退出状态时所执行的操作。
• 内部转换：在不使状态发生变更的情况下进行的转换。
• 子状态：状态的嵌套结构，包括不相连的（依次处于活动状态的）或并行的（同时处于活动状态的）子状态。
• 延迟的事件：未在该状态中处理但被延迟处理（即列队等待由另一个状态中的对象来处理）的一系列事件。

状态类型
状态类型分为以下两种：

• 简单状态（Simple State） ：
  简单状态是指不包含其他状态的状态；
• 组合状态（Composite State）：
  组成状态是可以包含一些嵌套的子状态的状态。

状态图标可以分为三部分：

• 状态名称
• 内部转换
• 嵌套状态图

转换（Transition）
转换是两个状态之间的关系，它表示当发生指定事件并且满足指定条件时，第一个状态中的对象将执行某些操作并进入第二个状态。当发生这种状态变更时，即“触发”了转换。在触发转换之前，可认为对象处于“源”状态；在触发转换之后，可认为对象处于“目标”状态。转换具有以下几项特征：

• 源状态：转换所影响的状态；如果对象处于源状态，当对象收到转换的触发事件并且满足警戒条件（如果有）时，就可能会触发输出转换。
• 事件触发器：使转换满足触发条件的事件。当处于源状态的对象收到该事件时（假设已满足其警戒条件），就可能会触发转换。
• 监护条件：一种布尔表达式。在接收到事件触发器而触发转换时，将对该表达式求值；如果该表达式求值结果为 True，则说明转换符合触发条件；如果该表达式求值结果为 False，则不触发转换。如果没有其他转换可以由同一事件来触发，该事件就将被丢弃。
• 动作：可执行的、不可分割（即原子的）的计算过程，该计算可能直接作用于拥有状态机的对象，也可能间接作用于该对象可见的其他对象。例如：发送消息给另一个对象、操作调用、设置返回值、创建和销毁对象等。
• 目标状态：在完成转换后被激活的状态。

转换的种类分为以下五种：

外部转换
外部转换：改变对象状态的转换，是最常见的一种转换。
对事件做出响应，引起状态变化或自身转换，同时引发一个特定动作。

内部转换
内部转换有一个源状态但是没有目标状态，它转换后的状态仍旧是它本身。
内部转换始终都不离开本状态。

自转换
自转换：自转换是离开本状态后重新进入该状态，它会执行状态的入口动作和出口动作。
自转换和内部转换的异同点：

• 两者都不改变状态本身；
• 自转换会激发入口动作和出口动作的执行，内部转换不会。

完成转换
完成转换：没有标明触发事件，是由状态中的活动执行完成引起的，是自然而然地完成活动后的转换。

复合转换
复合转换由简单转换组成，这些简单转换通过分支、并发结合在一起。

初始状态（Start State）

初始状态：是起始位置，只能作为源状态。
初始状态图形表示：

终止状态（End State）

终止状态：是状态图的终止点，只能作为目标状态。
终止状态图形表示：

判定（Decision）

判定在状态图中表示状态流在此处按条件的取值而发生分支。

状态建模步骤：

1. 找出适合用模型描述其行为的类。
2. 确定其对象可能存在的状态。
3. 确定引起状态转换的事件。
4. 对建模的结果进行相应的精化和细化。

示例图：

顺序图

顺序图概述

顺序图是交互图中的一种，顺序图也称为时序图或序列图。 用于描述对象之间的交互顺序，着重体现对象间消息传递的时间顺序。

（1）坐标

纵坐标代表时间，依次向下排序；
横坐标代表不同的参与者或相关的对象。

（2）角色

角色代表参与交互的对象。(Actor)
角色名加下划线；

（3）对象

• ObjectName:className
• :className
• objectName

（4）生命线(lifeline)

生命线用一条虚线从上穿下，显示按时间的顺序。

（5）消息(message)

生命线之间的箭头表示对象间传递的消息；
箭头方向代表前一个对象对后一个对象的调用；
箭头上方的标注文字是被调用对象的操作；
消息也可以是有条件的。：在消息上写出条件表达式； 用“if 条件”，或“[条件]”。

消息的分类：
下图依次为：

1. 简单消息( Simple Message)：
   不考虑通信的细节(默认)
2. 同步消息( Synchronous Message)。
   调用者发出消息后必须等待消息返回，同步消息表示等待的语义。
3. 阻止消息(Balking Message)
   发送者发出消息后，若接收者无法立即接收到消息，则发送者放弃这个消息。
4. 超时消息(Timeout Message)
   发送者发出消息后并定时，若接收者无法在指定时间内接收到消息，则发送者放弃这个消息。
5. 过程调用消息(Procedure Message)
   发送者发送消息后，接受者要等待处理消息的整个嵌套顺序完成后，才能继续。
6. 异步消息(Asynchronous Message)——并发
   调用者发出消息后不用等待消息的返回即可继续执行操作。
   异步消息表示不等待语义：发送者不必等待该消息处理完即可继续执行。
7. 返回消息(Return Message)
   接收者返回给发送者的消息，或返回结果。

（7）激活/控制焦点(focus of control)

接收对象收到消息时，接收对象被激活。
用长形条表示激活。

（8）返回消息

指向来源的虚线。

（9）发给自己的消息

画到自身的消息线，调用自己的方法。

（10）对象的创建与删除

当一个对象是通过一个同步消息创建的，此对象应该放置在比较低的位置。
一个对象被删除后，用“×”来标记，此时，生命线不再延长 。

通信图

通信图概念

“通信图”也叫“协作图、合作图”，是顺序图之外的另一种表示交互的图，二者在语义上是等价的，但是，两种图表达的侧重点不同。
顺序图侧重体现交互的时间顺序;
通信图侧重体现对象交互之间的静态连接关系，可以看成是由顺序图抽掉时间轴后转化而来的。

案例：
时序图

协作图

通信图的元素

对象/多值对象：

对象间的连接路径：直线;
传递的消息： 箭头及名称 ;
返回消息（数据流）。

通信图优势

通信图有助于发现系统的瓶颈资源。当某个对象连接的通信路径数明显比其他对象连接的通信路径数多时，说明这个对象可能频繁地与其它多个对象进行消息通信，它可能是一个瓶颈资源。

协作图VS顺序图

协作图和顺序图都表示出了对象间的交互作用，但是它们侧重点不同。

• 顺序图清楚地表示了交互作用中的时间顺序(强调时间)，但没有明确表示对象间的关系。
• 协作图清楚地表示了对象间的关系(强调空间)，但时间顺序必须从顺序号获得。
• 协作图和顺序图可以相互转化。

例子

情节描述：

1. CarOwner按下Carkey的按键，向Carkey发出请求消息，请求实现getButtonPress(b)操作；
2. Carkey发送消息给Car，通知Car实现处理按键的操作processKeyMessage(b)；
3. Car判断，如果是按下“lock”键，Car就自己执行lock()操作[b=”lock”] lock()；
4. Car发送亮灯消息BlinkLights和蜂鸣消息Beep给CarOwner。

顺序图如下：

通信图为：去掉顺序图中的时间概念，保留消息的序号。

构件图

概念

描述代码构件的物理结构以及各构件之间的依赖关系。
一般情况下，构件表示将类、接口等逻辑元素打包而形成的物理模块。
构件可以是源代码构件、二进制构件或一个可执行的构件。
构件与类的差别：

• 类描述了软件设计的逻辑组织和意图；
• 构件描述软件设计的物理实现，即每个组件体现了系统设计中特定类的实现。

目的

提供系统的物理视图，根据系统的代码构件显示系统代码的整个物理结构。

元素

组件图中通常包含3种元素：

• 组件( Component)
• 接口(Interface)
• 依赖关系( Dependency)
  

包图

概念

在对复杂系统建模时，经常需要处理大量的类、接口、组件、节点和图，有必要将这些元素进行分组，把语义相近的元素组织起来，加入同一包中，以方便理解和处理整个模型。
每个包有一个包名：

包中的元素

包中拥有的元素可以是：类、接口、组件、节点、协作、用例和图，甚至可以是其它的包。
可见性：
+ ：公有的（public），此元素可以被任何引入该包的包中的元素访问。
# ：保护的（protected），此元素可以被继承该包的包中的元素访问。
- ：私有的（private）， 此元素只能被同一包的元素访问。

包之间的关系

一个包中的元素有使用（或引入import）另一个包中的元素时，前者依赖后者。
前者为“客户”，后者为“供应者” 。

用虚线箭头，从使用者指向供应者。

部署图

概念

系统中硬件的物理体系结构

目的

显示系统的硬件和软件的物理结构