本文主要是介绍过程建模EPC，我拿什么拯救你，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
作者 ：胡长城 [ 银狐999 ]
http://www.javafox.org
http://blog.csdn.net/james999
完成日期：2006-10-8 version 1.0
联系信箱：james-fly@vip.sina.com
MSN ：fcxiao2000@hotmail.com
引言
EPC是一种过程建模方法，全称是 Event-driven Process Chain。在九十年代初期才由Keller等人提出。对于EPC，国内开发人员是陌生的，可能很多人听说EPC【 01】，也仅仅是在ARIS（ Architecture of Integrated Information System）系统框架中接触过一些。EPC可能很多人是陌生的，但SAP R3可能很多人或多或少听过，SAP R3就是基于EPC过程建模的。
我也仅仅只是在2004年中的时候才接触过EPC这个概念的，那时候还在 思维加速公司（现在叫起步公司了）研发Biz5.0系统，为了在Process Model这一层寻找一套方法论的支持，查阅了大量的建模方法资料，其中就包括EPC。
但那时候接触的业务场景和业务范围很局限，虽然对EPC很认同，却不敢轻易的深入和采用，加上当时受Alast的 YAWL的影响，所以更加痴迷于PetriNet。——很遗憾的是，那个时候没有看出EPC与PN之间是有很大关联性的，这是后话。
2004年底进入USE（ 用友软件工程），接手了工作流引擎的开发。虽然那时候很想按照自己的思路采用PN或EPC的模型来开发，但当时在我之前的开发人员已经花费了大量时间在XPDL模型语言上，并做出了一款可运行的Deme和设计器，对我来说，当时的首要任务是重构出一款实际可用的引擎，而不是重新开发一个工作流系统。
不得已，我只能采用XPDL流程模型，也只能选择重构，这在我去年写的《 工作流引擎核心调度算法与PetriNet》【 03】已经稍稍提及了。虽然模型这个层面让我很被动，但是由于至少还可以把握引擎结构和调度算法这一层，或多或少弥补了很多。
其实，那个时候即使允许采用PN或EPC，心里其实也是没有多少底的。毕竟早先我很多的研究基础也是基于WfMC的参考模型和XPDL描述语言的。两年之后再回过头来看看，心中已经很清晰了，至少那几个过程模型的思想已经很有把握了。
说道这儿，顺带说两个方面的个人观点，这两个方面与主题没有直接关系，但是有间接关系。以后我会写专门的文档来阐述我的这两个观点，此处我就不多加解释了，“仁者见仁，智者见智”，有心者自己把握吧。
第一：我不是很喜欢XPDL流程描述模型，但目前国内绝大多数的厂商采用的是XPDL描述模型及扩展，这没有任何不妥。目前国内的流程应用范围主要还集中在类似OA审批流之类的应用上，这一层面的应用XPDL的模型所描述的语义基本可以满足大家的理解和应用了。再加之绝大多数的客户更偏重于“离散型活动关系”，这就让建模的约束又浅了一层。
第二：在引擎构建上，需要把握关键的三点：过程模型建模、引擎调度算法和状态变迁、实例之间的对象关系。把握了这三点，则基本能够奠定一个引擎的主线结构。这好比是写文章的“主线”。当然，一篇好的文章，光有一个好的主线逻辑和构思是不够的，但主线是核心，写工作流引擎，也类似。
自从2005年初写出那款引擎之后，就很长时间没有想去写一个引擎的冲动了。这似乎是开发人员的一种诟病，如果感觉现在所做的研发或者开发，不能让自己超越现在的自己，则会丧失很大兴趣，甚至放弃。我当时就是那种状态。
我没有再去做工作流研发，但是却没有放弃对工作流的研究。从2005年中开始，我自己利用业余时间在默默地研究，也利用给别人培训和讲课的机会，对相关知识进行巩固和升华。这一年多来，收获是不小的，但是却没有再公开什么文章，是比较沉寂的一年。
什么是EPC
前面废话说了一堆，现在正式转入正题。
前段时间，公司接了一个物流的项目，其中有一个子系统是要做WMS（仓储管理系统），主要是处理物品入库、出库、库存的流程管理。我看这个WMS子系统的需求之后，对其内部所需要处理的流程、单据状态等业务场景，脑海中第一个念头就是应该采用EPC用于建模抽象。可惜这只是脑海中的一个念头而以，现实中，是不可能这么去实施这个项目的。（这是令人痛心的，不过国内很多项目的实施，是很应付性的，也很难听取开发人员的意见）。
回到家后，又把之前所搜刮到的有关EPC的资料翻了翻。其中有两篇文档在这里提一提：
第一篇就是《 SAP R/3 Business Blueprint:Understanding Enterprise Supply Chain Management》【 02】，这本书有一章节专门讲了EPC建模的要素，并且在后续章节中，用了大量的图例诠释了如何用EPC流程构建业务流程。
书中主要点了EPC的四个主要要素： 事件（Event）、功能（Function）、组织单元（Orgnization Unit）、信息（Data）（事实上，OU和Data这两个要素是ARIS系统框架中的）。由于本书的宗旨主要在于业务诠释，所以对于这几个要素讲解的不够概念化、形式化。但读完后，用EPC的图例绘制业务流程图，估计没有多大难度了。
| 元素 | 图例 | 描述 |
| Event |  | 描述了状态的发生，同时又充当了一个触发器 |
| Function |  | 功能描述了一个任务的执行，代表了一个start event和end event转换过程 |
| Orgnization Unit |  | |
| Data |  | |
| Process Path |  | 流程之间的连接关系 |
| Logical Connectors |  | 逻辑连符号：AND,OR,XOR |
让我们来看一个例子，可以加深对EPC所构建的流程模型的理解：下图显示的是一个货物接收处理的流程。
第二篇就是Alast大师写的《 Formalization and Verification of Event-driven Process Chains》【 04】。Alast是位Petri Net领域的专家，这篇文档也依然没有脱离PN角度。
这篇文档从“过程”角度给出了EPC的几个元素解释：
| 元素 | 描述 |
| Functions | A function corresponds to an activity (task, process step) which needs to be executed. |
| Events | Events describe the situation before and/or after a function is executed. Functions are linked by events. An event may correspond to the postcondition of one function and act as a precondition of another function. |
| Logical connectors | Connectors can be used to connect activities and events. This way the flow of control is specified. There are three types of connectors: AND, XOR (exclusive or) and OR |
Alast这篇文章另外一个重要内容，就是做了EPC到PetriNet的映射，但不涉及到对OR逻辑连接符的映射，因为OR的语义有多种诠释，不是非常清晰明确，这在Alast的这篇文档中也已经说明。
EPC的Event可以映射为PN中的库所（Place），而Function可以映射为PN中的变迁（Transition）。而至于逻辑连接符AND和XOR的映射在采用Place的控制，很容易表示：
国内EPC应用的匮乏
看到这儿，估计大家对EPC过程模型能够有个基本的认识。因为本篇不是讲解EPC的，而只是想说明： EPC在业务建模方面为我们提供了很好的参考，但是国内当前基于EPC模型的流程产品或业务产品几乎没有。在网络上搜索中文EPC的资料，仅有寥寥几篇，而且主要还都是因为讲解ARIS框架而顺带提及的。
到不是说EPC是一剂万能的良药，事实上EPC也仅是过程建模的一种。几个过程建模诸如 PetriNet、EPC、Activity Diagram、FSM等，如果可能的话， XPDL的定义元模型也算一种。
但是国内这几年的工作流相关的产品和应用发展，受WfMC的XPDL影响很深。
一方面是因为国内自身的理论研究过于薄弱和苍白，可能有些研究人员会注意到上述的那些过程建模方法，但是由于这些过程建模方法并没有形成完整的形式化描述语言支持（事实上，是有一些的，比如基于PN的PNML，基于EPC的EPML等，但是这些xml的描述语言过于理论化，不像XPDL那样偏应用），所以很难直接被一些开发厂商了解。
而另一方面，这几年国内工作流应用的主要领域依然是OA及相关审批流程。在这样一个“偏重用户自主行为控制”的流程应用领域，XPDL所阐述的流程元模型对象：Process、Activity、Transition、Participant已经基本可以描述一个完整的流程。在可以完整描述完一个流程之后，大部分厂商都把重点放在了：（1）通过扩展属性来丰富流程定义；（2）通过完善引擎的功能支持一些用户行为化的操作，诸如退回、自由流等。
但很少有厂商真正的反思一下，XPDL的过程建模就一定完善吗？合适吗？。 对于XPDL来说，有个最大的缺陷就是缺少对State和Event的描述（在XPDL2.0中已经部分的纳入Event概念了）。
而对于其他过程建模PetriNet、EPC、Activity Diagram、FSM这几个来说，State是一个核心的元素：
| 过程建模方法 | 基本模型元素 | 表示State的对象 |
| PetriNet | Place,Transition | Place |
| EPC | Event,Function,Connectors | Event |
| Activity Diagram | State,Decision | State |
| FSM | State,Action | State |
| XPDL Metedata | Activity,Transition |
在这几个过程建模方法中，EPC是最偏重于商业业务化流程的。但是却是国内应用却是空白的。
据我所知道的，目前国内已经有两三家厂商已经采用PetriNet作为流程描述模型；OSWorkflow和jBpm这两款开源引擎的应用，也已经让部分厂商在不知不觉中采用了FSM和Activity Diagram模型。唯独EPC没有应用（当然那些采用SAP R3的除外）。
我记得在2001年，我还在有生博大公司研发RiseOffice5.0公文流程系统，那时候采用的是Task和Action对象，有些类似FSM的State和Action。不过现在有生博大新版的RiseOffice工作流系统，已经采用XPDL模型了。—— 其实这也是国内很多厂商的一个开发趋势：虽然不了解“过程建模”，但是知道XPDL可以描述流程。
事实上， EPC所抽象的模型，很适合诸如B2B、供应链流程管理、仓储物流管理等商业化业务流程。这样的业务流程有个很共同的特点，对于“活动处理的前后状态”很在意。一旦把握了状态，则可以依据状态来丰富业务对象的生命周期控制和业务规则控制，这两点在业务系统中是比较重视的。
相比较而言，XPDL的元模型则仅仅只描述了“活动与活动之间的连接关系”，则很难在模型角度就看清楚活动之间所影响的状态及变更关系。
但很少有开发商或者开发人员去反思这个问题：活动与状态。XPDL虽然屏蔽了“状态”这个理念，但是由于其是目前最为“完善的XML描述化流程语言”（当然，这里我们不去谈论BPEL、BPML之类的规范），对于开发商来说，只需要考虑遵循规范和扩展，则可以基本清晰的描述一个“流程”，虽然不能够表达流程各个区段的状态问题，但是却可以清楚地展现“活动之间的关系”。
更况，国内的流程发展，这几年主要依赖于办公自动化和审批流，加上 国内应用偏重于“离散活动点的组合关系”，也就是说，在很多客户眼力：流程就是一个个离散的任务，这些任务在不同情况下可以很随意的组合。而这样的需求，是XPDL所依赖于的Activity和Transition所基本可以描述的。
加之WfMC毕竟是一个有着十多年的国际化标准组织，对客户，对开发商来说，这样的组织和标准，都是比较容易接受的。
而EPC,PetriNet,FSM,Activity Diagram则显得很脆弱，没有国际化的组织支撑，没有完善的描述语言支撑。最令人叹息的就是，在XPDL的描述模型中，几乎找不到任何这四个模型的影子，似乎WfMC在有意回避这几个建模思想。
国内的业务化建模流程，应该吸纳EPC这样建模方法，特别是在业务化系统中，比如B2B、供应链流程管理、仓储物流管理等商业化流程系统中。当然这样的代价是比较高的，需要基于这些模型元素和思想，自主摸索出一套完整描述语言。事实上，SAP R3的成功是很值得大家借鉴的。
下面把仓储管理系统中的一个入库流程中的“入库订单处理”用EPC模型表示，如下：
参考文档
【 01】 G. Keller, M. Nüttgens, A.-W. Scheer. Semantische Prozessmodellierung auf
der Grundlage „Ereignisgesteuerte Prozessketten (EPK)“. Veröffentlichung
des Institut für Wirtschaftsinformatik, Paper 089, Saarbrücken, 1992
(http://www.iwi.uni-sb.de/iwi-hefte/heft089.ps).
【 02】 Thomas A. Curran, Andrew Ladd. SAP R/3 Business Blueprint:Understanding Enterprise Supply Chain Management,2003
【 03】胡长城，《工作流引擎核心调度算法与PetriNet》，2005年
【 04】W.M.P. van der Aalst, Formalization and Verification of Event-driven Process Chains
作者 ：胡长城 [ 银狐999 ]
http://www.javafox.org
http://blog.csdn.net/james999
完成日期：2006-10-8 version 1.0
联系信箱：james-fly@vip.sina.com
MSN ：fcxiao2000@hotmail.com
引言
EPC是一种过程建模方法，全称是 Event-driven Process Chain。在九十年代初期才由Keller等人提出。对于EPC，国内开发人员是陌生的，可能很多人听说EPC【 01】，也仅仅是在ARIS（ Architecture of Integrated Information System）系统框架中接触过一些。EPC可能很多人是陌生的，但SAP R3可能很多人或多或少听过，SAP R3就是基于EPC过程建模的。
我也仅仅只是在2004年中的时候才接触过EPC这个概念的，那时候还在 思维加速公司（现在叫起步公司了）研发Biz5.0系统，为了在Process Model这一层寻找一套方法论的支持，查阅了大量的建模方法资料，其中就包括EPC。
但那时候接触的业务场景和业务范围很局限，虽然对EPC很认同，却不敢轻易的深入和采用，加上当时受Alast的 YAWL的影响，所以更加痴迷于PetriNet。——很遗憾的是，那个时候没有看出EPC与PN之间是有很大关联性的，这是后话。
2004年底进入USE（ 用友软件工程），接手了工作流引擎的开发。虽然那时候很想按照自己的思路采用PN或EPC的模型来开发，但当时在我之前的开发人员已经花费了大量时间在XPDL模型语言上，并做出了一款可运行的Deme和设计器，对我来说，当时的首要任务是重构出一款实际可用的引擎，而不是重新开发一个工作流系统。
不得已，我只能采用XPDL流程模型，也只能选择重构，这在我去年写的《 工作流引擎核心调度算法与PetriNet》【 03】已经稍稍提及了。虽然模型这个层面让我很被动，但是由于至少还可以把握引擎结构和调度算法这一层，或多或少弥补了很多。
其实，那个时候即使允许采用PN或EPC，心里其实也是没有多少底的。毕竟早先我很多的研究基础也是基于WfMC的参考模型和XPDL描述语言的。两年之后再回过头来看看，心中已经很清晰了，至少那几个过程模型的思想已经很有把握了。
说道这儿，顺带说两个方面的个人观点，这两个方面与主题没有直接关系，但是有间接关系。以后我会写专门的文档来阐述我的这两个观点，此处我就不多加解释了，“仁者见仁，智者见智”，有心者自己把握吧。
第一：我不是很喜欢XPDL流程描述模型，但目前国内绝大多数的厂商采用的是XPDL描述模型及扩展，这没有任何不妥。目前国内的流程应用范围主要还集中在类似OA审批流之类的应用上，这一层面的应用XPDL的模型所描述的语义基本可以满足大家的理解和应用了。再加之绝大多数的客户更偏重于“离散型活动关系”，这就让建模的约束又浅了一层。
第二：在引擎构建上，需要把握关键的三点：过程模型建模、引擎调度算法和状态变迁、实例之间的对象关系。把握了这三点，则基本能够奠定一个引擎的主线结构。这好比是写文章的“主线”。当然，一篇好的文章，光有一个好的主线逻辑和构思是不够的，但主线是核心，写工作流引擎，也类似。
自从2005年初写出那款引擎之后，就很长时间没有想去写一个引擎的冲动了。这似乎是开发人员的一种诟病，如果感觉现在所做的研发或者开发，不能让自己超越现在的自己，则会丧失很大兴趣，甚至放弃。我当时就是那种状态。
我没有再去做工作流研发，但是却没有放弃对工作流的研究。从2005年中开始，我自己利用业余时间在默默地研究，也利用给别人培训和讲课的机会，对相关知识进行巩固和升华。这一年多来，收获是不小的，但是却没有再公开什么文章，是比较沉寂的一年。
什么是EPC
前面废话说了一堆，现在正式转入正题。
前段时间，公司接了一个物流的项目，其中有一个子系统是要做WMS（仓储管理系统），主要是处理物品入库、出库、库存的流程管理。我看这个WMS子系统的需求之后，对其内部所需要处理的流程、单据状态等业务场景，脑海中第一个念头就是应该采用EPC用于建模抽象。可惜这只是脑海中的一个念头而以，现实中，是不可能这么去实施这个项目的。（这是令人痛心的，不过国内很多项目的实施，是很应付性的，也很难听取开发人员的意见）。
回到家后，又把之前所搜刮到的有关EPC的资料翻了翻。其中有两篇文档在这里提一提：
第一篇就是《 SAP R/3 Business Blueprint:Understanding Enterprise Supply Chain Management》【 02】，这本书有一章节专门讲了EPC建模的要素，并且在后续章节中，用了大量的图例诠释了如何用EPC流程构建业务流程。
书中主要点了EPC的四个主要要素： 事件（Event）、功能（Function）、组织单元（Orgnization Unit）、信息（Data）（事实上，OU和Data这两个要素是ARIS系统框架中的）。由于本书的宗旨主要在于业务诠释，所以对于这几个要素讲解的不够概念化、形式化。但读完后，用EPC的图例绘制业务流程图，估计没有多大难度了。
| 元素 | 图例 | 描述 |
| Event | | 描述了状态的发生，同时又充当了一个触发器 |
| Function | | 功能描述了一个任务的执行，代表了一个start event和end event转换过程 |
| Orgnization Unit | | |
| Data | | |
| Process Path | | 流程之间的连接关系 |
| Logical Connectors | | 逻辑连符号：AND,OR,XOR |
让我们来看一个例子，可以加深对EPC所构建的流程模型的理解：下图显示的是一个货物接收处理的流程。
第二篇就是Alast大师写的《 Formalization and Verification of Event-driven Process Chains》【 04】。Alast是位Petri Net领域的专家，这篇文档也依然没有脱离PN角度。
这篇文档从“过程”角度给出了EPC的几个元素解释：
| 元素 | 描述 |
| Functions | A function corresponds to an activity (task, process step) which needs to be executed. |
| Events | Events describe the situation before and/or after a function is executed. Functions are linked by events. An event may correspond to the postcondition of one function and act as a precondition of another function. |
| Logical connectors | Connectors can be used to connect activities and events. This way the flow of control is specified. There are three types of connectors: AND, XOR (exclusive or) and OR |
Alast这篇文章另外一个重要内容，就是做了EPC到PetriNet的映射，但不涉及到对OR逻辑连接符的映射，因为OR的语义有多种诠释，不是非常清晰明确，这在Alast的这篇文档中也已经说明。
EPC的Event可以映射为PN中的库所（Place），而Function可以映射为PN中的变迁（Transition）。而至于逻辑连接符AND和XOR的映射在采用Place的控制，很容易表示：
国内EPC应用的匮乏
看到这儿，估计大家对EPC过程模型能够有个基本的认识。因为本篇不是讲解EPC的，而只是想说明： EPC在业务建模方面为我们提供了很好的参考，但是国内当前基于EPC模型的流程产品或业务产品几乎没有。在网络上搜索中文EPC的资料，仅有寥寥几篇，而且主要还都是因为讲解ARIS框架而顺带提及的。
到不是说EPC是一剂万能的良药，事实上EPC也仅是过程建模的一种。几个过程建模诸如 PetriNet、EPC、Activity Diagram、FSM等，如果可能的话， XPDL的定义元模型也算一种。
但是国内这几年的工作流相关的产品和应用发展，受WfMC的XPDL影响很深。
一方面是因为国内自身的理论研究过于薄弱和苍白，可能有些研究人员会注意到上述的那些过程建模方法，但是由于这些过程建模方法并没有形成完整的形式化描述语言支持（事实上，是有一些的，比如基于PN的PNML，基于EPC的EPML等，但是这些xml的描述语言过于理论化，不像XPDL那样偏应用），所以很难直接被一些开发厂商了解。
而另一方面，这几年国内工作流应用的主要领域依然是OA及相关审批流程。在这样一个“偏重用户自主行为控制”的流程应用领域，XPDL所阐述的流程元模型对象：Process、Activity、Transition、Participant已经基本可以描述一个完整的流程。在可以完整描述完一个流程之后，大部分厂商都把重点放在了：（1）通过扩展属性来丰富流程定义；（2）通过完善引擎的功能支持一些用户行为化的操作，诸如退回、自由流等。
但很少有厂商真正的反思一下，XPDL的过程建模就一定完善吗？合适吗？。 对于XPDL来说，有个最大的缺陷就是缺少对State和Event的描述（在XPDL2.0中已经部分的纳入Event概念了）。
而对于其他过程建模PetriNet、EPC、Activity Diagram、FSM这几个来说，State是一个核心的元素：
| 过程建模方法 | 基本模型元素 | 表示State的对象 |
| PetriNet | Place,Transition | Place |
| EPC | Event,Function,Connectors | Event |
| Activity Diagram | State,Decision | State |
| FSM | State,Action | State |
| XPDL Metedata | Activity,Transition |
在这几个过程建模方法中，EPC是最偏重于商业业务化流程的。但是却是国内应用却是空白的。
据我所知道的，目前国内已经有两三家厂商已经采用PetriNet作为流程描述模型；OSWorkflow和jBpm这两款开源引擎的应用，也已经让部分厂商在不知不觉中采用了FSM和Activity Diagram模型。唯独EPC没有应用（当然那些采用SAP R3的除外）。
我记得在2001年，我还在有生博大公司研发RiseOffice5.0公文流程系统，那时候采用的是Task和Action对象，有些类似FSM的State和Action。不过现在有生博大新版的RiseOffice工作流系统，已经采用XPDL模型了。—— 其实这也是国内很多厂商的一个开发趋势：虽然不了解“过程建模”，但是知道XPDL可以描述流程。
事实上， EPC所抽象的模型，很适合诸如B2B、供应链流程管理、仓储物流管理等商业化业务流程。这样的业务流程有个很共同的特点，对于“活动处理的前后状态”很在意。一旦把握了状态，则可以依据状态来丰富业务对象的生命周期控制和业务规则控制，这两点在业务系统中是比较重视的。
相比较而言，XPDL的元模型则仅仅只描述了“活动与活动之间的连接关系”，则很难在模型角度就看清楚活动之间所影响的状态及变更关系。
但很少有开发商或者开发人员去反思这个问题：活动与状态。XPDL虽然屏蔽了“状态”这个理念，但是由于其是目前最为“完善的XML描述化流程语言”（当然，这里我们不去谈论BPEL、BPML之类的规范），对于开发商来说，只需要考虑遵循规范和扩展，则可以基本清晰的描述一个“流程”，虽然不能够表达流程各个区段的状态问题，但是却可以清楚地展现“活动之间的关系”。
更况，国内的流程发展，这几年主要依赖于办公自动化和审批流，加上 国内应用偏重于“离散活动点的组合关系”，也就是说，在很多客户眼力：流程就是一个个离散的任务，这些任务在不同情况下可以很随意的组合。而这样的需求，是XPDL所依赖于的Activity和Transition所基本可以描述的。
加之WfMC毕竟是一个有着十多年的国际化标准组织，对客户，对开发商来说，这样的组织和标准，都是比较容易接受的。
而EPC,PetriNet,FSM,Activity Diagram则显得很脆弱，没有国际化的组织支撑，没有完善的描述语言支撑。最令人叹息的就是，在XPDL的描述模型中，几乎找不到任何这四个模型的影子，似乎WfMC在有意回避这几个建模思想。
国内的业务化建模流程，应该吸纳EPC这样建模方法，特别是在业务化系统中，比如B2B、供应链流程管理、仓储物流管理等商业化流程系统中。当然这样的代价是比较高的，需要基于这些模型元素和思想，自主摸索出一套完整描述语言。事实上，SAP R3的成功是很值得大家借鉴的。
下面把仓储管理系统中的一个入库流程中的“入库订单处理”用EPC模型表示，如下：
参考文档
【 01】 G. Keller, M. Nüttgens, A.-W. Scheer. Semantische Prozessmodellierung auf
der Grundlage „Ereignisgesteuerte Prozessketten (EPK)“. Veröffentlichung
des Institut für Wirtschaftsinformatik, Paper 089, Saarbrücken, 1992
(http://www.iwi.uni-sb.de/iwi-hefte/heft089.ps).
【 02】 Thomas A. Curran, Andrew Ladd. SAP R/3 Business Blueprint:Understanding Enterprise Supply Chain Management,2003
【 03】胡长城，《工作流引擎核心调度算法与PetriNet》，2005年
【 04】W.M.P. van der Aalst, Formalization and Verification of Event-driven Process Chains
作者 ：胡长城 [ 银狐999 ]
http://www.javafox.org
http://blog.csdn.net/james999
完成日期：2006-10-8 version 1.0
联系信箱：james-fly@vip.sina.com
MSN ：fcxiao2000@hotmail.com
引言
EPC是一种过程建模方法，全称是 Event-driven Process Chain。在九十年代初期才由Keller等人提出。对于EPC，国内开发人员是陌生的，可能很多人听说EPC【 01】，也仅仅是在ARIS（ Architecture of Integrated Information System）系统框架中接触过一些。EPC可能很多人是陌生的，但SAP R3可能很多人或多或少听过，SAP R3就是基于EPC过程建模的。
我也仅仅只是在2004年中的时候才接触过EPC这个概念的，那时候还在 思维加速公司（现在叫起步公司了）研发Biz5.0系统，为了在Process Model这一层寻找一套方法论的支持，查阅了大量的建模方法资料，其中就包括EPC。
但那时候接触的业务场景和业务范围很局限，虽然对EPC很认同，却不敢轻易的深入和采用，加上当时受Alast的 YAWL的影响，所以更加痴迷于PetriNet。——很遗憾的是，那个时候没有看出EPC与PN之间是有很大关联性的，这是后话。
2004年底进入USE（ 用友软件工程），接手了工作流引擎的开发。虽然那时候很想按照自己的思路采用PN或EPC的模型来开发，但当时在我之前的开发人员已经花费了大量时间在XPDL模型语言上，并做出了一款可运行的Deme和设计器，对我来说，当时的首要任务是重构出一款实际可用的引擎，而不是重新开发一个工作流系统。
不得已，我只能采用XPDL流程模型，也只能选择重构，这在我去年写的《 工作流引擎核心调度算法与PetriNet》【 03】已经稍稍提及了。虽然模型这个层面让我很被动，但是由于至少还可以把握引擎结构和调度算法这一层，或多或少弥补了很多。
其实，那个时候即使允许采用PN或EPC，心里其实也是没有多少底的。毕竟早先我很多的研究基础也是基于WfMC的参考模型和XPDL描述语言的。两年之后再回过头来看看，心中已经很清晰了，至少那几个过程模型的思想已经很有把握了。
说道这儿，顺带说两个方面的个人观点，这两个方面与主题没有直接关系，但是有间接关系。以后我会写专门的文档来阐述我的这两个观点，此处我就不多加解释了，“仁者见仁，智者见智”，有心者自己把握吧。
第一：我不是很喜欢XPDL流程描述模型，但目前国内绝大多数的厂商采用的是XPDL描述模型及扩展，这没有任何不妥。目前国内的流程应用范围主要还集中在类似OA审批流之类的应用上，这一层面的应用XPDL的模型所描述的语义基本可以满足大家的理解和应用了。再加之绝大多数的客户更偏重于“离散型活动关系”，这就让建模的约束又浅了一层。
第二：在引擎构建上，需要把握关键的三点：过程模型建模、引擎调度算法和状态变迁、实例之间的对象关系。把握了这三点，则基本能够奠定一个引擎的主线结构。这好比是写文章的“主线”。当然，一篇好的文章，光有一个好的主线逻辑和构思是不够的，但主线是核心，写工作流引擎，也类似。
自从2005年初写出那款引擎之后，就很长时间没有想去写一个引擎的冲动了。这似乎是开发人员的一种诟病，如果感觉现在所做的研发或者开发，不能让自己超越现在的自己，则会丧失很大兴趣，甚至放弃。我当时就是那种状态。
我没有再去做工作流研发，但是却没有放弃对工作流的研究。从2005年中开始，我自己利用业余时间在默默地研究，也利用给别人培训和讲课的机会，对相关知识进行巩固和升华。这一年多来，收获是不小的，但是却没有再公开什么文章，是比较沉寂的一年。
什么是EPC
前面废话说了一堆，现在正式转入正题。
前段时间，公司接了一个物流的项目，其中有一个子系统是要做WMS（仓储管理系统），主要是处理物品入库、出库、库存的流程管理。我看这个WMS子系统的需求之后，对其内部所需要处理的流程、单据状态等业务场景，脑海中第一个念头就是应该采用EPC用于建模抽象。可惜这只是脑海中的一个念头而以，现实中，是不可能这么去实施这个项目的。（这是令人痛心的，不过国内很多项目的实施，是很应付性的，也很难听取开发人员的意见）。
回到家后，又把之前所搜刮到的有关EPC的资料翻了翻。其中有两篇文档在这里提一提：
第一篇就是《 SAP R/3 Business Blueprint:Understanding Enterprise Supply Chain Management》【 02】，这本书有一章节专门讲了EPC建模的要素，并且在后续章节中，用了大量的图例诠释了如何用EPC流程构建业务流程。
书中主要点了EPC的四个主要要素： 事件（Event）、功能（Function）、组织单元（Orgnization Unit）、信息（Data）（事实上，OU和Data这两个要素是ARIS系统框架中的）。由于本书的宗旨主要在于业务诠释，所以对于这几个要素讲解的不够概念化、形式化。但读完后，用EPC的图例绘制业务流程图，估计没有多大难度了。
| 元素 | 图例 | 描述 |
| Event | | 描述了状态的发生，同时又充当了一个触发器 |
| Function | | 功能描述了一个任务的执行，代表了一个start event和end event转换过程 |
| Orgnization Unit | | |
| Data | | |
| Process Path | | 流程之间的连接关系 |
| Logical Connectors | | 逻辑连符号：AND,OR,XOR |
让我们来看一个例子，可以加深对EPC所构建的流程模型的理解：下图显示的是一个货物接收处理的流程。
第二篇就是Alast大师写的《 Formalization and Verification of Event-driven Process Chains》【 04】。Alast是位Petri Net领域的专家，这篇文档也依然没有脱离PN角度。
这篇文档从“过程”角度给出了EPC的几个元素解释：
| 元素 | 描述 |
| Functions | A function corresponds to an activity (task, process step) which needs to be executed. |
| Events | Events describe the situation before and/or after a function is executed. Functions are linked by events. An event may correspond to the postcondition of one function and act as a precondition of another function. |
| Logical connectors | Connectors can be used to connect activities and events. This way the flow of control is specified. There are three types of connectors: AND, XOR (exclusive or) and OR |
Alast这篇文章另外一个重要内容，就是做了EPC到PetriNet的映射，但不涉及到对OR逻辑连接符的映射，因为OR的语义有多种诠释，不是非常清晰明确，这在Alast的这篇文档中也已经说明。
EPC的Event可以映射为PN中的库所（Place），而Function可以映射为PN中的变迁（Transition）。而至于逻辑连接符AND和XOR的映射在采用Place的控制，很容易表示：
国内EPC应用的匮乏
看到这儿，估计大家对EPC过程模型能够有个基本的认识。因为本篇不是讲解EPC的，而只是想说明： EPC在业务建模方面为我们提供了很好的参考，但是国内当前基于EPC模型的流程产品或业务产品几乎没有。在网络上搜索中文EPC的资料，仅有寥寥几篇，而且主要还都是因为讲解ARIS框架而顺带提及的。
到不是说EPC是一剂万能的良药，事实上EPC也仅是过程建模的一种。几个过程建模诸如 PetriNet、EPC、Activity Diagram、FSM等，如果可能的话， XPDL的定义元模型也算一种。
但是国内这几年的工作流相关的产品和应用发展，受WfMC的XPDL影响很深。
一方面是因为国内自身的理论研究过于薄弱和苍白，可能有些研究人员会注意到上述的那些过程建模方法，但是由于这些过程建模方法并没有形成完整的形式化描述语言支持（事实上，是有一些的，比如基于PN的PNML，基于EPC的EPML等，但是这些xml的描述语言过于理论化，不像XPDL那样偏应用），所以很难直接被一些开发厂商了解。
而另一方面，这几年国内工作流应用的主要领域依然是OA及相关审批流程。在这样一个“偏重用户自主行为控制”的流程应用领域，XPDL所阐述的流程元模型对象：Process、Activity、Transition、Participant已经基本可以描述一个完整的流程。在可以完整描述完一个流程之后，大部分厂商都把重点放在了：（1）通过扩展属性来丰富流程定义；（2）通过完善引擎的功能支持一些用户行为化的操作，诸如退回、自由流等。
但很少有厂商真正的反思一下，XPDL的过程建模就一定完善吗？合适吗？。 对于XPDL来说，有个最大的缺陷就是缺少对State和Event的描述（在XPDL2.0中已经部分的纳入Event概念了）。
而对于其他过程建模PetriNet、EPC、Activity Diagram、FSM这几个来说，State是一个核心的元素：
| 过程建模方法 | 基本模型元素 | 表示State的对象 |
| PetriNet | Place,Transition | Place |
| EPC | Event,Function,Connectors | Event |
| Activity Diagram | State,Decision | State |
| FSM | State,Action | State |
| XPDL Metedata | Activity,Transition |
在这几个过程建模方法中，EPC是最偏重于商业业务化流程的。但是却是国内应用却是空白的。
据我所知道的，目前国内已经有两三家厂商已经采用PetriNet作为流程描述模型；OSWorkflow和jBpm这两款开源引擎的应用，也已经让部分厂商在不知不觉中采用了FSM和Activity Diagram模型。唯独EPC没有应用（当然那些采用SAP R3的除外）。
我记得在2001年，我还在有生博大公司研发RiseOffice5.0公文流程系统，那时候采用的是Task和Action对象，有些类似FSM的State和Action。不过现在有生博大新版的RiseOffice工作流系统，已经采用XPDL模型了。—— 其实这也是国内很多厂商的一个开发趋势：虽然不了解“过程建模”，但是知道XPDL可以描述流程。
事实上， EPC所抽象的模型，很适合诸如B2B、供应链流程管理、仓储物流管理等商业化业务流程。这样的业务流程有个很共同的特点，对于“活动处理的前后状态”很在意。一旦把握了状态，则可以依据状态来丰富业务对象的生命周期控制和业务规则控制，这两点在业务系统中是比较重视的。
相比较而言，XPDL的元模型则仅仅只描述了“活动与活动之间的连接关系”，则很难在模型角度就看清楚活动之间所影响的状态及变更关系。
但很少有开发商或者开发人员去反思这个问题：活动与状态。XPDL虽然屏蔽了“状态”这个理念，但是由于其是目前最为“完善的XML描述化流程语言”（当然，这里我们不去谈论BPEL、BPML之类的规范），对于开发商来说，只需要考虑遵循规范和扩展，则可以基本清晰的描述一个“流程”，虽然不能够表达流程各个区段的状态问题，但是却可以清楚地展现“活动之间的关系”。
更况，国内的流程发展，这几年主要依赖于办公自动化和审批流，加上 国内应用偏重于“离散活动点的组合关系”，也就是说，在很多客户眼力：流程就是一个个离散的任务，这些任务在不同情况下可以很随意的组合。而这样的需求，是XPDL所依赖于的Activity和Transition所基本可以描述的。
加之WfMC毕竟是一个有着十多年的国际化标准组织，对客户，对开发商来说，这样的组织和标准，都是比较容易接受的。
而EPC,PetriNet,FSM,Activity Diagram则显得很脆弱，没有国际化的组织支撑，没有完善的描述语言支撑。最令人叹息的就是，在XPDL的描述模型中，几乎找不到任何这四个模型的影子，似乎WfMC在有意回避这几个建模思想。
国内的业务化建模流程，应该吸纳EPC这样建模方法，特别是在业务化系统中，比如B2B、供应链流程管理、仓储物流管理等商业化流程系统中。当然这样的代价是比较高的，需要基于这些模型元素和思想，自主摸索出一套完整描述语言。事实上，SAP R3的成功是很值得大家借鉴的。
下面把仓储管理系统中的一个入库流程中的“入库订单处理”用EPC模型表示，如下：
参考文档
【 01】 G. Keller, M. Nüttgens, A.-W. Scheer. Semantische Prozessmodellierung auf
der Grundlage „Ereignisgesteuerte Prozessketten (EPK)“. Veröffentlichung
des Institut für Wirtschaftsinformatik, Paper 089, Saarbrücken, 1992
(http://www.iwi.uni-sb.de/iwi-hefte/heft089.ps).
【 02】 Thomas A. Curran, Andrew Ladd. SAP R/3 Business Blueprint:Understanding Enterprise Supply Chain Management,2003
【 03】胡长城，《工作流引擎核心调度算法与PetriNet》，2005年
【 04】W.M.P. van der Aalst, Formalization and Verification of Event-driven Process Chains
作者 ：胡长城 [ 银狐999 ]
http://www.javafox.org
http://blog.csdn.net/james999
完成日期：2006-10-8 version 1.0
联系信箱：james-fly@vip.sina.com
MSN ：fcxiao2000@hotmail.com
引言
EPC是一种过程建模方法，全称是 Event-driven Process Chain。在九十年代初期才由Keller等人提出。对于EPC，国内开发人员是陌生的，可能很多人听说EPC【 01】，也仅仅是在ARIS（ Architecture of Integrated Information System）系统框架中接触过一些。EPC可能很多人是陌生的，但SAP R3可能很多人或多或少听过，SAP R3就是基于EPC过程建模的。
我也仅仅只是在2004年中的时候才接触过EPC这个概念的，那时候还在 思维加速公司（现在叫起步公司了）研发Biz5.0系统，为了在Process Model这一层寻找一套方法论的支持，查阅了大量的建模方法资料，其中就包括EPC。
但那时候接触的业务场景和业务范围很局限，虽然对EPC很认同，却不敢轻易的深入和采用，加上当时受Alast的 YAWL的影响，所以更加痴迷于PetriNet。——很遗憾的是，那个时候没有看出EPC与PN之间是有很大关联性的，这是后话。
2004年底进入USE（ 用友软件工程），接手了工作流引擎的开发。虽然那时候很想按照自己的思路采用PN或EPC的模型来开发，但当时在我之前的开发人员已经花费了大量时间在XPDL模型语言上，并做出了一款可运行的Deme和设计器，对我来说，当时的首要任务是重构出一款实际可用的引擎，而不是重新开发一个工作流系统。
不得已，我只能采用XPDL流程模型，也只能选择重构，这在我去年写的《 工作流引擎核心调度算法与PetriNet》【 03】已经稍稍提及了。虽然模型这个层面让我很被动，但是由于至少还可以把握引擎结构和调度算法这一层，或多或少弥补了很多。
其实，那个时候即使允许采用PN或EPC，心里其实也是没有多少底的。毕竟早先我很多的研究基础也是基于WfMC的参考模型和XPDL描述语言的。两年之后再回过头来看看，心中已经很清晰了，至少那几个过程模型的思想已经很有把握了。
说道这儿，顺带说两个方面的个人观点，这两个方面与主题没有直接关系，但是有间接关系。以后我会写专门的文档来阐述我的这两个观点，此处我就不多加解释了，“仁者见仁，智者见智”，有心者自己把握吧。
第一：我不是很喜欢XPDL流程描述模型，但目前国内绝大多数的厂商采用的是XPDL描述模型及扩展，这没有任何不妥。目前国内的流程应用范围主要还集中在类似OA审批流之类的应用上，这一层面的应用XPDL的模型所描述的语义基本可以满足大家的理解和应用了。再加之绝大多数的客户更偏重于“离散型活动关系”，这就让建模的约束又浅了一层。
第二：在引擎构建上，需要把握关键的三点：过程模型建模、引擎调度算法和状态变迁、实例之间的对象关系。把握了这三点，则基本能够奠定一个引擎的主线结构。这好比是写文章的“主线”。当然，一篇好的文章，光有一个好的主线逻辑和构思是不够的，但主线是核心，写工作流引擎，也类似。
自从2005年初写出那款引擎之后，就很长时间没有想去写一个引擎的冲动了。这似乎是开发人员的一种诟病，如果感觉现在所做的研发或者开发，不能让自己超越现在的自己，则会丧失很大兴趣，甚至放弃。我当时就是那种状态。
我没有再去做工作流研发，但是却没有放弃对工作流的研究。从2005年中开始，我自己利用业余时间在默默地研究，也利用给别人培训和讲课的机会，对相关知识进行巩固和升华。这一年多来，收获是不小的，但是却没有再公开什么文章，是比较沉寂的一年。
什么是EPC
前面废话说了一堆，现在正式转入正题。
前段时间，公司接了一个物流的项目，其中有一个子系统是要做WMS（仓储管理系统），主要是处理物品入库、出库、库存的流程管理。我看这个WMS子系统的需求之后，对其内部所需要处理的流程、单据状态等业务场景，脑海中第一个念头就是应该采用EPC用于建模抽象。可惜这只是脑海中的一个念头而以，现实中，是不可能这么去实施这个项目的。（这是令人痛心的，不过国内很多项目的实施，是很应付性的，也很难听取开发人员的意见）。
回到家后，又把之前所搜刮到的有关EPC的资料翻了翻。其中有两篇文档在这里提一提：
第一篇就是《 SAP R/3 Business Blueprint:Understanding Enterprise Supply Chain Management》【 02】，这本书有一章节专门讲了EPC建模的要素，并且在后续章节中，用了大量的图例诠释了如何用EPC流程构建业务流程。
书中主要点了EPC的四个主要要素： 事件（Event）、功能（Function）、组织单元（Orgnization Unit）、信息（Data）（事实上，OU和Data这两个要素是ARIS系统框架中的）。由于本书的宗旨主要在于业务诠释，所以对于这几个要素讲解的不够概念化、形式化。但读完后，用EPC的图例绘制业务流程图，估计没有多大难度了。
| 元素 | 图例 | 描述 |
| Event | | 描述了状态的发生，同时又充当了一个触发器 |
| Function | | 功能描述了一个任务的执行，代表了一个start event和end event转换过程 |
| Orgnization Unit | | |
| Data | | |
| Process Path | | 流程之间的连接关系 |
| Logical Connectors | | 逻辑连符号：AND,OR,XOR |
让我们来看一个例子，可以加深对EPC所构建的流程模型的理解：下图显示的是一个货物接收处理的流程。
第二篇就是Alast大师写的《 Formalization and Verification of Event-driven Process Chains》【 04】。Alast是位Petri Net领域的专家，这篇文档也依然没有脱离PN角度。
这篇文档从“过程”角度给出了EPC的几个元素解释：
| 元素 | 描述 |
| Functions | A function corresponds to an activity (task, process step) which needs to be executed. |
| Events | Events describe the situation before and/or after a function is executed. Functions are linked by events. An event may correspond to the postcondition of one function and act as a precondition of another function. |
| Logical connectors | Connectors can be used to connect activities and events. This way the flow of control is specified. There are three types of connectors: AND, XOR (exclusive or) and OR |
Alast这篇文章另外一个重要内容，就是做了EPC到PetriNet的映射，但不涉及到对OR逻辑连接符的映射，因为OR的语义有多种诠释，不是非常清晰明确，这在Alast的这篇文档中也已经说明。
EPC的Event可以映射为PN中的库所（Place），而Function可以映射为PN中的变迁（Transition）。而至于逻辑连接符AND和XOR的映射在采用Place的控制，很容易表示：
国内EPC应用的匮乏
看到这儿，估计大家对EPC过程模型能够有个基本的认识。因为本篇不是讲解EPC的，而只是想说明： EPC在业务建模方面为我们提供了很好的参考，但是国内当前基于EPC模型的流程产品或业务产品几乎没有。在网络上搜索中文EPC的资料，仅有寥寥几篇，而且主要还都是因为讲解ARIS框架而顺带提及的。
到不是说EPC是一剂万能的良药，事实上EPC也仅是过程建模的一种。几个过程建模诸如 PetriNet、EPC、Activity Diagram、FSM等，如果可能的话， XPDL的定义元模型也算一种。
但是国内这几年的工作流相关的产品和应用发展，受WfMC的XPDL影响很深。
一方面是因为国内自身的理论研究过于薄弱和苍白，可能有些研究人员会注意到上述的那些过程建模方法，但是由于这些过程建模方法并没有形成完整的形式化描述语言支持（事实上，是有一些的，比如基于PN的PNML，基于EPC的EPML等，但是这些xml的描述语言过于理论化，不像XPDL那样偏应用），所以很难直接被一些开发厂商了解。
而另一方面，这几年国内工作流应用的主要领域依然是OA及相关审批流程。在这样一个“偏重用户自主行为控制”的流程应用领域，XPDL所阐述的流程元模型对象：Process、Activity、Transition、Participant已经基本可以描述一个完整的流程。在可以完整描述完一个流程之后，大部分厂商都把重点放在了：（1）通过扩展属性来丰富流程定义；（2）通过完善引擎的功能支持一些用户行为化的操作，诸如退回、自由流等。
但很少有厂商真正的反思一下，XPDL的过程建模就一定完善吗？合适吗？。 对于XPDL来说，有个最大的缺陷就是缺少对State和Event的描述（在XPDL2.0中已经部分的纳入Event概念了）。
而对于其他过程建模PetriNet、EPC、Activity Diagram、FSM这几个来说，State是一个核心的元素：
| 过程建模方法 | 基本模型元素 | 表示State的对象 |
| PetriNet | Place,Transition | Place |
| EPC | Event,Function,Connectors | Event |
| Activity Diagram | State,Decision | State |
| FSM | State,Action | State |
| XPDL Metedata | Activity,Transition |
在这几个过程建模方法中，EPC是最偏重于商业业务化流程的。但是却是国内应用却是空白的。
据我所知道的，目前国内已经有两三家厂商已经采用PetriNet作为流程描述模型；OSWorkflow和jBpm这两款开源引擎的应用，也已经让部分厂商在不知不觉中采用了FSM和Activity Diagram模型。唯独EPC没有应用（当然那些采用SAP R3的除外）。
我记得在2001年，我还在有生博大公司研发RiseOffice5.0公文流程系统，那时候采用的是Task和Action对象，有些类似FSM的State和Action。不过现在有生博大新版的RiseOffice工作流系统，已经采用XPDL模型了。—— 其实这也是国内很多厂商的一个开发趋势：虽然不了解“过程建模”，但是知道XPDL可以描述流程。
事实上， EPC所抽象的模型，很适合诸如B2B、供应链流程管理、仓储物流管理等商业化业务流程。这样的业务流程有个很共同的特点，对于“活动处理的前后状态”很在意。一旦把握了状态，则可以依据状态来丰富业务对象的生命周期控制和业务规则控制，这两点在业务系统中是比较重视的。
相比较而言，XPDL的元模型则仅仅只描述了“活动与活动之间的连接关系”，则很难在模型角度就看清楚活动之间所影响的状态及变更关系。
但很少有开发商或者开发人员去反思这个问题：活动与状态。XPDL虽然屏蔽了“状态”这个理念，但是由于其是目前最为“完善的XML描述化流程语言”（当然，这里我们不去谈论BPEL、BPML之类的规范），对于开发商来说，只需要考虑遵循规范和扩展，则可以基本清晰的描述一个“流程”，虽然不能够表达流程各个区段的状态问题，但是却可以清楚地展现“活动之间的关系”。
更况，国内的流程发展，这几年主要依赖于办公自动化和审批流，加上 国内应用偏重于“离散活动点的组合关系”，也就是说，在很多客户眼力：流程就是一个个离散的任务，这些任务在不同情况下可以很随意的组合。而这样的需求，是XPDL所依赖于的Activity和Transition所基本可以描述的。
加之WfMC毕竟是一个有着十多年的国际化标准组织，对客户，对开发商来说，这样的组织和标准，都是比较容易接受的。
而EPC,PetriNet,FSM,Activity Diagram则显得很脆弱，没有国际化的组织支撑，没有完善的描述语言支撑。最令人叹息的就是，在XPDL的描述模型中，几乎找不到任何这四个模型的影子，似乎WfMC在有意回避这几个建模思想。
国内的业务化建模流程，应该吸纳EPC这样建模方法，特别是在业务化系统中，比如B2B、供应链流程管理、仓储物流管理等商业化流程系统中。当然这样的代价是比较高的，需要基于这些模型元素和思想，自主摸索出一套完整描述语言。事实上，SAP R3的成功是很值得大家借鉴的。
下面把仓储管理系统中的一个入库流程中的“入库订单处理”用EPC模型表示，如下：
参考文档
【 01】 G. Keller, M. Nüttgens, A.-W. Scheer. Semantische Prozessmodellierung auf
der Grundlage „Ereignisgesteuerte Prozessketten (EPK)“. Veröffentlichung
des Institut für Wirtschaftsinformatik, Paper 089, Saarbrücken, 1992
(http://www.iwi.uni-sb.de/iwi-hefte/heft089.ps).
【 02】 Thomas A. Curran, Andrew Ladd. SAP R/3 Business Blueprint:Understanding Enterprise Supply Chain Management,2003
【 03】胡长城，《工作流引擎核心调度算法与PetriNet》，2005年
【 04】W.M.P. van der Aalst, Formalization and Verification of Event-driven Process Chains
作者 ：胡长城 [ 银狐999 ]
http://www.javafox.org
http://blog.csdn.net/james999
完成日期：2006-10-8 version 1.0
联系信箱：james-fly@vip.sina.com
MSN ：fcxiao2000@hotmail.com
引言
EPC是一种过程建模方法，全称是 Event-driven Process Chain。在九十年代初期才由Keller等人提出。对于EPC，国内开发人员是陌生的，可能很多人听说EPC【 01】，也仅仅是在ARIS（ Architecture of Integrated Information System）系统框架中接触过一些。EPC可能很多人是陌生的，但SAP R3可能很多人或多或少听过，SAP R3就是基于EPC过程建模的。
我也仅仅只是在2004年中的时候才接触过EPC这个概念的，那时候还在 思维加速公司（现在叫起步公司了）研发Biz5.0系统，为了在Process Model这一层寻找一套方法论的支持，查阅了大量的建模方法资料，其中就包括EPC。
但那时候接触的业务场景和业务范围很局限，虽然对EPC很认同，却不敢轻易的深入和采用，加上当时受Alast的 YAWL的影响，所以更加痴迷于PetriNet。——很遗憾的是，那个时候没有看出EPC与PN之间是有很大关联性的，这是后话。
2004年底进入USE（ 用友软件工程），接手了工作流引擎的开发。虽然那时候很想按照自己的思路采用PN或EPC的模型来开发，但当时在我之前的开发人员已经花费了大量时间在XPDL模型语言上，并做出了一款可运行的Deme和设计器，对我来说，当时的首要任务是重构出一款实际可用的引擎，而不是重新开发一个工作流系统。
不得已，我只能采用XPDL流程模型，也只能选择重构，这在我去年写的《 工作流引擎核心调度算法与PetriNet》【 03】已经稍稍提及了。虽然模型这个层面让我很被动，但是由于至少还可以把握引擎结构和调度算法这一层，或多或少弥补了很多。
其实，那个时候即使允许采用PN或EPC，心里其实也是没有多少底的。毕竟早先我很多的研究基础也是基于WfMC的参考模型和XPDL描述语言的。两年之后再回过头来看看，心中已经很清晰了，至少那几个过程模型的思想已经很有把握了。
说道这儿，顺带说两个方面的个人观点，这两个方面与主题没有直接关系，但是有间接关系。以后我会写专门的文档来阐述我的这两个观点，此处我就不多加解释了，“仁者见仁，智者见智”，有心者自己把握吧。
第一：我不是很喜欢XPDL流程描述模型，但目前国内绝大多数的厂商采用的是XPDL描述模型及扩展，这没有任何不妥。目前国内的流程应用范围主要还集中在类似OA审批流之类的应用上，这一层面的应用XPDL的模型所描述的语义基本可以满足大家的理解和应用了。再加之绝大多数的客户更偏重于“离散型活动关系”，这就让建模的约束又浅了一层。
第二：在引擎构建上，需要把握关键的三点：过程模型建模、引擎调度算法和状态变迁、实例之间的对象关系。把握了这三点，则基本能够奠定一个引擎的主线结构。这好比是写文章的“主线”。当然，一篇好的文章，光有一个好的主线逻辑和构思是不够的，但主线是核心，写工作流引擎，也类似。
自从2005年初写出那款引擎之后，就很长时间没有想去写一个引擎的冲动了。这似乎是开发人员的一种诟病，如果感觉现在所做的研发或者开发，不能让自己超越现在的自己，则会丧失很大兴趣，甚至放弃。我当时就是那种状态。
我没有再去做工作流研发，但是却没有放弃对工作流的研究。从2005年中开始，我自己利用业余时间在默默地研究，也利用给别人培训和讲课的机会，对相关知识进行巩固和升华。这一年多来，收获是不小的，但是却没有再公开什么文章，是比较沉寂的一年。
什么是EPC
前面废话说了一堆，现在正式转入正题。
前段时间，公司接了一个物流的项目，其中有一个子系统是要做WMS（仓储管理系统），主要是处理物品入库、出库、库存的流程管理。我看这个WMS子系统的需求之后，对其内部所需要处理的流程、单据状态等业务场景，脑海中第一个念头就是应该采用EPC用于建模抽象。可惜这只是脑海中的一个念头而以，现实中，是不可能这么去实施这个项目的。（这是令人痛心的，不过国内很多项目的实施，是很应付性的，也很难听取开发人员的意见）。
回到家后，又把之前所搜刮到的有关EPC的资料翻了翻。其中有两篇文档在这里提一提：
第一篇就是《 SAP R/3 Business Blueprint:Understanding Enterprise Supply Chain Management》【 02】，这本书有一章节专门讲了EPC建模的要素，并且在后续章节中，用了大量的图例诠释了如何用EPC流程构建业务流程。
书中主要点了EPC的四个主要要素： 事件（Event）、功能（Function）、组织单元（Orgnization Unit）、信息（Data）（事实上，OU和Data这两个要素是ARIS系统框架中的）。由于本书的宗旨主要在于业务诠释，所以对于这几个要素讲解的不够概念化、形式化。但读完后，用EPC的图例绘制业务流程图，估计没有多大难度了。
| 元素 | 图例 | 描述 |
| Event | | 描述了状态的发生，同时又充当了一个触发器 |
| Function | | 功能描述了一个任务的执行，代表了一个start event和end event转换过程 |
| Orgnization Unit | | |
| Data | | |
| Process Path | | 流程之间的连接关系 |
| Logical Connectors | | 逻辑连符号：AND,OR,XOR |
让我们来看一个例子，可以加深对EPC所构建的流程模型的理解：下图显示的是一个货物接收处理的流程。
第二篇就是Alast大师写的《 Formalization and Verification of Event-driven Process Chains》【 04】。Alast是位Petri Net领域的专家，这篇文档也依然没有脱离PN角度。
这篇文档从“过程”角度给出了EPC的几个元素解释：
| 元素 | 描述 |
| Functions | A function corresponds to an activity (task, process step) which needs to be executed. |
| Events | Events describe the situation before and/or after a function is executed. Functions are linked by events. An event may correspond to the postcondition of one function and act as a precondition of another function. |
| Logical connectors | Connectors can be used to connect activities and events. This way the flow of control is specified. There are three types of connectors: AND, XOR (exclusive or) and OR |
Alast这篇文章另外一个重要内容，就是做了EPC到PetriNet的映射，但不涉及到对OR逻辑连接符的映射，因为OR的语义有多种诠释，不是非常清晰明确，这在Alast的这篇文档中也已经说明。
EPC的Event可以映射为PN中的库所（Place），而Function可以映射为PN中的变迁（Transition）。而至于逻辑连接符AND和XOR的映射在采用Place的控制，很容易表示：
国内EPC应用的匮乏
看到这儿，估计大家对EPC过程模型能够有个基本的认识。因为本篇不是讲解EPC的，而只是想说明： EPC在业务建模方面为我们提供了很好的参考，但是国内当前基于EPC模型的流程产品或业务产品几乎没有。在网络上搜索中文EPC的资料，仅有寥寥几篇，而且主要还都是因为讲解ARIS框架而顺带提及的。
到不是说EPC是一剂万能的良药，事实上EPC也仅是过程建模的一种。几个过程建模诸如 PetriNet、EPC、Activity Diagram、FSM等，如果可能的话， XPDL的定义元模型也算一种。
但是国内这几年的工作流相关的产品和应用发展，受WfMC的XPDL影响很深。
一方面是因为国内自身的理论研究过于薄弱和苍白，可能有些研究人员会注意到上述的那些过程建模方法，但是由于这些过程建模方法并没有形成完整的形式化描述语言支持（事实上，是有一些的，比如基于PN的PNML，基于EPC的EPML等，但是这些xml的描述语言过于理论化，不像XPDL那样偏应用），所以很难直接被一些开发厂商了解。
而另一方面，这几年国内工作流应用的主要领域依然是OA及相关审批流程。在这样一个“偏重用户自主行为控制”的流程应用领域，XPDL所阐述的流程元模型对象：Process、Activity、Transition、Participant已经基本可以描述一个完整的流程。在可以完整描述完一个流程之后，大部分厂商都把重点放在了：（1）通过扩展属性来丰富流程定义；（2）通过完善引擎的功能支持一些用户行为化的操作，诸如退回、自由流等。
但很少有厂商真正的反思一下，XPDL的过程建模就一定完善吗？合适吗？。 对于XPDL来说，有个最大的缺陷就是缺少对State和Event的描述（在XPDL2.0中已经部分的纳入Event概念了）。
而对于其他过程建模PetriNet、EPC、Activity Diagram、FSM这几个来说，State是一个核心的元素：
| 过程建模方法 | 基本模型元素 | 表示State的对象 |
| PetriNet | Place,Transition | Place |
| EPC | Event,Function,Connectors | Event |
| Activity Diagram | State,Decision | State |
| FSM | State,Action | State |
| XPDL Metedata | Activity,Transition |
在这几个过程建模方法中，EPC是最偏重于商业业务化流程的。但是却是国内应用却是空白的。
据我所知道的，目前国内已经有两三家厂商已经采用PetriNet作为流程描述模型；OSWorkflow和jBpm这两款开源引擎的应用，也已经让部分厂商在不知不觉中采用了FSM和Activity Diagram模型。唯独EPC没有应用（当然那些采用SAP R3的除外）。
我记得在2001年，我还在有生博大公司研发RiseOffice5.0公文流程系统，那时候采用的是Task和Action对象，有些类似FSM的State和Action。不过现在有生博大新版的RiseOffice工作流系统，已经采用XPDL模型了。—— 其实这也是国内很多厂商的一个开发趋势：虽然不了解“过程建模”，但是知道XPDL可以描述流程。
事实上， EPC所抽象的模型，很适合诸如B2B、供应链流程管理、仓储物流管理等商业化业务流程。这样的业务流程有个很共同的特点，对于“活动处理的前后状态”很在意。一旦把握了状态，则可以依据状态来丰富业务对象的生命周期控制和业务规则控制，这两点在业务系统中是比较重视的。
相比较而言，XPDL的元模型则仅仅只描述了“活动与活动之间的连接关系”，则很难在模型角度就看清楚活动之间所影响的状态及变更关系。
但很少有开发商或者开发人员去反思这个问题：活动与状态。XPDL虽然屏蔽了“状态”这个理念，但是由于其是目前最为“完善的XML描述化流程语言”（当然，这里我们不去谈论BPEL、BPML之类的规范），对于开发商来说，只需要考虑遵循规范和扩展，则可以基本清晰的描述一个“流程”，虽然不能够表达流程各个区段的状态问题，但是却可以清楚地展现“活动之间的关系”。
更况，国内的流程发展，这几年主要依赖于办公自动化和审批流，加上 国内应用偏重于“离散活动点的组合关系”，也就是说，在很多客户眼力：流程就是一个个离散的任务，这些任务在不同情况下可以很随意的组合。而这样的需求，是XPDL所依赖于的Activity和Transition所基本可以描述的。
加之WfMC毕竟是一个有着十多年的国际化标准组织，对客户，对开发商来说，这样的组织和标准，都是比较容易接受的。
而EPC,PetriNet,FSM,Activity Diagram则显得很脆弱，没有国际化的组织支撑，没有完善的描述语言支撑。最令人叹息的就是，在XPDL的描述模型中，几乎找不到任何这四个模型的影子，似乎WfMC在有意回避这几个建模思想。
国内的业务化建模流程，应该吸纳EPC这样建模方法，特别是在业务化系统中，比如B2B、供应链流程管理、仓储物流管理等商业化流程系统中。当然这样的代价是比较高的，需要基于这些模型元素和思想，自主摸索出一套完整描述语言。事实上，SAP R3的成功是很值得大家借鉴的。
下面把仓储管理系统中的一个入库流程中的“入库订单处理”用EPC模型表示，如下：
参考文档
【 01】 G. Keller, M. Nüttgens, A.-W. Scheer. Semantische Prozessmodellierung auf
der Grundlage „Ereignisgesteuerte Prozessketten (EPK)“. Veröffentlichung
des Institut für Wirtschaftsinformatik, Paper 089, Saarbrücken, 1992
(http://www.iwi.uni-sb.de/iwi-hefte/heft089.ps).
【 02】 Thomas A. Curran, Andrew Ladd. SAP R/3 Business Blueprint:Understanding Enterprise Supply Chain Management,2003
【 03】胡长城，《工作流引擎核心调度算法与PetriNet》，2005年
【 04】W.M.P. van der Aalst, Formalization and Verification of Event-driven Process Chains
作者 ：胡长城 [ 银狐999 ]
http://www.javafox.org
http://blog.csdn.net/james999
完成日期：2006-10-8 version 1.0
联系信箱：james-fly@vip.sina.com
MSN ：fcxiao2000@hotmail.com
引言
EPC是一种过程建模方法，全称是 Event-driven Process Chain。在九十年代初期才由Keller等人提出。对于EPC，国内开发人员是陌生的，可能很多人听说EPC【 01】，也仅仅是在ARIS（ Architecture of Integrated Information System）系统框架中接触过一些。EPC可能很多人是陌生的，但SAP R3可能很多人或多或少听过，SAP R3就是基于EPC过程建模的。
我也仅仅只是在2004年中的时候才接触过EPC这个概念的，那时候还在 思维加速公司（现在叫起步公司了）研发Biz5.0系统，为了在Process Model这一层寻找一套方法论的支持，查阅了大量的建模方法资料，其中就包括EPC。
但那时候接触的业务场景和业务范围很局限，虽然对EPC很认同，却不敢轻易的深入和采用，加上当时受Alast的 YAWL的影响，所以更加痴迷于PetriNet。——很遗憾的是，那个时候没有看出EPC与PN之间是有很大关联性的，这是后话。
2004年底进入USE（ 用友软件工程），接手了工作流引擎的开发。虽然那时候很想按照自己的思路采用PN或EPC的模型来开发，但当时在我之前的开发人员已经花费了大量时间在XPDL模型语言上，并做出了一款可运行的Deme和设计器，对我来说，当时的首要任务是重构出一款实际可用的引擎，而不是重新开发一个工作流系统。
不得已，我只能采用XPDL流程模型，也只能选择重构，这在我去年写的《 工作流引擎核心调度算法与PetriNet》【 03】已经稍稍提及了。虽然模型这个层面让我很被动，但是由于至少还可以把握引擎结构和调度算法这一层，或多或少弥补了很多。
其实，那个时候即使允许采用PN或EPC，心里其实也是没有多少底的。毕竟早先我很多的研究基础也是基于WfMC的参考模型和XPDL描述语言的。两年之后再回过头来看看，心中已经很清晰了，至少那几个过程模型的思想已经很有把握了。
说道这儿，顺带说两个方面的个人观点，这两个方面与主题没有直接关系，但是有间接关系。以后我会写专门的文档来阐述我的这两个观点，此处我就不多加解释了，“仁者见仁，智者见智”，有心者自己把握吧。
第一：我不是很喜欢XPDL流程描述模型，但目前国内绝大多数的厂商采用的是XPDL描述模型及扩展，这没有任何不妥。目前国内的流程应用范围主要还集中在类似OA审批流之类的应用上，这一层面的应用XPDL的模型所描述的语义基本可以满足大家的理解和应用了。再加之绝大多数的客户更偏重于“离散型活动关系”，这就让建模的约束又浅了一层。
第二：在引擎构建上，需要把握关键的三点：过程模型建模、引擎调度算法和状态变迁、实例之间的对象关系。把握了这三点，则基本能够奠定一个引擎的主线结构。这好比是写文章的“主线”。当然，一篇好的文章，光有一个好的主线逻辑和构思是不够的，但主线是核心，写工作流引擎，也类似。
自从2005年初写出那款引擎之后，就很长时间没有想去写一个引擎的冲动了。这似乎是开发人员的一种诟病，如果感觉现在所做的研发或者开发，不能让自己超越现在的自己，则会丧失很大兴趣，甚至放弃。我当时就是那种状态。
我没有再去做工作流研发，但是却没有放弃对工作流的研究。从2005年中开始，我自己利用业余时间在默默地研究，也利用给别人培训和讲课的机会，对相关知识进行巩固和升华。这一年多来，收获是不小的，但是却没有再公开什么文章，是比较沉寂的一年。
什么是EPC
前面废话说了一堆，现在正式转入正题。
前段时间，公司接了一个物流的项目，其中有一个子系统是要做WMS（仓储管理系统），主要是处理物品入库、出库、库存的流程管理。我看这个WMS子系统的需求之后，对其内部所需要处理的流程、单据状态等业务场景，脑海中第一个念头就是应该采用EPC用于建模抽象。可惜这只是脑海中的一个念头而以，现实中，是不可能这么去实施这个项目的。（这是令人痛心的，不过国内很多项目的实施，是很应付性的，也很难听取开发人员的意见）。
回到家后，又把之前所搜刮到的有关EPC的资料翻了翻。其中有两篇文档在这里提一提：
第一篇就是《 SAP R/3 Business Blueprint:Understanding Enterprise Supply Chain Management》【 02】，这本书有一章节专门讲了EPC建模的要素，并且在后续章节中，用了大量的图例诠释了如何用EPC流程构建业务流程。
书中主要点了EPC的四个主要要素： 事件（Event）、功能（Function）、组织单元（Orgnization Unit）、信息（Data）（事实上，OU和Data这两个要素是ARIS系统框架中的）。由于本书的宗旨主要在于业务诠释，所以对于这几个要素讲解的不够概念化、形式化。但读完后，用EPC的图例绘制业务流程图，估计没有多大难度了。
| 元素 | 图例 | 描述 |
| Event | | 描述了状态的发生，同时又充当了一个触发器 |
| Function | | 功能描述了一个任务的执行，代表了一个start event和end event转换过程 |
| Orgnization Unit | | |
| Data | | |
| Process Path | | 流程之间的连接关系 |
| Logical Connectors | | 逻辑连符号：AND,OR,XOR |
让我们来看一个例子，可以加深对EPC所构建的流程模型的理解：下图显示的是一个货物接收处理的流程。
第二篇就是Alast大师写的《 Formalization and Verification of Event-driven Process Chains》【 04】。Alast是位Petri Net领域的专家，这篇文档也依然没有脱离PN角度。
这篇文档从“过程”角度给出了EPC的几个元素解释：
| 元素 | 描述 |
| Functions | A function corresponds to an activity (task, process step) which needs to be executed. |
| Events | Events describe the situation before and/or after a function is executed. Functions are linked by events. An event may correspond to the postcondition of one function and act as a precondition of another function. |
| Logical connectors | Connectors can be used to connect activities and events. This way the flow of control is specified. There are three types of connectors: AND, XOR (exclusive or) and OR |
Alast这篇文章另外一个重要内容，就是做了EPC到PetriNet的映射，但不涉及到对OR逻辑连接符的映射，因为OR的语义有多种诠释，不是非常清晰明确，这在Alast的这篇文档中也已经说明。
EPC的Event可以映射为PN中的库所（Place），而Function可以映射为PN中的变迁（Transition）。而至于逻辑连接符AND和XOR的映射在采用Place的控制，很容易表示：
国内EPC应用的匮乏
看到这儿，估计大家对EPC过程模型能够有个基本的认识。因为本篇不是讲解EPC的，而只是想说明： EPC在业务建模方面为我们提供了很好的参考，但是国内当前基于EPC模型的流程产品或业务产品几乎没有。在网络上搜索中文EPC的资料，仅有寥寥几篇，而且主要还都是因为讲解ARIS框架而顺带提及的。
到不是说EPC是一剂万能的良药，事实上EPC也仅是过程建模的一种。几个过程建模诸如 PetriNet、EPC、Activity Diagram、FSM等，如果可能的话， XPDL的定义元模型也算一种。
但是国内这几年的工作流相关的产品和应用发展，受WfMC的XPDL影响很深。
一方面是因为国内自身的理论研究过于薄弱和苍白，可能有些研究人员会注意到上述的那些过程建模方法，但是由于这些过程建模方法并没有形成完整的形式化描述语言支持（事实上，是有一些的，比如基于PN的PNML，基于EPC的EPML等，但是这些xml的描述语言过于理论化，不像XPDL那样偏应用），所以很难直接被一些开发厂商了解。
而另一方面，这几年国内工作流应用的主要领域依然是OA及相关审批流程。在这样一个“偏重用户自主行为控制”的流程应用领域，XPDL所阐述的流程元模型对象：Process、Activity、Transition、Participant已经基本可以描述一个完整的流程。在可以完整描述完一个流程之后，大部分厂商都把重点放在了：（1）通过扩展属性来丰富流程定义；（2）通过完善引擎的功能支持一些用户行为化的操作，诸如退回、自由流等。
但很少有厂商真正的反思一下，XPDL的过程建模就一定完善吗？合适吗？。 对于XPDL来说，有个最大的缺陷就是缺少对State和Event的描述（在XPDL2.0中已经部分的纳入Event概念了）。
而对于其他过程建模PetriNet、EPC、Activity Diagram、FSM这几个来说，State是一个核心的元素：
| 过程建模方法 | 基本模型元素 | 表示State的对象 |
| PetriNet | Place,Transition | Place |
| EPC | Event,Function,Connectors | Event |
| Activity Diagram | State,Decision | State |
| FSM | State,Action | State |
| XPDL Metedata | Activity,Transition |
在这几个过程建模方法中，EPC是最偏重于商业业务化流程的。但是却是国内应用却是空白的。
据我所知道的，目前国内已经有两三家厂商已经采用PetriNet作为流程描述模型；OSWorkflow和jBpm这两款开源引擎的应用，也已经让部分厂商在不知不觉中采用了FSM和Activity Diagram模型。唯独EPC没有应用（当然那些采用SAP R3的除外）。
我记得在2001年，我还在有生博大公司研发RiseOffice5.0公文流程系统，那时候采用的是Task和Action对象，有些类似FSM的State和Action。不过现在有生博大新版的RiseOffice工作流系统，已经采用XPDL模型了。—— 其实这也是国内很多厂商的一个开发趋势：虽然不了解“过程建模”，但是知道XPDL可以描述流程。
事实上， EPC所抽象的模型，很适合诸如B2B、供应链流程管理、仓储物流管理等商业化业务流程。这样的业务流程有个很共同的特点，对于“活动处理的前后状态”很在意。一旦把握了状态，则可以依据状态来丰富业务对象的生命周期控制和业务规则控制，这两点在业务系统中是比较重视的。
相比较而言，XPDL的元模型则仅仅只描述了“活动与活动之间的连接关系”，则很难在模型角度就看清楚活动之间所影响的状态及变更关系。
但很少有开发商或者开发人员去反思这个问题：活动与状态。XPDL虽然屏蔽了“状态”这个理念，但是由于其是目前最为“完善的XML描述化流程语言”（当然，这里我们不去谈论BPEL、BPML之类的规范），对于开发商来说，只需要考虑遵循规范和扩展，则可以基本清晰的描述一个“流程”，虽然不能够表达流程各个区段的状态问题，但是却可以清楚地展现“活动之间的关系”。
更况，国内的流程发展，这几年主要依赖于办公自动化和审批流，加上 国内应用偏重于“离散活动点的组合关系”，也就是说，在很多客户眼力：流程就是一个个离散的任务，这些任务在不同情况下可以很随意的组合。而这样的需求，是XPDL所依赖于的Activity和Transition所基本可以描述的。
加之WfMC毕竟是一个有着十多年的国际化标准组织，对客户，对开发商来说，这样的组织和标准，都是比较容易接受的。
而EPC,PetriNet,FSM,Activity Diagram则显得很脆弱，没有国际化的组织支撑，没有完善的描述语言支撑。最令人叹息的就是，在XPDL的描述模型中，几乎找不到任何这四个模型的影子，似乎WfMC在有意回避这几个建模思想。
国内的业务化建模流程，应该吸纳EPC这样建模方法，特别是在业务化系统中，比如B2B、供应链流程管理、仓储物流管理等商业化流程系统中。当然这样的代价是比较高的，需要基于这些模型元素和思想，自主摸索出一套完整描述语言。事实上，SAP R3的成功是很值得大家借鉴的。
下面把仓储管理系统中的一个入库流程中的“入库订单处理”用EPC模型表示，如下：
参考文档
【 01】 G. Keller, M. Nüttgens, A.-W. Scheer. Semantische Prozessmodellierung auf
der Grundlage „Ereignisgesteuerte Prozessketten (EPK)“. Veröffentlichung
des Institut für Wirtschaftsinformatik, Paper 089, Saarbrücken, 1992
(http://www.iwi.uni-sb.de/iwi-hefte/heft089.ps).
【 02】 Thomas A. Curran, Andrew Ladd. SAP R/3 Business Blueprint:Understanding Enterprise Supply Chain Management,2003
【 03】胡长城，《工作流引擎核心调度算法与PetriNet》，2005年
【 04】W.M.P. van der Aalst, Formalization and Verification of Event-driven Process Chains
作者 ：胡长城 [ 银狐999 ]
http://www.javafox.org
http://blog.csdn.net/james999
完成日期：2006-10-8 version 1.0
联系信箱：james-fly@vip.sina.com
MSN ：fcxiao2000@hotmail.com
引言
EPC是一种过程建模方法，全称是 Event-driven Process Chain。在九十年代初期才由Keller等人提出。对于EPC，国内开发人员是陌生的，可能很多人听说EPC【 01】，也仅仅是在ARIS（ Architecture of Integrated Information System）系统框架中接触过一些。EPC可能很多人是陌生的，但SAP R3可能很多人或多或少听过，SAP R3就是基于EPC过程建模的。
我也仅仅只是在2004年中的时候才接触过EPC这个概念的，那时候还在 思维加速公司（现在叫起步公司了）研发Biz5.0系统，为了在Process Model这一层寻找一套方法论的支持，查阅了大量的建模方法资料，其中就包括EPC。
但那时候接触的业务场景和业务范围很局限，虽然对EPC很认同，却不敢轻易的深入和采用，加上当时受Alast的 YAWL的影响，所以更加痴迷于PetriNet。——很遗憾的是，那个时候没有看出EPC与PN之间是有很大关联性的，这是后话。
2004年底进入USE（ 用友软件工程），接手了工作流引擎的开发。虽然那时候很想按照自己的思路采用PN或EPC的模型来开发，但当时在我之前的开发人员已经花费了大量时间在XPDL模型语言上，并做出了一款可运行的Deme和设计器，对我来说，当时的首要任务是重构出一款实际可用的引擎，而不是重新开发一个工作流系统。
不得已，我只能采用XPDL流程模型，也只能选择重构，这在我去年写的《 工作流引擎核心调度算法与PetriNet》【 03】已经稍稍提及了。虽然模型这个层面让我很被动，但是由于至少还可以把握引擎结构和调度算法这一层，或多或少弥补了很多。
其实，那个时候即使允许采用PN或EPC，心里其实也是没有多少底的。毕竟早先我很多的研究基础也是基于WfMC的参考模型和XPDL描述语言的。两年之后再回过头来看看，心中已经很清晰了，至少那几个过程模型的思想已经很有把握了。
说道这儿，顺带说两个方面的个人观点，这两个方面与主题没有直接关系，但是有间接关系。以后我会写专门的文档来阐述我的这两个观点，此处我就不多加解释了，“仁者见仁，智者见智”，有心者自己把握吧。
第一：我不是很喜欢XPDL流程描述模型，但目前国内绝大多数的厂商采用的是XPDL描述模型及扩展，这没有任何不妥。目前国内的流程应用范围主要还集中在类似OA审批流之类的应用上，这一层面的应用XPDL的模型所描述的语义基本可以满足大家的理解和应用了。再加之绝大多数的客户更偏重于“离散型活动关系”，这就让建模的约束又浅了一层。
第二：在引擎构建上，需要把握关键的三点：过程模型建模、引擎调度算法和状态变迁、实例之间的对象关系。把握了这三点，则基本能够奠定一个引擎的主线结构。这好比是写文章的“主线”。当然，一篇好的文章，光有一个好的主线逻辑和构思是不够的，但主线是核心，写工作流引擎，也类似。
自从2005年初写出那款引擎之后，就很长时间没有想去写一个引擎的冲动了。这似乎是开发人员的一种诟病，如果感觉现在所做的研发或者开发，不能让自己超越现在的自己，则会丧失很大兴趣，甚至放弃。我当时就是那种状态。
我没有再去做工作流研发，但是却没有放弃对工作流的研究。从2005年中开始，我自己利用业余时间在默默地研究，也利用给别人培训和讲课的机会，对相关知识进行巩固和升华。这一年多来，收获是不小的，但是却没有再公开什么文章，是比较沉寂的一年。
什么是EPC
前面废话说了一堆，现在正式转入正题。
前段时间，公司接了一个物流的项目，其中有一个子系统是要做WMS（仓储管理系统），主要是处理物品入库、出库、库存的流程管理。我看这个WMS子系统的需求之后，对其内部所需要处理的流程、单据状态等业务场景，脑海中第一个念头就是应该采用EPC用于建模抽象。可惜这只是脑海中的一个念头而以，现实中，是不可能这么去实施这个项目的。（这是令人痛心的，不过国内很多项目的实施，是很应付性的，也很难听取开发人员的意见）。
回到家后，又把之前所搜刮到的有关EPC的资料翻了翻。其中有两篇文档在这里提一提：
第一篇就是《 SAP R/3 Business Blueprint:Understanding Enterprise Supply Chain Management》【 02】，这本书有一章节专门讲了EPC建模的要素，并且在后续章节中，用了大量的图例诠释了如何用EPC流程构建业务流程。
书中主要点了EPC的四个主要要素： 事件（Event）、功能（Function）、组织单元（Orgnization Unit）、信息（Data）（事实上，OU和Data这两个要素是ARIS系统框架中的）。由于本书的宗旨主要在于业务诠释，所以对于这几个要素讲解的不够概念化、形式化。但读完后，用EPC的图例绘制业务流程图，估计没有多大难度了。
| 元素 | 图例 | 描述 |
| Event | | 描述了状态的发生，同时又充当了一个触发器 |
| Function | | 功能描述了一个任务的执行，代表了一个start event和end event转换过程 |
| Orgnization Unit | | |
| Data | | |
| Process Path | | 流程之间的连接关系 |
| Logical Connectors | | 逻辑连符号：AND,OR,XOR |
让我们来看一个例子，可以加深对EPC所构建的流程模型的理解：下图显示的是一个货物接收处理的流程。
第二篇就是Alast大师写的《 Formalization and Verification of Event-driven Process Chains》【 04】。Alast是位Petri Net领域的专家，这篇文档也依然没有脱离PN角度。
这篇文档从“过程”角度给出了EPC的几个元素解释：
| 元素 | 描述 |
| Functions | A function corresponds to an activity (task, process step) which needs to be executed. |
| Events | Events describe the situation before and/or after a function is executed. Functions are linked by events. An event may correspond to the postcondition of one function and act as a precondition of another function. |
| Logical connectors | Connectors can be used to connect activities and events. This way the flow of control is specified. There are three types of connectors: AND, XOR (exclusive or) and OR |
Alast这篇文章另外一个重要内容，就是做了EPC到PetriNet的映射，但不涉及到对OR逻辑连接符的映射，因为OR的语义有多种诠释，不是非常清晰明确，这在Alast的这篇文档中也已经说明。
EPC的Event可以映射为PN中的库所（Place），而Function可以映射为PN中的变迁（Transition）。而至于逻辑连接符AND和XOR的映射在采用Place的控制，很容易表示：
国内EPC应用的匮乏
看到这儿，估计大家对EPC过程模型能够有个基本的认识。因为本篇不是讲解EPC的，而只是想说明： EPC在业务建模方面为我们提供了很好的参考，但是国内当前基于EPC模型的流程产品或业务产品几乎没有。在网络上搜索中文EPC的资料，仅有寥寥几篇，而且主要还都是因为讲解ARIS框架而顺带提及的。
到不是说EPC是一剂万能的良药，事实上EPC也仅是过程建模的一种。几个过程建模诸如 PetriNet、EPC、Activity Diagram、FSM等，如果可能的话， XPDL的定义元模型也算一种。
但是国内这几年的工作流相关的产品和应用发展，受WfMC的XPDL影响很深。
一方面是因为国内自身的理论研究过于薄弱和苍白，可能有些研究人员会注意到上述的那些过程建模方法，但是由于这些过程建模方法并没有形成完整的形式化描述语言支持（事实上，是有一些的，比如基于PN的PNML，基于EPC的EPML等，但是这些xml的描述语言过于理论化，不像XPDL那样偏应用），所以很难直接被一些开发厂商了解。
而另一方面，这几年国内工作流应用的主要领域依然是OA及相关审批流程。在这样一个“偏重用户自主行为控制”的流程应用领域，XPDL所阐述的流程元模型对象：Process、Activity、Transition、Participant已经基本可以描述一个完整的流程。在可以完整描述完一个流程之后，大部分厂商都把重点放在了：（1）通过扩展属性来丰富流程定义；（2）通过完善引擎的功能支持一些用户行为化的操作，诸如退回、自由流等。
但很少有厂商真正的反思一下，XPDL的过程建模就一定完善吗？合适吗？。 对于XPDL来说，有个最大的缺陷就是缺少对State和Event的描述（在XPDL2.0中已经部分的纳入Event概念了）。
而对于其他过程建模PetriNet、EPC、Activity Diagram、FSM这几个来说，State是一个核心的元素：
| 过程建模方法 | 基本模型元素 | 表示State的对象 |
| PetriNet | Place,Transition | Place |
| EPC | Event,Function,Connectors | Event |
| Activity Diagram | State,Decision | State |
| FSM | State,Action | State |
| XPDL Metedata | Activity,Transition |
在这几个过程建模方法中，EPC是最偏重于商业业务化流程的。但是却是国内应用却是空白的。
据我所知道的，目前国内已经有两三家厂商已经采用PetriNet作为流程描述模型；OSWorkflow和jBpm这两款开源引擎的应用，也已经让部分厂商在不知不觉中采用了FSM和Activity Diagram模型。唯独EPC没有应用（当然那些采用SAP R3的除外）。
我记得在2001年，我还在有生博大公司研发RiseOffice5.0公文流程系统，那时候采用的是Task和Action对象，有些类似FSM的State和Action。不过现在有生博大新版的RiseOffice工作流系统，已经采用XPDL模型了。—— 其实这也是国内很多厂商的一个开发趋势：虽然不了解“过程建模”，但是知道XPDL可以描述流程。
事实上， EPC所抽象的模型，很适合诸如B2B、供应链流程管理、仓储物流管理等商业化业务流程。这样的业务流程有个很共同的特点，对于“活动处理的前后状态”很在意。一旦把握了状态，则可以依据状态来丰富业务对象的生命周期控制和业务规则控制，这两点在业务系统中是比较重视的。
相比较而言，XPDL的元模型则仅仅只描述了“活动与活动之间的连接关系”，则很难在模型角度就看清楚活动之间所影响的状态及变更关系。
但很少有开发商或者开发人员去反思这个问题：活动与状态。XPDL虽然屏蔽了“状态”这个理念，但是由于其是目前最为“完善的XML描述化流程语言”（当然，这里我们不去谈论BPEL、BPML之类的规范），对于开发商来说，只需要考虑遵循规范和扩展，则可以基本清晰的描述一个“流程”，虽然不能够表达流程各个区段的状态问题，但是却可以清楚地展现“活动之间的关系”。
更况，国内的流程发展，这几年主要依赖于办公自动化和审批流，加上 国内应用偏重于“离散活动点的组合关系”，也就是说，在很多客户眼力：流程就是一个个离散的任务，这些任务在不同情况下可以很随意的组合。而这样的需求，是XPDL所依赖于的Activity和Transition所基本可以描述的。
加之WfMC毕竟是一个有着十多年的国际化标准组织，对客户，对开发商来说，这样的组织和标准，都是比较容易接受的。
而EPC,PetriNet,FSM,Activity Diagram则显得很脆弱，没有国际化的组织支撑，没有完善的描述语言支撑。最令人叹息的就是，在XPDL的描述模型中，几乎找不到任何这四个模型的影子，似乎WfMC在有意回避这几个建模思想。
国内的业务化建模流程，应该吸纳EPC这样建模方法，特别是在业务化系统中，比如B2B、供应链流程管理、仓储物流管理等商业化流程系统中。当然这样的代价是比较高的，需要基于这些模型元素和思想，自主摸索出一套完整描述语言。事实上，SAP R3的成功是很值得大家借鉴的。
下面把仓储管理系统中的一个入库流程中的“入库订单处理”用EPC模型表示，如下：
参考文档
【 01】 G. Keller, M. Nüttgens, A.-W. Scheer. Semantische Prozessmodellierung auf
der Grundlage „Ereignisgesteuerte Prozessketten (EPK)“. Veröffentlichung
des Institut für Wirtschaftsinformatik, Paper 089, Saarbrücken, 1992
(http://www.iwi.uni-sb.de/iwi-hefte/heft089.ps).
【 02】 Thomas A. Curran, Andrew Ladd. SAP R/3 Business Blueprint:Understanding Enterprise Supply Chain Management,2003
【 03】胡长城，《工作流引擎核心调度算法与PetriNet》，2005年
【 04】W.M.P. van der Aalst, Formalization and Verification of Event-driven Process Chains
作者 ：胡长城 [ 银狐999 ]
http://www.javafox.org
http://blog.csdn.net/james999
完成日期：2006-10-8 version 1.0
联系信箱：james-fly@vip.sina.com
MSN ：fcxiao2000@hotmail.com
引言
EPC是一种过程建模方法，全称是 Event-driven Process Chain。在九十年代初期才由Keller等人提出。对于EPC，国内开发人员是陌生的，可能很多人听说EPC【 01】，也仅仅是在ARIS（ Architecture of Integrated Information System）系统框架中接触过一些。EPC可能很多人是陌生的，但SAP R3可能很多人或多或少听过，SAP R3就是基于EPC过程建模的。
我也仅仅只是在2004年中的时候才接触过EPC这个概念的，那时候还在 思维加速公司（现在叫起步公司了）研发Biz5.0系统，为了在Process Model这一层寻找一套方法论的支持，查阅了大量的建模方法资料，其中就包括EPC。
但那时候接触的业务场景和业务范围很局限，虽然对EPC很认同，却不敢轻易的深入和采用，加上当时受Alast的 YAWL的影响，所以更加痴迷于PetriNet。——很遗憾的是，那个时候没有看出EPC与PN之间是有很大关联性的，这是后话。
2004年底进入USE（ 用友软件工程），接手了工作流引擎的开发。虽然那时候很想按照自己的思路采用PN或EPC的模型来开发，但当时在我之前的开发人员已经花费了大量时间在XPDL模型语言上，并做出了一款可运行的Deme和设计器，对我来说，当时的首要任务是重构出一款实际可用的引擎，而不是重新开发一个工作流系统。
不得已，我只能采用XPDL流程模型，也只能选择重构，这在我去年写的《 工作流引擎核心调度算法与PetriNet》【 03】已经稍稍提及了。虽然模型这个层面让我很被动，但是由于至少还可以把握引擎结构和调度算法这一层，或多或少弥补了很多。
其实，那个时候即使允许采用PN或EPC，心里其实也是没有多少底的。毕竟早先我很多的研究基础也是基于WfMC的参考模型和XPDL描述语言的。两年之后再回过头来看看，心中已经很清晰了，至少那几个过程模型的思想已经很有把握了。
说道这儿，顺带说两个方面的个人观点，这两个方面与主题没有直接关系，但是有间接关系。以后我会写专门的文档来阐述我的这两个观点，此处我就不多加解释了，“仁者见仁，智者见智”，有心者自己把握吧。
第一：我不是很喜欢XPDL流程描述模型，但目前国内绝大多数的厂商采用的是XPDL描述模型及扩展，这没有任何不妥。目前国内的流程应用范围主要还集中在类似OA审批流之类的应用上，这一层面的应用XPDL的模型所描述的语义基本可以满足大家的理解和应用了。再加之绝大多数的客户更偏重于“离散型活动关系”，这就让建模的约束又浅了一层。
第二：在引擎构建上，需要把握关键的三点：过程模型建模、引擎调度算法和状态变迁、实例之间的对象关系。把握了这三点，则基本能够奠定一个引擎的主线结构。这好比是写文章的“主线”。当然，一篇好的文章，光有一个好的主线逻辑和构思是不够的，但主线是核心，写工作流引擎，也类似。
自从2005年初写出那款引擎之后，就很长时间没有想去写一个引擎的冲动了。这似乎是开发人员的一种诟病，如果感觉现在所做的研发或者开发，不能让自己超越现在的自己，则会丧失很大兴趣，甚至放弃。我当时就是那种状态。
我没有再去做工作流研发，但是却没有放弃对工作流的研究。从2005年中开始，我自己利用业余时间在默默地研究，也利用给别人培训和讲课的机会，对相关知识进行巩固和升华。这一年多来，收获是不小的，但是却没有再公开什么文章，是比较沉寂的一年。
什么是EPC
前面废话说了一堆，现在正式转入正题。
前段时间，公司接了一个物流的项目，其中有一个子系统是要做WMS（仓储管理系统），主要是处理物品入库、出库、库存的流程管理。我看这个WMS子系统的需求之后，对其内部所需要处理的流程、单据状态等业务场景，脑海中第一个念头就是应该采用EPC用于建模抽象。可惜这只是脑海中的一个念头而以，现实中，是不可能这么去实施这个项目的。（这是令人痛心的，不过国内很多项目的实施，是很应付性的，也很难听取开发人员的意见）。
回到家后，又把之前所搜刮到的有关EPC的资料翻了翻。其中有两篇文档在这里提一提：
第一篇就是《 SAP R/3 Business Blueprint:Understanding Enterprise Supply Chain Management》【 02】，这本书有一章节专门讲了EPC建模的要素，并且在后续章节中，用了大量的图例诠释了如何用EPC流程构建业务流程。
书中主要点了EPC的四个主要要素： 事件（Event）、功能（Function）、组织单元（Orgnization Unit）、信息（Data）（事实上，OU和Data这两个要素是ARIS系统框架中的）。由于本书的宗旨主要在于业务诠释，所以对于这几个要素讲解的不够概念化、形式化。但读完后，用EPC的图例绘制业务流程图，估计没有多大难度了。
| 元素 | 图例 | 描述 |
| Event | | 描述了状态的发生，同时又充当了一个触发器 |
| Function | | 功能描述了一个任务的执行，代表了一个start event和end event转换过程 |
| Orgnization Unit | | |
| Data | | |
| Process Path | | 流程之间的连接关系 |
| Logical Connectors | | 逻辑连符号：AND,OR,XOR |
让我们来看一个例子，可以加深对EPC所构建的流程模型的理解：下图显示的是一个货物接收处理的流程。
第二篇就是Alast大师写的《 Formalization and Verification of Event-driven Process Chains》【 04】。Alast是位Petri Net领域的专家，这篇文档也依然没有脱离PN角度。
这篇文档从“过程”角度给出了EPC的几个元素解释：
| 元素 | 描述 |
| Functions | A function corresponds to an activity (task, process step) which needs to be executed. |
| Events | Events describe the situation before and/or after a function is executed. Functions are linked by events. An event may correspond to the postcondition of one function and act as a precondition of another function. |
| Logical connectors | Connectors can be used to connect activities and events. This way the flow of control is specified. There are three types of connectors: AND, XOR (exclusive or) and OR |
Alast这篇文章另外一个重要内容，就是做了EPC到PetriNet的映射，但不涉及到对OR逻辑连接符的映射，因为OR的语义有多种诠释，不是非常清晰明确，这在Alast的这篇文档中也已经说明。
EPC的Event可以映射为PN中的库所（Place），而Function可以映射为PN中的变迁（Transition）。而至于逻辑连接符AND和XOR的映射在采用Place的控制，很容易表示：
国内EPC应用的匮乏
看到这儿，估计大家对EPC过程模型能够有个基本的认识。因为本篇不是讲解EPC的，而只是想说明： EPC在业务建模方面为我们提供了很好的参考，但是国内当前基于EPC模型的流程产品或业务产品几乎没有。在网络上搜索中文EPC的资料，仅有寥寥几篇，而且主要还都是因为讲解ARIS框架而顺带提及的。
到不是说EPC是一剂万能的良药，事实上EPC也仅是过程建模的一种。几个过程建模诸如 PetriNet、EPC、Activity Diagram、FSM等，如果可能的话， XPDL的定义元模型也算一种。
但是国内这几年的工作流相关的产品和应用发展，受WfMC的XPDL影响很深。
一方面是因为国内自身的理论研究过于薄弱和苍白，可能有些研究人员会注意到上述的那些过程建模方法，但是由于这些过程建模方法并没有形成完整的形式化描述语言支持（事实上，是有一些的，比如基于PN的PNML，基于EPC的EPML等，但是这些xml的描述语言过于理论化，不像XPDL那样偏应用），所以很难直接被一些开发厂商了解。
而另一方面，这几年国内工作流应用的主要领域依然是OA及相关审批流程。在这样一个“偏重用户自主行为控制”的流程应用领域，XPDL所阐述的流程元模型对象：Process、Activity、Transition、Participant已经基本可以描述一个完整的流程。在可以完整描述完一个流程之后，大部分厂商都把重点放在了：（1）通过扩展属性来丰富流程定义；（2）通过完善引擎的功能支持一些用户行为化的操作，诸如退回、自由流等。
但很少有厂商真正的反思一下，XPDL的过程建模就一定完善吗？合适吗？。 对于XPDL来说，有个最大的缺陷就是缺少对State和Event的描述（在XPDL2.0中已经部分的纳入Event概念了）。
而对于其他过程建模PetriNet、EPC、Activity Diagram、FSM这几个来说，State是一个核心的元素：
| 过程建模方法 | 基本模型元素 | 表示State的对象 |
| PetriNet | Place,Transition | Place |
| EPC | Event,Function,Connectors | Event |
| Activity Diagram | State,Decision | State |
| FSM | State,Action | State |
| XPDL Metedata | Activity,Transition |
在这几个过程建模方法中，EPC是最偏重于商业业务化流程的。但是却是国内应用却是空白的。
据我所知道的，目前国内已经有两三家厂商已经采用PetriNet作为流程描述模型；OSWorkflow和jBpm这两款开源引擎的应用，也已经让部分厂商在不知不觉中采用了FSM和Activity Diagram模型。唯独EPC没有应用（当然那些采用SAP R3的除外）。
我记得在2001年，我还在有生博大公司研发RiseOffice5.0公文流程系统，那时候采用的是Task和Action对象，有些类似FSM的State和Action。不过现在有生博大新版的RiseOffice工作流系统，已经采用XPDL模型了。—— 其实这也是国内很多厂商的一个开发趋势：虽然不了解“过程建模”，但是知道XPDL可以描述流程。
事实上， EPC所抽象的模型，很适合诸如B2B、供应链流程管理、仓储物流管理等商业化业务流程。这样的业务流程有个很共同的特点，对于“活动处理的前后状态”很在意。一旦把握了状态，则可以依据状态来丰富业务对象的生命周期控制和业务规则控制，这两点在业务系统中是比较重视的。
相比较而言，XPDL的元模型则仅仅只描述了“活动与活动之间的连接关系”，则很难在模型角度就看清楚活动之间所影响的状态及变更关系。
但很少有开发商或者开发人员去反思这个问题：活动与状态。XPDL虽然屏蔽了“状态”这个理念，但是由于其是目前最为“完善的XML描述化流程语言”（当然，这里我们不去谈论BPEL、BPML之类的规范），对于开发商来说，只需要考虑遵循规范和扩展，则可以基本清晰的描述一个“流程”，虽然不能够表达流程各个区段的状态问题，但是却可以清楚地展现“活动之间的关系”。
更况，国内的流程发展，这几年主要依赖于办公自动化和审批流，加上 国内应用偏重于“离散活动点的组合关系”，也就是说，在很多客户眼力：流程就是一个个离散的任务，这些任务在不同情况下可以很随意的组合。而这样的需求，是XPDL所依赖于的Activity和Transition所基本可以描述的。
加之WfMC毕竟是一个有着十多年的国际化标准组织，对客户，对开发商来说，这样的组织和标准，都是比较容易接受的。
而EPC,PetriNet,FSM,Activity Diagram则显得很脆弱，没有国际化的组织支撑，没有完善的描述语言支撑。最令人叹息的就是，在XPDL的描述模型中，几乎找不到任何这四个模型的影子，似乎WfMC在有意回避这几个建模思想。
国内的业务化建模流程，应该吸纳EPC这样建模方法，特别是在业务化系统中，比如B2B、供应链流程管理、仓储物流管理等商业化流程系统中。当然这样的代价是比较高的，需要基于这些模型元素和思想，自主摸索出一套完整描述语言。事实上，SAP R3的成功是很值得大家借鉴的。
下面把仓储管理系统中的一个入库流程中的“入库订单处理”用EPC模型表示，如下：
参考文档
【 01】 G. Keller, M. Nüttgens, A.-W. Scheer. Semantische Prozessmodellierung auf
der Grundlage „Ereignisgesteuerte Prozessketten (EPK)“. Veröffentlichung
des Institut für Wirtschaftsinformatik, Paper 089, Saarbrücken, 1992
(http://www.iwi.uni-sb.de/iwi-hefte/heft089.ps).
【 02】 Thomas A. Curran, Andrew Ladd. SAP R/3 Business Blueprint:Understanding Enterprise Supply Chain Management,2003
【 03】胡长城，《工作流引擎核心调度算法与PetriNet》，2005年
【 04】W.M.P. van der Aalst, Formalization and Verification of Event-driven Process Chains
这篇关于过程建模EPC，我拿什么拯救你的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
