Chapter 5. 討論與範例
5.1 時間複雜度討論
Batch Mod. Batch Interactive Incremental
worst case O(n3) O(n2) O(n) O(n)
Table 2 Time complexity comparison
由先前的討論中，各個演算法在worst case 的時間複雜度列表如上。當中 遞增式演算法雖然tracking 的 processes 數與互動式演算法都是逼近 O(n)，但遞 增式演算法僅在CONTROL BLOCK 的分支點為 AND-SPLIT 時才會進行計算，
若工作流程規格中的AND-SPLIT 數量少時，計算也會相對很少。所以 tracking 的processes 個數並不等於需要計算的 processes 個數。
從需要計算的觀點來看，遞增式演算法的計算量，會與 AND-SPLIT 個數 成正比。考慮Figure 9 僅一個 AND-SPLIT 的情況，假設編輯 process n1時採用 遞增式演算法，僅需O(1)的計算時間。若採用互動式演算法，則需拜訪所有其 他的processes，並存取計算這些 processes 對應的資源參照集合，時間花費 O(n)。
A-S
n1 n2 ……… nn-3 nn-2 S
A-J
E
接著考慮當 AND-SPLIT 個數漸漸增多時的狀況，例如當接近 O(n)個 AND-SPLITs，則可用下圖的工作流程做為例子來說明。假設 processes 總數為 n 個，以類似兩個互相對稱的二元樹架構來看，可以發現自 Start node S 到 End node E 的路徑長約為 2log(n/2)，若是在 process n1上進行編輯操作，遞增式演 算法只計算n1回溯到起始點的路徑上的每個 ancestor AND-SPLIT，因此時間複 雜度大概會在O(log(n/2) )≈O(logn)。同樣地互動式演算法會拜訪並計算所有其 他n 個 processes 一次，時間複雜度為 O(n)。
從計算量的觀點來說，可以保證遞增式演算法較互動式演算法為優。
Figure 10 an example with lots of AND-SPLITs
A-S
5.2 劇本範例
Figure 11 Scenario example
r1 r2 r3
Table 3 Resource lists on the split paths
A-J1 E
d D EST LET
n1 2 4 0 4
n2 3 5 0 5
n3 1 4 3 9
n4 4 6 0 6
n5 3 7 4 13
n6 5 10 2 14
Table 4 EAI time table
接下來我們對這個工作流程規格進行 4.1 節當中所討論的幾項編輯操作，
並分析說明所造成的影響：
(1) 新增插入一個 process n7 於 n1 與 n6 間，且 d(n7)=5, D(n7)=8, R(n7)=
r2：首先擴增 Table 4 加入 n7 的計算，EST(n7)=2，LET(n7)=12；同時更動了其 後 續 process n6 的 EST 與 LET 值 ， EST’(n6)=7>EST(n6)=2 ， LET’
(n6)=22>EST(n6)=14，推斷可能部分的資源衝突被移除且產生一些新的資源衝 突。由 錯誤! 找不到參照來源。判斷出 n7 將帶來的新資源衝突，接著利用 T_CPV 演算法往前回溯追蹤，在 A-S1的資源使用串列記錄中，首先更新自身 所在的RLsp2的記錄，然後比對其他分支上的使用情況，由於n7使用了r2這項 資源，從RLsp1上查出r2亦為所使用，緊接著從Table 5 更新過後的 EAI 時間 表上判斷，n7與n4由於時間有重疊到，因此會出現資源衝突。接著由錯誤! 找 不到參照來源。後半遞迴判斷descendant processes n6。n6回溯至A-S1得已存源 衝突(r2, n4, n6)，接著根據 Table 5 可計算出 [EST(n6), LET(n6)]∩[EST(n4), LET(n4)]=[2,6]⊆ [2,7]=[EST(n6), EST’(n6)]，因此(r2, n4, n6)這項資源衝突會因 n7
插入而消除。最後考慮是否因LET’(n6)的延後產生新的資源衝突，從 Table 5 發 現不存在與[LET(n6), LET’(n6)]=[14, 22]有交集的 process，因此不會產生新的資
源衝突。由於n6後已無activity process，檢查到此結束。下列各圖表示這次編
Table 5 EAI time table
r1 r2 r3
Table 6 Resource lists on the split paths
(2) 當移除 process n7時，一樣的回溯到A-S1中查詢哪些資源衝突會因此 而消除。將訊息通知使用者後，接著進行RLsp2的維護，以及刪除EAI 時間記 錄表上相關的欄、列記錄。除此之外，在刪除 n7 之後，也需對其後的後續 processes 的 EST 與 LET 值進行更新，並檢查其 descendent processes 是否因此 增刪了資源衝突。此操作最後結果等同將Table 5 還原為 Table 3，Table 6 還原 為Table 4。
(3) 將 process n1資源參考項目增加一項 r2，則由T_CPV 可以回溯至 A-S1
查出所造成的資源衝突為 (r2, n1, n4)，將此資訊通知使用者，並將 Table 4 中 RLsp2對應r2的位置上資訊更新為n1, n6。
(4) 緊接著當消除(3)中 n1的參考項目 r2，同樣地可以由 T_CPV 演算法回 溯查詢比對RLsp1上r2的使用情況而得知資源衝突 (r2, n1, n4) 將消除。將 Table 4 中 RLsp2對應r2的位置上資訊更新為n6。
(5) 改變 process n4的durations：由 d(n4)=4→d’(n4)=1，D(n4)=6→D’(n4)=2。
此 變 化 造 成 了 LET’(n4)=2<LET(n4)=6 ， 其 後 續 process n5 也 受 到 改 變 EST’(n5)=1<EST(n5)=4，LET’(n5)=9<LET(n5)=13，將這些更新後的狀況記錄到 Table 8。此時根據回溯到 A-S2比對RLsp3上並無n4所用資源r2被其他processes 參考，因此繼續回溯到A-S1比較，得到RLsp2上的n4與n6間存在資源衝突(r2, n4, n6) 。 接 著 根 據 4.4 節 的 判 斷 式 ， [EST(n4), LET(n4)]∩[EST(n6), LET(n6)]=[2,6] ⊆ [2,6]=[LET’(n4), LET(n4)]，可以判斷出資源衝突 (r2, n4, n6) 會 被消除。由於EST 與 LET 的改變並未終止，因此需遞迴的考慮 n4的descendent process n5，同樣的回溯A-S2與A-S1上的資源串列記錄同時比對EAI 時間記錄 表 ， 查 得 原 本 與 n5 有 資 源 衝 突 的 為 n3， 但[EST(n5), LET(n5)]∩[EST(n3), LET(n )]=[4,9]⊄ [9,13]=[LET’(n ), LET(n )]，所以已存在的資源衝突 (r , n , n )
無法消除。另外由於判斷到[EST’(n5), EST(n5)]∩[EST(n1), LET(n1)]=[1,4]≠φ， 所以將產生新資源衝突 (r1, n1, n5)。經過上述編輯異動，獲得以下 Table 8 與 Table 9 分別代表 EAI 時間記錄表與分支路徑資源串列記錄的最後狀態。
D D EST LET
n1 2 4 0 4
n2 3 5 0 5
n3 1 4 3 9
n4 4→1 6→2 0 6→2
n5 3 7 4→1 13→9
n6 5 10 2 14
Table 7 Updated abstract time table
r1 r2 r3
RLsp1 n3, n5 n4 n3
A-S1
RLsp2 n1 n6 n1
RLsp3 n3 - n3
A-S2
RLsp4 n5 n4 -
Table 8 Updated resource lists on the split paths
Chapter 6. 相關研究
一般設計工作流程，是由真實的商業流程加以抽象化後，再以工作流程規 格 語 言 來 描 述 其 定 義 ， 我 們 稱 這 樣 的 定 義 為 工 作 流 程 的 規 格 (workflow specification)。定義工作流程規格的過程是複雜而且容易導致錯誤的，特別是大 型 (large-scale) 的系統。目前幾個工作流程分析的角度包括有：(1)工作流程檢 驗 [21] (2)工作流程模擬 [22] (3)工作流程效能分析 [23]。其中工作流程檢驗 目的是檢查工作流程規格有無缺陷，因為工作流程規格的滿足正確性對工作流 程執行而言極為重要，且必須保持這樣的正確性才能達成商業的目標。[2]
6.1 工作流程規格的驗證
流程規格驗證目前主要以結構、時間、與資源三方面來分析，當中最基本 也最重要的，當屬結構驗證，因為工作流程規格必須保有其正確性，否則可能 連執行都無法開始。目前已知的結構驗證包含Petri-nets、有向圖、代數等等方 法。
Petri-nets 將工作流程中的活動之間的傳遞與相依關係對映到 places 及 arcs，且利用既有的 Petri-nets 分析技術來分析工作流程規格的正確性與一致 性。Sadiq 等人[3] 及 Onoda 等人[13] 利用有向圖分析工作流程規格，將隱含 於規格當中可能造成死結 (deadlock) 或缺乏同步性 (lack of synchronization) 的狀況利用有效的演算法偵測出來。以代數為基礎來驗證工作流程規格的方 法，是將工作流程中的 activity 表示為符號，而 activities 間的流向表示為運算 子。藉由分析這些數學運算式來判斷是否符合工作流程規格的正確性。Singh [14]
提出了事件代數 (event algebra) 來定義工作流程的模型，以便分析其正確性。
除了結構驗證被廣泛討論外，時間因素的考量也有諸多文獻提及。 1957 年 J.E. Kelly 與 M.R. Walker 共同開發了所謂的「關鍵路徑方法」(CPM, critical path method) [15]，用於製造生產與裝配作業的時間預估與控管，隨著應用領域 擴大，目前也運用到一般商業流程上。根據修改過的關鍵路徑方法，可以在工 作流程設計階段估算像是特定時間限制內要完成的工作、或是一些時間上限下 限的限制。Eder 等人[16] 在 1999 年以工作流程圖形來定義出最早結束時間與 最晚結束時間，Marjanovic [4] 則於 2000 年假設了每項 activity 有最小工作時 限 (minimum duration) 與最大工作時限 (maximum duration)，並給予每個 activity process 在執行階段時起始時間與結束時間，藉此達到設計階段更精確的 時間限制驗證。Zhunge 2001 [17] 則加入了不同時區、流向時間等考量，除了 為工作流程時間限制的一致性作更深入的分析，也巧妙利用不同時區的時差，
將工作任務調整為時間限制內可以完成。此外 Adam [10] 也運用考慮時間因素 的 Petri-nets (TCPN) 在設計間段辨別工作流程時間上的恰當性。
驗證工作流程的正確性，並不止於結構與時間上。工作流程中的processes 在操作時，需要存取各式各樣的資源來協助其完成作業，就現實環境而言，資 源限制成了驗證工作流程正確性的一項重要課題。Hongchen Li 等人於 2004 年 [2] 當中討論資源發生不一致性所可能導致的問題，且對資源一致性驗證作分 析並提供適當的演算法，最後更進一步的加入了時間因素的考量。然而這種完 整且全面的檢驗分析，對於流程設計者而言，並未能達到即時性的輔助。
6.2 遞增式設計與需求
遞增式分析原本是微觀經濟學 (microeconomics) 上的一種分析方法，主要 針對特定變因的微小改變，所造成相關變因與整體系統的影響，這種分析方法 也稱作邊際分析 (marginal analysis)。
軟體工程開發上所討論的遞增式開發則是一項類似上述的重要技術。以這 種技術開發軟體可以避免「大爆炸」(“Big Bang”) 效應，也就是說，長時間沒 有發生任何狀況，但突然間，系統被導向一個從未面對過的新狀況。遞增式發 展方法的觀念，是以軟體成長的方式取代軟體建設。同時遞增式開發方法，能 將觀察優先聚焦於軟體本質特性，也就是說額外的功能只有再需要的時候才被 加進來。[18]
針對軟體的設計而言，採用遞增式分析來觀察異動部份的元件在異動後所 造成的局部影響，然後採取相對應的措施。避免設計者因為小異動而仍須大規 模檢驗其影響。此類遞增性檢驗分析，常見的應用如有：文書軟體的錯誤拼字 檢查、程式編寫環境對指令與變數即時檢查等等。
Chapter 7. 結論與未來研究方向
工作流程規格是輔助工作流程自動化的正規化方法，許多工作流程管理系 統針對工作流程的設計環境與執行環境，提供便利於設計者、使用者與管理者 的工具。本文提出在設計階段一系列的互動式資源衝突檢驗分析討論，與改進 後的遞增式檢驗方法，對於設計工作流程的設計師即時編輯而言，有絕對正面 的幫助，除此之外也能夠有效降低執行階段的可能會遭遇的負擔與困擾。
已知的文獻中對於工作流程規格的結構正確性與時間一致性的驗證討論 甚為豐富，但對於資源驗證方面卻停留在完整而缺乏效率的方法。我們以遞增 式設計的想法，分析設計者編輯process 所帶來的局部影響，經過適當與適量的 檢驗，將消除資源衝突或可能帶來新的資源衝突的狀況，立刻反應給設計者知 道。這些activity processes 的異動因素，包含了插入新增、刪除 process、改變 process 內的資源參考，接著再加入時間因素考量，分析當一個 process 的最小 工作時限與最大工作時限有改變時，所造成的影響程度以及必須檢驗的範圍。
本文的研究重心擺在設計階段透過探討互動式分析 process 的改變與影 響，最後利用分支路徑資源串列記錄表與EAI 時間表，達成遞增式分析且加速 了分析工作的效能。未來研究將朝向：(1)複雜的不同資源類別探討，(2)在執行 階段動態改變工作流程的規格定義，如何針對資源衝突檢驗提供動態分析，(3)
本文的研究重心擺在設計階段透過探討互動式分析 process 的改變與影 響，最後利用分支路徑資源串列記錄表與EAI 時間表，達成遞增式分析且加速 了分析工作的效能。未來研究將朝向：(1)複雜的不同資源類別探討，(2)在執行 階段動態改變工作流程的規格定義，如何針對資源衝突檢驗提供動態分析，(3)