简介《BPMN2.0 过程建模语言图元中文术语集》是由北京交通大学软件学院、华胜天成、摩卡软件与炎黄盈动共同整理的标准术语文档面向流程建模人员、业务分析师及BPM实施团队用于统一BPMN2.0图元称谓并减少协作沟通歧义。资源为单个PDF文件压缩包大小约936KB内容覆盖事件、泳池泳道、数据、编排、逻辑门、活动、标记及会话共八类图元并对常规、消息、时间、升级、条件等事件类型及排他、并行、复杂等网关语义作了系统说明。文档还给出多例参与者、调用活动、事件子过程等标记的准确中文表述适合在流程梳理、建模规范制定或BPM工具选型时作为速查手册。目前已有140人学习下载可作为团队内部术语对齐和新人入门BPMN2.0的轻量参考资料。1. BPMN2.0 符号术语表是什么一份中文参考手册如何终结评审会上的叫法之争业务方把流程图上那个空心圆圈叫“入口”开发叫“启动事件”测试叫“流程开始”三种叫法在同一个评审会上出现五次会议就废了一半。BPMN2_0_Symbols-Terms_CHN.pdf说得直白一点就是把 BPMN 2.0 规范里的 Symbols 图形语言和 Terms 术语约定整理成一份按中文使用习惯编排的对照参考手册。它能解决三个实际问题符号认不全、术语不对齐、模型语义靠猜。适合业务分析师、流程工程师以及要对接流程引擎的开发测试人员。拿到手先别收藏按本文的顺序把它变成团队能照着执行的规范比翻十遍 PDF 有用得多。2. 拆解 Symbols 分类与 Terms 术语从流对象到工件先建立判断框架BPMN 2.0 的符号体系看着零散但按规范口径只有四类流对象、连接对象、泳道、工件。术语表的核心价值不在“知道圆圈叫事件”而在于帮你建立“位置决定语义、线型决定语义”这套判断框架。先看一张总表再逐个拆容易出错的细节。类别子类标准英文术语中文规范译名主要用途流对象事件Event事件描述流程的触发、中间等待和结束流对象活动Activity活动描述要执行的工作任务或子流程流对象网关Gateway网关控制分支、合并与路径选择逻辑连接对象序列流Sequence Flow序列流同一池内元素的执行顺序连接对象消息流Message Flow消息流跨池参与者之间的消息传递连接对象关联Association关联把数据对象、注解附加到活动泳道池与道Pool / Lane池 / 道划分参与者与职责分区工件数据对象Data Object数据对象活动需要或产生的数据工件数据存储Data Store数据存储持久化存储的位置这张表对应术语表前半部分的目录结构。接下来三个小节分别讲流对象、连接对象与泳道、工件里最值得注意的语义边界和选型理由这些都是建模时真正会踩的位置。2.1 事件、活动、网关三种流对象的术语怎么对号入座事件用圆圈表达是流程的骨架节点。术语表里的事件通常按两个维度拆第一个维度是位置分开始、中间、结束第二个维度是触发类型分消息、定时、条件、信号、错误、补偿等。位置和类型合起来才是一个完整术语比如“开始-定时事件”“中间-消息事件”“结束-错误事件”。建模时最常见的误用是把它们拆开读只知道“这是定时事件”却不知道它挂在开始还是中间语义差得很远。活动用圆角矩形表达。术语表把活动拆成任务和子流程。选型理由其实就一句话这段工作由人完成用用户任务User Task由系统自动执行逻辑或调接口用服务任务Service Task想在一张图里折叠一批内部步骤用嵌入式子流程或调用活动。判断时先问“谁来干”再问“要不要展开”而不是看图形得像什么。很多新手把服务任务画成用户任务因为活动里要填负责人反过来也有人把纯系统处理画成用户任务导致引擎部署后所有节点都在等人办。这两个符号的边界术语表里一般会写但团队实际使用时最容易被“业务上叫审批”带偏。网关用菱形表达内部图标决定路由逻辑。排他网关内部是 X 形标表示多选一并行网关内部是 形标表示所有路径并发执行包含网关内部是圆圈加 形标表示满足条件的路径都要走事件网关内部是五边形标表示谁先触发谁生效。网关选型不依赖业务名词依赖的是“要不要等、能不能同时走”。我一般让团队记住两条排他网关必须配互斥条件并设置默认出口并行网关不需要条件但它的所有入边最好都由同一个并行网关发起否则会出现流程实例卡死。2.2 连接对象与泳道序列流、消息流、关联和池/道的术语红线序列流是实线带实心箭头只在同一个池内使用表达“前一个节点完成后下一个节点开始”的先后关系。它是流程执行顺序的骨架绝大多数节点之间的连接都靠它。对应到术语表里Sequence Flow 的中文译名“序列流”强调的正是顺序不是传递。消息流是虚线带空心箭头只在两个不同的池之间使用表达“一个参与者给另一个参与者发消息”。术语红线是同一池内不允许出现消息流跨池时不能出现序列流。违反这两条建模工具可能不报错但导入 Camunda、Flowable 这类引擎后要么被忽略要么部署直接失败。我见过把跨部门交接画成消息流的模型部署后连消息接收方都找不到。关联是点线不决定执行顺序只用来把文本注解、数据对象附加到活动节点上。关联有没有方向语义强度不一样如果数据对象表示“产出物”建议标出方向让评审人看清数据流向而不是默认用无向关联含糊带过。泳道这组术语最容易引发团队分歧。池代表一个参与者在跨组织流程里是一个系统或独立法人道是池内部的职责分区。同一个公司内部产品部、研发部、测试部应当画在同一个池的不同道里而不是各画一个池。拆池的前提是存在独立的系统边界或组织边界否则消息流会把一条简单的审批流程画成一张网。术语表整理得再细画连接线之前只要回答三个问题两个节点在不在同一个池内是先后执行还是跨参与者协作这个连接本身会不会传数据答案分别对应序列流、消息流、关联。这套判断链比背二十个符号更值得先建立起来。2.3 工件与数据数据对象和数据存储在 Terms 里的正确姿势数据对象是右上角带折角的矩形表示某个活动需要读入或产出的数据比如“请假申请单”“审批意见”。它不定义数据生命周期也不代表数据库表。术语表里会提醒别把数据对象理解成数据结构它只是流程语义里的一个数据使用点。评审时经常有人指着数据对象问“这是哪张表”这个问题的前提就错了。数据存储是圆柱形表示持久化存储位置比如“客户主数据库”“订单库”。它和数据对象的区别在于数据对象跟着活动走活动结束它就离开语义范围数据存储长期存在多个活动可以反复读写。建模时如果只是描述一次审批里的表单填写用数据对象如果要描述落库、查历史数据才用数据存储。把这两类工件混着用流程图会变成一张伪数据字典既丢了流程语义又误导开发去建表。文本注解通常是一条点线连着一个文本框用来写给人看的补充说明不参与执行。它也有术语层面的作用如果评审时发现某个节点需要大量注解才能解释清楚说明节点命名或选型没做好而不是注解写得不够多。把三类工件放一起看术语表真正训练的是“语义最小化”思维能用一个节点说清楚的事不要拆成三个节点加两个注解。我现在看流程图先数数据对象数量一旦超过活动数量的一半就先怀疑有人在用流程图画数据模型。3. 把术语表变成团队建模规范三步落地的 terms 聚合方法PDF 只有被当成规范用起来才有价值。很多团队把术语表发到群里然后就没了下文。我自己的做法是拆成三步圈定符号子集、做 terms 聚合、映射评审检查单。三步做完术语表就从一个人的笔记变成了团队的公共约束。3.1 第一步圈定团队必用的符号子集别让规范变成没人翻的字典BPMN 2.0 全部符号有几十种日常流程建模根本用不到。术语表的价值恰恰在于可以做减法圈出“默认启用”和“默认禁止”两个子集新人老手都按这个范围画图评审时只讨论子集里的符号用得对不对不用争“这个符号能不能用”。流程类型默认启用符号默认禁止或慎用符号内部审批流程开始事件、用户任务、排他网关、并行网关、序列流、池与道、数据对象事件网关、事务子流程、补偿活动系统集成流程消息开始事件、接收任务、发送任务、服务任务、消息流、数据存储用户任务除非有人工确认环节定时批处理流程定时开始事件、定时中间事件、中断或非中断边界事件、循环活动并行网关中混入定时等待圈定理由内部审批流程的控制流最典型排他和并行网关足够覆盖分支合并系统集成流程的核心是跨系统协作消息流和服务任务是主角定时批处理流程则以事件驱动为主。子集一经确定要写进团队 Wiki并声明只能从子集里选符号。新人画图前先看子集而不是翻完整份术语表。团队里总有人想用“看起来高级”的复杂网关和补偿事件如果没有子集约束评审会一半时间会花在争论符号合法性上。3.2 第二步做一次 terms 聚合把中英文术语和业务黑话收敛成唯一基线无论团队用什么平台画图最终都要落到自然语言上。术语表如果只是“英文规范词加中文直译”没和团队已有叫法对齐评审时照样各说各话。terms 聚合要做的是把流程文档、代码枚举、数据库注释、会议黑话里描述同一概念的叫法全部收集起来映射到 BPMN 标准术语然后规定只有唯一的说法能出现在模型和相关代码里。团队里的散落叫法BPMN 标准英文统一中文术语不允许再用的叫法发起、入口、新建申请Start Event开始事件发起节点人工处理、待办、审批User Task用户任务人工节点、待办节点自动处理、调接口Service Task服务任务自动节点分流、判断、条件节点Exclusive Gateway排他网关分支节点完成、终结、提交结果End Event结束事件终态做完聚合后要把这张表放到会议纪要模板或 Wiki 首页。我一般还会做一次命名巡检打开已有流程图把不符合统一术语的节点 name 列出来逐个改。这一步看着琐碎但它是后续自动校验的基础。terms 聚合的关键是以“唯一主术语”为准业务俗称可以放在括号里保留但绝不允许再出现第二个主叫法。代码枚举名也尽量跟随英文标准术语做映射比如用户任务对应的状态用 USER_TASK_IN_PROGRESS避免中文翻译和英文代码两层命名越走越远。3.3 第三步把术语表映射成评审检查单做成模型自检清单术语表落地的最后一步是变成评审时能逐条打勾的东西。可以是一份 JSON一个文档模板也可以是一页墙上的检查单。我习惯做成 JSON因为既能贴进评审纪要又能留给脚本做的基础一致性检查。{ model: 请假审批流程, rules: [ {element: start, label: 开始事件, check: 有且仅有一个开始事件不能有入边}, {element: userTask, label: 用户任务, check: 必须填写负责人或候选组节点命名为动词加宾语}, {element: exclusiveGateway, label: 排他网关, check: 所有出口条件互斥且有默认出口}, {element: messageFlow, label: 消息流, check: 只允许出现在不同池之间}, {element: boundaryEvent, label: 边界事件, check: 中断与非中断边框样式和语义一致} ] }逻辑说明rules 数组里每一条都是一个独立评审项评审时逐条打勾。element 字段是 BPMN 元素类型label 是评审台本里的中文名check 是人工判断标准。model 字段记录流程名多流程评审时方便区分。参数说明check 字段不要写太长控制在二十字以内否则评审时读起来费劲如果团队用 Camunda 建模器可以把 element 字段替换成模型里对应的 id 前缀比如 task_、gw_自动检查时更直接。注意检查单规则按团队子集调整不要一次性把 BPMN 全部规则塞进评审会否则评审会变成规范考试。我实际维护的检查单只有八到十二条覆盖开始事件、任务、网关、边界事件、消息流、数据对象这些高频误用点。4. BPMN2.0 建模避坑最容易翻车的 5 个符号与术语踩坑记录下面五个坑都来自评审现场按“现象、原因、解决”三连写方便对照排查。每一条都对应术语表里某个容易被一眼略过的细节。4.1 定时器挂错事件位置流程一到夜里就跑飞现象建模者想在流程中间加一个“等 24 小时再走下一步”的环节直接把定时器图标挂在开始事件上。模型部署后每天早上定时器批量创建新流程实例而不是让既有实例在中间节点停下来等待。 原因把“定时等待”和“定时触发流程”拆开理解错了。BPMN 事件是位置与类型的组合“定时开始事件”负责新建流程实例“定时中间事件”负责在既有实例里等待两者在 XML 里结构不同引擎语义也不同。 解决在术语表里把事件按“位置乘类型”列成二维表建模前先确定位置再选图标。我自己的习惯是画图前先写一句话流程在什么条件下开始中间哪里需要等什么事件会导致提前结束然后分别对照开始、中间、结束事件。评审时看到圆圈先问它是哪条边上的圆圈再问里面是什么图标。4.2 排他网关条件互斥没做好边界值把流程分裂了现象审批流程里两个出口分别写“金额大于 1000”和“金额小于等于 1000”业务方说边界是 1000但运行时金额刚好是 1000 的单子要么两条条件都没命中要么两条都命中流程走进兜底分支事后查不到原因。 原因条件表达式用了半开区间边界重叠或留白。排他网关要求出口条件互斥且完备缺一不可。多数建模工具对条件表达式不校验引擎运行期按 XML 顺序逐条执行非预期行为很难在测试环境发现。 解决排他网关的每个出口统一用闭区间写法比如金额在 (0, 1000] 和金额大于 1000边界只有一个归属。同时每个网关必须配置默认出口默认出口不带条件专门接管所有意外输入。没有默认出口的排他网关遇到条件全部不匹配时引擎直接抛异常这种故障通常要等线上流量撞进去才发现。4.3 跨部门交接误用消息流画成了池之间的协作现象A 部门“提交资料”任务完成后用一条虚线箭头连到 B 部门的“资料审核”任务。模型部署后消息流提示找不到消息接收方两个池之间的执行顺序也不确定。 原因把组织架构里的业务交接理解成了消息协作。同一家公司内部部门只是不同 Lane交接是顺序控制流用序列流只有跨系统、跨组织参与者之间才需要消息流。消息流不负责执行顺序它只负责传递消息和序列流的语义完全不同。 解决画线之前先问一个问题交接双方是不是同一个流程里的两个职责分区是就把它们放进同一个池的不同 Lane用序列流连接只有在两个 Pool 之间才用消息流。如果后续确实出现异步响应和超时语义再把相应活动拆成独立的池不要一开始就把部门名字直接画成池。4.4 黑话与标准术语并存流程图和代码是两套词汇现象流程图节点叫“人工审批”代码状态枚举叫 WAIT_APPROVE数据库注释叫“审核中”需求文档叫“部门领导确认”。排查问题时每个人要在四套词之间来回翻译效率极低。 原因团队没有统一的 terms 基线。BPMN 术语表是规范层的东西但没人把它推进到命名层和代码层术语表挂在网盘里和日常绘图、写代码完全脱节。 解决做一次 terms 聚合让流程图节点 name、状态枚举、数据库注释全部从同一张表取词。比如统一成“用户任务-人工审批”“人工审批中”代码枚举写成 APPROVAL_IN_PROGRESS数据库注释写“人工审批中对应 BPMN 用户任务”。如果历史代码一时改不动至少新模型和新代码从今天开始遵守。这个坑修复成本最高因为要动代码枚举、动数据库注释、动测试用例最好在项目起步阶段就用术语表收口。4.5 边界事件的中断性被忽略虚线圆圈被当成装饰现象想做一个“三天未处理自动提醒一次”的功能建模者在用户任务上挂了一个定时边界事件。部署后定时器触发时主流程直接终止业务方投诉流程莫名其妙断了。 原因边界事件有两种边框样式实线表示中断触发后会取消当前活动沿异常路径走虚线表示非中断触发时活动继续执行通常用于催办、通知。建模工具默认新增的边界事件是中断的术语表里如果不特意标注“中断性”这个维度新手几乎都会踩。 解决团队规则写死提醒、催办、追加抄送这类不改主流程的动作统一用非中断边界事件并显式检查边框是虚线超时撤销、自动转办这类需要取消当前活动的用中断边界事件。导出 XML 后检查边界事件的 cancelActivity 属性非中断必须为 false。这条规则应该直接写进第三章的评审检查单光靠口头提醒一定会漏。5. 术语表落到 Camunda 与 Flowable 建模工具XML 元素映射和一致性校验流程图画完下一步是交给引擎执行典型引擎包括 Camunda、Flowable、Activiti。这一阶段最容易出现“图上好看、XML 跑不通”的问题。把术语表里的 Symbols 和 Terms 映射成工具里的 XML 元素属性是模型能落地执行的关键一公里。5.1 建模工具里的元素类型与 PDF 术语对照一张能填属性的映射表BPMN 标准元素PDF 中文术语Camunda/Flowable XML 元素关键属性或子元素Start Event开始事件bpmn:startEventeventDefinition支持定时、消息、信号End Event结束事件bpmn:endEventeventDefinition支持无、错误、终止User Task用户任务bpmn:userTaskassignee、candidateGroups、dueDateService Task服务任务bpmn:serviceTaskdelegateExpression、implementationReceive Task接收任务bpmn:receiveTaskmessageRef配合消息流使用Exclusive Gateway排他网关bpmn:exclusiveGatewaydefault 属性指定默认出口Sequence Flow序列流bpmn:sequenceFlowconditionExpression条件只在网关出口有意义Message Flow消息流bpmn:messageFlowsourceRef、targetRef必须跨池这张表解决的是术语层到技术层的翻译问题。建模时节点 name 写成中文标准术语但 XML 里的 id 要用英文语义命名assignee 属性是表达式或用户 ID不是中文名。读术语表的人如果不知道这个映射画图时会把“审批人”写进 name然后在 assignee 里填“部门领导”部署后 Camunda 把它当字符串处理任务派给了字面意义上的“部门领导”直接报错。参数说明assignee 可以是固定用户 ID也可以写成 ${leader} 这类表达式candidateGroups 是候选组标识。术语表不负责定义表达式语法但它能帮你先确认“这个任务到底是给谁的”避免在属性里填错。5.2 按术语表做 XML 一致性检查命名规则和事件白名单有了映射表就能做一致性检查。最靠谱的做法是先把模型命名规范定下来再在 XML 导出后跑一轮检查。命名规则我一般这样定节点 id 使用英文动词短语前缀标记元素类型比如 start_、task_、gw_、end_节点 name 使用中文标准术语加业务名比如“用户任务-部门领导审批”事件定义只允许团队子集里的类型看到条件事件或补偿事件时先回术语表确认有没有放行。# 1. 检查是否有节点 id 不满足命名前缀 grep -o id[^]* model.bpmn | grep -Ev id(start_|task_|gw_|end_) echo 存在不符合命名规则的节点 id # 2. 检查允许的事件类型白名单 grep -oE (timer|message|signal|none|error)EventDefinition model.bpmn | sort | uniq -c逻辑说明第一个命令把模型里所有 id 属性抽出来反选掉 start_、task_、gw_、end_ 这些前缀只要还有输出就说明有节点绕过命名规范。第二个命令统计事件定义类型如果出现白名单以外的 conditionalEventDefinition、escalationEventDefinition就要回头核对术语表子集。参数说明前缀按团队子集调整即可不用照抄uniq -c 前的 sort 是为了去重统计输出左边是次数右边是事件类型一眼能看出哪些事件被大量使用、哪些不该出现的出现了一次。这类检查适合放在引擎部署前由流程工程师手动跑或者直接接进 CI不需要引入复杂工具grep 已经能拦住最明显的不一致。5.3 把术语表版本写进模型文档头让模型自描述语义来源还有一个让评审更省事的小动作在 BPMN 2.0 XML 的 definitions 节点里加一段 documentation记录模型遵循的术语表版本号和两条最重要的图例约束。这样文件无论传到谁手里打开 XML 就能看到术语依据不用到处问人。bpmn:definitions xmlns:bpmnhttp://www.omg.org/spec/BPMN/20100524/MODEL targetNamespacehttp://example.com/bpmn/leave bpmn:documentation 术语依据BPMN2_0_Symbols-Terms_CHN.pdf 内部流程子集 图例约束用户任务必须配置 assignee 或候选组排他网关必须配置默认出口。 /bpmn:documentation /bpmn:definitions逻辑说明documentation 节点会被建模工具显示出来评审时打开模型属性就能看到约束说明不需要再翻聊天记录。targetNamespace 是项目自定义命名空间替换成业务模块名即可。参数说明如果流程要跨团队复用把术语表版本号写清楚便于后续追踪“这张图是依照哪个版本画的”。引擎不会执行这段文字但它能提醒后续维护的人换术语表版本后旧模型的命名和符号要不要统一回迁。到这一步术语表就从 PDF 变成了模型自描述的一部分而不是网盘里的死文档。6. 吃透符号与术语后我每次建模前和评审后必做的两件事第一件事建模前先写一句话流程描述把整个过程从开始事件到结束事件串成主谓宾。比如“HR 发起请假申请部门领导审批超过三天转总监审批HR 归档结束”。这句话写在绘图工具和术语表之外先把执行顺序说顺。一句说不顺的地方画出来多半也是错的。写完再对照术语表逐个节点选型确认开始事件触发方式、中间事件是不是必须、网关条件有没有互斥这套流程走下来建模错误能少一大半。第二件事评审结束后导出一份 BPMN XML用前面那段 grep 命令跑一遍检查重点看节点 id 前缀和事件类型白名单。如果业务方本次只提了 name 和 assignee 的修改我只动这些字段不去重构节点类型和 id避免一条看似很小的改动引入新的不一致。顺手再把 documentation 里的术语表版本号更新掉保持模型自描述和实际用的一致。还有一个私心技巧把术语表按位置切成三份一份管事件一份管活动一份管网关。拿不准节点类型时先问自己“这个符号出现在流程的哪一段”而不是“这个图形长什么样”。我发现大部分误用都来自从图形倒推语义而不是从语义选图形。这套习惯坚持半年后评审会上关于“这是什么符号”的争论基本消失剩下的都是真实的业务分歧。希望这些能帮到你也帮团队把流程图真正当作可执行的东西来用。本文还有配套的精品资源点击获取