EU 3.4.4 建模功能和流程（L3）
动态模型：活动模型（Activity Model） 和 过程模型（Process Model）。
很多初学者会把它们混为一谈，但 IREB 告诉你：两者关注的“粒度”和“视角”完全不同。 我帮你把它拆解为 “两个层次、三个核心要素、两个工具选型”，你就彻底通透了。
一、先搞清楚本质区别：活动模型 vs 过程模型
| 维度 | 活动模型（Activity Model） | 过程模型（Process Model） |
|---|---|---|
| 核心关注点 | 系统内部“怎么做”（算法逻辑） | 业务/技术领域“怎么走”（协作流程） |
| 目标 | 指定系统功能的内部实现步骤 | 描述现实世界的业务流转或技术工序 |
| 典型提问 | 系统接到指令后，内部执行了哪几步计算？ | 一笔订单从创建到发货，经历了哪些部门和系统？ |
| 谁负责看 | 程序员、系统架构师（偏向技术实现） | 业务方、产品经理、流程优化专家（偏向业务沟通） |
| 建模语言 | 通常用UML 活动图 | 可用UML 活动图，但更推荐BPMN（业务流程建模符号） |
实战对比案例：
活动模型（系统内）：“用户点击支付后，系统内部校验余额、冻结库存、生成流水号”这三步的逻辑顺序和异常回滚。
过程模型（业务间）：“客户下单 → 系统扣库存 → 银行扣款 → 仓库备货 → 物流揽收”跨系统、跨部门的整个价值链流转。
二、这类模型要抓牢的“三大核心要素”
无论是活动模型还是过程模型，你在画图时都必须把以下三件事交代清楚（原文的强调点）：
1. 行动的顺序（Sequence of Actions）
白话：先迈左脚还是先迈右脚？
实战：必须“冻结库存”成功了，才能“生成支付链接”。顺序错了，就会出现“扣了用户的钱，但库存没锁住”的超卖事故。
2. 控制流与数据流（Control Flow & Data Flow）
白话：
- 控制流：告诉箭头下一步往哪走（是顺序执行、条件分支 [if/else]，还是并行分叉 [fork]）。
- 数据流：在步骤之间传递了什么“材料”（比如第一步计算出的“应付金额”，传给第二步的“支付网关”去扣款）。
3. 责任分配（Who is responsible）
白话：这步活到底归谁干？是系统自动干，还是人工干，或是外部系统干？
建模技巧：在 UML 活动图或 BPMN 中，利用“泳道（Swimlane）”来实现。比如：上面一行是“用户”，中间一行是“订单系统”，下面一行是“支付系统”。哪个动作落在哪个泳道，就代表由谁负责。
三、工具选型指南：什么时候用 UML 活动图，什么时候用 BPMN？
这是很多人纠结的点，原文其实已经给了明确的暗示：
用 UML 活动图（UML Activity Diagram）的场景：
- 面向技术实现：你是在画程序内部的逻辑（如“重试机制”、“递归算法”）。
- 兼顾控制流与数据流：UML 活动图既能画箭头跳转，又能画“输入/输出”的数据引脚（Pin），非常适合系统设计阶段的详细规格说明。
用 BPMN（或专门的过程建模语言）的场景：
- 面向业务沟通：你需要跟业务部门开会评审，BPMN 在表示“事件（如消息到达）”、“网关（复杂分支）”和“人工任务”上比 UML 更专业。
- 跨系统/跨组织流程：涉及多个合作伙伴、外部系统的端到端流程梳理。BPMN 天生就是做这个的，且业务方更容易看懂。
一句话决策公式：
如果你是在做“详细设计，写给程序员看的”，优先 UML 活动图；如果你是在做“业务梳理，准备拉各方大佬开评审会的”，优先 BPMN。
总结一句口诀
“活动模型管‘内功’（系统实现步骤），过程模型管‘外功’（业务流转生态）；前者看重数据与跳转，后者看重角色与协作；工具无好坏，BPMN 讲业务，UML 讲实现——看人下菜碟，才是真高手！”😊
