常用UML图类型介绍，以及不同UML图的特点及用法。
前言
UML(Unified Modeling Language)统一建模语言，又称标准建模语言。是用来对软件密集系统进行可视化建模的一种语言。UML的定义包括UML语义和UML表示法两个元素。
UML是在开发阶段，说明、可视化、构建和书写一个面向对象软件密集系统的制品的开放方法。最佳的应用是工程实践，对大规模，复杂系统进行建模方面，特别是在软件架构层次，已经被验证有效。统一建模语言(UML)是一种模型化语言。模型大多以图表的方式表现出来。一份典型的建模图表通常包含几个块或框，连接线和作为模型附加信息之用的文本。这些虽简单却非常重要，在UML规则中相互联系和扩展。
UML的特点及应用场景
UML具有以下特点：
UML统一了各种方法对不同类型的系统、不同开发阶段以及不同内部概念的不同观点，从而有效的消除了各种建模语言之间不必要的差异。它实际上是一种通用的建模语言，可以为许多面向对象建模方法的用户广泛使用。
UML建模能力比其它面向对象建模方法更强。它不仅适合于一般系统的开发，而且对并行、分布式系统的建模尤为适宜。
UML是一种建模语言，而不是一个开发过程。
UML的目标是以面向对象图的方式来描述任何类型的系统，具有很宽的应用领域。其中最常用的是建立软件系统的模型，但它同样可以用于描述非软件领域的系统，如机械系统、企业机构或业务过程，以及处理复杂数据的信息系统、具有实时要求的工业系统或工业过程等。总之，UML是一个通用的标准建模语言，可以对任何具有静态结构和动态行为的系统进行建模，而且适用于系统开发的不同阶段，从需求规格描述直至系统完成后的测试和维护。
UML图类型
结构行为图
用例图(use case diagram)
用例图捕捉了模拟系统中的动态行为，并且描述了用户、需求以及系统功能单元之间的关系，展示了一个外部用户能够观察到的系统功能模型图。用例图由主角，用例和它们之间的关系组成。
用例图的目的是捕捉到一个系统的动态方面，获取系统的外观图。用例图通常用来收集系统的要求，包括内部和外部的影响。这些要求大多是设计要求。所以，分析一个系统时要收集其功能用例和确定参与者。
示例
下面是一个用例图示例，代表订单管理系统。图中使用了三个用例(订单、特殊订单和正常订单)和一个参与者(顾客)。另外很重要的一点是确定系统边界，用例位于系统边界内，行为者位于系统边界外。关联线显示了用例和行为者之间的关系。
对象模型图(object model diagram)
对象模型图(OMDS)指定了系统中类的结构和静态关系。对象模型图包含类图和对象图。如UML中所规定，它们显示了系统中的类、对象、接口和属性，以及它们之间的静态关系。
类图(class diagram)
类图是面向对象系统建模中最常用和最重要的图，是定义其它图的基础。类图主要是用来显示系统中的类、接口以及它们之间的静态结构和关系的一种静态模型。类图不仅用于可视化描述和记录系统的不同方面，也为构建可执行代码的软件应用程序。
类图描述一类的属性和操作，也对系统的约束。被广泛应用于类图的建模的面向对象的系统中，因为它们是唯一的，可以直接映射到面向对象语言的UML图。
在UML类图中，常见的有以下几种关系: 泛化(Generalization), 实现(Realization)，关联(Association)，聚合(Aggregation)，组合(Composition)，依赖(Dependency)。
各种关系的强弱顺序： 泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖
- 泛化是一种继承关系，表示一般与特殊的关系，它指定了子类如何继承父类的所有特征和行为。泛化使用带空心三角箭头的实线表示。
- 实现是一种类与接口的关系，表示类是接口所有特征和行为的实现。实现使用带空心三角箭头的虚线表示。
- 关联是一种拥有的关系，它使一个类知道另一个类的属性和方法。关联可以是双向的，也可以是单向的。双向的关联使用一根实线或者带双向箭头的实线表示，单向的关联使用一根带单向箭头的实线表示。
- 聚合是整体与部分的关系，且部分可以离开整体而单独存在。如车和轮胎是整体和部分的关系，轮胎离开车仍然可以存在。聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。聚合使用带空心菱形箭头的实线表示。
- 组合是整体与部分的关系，但部分不能离开整体而单独存在。如公司和部门是整体和部分的关系，没有公司就不存在部门。组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。组合使用带实心菱形箭头的实线表示。
- 依赖是一种使用的关系，即一个类的实现需要另一个类的协助，所以要尽量不使用双向的互相依赖。依赖使用带箭头的虚线表示。
示例
对象图(object diagram)
对象图和类图一样反映系统的静态过程，但它是从实际的或原型化的情景来表达的。对象图显示某时刻对象和对象之间的关系，可看成一个类图的特殊用例，实例和类可在其中显示。
对象图是类图的实例，几乎使用与类图完全相同的标识。由于对象存在生命周期，因此对象图只能在系统某一时间段存在。
示例
假设一个订单管理系统的类图如下。
其某一时刻对应的对象图如下。
组件图(component diagram)
组件图又称为组件图，由组件、接口和组件之间联系构成，他描述的是在软件系统中遵从并实现一组接口的物理的、可替换的软件模块。
组件图是用来表示系统中组件与组件之间，类或接口与组件之间的关系图。其中，组件之间的关系表现为依赖关系，定义的类或接口与类之间的关系表现为依赖关系或实现关系。
组件图的组成元素: 组件、接口、关系、端口、连接器。
示例
部署图(deployment diagram)
部署图由节点以及节点之间的关系组成，描述的是系统运行时的结构，展示了硬件的配置及其软件如何部署到网络结构中。部署图通常用来帮助理解分布式系统，一个系统模型只有一个部署图。
部署图与组件图密切相关，部署图是用来描述软件组件部署的硬件组件；而组件图是用来描述组件和显示了它们是如何在硬件中部署。
示例
动态行为图
交互图(interaction diagram)
序列图(sequence diagram)
序列图又称时序图，是交互图的一种。它通过描写叙述对象之间发送消息的时间顺序，显示多个对象之间的动态协作。它能够表示用例的行为顺序，当运行一个用例行为时，序列图中的每条消息响应了一个类操作或状态机中引起转换的触发事件。
序列图展示对象之间的交互，这些交互是指在场景或用例的时间流中发生的，序列图属于动态建模。序列图的重点在消息序列上，也就是说，描写叙述消息是怎样在对象间发送和接收的，表示对象之间传送消息的时间顺序。
序列图的组成元素：对象、生命线、激活、消息。
示例
协作图(collaboration diagram)
协作图，与序列图类似，显示对象、它们的消息以及它们在特定场景或用例中的关系。序列图强调消息流，可以指示发送或接收的消息的时间顺序，而协作图强调对象之间的关系。
协作图显示了通过关联角色传递的消息。消息通常是类操作的实例，它们被编号以表示顺序，也可以用子编号(例如，la.，1b.，1.1.2,1.1.3,2.3a.1.，2.3a.2.，等等)以表示同时发生的任务或实现更大任务的子任务。
示例
状态图(statechart diagram)
状态图是对类图的补充。状态图描述了一个实体基于事件反映的动态行为，显示了该实体是如何根据当前所处的状态对不同的事件作出反应的。
一个状态图应该连接到所有具有清晰的可标志状态和复杂行为的类。状态图可以确定类的行为以及该行为如何根据当前的状态而变化，也可以展示哪些事件将会改变类的对象的状态。
状态图可以捕获对象、子系统和系统的生命周期，可以告知一个对象可以拥有的状态，并且事件(如消息的接收，时间的流逝、错误、条件为真等)会怎样随着时间的推移来影响这些状态。状态图主要是为了模拟响应系统。
一个状态图本质上就是一个状态机，或者是状态机的特殊情况，它基本上是一个状态机中元素的一个投影，这也就意味着状态图包括状态机的所有特征。
在UML中，状态图由表示状态的节点和表示状态之间转换的带箭头的直线组成。状态的转换由事件触发，状态和状态之间由转换箭头连接。每一个状态图都有一个初始状态（实心圆），用来表示状态机的开始。还有一个中止状态（半实心圆），用来表示状态机的终止。
状态图主要由元素状态、转换、初始状态、中止状态和判定等组成。
示例
活动图(activity diagram)
活动图是一种特殊的状态图，它对于系统的功能建模特别重要，强调对象间的控制流程。与状态图不同，当行为不是由事件驱动时，活动图更为合适。
一个类(用例/操作)可以有一个活动图或一个状态图，但不能同时拥有两者。然而，一个类、对象或用例可能有一个以上的活动图，其中一个图被指定为主要行为。
示例
