UML 是 OMG 在1997年1月提出了创建由对象管理组和 UML1.0 规范草案；
UML 是一种为面向对象开发系统的产品进行说明、可视化、和编制文档的标准语言；
UML 作为一种模型语言，它使开发人员专注于建立产品的模型和结构，而不是选用什么程序语言和算法实现；
UML 是不同于其他常见的编程语言，如 C + +，Java中，COBOL 等，它是一种绘画语言，用来做软件蓝图；
UML 不是一种编程语言，但工具可用于生成各种语言的代码中使用 UML 图；
UML 可以用来建模非软件系统的处理流程，以及像在一个制造单元等.
UML 的目标是定义一些通用的建模语言并对这些建模语言做出简单的说明，这样可以让建模者理解与使用。UML 也是为普通人和有兴趣的人而开发的系统，它可以是一个软件或者使用非软件，它必须是明确的。我们不将 UML 作为一个开发方法，而是随着流程做一个成功的系统。
现在我们可以明确的了解 UML 的目标就是 UML 被定义为一个简单的建模机制，帮助我们按照实际情况或者按照我们需要的样式对系统进行可视化；提供一种详细说明系统的结构或行为的方法；给出一个指导系统构造的模板；对我们所做出的决策进行文档化。
对于 UML 的概念模型，我们有以下的理解：
-
概念模型可以被定义为模型，它是由概念和它们之间的关系组成的。
-
概念模型是在绘制 UML 图之前，它帮助了解在现实世界中的各个实体，以及他们如何互相交流。
UML 描述的实时系统，这是非常重要的一个概念模型。
掌握 UML 概念模型可以通过学习以下三大要素达到：
- UML 构建模块
- 规则连接构建模块
- UML 公共机制
面向对象 (Object Oriented,OO) 是软件开发方法，面向对象的概念和应用已超越了程序设计和软件开发。我们可以将 UML 描述为面向对象的分析和设计的继任者。
一个对象中包含了数据和控制数据的方法，其中数据表示对象的状态，类描述的对象，他们也形成层次结构模型真实世界的系统。表示为继承层次结构，也可以以不同的方式按要求相关的类。
对象是现实世界的实体存在我们周围像抽象，封装，继承，多态的基本概念，都可以使用 UML 表示。因此，UML 是强大到足以代表所有的概念存在于面向对象的分析和设计。
UML 图是面向对象的概念的表示，因此，学习 UML 之前，详细了解面向对象的概念就变得非常重要。
以下是一些面向对象基本概念：
-
对象: 对象代表一个实体的基本构建块.
-
类: 类是对象的蓝图.
-
抽象化: 抽象代表现实世界中实体的行为.
-
封装: 封装是将数据绑定在一起，并隐藏他们外部世界的机制。
-
继承: 继承是从现有的机制作出新的类。
-
多态性: 定义的机制来以不同的形式存在.
调查可以被定义为面向对象的分析，更具体地，它是调查对象。设计是指确定对象的协作。
所以重要的是要了解面向对象的分析和设计理念。现在，面向对象的分析的最重要的目的是要设计一个系统来识别对象。这一分析也做了为现有的系统。现在，一种有效的分析是唯一可能的，当我们能够开始思考对象可以识别的方式。确定对象后，确定它们之间的关系，并最终产生的设计。
因此，面向对象的分析与设计的目的可以描述为：
-
确定一个系统中的对象.
-
确定它们之间的关系.
-
做一个设计，使用面向对象的语言可以转换为可执行文件.
有三种基本应用面向对象的概念和实施步骤。步骤可以被定义为：
OO Analysis --> OO Design --> OO implementation using OO languages
以上三点可以详细描述：
-
在面向对象的分析，最重要的目的是确定对象和描述他们以适当的方式。如果这些对象的有效识别，那么接下来的设计工作是很容易的。对象应确定职责。职责是对象所执行的功能。每一个对象具有某种类型的要执行的责任。当这些责任协作系统的目的达成。
-
第二阶段是面向对象的设计。在这个阶段的重点是要求及其履行情况。在这一阶段中的对象根据其预期的关联协作。协作完成设计也完成了。
-
第三阶段是面向对象的执行。在这个阶段，设计采用面向对象语言，如 Java，C++ 等。
UML 是一种建模语言，用于示范性软件和非软件系统。虽然 UML 用于非软件系统，重点是面向对象的软件应用建模。大多数的 UML 图到目前为止讨论的用于模拟静态，动态等不同的方面，如现在各方面的构件是对象。
如果我们观察到类图，对象图，协作图，交互图，将基本上基于对象的设计。
因此，面向对象的设计和 UML 之间的关系是非常重要的理解。根据要求，面向对象的设计转化为 UML 图。在详细了解 UML 的面向对象的概念应该学会正确。的面向对象的分析与设计完成后，下一步是很容易的。从面向对象的分析与设计的输入是输入的UML 图。
- 三个基本模块：事务，关系，图。
- 四种事务
- 结构事务：类，接口，协作，用例，活动类，组件，节点。
- 行为事务：交互，状态机。
- 分组事务：包
- 注释事务：注释。
- 四种关系
- 依赖
- 关联
- 实现
- 泛化
- 十种图
- 用例图
- 类图
- 对象图
- 包图
- 部署图
- 活动图
- 状态图
- 序列图
- 协作图
- 组件图
UML 中最重要的建模元素是符号。
适当有效地使用符号对于一个完整的，有意义的模型来说是非常重要的。如果一个模型的目的无法正确的描绘，那么该模型是无用的。
因此，在开始学习 UML 的时候就要强调表示法的重要性，不同的符号可用于表示物件和关系。
可扩展性是 UML 的另一个重要的特点，这使得UML更加强大和灵活。
UML 的核心是图表，大致可以将这些图归类为结构图和行为图。
-
结构图是由像静态图，如类图，对象图等静态图；
-
行为图是由像序列图，协作图等动态图；
一个系统的静态和动态特性是通过使用这些图的可视化。
类图是使用面向对象的社会最流行的 UML 图。它描述了在一个系统中的对象和他们的关系，能够让我们在正确编写代码以前对系统有一个全面的认识。
一个单独的类图描述系统的一个具体方面，收集类图表示整个系统。基本上，类图表示系统的静态视图。
类图是唯一可以直接映射到面向对象的语言UML图。因此，它被广泛应用于开发者社区。
对象图(Object Diagram)描述的是参与交互的各个对象在交互过程中某一时刻的状态。对象图可以被看作是类图在某一时刻的实例。
在UML中，对象图使用的是与类图相同的符号和关系，因为对象就是类的实例。
组件图是一种特殊的UML图来描述系统的静态实现视图。组件图包括物理组件，如库，档案，文件夹等。
此图是用来从实施的角度。使用一个以上的元件图来表示整个系统。正向和逆向工程技术的使用，使可执行文件组件图。
组件图是用来描述一个系统的静态部署视图。这些图主要用于系统工程师。
部署图是由节点和它们之间的关系。一个高效的部署图是应用软件开发的一个组成部分。
用例图是从用户角度**描述系统功能，并指出各功能的操作者，用来捕捉系统的动态性质。
一个高层次的设计用例图是用来捕捉系统的要求，因此它代表系统的功能和流向。虽然用例图的正向和反向工程是不是一个很好的选择，但他们仍然在一个稍微不同的方法来模拟它。
交互图，用于捕获系统的动态性质。
交互图包括序列图和协作图，其中：序列图显示对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显示对象之间的交互；协作图描述对象间的协作关系，协作图跟时序图相似，显示对象间的动态合作关系。
状态图是一个用于模拟系统的动态性质的五个图。这些图用来模拟一个对象的整个生命周期。
一个对象的状态被定义为对象所在的条件下，特定的时间和对象移动对其他状态，在某些事件发生时。状态图还用于正向和反向工程。
状态图着重描述从一个状态到另一个状态的流程，主要有外部事件的参与。
活动图是 UML 的动态模型的一种图形，一般用来描述相关用例图，活动图是一种特殊的状态图。
准确的活动图定义：活动图描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动。活动图是一种特殊的状态图，它对于系统的功能建模特别重要，强调对象间的控制流程。
复习上节内容，在上节内容中我们知道 UML 的概念模型需要掌握的三大要素是：
- UML构建模块
- 规则连接构建模块
- UML的公共机制
本节讲解 UML 构建模块的所有要素，UML 的构建块的定义如下：
- 事物
- 关系
- 图
事物是实体抽象化的最终结果，是 UML 构建块最重要的组成部分，事物的分类如下:
- 结构事物
- 行为事物
- 分组事物
- 注释事物
结构事物是模型中的静态部分，用以呈现概念或实体的表现元素，是软件建模中最常见的元素，接下来是对结构化物件的简要描述：
类是指具有相同属性、方法、关系和语义的对象的集合；
接口是指类或组件所提供的服务（操作），描述了类或组件对外可见的动作；
协作定义元素之间的相互作用；
用例定义了执行者（在系统外部和系统交互的人）和被考虑的系统之间的交互来实现的一个业务目标；
组件描述物理系统的一部分；
一个节点可以被定义为在运行时存在的物理元素；
行为事物指的是 UML 模型中的动态部分，代表语句里的 "动词"，表示模型里随着时空不断变化的部分，包含两类：
交互被定义为一种行为，包括一组元素之间的消息交换来完成特定的任务。
状态机由一系列对象的状态组成，它是有用的，一个对象在其生命周期的状态是很重要的。
可以把分组事物看成是一个"盒子"，模型可以在其中被分解。目前只有一种分组事物，即包（package）。结构事物、动作事物甚至分组事物都有可能放在一个包中。包纯粹是概念上的，只存在于开发阶段，而组件在运行时存在。
封装是唯一一个分组事物可收集结构和行为的东西。
注释事物可以被定义为一种机制来捕捉UML模型元素的言论，说明和注释。注释是唯一一个注释事物。
注释用于渲染意见，约束等的UML元素。
关系是另一个最重要的构建块UML，它显示元素是如何彼此相关联，此关联描述的一个应用程序的功能，UML中定义了四种关系：
依赖是两件事物之间的语义联系，其中一个事物的变化也影响到另一个事物。
一种描述一组对象之间连接的结构关系，如聚合关系（描述了整体和部分间的结构关系）；
泛化可以被定义为一个专门的元件连接关系与一个广义的元素，它基本上描述了在对象世界中的继承关系，是一种一般化-特殊化的关系；
类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。
UML 图的整个讨论的最终输出所有要素，关系用于使一个完整的UML图，图中表示的系统。
UML 图的视觉效果是整个过程中最重要的部分。
图是事物集合的分类，UML 中包含多种图：
- 类图：类图描述系统所包含的类、类的内部结构及类之间的关系；
- 对象图：对象图是类图的一个具体实例；
- 用例图：用例图从用户的角度出发描述系统的功能、需求，展示系统外部的各类角色与系统内部的各种用例之间的关系；
- 顺序图：顺序图表示对象之间动态合作的关系；
- 协作图：协作图描述对象之间的协作关系；
- 活动图：活动图描述系统中各种活动的执行顺序。
- 状态图：状态图描述一类对象的所有可能的状态以及事件发生时状态的转移条件；
- 部署关系图：部署关系图定义系统中软硬件的物理体系结构；
- 组件图：组件图描述代码部件的物理结构以及各部件之间的依赖关系；
本教程之后的章节中会对上述图进行详细的介绍。
UML 是由视图（View）、图（Diagrams）、模型元素（Model elements）和通用机制等几个部分构成。
视图用来表示被建模系统的各个方面。由多个图构成，它不是一个图片，而是在某一个抽象层上，对系统的抽象表示。如果要为系统建立一个完整的模型图，只需定义一定数量的视图，每个视图表示系统的一个特殊方面就可以了。视图还把建模语言和系统开发时选择的方法或过程连接起来。
图由各种图片构成，用来描述一个视图的内容。UML语言定了9中不同的图的类型，把它们有机地结合起来就可以描述系统的所有视图。
模型元素代表面向对象中的类、对象、消息和关系等概念，是构成图的最基本的常用概念。
通用机制用于表示其他信息，比如注释、模型元素的语义等。它还提供扩展机制，使UML语言能够适应一个特殊的方法（或过程）、或扩充至一个组织或用户。
UML 系统可以由不同的用户使用，用户可以是开发人员、测试人员、商务人士、分析师等等，所以要设计一个系统的体系结构，最重要的是做到从不同的角度来看，实现可视化系统，这样也可以让我们自己更好的了解系统，让它达到一个更好的效果。
从不同的角度使用 UML 定义一个系统的起着重要的作用，这些角度是：
- 设计
- 实现
- 处理
- 部署
该中心是连接所有这四个用例视图，一个用例代表了系统的功能。因此，其他的角度连接使用的情况下：
-
系统设计包括类，接口和协作。 UML类图，对象图支持。
-
实现定义的组件组装在一起，使一个完整的物理系统。 UML组件图是用来支持实施的角度。
-
流程定义了系统的流动。因此，在设计中所用的相同的元件也可用来支持当前角度看。
-
部署代表物理节点的硬件系统构成。 UML部署图是用来支持这个角度来看。
UML 建模可以把在复杂世界的许多重要的细节给抽象出。为了区分 UML 模型， UML 建模用不同类型的不同的图。接下来介绍三个重要类型的UML建模：
结构建模具有捕捉静态的功能，包括下列各项：
- 类图
- 对象图
- 部署图
- 包图
- 复合结构图
- 组件图
结构模型代表的系统架构，这个框架的所有其他组件存在的地方。因此，类图，组件图和部署图的部分结构建模。它们都代表的元素和机制将它们组装。
但是，从来没有的结构模型描述系统的动态行为。类图中是最广泛使用的结构图。
行为建模描述了在系统中的相互作用，代表之间的交互的结构图，行为建模显示系统的动态性质，包括下列各项：
- 活动图
- 交互图
- 用例图
所有上述的显示在一个系统中流动的动态序列。
架构建模表示的是一个系统的总体框架，它包含了系统的结构和行为的元素。架构建模可以被定义为整个系统的蓝图。包图是根据架构模型进行的。
UML 是流行的图解符号。我们都知道，UML 是可视化，说明，构建和记录软件和非软件系统的组成部分。这里的可视化是最重要的部分，需要被理解和记忆。
UML 符号是最重要的建模元素。适当有效地使用符号是非常重要的一个完整的，有意义的模型。该模型是无用的，除非它的目的是正确描绘。
所以学习符号应该从一开始就强调。不同的符号可用于事物和关系。 UML 图使用的符号物件和关系。可扩展性是另一个重要的功能，这使得 UML 更加强大和灵活。
图形表示法中使用的结构事物是 UML 中最广泛使用的，这些被认为是为 UML 模型的名词。以下是结构事物的列表。
- 类
- 接口
- 协作
- 用例
- 活动类
- 组件
- 节点
下面的图表示的 UML 类，该图被分为四个部分。
- 顶端部分被用来命名类。
- 第二个是用来显示类的属性。
- 第三部分是用来描述由类执行的操作。
- 第四部分是可选的显示附加组件。
类是用来表示对象，对象可以是任何性质和职责。
该对象表示以同样的方式作为类。唯一的区别是有下划线的名称，如下图所示。
由于对象是实际执行的一类被称为类的实例。因此，它具有相同的使用作为类。
接口是用圆来表示，如下所示。它有一个名称，一般写成下面的圆圈。
接口是用来描述的功能，而不执行。界面就像一个模板，定义不同的功能但不执行。当一个类实现了接口，也按要求实现功能。
协作表示由 eclipse 虚线如下所示。它有一个名字，里面写 eclipse。
协作表示职责，一般职责在一组。
用例表示它里面的一个名字作为 eclipse。它可能包含更多的责任。
用例是用来捕捉系统的高层次功能。
某些内部或外部的与系统进行交互的实体，可以被定义为一个角色。
角色是在描述用例图内部或外部实体。
初始状态被定义，以显示开始的一个过程。这个符号存在于大多数图。
初始状态的表示法的用法是显示一个过程的起点。
最终状态是用来显示的一个过程的结束。这种表示法也可以用来在大部分的图中描述的目的。
最终状态表示法的用法是显示一个过程的终止点。
活动类类似于一类具有扎实的边界，活动类一般是用来描述一个系统的并发行为。
活动类是用来表示一个系统的并发性。
UML 中的一个组件，如下图所示名称里面。在必要时，可以添加额外的元素。
元器件是用来表示系统的任何部分的 UML 图。
UML 中的一个节点表示的一个方盒子，如下图所示，同一个名字。一个节点表示一个物理的系统组件。
节点用来表示物理系统的一部分，如服务器，网络等。
动态部分是 UML 中最重要的元素之一。
UML 有一个强大的功能集，代表软件和非软件系统的动态部分。这些功能包括交互和状态机。
相互作用可分为两种类型：
- 顺序（序列图）
- 协作（协作图）
交互基本上是两个 UML 组件之间的信息交换。下图表示交互中使用不同的符号。
交互是用来表示一个系统的组件之间的通信。
状态机描述的组件在其生命周期的不同状态。在下面的图中描述的符号。
状态机是用来描述一个系统组件的不同状态。状态可以是活动，空闲或任何其他根据情况。
组织的 UML 模型设计的最重要的方面之一。 UML 中只有一个元件即可用于分组，也就是包。
包装信息书写方式如下表所示，这是用来包装系统组成部分的。
任一图表中说明的不同的元素和它们的功能是非常重要的。因此，UML 符号注释，以支持这一要求。
这种表示法如下所示，它们被用来提供一个系统的必要的信息。
模型是不完整的，正确的描述，除非元素之间的关系。关系给出了一个 UML 模型的意思。
以下是 UML 中提供的不同类型的关系：
- Dependency
- Association
- Generalization
- Extensibility
依赖是UML元素的一个重要方面。它描述了相关的元素和方向上依赖关系。
依赖关系的虚线箭头表示，如下所示。箭头代表的独立元素，另一端的依赖元素。
依赖关系是用来表示一个系统的两个元素之间的依赖。
协作介绍 UML 图中的元素相关联。简单的一句话，它介绍了多少个元素参与互动。
联合会（无）两侧的箭头的虚线表示。两端代表两个相关联的元素，如下所示。在两端（1，*等）的多样性也提到多少对象相关。
协作是用来表示一个系统的两个元素之间的关系。
泛化介绍了面向对象世界的继承关系。这是父与子的关系。
泛化为代表的空心箭头，如下图所示箭头的一端表示的父元素而另一端表示子元素。
泛化是用来描述一个系统的两个元素的亲子关系。
所有的语言（编程或模型）有某种机制来扩展与其功能类似的语法，语义等。 UML 具有以下机制来提供可扩展性功能。
- 定型观念(代表新元素)
- 标记值 (代表新的属性)
- 约束 (代表界限)
可扩展标记基本上是用来表示一些额外的系统行为的附加元素。这些额外的行为，不包括可用的标准符号。
对于 UML 中一些必须使用到的元素，我们在之前的章节中已经有了详细介绍，接下来，我们将会知道这些元素在 UML 中具体的使用。
在 UML 中元素以不同的方式，表达了不同的图表，我们通过不同类型的图片或者图表可以很直观的了解任何复杂的系统，这种方法以不同的形式被广泛应用到不同的行业中。
一个单一的图涵盖所有方面的制度是不够的，因此，UML 定义了各种图表覆盖系统方面。
我们将 UML 中的图分为两大类：
-
结构图
-
行为图
UML 结构图表示系统的静态方面。这些静态方面指示，形成的主要结构并因此稳定那些部分。
这些静态部分是类，接口，对象，组件和节点四个结构图：
- 类图
- 对象图
- 组件图
- 部署图
类图是描述系统中的类，以及各个类之间的关系的静态视图，它包括：类、接口、关联和协作。
类图能够让我们在正确编写代码以前对系统有一个全面的认识。
类图是一种模型类型，确切的说，是一种静态模型类型。
活动类在类图来表示系统的并发性。
类图代表的面向对象的系统。
对象图与类图极为相似，它是类图的实例，对象图显示类的多个对象实例，而不是实际的类，它描述的不是类之间的关系，而是对象之间的关系。从实际的角度来看，它们被用来建立一个系统的原型。
组件图描述代码构件的物理结构以及各种构建之间的依赖关系。
组件图用来建模软件的组件及其相互之间的关系，这些图由构件标记符和构件之间的关系构成。
组件图中，构件时软件单个组成部分，它可以是一个文件，产品、可执行文件和脚本等。
在设计阶段的软件构件（类，接口等）的系统被安排在不同的组，这取决于他们的关系。这些组被称为组件。
组件图用于可视化的实现。
部署图是用来建模系统的物理部署。例如计算机和设备，以及它们之间是如何连接的。
部署图的使用者是开发人员、系统集成人员和测试人员。
部署图是一组节点和它们之间的关系，这些节点部署这些组件的物理实体。
部署图用于可视化系统的部署视图。
注: 如果上述描述和用法仔细观察，这是很清楚的，所有的图表都彼此有某种关系。组件图是依赖的类，接口等类/对象图的一部分。再次部署图是取决于使用的组件，这些组件，以使一个组件图。
任何系统都可以有两个方面，静态和动态。因此，一个模型被认为是完成时，这两个方面都完全覆盖。
行为图基本上捕捉系统的动态方面。动态方面可以进一步改变/移动系统的一部分。
UML具有以下五种行为图：
- 用例图
- 序列图
- 协作图
- 状态图
- 活动图
用例图描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。
一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依赖。
因此，用例图是用来描述的功能之间的关系和他们的内部/外部控制器，这些控制器是已知的参与者。
序列图是一种交互图。
序列图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。
序列图可以用来展示对象之间是如何进行交互的。
序列图将显示的重点放在消息序列上，即强调消息是如何在对象之间被发送和接收的。
从实施和执行的角度来看是非常重要的系统组件之间的交互。
因此，在一个系统中执行一个特定的功能的调用序列的序列图是用于可视化。
协作图和序列图相似，是另一种形式的交互图；如果强调时间和顺序，则使用序列图；如果强调上下级关系，则选择协作图。
协作图代表了一个系统的组织结构和发送/接收的消息。组织结构由对象和链接。
协作图的目的是类似的序列图。但是，协作图的具体目的是可视化的组织对象及其相互作用。
状态图描述类的对象所有可能的状态，以及事件发生时状态的转移条件。
状态图可以捕获对象、子系统和系统的生命周期。他们可以告知一个对象可以拥有的状态，并且事件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。
状态图是用来表示的事件驱动的系统状态的变化。它基本上描述了类，接口状态变化等
状态图是用于可视化的反应系统内部/外部因素。
活动图描述了在一个系统中的控制流。
活动图描述用例要求所要进行的活动，以及活动间的约束关系，有利于识别并行活动。
活动图能够演示出系统中哪些地方存在功能，以及这些功能和系统中其他组件的功能如何共同满足前面使用用例图建模的商务需求。
活动图用于可视化的流量控制在一个系统中。这是准备系统将如何工作，在执行时有一个想法。
注: 在一个系统中很难捕捉到动态性质，而 UML 已经提供从不同的角度捕捉到动态系统的功能。序列图和协作图是同构的，它们之间的转换不会丢失任何信息。
类图（Class Diagram）是面向对象系统建模中最常用和最重要的图，是定义其它图的基础。
类图主要是用来显示系统中的类、接口以及它们之间的静态结构和关系的一种静态模型。
类图不仅用于可视化描述和记录系统的不同方面，也为构建可执行代码的软件应用程序。
类图描述一类的属性和操作，也对系统的约束。被广泛应用于类图的建模的面向对象的系统中，因为它们是唯一的，可以直接映射到面向对象的语言的 UML 图。
类图显示集合的类，接口，关联，协作和约束，它也被称为作为结构图。
类图的目的是模型的一个应用程序的静态视图。
类图是唯一的图可以直接映射到面向对象的语言，因此广泛应用于施工时间。
UML 图，像活动图，序列图图只能给应用程序，但顺序流类图是一个有点不同。所以它是最流行的 UML 图编码社区。
因此，类图的目的可概括为：
-
分析和设计应用程序的静态视图。
-
描述一个系统的责任。
-
基地组件图和部署图。
-
正向和逆向工程。
UML 类图是软件行业经常需要的一项技能。许多项目立项文档、需求分析等文档中，都会有关UML类图的涉及，所以，学习UML类图的绘制至关重要。
绘制类图时需要考虑的属性较多，这里的图将被视为从顶层视图。
类图基本上是一个系统的静态视图的图形表示，代表不同方面的应用。因此，集合类图表示整个系统。
在画类图时要牢记以下几点：
-
类图中的名称应该是有意义的描述，并且是面向系统的。
-
画类图前应先确定每个元素之间的关系。
-
类图中的每个类职责（属性和方法）应该清晰标明。
-
对于每个类的属性的最小数量应符合规定，不必要的属性将使图表复杂。
-
使用了以下注释有否要求来描述图中的某些方面。因为上面的附图，它应该是可以理解的开发者/编码器。
-
最后，在最终版本之前，该图应绘制在普通纸上尽可能多次，使其纠正和返工。
下图是一个二阶系统的一个应用程序的一个例子，它描述了整个应用程序的一个特定方面：
-
系统中的两个要素是所有订单以及客户，他们有一个一对多的关系，因为一个客户可以有多个订单。
-
我们将保持 Order 类是一个抽象类，它有两个具体的类（继承关系）SpecialOrder 和 NormalOrder。
-
两个继承类 Order 类的所有属性。此外，他们有额外的功能 dispatch () 和 receive ().
因此，下面的类图已经绘就考虑到所有上述提到的几点：
类图是一个静态图，它是用来模拟一个系统的静态视图，也被认为是类图作为基础组件图和部署图。
类图不仅用于可视化系统的静态视图，但它们也可用于构建可执行代码的任何系统中的前向和反向工程。
UML 图一般不直接映射到任何面向对象的编程语言，但在类图是一个例外。
类图清楚地显示了映射面向对象语言，如Java，C++等，因此，从实际经验的类图通常用于构建用途。
因此类图可以用来：
-
描述系统的静态视图。
-
显示静态视图中的元素之间的协作。
-
由系统执行的功能的描述。
-
构建软件应用面向对象的语言。
类图（Class Diagram）是面向对象系统建模中最常用和最重要的图，是定义其它图的基础。
类图主要是用来显示系统中的类、接口以及它们之间的静态结构和关系的一种静态模型。
类图不仅用于可视化描述和记录系统的不同方面，也为构建可执行代码的软件应用程序。
类图描述一类的属性和操作，也对系统的约束。被广泛应用于类图的建模的面向对象的系统中，因为它们是唯一的，可以直接映射到面向对象的语言的 UML 图。
类图显示集合的类，接口，关联，协作和约束，它也被称为作为结构图。
类图的目的是模型的一个应用程序的静态视图。
类图是唯一的图可以直接映射到面向对象的语言，因此广泛应用于施工时间。
UML 图，像活动图，序列图图只能给应用程序，但顺序流类图是一个有点不同。所以它是最流行的 UML 图编码社区。
因此，类图的目的可概括为：
-
分析和设计应用程序的静态视图。
-
描述一个系统的责任。
-
基地组件图和部署图。
-
正向和逆向工程。
UML 类图是软件行业经常需要的一项技能。许多项目立项文档、需求分析等文档中，都会有关UML类图的涉及，所以，学习UML类图的绘制至关重要。
绘制类图时需要考虑的属性较多，这里的图将被视为从顶层视图。
类图基本上是一个系统的静态视图的图形表示，代表不同方面的应用。因此，集合类图表示整个系统。
在画类图时要牢记以下几点：
-
类图中的名称应该是有意义的描述，并且是面向系统的。
-
画类图前应先确定每个元素之间的关系。
-
类图中的每个类职责（属性和方法）应该清晰标明。
-
对于每个类的属性的最小数量应符合规定，不必要的属性将使图表复杂。
-
使用了以下注释有否要求来描述图中的某些方面。因为上面的附图，它应该是可以理解的开发者/编码器。
-
最后，在最终版本之前，该图应绘制在普通纸上尽可能多次，使其纠正和返工。
下图是一个二阶系统的一个应用程序的一个例子，它描述了整个应用程序的一个特定方面：
-
系统中的两个要素是所有订单以及客户，他们有一个一对多的关系，因为一个客户可以有多个订单。
-
我们将保持 Order 类是一个抽象类，它有两个具体的类（继承关系）SpecialOrder 和 NormalOrder。
-
两个继承类 Order 类的所有属性。此外，他们有额外的功能 dispatch () 和 receive ().
因此，下面的类图已经绘就考虑到所有上述提到的几点：
类图是一个静态图，它是用来模拟一个系统的静态视图，也被认为是类图作为基础组件图和部署图。
类图不仅用于可视化系统的静态视图，但它们也可用于构建可执行代码的任何系统中的前向和反向工程。
UML 图一般不直接映射到任何面向对象的编程语言，但在类图是一个例外。
类图清楚地显示了映射面向对象语言，如Java，C++等，因此，从实际经验的类图通常用于构建用途。
因此类图可以用来：
-
描述系统的静态视图。
-
显示静态视图中的元素之间的协作。
-
由系统执行的功能的描述。
-
构建软件应用面向对象的语言。
UML 组件图（Component Diagram）又称为构件图，他描述的是在软件系统中遵从并实现一组接口的物理的、可替换的软件模块。
组件图 = 构件（Component）+接口（Interface）+关系（Relationship）+端口（Port）+连接器（Connector）
UML 组件图给提供了将要建立的系统的高层次的架构视图，这将帮助开发者开始建立实现的路标，并决定关于任务分配及（或）增进需求技能。
组件图是一种特殊的 UML 图。与我们之前讨论的 UML 图标的目的都不同。组件图不描述该系统的功能，但它描述了用于使这些功能的组件。
所以从这一点来说，组件图用于可视化在一个系统中的物理组件。这些组件包括库，程序包，文件等。
组件图也被描述为一个静态的实施的系统视图，在一个特定的时刻，静态执行代表组织的组成部分。
一个单一的组件图不能代表整个系统，但图的集合可用来代表整个。
组件图的目的概括如下：
-
可视化系统的组成部分。
-
构建的可执行文件，使用正向和反向工程。
-
描述的组织和组件的关系。
组件图是用来描述一个系统的物理构件。此神器包括文件，可执行文件，库等。
所以这张图的目的是不同的，组件图的过程中使用的应用程序的实施阶段。但它准备提前以可视化的实现细节。
最初，系统的设计使用不同的UML图，然后构件是现成的组件图是用来得到一个想法的实现。
此图是非常重要的，因为如果没有它，应用程序不能有效地实施。精心准备的组件图在其他方面也是很重要的，如应用程序的性能，维护等
所以在绘制组件图后的工件是清楚可辨：
-
在系统中使用的文件。
-
库和其他构件的申请有关。
-
构件之间的关系。
下面是一个订单管理系统的组件图，其中的构件是文件。所以，该图显示了在应用程序的文件以及它们之间的关系。在实际组件图还包含 dll 文件，库，文件夹等。
在下面的图中，四个文件识别，并产生了它们之间的关系。到目前为止讨论与其他 UML 图，组件图不能直接匹配。因为它是得出完全不同的目的。
所以下面的组件图已经绘就考虑到所有上述提到的几点：
UML 组件图经常是一个架构师在项目的初期就建立的非常重要的图，它是无价的，因为它们模型化和文档化了一个系统的架构。
UML 组件图文档化了系统的架构，开发者和系统可能的系统管理员会发现这一工作的关键产品有助于他们理解系统。
UML 组件图也视为软件系统配置图的输入，这将会是本系列后面的文章主题。
我们已经说过组件图可用于可视化系统的静态实现视图，它是特殊类型的 UML 图，它描述了在一个系统中的组件组织。
组织机构可以进一步描述为在一个系统中的组件的位置。这些组件是在一个特殊的组织方式，以满足系统要求。
正如我们已经讨论过这些组件库，文件，可执行文件等，现在组织实施这些组件的应用程序。
组件图的使用可以被描述为：
-
组件建模的一个系统。
-
模型的数据库架构。
-
模型的应用程序的可执行文件。
-
模型系统的源代码。
部署图由节点以及节点之间的关系组成。
部署图描述的是系统运行时的结构，展示了硬件的配置及其软件如何部署到网络结构中。
部署图通常用来帮助理解分布式系统，一个系统模型只有一个部署图。
部署图用于可视化的软件组件部署的系统中的物理组件的拓扑结构。
部署图是用来描述一个系统的静态部署视图。
1、结点（Node）
结点是存在与运行时的代表计算机资源的物理元素，可以是硬件也可以是运行其上的软件系统，比如64主机、Windows server 2008操作系统、防火墙等。
结点用三维盒装表示，如下图所示：
2、结点实例（Node Instance）
结点实例的命名格式：Node Instance : node。它与结点的区别在于名称有下划线和结点类型前面有冒号，冒号前面可以有示例名称也可以没有示例名称，如下图：
3、结点类型（Node Stereotypes）
结点类型有：cdrom、cd-rom、computer、disk array、pc、pc client、pc server、secure、server、storage、unix server、user pc，并在结点的右上角用不同的图标表示，如下图：
4、物件（Artifact）
物件是软件开发过程中的产物，包括过程模型（比如用例图、设计图等等）、源代码、可执行程序、设计文档、测试报告、需求原型、用户手册等等。物件表示如下，带有关键字 artifact 和文档图标
5、连接（Association）
结点之间的连线表示系统之间进行交互的通信路径，这个通信路径称为连接（Association），如下图所示，连接中有网络协议：
6、结点容器（Node as Container）
一个结点可以包括其他的结点，比如组件或者物件，则称此结点为结点容器（Node as Container）。如下图所示，结点（Node）包容了物件（Artifact）：
部署图与组件图密切相关，部署图是用来描述软件组件部署的硬件组件；而组件图是用来描述组件和显示了它们是如何在硬件中部署。
UML的设计主要是把重点放在系统的软件构件。但是，这两个图是使用特殊图表专注于软件组件和硬件组件。
所以大多数的 UML 图是用来处理逻辑组件，但把重点放在系统的硬件拓扑部署图。
以下是部署图的目的描述：
-
可视化系统的硬件拓扑。
-
描述用于部署软件组件的硬件组件。
-
描述运行时处理节点。
部署图对系统工程师是非常有用。一个高效的部署图是非常重要的，因为它控制以下参数：
-
性能
-
可扩展性
-
可维护性
-
可移植性
在绘制部署图前应确定以下构件：
-
节点
-
节点之间的关系
下列部署图是一个样品给订单管理系统的部署视图的想法，已经表明的节点：
-
监控
-
调制解调器
-
缓存服务器
-
服务器
假定应用程序是一个基于 Web 的应用程序部署在集群环境中使用服务器1，服务器2和服务器3。用户连接到使用互联网的应用程序。控制流从缓存服务器的集群环境中。
所以下面的部署图已经制定考虑到所有上述提到的几点：
部署图主要用于系统工程师。这些图用来描述的物理组件（硬件）以及它们的分布和关联。
为了阐述清楚细节，我们可以想像的硬件组件/节点上的软件组件位于部署图。
软件应用程序的开发需要复杂的业务流程模型。为了满足业务的需求，一个软件应用只做到高效是不够的，还应考虑到业务是否能够支持用户的不断增长以及响应的时间是否够快等。
软件应用程序可以是独立的，基于 Web，分布式，基于大型机和更多。
使用部署图可以描述如下：
-
为了模拟一个系统的硬件拓扑。
-
嵌入式系统建模。
-
为了模拟一个客户机/服务器系统的硬件的详细信息。
-
为了模拟硬件的分布式应用程序的细节。
-
正向和逆向工程。
用例图捕捉了模拟系统中的动态行为，并且描述了用户、需求以及系统功能单元之间的关系。
用例图展示了一个外部用户能够观察到的系统功能模型图。
用例图由主角，用例和它们之间的关系组成。
用例图的目的是捕捉到一个系统的动态方面。
用例图是用来收集系统的要求，包括内部和外部的影响。这些要求大多是设计要求。所以，分析一个系统时要收集其功能用例和确定参与者。
简单来说，用例图的目的如下：
-
用例图用来收集系统的要求。
-
用例图用于获取系统的外观图。
-
用例图识别外部和内部因素影响系统。
-
用例图显示要求之间的相互作用是参与者。
用例图被认为是高层次的需求分析系统。因此，当系统的要求，分析被捕获在用例的功能。
因此，我们可以说，使用情况是什么，但在一个有组织的方式编写的系统功能。现在到用例相关的第二件事情是参与者。行为者可以被定义为与系统进行交互的东西。
参与者可以是人的用户，一些内部的应用程序，或可能会有一些外部应用程序。因此，在一个简短的，当我们正计划绘制一个用例图中应该有以下项目:
-
功能被表示为一个用例
-
参与者
-
用例和参与者之间的关系。
绘制到用例图捕获系统的功能要求。因此，确定上述项目后，我们必须遵循以下指导原则，绘制一个有效的用例图。
-
一个用例的名称是非常重要的。所以名的选择应以这样的方式，以便它可以识别执行的功能。
-
给出一个合适的名参与者。
-
图中清楚地显示关系和依赖性。
-
不要试图包括所有类型的关系。由于该图的主要目的是确定要求。
-
使用注意以往任何时候都需要阐明一些重要的点。
下面是一个示例用例图，代表订单管理系统。因此，如果我们看看图，那么我们会发现三个用例（订单，特殊订单和正常订单）和一个参与者：顾客。
SpecialOrder 和_NormalOrder_ 从订单使用情况扩展。因此，他们扩展了关系。另外很重要的一点是确定系统边界，这是图中所示。参与者是客户以外的系统，因为它是系统的外部用户。
要了解一个系统的动态，我们需要使用不同类型的图表。用例图就是其中之一，其具体目的是收集系统的的需求和参与者。
用例图指定系统的事件和他们的流向。但从未用例图描述了他们是如何实现的。可以被想象成一个黑盒子，只有输入，输出和黑盒子的功能被称为用例图。
在这些图中使用的设计在一个非常高的水平。那么这种高层次的设计高雅，一遍又一遍完善使系统得到一个完整实用的图片。一个结构良好的用例，还介绍了前置条件，后置条件和例外。而这些多余的元素在执行测试时被用来制造测试的情况下。
用例都不是正向和反向工程，但他们仍然使用略有不同的方式。同样是真实的逆向工程。仍用例图的使用方式不同，使其逆向工程的一个候选。
在正向工程用例图是用来做测试案例和逆向工程中的使用情况下是用来准备从现有的应用程序的需求细节。
所以下面的地方使用用例图：
-
需求分析和高水平的设计。
-
模拟系统的上下文。
-
逆向工程。
-
Forward engineering.
-
UML 交互图描述的是对象之间的动态合作关系以及合作过程中的行为次序。
-
UML 交互图常常用来描述一个用例的行为，显示该用例中所涉及的对象以及这些对象之间的消息传递情况，即一个用例的实现过程。
-
UML 交互图包括两种：序列图和协作图。
-
序列图 ：显示对象之间的关系，强调对象之间消息的时间顺序，显示对象之间的交互。
-
协作图 ：描述对象之间的交互关系。
UML 交互图主要包括对象和消息两类元素，创建交互图的过程实际上就是向对象分配任务的过程，是可视化系统的交互行为。
由于可视化的交互是一个困难的任务，所以要使用不同类型的模型来捕获不同方面的相互作用，这也是序列图和时序图的作用。
总而言之，对交互图的描述如下：
-
交互图捕捉一个系统的动态行为；
-
交互图用来描述该系统中的消息流；
-
交互图用来描述对象的结构组织；
-
交互图是为了描述对象之间的互动。
我们已经了解了交互图的作用就是捕捉系统的动态环节。因此，关于动态捕捉，我们需要知道一个动态的环节是如何实现可视化的。
动态环节可以定义为在一个特定的时刻运行的系统快照。
在绘制交互图之前，确定以下条件：
-
参与互动的对象；
-
对象之间的消息流；
-
消息的顺序流程；
-
对象的组织。
下面描述了两个交互图建模的订单管理系统：第一个图是序列图，第二个图是协作图。
序列图中包含了四个对象：客户、订单、特殊订单和正常订单。
下面的关系图所示的消息序列为 SpecialOrder 对象和 NormalOrder 对象在相同的情况下使用。现在重要的是要了解时间顺序的消息流，与消息流无关，使用一个对象的方法调用。
首先调用的是 sendOrder（），这是一个订单对象的方法；在下一次调用 _confirm ()，_这是一个 SpecialOrder 对象的方法；最后调用 Dispatch ()，它是一种方法的 SpecialOrder 对象。所以这里的图主要描述方法从一个对象到另一个对象的调用，在系统运行时这也是实际情况：
协作图显示对象的组织，如下图所示。
这里协作图的方法调用序列是表示，由一些数字技术，如下所示。
该数字表示方法如何被称为此起彼伏。我们已经采取了相同的订单管理系统，协作图来描述。
这些调用方法类似的序列图。但不同的是，序列图中未介绍的对象组织，而协作图中示出的对象的组织。
现在选择这两个图表之间主要强调的是需求类型。如果时间序列是很重要的，那么序列图中被使用，并且，如果需要的组织，那么使用协作图。
我们现在来讨论交互图在实际情况中的应用。要了解实际应用中，我们需要了解的基本性质序列图和协作图。
这两个图的主要目的，是相似的，因为它们是用来捕捉系统的动态行为：序列图是用来捕获从一个对象到另一个消息流的顺序；协作图用来描述参与相互作用中的对象的结构组织。
一个单一的图是不足以说明整个系统的动态环节，这样的一套图是用来捕获一个整体。
使用交互图，当我们想要了解的消息流和组织结构。消息流装置控制流从一个对象到另一个序列和结构组织的装置，在一个系统中的元素的视觉组织。
以下是交互图的用法：
-
按时间顺序的控制流建模。
-
为了模拟流结构组织控制。
-
对于正向工程。
-
逆向工程。
UML 状态图是图表本身的名称，主要用于描述对象具有的各种状态、状态之间的转换过程以及触发状态转换的各种事件和条件。
UML 状态图描述了一个状态机，可以被定义为一台机器，它定义了一个对象，这些状态控制外部或内部事件的不同状态。
状态机由状态、转换、事件、活动和动作五部分组成。
- 状态：状态指的是对象在其生命周期中的一种状况，处于某个特定状态中的对象必然会满足某些条件、执行某些动作或者是等待某些事件。一个状态的生命周期是一个有限的时间阶段。
- 转换：转换指的是两个不同状态之间的一种关系，表明对象在第一个状态中执行一定的动作，并且在满足某个特定条件下由某个事件触发进入第二个状态。
- 事件：事件指的是发生在时间和空间上的对状态机来讲有意义的那些事情。事件通常会引起状态的变迁，促使状态机从一种状态切换到另一种状态，如信号、对象额度创建和销毁等。
- 活动：活动指的是状态机中进行的非原子操作。
- 动作：动作指的是状态机中可以执行的哪些原子操作。所谓原子操作，指的是他们在运行的过程中不能被其他消息中断，必须一直执行下去，以至最终导致状态的变更或者返回一个值。
UML 状态图可以捕获对象、子系统和系统的生命周期，可以告知一个对象可以拥有的状态，并且事件(如消息的接收，时间的流逝、错误、条件为真等)会怎样随着时间的推移来影响这些状态。一个状态图应该连接到所有具有清晰的可标志状态和复杂行为的类；该图可以确定类的行为以及该行为如何根据当前的状态而变化，也可以展示哪些事件将会改变类的对象的状态。
状态图主要是为了模拟响应系统。
以下是使用状态图的主要目的：
-
为了模拟系统的动态环节。
-
反应系统模型生命周期。
-
一个对象来描述不同的状态，在其生命周期的时间。
-
定义一个状态机模型状态的对象。
状态图是用来描述不同的对象在其生命周期的状态。因此，强调的是一些内部或外部事件的状态发生变化时，这些对象的状态要重要的分析和准确的贯彻落实。
状态图描述的状态是非常重要的。对象的状况，当发生特定事件时，可以被确定为状态。
绘制状态图之前，我们必须明确以下几点：
-
识别对象，以进行分析。
-
识别状态。
-
识别的事件。
一个状态图（Statechart Diagram）本质上就是一个状态机，或者是状态机的特殊情况，它基本上是一个状态机中元素的一个投影，这也就意味着状态图包括状态机的所有特征。
状态图描述了一个实体基于事件反映的动态行为，显示了该实体是如何根据当前所处的状态对不同的事件作出反应的。
在UML中，状态图由表示状态的节点和表示状态之间转换的带箭头的直线组成。状态的转换由事件触发，状态和状态之间由转换箭头连接。每一个状态图都有一个初始状态（实心圆），用来表示状态机的开始。还有一个中止状态（半实心圆），用来表示状态机的终止。状态图主要由元素状态、转换、初始状态、中止状态和判定等组成，一个简单的状态图如下：
1.状态：状态用于对实体在其生命周期中的各种状况进行建模，一个实体总是在有限的一段时间内保持一个状态。状态由一个带圆角的矩形表示，状态的描绘素应该包括名称、入口和出口动作、内部转换和嵌套状态。如下图，为一个简单状态：
- 状态名指的是状态的名字，通常用字符串表示，其中每个单词的首字母大写。状态名可以包含任意数量的字母、数字和除了冒号“：”以外的一些字符，可以较长，甚至连续几行。但是一定要注意一个状态的名称在状态图所在的上下文中应该是唯一的，能够把该状态和其他状态区分开。
- 入口和出口动作一个状态可以具有或者没有入口和出口动作。入口和出口动作分别指的是进入和退出一个状态时所执行的“边界”动作。
- 内部转换指的是不导致状态改变的转换。内部转换中可以包含进入或者退出该状态应该执行的活动或动作。
- 嵌套状态状态分为简单状态（Simple State）和组成状态（Composite State）。简单状态是指在语义上不可分解的、对象保持一定属性值的状况，简单状态不包含其他状态：而组成状态是指内部嵌套有子状态的状态，在组成状态的嵌套状态图部分包含的就是此状态的子状态。
2.转换：在UML的状态建模机制中，转换用带箭头的直线表示，一端连接源状态，箭头指向目标状态。转换还可以标注与此转换相关的选项，如事件、监护条件和动作等，如下图所示。注意：如果转换上没有标注触发转换的事件，则表示此转换自动进行。
在状态转换机制中需要注意的五个概念如下：
- 状态源（Source State）：指的是激活转换之间对象处于的状态。如果一个一个状态处于源状态，当它接收到转换的触发事件或满足监护条件时，就激活了一个离开的转换。
- 目标状态（Event State）：指的是转换完成后对象所处的状态。
- 事件触发器（Event Trigger）：指的是引起源状态转换的事件。事件不是持续发生的，它只发生在时间的一点上，对象接收到事件，导致源状态发生变化，激活转换并使监护条件得到满足。
- 监护条件（Guard Condition）：是一个布尔表达式。当接收到触发事件要触发转换时，要对该表达式求值。如果表达式为真，则激活转换：如果表达式为假，则不激活转换，所接收到的触发事件丢失。
- 动作（Action）：是一个可执行的原子计算。
3.初始状态：每个状态图都应该有一个初始状态，它代表状态图的起始位置。初始状态是一个伪状态（一个和普通状态有连接的假状态），对象不可能保持在初始状态，必须要有一个输出的无触发转换（没有事件触发器的转换）。通常初始状态上的转换是无监护条件的，并且初始状态只能作为转换的源，而不能作为转换的目标。在UML中，一个状态图只能有一个初始状态，用一个实心圆表示。
4.终止状态：终止状态是一个状态图的终点，一个状态图可以拥有一个或者多个终止状态。对象可以保持在终止状态，但是终止状态不可能有任何形式的和触发转换，它的目的就是为了激发封装状态上的转换过程的结束。因此，终止状态只能作为转换的目标而不能作为转换的源，在UML中，终止状态用一个含有实心圆的空心圆表示。
5.判定：活动图和状态图中都有需要根据给定条件进行判断，然后根据不同的判断结果进行不同转换的情况。实际就是工作流在此处按监护条件的取值发生分支，在UML中，判定用空心菱形表示。
状态图的作用主要体现在以下几个方面。
- 状态图清晰地描述了状态之间的转换顺序，通过状态的转换顺序也就可以清晰地看出事件的执行顺序。如果没有状态图我们就不可避免地要使用大量文字来描述外部事件的合法顺序。
- 清晰的事件顺序有利于程序员在开发程序时避免出现事件顺序错误的情况。例如，对于一个网上销售系统，在用户处于登录状态前是不允许购买商品的，这就需要程序员开发程序的过程中加以限制。
- 状态图清晰地描述了状态转换时所必需的触发事件、监护条件和动作等影响转换的因素，有利于程序员避免程序中非法事件的进入。例如，飞机起飞前半小时不允许售票，在状态图中就可以清晰地看到，可以提醒程序员不要遗漏这些限制条件。
- 状态图通过判定可以更好地描述工作流因为不同的条件发生的分支。例如，当一个班的人数少于10人的时候需要和其他班合为一班上课，大于10人则单独上课，在状态图中就可以很明确地表达出来。
总之一个简洁完整的状态图可以帮助一个设计者不遗漏任何事情，最大程度地避免程序中错误的发生。
UML 活动图是 UML 的动态模型的一种图形，一般用来描述相关用例图。
UML 活动图描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动。
UML 活动图是一种特殊的状态图，它对于系统的功能建模特别重要，强调对象间的控制流程。
UML 活动图是一种表述过程基础、业务过程以及工作流的技术。它可以用来对业务过程、工作流建模，也可以对用例实现甚至是程序实现来建模
UML 活动图基本上是代表流程形成一个活动到另一个活动的流程图。活动可以被描述为一个系统的操作。
UML 活动图能够捕捉到该系统的动态行为，UML 中其它的四个图是用来显示从一个对象到另一个消息流，但活动图是用来显示消息流从一个活动到另一个活动图。
活动图不仅用于可视化系统的动态性质，也可用于通过使用正向和逆向工程技术来构建可执行的系统。唯一缺少的东西在活动图的消息部分。
它并不显示任何消息流程从一个活动到另一个。活动图是一段时间视为流程图。虽然图中看起来像一个流程图，但事实并非如此。它显示不同的流程，如并行，分支，并发流。
以下是 UML 活动图目的描述：
-
绘制活动流程系统。
-
描述的顺序从一个活动到另一个。
-
描述系统并行，分支，并发流。
活动图主要用于为流程图包括由系统执行的活动，但活动图是不完全的，因为他们有一些额外的功能流程图。这些额外的功能，包括分支，平行流，泳道等。
绘制活动图之前，我们得知道活动图的主要元素是活动本身，一个活动是由系统执行的功能。确定活动后，我们需要了解他们是如何相关的约束和条件。
所以在绘制活动图，我们应该确定以下要素：
-
活动
-
交互
-
条件
-
约束
上述参数确定后，我们需要做一个心理布局整个流程。这种心理的布局转化成一个活动图。
下面是一个订单管理系统的活动图的例子，在图中确定了四个活动都与条件。
其中重要的一点应该清楚地了解活动图不能完全匹配的代码。活动图了解活动流程，主要用于企业用户。
下图绘制的四个主要活动：
-
由客户发送订单
-
收到订单
-
确认订单
-
分发订单
收到订单后请求状态进行检查，以检查它是否是正常的或特殊的顺序。不同的顺序确定之后，执行调度活动，并标记为终止进程。
活动图是适用于该系统的活动流程建模。应用程序可以有多个系统。活动图也抓住了这些系统，并介绍了流程从一个系统到另一个。在其他图中，这个特定的用法，不提供。这些系统可以是数据库，外部队列或任何其他系统。
现在，我们将看看活动图到实际应用。从上面的讨论，很显然，活动图是来自一个非常高的级别。因此，它给出了一个系统的高级视图。这种高层次的观点主要是针对企业用户或任何其他人而不是一个技术人员。
以下是活动图的主要用途：
-
使用业务建模工作流程。
-
建模的业务需求。
-
高层次的理解系统的功能。
-
调查在后一阶段的业务需求。
UML 2.0 中增加了新的功能，所以它的使用可以更广泛。
UML 2.0 将正式和完全定义语义的定义。这种新的可能性可以用于模型的开发，并从这些模型可以产生相应的系统。但要利用这个新的层面，必须作出相当大的努力，获得知识。
UML 的结构和文档 UML2.0 的最新版本进行了全面修订。现在有两个文件，描述 UML：
-
UML2.0 结构的定义是基于 UML 语言的基本结构。本节是 UML 的用户并不直接相关。这是指向对建模工具的开发。所以，这方面不在本节的范围内。
-
UML2.0 上盖定义 UML2.0 的用户结构。这意味着这些用户将立即使用的 UML 元素。因此，这是UML的用户群体的主要焦点。
UML 2.0 创建完成一个目标，调整和完善 UML，以便简化可用性，实施和适应。
使用 UML 基础设施：
-
提供了一个可重用的元语言的核心。这是用来定义 UML 本身。
-
提供机制调整的语言。
使用 UML 上层建筑：
-
基于组件的发展提供更好的支持。
-
提高架构规范构造。
-
提供更好的选择行为建模。
所以很重要的一点要注意的是上述的主要分部。这些区划是用来增加UML的可用性和定义清楚地了解它的用法。
另外一个方面，已经提出了这个新版本。它是一个完全新的对象约束语言（OCL）和图交汇处的建议。这些功能都一起形成完整的UML2.0包。
UML2.0 中描述的交互图与旧版本相比有所不同，主要的区别是增强和附加功能添加到 UML2.0 图。
UML2.0 模型对象以四个不同的方式互动：
-
通过序列图中的对象之间的交互来完成，系统的行为目标是一个随时间变化的图。时间序列是类似于早期版本的序列图。在系统内的设计上的交互，可以在任何级别的抽象设计，从子系统交互的实例级。
-
UML2.0 中添加了一个新的名字：通信图。通信图是对象之间的消息传递，来自于 UML1.4 的协作图和更早的版本概念的结构图。这可以定义为协作图的修改版本。
-
UML2.0 也是一个新的互动概述图。一组组合成一个逻辑顺序的相互作用，包括流量控制逻辑之间的互动导航的互动概述图描述了一个高层次的。
-
UML2.0 还增加了时序图。这是一个可选的设计的一个交互的过程中发送和接收的消息中指定的时间限制的图。
因此，从上面的描述中，重要的是要注意，所有的图的目的是发送/接收消息。载入这些消息的装卸内部的对象。所以对象也有接收和发送邮件的选项，这里谈到的另一个重要方面称为接口。现在，这些接口是负责接受和发送消息到另一个。
因此，从上面的讨论可以得出结论，UML2.0中相互作用以不同的方式描述的，这就是为什么进入图片所遇到的新的图名。但是，如果我们分析了新的图，那么很显然，根据在早期版本中所描述的交互图创建的所有图。唯一的区别是UML2.0添加附加功能。使图更高效和目的导向。
正如我们已经讨论过的，协作是用来模拟常见的物体之间的相互作用。要阐明的话，我们可以说，协作是互动对象由一组消息预先定义的角色。
最重要的一点要注意的是协作图的早期版本，并在UML2.0版本之间的差异。因此，区分协作图名称已更改于UML2.0。它被命名为UML2.0通信图。
因此，协作被定义为一类的属性（属性）和行为（操作）。的协作类上的隔间可以用户定义的也可用于相互作用（时序图）的构成要素（组合结构图）。
下图模型的观察者设计模式之间的协作对象观察到的项目中的作用，以及任何数量的观察员的对象。
通信图协作图的早期版本略有不同。我们可以说，它是一个缩减版的早期版本的UML。通信图的区别因素是在对象之间的链接。
这是一个可视化的链接，它缺少的序列图。在序列图只显示对象之间传递的消息，即使有它们之间没有联系。
通信图是建模人员是用来防止这样的错误，通过使用一个对象图的格式作为消息传递的基础。通信图上每个对象被称为对象生命线。
通信图的消息类型是相同的序列图。通信图可以模拟同步，异步，返回，丢失，发现，和对象的创建消息。
下图显示了三个对象的对象图和两个环节，形成了基础通信图是。通信图是上每个对象被称为对象生命线。
在实际使用中，一个单一的场景的序列图是用来模型。所以使用序列图来完成整个应用程序。当一个单一的场景建模，它有可能忘记的全过程并且这可能带来误差。
因此，要解决这个问题，新的互动概述结合的控制流图，活动图，序列图和消息规范。
活动图使用活动对象流来形容一个过程。互动概述图使用相互作用和交互出现。序列图中的生命线和消息只出现内相互作用或相互作用的发生。然而，参与的互动概述图的生命线（对象）可能被列为图名。
下图显示了一个决定帧和终止点的交互概览图
此图中本身的名称，描述图中的目的。它基本上是涉及在其整个生命周期中的事件的时间。
因此，可以被定义为一个时序图，把重点放在其使用寿命中的一个对象的事件的特殊目的的交互图。它基本上是一个混合的状态机和交互图。时序图使用下面的时间线：
-
状态的时间线
-
一般值的时间线
在时序图中的生命线一帧的内容区域内形成一个长方形的空间。它通常是水平对齐读取由左到右。在同一帧内，也可以层叠多个生命线，它们之间的相互作用模型。
UML2.0 是一个增强版本的新功能被添加到使它更可用，高效。在UML2.0的主要有两大类，一个是UML超级结构和另一个是UML基础设施。虽然新的图表是基于旧的观念，但他们仍然有额外的功能。
UML2.0 提供了四个交互图，序列图，通信图，交互概览图，和一个可选的时序图。所有四个图使用的帧符号括起来的相互作用。使用框架支持重用的相互作用发生的相互作用。