UML基础之活动图
关于活动图一些特征
以下是笔者收集的关于活动图的一些阐述：
l 在UML中，一个活动图通过处理过程中的有序的活动描述系统行为。
l 活动图是UML用于对系统的动态行为建模的一种常用工具，它描述活动的顺序，展现从一个活动到另一个活动的控制流。
l 活动图描述的是对象活动的顺序关系所遵循的规则；
l 活动图能够表示并发活动的情形；
l 活动图着重表现从一个活动到另一个活动的控制流，是内部处理驱动的流程（相对应的：状态图则是事件驱动）；
l 活动图可以描述一组相关动作如何执行，以及其如何影响周围的对象。
活动图的应用场景
应用场景：
活动图可以描述一个业务领域的业务流程、用例执行过程、类方法执行过程等，随需而动。
l 启动项目的时候，可以对最为关键的业务流程构建活动图。
l 在需求分析阶段，可以对用例的事件流进行说明。
l 在分析和设计阶段，可以对操作进行说明。
l 在你需要的其他时候…………。
特殊说明：
活动图一般是用例、类、方法等概念的补充描述，而非独立存在（活动需要有自己的上下文）。
活动图主要元素
¡ 活动（Activity）
¡ 动作（Action)
¡ 动作约束（Action Constraints）
¡ 控制流（Control Flow）
¡ 开始节点（Initial Node）
¡ 终止节点（Final Node）
¡ 对象（Object）
¡ 对象流（Object Flows）
¡ 分支与合并（Decision and Merge）
¡ 分叉与汇合（Fork and Join）
¡ 异常处理（Exception Handler）
¡ 接收事件（Accept event）
¡ 泳道（Partition）
活动图示例：
开始节点（Initial Node）
开始节点用以标识流程伊始被调用的活动。
特殊说明：
需要注意的是，一个活动图中可以存在多个开始节点，也就意味着，一个流程可以存在不同的起始活动。
终止节点（Final Node）
终止节点分为两种：活动终止节点（Activity final）和流程终止节点（Flow final）
l 活动终止节点：一个活动图中，允许存在多个活动终止节点，但是，当其中一个终止后，所有活动流程都将终止。
l 流程终止节点：和活动终止节点显著的区别是：流程终止节点只终结当前流程，而其他并行的流程不会被终止。
UML标识：
特殊说明：
一般来说，只需要一个终止节点即可，但是实际应用中，会出现两种情况，一种是没有终止节点，一种是多个终止节点。
没有终止节点：这种情况可能使用在没有终点的常态运行中，比如信息的异步处理服务。如果大家都知道某个活动是终结的，那么也可以不使用终止节点。
多个终止节点：这个主要是作图的习惯，对于活动图来说，在混乱的连线和多个终点之间，建议选择使用多个终点。
活动（Activity）
关于活动：
又称活动状态，在UML中，活动是一个容器元素；在活动图中，活动是行为的最高层次描述。（此处是相对于动作（action）而言的）
一个活动是由一系列离散的活动节点、对象节点、对像流、控制流组成，如果发生以下情形，活动将被调用：
l 其他活动完成操作；
l 活动需要的数据或对象满足使用条件；
l 外部事件触发；
UML标识：
活动和动作的图标相同，但是活动可以在图标中给出入口动作、出口动作等信息。
特征：
l 和动作状态不同，活动状态可以有入口动作和出口动作，也可以有内部转移。
l 动作状态是活动状态的一个特例，如果某个活动状态只包括一个动作，那么它就是一个动作状态。
l 每一个活动都有唯一的名称，以标识其目的。
l UML中活动状态和动作状态的图标形状相同，但是活动状态可以在图标中给出入口动作和出口动作等信息。
特殊说明：
活动的来源：
l 如果描述涉及多个用例的业务流：活动可能来源于用例；也可能来源于用例中的系统行为；
l 如果描述系统用例：活动可能来源于用例中的系统行为。
l 如果描述方法：活动需从方法的实现过程中获取。
l 如果是其他应用：获取的活动能说明问题就好。
动作（Action）
关于动作：
动作，又称动作状态。动作状态是指原子的，不可中断的动作，并在此动作完成后通过完成转换转向另一个状态。
动作是活动的特例。
UML标识：
活动图中的动作（或动作状态）是用圆角矩形来表示的。如下图所示：
特征：
l 动作是用来执行并产生某种结果的。
l 动作状态是原子的，它是构造活动图的最小单位。
l 动作状态是不可中断的。
l 动作状态是瞬时的行为。
l 动作状态可以有入转换，入转换既可以是控制流，也可以是对象流。动作状态至少有一条出转换，这条转换以内部的完成为起点，与外部事件无关，即系统内部执行过程，而不是外部事件触发的。
l 动作状态与状态图中的状态不同，它不能有入口动作和出口动作，更不能有内部转移。
动作的应用：
l 在分析阶段，动作一般会来源于操作契约。（关于操作契约，可参考《UML与模式应用》）
l 在设计阶段，对动作的最直观的理解即是一个类的方法。
l 一个操作或一个类方法，也可以由一组动作组成，如何应用，需根据自身需要灵活处理。
动作约束（Action Constraints）：
用来约束动作（Action），约束一般分为前置条件、后置条件、不变式约束、一般约束、过程约束。
UML标识：
控制流（Control Flow）
关于控制流：
动作之间的转换称之为控制流
UML标识：
活动图的转换用带箭头的直线表示，箭头的方向指向转入的方向。
特征：
l 活动图的转换一般都不需要特定事件的触发。
l 控制流可以增加临界条件，即定义了目标节点进行执行前必须满足的条件。你可以通过以下方式定义临界条件：
n [guard conditon] 临界条件定义了，但是没有分配一个名称，比如：
n name [guard condition] ，其中的name是为临界条件设置了一个名称。
异常处理（Exception Handler）
异常处理节点是活动的一种类型，当受保护的活动发生异常时，触发异常处理节点。
接收事件（Accept event）
接收事件是活动的一种，一般应用于一些可被中断的活动图。
比如下图，正常情况下【Process Order】顺序流转到【Close Order】，订单处理流程完毕；但在【Process Order】过称中，会发送【Cancel Order】请求，这时会流转到【Cancel Order】，从而订单处理流程结束
对象（Object）
关于对象：
在活动图中，对象节点是一个抽象的活动节点，可以帮助确定在一个活动中的对象流，对象节点标识某外部实体的一个实例在某个活动的一个特定点能够使用。
比如，在需求分析阶段，我们对一个“处理订单”的用例进行活动图说明，如果此时已经构建领域模型的话，那么就可以将领域模型中的“订单”实体引入到活动图中，如图所示：
关于对象节点的另一种表述方式：
在此图中，将对象流独立了出来，表现会更为灵活。（比如说，提交订单的时候记录了一条日志，并要求在流程图中增加此对象。）
对象流（Object Flows）
对象流是动作状态或者活动状态与对象之间的依赖关系，表示动作使用对象或动作对对象的影响。用活动图描述某个对象时，可以把涉及到的对象放置在活动图中并用一个依赖将其连接到进行创建、修改和撤销的动作状态或者活动状态上，对象的这种使用方法就构成了对象流。
特点：
l 一个对象可以由多个动作操作。
l 一个动作输出的对象可以作为另一个动作输入的对象。
l 在活动图中，同一个对象可以多次出现，它的每一次出现表明该对象正处于对象生存期的不同时间点，此处可以使用状态进行标识。
在建模工具EA中，可以通过“set object state”来进行设置
l 对象流用带有箭头的虚线表示。（建模工具EA中，使用了实线）
n 如果箭头是从动作状态出发指向对象，则表示动作对对象施加了一定的影响。施加的影响包括创建、修改和撤销等。
n 如果箭头从对象指向动作状态，则表示该动作使用对象流所指向的对象。
分支（Decision）与合并（ Merge）
关于分支：
表示一个活动处理后根据不同的后置条件产生的不同的分支处理流程。分支也称为决策点。合并节点一般是和分支成对出现的。
UML标识：
特殊说明：
l 使用决策点是可选的，以上的例子也可以这样来描述：
l 避免使用多余的分支。
l 确保离开警戒点的每个活动都有一个警戒条件。
l 确保分支后的连接线上的警戒条件集合是完整的，不要出现遗漏。（可以想一下MECE原则）
l 为复杂的警戒条件标明决策逻辑，比如使用一个注释框来单独说明。
分叉（Fork）与汇合（Join）
对象在运行时可能会存在两个或多个并发运行的控制流，为了对并发的控制流建模，UML中引入了分叉与汇合的概念。
分叉用于将控制流分为两个或多个并发运行的分支，而汇合则用于同步这些并发分支，以达到共同完成一项事务的目的。
泳道（Partition）
关于泳道：
l 泳道将活动图中的活动划分为若干组，并把每一组指定给负责这组活动的业务组织，即对象。在活动图中，泳道区分了负责活动的对象，它明确地表示了哪些活动是由哪些对象进行的。在包含泳道的活动图中，每个活动只能明确地属于一个泳道。
l 泳道是用垂直实线绘出，垂直线分隔的区域就是泳道。在泳道的上方可以给出泳道的名字或对象的名字，该对象负责泳道内的全部活动。
l 泳道没有顺序，不同泳道中的活动既可以顺序进行也可以并发进行，控制流和对象流允许穿越分隔线。