转载请注明出处
最近工作需要,学习下BPMN,国内很少有完善的资料,所以翻译一下官方文档。原文在此——>链接
- BPMN基础
- 事件(Event)
- 启动事件(Start Event)
- 中间事件(Intermediate Event)
- 结束事件(End Event)
- 活动(Activity)
- 任务(Task)
- 副流程基础(Sub Process Basics)
- 副流程(Sub Process)
- 特设副流程( Adhoc Sub Process)
- 事务(Transaction)
- 事件副流程(Event Sub Process)
- 调用活动(Call Activity)
- 关口(Gateway)
- 流(Flow)
- 序列流(Sequence Flow)
- 消息流(Message Flow)
- 关联(Association)
- 数据关联(Data Association)
- 数据(Data)
- 器物(Artifact)
- 泳道基础(Swimlane Basics)
- 泳道(Lane)
- 池(Pool)
- BPMN基本规则
- 序列流
- 用于显示活动在子流程当中的执行顺序
- 不能跨越副流程的边界
- 不能跨越池的边界
- 消息流
- 用于表示参与者之间的交流
- 不能用来连接同一池内的对象
- 边界事件
- 必须且最多拥有一个向外的序列流
- 必须没有任何向内的序列流
- 副流程
- 副流程当中的启动事件类型必须为空(None)
- BPMN当中的常见错误和澄清
- 流程,模型,图表和文件
- 在BPMN中,流程,模型,图表和文件的关系不是对等的。
- 一个BPMN模型中,可能会包含一个或多个BPMN业务流程(如在协作中)
- BPMN模型的组成部分可以保存在各种文件中
- 一个BPMN图描述了一个BPMN流程模型的子集(也有可能是完整的)
- 一个BPMN模型可以使用多个图来描述
- 数据流
- BPMN图不是数据流图
- 尽管数据对象是BPMN中的一级实体,但不建议使用BPMN对数据流进行建模。
- 关口
- 关口不是决定本身
- 关口也不做决定,它只负责导向
- 决定结果应当在关口之前的一项活动(Activity)中确定
- 手工,自动和半自动任务
- 使用手工任务来描述不借助任何软件应用的情况下所做的工作
- 用户任务用来描述半自动化的工作——人使用软件应用来完成任务
- 服务任务用来描述完全自动化的工作
- 发送和接收消息
- 如果认为消息的发送和接收是实时的,就需要使用消息事件(Message Event)
- 如果消息的发送和接收是可中断的,就使用消息任务(Message Task)
- 从时间的角度来看,一个事件映射到时间轴上的一个时间点,一个任务映射到时间轴上的一段时间间隔。
- BPMN命名规范最佳实践
BPMN没有官方指定的命名惯例,但这里有一些多年来公认的最佳实践。
- 始终使用对业务有意义的关键词
- 不要使用不常见的缩写
- 不要在名称中带有元素类型
- 避免使用文章和代词
- 活动(Activity)
- 用动词+名词短语来命名活动
- 使用对企业有意义的主动语态助词的现在时
- 使用对企业有意义的限定名词
- 不要用同一个名字命名多个活动(调用活动除外)
- 关口(Gateway)
- 关口并不执行任何工作,也不做任何决策,它只是流的分流或者聚合的可视化。
- 不要给聚合关口命名
- 当聚合逻辑不明显的时候,关联一个文本注释
- 用问句命名分流的独占关口(Exclusive Gateway)
- 序列流(Sequence Flows)
- 对独占/兼容/聚合分流关口流出的序列流加以命名,并将其条件作为结果说明
- 对条件序列流(Conditional Sequence Flows)加以命名,使用其相关条件作为结果
- 不要命名默认序列流
- 事件(Events)
- 所有事件都需要命名
- 使用主动语态的过去时命名消息/信号/升级/错误事件
- 用名词命名连接事件(Link Event)
- 使用匹配的名称来命名配对的消息/链接/信号/升级/错误事件
- 用时间计划命名定时事件(Timer Event)
- 使用触发条件命名条件事件(Conditional Event)
- 使用结束状态的名称来命名结束事件(End Event)
- 数据对象(Data Object)
- 所有数据对象都应当命名
- 使用一个特定的名词来命名数据对象,该名词是业务对象或者对业务有意义的信息对象的名称
- 使用一个匹配的名称来命名同一数据对象的多个实例(实际上是数据对象引用),后面用方括号标明适用的状态。
- 参与者(Participants)
- 使用特定的名词或者名词短语来命名参与者
- 角色(Roles)
- 使用特定的名称或者名词短语来命名角色
- 池(Pools)
- 使用参与者的名称来命名池
- 不要用流程名称来命名池
- 在BPMN中,池是对参与者的一种描述
- 泳道(Lanes)
- 使用类别(Category)名称来命名泳道
- 泳道通常用于按角色(Role)对元素进行分类
- BPMN建模最佳实践
- 流程范围(Process Scope)
- 通过确定流程中的5W(谁,做什么,什么时候,在哪里,为什么)来确定明确的流程范围(流程本身就是为什么)
- 确定流程中的每个实例代表什么
- 实例是完整和明确的:你可以列出每一个实例以及计算出它们的数量
- 准备好潜在的替代方法来触发由开始事件(Start Event)发起的流程
- 对于使用了结束事件(End Event)的流程,准备好潜在的替代状态来表示
- 图表布局(Diagram layouts)
- 最好正好塞满一页纸
- 布局要整齐,通过最大限度减少交叉流程来增加可读性
- 使用水平序列流和垂直的数据关联/消息流的一致性布局
- BPMN图虽然没有严格的时间顺序(因为可以成环),但为了遵循阅读习惯,最好还是从左到右
- 不要创建过于曲折的元素布局
- 应该明确流程的主线是什么
- 只要有可能,就将业务规则从流程中外部化,使用业务规则任务(Business Rule Task)创建更简洁,更敏捷的流程模型
- 为不同的沟通目的和利益相关者创建同一流程的不同可视化
- 一个包含所有副流程和调用活动的汇总图,折叠后不显示任何数据对象
- 一个包含所有副流程和调用活动的汇总图,展开后显示所有数据对象以及注释
- 流程分割和结构(Process Partitioning and Structure)
- 创建层次分明的多层细节
- 使用副流程将流程分割成阶段
- 使用调用活动(Call Activity)来复用其他的流程
开始和结束事件(Start and End Event)
- 永远都要带有开始和结束事件
- 将流程的替代实例区分为单独的启动事件(Start Event)
- 将各种终止状态区分为独立的结束事件(End Event)
- 在同一终止状态下结束的流应当合并到同一个结束事件
- 关口(Gateway)
- 始终使用关口来描述流的拆分和合并
- 不要使用混合模式的网关(比如同时包含拆分和合并)
- 始终将确定拆分条件的活动放在独占/兼容/复合类型的关口,这样做的其中一个好处是可以在有需要的时候直接终止这个决策活动
- 将多个菊花链分支的网关抽象成一个业务规则任务
- 协作(Collaborations)
- 不要将重点内部流程建模成Pool