活动图设计指南：从需求梳理到并行分支的完整实践

1. 活动图到底在画什么从一张“没人看”的图说起第一次接触活动图是在一个内部工单系统的重构项目里。当时需求方丢过来一份二十多页的文档流程图、状态图、时序图混在一起开发看完一头雾水测试看完直接问“到底有几个分支”。后来我们把整条业务链路重新梳理成一张活动图从“用户提交工单”到“归档关闭”每个判断节点、每条并行路径都摆在明面上原本吵了三天的问题一张图讲清楚了。活动图本质上是一种行为建模图用来描述一个流程从起点到终点的动态执行过程。它关注的不是“系统有哪些对象”而是“事情按什么顺序发生、在哪些点分叉、哪些步骤可以同时干”。换句话说它回答的是“这个业务到底怎么跑起来”的问题。适合看这张图的人很广产品用它对齐需求边界开发用它确认分支覆盖测试用它设计用例运维用它理解异常处理路径。哪怕你只是刚入行的新人只要手上有一个“有步骤、有判断、有并行”的流程活动图就是最顺手的表达工具。我见过太多团队把活动图当成“交差用的文档插图”画完就锁进文件夹。真正有价值的活动图是画给自己和协作方看的分支有没有漏、循环会不会死、并行汇合点对不对这些问题在图上一目了然。接下来我会把这张图从设计思路到落地细节完整拆一遍包括我踩过的坑和那些文档里不会写的经验。2. 整体设计与思路拆解为什么偏偏选活动图2.1 活动图和其他行为图的边界在哪很多人分不清活动图、流程图和状态图画着画着就串了。我的判断标准很简单看焦点是“动作”还是“状态”。状态图关心的是“一个对象在生命周期里经历哪些状态”比如订单从待支付到已完成的流转活动图关心的是“一串动作如何协作完成一件事”比如订单从创建到履约涉及哪些步骤、哪些步骤能并行。普通流程图和活动图的区别则在于表达力。流程图能画顺序和判断但遇到并行、汇合、分叉这些结构就显得吃力而活动图原生支持并发路径和同步汇合这在涉及多系统协作、多角色并行的场景里非常关键。我做过一个对账系统日终要对多个渠道的数据同时拉取、分别校验、最后汇总用流程图只能画成一条线用活动图就能把“并行拉取”和“汇合校验”表达得清清楚楚。选活动图的另一个理由是它天然适合跨角色沟通。泳道把“谁负责哪一步”直接画在图上产品、开发、运营坐在一起看同一张图不需要额外解释“这一步是前端做还是后端做”。这种把职责可视化的能力是其他行为图很难替代的。2.2 一张活动图的信息分层设计我习惯把活动图拆成三层来看画的时候也按这个顺序推进避免一上来就陷进细节。第一层是主干流程也就是从起点到终点最顺的那条路。先把这条线画出来确认业务主链路没有理解偏差。第二层是分支与异常把每个判断节点的所有出口都补上尤其是那些“看起来不会发生”的异常分支。第三层是并行与汇合识别哪些步骤可以同时进行哪些步骤必须等前面全部完成才能继续。这个分层顺序的好处是可控。主干没对齐就画分支等于在错误的地基上盖楼分支没画全就加并行很容易出现“汇合点等一个永远不会到达的分支”这种死锁结构。我见过一张图并行分叉出去三条路汇合点却只连了两条第三条悬空评审时没人发现开发按图实现后线上直接卡死。这种问题在分层推进的过程中基本不会出现因为每一层都会单独检查完整性。2.3 方案选型的现实考量工具层面我一般用支持标准建模语法的绘图工具团队协作时优先选能版本管理、能多人同时编辑的。这里不展开具体产品重点说选型逻辑图要能跟着代码一起迭代。活动图最大的价值在需求澄清和设计阶段一旦进入开发图如果和实现脱节就变成了负担。所以我倾向于把图源文件和项目仓库放在一起改需求的时候顺手改图评审的时候对着图讲而不是另开一个文档系统单独维护。另一个考量是图的粒度。一张活动图塞进三十个活动节点基本没人看得下去。我的经验是单张图控制在十五个活动节点以内超了就拆成子图用“子流程”节点引用。这样每张图都能在一屏内看完讨论的时候不用来回滚动。3. 核心细节解析与实操要点节点、分支、并行的正确画法3.1 起点终点与活动节点的规范活动图的起点用实心圆表示终点用带圆环的实心圆表示。看起来是小事但我见过不少图起点画成空心圆、终点画成实心圆和状态图的初始状态混淆评审时被追问半天。规范画法不只是为了好看而是让读图的人一眼分清“这是流程的开始”还是“这是某个对象的状态”。活动节点用圆角矩形命名上我坚持一个原则动词开头宾语明确。“校验参数”比“参数校验”好“发送通知”比“通知发送”好。原因很实际活动图描述的是动作序列动词开头的命名读起来就是一条连贯的动作链评审时顺着念一遍就能发现逻辑断点。我见过一张图里混用“订单创建”“创建订单”“订单已创建”读图的人根本分不清哪个是动作、哪个是结果。注意活动节点不要写成“系统A调用系统B”这种实现细节活动图描述的是业务动作不是技术调用。技术调用留给时序图。3.2 判断分支与合并的完整性检查判断节点用菱形表示一个入口、多个出口每个出口上标注守卫条件。这里最容易出的问题是分支不全。比如“校验通过”走正常流程“校验不通过”走异常流程但“校验超时”呢很多图里没有这个分支开发实现时要么默认超时算失败要么自己拍脑袋加一个最后和需求对不上。我的检查方法是对每个判断节点把所有可能的输入结果列出来逐一确认有没有对应出口。守卫条件要写成互斥且完备的比如“金额大于零”“金额等于零”“金额小于零”三个出口覆盖全部情况而不是只写“金额大于零”和“金额不大于零”两个出口却漏掉边界。合并节点同样用菱形多个入口汇成一个出口它的作用是收拢分支让后续流程只有一个入口避免线条交叉混乱。3.3 并行分叉与汇合的同步语义并行分叉用粗实线表示一个入口分出多条路径这些路径同时开始执行。汇合同样用粗实线多条路径汇入后同时结束后续流程才继续。这里的核心语义是同步汇合点必须等所有入边都到达才能往下走少一条都不行。这个语义在实际业务里对应的是“全部完成才能继续”的场景。比如批量审批多个审批人并行处理全部通过后才进入下一环节只要有一个驳回就走另一条异常路径。画的时候要注意并行分叉出去的每条路径最终都要能到达汇合点或者有明确的终止出口。我见过一张图并行出去三条路其中一条走到一半直接连到终点另外两条汇合后继续这种结构在语义上是混乱的读图的人会问“到底等不等那条提前结束的路”。提示并行路径里如果有判断分支每个分支都要能回到汇合点或者走到终止节点不能出现“某条分支走到一半没下文”的情况。3.4 泳道划分与职责边界泳道把活动按执行者分组横向或纵向排列每个活动落在对应执行者的泳道里。泳道划分的关键是边界清晰一个活动只属于一个泳道跨泳道的连线表示职责交接。我见过把“审批”放在两个泳道交界处的画法读图的人根本不知道这一步到底谁做。划分泳道时我一般按角色分不按系统分。按角色分的好处是业务方看得懂按系统分容易变成技术架构图。如果确实需要体现系统边界可以在活动命名里带上系统标识但泳道还是保持角色维度。另外泳道数量控制在五个以内超了就说明流程涉及的角色太多考虑拆成多张图或者用子流程收拢。4. 实操过程与核心环节实现从零画出一张能用的活动图4.1 需求梳理阶段的动作清单提取画图之前先别打开工具拿一张纸把流程里所有的“动作”列出来。我的做法是找一段真实的业务描述逐句拆解每遇到一个“做某事”就记一条。比如“用户提交申请后系统校验资料校验通过则进入初审不通过则退回补充”拆出来就是提交申请、校验资料、进入初审、退回补充外加一个判断节点“校验是否通过”。这个阶段不要管顺序和分支先把动作清单列全。清单列完后再排顺序把明显有先后依赖的连起来把可以并行的标出来。我习惯用不同颜色的便签纸区分“动作”“判断”“并行”贴在白板上调整顺序比直接在工具里拖拽快得多。等顺序和分支都确认了再落到工具里画正式图。4.2 主干先行与分支补全的绘制顺序落到工具里之后先画主干起点、第一个活动、判断节点、正常路径上的活动、终点。这条线画完找业务方确认一遍确认“最顺的那条路”没有理解偏差。这一步花十分钟能省掉后面大量返工。主干确认后补分支。对每个判断节点把异常出口和边界出口都补上每个出口连到对应的处理活动处理完再连回主干或者连到终止节点。补分支的时候我会刻意问自己三个问题这个判断有没有“什么都不做”的出口有没有“超时”的出口有没有“部分成功”的出口这三个问题能挖出大部分被遗漏的分支。分支补全后再加并行结构。识别哪些活动之间没有数据依赖、可以同时进行用分叉和汇合把它们框起来。加并行的时候同步检查汇合点的入边数量是否和分叉点的出边数量一致不一致就是结构错误。4.3 守卫条件的写法与参数化表达守卫条件写在判断节点的出口连线上用方括号括起来。写法上我坚持可判定原则条件必须是明确的、可验证的不能写“资料齐全”这种模糊表述要写成“资料项数等于要求项数”。模糊条件在评审时一定会被追问开发实现时也只能靠猜。涉及数值判断的把参数写进条件里比如“[库存量 下单量]”“[重试次数 3]”。这样图本身就是一份可执行的规格说明开发照着写判断逻辑不会跑偏。我做过一个库存扣减的流程守卫条件里直接写了库存和下单量的比较关系开发实现时连需求文档都没再翻直接按图上的条件写联调时一次通过。4.4 子流程节点的拆分与引用流程超过十五个活动节点就拆子流程。子流程节点画成带子流程标记的活动节点双击进去是另一张活动图。拆分的依据是功能内聚把“校验资料”相关的所有活动和判断收进一个子流程主图上只留一个“校验资料”节点读图的人先看主干需要细节再点进去。拆子流程时要注意输入输出对齐。子流程的入口对应主图上进入该节点的连线出口对应离开该节点的连线子流程内部的起点和终点要和外部衔接一致。我见过子流程内部有两个终点、外部只连了一条线的情况读图的人不知道另一个终点对应什么场景。拆分完成后主图和子图要一起评审确保引用关系没有断链。5. 常见问题与排查技巧实录那些评审时被问住的瞬间5.1 分支遗漏与死循环的排查方法分支遗漏是活动图最高频的问题排查方法我总结成“三查”查判断节点的出口数量是否等于可能结果数量查每个出口是否都有后续活动查异常出口是否最终能到达终止节点。第三查最容易被忽略很多图里异常分支画到“记录日志”就断了没有连到终点读图的人不知道记录完日志之后流程是结束还是回到主干。死循环的排查靠追踪路径。从起点出发沿着每条路径走一遍看有没有回到之前经过的节点且没有退出条件的结构。活动图里的循环通常表现为“某个活动连回前面的判断节点”这时候要确认判断节点有退出条件否则就是死循环。我见过一张图重试逻辑连回判断节点但判断节点的守卫条件里没有“重试次数上限”这条路径理论上可以无限循环。5.2 并行结构中的资源冲突识别并行路径同时执行时如果两条路径操作同一个资源就可能产生冲突。活动图本身不表达资源锁但画图的人要在评审时主动识别。比如两条并行路径都要“扣减库存”汇合后库存可能被扣了两次这种问题在图上看不出来但业务上就是错的。我的做法是在并行结构旁边加注释标明共享资源评审时专门过一遍。如果冲突无法避免就把并行改成串行或者在其中一条路径上加“加锁”活动。这个细节文档里很少提但实际项目里踩过一次就记住了。5.3 泳道错位与职责模糊的修正泳道错位表现为活动落在错误的泳道里或者跨泳道连线绕来绕去。修正方法是重新确认每个活动的执行者把活动拖回正确的泳道。跨泳道连线尽量保持单向、少交叉如果连线太乱说明泳道划分有问题考虑调整泳道顺序或者拆图。职责模糊的典型表现是“审批”这类活动不知道放哪个泳道。我的处理方式是看这个活动由谁发起、由谁完成放在完成方的泳道里发起方通过连线表达交接。如果实在分不清就说明这个活动的职责定义本身有问题需要先和业务方对齐再画图。5.4 常见问题速查表问题现象可能原因排查动作修正方式流程走不到终点某分支未连到终止节点沿每条路径追踪到终点补全分支连线或加终止节点汇合点卡死汇合入边数量与分叉出边不一致数分叉出边和汇合入边补齐缺失路径或调整汇合结构判断节点出口条件重叠守卫条件不互斥逐条检查条件表达式改写为互斥且完备的条件并行路径资源冲突多条路径操作同一资源标注共享资源逐一核对改串行或加锁活动泳道连线混乱泳道划分粒度过细检查泳道数量和跨道连线合并泳道或拆分子流程子流程引用断链子流程输入输出与主图不对齐核对子流程起终点与外部连线调整子流程边界或主图连线这张表我一般贴在项目 wiki 里评审前过一遍能挡掉大部分低级问题。6. 让活动图真正被用起来版本管理与协作习惯图画完只是开始能不能被持续使用才是关键。我的习惯是把活动图的源文件放进项目仓库和需求文档、接口定义放在同一层级改需求的时候强制要求同步改图。评审会上对着图讲而不是对着文字文档讲讲的过程中发现的问题当场在图上改改完截图发群里留痕。另一个习惯是给活动图加版本号和变更说明。每次修改在图的角落标注版本和日期重大结构调整在变更说明里写清楚改了什么、为什么改。这个习惯来自一次教训一个流程改了三个月图还是最初版本新来的同事按图理解业务结果和线上完全对不上排查问题时走了大弯路。协作上我倾向于让开发和测试都参与画图而不是产品一个人画完丢过来。开发画图时会自然考虑分支覆盖和异常处理测试画图时会自然考虑用例设计多方一起画出来的图遗漏明显更少。画图的过程本身就是对齐认知的过程这比图本身更有价值。最后分享一个我常用的检查技巧画完图后找一个没参与需求讨论的同事让他只看图讲一遍流程。如果他讲的过程中卡壳或者理解偏差说明图上有表达不清的地方当场修正。这个“陌生人读图”测试比任何自查清单都管用。