| UML由于其简单、统一，又能够表达软件设计中的动态和静态信息，目前已经成为可视化建模语言事实上的工业标准。UML由三个要素构成：UML的基本构造块、支配这些构造块如何放置在一起的规则和运用于整个语言的一些公共机制。UML的词汇表包含三种构造块：事物、关系和图。事物是对模型中最具有代表性的成分的抽象；关系把事物结合在一起；图聚集了相关的事物。
|
|
|
|
|
| UML中有4种事物：结构事物、行为事物、分组事物和注释事物。
|
|
|
| （1）结构事物（structural thing）。结构事物是UML模型中的名词。它们通常是模型的静态部分，描述概念或物理元素。结构事物包括类（class）、接口（interface）、协作（collaboration）、用例（use case）、主动类（active class）、构件（component）、制品（artifact）和结点（node）。
|
|
|
|
|
|
|
|
|
| （2）行为事物（behavior thing）。行为事物是UML模型的动态部分。它们是模型中的动词，描述了跨越时间和空间的行为。行为事物包括交互（interaction）、状态机（state machine）和活动（activity）。各种行为事物的图形化表示如下图所示。
|
|
|
|
|
|
|
| 交互由在特定语境中共同完成一定任务的一组对象之间交换的消息组成。一个对象群体的行为或单个操作的行为可以用一个交互来描述。交互涉及一些其他元素，包括消息、动作序列（由一个消息所引起的行为）和链（对象间的连接）。在图形上，把一个消息表示为一条有向直线，通常在表示消息的线段上总有操作名。
|
|
|
| 状态机描述了一个对象或一个交互在生命期内响应事件所经历的状态序列。单个类或一组类之间协作的行为可以用状态机来描述。一个状态机涉及到一些其他元素，包括状态、转换（从一个状态到另一个状态的流）、事件（触发转换的事物）和活动（对一个转换的响应）。在图形上，把状态表示为一个圆角矩形，通常在圆角矩形中含有状态的名称及其子状态。
|
|
|
| 活动是描述计算机过程执行的步骤序列，注重步骤之间的流而不关心哪个对象执行那个步骤。活动的一个步骤称为一个动作。在图形上，把动作画成一个圆角矩形，在其中含有指明其用途的名字。状态和动作靠不同的语境得以区别。
|
|
|
| 交互、状态机和活动是可以包含在UML模型中的基本行为事物。在语义上，这些元素通常与各种结构元素（主要是类、协作和对象）相关。
|
|
|
| （3）分组事物（grouping thing）。分组事物是UML模型的组织部分，是一些由模型分解成的“盒子”。在所有的分组事物中，最主要的分组事物是包（package）。包是把元素组织成组的机制，这种机制具有多种用途。结构事物、行为事物甚至其他分组事物都可以放进包内。包与构件（仅在运行时存在）不同，它纯粹是概念上的（即它仅在开发时存在）。包的图形化表示如下图所示。
|
|
|
|
|
|
|
| （4）注释事物（annotational thing）。注释事物是UML模型的解释部分。这些注释事物用来描述、说明和标注模型的任何元素。注解（note）是一种主要的注释事物。注解是一个依附于一个元素或者一组元素之上，对它进行约束或解释的简单符号。注解的图形化表示如下图所示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| （1）依赖（dependency）。依赖是两个事物间的语义关系，其中一个事物（独立事物）发生变化会影响另一个事物（依赖事物）的语义。在图形上，把一个依赖画成一条可能有方向的虚线，如上图所示。
|
|
|
|
|
|
|
| （2）关联（association）。关联是一种结构关系，它描述了一组链，链是对象之间的连接。聚集（aggregation）是一种特殊类型的关联，它描述了整体和部分间的结构关系。关联和聚集的图形化表示如上图和下图所示。
|
|
|
|
|
|
|
| 在关联上可以标注重复度（multiplicity）和角色（role）。
|
|
|
| （3）泛化（generalization）。泛化是一种特殊／一般关系，特殊元素（子元素）的对象可替代一般元素（父元素）的对象。用这种方法，子元素共享了父元素的结构和行为。在图形上，把一个泛化关系画成一条带有空心箭头的实线，它指向父元素，如下图所示。
|
|
|
|
|
|
|
| （4）实现（realization）。实现是类元之间的语义关系，其中一个类元指定了由另一个类元保证执行的契约。在两种情况下会使用实现关系：一种是在接口和实现它们的类或构件之间；另一种是在用例和实现它们的协作之间。在图形上，把一个实现关系画成一条带有空心箭头的虚线，如下图所示。
|
|
|
|
|
|
|
| 这4种关系是UML模型中可以包含的基本关系事物。它们也有变体，例如，依赖的变体有精化、跟踪、包含和延伸。
|
|
|
|
|
| 图（diagram）是一组元素的图形表示，大多数情况下把图画成顶点（代表事物）和弧（代表关系）的连通图。为了对系统进行可视化，可以从不同的角度画图，这样图是对系统的投影。
|
|
|
| UML 2.0提供了13种图，分别是类图、对象图、用例图、序列图、通信图、状态图、活动图、组件图、部署图、组合结构图、包图、交互概览图和定时图。序列图、通信图、交互概览图和计时图均被称为交互图。
|
|
|
| （1）类图（class diagram）。展现了一组对象、接口、协作和它们之间的关系，如下图所示。在面向对象系统的建模中，最常见的图就是类图。类图给出了系统的静态设计视图，包含主动类的类图给出了系统的静态进程视图。类图中通常包含类、接口、协作，以及依赖、泛化和关联关系，也可以包含注解和约束。类图通常用于对系统的词汇建模；对简单的协作建模；对逻辑数据库模式建模。
|
|
|
|
|
|
|
| （2）对象图（object diagram）。展现了一组对象以及它们之间的关系，描述了在类图中所建立的事物实例的静态快照。对象图一般包括对象和链。与类图相同，对象些图给出系统的静态设计视图或静态进程视图，但它们是从真实的或原型案例的角度建立的。
|
|
|
| （3）用例图（use case diagram）。展现了一组用例、参与者（actor）以及它们之间的关系，描述了谁将使用系统以及用户期望以什么方式与系统交互，如下图所示。用例图中包含用例、参与者，以及用例之间的扩展关系（<>）和包含关系（<>），参与者和用例之间的关联关系，用例与用例以及参与者与参与者之间的泛化关系。用例图给出系统的用例视图，可用于对系统的语境建模；对系统的需求建模。
|
|
|
|
|
|
|
| （4）序列图（sequence diagram）。是场景（scenario）的图形化表示，描述了在一个用例或操作的执行过程中以时间顺序组织的对象之间的交互活动，如下图所示。图中对象发送和接收的消息沿垂直方向按时间顺序从上到下放置。序列图中有对象生命线和控制焦点。
|
|
|
|
|
|
|
| （5）通信图（communication diagram）。强调收发消息的对象之间的结构组织。通信图有路径和顺序号。序列图和通信图都是交互图（interaction diagram）。交互图展现了一种交互，它由一组对象和它们之间的关系组成，包括它们之间可能发送的消息。交互图关注系统的动态视图。序列图和通信图是同构的，它们之间可以相互转换。
|
|
|
| （6）交互概览图（interaction overview diagram）。组合了序列图和活动图的特征，显示了每个用例的活动中对象如何交互。它使用活动图的表示法，描述业务过程中的控制流概览，软件过程中的详细逻辑概览，以及将多个图进行连接，抽象掉了消息和生命线。
|
|
|
| （7）定时图（timing diagram）。是另一种交互图，关注一个对象或一组对象在改变状态时的时间约束条件，描述对象状态随着时间改变的情况，很像示波器，适合分析周期和非周期性任务。当为设备设计嵌入式软件时，定时图特别有用。
|
|
|
| （8）状态图（state diagram）。展现了一个状态机，它由状态、转换、事件和活动组成，用于建模时间如何改变对象的状态以及引起对象从一个状态向另一个状态转换的事件，如下图所示。状态图关注系统的动态视图，它对于接口、类和协作的行为建模尤为重要，强调对象行为的事件顺序。
|
|
|
|
|
|
|
| （9）活动图（activity diagram）。是一种特殊的状态图，展现了在系统内从一个活动到另一个活动的流程。活动图专注于系统的动态视图。它对于系统的功能建模特别重要，并强调对象间的控制流程。活动图可用于对工作流建模，操作建模。
|
|
|
| （10）组合结构图（composite structure diagram）。用于描述一个分类器（类、组件或用例）的内部结构，分类器与系统中其他组成部分之间的交互端口，展示一组相互协作的实例如何完成特定的任务，描述设计、架构模式或策略。
|
|
|
| （11）组件图（component diagram）。展现了一组构件之间的组织和依赖。组件图专注于系统的静态实现视图。它与类图相关，通常把构件映射为一个或多个类、接口或协作。
|
|
|
| （12）部署图（deployment diagram）。展现了运行时处理结点以及其中构件（制品）的配置。部署图给出了体系结构的静态实施视图。它与构件图相关，通常一个结点包含一个或多个构件。部署图是UML图中唯一用来对面向对象系统的物理方面建模的一种图。
|
|
|
| （13）包图（package）。用于把模型本身组织成层次结构的通用机制，描述类或其他UML构件如何组织成包，以及这些包之间的依赖关系。包可以拥有其他元素，可以是类、接口、构件、结点、协作、用例和图，甚至是嵌套的其他包。拥有是一种组成关系。
|
|
|
