常见的UML图如下：
1、类图(Class Diagram)
类(Class)封装了数据和行为，是面向对象的重要组成部分，它是具有相同属性操作关系的对象集合的总称。类的关系通常有以下几种：关联关系(Association)、聚合关系(Aggregation)、组合关系(Composition)、依赖关系(Dependency)、泛化关系(Generalization)、实现关系(Realization)。
1.1 关联关系(Association)
通常用来实现连接有关联的对象所对应的类，即：将一个类的对象作为另一个类的属性。关联关系可以是单向的也可以是双向的。双向的符号是没有方向标的只是一条直线。常见的关联关系如：被关联类B以类属性的形式出现在关联类A中；关联类A引用了一个类型为被关联类B的全局变量。
1.1.1 单向关联
1.1.2 双向关联
1.1.3 自己关联
1.1.4 多重关联
关联关系的多重性说明：
| 表示方式 | 多重性说明 |
|---|---|
| 1…1 | 表示另一个类的一个对象只与一个该类对象有关系 |
| 0…* | 表示另一个类的一个对象与零个或多个该类对象有关系 |
| 1…* | 表示另一个类的一个对象与一个或多个该类对象有关系 |
| 0…1 | 表示另一个类的一个对象没有或只与一个该类对象有关系 |
| m…n | 表示另一个类的一个对象与最少m、最多n个该类对象有关系 |
1.2、依赖关系(Dependency)
是一个使用关系，特定事物的改变有可能会影响到使用该事物的其他事物。即：在一个类中通过另外一个类来调用其方法的表示。常见的依赖关系如：类A的某个方法中参数引用了类B作为形参。
1.3、聚合关系(Aggregation)
表示整体与部分的关系，体现的是整体与部分、拥有的关系，即has-a的关系。考虑到一个整体类的组成结构需要找出成员类，即：成员对象是整体对象的一部分，但是成员对象可以队里整体对象独立存在。这是一种弱关系，一大特点就是可替换。
1.4、组合关系(Composition)
表示整体与部分的关系，体现的是一种contains-a的关系，但是与聚合不同此关系是整体与部分是同生共死关系，即：整体对象若销毁了，则部分也会被销。这是一种强关系，一同创建一同销毁的关系。
1.5、泛化关系(Generalization)
即继承(extends)关系 是父类与子类的关系。
1.6、实现关系(Realization)
即类实现（implements）了接口的关系，当多个类有类似的行为方式的时候通常会使用接口。
1.7 UML类图总结
| 关系 | 说明 | 符号 |
|---|---|---|
| 关联 | 联系关系，表示类与类之间的联结，使一个类知道另一个类的属性和方法 |  |
| 聚合 | 整体和部分的关系，指向方（符号左）整体类，被指向方（符号右）为部分类 |  |
| 组合 | 整体和部分的关系，指向方（符号左）整体类，被指向方（符号右）为部分类 |  |
| 依赖 | 使用关系，指向方（符号左）适用类，被指向方（符号右）为被使用类 |  |
| 泛化 | 继承关系，指向方（符号左）子类，被指向方（符号右）为父类 |  |
| 实现 | 接口的实现关系，指向方（符号左）实现类，被指向方（符号右）为接口类 |  |
最后以一张图来说明这些关系：
2、用例图(Use Case Diagram)
用例图用于描述角色以及角色与用例之间的连接关系，展示了一个外部用户能够观察到的系统功能模型图。说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如：参与者(Actor)、用例(Use Case)、子系统(Subsystem)，并且显示这些元素之间的各种关系。用例图的关系通常有以下几种：关联(Association)、泛化(Inheritance)、包含(Include)、扩展(Extend)、依赖(Dependency)。
2.1 模型元素
2.1.1 参与者(Actor)
与应用程序或系统进行交互的用户、组织或外部系统，用一个小人表示：
2.1.2 用例(Use Case)
外部可见的系统功能，对系统提供的服务进行描述，用椭圆表示：
2.1.3 子系统(Subsystem)
用来展示系统的一部分功能，这部分功能联系紧密：
2.2 用例图中的关系
### 2.2.1 关联(Association)
表示参与者与用例之间的通信，任何一方都可发送或接受消息。
2.2.2 泛化(Inheritance)
子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系；子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。
2.2.3 包含(Include)
用于将一个较复杂用例所表示的功能分解成较小的步骤：有时当某用例的事件流过于复杂时，为了简化用例的描述可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例，类似于在过程设计语言中将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。
2.2.4 扩展(Extend)
扩展关系指用例功能的延伸，相当于为基础用例提供一个附加功能：将基用例中一段相对独立并且可选的动作用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练、目标更集中。扩展用例为基用例添加新的行为，扩展用例可以访问基用例的属性因此它能根据基用例中扩展点的当前状态来判断是否执行自己，但是扩展用例对基用例不可见。
### 2.2.5 依赖(Dependency)
表示源用例依赖于目标用例。
2.3 用例图示例
3、状态图
状态机图描述了一个对象在其生命周期内所经历的各种状态，以及引起对象状态变化的原因。状态机用于对一个模型元素建立行为模型，该模型元素通常是一个类/对象，也可以是一个 Use Case ，甚至是整个系统。
3.1 状态图的元素
状态图由状态、转移、事件、活动和动作五个元素组成：
| 构成元素 | 说明 |
|---|---|
| 状态（State） | 对象在其生命周期中的一种状况，如没有任何行为的休眠状态、被激发运行状态等。一个状态的生命周期是一个有限的时间阶段 |
| 转移（Transition） | 表示一个模型元素的不同状态之间的联系。在事件的触发下，模型元素由一个状态转移到另一个状态 |
| 事件（Event） | 一个有意义的事情出现的说明，该事情在某个时间和空间点发生，并且立即触发一个状态的转移 |
| 活动（Activity） | 状态机中进行的一个非原子执行行为，由一系列动作组成 |
| 动作（Action） | 一个可执行的原子计算，它导致状态的变更或返回一个值 |
3.2 状态（State）
状态图定义的状态分为以下几种：
| 状态类型 | 状态样式 | 状态说明 |
|---|---|---|
| 初始状态 |  |
状态图的起始点 |
| 终止状态 |  |
对象在生命周期结束时的状态 |
| 中间状态 |  |
标志符为圆角矩形，状态名位于矩形中 |
| 并发状态 | 述一起进行的状态变化流，强调时间发生时刻的一致 |
3.3 转移（Transition）
转移是两个状态之间的关系，指示处于第一状态的对象将执行某些动作并且当指定事件发生并且满足指定条件时进入第二状态。状态图中，转移用实线箭头表示，箭头指明转换方向。
3.3.1 转移的5个要素
- 源状态：受转换影响的状态；如果对象处于源状态，则当对象接收到转换的触发事件并且满足监护条件（如果有）时，可以触发传出转换。
- 目标状态：转移完成后对象处于的状态。
- 触发事件：一种可以触发源状态以满足监护条件的激励。
- 监护条件：是原状态向目标状态转移的条件，原状态结束时进行监护条件的判断，只有当监护条件满足时，才能转移到指定的目标状态。
- 动作：转换激活时的操作。
3.3.2 触发事件和监护条件遵循的规则
- 转移时，监护条件在事件发生时计算一次。若转移被重新触发，则监护条件将会被重新计算。
- 如果监护条件和触发事件放在一起使用，当且仅当触发事件发生且监护条件布尔表达式成立时，状态转移才发生 。
- 如果只有监护条件，则只要监护条件为真，状态就发生转移。
3.3.3 转移的类型
| 类型 | 说明 |
|---|---|
| 自转移 | 打断当前状态下的所有活动，使对象退出当前状态，最后又返回该状态。状态转移的源状态和目标状态是同一个状态 |
| 内部转移 | 描述执行响应事件的内部动作或活动，转移只有源状态没有目标状态，内部转移激发的结果并不是改变状态本身 |
| 自动转移 | 又称为完全转移，是当前状态自然结束并引发的转移 |
| 复合转移 | 由简单转移组成，这些简单转移通过判定、分叉或汇合组合在一起 |
3.4 事件（Event）
事件是能够引发系统对象状态改变的行为。事件和转移是相伴出现的，事件可以看作是对转移的修饰，描述系统元素状态改变的原因。事件可以有属性和参数，参数放在事件名称后面的括号（）内。事件是一个触发器，有时事件又被称为事件触发器。它触发了状态之间的转移和状态内部转移，接收事件的对象必须了解如何对触发器进行响应。
3.5 活动（Activity）
活动是当对象处于一个状态时，它一般是空闲的，在等待一个事件的发生。但是某些时间，人们希望描述正在进行的活动。在处于一个状态的同时，对象做着某些工作，并一直继续到被某个时间中断。
3.6 动作（Action）
动作是不可分隔的行为，是行为最小的单元。动作可以是类对象的操作和属性，一个状态中允许有多个动作。动作有以下5种基本类型：
| 类型 | 说明 |
|---|---|
| entry | 入口动作，进入状态是发生的动作 |
| exit | 出口动作，当前状态结束时发生的动作 |
| do | 内部动作，模型元素处于某个状态时执行的动作 |
| include | 引用子状态机状态 |
| event | 用来指定特定事件触发时发生的动作 |
3.7 状态图示例
4、活动图
活动图是UML用于对系统的动态行为建模的另一种常用工具，它描述活动的顺序，展现从一个活动到另一个活动的控制流。活动图在本质上是一种流程图。活动图着重表现从一个活动到另一个活动的控制流，是内部处理驱动的流程。UML 2.0而言，去除了“活动图是状态图的一种特例”这一规定。
4.1 活动图的元素
状态图由动作状态（Actions）、动作状态约束（Action Constraints）、动作流（Control Flow）、开始节点（Initial Node）、终止节点（Final Node）、对象（Objects）、数据存储对象（DataStore）、对象流（Object Flows）组成。
4.1.1 动作
| 动作类型 | 动作样式 | 动作说明 |
|---|---|---|
| 动作状态 |  |
指原子的\不可中断的动作，完成后转向另一个状态 |
| 动作状态约束 |  |
用来约束动作状态 |
| 动作流 |  |
代表动作之间的转换 |
4.1.2 节点
| 节点类型 | 节点样式 | 节点说明 |
|---|---|---|
| 开始节点 |  |
表示活动开始 |
| 活动终止节点 |  |
表示整个活动结束 |
| 流程终止节点 |  |
表示是子流程结束 |
4.1.3 对象
| 对象类型 | 对象样式 | 对象说明 |
|---|---|---|
| 对象 |  |
- |
| 数据存储对象 |  |
- |
| 对象流 | - | 动作状态或者活动状态与对象之间的依赖关系，表示动作使用对象或动作对对象的影响 |
4.1.4 信号
| 信号类型 | 信号样式 | 信号说明 |
|---|---|---|
| 时间信号 |  |
- |
| 发送信号 |  |
- |
| 接收信号 |  |
- |
4.1.5 其他
| 类型 | 样式 | 说明 |
|---|---|---|
| 分支与合并 |  |
用于表示满足条件时执行该转换 |
| 分叉与汇合 |  |
- |
4.2 活动图示例
5、协作图/通信图
协作图是一种交互图，它关注对象在参与具体交互时，对象之间如何链接以及传递什么消息。协作图按时间和空间的顺序描述系统元素之间的交互和关系，侧重于描述消息的组成关系。
在使用协作图时，通过在对象之间建立链接并在其上附加信息来表明对象间的交互，消息名称反映了在与被引用对象交互时引用对象的意图。
5.1、协作图的元素
协作图由对象（Object）、消息（Message）、链（Link）组成。
5.1.1 对象
协作图中对象的表示方式使用包围名称的矩形框来标记，所显示的对象及其类的名称带有下划线，两者用冒号隔开。使用“对象名：类名”的形式表示。
| 对象类型 | 对象样式 | 说明 |
|---|---|---|
| 控制类 |  |
用于协作图的处理过程 |
| 实体类 |  |
表示协作图中的实体对象 |
| 边界类 |  |
协作图中的边界条件 |
5.1.2 消息
在协作图中，可以通过一系列的消息来描述系统的动态行为。从一个对象（发送者）向另一个或几个其他对象（接收者）发送信号，或由一个对象（发送者或调用者）调用另一个对象（接收者）的操作，并且都由三部分组成，分别是发送者、接收者和活动。
| 消息类型 | 消息样式 |
|---|---|
| 同步消息 |  |
| 异步消息 |  |
| 返回消息 |  |
| 简单消息 |  |
5.1.3 链
表示对象之间的语义关系，链是关联的一个实例。协作图中链的符号和对象图中链所用的符号是一样的，即一条连接两个对象的实线。
5.2 消息编号
消息的编号有两种，一种是无层次编号(按顺序编号)，它简单直观；另一种是嵌套的编号，它更易于表示消息的包含关系。
5.3 迭代标记
| 迭代表达式 | 语义 |
|---|---|
| [i:=1…n] | 迭代n次 |
| [I=1…10] | I迭代10次 |
| [while(表达式)] | 表达式为true时，才进行迭代 |
| [until(表达式)] | 迭代到表达式为true时，才停止迭代 |
5.4 协作图示例
6、部署图
部署图表示运行时的物理架构，包括节点（如服务器、工作站等）以及在这些节点上运行的软件组件、进程和对象。部署图展示了如何将软件部署到硬件环境中。
6.1、部署图的元素
部署图由节点（Node）、组件（Component）、接口（Interface）、关联关系（Association）、部署关系（Deployment）组成。
6.2、部署图的符号表示
| 名称 | 图例 | 解释 |
|---|---|---|
| 节点 |  |
是存在与运行时的代表计算机资源的物理元素，可以是硬件也可以是运行其上的软件系统。处理器是带阴影的立方体，设备是不带阴影的立方体。 |
| 组件 |  |
软件开发过程中的产物，包括过程模型（比如用例图、设计图等等）、源代码、可执行程序、设计文档、测试报告、需求原型、用户手册等 |
| 接口 | 表示组件或节点之间的通信点，用带有《interface》标签的棒棒糖（lollipop）符号表示 | |
| 关联关系 | 用实线表示，表示节点之间的物理连接 | |
| 部署关系 | 用带箭头的虚线表示，箭头指向部署组件的节点 |
6.3 部署图示例
7、组件图
组件图即是用来描述组件与组件之间关系的一种UML图。组件图在宏观层面上显示了构成系统某一个特定方面的实现结构。
7.1、组件图的元素
组件图由组件（Component）、接口（Interface）、 关系（Relationship）、 端口（Port）、 连接器（Connector）组成
7.2、组件图的符号表示
| 名称 | 图例 | 解释 |
|---|---|---|
| 节点 | |
是存在与运行时的代表计算机资源的物理元素，可以是硬件也可以是运行其上的软件系统。处理器是带阴影的立方体，设备是不带阴影的立方体。 |
| 组件 | |
软件开发过程中的产物，包括过程模型（比如用例图、设计图等等）、源代码、可执行程序、设计文档、测试报告、需求原型、用户手册等 |
7.3 组件图示例
