五、折回模式
實際工作中，工作的執行狀態不可能總是與預想相符的，總會出現各種各樣的情況，例如原本分配給員工甲的任務由于甲要請假不得不重新分配，由于新的緊急任務員工乙當前的工作需要掛起一段時間等等。折回模式則剛好對應著這些情況，折回代表著工作項狀態的反復、回退。
圖 5-33
如圖5-33所示，折回模式對應著紅線標識著的工作項的狀態變遷。這些狀態變遷對應著以下情況：
委派：資源將先前指派給他的工作項委派給他人執行。
系統重新分配：系統將沒有完成的工作項重新提供或指派給其他資源執行。
退回指派：資源撤銷指派給他的工作項，工作項可以重新指派給其他資源。
工作移交：資源將其已經開始執行的工作項移交給他人執行。
掛起/恢復執行：資源臨時掛起當前執行的工作項，并在某一個時候重新恢復執行該工作項。
跳過：資源選擇跳過指派給他的工作項的執行，不執行該工作項。
重做：資源重新執行先前已經完成的工作項。
提前執行：資源在流程實際觸發該工作前已經開始執行該工作。
折回模式共有9種。
1、委派（WRP_27:
Delegation）
描述
資源能夠將先前指派給他的工作項指派給另外的資源執行。
圖 5-34
如圖5-34所示，委派對應于紅線標識著的工作項狀態變遷。
應用
委派在平常工作中非常常見，例如員工甲將要請假，他將他要完成的工作委派給同事乙執行；在協同辦公里，領導將相關工作委派給下屬執行等等。
實現
實際應用中，委派按照粒度分為了兩種：一種
是工作項的委派，這是一種細粒度的委派，指單一任務實例的委派，與某一特定的任務實例關聯；另一種是業務的委派，這是一種粗粒度的委派，例如，員工甲將其
負責的某類業務的工作全部委派給員工乙，這意味著屬于這類業務的所有工作都將由員工乙執行。業務的委派通常與權限緊密關聯，實際實現時為避免用戶權限的混
淆，一般采取分開登錄系統的方式進行實現，即員工乙如果想處理員工甲委派給其的工作，則需要用員工甲的賬號和其給定的密碼重新登錄系統，并注銷掉自己賬號
的使用。
需要注意的一點是：委派意味著原先指派的資源還必須對該工作負責，例如員工甲將某項工作委派給員工乙執行，盡管員工乙實際執行了該工作，但該工作仍然必須由員工甲負責。所以在實現中，員工甲必須能夠保持對委派工作項的追蹤和控制。
2、系統重新分配（WRP_28:
Escalation）
描述
系統能夠重新分配已經分配的工作項，以加快工作項的執行。
圖 5-35
如圖5-35所示，工作項原先提供或指派給了一個或多個資源執行，現在由于各種原因，需要優化該工作項的執行，所以將該工作項收回重新分配，提供或指派給其他的資源。
應用
工作分配的優化。很多時候，計劃跟不上變
化，工作也是這樣，分配工作前有許多的考慮因素，例如個人能力、工作經驗、技能要求等等，但在實際工作中往往會發現原先的人力分配并不合理，或者有些人承
擔了太多的職責，或者有人能力超出其目前擔承的職責等等（在敏捷軟件開發里，我們通過頻繁的交換結對編程以達到部分的平衡），在這種時候就需要對工作進行
靈活的重新分配以到達最高的執行效率。
實現
實際實現中非常受限，對流程的優化始終是一
個對人的命題，而不是對機器對工具的命題，工具所能做到的只是盡可能多的提供可供參考的數據模型，例如各種報表、數據分析等等，最后做出決策的還是人。所
以該模式的實現也以提供給流程管理員重新分配工作項的能力為主，同時提供工作項超時的提示為輔。
3、退回指派（WRP_29:
Deallocation）
描述
資源撤銷指派給他的工作項，工作項可以重新分配給其他資源。
圖 5-36
如圖5-36所示，資源能夠退回原先指派給他的工作項，該工作項可以交由系統重新分配給其他資源。
應用
同樣是工作分配的優化，只不過該模式由資源驅動。
實際工作中，由于各種原因，例如經驗不足、當前承擔職責過多等等，發現自己并不能很好完成當前的任務時，可以提出不執行該任務。
實現
實現的難點在于資源退回工作項后的重新分配，即如何重新分配該工作項。
與提供給多個資源模式對應，該模式的最簡單支持是退回重新提供給多個資源。例如工作項分配給開發人員這一角色執行，開發人員甲拾取了該工作項（故事卡），經過一番痛苦和彷徨，最終將該工作項退回，這樣所有開發人員又都能拾取該工作項。
4、有狀態工作移交（WRP_30:
Stateful Reallocation）
描述
資源將正在執行的工作項移交給其他資源執行，該工作的狀態將得到保存。
圖 5-37
如圖5-37所示，資源將已開始執行的工作移交給其他資源執行。該模式與委派模式很相似，差別就在于委派模式是將未開始執行的工作進行重新指派執行，而該模式則是將已開始執行的工作進行重新指派執行。委派模式中的委派者仍需要為委派出去的工作負責，而移交則同時意味著責任的移交。
應用
工作移交非常常見，最常見的原因包括位置調動、離職、休假等等。
實現
在大多數的工作流系統實現里，業務數據與流程數據是相互隔離的，僅僅通過某一字段進行關聯（例如業務主鍵），流程的目標是攜帶業務數據進行流轉。在這種情況下，該模式的實現變成了默認實現，系統不需要做任何回退或清理操作，直接做工作項的轉發即可。
5、無狀態工作移交（WRP_31:
Stateless Reallocation）
描述
資源將正在執行的工作項移交給其他資源執行，該工作的狀態不會得到保存。
與有狀態工作移交對應。
應用
工作的無狀態移交通常意味著工作的重新執行，并且原有的工作對重啟的工作而言沒有太大的價值。
實現
與有狀態工作移交相比，該模式需要處理相應業務數據的回退或清理。直接支持該模式比較困難，需要在實施時根據情況對該任務節點操作業務數據的權限進行限定，并在限定的基礎上進行記錄和回退。
6、掛起/恢復執行（WRP_32:
Suspension/Resumption）
描述
資源能夠掛起當前執行的工作項，并在某一個時候重新恢復執行該工作項。
圖 5-38
應用
資源對分配給其的工作進行優化執行，能夠根據自己和當前的實際情況合理的安排工作執行，掛起正在執行的工作，執行當前最重要或效率最高的工作，然后再返回執行該工作。
實現
基本的狀態變遷。
7、跳過（WRP_33:
Skip）
描述
資源能夠選擇跳過指派給他的工作項的執行，不執行該工作項，并將該工作項標識為完成。
圖 5-39
應用
實際工作中，對于非關鍵工作，可以選擇跳過，以便進行后續更為緊急或重要的工作。
實現
對于實現工作項本身的狀態變遷來說，支持該模式非常簡單，問題在于業務數據的依賴關系，如果后續工作的處理依賴于該節點處理后的業務數據，那么簡單的選擇跳過該工作項的執行就會產生問題。所以一個好的做法是給一些關鍵任務節點加上約束，不允許執行跳過操作。
8、重做（WRP_34:
Redo）
描述
資源能夠對先前完成的工作項重新處理，同時，該工作的后續工作項（后續任務所對應的工作項）也將被重新處理。
圖 5-40
應用
對已完成的工作進行重新處理并不少見，但該
模式最為重要的部分還是在于要求所有后續工作的重新處理。所以該模式一般應用在極其重要的關鍵任務節點，例如非常重要的決策節點，因為后續的任務嚴重依賴
于該節點所作出的決策（所產生的數據），一旦決策發生變化，那么相應的后續工作必須都要做出變化。這也是業務敏捷性的一種反映。同時需要注意，該模式也是
一種代價高昂的應用，因為這往往意味著該業務流程實例中的很多工作都需要重新處理，所以如何在業務處理中盡早發現可能的環境變化并及時作出決策的調整并避
免成本高昂的返工才是最為重要的一點。
現在的軟件開發越來越強調于擁抱變化，強調
代碼的重構和演進，盡管如此，如果軟件的基礎架構需要根據當前業務變化發生重大變更，那么這依舊是一件成本高昂的事情，因為一旦基礎架構發生變化，那么很
多模塊實現將不得不重新編寫代碼。所以盡管越來越多的開發團隊開始引入敏捷的開發方法，但是經驗豐富的開發人員才是整個敏捷團隊的基石（敏捷開發非常重視
人）。
實現
從該模式里能夠看到資源模式與控制模式的結合，工作項的重做需要后續任務的重新執行，這需要取消當前的執行任務，并將流程實例的控制點重新返回至該工作項所對應的任務。這涉及到兩種控制模式，分別是：取消任務模式和任意循環模式（具體可以參考第四章的說明）。
9、提前執行（WRP_35:
Pre-Do）
描述
在工作項實際提供或指派給資源執行之前，資源已經可以執行該工作項。
圖 5-41
如圖5-41所示，任務A還在執行，任務B還未激活，但此時員工甲已經可以開始執行任務B的工作項。該模式的實現需要一個前提條件：任務B不能依賴于任務A的執行結果，即不能依賴于前續任務的處理輸出。
可以看出，該模式與前面推模式里的提前分配模式非常相似，所不同的是：提前分配強調一種通知機制，強調預先準備；而提前執行則已經可以開始實際的執行工作。
應用
和提前分配模式不同，該模式實際提供了一種
流程任務執行的靈活機制，在預先定義的業務流程里，任務的執行是具有一定順序的，可能在大多數情況下，這種順序是合理的，但是在某些具體的流程實例里，某
些串行執行的任務節點可以并行的執行以達到最好的執行效率和負載均衡，在這種情況下，就可以應用該模式并行執行部分任務。
需要注意的是，該模式僅僅引入了一種實際執行任務的靈活性，是對業務流程定義固化的補償，如果在一個業務流程中頻繁應用到該模式，則往往意味著流程定義本身需要作出調整。
http://www.tkk7.com/ronghao 榮浩原創，轉載請注明出處：）
posted on 2009-11-08 21:08
ronghao 閱讀(1684)
評論(1) 編輯 收藏 所屬分類:
Head First Process-深入淺出流程