epc于模型.doc

EPC模型（事件驱动过程链）（Event-Driven Process Chain ） 1、EPC是软件工程中的一种建模方法 1) EPC 是事件驱动过程链（Event-Driven Process Chain ）的缩写 。 2) EPC 模型通过将业务过程中的静态资源（系统、组织、数据等）组织在一起形成一个能够完成特定任务或者流程的动态模型。 3) EPC 模型体现了商业业务的增值过程。 2、EPC建模方法的核心 事件Events? ?功能Functions? ?规则Rules 3、EPC-建模规则 1) 每一个模型必须至少包含有一个开始事件和一个结束事件。 2) 功能与事件总是交替着出现。 3) 时间和功能永远只有一个输入和一个输出连接。 4) 流程路径使用规则进行分离与合并。 5) 功能的多事件触发也是通过规则表达。 6) 决策必须是由功能作出。 7) 凡是做出了某种决策的功能，后面总是紧跟着规则。 8) 通过规则体现某个决策之后的各种可能路径。 9) 紧跟在规则之后的事件，体现了决策的一种可能结果。 10) 规则不能同时有多个输入和输出。 4、 1）面向模型：模型抽象地描述了现实世界中发生的事情。但是，在信息内容和可理解性之间必须获得平衡。参考模型描述了最为常见的业务流程及其变体。这些描述确保那些最经常选择的业务流程可以利用ERP有效地实施。 2）面向客户：模型的一个基本原则是必须针对不同的目标群进行创建。比如，软件开发人员可能希望查看具体细节，但是最终用户和计划制订者在业务工程的第一阶段可能会被过于具体的信息所干扰。模型选择了一个简明的描述方法，它只采用少量几个不同的符号（这些符号组织在一个排列结合中），即使一个外行也能够立即领会。 5、事件Events定义：事件是环境的一种特定状态，当环境改变到这种状态时，相应的流程就被触发了。通常也可以理解魏现实世界的事物的某种状态的改变，常见的三种情况： 1) 能触发某个流程开始的外部改变（比如：客户订单到达） 2) 流程内部处理状态的改变（比如：产品制造完毕） 3) 带来外部影响的结果（比如：订单送到客户手中） 要点：事件可以是某人为事件或者是计算机系统操作的结果；事件的描述，通常采用一个主谓结构的词组来表示一个状态，比如：订单到达、成本计算完成； 如何判断有效事件：这个事件真的代表状态改变吗？这个事件是直接触发流程？还是仅仅影响流程？ 6、事件命名 1)?流程开始事件 流程开始事件通常来自于系统之外，它启动流程的第一个功能，因此命名时应注意相对于整体流程的意义，而不是仅仅对于其后的第一个功能有意义 2)?流程中间事件 流程中间事件既是上一个功能的结果，又会触发下一个功能，命名上通常会以上个功能的结果为主 3)?流程结束事件 流程结束事件是整个流程的结果，也可能是另外一个流程的开端，命名上需要注意选择对结束流程和触发流程都有意义的名称 7、功能Functions 定义：功能表示业务流程中的某个行为或者完成特定任务的活动。 要点：通常，流程中的每一个活动都应该是一个增值过程；功能可能由人或者计算机系统完成；每一个功能都包含有输入，经过处理创造输出；功能的描述，通常采用动宾短语来表示，比如：输入订单、计算成本，应当避免使用模糊的单个动词来表达 8、EPC建模—简单例子 ?? 9、规则Rules – OR? XOR? AND 操作符 在功能之后：单输入多输出 在功能之前：多输入单输出 OR 或决策，在一个决策之后有一个或多个可能的结果路径 或事件，功能有一个或多个可能的触发事件 XOR 异或决策，在一个决策之后的某个时刻有且仅有一个结果路径 异或事件，某个时刻有且仅有一个触发事件 AND 与决策，在一个决策之后有多个并行的结果路径 与实践，所有事件要同时满足才能触发事件 10、规则-使用要点 不要组合规则，这样会难以理解。 避免在事件之后使用OR和XOR，尽量使用功能来作出决策。 在功能之后，除非清楚知道多分支结果事件会同时发生才用OR，否则尽量采用XOR。 分支和合并通常使用同一个规则，如果要合并分支，在事件之后合并会更容易理解。 11、规则-分支与合并 分支：事件使用与规则可以触发两个并行流程，不能使用或、异或规则。尽量避免，组合规则 12、规则-多重事件触发 事件出现场景 事件的作用 使用逻辑 非同时发生的事件 有相同的事件处理过程 XOR 非同时发生的事件 事件处理过程不同 需要更复杂的逻辑 同时发生的事件 同时发生与单一事件发生效果相同 OR 同时发生的事件 各自需要不同的处理 OR 同时发生的事件 需要两者都完成才行 AND 13、规则-依赖关系依赖：是指流程某部分得以进行之前必须满足的条件或必须完成的任务，依赖通常是一种状态而非状态的改变