delvin

按:從2004年到2006年,本人一直在一家公司參與開發支持XPDL規范的工作流管理系統。由于各方面的原因，產品最終沒有向市場發布，只是內部使用。2006年底，團隊解散，團隊成員都相繼離開公司。從2007年到現在，就沒有怎么做過工作的東西，但以前困擾的問題，還時時在折磨著我。為此我準備抽時間把以前對工作流的一點思考寫下來或重新整理下。

1.前言
1.1 為什么需要分析現實任務執行
  1）規范對國內的人工參與的流程關注不夠
在分析XPDL和其他規范時，發現這些規范大多數都是關注于國外的情況，就是比較關注流程自動化，對國內經常要求的那種人工干預和自由流等場景不大關注。你可以說國內客戶把工作流用偏了，假若你站在國外的情況，但我們也可以這樣來看，國內的這樣情況，是不是工作流新發展的一個動力，是工作流從不成熟到成熟的一個階段。總之，關注客戶的需求，比規范本身重要，不管是國外客戶或是國內客戶，客戶需求是技術法中的永恒動力。
  2）對工作流類任務和其他任務認識不清
1.2 目的
   設法分析現實任務類型和執行情況，為設計任務模型做理論準備。

2.內容
 現實中任務執行情況非常復雜,我們有必要對現實的復雜情況進行分析，在分析的基礎上抽象成幾種基本情況，其他的復雜情況可有這些基本情況組合而成。最好能拿出一個面向對象的任務執行模型（最好用UML表達）為我們的工作流工作項處理作準備。在實現時再分析一下那些現實的處理情況可以支持,那些情況不能支持,對不能支持的情況要說明情況(現實分析不清, 工作項處理模型不能表達現實情況,模型能表達但沒時間, 其他原因)。

為分析現實情況,讓我們用case的方式來分析，重點關注任務執行情況。為了分析的真實性，我重點分析了一個真實的轉正流程（注：考慮了隱私，我隱去具體公司的名字和人名），下表是轉正流程的圖示表示，該圖可能沒有表示此流程的所有內容，若分析需要我可能加一點東西來滿足現實的需要，我們盡量嚴格遵循現實流程的運行情況，不考慮權限控制等實現問題，側重控制流程的運轉和任務產生，分派等）：

                  
                    圖 1 XX公司員工轉正申請

1 直接完成任務

定義：任務接受者完成任務。

例子：（XX轉正流程）張三在XX公司實習了三個月，文秘發送轉正資料給張三（文秘發送轉正資料就相當于啟動一個轉正流程實例，現實中并沒有流程實例創建的概念，都是隱含的），此時該轉正流程走到填寫轉正申請，張三有了一個任務，填寫轉正申請；張三在規定時間內填寫轉正申請，完成該任務，流程到達初審活動。

2 暫停某項任務

暫停某項任務又分幾種情況（可能不全）

情況1 ：暫停某項任務，不限定時間，在該任務未超時的情況下，可以隨時繼續。

例子：（XX公司轉正流程）張三轉正流程走到復審這一步，部門經理有一項任務，復審張三的轉正申請，但部門經理因有事要出差（多長時間不能確定），只能暫停復審任務，等到有時間再復審。

情況二：暫停某項任務一段時間

例子：（XX公司轉正流程）張三轉正流程走到復審這一步，部門經理有一項任務，復審張三的轉正申請，但宋剛因有事要出差（時間為一個星期），只能暫停復審任務一個星期，等過了一個星期，復審繼續。

情況三：暫停某項任務，具體時間不知道，但重新開始的條件知道

例子：（XX公司轉正流程）張三轉正流程走到答辯這一步，答辯委員會成員（部室主任，部門經理，文秘）和答辯人吳紅軍都有一項任務，參加答辯會，但是部門經理有事要出差，不能參加，所有人的任務都處于暫停，部門經理的情況屬于情況一，其他人的任務繼續的條件是部門經理回來，他的任務重新開始。

此處有一個問題（對參加答辯會的產生的任務看法問題）：把參加答辯會是看作一個任務，有多人協作完成，還是看作多個任務，還是既看作一個任務，也看作多個任務。現實情況好象有一個隱含視角問題，從公司的角度（top-level ,不限于是公司）來看答辯會是一個任務，很可能郭安艷代表公司在公司日程上有一條答辯會條目（相當于待辦任務），從個人來說，每人都有一個任務，現實中，他們很可能每人都在自己的待辦事宜內記錄一條參加答辯會的條目（相當于待辦工作項）。

3 拒絕某項任務（不考慮原因）

例子：（精論軟件轉正流程）吳紅軍轉正流程走到答辯這一步，答辯委員會成員（部室主任，部門經理，文秘）和答辯人張三都有一項任務，參加答辯會，因為部室主任正在準備電力ppt，不想參加，他就發消息給部門經理不想參加（實質上就是拒絕此任務），部門經理就召集其他的人開答辯會（此處又涉及對拒絕任務的處理）。

4 終止（取消，結束）某項任務

例子：（XX公司轉正流程）張三轉正流程走到答辯這一步，答辯委員會成員（部室主任，部門經理，文秘）和答辯人張三都有一項任務，參加答辯會，因為不知道什么原因，張三突然離開公司（假設情況），以上任務只能終止，實際上整個流程只能終止（此處涉及到一個任務結束對活動和流程的影響，但不在此處祥解）。

注：在現實世界，終止，結束和取消的含義差不多，我們在現實生活中可以經常不加區分的使用這些詞，不過在軟件世界這些詞需要區別對待，具體區別有待在軟件產品分析中定義，主要是精確區分對資源的銷毀和回收情況。

5 指派/分派某項任務

指派任務的情況本身也非常復雜，以下把暫時能想到的情況列一下：

情況一：把自己的任務指派給他人

例子：（XX公司轉正流程）張三轉正流程走到答辯這一步，答辯委員會成員（部室主任，部門經理，文秘）和張三都有一項任務，參加答辯會，因為部室主任正在準備一個競標書，不想參加，他就指派另外一個人（被委托人）代表他參加答辯會，這樣部室主任的任務就變成了被委托人的任務。
分析：此處假定任務能被重新指派給他人。在現實中，有些任務可以重新指派給他人，但有些任務就不可以，比如涉及某些需要簽署法律效應的文件就不可以。在現實世界，一般也沒有詳細定義那些可以，那些不可以，人們基本隨機或按某種隱性規則處理。但若要在軟件領域處理此類情況，就需要精確定義，而要精確定義之前，就需要分析現實情況，并進行抽象建模。

情況二：部門領導（主管等等）把本部門的任務指派給具體的員工。

例子：（XX公司轉正流程）張三轉正流程走到答辯這一步，部門經理指派答辯委員1和答辯委員2參加答辯會。

以上只是對現實中各種可能情況的描述（注：不夠全面，僅側重于參與者[執行者]是人的情況），并不是合理的抽象，（暫時不知道如何抽象好）不知你有什么看法？