UML 活动图：知识讲解与软件设计师考点¶

活动图描述**一件事要经过哪些动作、按什么条件往下走，以及哪些动作可以并发执行**。软件设计师备考时，最值得先掌握的是四个节点：判定、合并、分叉、汇合。它们决定了读图、判断执行顺序和补图时的答案。

本文按软件设计师科目整理。后文练习均为**自编题**，用于训练相关能力，不对应某年真题，也不据此推断每年的固定题数或分值。

1. 软考会从哪些角度问¶

可以把备考任务分成“认得符号 → 读懂流程 → 根据需求补图”三层。

考查角度	题干可以怎样问	解题时抓什么
图的分类与用途	哪种 UML 图适合描述业务工作流？活动图属于结构图还是行为图？	活动图属于行为图，描述控制流和对象流
基本符号	菱形、粗实线、圆圈中的叉分别表示什么？	同一形状还要结合入边、出边及上下文判断
条件选择	满足某个条件后执行哪个动作？多个条件都为真会怎样？	判定节点每个输入令牌只选择一条输出边
并发与同步	哪些动作可并发？后继动作必须等谁？	分叉产生并发流，默认汇合等待所有输入分支
执行顺序与次数	哪个执行顺序不可能？把汇合改成合并会怎样？	追踪令牌、同步点和终结点，不能只看图上左右顺序
结束范围	一条分支结束后，其他分支能否继续？	区分流终结与活动终结
业务建模与补图	根据“二选一”“同时”“均完成后”补节点、边和条件	把需求文字转成选择、并发、同步及责任划分
对象与职责	哪个部门执行动作？两个动作传递什么数据？	泳道表示职责，对象流表示对象或数据传递

综合知识复习可用选择题、判断题训练前几项；遇到要求使用活动图的建模题或案例材料时，再按本文方法补图。不能把所有 UML 案例题都当成活动图题，还要根据题干区分类图、用例图、状态图和顺序图。

2. 活动图到底描述什么¶

以“处理订单”为例：

接收订单 → 判断库存 → 库存不足时通知客户；库存足够时，并发进行备货和开票 → 两项都完成后发货。

这里关注的是处理步骤与执行条件，因此适合用活动图。

活动 Activity：一个完整的行为，例如“处理订单”，内部可以协调多个动作。
动作 Action：活动中的执行步骤，例如“检查库存”“生成发票”。它是当前图中不再展开的执行单元，不表示内部绝对不可分解。
控制流 Control Flow：传递执行控制，说明什么条件下可以继续某一步。
对象流 Object Flow：传递对象或数据，例如把“已填写申请单”送给“审核申请”。

活动图可以用于业务流程、用例内部流程、操作或算法逻辑，不限于某一个类的方法。

与其他图怎么区分¶

图	主要回答的问题	同一订单业务的例子
用例图	谁使用系统完成什么目标？	客户下单、管理员管理商品
活动图	一件事如何按步骤、条件与并发关系完成？	检查库存、备货、开票、发货
状态机图	一个对象处于什么状态，什么事件导致状态变化？	订单从“待付款”变成“待发货”
顺序图	哪些对象按什么顺序发送消息？	页面调用订单服务，订单服务调用库存服务
类图	有哪些类及其静态结构关系？	订单、订单项、商品之间的关联

活动图与状态机图都属于行为图，也有相似符号；辨别时看**动作流程**还是**对象状态及事件触发的转换**。

3. 标准符号与含义¶

元素	标准 UML 中怎样画	含义与识图要点
初始节点 Initial Node	实心圆	活动启动时发出初始控制令牌
动作 Action	圆角矩形，通常写动宾短语	如“提交申请”“审核申请”
控制流	带箭头的实线	箭头方向表示流向，不代表消息调用
判定节点 Decision	菱形，通常一入多出	根据守卫条件选择一条出边
合并节点 Merge	菱形，多入一出	汇集选择分支；不等待全部输入，也不做并发同步
分叉节点 Fork	粗实线，一入多出	将一个流分为多个并发流
汇合节点 Join	粗实线，多入一出	默认等待所有输入分支，再继续后继流程
活动终结 Activity Final	实心圆外再套一个圆，即靶心形	结束当前整个活动执行，包括其他仍在运行的分支
流终结 Flow Final	圆圈中画叉	只结束到达这里的流，不停止同一活动中的其他流
对象节点 Object Node	普通矩形，可写名称、类型、状态	如 `申请单 [待审核]`，区别于圆角的动作节点
活动分区／泳道 Partition	带名称的分区	按角色、部门、系统等划分动作的责任归属

不要只凭“菱形”或“粗线”答题，要同时数入边和出边。 标准也允许把合并与判定、汇合与分叉组合在同一个符号中；遇到多入多出时，要按“先汇入，再分出”的功能理解。

本文的控制流程使用 Mermaid 的状态图绘图语法近似呈现，利用其起止、菱形和粗线符号表达活动流程；图中圆角节点按动作理解，不是订单状态。对象流和泳道用 Mermaid 流程图示意。考试识图以题目给出的标准 UML 符号为准。

4. 判定与合并：多条路中选一条¶

报销金额不超过 1,000 元，由主管审批；超过 1,000 元，由经理审批。审批完成后，都进入“登记结果”。

stateDiagram-v2
    direction TB
    [*] --> Submit
    state "提交报销申请" as Submit
    state Choose <<choice>>
    Submit --> Choose
    state "主管审批" as Supervisor
    state "经理审批" as Manager
    Choose --> Supervisor: [金额 ≤ 1000]
    Choose --> Manager: [金额 > 1000]
    state Merge <<choice>>
    Supervisor --> Merge
    Manager --> Merge
    state "登记结果" as Record
    Merge --> Record
    Record --> [*]

上面的菱形是判定，下面的菱形是合并。针对一次申请，只会进入一种审批路径；合并节点收到这一条路径的令牌后，就可以继续。

守卫条件不是动作¶

出边上的 [金额 > 1000] 是**守卫条件 Guard**，不是让系统“执行金额大于 1000”这个操作。条件通常写在方括号内；图中的方括号不是可省略内容的意思。

建模时应尽量让选择条件**互斥且覆盖需要处理的情况**。
[else] 表示其他出边的守卫条件均不成立时的兜底分支；一个判定至多有一条 [else] 出边。
如果多个出边条件都为真，不会因此分裂成多个并发流；每个输入令牌仍只走一条边，不能根据图上左右位置或书写顺序认定选哪一条。
如果所有条件均不成立，而且没有可用的 [else]，该令牌暂时不能通过这处判定；不能自行假定活动结束。

例如条件写成 [金额 ≥ 1000] 和 [金额 ≤ 1000]，在 1,000 元处发生重叠。它没有表达清楚唯一审批路径，应修改边界条件。

合并为什么不能换成汇合¶

主管审批和经理审批是二选一。如果后面错误使用默认 AND 汇合，它就会等待两条路径的令牌，而本次申请永远只会走其中一条，后继流程便无法继续。

5. 分叉与汇合：多条路都要做¶

订单审核通过后，仓库备货与财务开票可以并发进行；两者均完成后才能发货。

stateDiagram-v2
    direction TB
    [*] --> Review
    state "审核订单" as Review
    state Fork <<fork>>
    Review --> Fork
    state "仓库备货" as Prepare
    state "财务开票" as Invoice
    Fork --> Prepare
    Fork --> Invoice
    state Join <<join>>
    Prepare --> Join
    Invoice --> Join
    state "发货" as Ship
    Join --> Ship
    Ship --> [*]

上面的粗线是分叉，下面的粗线是汇合。

分叉让备货、开票两个分支都获得继续执行的机会。
两个分支之间没有由此规定的先后顺序；“可并发”不意味着它们必须同一时刻开始，或一定由两颗 CPU 并行执行。
默认汇合是 AND 同步：备货与开票都完成后，才允许发货。
开票先完成时，要等备货；备货先完成时，要等开票。

没有特别说明时，按默认 AND 汇合理解。如果题目明确给出 joinSpec 等自定义汇合条件，应遵从题设，不能再机械套用“所有输入都到达”。

用令牌读图¶

令牌 Token 可以理解为“这条流程现在获得了往下走的资格”。它是帮助理解活动图的概念，不需要把它理解成程序中的某个固定变量。

节点	一个输入令牌到达后怎样处理
判定	选择一个满足条件的出口，不复制成多个令牌
分叉	在本例无守卫、无阻塞的情况下，让多个输出分支分别获得令牌
合并	不把多个输入同步成一次；到达的令牌可分别继续向后传递
默认汇合	等待每条输入边提供令牌，满足同步条件后继续

因此，将汇合换成合并，可能让后继动作过早执行，甚至重复执行。合并不是“先等齐，再只放行一次”。

执行顺序与时间题¶

设 A → 分叉 → B、C → 汇合 → D，每个动作只执行一次，没有循环，也没有提前终止。

A、B、C、D 和 A、C、B、D 都可以作为动作的完成先后顺序；B、C 的实际执行时间也可以重叠。
A、B、D、C 不可能，因为 D 必须等 C 完成。
B、C 都要执行，它们不是“任选一条的两条路径”。

若 A、B、C、D 分别耗时 2、3、5、1 秒，并且**分叉后两个分支能立即并行、没有资源竞争或调度开销**，最短完成时间为：

1	`2 + max(3, 5) + 1 = 8 秒`

只有满足上述前提才能这样计算。单处理器串行执行、共用互斥资源或分支内部还有依赖时，要重新分析；不能看到分叉就直接取最大值。

6. 两种终结：结束这一支，还是整个活动¶

假设一次活动分叉后，同时“发送通知”和“备货”。

通知分支最后接什么	到达该节点后	备货分支是否受影响
流终结：圆圈中画叉	只消费并终止通知分支到达的流	不会仅因为这个流终结而停止
活动终结：靶心形	结束当前活动执行	尚未完成的备货分支也会被终止

一个活动中可以有多个活动终结节点，先到达其中一个就会结束当前活动。 这不等于必须等待所有终结节点都到达。

读图时还要看流终结与后面的汇合是否冲突：如果某分支在到达汇合前已被流终结销毁，而汇合又必须等待它，这个汇合就无法等齐所需输入。

“一个活动只能有一个初始节点、一个终结节点”也不是 UML 的普遍规则。简单教学图常采用单一入口，但 UML 允许多个初始节点；也存在没有显式初始节点、由输入等启动的活动。

7. 对象流与泳道¶

控制流表示执行控制，对象流表示数据传递¶

flowchart LR
    A("填写申请") --> O["申请单<br/>[待审核]"]
    O --> B("审核申请")

“填写申请”和“审核申请”是动作，圆角矩形；中间的“申请单”是对象节点，普通矩形。两条边表示申请单从产生方传给使用方。

不要把对象流理解成单纯的执行先后，也不要把活动图中的对象节点当成类图中的类。对象节点可表示某个类型的实例或值在这个流程位置可用；标出的状态只是对该对象的补充约束。

在 UML 2.x 中，控制流与对象流通常都用实线箭头表达，不能一概用“虚线就是对象流”来识别。需要结合节点、输入／输出引脚和图的上下文判断。

泳道回答“由谁负责”¶

flowchart LR
    subgraph Customer["客户"]
        A("提交订单")
    end
    subgraph System["订单系统"]
        B("校验订单")
    end
    subgraph Warehouse["仓库"]
        C("准备发货")
    end
    A --> B --> C

这里用分组框示意泳道的责任划分，不要求 Mermaid 的排版与试卷上的纵向泳道完全相同。

跨泳道连线表示不同责任方的流程衔接，不自动等于异步消息。
三个泳道不代表三条并发流，也不代表三个线程。
泳道划分职责；是否并发仍要看分叉、汇合及流的连接。

8. 综合补图：选择嵌在并发分支中¶

需求如下：

订单确认后，同时进行备货与开票。
开票时按客户选择，只开电子发票或纸质发票中的一种。
备货完成且所选发票开好后，才能发货。

stateDiagram-v2
    direction TB
    [*] --> Confirm
    state "确认订单" as Confirm
    state F <<fork>>
    Confirm --> F
    state "备货" as Prepare
    F --> Prepare
    state D <<choice>>
    F --> D
    state "开电子发票" as Electronic
    state "开纸质发票" as Paper
    D --> Electronic: [电子发票]
    D --> Paper: [纸质发票]
    state M <<choice>>
    Electronic --> M
    Paper --> M
    state J <<join>>
    Prepare --> J
    M --> J
    state "发货" as Ship
    J --> Ship
    Ship --> [*]

空缺节点	应补内容	需求依据
F	分叉 Fork	备货与开票同时推进
D	判定 Decision	两种发票二选一
M	合并 Merge	任一所选发票完成后，都形成一条“开票完成”的流
J	汇合 Join	等待“备货完成”和“开票完成”两个结果

不能把“备货”“电子发票”“纸质发票”三条边直接接入默认汇合。 那样会要求两种发票都完成，与“二选一”的需求矛盾。先用 M 合并选择分支，再把它作为一路输入接入 J。

循环的补图也要遵守这一点。例如“校验失败就返回修改，成功才提交”，可以用判定分出 [失败] 和 [成功]；回到修改动作之前，可用合并节点汇集初次进入与重试返回的流程。有回边不等于并发，条件选择也不应补成分叉。

补图时按文字找节点¶

需求中的表达	优先考虑的图形元素
如果、否则、满足条件时	判定及出边上的守卫条件
无论选择哪种方式，之后都……	合并
同时、分别开展、可以并行	分叉
全部完成后、两者都完成才……	默认 AND 汇合
不满足则重试、直到通过	判定与返回边，必要时增加合并
客户负责、仓库处理、系统校验	泳道／活动分区
生成申请单、传递订单数据	对象节点与对象流

不要只按关键词机械填图；最后要检查它与其他分支、同步点和结束条件是否一致。

9. 自编练习与解析¶

以下练习均为自编题。先独立作答，再展开解析。

题 1：选哪种图¶

要描述“提交申请、条件审批、并行办理、全部完成后归档”的业务流程，最直接的 UML 图是什么？

A. 类图　B. 对象图　C. 活动图　D. 部署图

答案与解析

C。题干关注处理步骤、条件和并发关系，属于活动图的适用范围。

题 2：两个条件都成立¶

某判定的两条出边条件是 [x ≥ 0] 与 [x ≤ 0]。当 x 为 0 时，能否判断两条分支都会执行？

答案与解析

不能。 判定对每个输入令牌只选择一条输出边，条件重叠不会让它变成分叉；也不能按画在左边或先写出的条件断定结果。应修正条件，使预期业务路径明确，例如 [x > 0] 与 [x ≤ 0]。

题 3：错误的执行顺序¶

对 A → 分叉 → B、C → 默认汇合 → D，每个动作执行一次。以下哪种完成先后顺序不可能？

A. A、B、C、D　B. A、C、B、D　C. A、B、D、C

答案与解析

C。 D 必须等待 B、C 均完成。A、B 两个选项都满足依赖，但不代表 B 与 C 必须串行运行。

题 4：把汇合改成合并¶

一条流分叉后进入 B、C；B、C 各执行一次，并各向同一个合并节点 M 提供一个令牌，M 后接 R。题设保证没有提前终止或其他阻塞，R 每次收到令牌都可执行。M 会向后传递几个令牌？R 是否保证只执行一次？

答案与解析

两个令牌；不保证只执行一次，在本题前提下会执行两次。 合并不执行 AND 同步，也不会把两个令牌合成一个。要表达“两项均完成后只继续一次”，这里应使用默认汇合。

如果图中还画了活动终结，必须额外分析它是否会提前终止另一条分支；不能不看题设就把所有“分叉后接合并”都机械判成执行两次。

题 5：找出补图错误¶

审批要么走“主管批准”，要么走“经理批准”，两条出边都直接进入默认汇合，再连接“登记”。问题在哪里？

答案与解析

把互斥分支误接到了 AND 汇合。 一次申请只会产生一个审批结果，汇合却等待两条输入，登记无法继续。应在此使用合并节点。

题 6：终结的范围¶

同一活动中 B、C 并发。B 先到达流终结节点，此时能否断定 C 被终止？如果改成活动终结呢？

答案与解析

流终结不能推出 C 被终止；活动终结会结束当前活动中的 C 分支。 前者结束到达它的流，后者结束当前活动执行。

题 7：泳道与并发¶

图中有“客户”“系统”“财务”三个泳道，因此它一定有三条同时执行的线程。这句话对吗？

答案与解析

不对。 泳道划分职责，不规定线程数量或并发关系。要分析并发，应查看分叉、汇合和流程连接。

题 8：最短完成时间¶

A 耗时 2 秒，之后 B、C 分叉并行，分别耗时 3、5 秒；汇合后的 D 耗时 1 秒。无资源竞争、无额外开销，分支立即开始。最短多久完成？

答案与解析

8 秒。 2 + max(3, 5) + 1 = 8。题目已提供可直接并行的前提，因此等待较慢分支即可；把 3 与 5 直接相加，会把并发段误算成串行段。

10. 考场读图顺序与速记¶

看目的：图中主要是做事的动作，还是对象的状态、消息或静态结构？
认入口和出口：特别区分流终结与活动终结，不遗漏提前终止。
数入边和出边：菱形区分判定／合并，粗线区分分叉／汇合。
查条件：是否互斥，是否遗漏取值，[else] 能否覆盖其他情况？
沿令牌走一遍：哪里选一路，哪里分成多路，哪里必须等待？
回到题设：补图是否满足“任选其一”“均完成后”等业务约束？判断次数或时间时，循环、资源和终结条件是否已考虑？

记忆句：判定选一路，合并不等齐；分叉开多路，汇合等到齐；流终结停本支，活动终结停本次活动。 其中“汇合等到齐”指默认 AND 汇合。

参考资料¶

OMG UML 2.5.1 标准入口：活动、动作和控制节点语义的规范来源。
UML Activity Diagrams：活动图、动作、分区和流的说明。
UML Activity Diagram Controls：判定、合并、分叉、汇合及两种终结节点。
UML Activity Diagram Object Nodes：对象节点、引脚和对象流。
软件设计师：面向对象技术：回顾 UML 图的分类及其他图形。
UML 学习资源与路线：配套书籍与学习顺序。

以上外部资料用于核对 UML 语义；本文的题型拆解、业务示例和练习由这些语义整理而来，不作为历年命题统计。查阅日期：2026-09-28。

UML 活动图：知识讲解与软件设计师考点¶

1. 软考会从哪些角度问¶

2. 活动图到底描述什么¶

与其他图怎么区分¶

3. 标准符号与含义¶

4. 判定与合并：多条路中选一条¶

守卫条件不是动作¶

合并为什么不能换成汇合¶

5. 分叉与汇合：多条路都要做¶

用令牌读图¶

执行顺序与时间题¶

6. 两种终结：结束这一支，还是整个活动¶

7. 对象流与泳道¶

控制流表示执行控制，对象流表示数据传递¶

泳道回答“由谁负责”¶

8. 综合补图：选择嵌在并发分支中¶

补图时按文字找节点¶

9. 自编练习与解析¶

题 1：选哪种图¶

题 2：两个条件都成立¶

题 3：错误的执行顺序¶

题 4：把汇合改成合并¶

题 5：找出补图错误¶

题 6：终结的范围¶

题 7：泳道与并发¶

题 8：最短完成时间¶

10. 考场读图顺序与速记¶

参考资料¶

评论