活动图
活动图描述了为了完成某一个目标需要做的活动以及这些活动的执行顺序。UML中有两个层面的活动图，一种用于描述用例场景，另一种用于描述对象交互。
活动图引发的困惑
一方面， 活动图实际上描述的是业务流程，是一种过程化的分析 *** ，很多人担心面向过程的活动图引入会导致面向对象的类职责的混乱，这种担心是有道理的。在面向对象的眼中是没有业务流程这种东西的，所谓流程只不过是在某个外部力量推动下对象之间相互交流的一个过程，它只是“瞬时”的。如果从活动图的观点来描述业务，实际上是不能直接看到对象是如何发挥作用的。这样在观念上很容易导致对象独立性被破坏，例如有的设计者可能会试图得到一个从头到尾参与了整个业务流程的“对象”。
另一方，在UML中引入活动图可能也是不可避免的，对象主要是在建模和设计阶段才会出现，而在面向业务人员进行交流的时候，他们是很难理解“对象”这个概念的。强迫他们理解“对象”，徒增他们的成本，从他们的角度出发，他们主要以“过程化”的方式把业务讲述清楚。进行了对象化的建模和设计以后，我们也要利用过程化的业务流程来验证设计是不是可行的。
活动图在描述用例场景时是十分有效的工具，但需要建模者自己要避免被过程化的观点所困扰，活动图只是用来描述业务目标的达成过程并借此来发现对象的工具，它不是我们的分析目标，也不是编程的依据，它只是对象的应用场景之一。我们使用活动图来描述用例场景，帮助我们认识问题领域，从问题领域中发现关键的对象，然后就应该把活动图中的流程忘掉，而专心研究关键对象的特性。最后，验证一下这些关键对象的某个交互结果是否能够达到用例场景所描述的业务目标。
活动图的基本元素
起始点（Initial）。起点标记业务流程的开始。一个活动图，或者说一个业务流程有且仅有一个起始点。结束点（Final）。结束点表示业务流程的终止。一个活动图（或者说一个业务流程）可以有一个或多个结束点。结束点可以分为活动终止节点（activity final nodes）和流程终止节点（flow final nodes）。活动终止节点表示整个活动的结束而流程终止节点表示是子流程的结束。动作状态（Action）—— 动作状态是指原子的，不可中断的动作，并在此动作完成后通过完成转换转向另一个状态。动作有很多种类型CallBehavior（调用行为）:这种类型的Action可以关联到活动图、状态图、交互图，意思就是可以对这些图表示的行为发起调用。CallOperation（调用操作）:指的是调用某个对象的操作。CallBehavior和CallOperation还是有明显区别的，各有各的应用场景。Create 和Destory：分别表示创建对象和销毁对象的动作SendSignal和AcceptSignal。SendSignal动作创建了一个信号（Signal)发送给特定的目标对象，从而引发状态的变化或者活动的执行。因为发送的是信号，UML里面对“信号”的定义是发送者是异步执行，而且不感知接受者的执行结果。AcceptSignal动作是用于接收信号，并加以执行。发送信号和接收信号动作
TriggerEvent和AcceptEvent：触发事件Action用于生成异步消息。在UML里面消息（Message）的定义是：调用方异步，但调用方需要等待调用结果。比如异步调用支付宝进行支付，并等待支付的回调。接收事件Action接收事件消息，而且可以进一步检查事件是不是满足动作触发的条件，如果满足条件就执行相应的ActionTimeEvent:当时间表达式为True的时候，事件出现，然后事件信号流触发。还有一些其他类型：Read 、Write、Insert 、Delete、Opaque没找到文档说明，有一些可能是StarUML自己的扩展活动（Activity）。活动（Activity）和动作（Action）的差别还是比较大的。动作状态是指原子的，不可中断的动作，并在此动作完成后通过完成转换转向另一个状态。动作状态特点包括：一、动作状态是原子的，它是构造活动图的最小单位；二、动作状态是不可中断的。三、动作状态是瞬时的行为。活动的特点包括：一、活动状态可以分解成其他子活动或者动作状态。二、活动状态的内部活动可以用另一个活动图来表示。三、和动作状态不同，活动状态可以有入口动作和出口动作，也可以有内部转移。控制流（Control Flow）——动作之间的转换称之为控制流。选择(Decision)和选择合并(Decision Merge)。它有一个进入转换（箭头从外指向分支符号），一个或多个离开转换（箭头从分支符号指向外）。而每个离开转换上都会有一个监护条件，用来表示满足什么条件的时候执行该转换。选择合并表示多个选择路径要合并到一个路径上来。■ 分叉(fork)和汇合(join)：分叉起始表示从它开始多个支流并行执行。汇合表示多个支流同时到达后再执行后续活动。
泳道（Swimlane）
下图是一张比较完整的订单退货的活动图。这张活动图描述了业务流程中活动的执行顺序，却没有描述出谁来执行这些活动，执行业务流程的职责被遗漏了。在面向过程的分析观点里，对象职责是不重要的，重要的是业务的执行过程；而在面向对象的分析观点里则与之相反，业务的执行过程不是重要的，对象职责才是最重要的。
活动图引入泳道这个概念就是为了解决活动图不能描述对象职责的遗憾。泳道，顾名思义，就像一个游泳运动员只能在一个泳道里进行比赛一样，一个对象也只能在一个业务流程中担任一个（或一类）职责。泳道代表了一个特定的类、人、部门、层次等对象的职责区，这些对象在业务流程中负责执行的活动***构成了它们的职责。我们再来看看加入了泳道以后活动图的效果如何。
加入了泳道以后的活动图，这些动作是哪个对象或者角色负责就一目了然。
对象流（Object Flow)
先说一下UML中对象流和控制流的区别：
控制流是动作之间的转换，而对象流是表示动作使用对象或者动作对对象的影响。Control flow控制流：动作之间的转换称为控制流，活动图的转换用带直线的箭头表示，箭头的方向指向转入的方向。Object flow对象流：对象流是动作状态或者活动状态与对象之间的依赖关系，对象流表示动作使用对象或者动作对对象的影响，用活动图描述某个对象时，可以把涉及到的对象放置在活动图中，并用一个依赖将其连接到进行创建、修改和撤销的动作状态或者活动状态上，对象的这种使用 *** 就构成了对象流。对象节点（Object Node)
对象节点（object node）为矩形图示，对象流（object flow）的图示与控制流相同，不过它的其中一个端点必须是对象节点，而另一端必须是其他节点。控制流的两个端点不可以都是对象节点。下图中下单动作输出“订单对象而且定义了状态是New”，这个对象又成了生成送货单这个动作的输入。借助“对象节点”活动图中涉及的数据和数据状态就能体现出来了。
活动参数节点(Activity Parameter Node)和输入输出Pin(Input/Output Pin)
如果对象是活动（Activity）参数的时候就可以用活动参数（Activity Parameter ）来表示。询价活动就有两个活动参数SKUID和Num。
引脚（pin）和活动参数节点很像，两者都作为输入/输出使用。差别在于引脚用在动作处，活动参数则用在活动处。引脚会提供值（values）给动作，且从动作处接受返回值。引脚有两种，一种称为输出引脚（output pin），另一种称为输入引脚（input pin）。获取原价这个动作就有两个输入PIN和一个Value Pin。Value Pin用于说明这个值自行提供的，例如当前的系统时间。活动参数和输入输出PIN直接可以通过对象流连接起来。
其他元素
中央缓冲节点（central buffer node）：央缓冲节点可以同时从多个对象节点接收输入，并可以为多个对象节点产生输出。和对象流不同，中央缓冲节点提供的数据不作为活动或动作的启动条件。
数据存储节点（data store node）: 数据存储节点就是带有数据持久化功能的中央缓冲节点。
数据存储节点可以同时从多个对象节点接收输入，并可以为多个对象节点产生输出。数据的输入流和输出流是不相连的，也就是说数据的存储和使用要求可以来自不同的线程。
数据存储节点和中央缓冲节点输出数据的行为是不同的。中央缓冲节点输出的是数据本身，而数据存储节点输出的是数据的拷贝，数据本身是在包含该数据存储节点的活动结束以后才会被销毁的。
活动图与流程图的区别
流程图着重描述处理过程，它的主要控制结构是顺序、分支和循环，各个处理过程之间有严格的顺序和时间关系。而活动图描述的是对象活动的顺序关系所遵循的规则，它着重表现的是系统的行为，而非系统的处理过程。所以系统级的流程用活动图而某个特定函数或者服务的实现过程用流程图。 UML2.5 14种图并不包括流程图。流程图是面向过程设计的产物，而UML是基于面向对象重新定义的，当需要复杂的对象间的交互过程描述的时候，时序图会更合适。如果需要描述特定算法的实现逻辑的时候，完全可以使用流程图，两种不同的工具要描述的问题在性质和场景是有蛮大差别的。
