UML九种标准图详解_uml图-CSDN博客

本文链接：https://blog.csdn.net/leesinbad/article/details/128888351

在 UML 中元素以不同的方式，表达了不同的图表，我们通过不同类型的图片或者图表可以很直观的了解任何复杂的系统，这种方法以不同的形式被广泛应用到不同的行业中。

一个单一的图涵盖所有方面的制度是不够的，因此，UML 定义了各种图表覆盖系统方面。

我们将 UML 中的图分为两大类：

结构图

行为图

一、UML 结构图：

UML 结构图表示系统的静态方面。这些静态方面指示，形成的主要结构并因此稳定那些部分。

这些静态部分是类，接口，对象，组件和节点四个结构图：

类图

对象图

组件图

部署图

1、UML 类图概述:

类图（Class Diagram）是面向对象系统建模中最常用和最重要的图，是定义其它图的基础。类图主要是用来显示系统中的类、接口以及它们之间的静态结构和关系的一种静态模型。类图不仅用于可视化描述和记录系统的不同方面，也为构建可执行代码的软件应用程序。类图描述一类的属性和操作，也对系统的约束。被广泛应用于类图的建模的面向对象的系统中，因为它们是唯一的，可以直接映射到面向对象的语言的 UML 图。

类图显示集合的类，接口，关联，协作和约束，它也被称为作为结构图。

1.1 UML 类图的目的:

类图的目的是模型的一个应用程序的静态视图。

类图是唯一的图可以直接映射到面向对象的语言，因此广泛应用于施工时间。

UML图，像活动图，序列图图只能给应用程序，但顺序流类图是一个有点不同。所以它是最流行的 UML 图编码社区。

因此，类图的目的可概括为：

分析和设计应用程序的静态视图。

描述一个系统的责任。

基地组件图和部署图。

正向和逆向工程。

1.2如何画类图？

UML 类图是软件行业经常需要的一项技能。许多项目立项文档、需求分析等文档中，都会有关UML类图的涉及，所以，学习UML类图的绘制至关重要。绘制类图时需要考虑的属性较多，这里的图将被视为从顶层视图。类图基本上是一个系统的静态视图的图形表示，代表不同方面的应用。因此，集合类图表示整个系统。

在画类图时要牢记以下几点：

类图中的名称应该是有意义的描述，并且是面向系统的。

画类图前应先确定每个元素之间的关系。

类图中的每个类职责（属性和方法）应该清晰标明。

对于每个类的属性的最小数量应符合规定，不必要的属性将使图表复杂。

使用了以下注释有否要求来描述图中的某些方面。因为上面的附图，它应该是可以理解的开发者/编码器。

最后，在最终版本之前，该图应绘制在普通纸上尽可能多次，使其纠正和返工。下图是一个二阶系统的一个应用程序的一个例子，它描述了整个应用程序的一个特定方面：

系统中的两个要素是所有订单以及客户，他们有一个一对多的关系，因为一个客户可以有多个订单。

我们将保持 Order 类是一个抽象类，它有两个具体的类（继承关系）SpecialOrder 和 ormalOrder。

两个继承类 Order 类的所有属性。此外，他们有额外的功能 dispatch () 和 receive ().

因此，下面的类图已经绘就考虑到所有上述提到的几点：

1.3在哪里使用类图？

类图是一个静态图，它是用来模拟一个系统的静态视图，也被认为是类图作为基础组件图和部署图。

类图不仅用于可视化系统的静态视图，但它们也可用于构建可执行代码的任何系统中的前向和反向工程。

UML 图一般不直接映射到任何面向对象的编程语言，但在类图是一个例外。

类图清楚地显示了映射面向对象语言，如Java，C++等，因此，从实际经验的类图通常用于构建用途。

因此类图可以用来：

描述系统的静态视图。

显示静态视图中的元素之间的协作。

由系统执行的功能的描述。

构建软件应用面向对象的语言。

2、UML 对象图概述:

UML 对象图和类图一样反映系统的静态过程，但它是从实际的或原型化的情景来表达的。

UML 对象图显示某时刻对象和对象之间的关系。一个UML对象图可看成一个类图的特殊用例，实例和类可在其中显示。

UML 对象图是类图的实例，几乎使用与类图完全相同的标识。

由于对象存在生命周期，因此UML对象图只能在系统某一时间段存在。

2.1 UML 对象图目的:

对象图的目的与类图类似。

不同的是，一个类图代表一个抽象的模型，包括类和它们之间的关系。但是，由于对象存在生命周期，因此UML对象图只能在系统某一时间段存在。

这意味着对象图是更接近实际的系统行为。目的是在一个特定的时刻捕捉到静态的系统视图。

对象图的目的概述如下：

正向和逆向工程。

一个系统的对象间的关系

一个交互的静态视图。

了解对象的行为和他们的关系从实用的角度来看

2.2 如何绘制对象图？

我们已经讨论过的一个对象图是类图的一个实例。它意味着一个对象图包含在类图中所用的东西的实例。

所以，对象图和类图的基本元素是相同的，不同的只是形式的差别。在类图中的元素是抽象的形式来表示蓝图，并在对象图中元素的具体形式来表示真实世界中的对象。

为了捕捉一个特定的系统，类图的数量是有限的。但是，如果我们考虑对象图，那么我们就可以有无限数量的实例在本质上是独一无二的。因此，只有这些情况下被认为是对系统的影响。

从上面的讨论，很显然，一个单一的对象图不能捕获所有必要的实例，而不能指定一个系统的所有对象。因此，解决方案是：

首先，分析系统，并决定哪些情况下有重要的数据和关联。

其次，只考虑那些实例将涵盖功能。

第三，做一些优化实例的数量是无限的。

绘制对象图之前，应该记住以下事情，并清楚地理解：

对象图的主要内容是对象。

对象图中的链接是用来连接对象。

对象和链接的两个要素，用于构造一个对象图。

在开始构建图前，下列事项要明确：

对象图的名称要有意义，以表明其目的。

最重要的要素是要确定。

对象之间的关联，应该予以明确。

不同元素的值需要捕获包含在对象图。

添加适当的注释，需要更清晰点。

下面的图是一个对象图的一个例子。它代表了订单管理系统，我们已经讨论了在类图。下图是该系统的一个实例，在一个特定的时间购买。它具有以下的对象

顾客

订单

特殊订单

一般订单

现在客户对象（C）是与三阶对象（O1，O2和O3）。这些订单对象相关联的特殊订单和一般订单对象（S1，S2和N1）。顾客具有以下三个具有不同数目的订单（12，32和40），用于所考虑的特定的时间。

现在，客户可以在将来增加的订单数量，在这种情况下对象图将反映。如果订单、特殊订单和正常秩订单对象那么观察会发现，他们有一些值。

订单的值是12，32和40，这意味着，这些对象都拥有这些实例时，捕获特定时刻的值（这里是购买时的时刻被视为特定时间）。

相同特别订订单和正常订单对象所具有的订单数分别为20，30和60。如果被认为是一个不同的时间购买，那么这些值将发生相应的变化。

因此，下面的对象图已经绘就考虑到所有上述提到的几点：

2.3在哪里使用对象图？

对象图可以被想象成正在运行的系统在某一时刻的快照。我们可以举一个例子来描述它：一个正在运行的列车。

现在，如果运行一个单元列车运行，那么会发现它具有以下静态图片：

这是一个特别的运行状态

一个特定的乘客数量。如果捕捉在不同的时间，这将在不断改变。

所以，在这里我们可以想像的列车运行的管理单元是一个对象，具有上述值。任何现实生活中的简单或复杂的系统而且的确如此。

对象图可用于：

使一个系统的原型。

逆向工程。

造型复杂的数据结构。

从实用的角度了解系统。

捕捉实例和链接。

详细描述瞬态图。

3、UML 组件图概述:

UML 组件图（Component Diagram）又称为构件图，他描述的是在软件系统中遵从并实现一组接口的物理的、可替换的软件模块。

组件图 = 构件（Component）+接口（Interface）+关系（Relationship）+端口（Port）+连接器（Connector）

UML 组件图给提供了将要建立的系统的高层次的架构视图，这将帮助开发者开始建立实现的路标，并决定关于任务分配及（或）增进需求技能。

3.1 UML 组件图目的:

组件图是一种特殊的 UML 图。与我们之前讨论的 UML 图标的目的都不同。组件图不描述该系统的功能，但它描述了用于使这些功能的组件。

所以从这一点来说，组件图用于可视化在一个系统中的物理组件。这些组件包括库，程序包，文件等。

组件图也被描述为一个静态的实施的系统视图，在一个特定的时刻，静态执行代表组织的组成部分。

一个单一的组件图不能代表整个系统，但图的集合可用来代表整个。

组件图的目的概括如下：

可视化系统的组成部分。

构建的可执行文件，使用正向和反向工程。

描述的组织和组件的关系。

3.2如何绘制组件图？

组件图是用来描述一个系统的物理构件。此神器包括文件，可执行文件，库等。所以这张图的目的是不同的，组件图的过程中使用的应用程序的实施阶段。但它准备提前以可视化的实现细节。最初，系统的设计使用不同的UML图，然后构件是现成的组件图是用来得到一个想法的实现。

此图是非常重要的，因为如果没有它，应用程序不能有效地实施。精心准备的组件图在其他方面也是很重要的，如应用程序的性能，维护等

所以在绘制组件图后的工件是清楚可辨：

在系统中使用的文件。

库和其他构件的申请有关。

构件之间的关系。

下面是一个订单管理系统的组件图，其中的构件是文件。所以，该图显示了在应用程序的文件以及它们之间的关系。在实际组件图还包含 dll 文件，库，文件夹等。在下面的图中，四个文件识别，并产生了它们之间的关系。到目前为止讨论与其他 UML 图，组件图不能直接匹配。因为它是得出完全不同的目的。

所以下面的组件图已经绘就考虑到所有上述提到的几点：

3.3 在哪里使用组件图？

UML 组件图经常是一个架构师在项目的初期就建立的非常重要的图，它是无价的，因为它们模型化和文档化了一个系统的架构。UML 组件图文档化了系统的架构，开发者和系统可能的系统管理员会发现这一工作的关键产品有助于他们理解系统。UML 组件图也视为软件系统配置图的输入，这将会是本系列后面的文章主题。我们已经说过组件图可用于可视化系统的静态实现视图，它是特殊类型的 UML 图，它描述了在一个系统中的组件组织。组织机构可以进一步描述为在一个系统中的组件的位置。这些组件是在一个特殊的组织方式，以满足系统要求。正如我们已经讨论过这些组件库，文件，可执行文件等，现在组织实施这些组件的应用程序。

组件图的使用可以被描述为：

组件建模的一个系统。

模型的数据库架构。

模型的应用程序的可执行文件。

模型系统的源代码。

4、UML 部署图概述:

部署图由节点以及节点之间的关系组成。

部署图描述的是系统运行时的结构，展示了硬件的配置及其软件如何部署到网络结构中。

部署图通常用来帮助理解分布式系统，一个系统模型只有一个部署图。

部署图用于可视化的软件组件部署的系统中的物理组件的拓扑结构。

部署图是用来描述一个系统的静态部署视图。

4.1 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）：

4.2 UML 部署图目的:

部署图与组件图密切相关，部署图是用来描述软件组件部署的硬件组件；而组件图是用来描述组件和显示了它们是如何在硬件中部署。

UML的设计主要是把重点放在系统的软件构件。但是，这两个图是使用特殊图表专注于软件组件和硬件组件。

所以大多数的 UML 图是用来处理逻辑组件，但把重点放在系统的硬件拓扑部署图。

以下是部署图的目的描述：

可视化系统的硬件拓扑。

描述用于部署软件组件的硬件组件。

描述运行时处理节点。

4.3 如何绘制 UML 部署图？

部署图对系统工程师是非常有用。一个高效的部署图是非常重要的，因为它控制以下参数：

性能

可扩展性

可维护性

可移植性

在绘制部署图前应确定以下构件：

节点

节点之间的关系

下列部署图是一个样品给订单管理系统的部署视图的想法，已经表明的节点：

监控

调制解调器

缓存服务器

服务器

假定应用程序是一个基于 Web 的应用程序部署在集群环境中使用服务器1，服务器2和服务器3。用户连接到使用互联网的应用程序。控制流从缓存服务器的集群环境中。

所以下面的部署图已经制定考虑到所有上述提到的几点：

4.4 在哪里使用部署图？

部署图主要用于系统工程师。这些图用来描述的物理组件（硬件）以及它们的分布和关联。

为了阐述清楚细节，我们可以想像的硬件组件/节点上的软件组件位于部署图。

软件应用程序的开发需要复杂的业务流程模型。为了满足业务的需求，一个软件应用只做到高效是不够的，还应考虑到业务是否能够支持用户的不断增长以及响应的时间是否够快等。

软件应用程序可以是独立的，基于 Web，分布式，基于大型机和更多。

使用部署图可以描述如下：

为了模拟一个系统的硬件拓扑。

嵌入式系统建模。

为了模拟一个客户机/服务器系统的硬件的详细信息。

为了模拟硬件的分布式应用程序的细节。

正向和逆向工程。

二、UML 行为图：

任何系统都可以有两个方面，静态和动态。因此，一个模型被认为是完成时，这两个方面都完全覆盖。

行为图基本上捕捉系统的动态方面。动态方面可以进一步改变/移动系统的一部分。

UML具有以下五种行为图：

用例图

序列图

协作图

状态图

活动图

1、UML 用例图概述:

用例图捕捉了模拟系统中的动态行为，并且描述了用户、需求以及系统功能单元之间的关系。

用例图展示了一个外部用户能够观察到的系统功能模型图。

用例图由主角，用例和它们之间的关系组成。

1.1 UML 用例图的目的:

用例图的目的是捕捉到一个系统的动态方面。

用例图是用来收集系统的要求，包括内部和外部的影响。这些要求大多是设计要求。所以，分析一个系统时要收集其功能用例和确定参与者。

简单来说，用例图的目的如下：

用例图用来收集系统的要求。

用例图用于获取系统的外观图。

用例图识别外部和内部因素影响系统。

用例图显示要求之间的相互作用是参与者。

1.2 如何画用例图？

用例图被认为是高层次的需求分析系统。因此，当系统的要求，分析被捕获在用例的功能。

因此，我们可以说，使用情况是什么，但在一个有组织的方式编写的系统功能。现在到用例相关的第二件事情是参与者。行为者可以被定义为与系统进行交互的东西。

参与者可以是人的用户，一些内部的应用程序，或可能会有一些外部应用程序。因此，在一个简短的，当我们正计划绘制一个用例图中应该有以下项目:

功能被表示为一个用例

参与者

用例和参与者之间的关系。

绘制到用例图捕获系统的功能要求。因此，确定上述项目后，我们必须遵循以下指导原则，绘制一个有效的用例图。

一个用例的名称是非常重要的。所以名的选择应以这样的方式，以便它可以识别执行的功能。

给出一个合适的名参与者。

图中清楚地显示关系和依赖性。

不要试图包括所有类型的关系。由于该图的主要目的是确定要求。

使用注意以往任何时候都需要阐明一些重要的点。

下面是一个示例用例图，代表订单管理系统。因此，如果我们看看图，那么我们会发现三个用例（订单，特殊订单和正常订单）和一个参与者：顾客。

SpecialOrder 和NormalOrder 从订单使用情况扩展。因此，他们扩展了关系。另外很重要的一点是确定系统边界，这是图中所示。参与者是客户以外的系统，因为它是系统的外部用户。

1.3用例图怎么使用？

要了解一个系统的动态，我们需要使用不同类型的图表。用例图就是其中之一，其具体目的是收集系统的的需求和参与者。

用例图指定系统的事件和他们的流向。但从未用例图描述了他们是如何实现的。可以被想象成一个黑盒子，只有输入，输出和黑盒子的功能被称为用例图。

在这些图中使用的设计在一个非常高的水平。那么这种高层次的设计高雅，一遍又一遍完善使系统得到一个完整实用的图片。一个结构良好的用例，还介绍了前置条件，后置条件和例外。而这些多余的元素在执行测试时被用来制造测试的情况下。

在正向工程用例图是用来做测试案例和逆向工程中的使用情况下是用来准备从现有的应用程序的需求细节。

所以下面的地方使用用例图：

需求分析和高水平的设计。

模拟系统的上下文。

逆向工程。

Forward engineering.

2、UML 交互图概述:

UML 交互图描述的是对象之间的动态合作关系以及合作过程中的行为次序。

UML 交互图常常用来描述一个用例的行为，显示该用例中所涉及的对象以及这些对象之间的消息传递情况，即一个用例的实现过程。

UML 交互图包括两种：序列图和协作图。

序列图：显示对象之间的关系，强调对象之间消息的时间顺序，显示对象之间的交互。

协作图：描述对象之间的交互关系。

2.1 UML 交互图作用:

UML 交互图主要包括对象和消息两类元素，创建交互图的过程实际上就是向对象分配任务的过程，是可视化系统的交互行为。

由于可视化的交互是一个困难的任务，所以要使用不同类型的模型来捕获不同方面的相互作用，这也是序列图和时序图的作用。

总而言之，对交互图的描述如下：

交互图捕捉一个系统的动态行为；

交互图用来描述该系统中的消息流；

交互图用来描述对象的结构组织；

交互图是为了描述对象之间的互动。

2.2 UML 交互图如何绘制？

我们已经了解了交互图的作用就是捕捉系统的动态环节。因此，关于动态捕捉，我们需要知道一个动态的环节是如何实现可视化的。

动态环节可以定义为在一个特定的时刻运行的系统快照。

在绘制交互图之前，确定以下条件：

参与互动的对象；

对象之间的消息流；

消息的顺序流程；

对象的组织。

下面描述了两个交互图建模的订单管理系统：第一个图是序列图，第二个图是协作图。

3、序列图：

序列图中包含了四个对象：客户、订单、特殊订单和正常订单。

下面的关系图所示的消息序列为 SpecialOrder 对象和 NormalOrder 对象在相同的情况下使用。现在重要的是要了解时间顺序的消息流，与消息流无关，使用一个对象的方法调用。

首先调用的是 sendOrder（），这是一个订单对象的方法；在下一次调用 confirm ()，这是一个 SpecialOrder 对象的方法；最后调用 Dispatch ()，它是一种方法的 SpecialOrder 对象。所以这里的图主要描述方法从一个对象到另一个对象的调用，在系统运行时这也是实际情况：

4、协作图：

协作图显示对象的组织，如下图所示。

这里协作图的方法调用序列是表示，由一些数字技术，如下所示。

该数字表示方法如何被称为此起彼伏。我们已经采取了相同的订单管理系统，协作图来描述。

这些调用方法类似的序列图。但不同的是，序列图中未介绍的对象组织，而协作图中示出的对象的组织。

现在选择这两个图表之间主要强调的是需求类型。如果时间序列是很重要的，那么序列图中被使用，并且，如果需要的组织，那么使用协作图。

5、使用交互图的场合

我们现在来讨论交互图在实际情况中的应用。要了解实际应用中，我们需要了解的基本性质序列图和协作图。

这两个图的主要目的，是相似的，因为它们是用来捕捉系统的动态行为：序列图是用来捕获从一个对象到另一个消息流的顺序；协作图用来描述参与相互作用中的对象的结构组织。

一个单一的图是不足以说明整个系统的动态环节，这样的一套图是用来捕获一个整体。

使用交互图，当我们想要了解的消息流和组织结构。消息流装置控制流从一个对象到另一个序列和结构组织的装置，在一个系统中的元素的视觉组织。

以下是交互图的用法：

按时间顺序的控制流建模。

为了模拟流结构组织控制。

对于正向工程。

逆向工程。

6、UML 状态图概述:

UML 状态图是图表本身的名称，主要用于描述对象具有的各种状态、状态之间的转换过程以及触发状态转换的各种事件和条件。

UML 状态图描述了一个状态机，可以被定义为一台机器，它定义了一个对象，这些状态控制外部或内部事件的不同状态。

状态机由状态、转换、事件、活动和动作五部分组成。

状态：状态指的是对象在其生命周期中的一种状况，处于某个特定状态中的对象必然会满足某些条件、执行某些动作或者是等待某些事件。一个状态的生命周期是一个有限的时间阶段。

转换：转换指的是两个不同状态之间的一种关系，表明对象在第一个状态中执行一定的动作，并且在满足某个特定条件下由某个事件触发进入第二个状态。

事件：事件指的是发生在时间和空间上的对状态机来讲有意义的那些事情。事件通常会引起状态的变迁，促使状态机从一种状态切换到另一种状态，如信号、对象额度创建和销毁等。

活动：活动指的是状态机中进行的非原子操作。

动作：动作指的是状态机中可以执行的哪些原子操作。所谓原子操作，指的是他们在运行的过程中不能被其他消息中断，必须一直执行下去，以至最终导致状态的变更或者返回一个值。

6.1 UML 状态图的目的:

UML 状态图可以捕获对象、子系统和系统的生命周期，可以告知一个对象可以拥有的状态，并且事件(如消息的接收，时间的流逝、错误、条件为真等)会怎样随着时间的推移来影响这些状态。一个状态图应该连接到所有具有清晰的可标志状态和复杂行为的类；该图可以确定类的行为以及该行为如何根据当前的状态而变化，也可以展示哪些事件将会改变类的对象的状态。

状态图主要是为了模拟响应系统。

以下是使用状态图的主要目的：

为了模拟系统的动态环节。

反应系统模型生命周期。

一个对象来描述不同的状态，在其生命周期的时间。

定义一个状态机模型状态的对象。

6.2 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中，判定用空心菱形表示。