1.概述

有经验的同学一定看到过产品经理给的业务流程图，UML的活动图和流程图画法是很相似的，只是相对于流程图来说，活动图有更丰富的图标可以表达更加丰富的语义。此外，在与uml的用例图对比中，如果说用例图是表达了参与者与系统功能之间的关系，那么活动图就是对用例中系统功能更详细的描述。

简单的说，活动图描述的就是用例中的功能流程实现细节，例如：从哪里开始到哪里结束，中间有什么判断条件，有没有异步处理，哪里可以做存储等等。活动图是对业务功能流程细节的分析，能够为代码开发提供指导作用，适用的人群一般是研发同学。

在我的另一篇文章《用例图（Use Case Diagram）》中讲述了用例图特点及其画法，不熟悉用例图的同学又有兴趣了解的同学，可以去看一看。

2.常用的节点图例

2.1.开始、结束、动作节点

开始、结束是通过圆形的图标来表示，其中开始是实心圆，结束是一个空心圆中包含了一个小一点的实心圆，动作则是通过一个圆角方框来表示，他们之间的执行流程通过实现箭头来表示，箭头的方向就是流程运行的方向。

活动图表达的是业务流程，所有的业务流程都是有始有终的，如下图：

动作（action）节点表示的是需要执行的任务，它是当前活动流程中的一个原子性步骤，通过动词来进行描述，下面是一个极简版的商品购买流程：

2.2.决策、合并节点

我们在实际的流程一般不会这么简单，在流程中往往会存在一些条件分支，通过不同的条件来执行不同的子流程，这样的条件分支在代码中体现为if/else这样的代码块，而在活动图当中是通过决策节点来描述的。

决策节点可以通过一个空心菱形来表示，在指向子流程的箭线上可以写上条件，意思是满足xxx条件后，会进入这个分支，如下图所示：

空心菱形除了可以表示决策节点外，还可以表示合并节点。所谓的合并节点就是不同的条件中分支子流程执行后，最终都会在某个节点上进行合并，执行同一个后续流程。对于上图中的后续动作，有时候会看到如下图的表示方式：

我们在选购商品的过程中，有两种下单的方式，一种是立即购买，另一种是先加入购物车等逛得差不多了以后，再统一进行结算。所以我们就可以在选购商品后加入决策节点，并在生成订单之后加入一个合并节点。上面的活动图修改过后的图示如下：

2.3.fork、join 节点

fork、join节点与上面的决策、合并节点类似，都是将一个流程分叉成多个子流程链路，最终再合并到一起，不同的是，fork节点分叉出的子流程是并行执行的，也就是异步操作。join节点也很好理解，就是在某个位置等待所有异步执行的流程都执行完毕后，再合并成同一个流程运行。

fork、join节点都是通过一根又黑又粗又长的直线来表示的，如下图：

在购买商品的流程中，用户支付成功之后需要修改支付订单的状态为成功，同时需要生产快递单以进行配送，这两个动作可以并行执行，则可以表示为：

2.4.泳道

在上面的商城下单支付业务活动图中，已经可以看到大致业务流程，相信大家已经注意到了，图中不同的动作节点应该属于不同的角色来触发的，但是现在所有的节点都试混杂在一起的，不容易理解，为了避免这样的情况，我们可以将同一种类型的动作按照角色、流程阶段等维度进行分组。

在活动图中提供分组功能的图例就是接下来要说的泳道，由多个并列的长矩形框组成，由酷似泳池中的泳道而得名，如下图：

通过泳道，可以将上面的商品购买流程东西表示的更加精确，不仅仅展示了流程的运行方向，也展示了流程中不同角色之间的交互关系，例如添加购物车、立即购买这样的东西应该时由用户触发，生成订单、支付、支付结果更新这样的动作应该属于支付服务，而快递单、配送订单等应该属于快递服务。

我们将流程节点进行分组并放置到不同的泳道之后，展示的信息如下：

可以看到的使，加入了泳道之后流程的信息表达的更加丰富、也更加准确了。

3.总结

本篇主要是讲述了活动图以及活动图中的常用节点图例，活动图是用例图细节的补充，我们在活动中可以表达的是一个完整的功能流程，通过决策、fork/join等节点展示出条件分支、异步功能特点，并指导研发人员进行代码开发。

我们在梳理一条完整的功能链路的时候，使用泳道对活动节点进行分组的方式更佳，但泳道使信息变得丰满的同时，也会增加画图的复杂度以及耗时，所以在画一些相对简单的流程时，可以选择不使用泳道。

最后再总结一下本篇文章中需要注意的一些细节点：

• 动作节点：表达的是一个具有原子性的动作，描述的文字一定是动词
• 决策/合并节点：都是通过空心菱形来表示，合并节点不是必须存在的。
• fork/join节点：join节点只有在多个异步流程会重新聚合成一个同步流程的时候才需要画出来。

图例重其意而不重其形，在标准图例的基础上可以适当的做一些修改，只要整个团队中都能够理解其含义即可。