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