Unified Modeling Language (UML)又称统一建模语言或标准建模语言，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。
- UML分类 （1）静态模型（系统结构）： 用例图、类图、对象图、构件图、部署图 （2）动态模型（系统行为）：状态图、活动图、顺序图、协作图
- UML中有4种事务： （1）结构事务：名词、静态部分、物理元素。
-
（2）行为事务：动词、动态部分、行为。
-
（3）分组事务：包。
-
（4）注释事务：注解。
用例图：
用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的蓝图，用于需求分析阶段。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。 
用例之间的关系 （1）包含 (include) 关系 父用例包含子用例，父用例执行，子用例必然被执行 当两个或多个用例中共用一组相同的动作，这时可以将这组相同的动作抽出来作为一个独立的子用例，供多个基用例所共享。因为子用例被抽出，基用例并非一个完整的用例，所以include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行。include关系在用例图中使用带箭头的虚线表示(在线上标注<>)，箭头从基用例指向子用例。
（2）扩展(extend)关系 子用例扩展父用例，复用执行，子用例不一定执行 是对基用例的扩展，基用例是一个完整的用例，即使没有子用例的参与，也可以完成一个完整的功能。 extend关系在用例图中使用带箭头的虚线表示(在线上标注<>)，箭头从子用例指向基用例。
图例：用户如果如期还书，则还书业务就结束了，如果超期了，才会有罚款的业务，罚款不是必须，所以是扩展关系。
类图
类图（Class diagram）展现了一组对象、接口、协作和它们之间的关系。类图是静态视图。 类图中包括： （1）类 （2）接口 （3）协作 （4）依赖、泛化和关联关系
使用类图的场景： （1）对系统的静态设计建模 （2）对简单的协作建模 （3）对逻辑数据库模式建模
类的分类：
(1) 实体类：实体类对应系统需求中的每个实体，它们通常需要保存在永久存储体中，一般使用数据库表或文件来记录，实体类既包括存储和传递数据的类，还包括操作数据的类。实体类来源于需求说明中的名词，如学生、商品等。
(2) 控制类：控制类用于体现应用程序的执行逻辑，提供相应的业务操作，将控制类抽象出来可以降低界面和数据库之间的耦合度。控制类用于对一个或几个用例所特有的控制行为进行建模。控制对象（控制类的实例）通常控制其他对象，因此它们的行为具有协调性质。控制类将用例的特有行为进行封装
(3) 边界类：边界类用于对外部用户与系统之间的交互对象进行抽象，主要包括界面类，如对话框、窗口、菜单等。
类图中的关系：
- 依赖(Dependency)
是一种使用的关系, 即一个类的实现需要另一个类的协助, 所以要尽量不使用双向的互相依赖。可以简单的理解，就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、临时性的、非常弱的，但是B类的变化会影响到A；比如某人要过河，需要借用一条船，此时人与船之间的关系就是依赖。在UML中，依赖关系用带箭头的虚线表示，由依赖的一方指向被依赖的一方。
- 泛化（Generalization）
也就是继承关系的反关系，用于描述父类与子类之间的关系，父类又称作基类或超类，子类又称作派生类。在UML中，泛化关系用带空心三角形的直线来表示。 子类继承自父类，父类是子类的泛化。
- 关联（Association)
是一种拥有的关系, 它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子。 关联是类之间的结构关系，它描述了一组链，链是对象之间的连接。两个类之间可以有多个由不同角色标识的关联。关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。
(1) 双向关联。默认情况下，关联是双向的。
(2) 单向关联 (3)自关联 (4)多重关联
-
聚合（Aggregation）
聚合是关联关系的一种特例，他体现的是整体与部分、拥有的关系，即has-a的关系，此时整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享在UML中，聚合关系用带空心菱形的直线表示。例如：汽车发动机(Engine)是汽车(Car)的组成部分，但是汽车发动机可以独立存在，因此，汽车和发动机是聚合关系，如图所示 -
组合(Composition)
组合也是关联关系的一种特例，他体现的是一种contains-a的关系，这种关系比聚合更强，也称为强聚合；他同样体现整体与部分间的关系，但此时整体与部分是不可分的，整体的生命周期结束也就意味着部分的生命周期结束。在UML中，组合关系用带实心菱形的直线表示。
- 实现（Realization）
是用来规定接口和实现接口的类或者构建结构的关系，接口是操作的集合，而这些操作就用于规定类或者构建的一种服务。 接口之间也可以有与类之间关系类似的继承关系和依赖关系，但是接口和类之间还存在一种实现关系(Realization)，在这种关系中，类实现了接口，类中的操作实现了接口中所 声明的操作。在UML中，类与接口之间的实现关系用带空心三角形的虚线来表示。例如：定义了一个交通工具接口Vehicle，包含一个抽象操作move()，在类Ship和类Car中都实现了该move()操作，不过具体的实现细节将会不一样，如图所示：
对象图
对象图(ObjectDiagram) 展现了某一时刻一组对象以及它们之间的关系，描述了在类图中所建立的事物的实例的静态快照。 
交互图
交互图表现为序列图、通信图、交互概览图和计时图。用于动态建模。
序列图
序列图强调消息时间顺序的交互 
通信图
通信图（协作图）强调接收和发送信息的对象的结构组织的交互 对象：图中的矩形元素即为对象，其中冒号前面部分为对象名，后面为类名，表示类的一个实例。 链接：用两个对象之间的单一线条表示，用来在通信图中关联对象，目的是让消息在不同系统对象之间传递。可以理解链接是公路，消息是车。 消息：通信图中对象之间通信的方式。 
交互概览图
交互概览图强调控制流的交互图 
计时图
计时图适合嵌入式系统建模的交互图 
状态图
用来描述一个特定的对象所有可能的状态，以及由于各种事件的发生而引起的状态之间的转移和变化。用于对系统的动态方面建模。 
活动图
将进程或其他计算的结构展示为计算内部一步步的控制流和数据流，主要用来描述系统的动态视图。活动图在本质上是一种流程图。活动图着重表现从一个活动到另一个活动的控制流，是内部处理驱动的流程。 活动图主要描述行为的动作， 状态图主要描述行为的结果。
构件图
使用构件图的思想是复用。就像是我们盖房子，当房子的大体框架建好之后，剩下的门和窗户家具之类的直接拿来安装上即可，不需要再从新制作，直接拿来复用的思想。这些门和窗户就相当于一个个的构件。 构件有一下几种类型： （1）部署构件：dll文件、exe文件、com+对象、CORBA对象、EJB、动态Web页和数据库表等。 （2）工作产品构件：源代码文件、数据文件等 （3）执行构件：系统执行后得到的构件。 
部署图
表示系统中软件和硬件的物理架构。 从部署图中，可以了解到软件和硬件组件之间的物理关系以及处理节点的组件分布情况。使用部署图可以显示运行时系统的结构，同时还传达构成应用程序的硬件和软件元素的配置和部署方式。 
包图
在 UML 中用类似于文件夹的符号表示的模型元素的组合。包图是一种维护和描述系统总体结构的模型的重要建模工具，通过对包中各个包以及包之间关系的描述，展现出系统的模块与模块之间的依赖关系。 包图的作用：包图可以描述需求，设计的高阶概况；包图通过合理规划自身功能反应系统的高层架构，在逻辑上将系统进行模块化分解；包图最终是组织源码的方式。 一个包图可以由任何一种ＵＭＬ图组成，通常是ＵＭＬ用例图或是ＵＭＬ类图。 包被描述成文件夹，可以用于ＵＭＬ任何一种的图上。 包图只是把某些类放在一个包中，因此可以看做是类图的一种。
