上述演算法的時間複雜度雖會將 Batch 的方法由 O(n3) 降為 O(n2)，但採 取這樣的檢驗方法仍會消耗過多時間做額外的比較、不適合用於互動式分析。
下一節我們介紹較佳的演算法來作較執行與使用者的互動式分析，並提供較細 膩的相關資訊。
3.2 activity process 編輯操作與造成的影響
流程設計師在設計階段，對工作流程規格中一個 process 所作的可能操作 有：新增、刪除、修改。如 2.2 中所述，process 的類型主要區分為兩種：(1) activity processes (2) control processes。前者主要提供給使用者任務項目內容，後者主要 作為流程流向的控制。由於control processes 的修改可能會造成工作流程結構上 的破壞，必須另外由結構驗證的方法來加以分析，而這些分析超出本文的範圍，
且以下所討論的工作流程規格，皆在無迴圈且結構正確的前替下。因此我們將 問題聚焦於針對activity processes 的編輯作分析。
互動式檢驗分析，目的是針對流程設計師的每一個編輯動作進行資源衝突 分析，提供即時反應機制，使設計師能夠迅速的獲知每個編輯細節動作，影響 潛在資源衝突的情況。[2] 中陳述的資源檢驗方式雖說完整，但全面性檢查所 有點的方法並不符合互動式開發時的分析，也就是說，流程的設計師無法準確 的掌握該次編輯異動所造成的影響為何。除此之外，若以這樣的檢驗資源衝突 演算法分析細微修改則會效率不彰。我們期望能找出一個符合互動式設計的檢 測方法，能夠讓設計師在設計階段的環境中編輯異動一個process 時，便能以更 有效率的演算法，檢查出這個異動是否會帶來資源衝突的衝擊。
activity process 的編輯主要可以分為四種，分別是： (1) 新增一個 activity process， (2) 刪除一個 activity process， (3) 增加一個 activity process 參考的 一項資源， (4) 刪除一個 activity process 當中已被參考的一項資源內容。稍後 分別再對這些情況的操作與影響做更詳細的說明。
從以上四種情況來看，對於被修改的activity process n 而言，下述三種情 況的processes 都不會與其發生資源衝突的增加或消除，因此在遞增式分析時可 以加以省去相關的比對工作。這些可省去比對的processes 包括有：(1) 所有可 到達process n 的先行(ancestor) processes，(2) 所有 n 可經由 paths 到達的後續 (descendant) processes，(3) 與 n 處在不同的平行 path 上，但彼此的共同祖先為 XOR-Split。
當一個新的activity process 被插入工作流程當中時，如果此 process 有參考 到任何資源，則有必要進行是否會造成資源衝突的檢驗。首先判斷此新增 process 的導入流 (in-flow) 的來源點，也就是此新增點的父 process，判斷是否 為一個 AND-SPLIT 型態的 control process，若不是則由此回溯的方式依序尋找 其來源點，直到Start node 為止。當找到 AND-SPLIT ancestor process 時，即可
否與此新增的activity process 有資源的交集，如果交集不為空集合，則符合不 考慮時間因素的資源衝突條件，也就是可能會導致一種或多種不同資源的潛在 資源衝突發生。
當一個activity process 被刪除掉時，由於其參考到的資源集合也相對的被 刪除，因此若此資源集合不為空集合時，則可能使原先多種資源的潛在資源衝 突的情況消除掉。必須在該process 確實被刪除前，檢查出已存在衝突，才能告 知使用者。
若增加activity process 某項資源的參考，.所需要判斷的 process，即為與此 點所在路徑可能同時執行的平行 (parallel) 路徑上其他 processes。此時需檢驗 這些路徑上的processes 個別所含的資源集合是否包含了此項新增的資源，若有 包含則可能發生此單一種資源類別的資源衝突。
修改時若僅是刪除掉所參考的資源，則可能消除同時執行的平行路徑上的 資源相依processes 的單一種資源的資源衝突。類似於刪除一個 process 的分析，
在確切消除該資源前，必須進行相關的檢驗，以告知使用者在特定的 process 上刪除該項資源會帶來哪些資源衝突的消除。
3.3 互動式資源衝突檢驗演算法
如同前節中對一個 activity processes 編輯異動的分析，互動式檢驗演算法 可改良為分析異動點所帶來的影響即可，而不必如 Algorithm 4 中對整體工作 流程規格作完整的比對。底下Algorithm 5 用於判斷新增插入一個 process 時 是否產生資源衝突，當判斷出一個資源衝突，則演算法即可中止並回傳資訊。
對使用者而言，能提供這樣的訊息是一個很好的服務。方法是首先判斷此
任何潛在資源衝突。接著可以忽略此新增process 對所有 ancestor 或 descendant processes 的影響，如前節所述以回溯(back-tracking)方式逐步找出 AND-SPLIT 的ancestor processes，然後逐一比較這個 AND-SPLIT 的其他分支上到與此新 增process 所處路徑的 AND-JOIN 會合前的各點，檢驗是否與此新增的 process 有資源交集，若有則表示產生潛在資源衝突。
Boolean OBD(workflow specification ws, process n) 1 {
10 //PART-1: Finding n’s descendants which are AND-JOIN 11 insert all out-flows of n into P;
12 while P≠φ
13 {
14 remove the first flow f from P 15 n’ = sink of f;
16 if (n’.TYPE=AND-JOIN) then 17 add n’ into AND-JOIN_SET;
18 insert all out-flows of n’ into P;
19 }
20 set P = empty;
21
22 //PART-2: Finding all AND-Split parallel processes of n 23 while Q≠φ
24 {
25 remove the first flow f from Q;
28 for each out-flow f’≠ f of n’
37 //PART-3: Detecting resource dependency 38 while P≠φ