EPC 模型（事件驅動過程鏈）（Event-Driven Process Chain ）
1 、EPC是軟體工程中的一種建模方法
1) EPC 是事件驅動過程鏈（Event-Driven Process Chain ）的縮寫 。
2) EPC 模型體現了商業業務的增值過程。
2 、EPC建模方法的核心
事件Events 功能Functions 規則Rules
3 、EPC-建模規則
1) 每一個模型必須至少包含有一個開始事件和一個結束事件。
2) 功能與事件總是交替著出現。
3) 時間和功能永遠只有一個輸入和一個輸出連線。
4) 流程路徑使用規則進行分離與合併。
5) 功能的多事件觸發也是通過規則表達。
6) 決策必須是由功能作出。
7) 凡是做出了某種決策的功能，後面總是緊跟著規則。
8) 通過規則體現某個決策之後的各種可能路徑。
9) 緊跟在規則之後的事件，體現了決策的一種可能結果。
10) 規則不能同時有多個輸入和輸出。
4 、事件Events
定義：事件是環境的一種特定狀態，當環境改變到這種狀態時，相應的流程就被觸發了。通常也可以理解為現實世界的事物的某種狀態的改變，常見的三種情況：
1) 能觸發某個流程開始的外部改變（比如：客戶訂單到達）
2) 流程內部處理狀態的改變（比如：產品製造完畢）
3) 帶來外部影響的結果（比如：訂單送到客戶手中）
要點：事件可以是某人為事件或者是計算機系統操作的結果；事件的描述，通常採用一個主謂結構的詞組來表示一個狀態，比如：訂單到達、成本計算完成；
如何判斷有效事件：這個事件真的代表狀態改變嗎？這個事件是直接觸發流程？還是僅僅影響流程？
5 、事件命名
1) 流程開始事件
流程開始事件通常來自於系統之外，它啟動流程的第一個功能，因此命名時應注意相對於整體流程的意義，而不是僅僅對於其後的第一個功能有意義。
2) 流程中間事件
流程中間事件既是上一個功能的結果，又會觸發下一個功能，命名上通常會以上個功能的結果為主
3) 流程結束事件。
流程結束事件是整個流程的結果，也可能是另外一個流程的開端，命名上需要注意選擇對結束流程和觸發流程都有意義的名稱。
6 、功能Functions
定義：功能表示業務流程中的某個行為或者完成特定任務的活動。
要點：通常，流程中的每一個活動都應該是一個增值過程；功能可能由人或者計算機系統完成；每一個功能都包含有輸入，經過處理創造輸出；功能的描述，通常採用動賓短語來表示，比如：輸入訂單、計算成本，應當避免使用模糊的單個動詞來表達
7 、EPC建模—簡單例子
EPC模型8 、規則Rules – OR XOR AND
| 操作符 | 在功能之後：單輸入多輸出 | 在功能之前：多輸入單輸出 |
| OR | 或決策，在一個決策之後有一個或多個可能的結果路徑 | 或事件，功能有一個或多個可能的觸發事件 |
| XOR | 異或決策，在一個決策之後的某個時刻有且僅有一個結果路徑 | 異或事件，某個時刻有且僅有一個觸發事件 |
| AND | 與決策，在一個決策之後有多個並行的結果路徑 | 與事件，所有事件要同時滿足才能觸發事件 |
9 、規則-使用要點
不要組合規則，這樣會難以理解。
避免在事件之後使用OR和XOR，儘量使用功能來作出決策。
在功能之後，除非清楚知道多分支結果事件會同時發生才用OR，否則儘量採用XOR。
分支和合併通常使用同一個規則，如果要合併分支，在事件之後合併會更容易理解。
10 、規則-分支與合併
分支：事件使用與規則可以觸發兩個並行流程，不能使用或、異或規則。儘量避免，組合規則
11 、規則-多重事件觸發
| 事件出現場景 | 事件的作用 | 使用邏輯 |
| 非同時發生的事件 | 有相同的事件處理過程 | XOR |
| 非同時發生的事件 | 事件處理過程不同 | 需要更複雜的邏輯 |
| 同時發生的事件 | 同時發生與單一事件發生效果相同 | OR |
| 同時發生的事件 | 各自需要不同的處理 | OR |
| 同時發生的事件 | 需要兩者都完成才行 | AND |
12 、規則-依賴關係
依賴：是指流程某部分得以進行之前必須滿足的條件或必須完成的任務，依賴通常是一種狀態而非狀態的改變，避免把依賴變成事件，通常可以使用功能來檢查依賴關係
13 、總結
EPC 可以描述複雜的流程，但是為了易讀，應當注意通過控制粒度來界定表達的流程細節 。EPC 的規則是為了將流程表達的更清晰，遵循標準有利於知識的整理和傳播。
