三、推模式
在創建階段，系統根據不同的創建模式為任務
節點產生了一個或多個工作項，每個工作項或分配給單個資源或分配給角色、部門等。那么接下來，系統就需要將這些工作項推送給相關的資源進行執行，這個推送
的過程即是推模式所包含的內容。需要注意的是，推模式討論的是對單個工作項的推送。
在前面我們已經了解到，工作流系統通過工作項管理器即不同類型的工作項列表與用戶進行交互，這里的推送也可以理解為系統將生成的工作項推送至相應資源的工作項列表里。
圖 5-17
如圖5-17所示，推模式對應著工作項到三種狀態的變遷：提供給一個資源拾取執行；提供給多個資源拾取執行（這些資源中只會有一個會實際執行，屬于競爭關系）；指派給一個資源負責執行。
推模式共有9種，分為3組，
第一組包括提供給單個資源、提供給多個資源和指派給單個資源，討論工作項推送的最終分配狀態；第二組包括隨機指派、循環指派和最短隊列指派，關注當工作項
分配給角色、部門等包含多個資源的資源組時，如何從中確定最終的一個資源并進行指派；第三組包括提前分配、即時分配和推后分配，關注將工作項推送給用戶的
時間。
1、提供給單個資源（WRP_12:
Distribution by Offer - Single Resource）
描述
能夠在非綁定的基礎上將工作項推送給單個資源。
圖 5-18
如圖5-18所示，任務A工
作項被系統推送至員工甲的可拾取列表。這意味著員工甲不必為該工作負責，他可以選擇執行該工作也可選擇忽略或拒絕。如果他選擇拒絕或忽略且工作項超時，那
么會導致系統對該工作項的重新分配。如果他選擇執行該工作，那么他首先需要拾取該工作項，這會使該工作項進入他的代辦列表，意味著其必須對該工作負責。
應用
該模式類似于現實工作中的征求意見，先將工作分配給你，然后找你談話，征求你對該工作的看法，如果合適那么就由你執行，否則再找他人執行。
實現
參與者對工作項的拒絕會導致系統對工作項的
重新分配，這是實現該模式的難點。如何重新分配該工作項，采取何種重新分配策略，這些都具有很大的復雜性。實際上這些工作流模式單個看起來可能比較清晰明
了，但一旦組合起來，例如該模式與創建模式結合起來，那么就有了多種情況變得復雜起來。對于復雜的問題，最好的解決辦法就是留給實施階段，由用戶情況作出
使用限定。這也再次強調了工作流實施在工作流應用中的重要性。
2、提供給多個資源（WRP_13:
Distribution by Offer – Multiple Resource）
描述
能夠在非綁定的基礎上將工作項推送給多個資源。
圖 5-19
如圖5-19所示，任務A所
生成的工作項被推送給多個員工的可拾取列表。這些員工不必為該工作負責，他們可以選擇執行該工作也可選擇忽略或拒絕。如果他們都選擇拒絕或忽略且工作項超
時，那么會導致系統對該工作項的重新分配。如果有一名員工選擇執行該工作，那么該工作項進入他的代辦列表，其他員工將不再具有拾取該工作項的機會。
應用
該模式是典型的競爭參與，即多人可以完成該工作，先執行者先得。類似于尋找志愿者。
實現
該模式的實現一般是創建階段將工作項分配給角色、部門等包含多個資源的分組，在推送階段，將該工作項送至這些組下所有資源共享的可拾取列表里，工作項的實例只有一個，但是多資源可見。
3、指派給單個資源（WRP_14:
Distribution by Allocation – Single Resource）
描述
能夠在綁定的基礎上將工作項推送給單個資源。
圖 5-20
如圖5-20所示，任務A工作項被系統推送至員工甲的待辦列表。這意味著員工甲必須為該工作負責。
應用
該模式是應用最多的模式，直接指定任務的負責人。
在采用軍事化管理的企業里，上級的命令一定要執行，下屬沒有商量和拒絕的權利。
實現
相比提供，指派實現非常容易，直接將工作項推送至選定資源的待辦列表。
4、隨機指派（WRP_15:
Random Allocation）
描述
當存在多個資源可供選擇時，從中隨機選擇一個資源進行工作項的指派。
圖 5-21
如圖5-21所示，任務A所生成的工作項在創建階段分配給了開發人員這一角色，在推送階段，系統會隨機選取一名開發人員負責該工作項的執行。
應用
該模式提供了一種指派資源的非確定性機制。
5、循環指派（WRP_16:
Round Robin Allocation）
描述
當存在多個資源可供選擇時，循環選擇其中一個資源進行工作項的指派。
圖 5-22
如圖5-22所示，任務A所生成的工作項在創建階段分配給了開發人員這一角色，在推送階段，系統會循環輪流選取一名開發人員負責該工作項的執行。
應用
不患貧而患不均，平等的分配工作。
6、最短隊列指派（WRP_17:
Shortest Queue）
描述
當存在多個資源可供選擇時，選擇其中一個具有最少待辦工作即最短工作隊列的資源進行工作項的指派。
圖 5-23
如圖5-23所示，任務A所生成的工作項在創建階段分配給了開發人員這一角色，在推送階段，系統發現員工甲的待辦列表里有兩條待辦工作（任務B和任務C），員工乙的待辦列表里沒有待辦工作，所以系統將任務A工作項指派給員工乙負責該工作項的執行。
應用
該模式的目的在于能夠最快開始工作的執行，找出相比而言最為空閑的資源迅速開始工作。但是實際應用中，僅僅依靠工作的數量來判斷資源是否空閑是不可靠的，因為工作和工作之間還存在著難易之分。
7、提前分配（WRP_18:
Early Distribution）
描述
在工作項實際可以執行之前即將該工作項通知或潛在的分配給資源。
圖 5-24
如圖5-24所示，任務A還在執行，任務B還未激活，但此時任務B的工作項已經提前分配給員工甲，該工作項的主要職責是通知員工甲將由其來完成任務B并能開始一部分準備工作，而實際的工作則要等到任務B被激活后才能進行。
應用
該模式強調的是預先計劃，即管理的計劃性。
在我們實際的項目開始之前，項目經理已經通知我們將要進行的開發工作，讓我們提前熟悉相關的技術。這樣當項目開始時就能提高最初迭代的開發效率。
從某種意義上說，稍微復雜一點的工作都應該做到提前通知、提前準備，即計劃的必要性。
實現
讓工作流系統直接支持該模式比較困難，因為該模式嵌套在控制模式和不同的工作項創建模式里，找不出一種通用的模式，無法預判工作項的生成和實際的參與者。在一定范圍內，可以采用下面的方式變通：
圖 5-25
如圖5-25所示，在自動節點執行時能確定任務B的參與者的情況下，可以通過自動節點給員工甲發送郵件或消息進行通知，工作流系統并不生成工作項。
8、即時分配（WRP_19:
Distribution on Enablement）
描述
在工作項實際可以執行時將該工作項分配給資源。
應用
機器執行的工作，重復單一的審批工作，無計劃性的工作，如各種突發情況的處理。
實現
大多數工作流系統的標準實現，滿足任務執行條件時先激活任務節點，然后創建工作項、分配工作項。
9、推后分配（WRP_20:
Late Distribution）
描述
在工作項實際可以執行后的某個時間才將該工作項分配給資源。
圖 5-26
如圖5-26所示，任務B已經激活且已生成可以執行工作項，但是系統并沒有將其分配至員工甲的工作項列表里。這是因為員工甲正在執行任務A的工作項，直到其執行任務A完畢，系統才會把任務B工作項推送至工作項列表。
應用
保證流程和資源對工作的負載處于一種良好的狀態，避免出現下圖的情況：
圖 5-27
在敏捷開發里，我們強調客戶合作，整個的開發過程對用戶透明，用戶知道當前正在進行的開發工作，也清楚開發團隊的開發速度，在這種情況下，一旦有新的需求加入，用戶會推遲該需求的實現，或者推遲當前其他需求的實現，從而保證整個團隊的開發效率。
實現
該模式的實現依賴于推后的策略，即在什么情況下推后分配，滿足什么條件下進行分配。具體實現同樣采取推后模式，推后到實施階段實現。
posted @
2009-10-25 21:46 ronghao 閱讀(1821) |
評論 (1) |
編輯 收藏二、創建模式
創建模式在系統創建工作項時生效，如下圖所示，其位于工作項生命周期的創建階段。
圖 5-2
正如上面提到的，工作流系統在執行任務節點時會為其創建相應的工作項，根據情況工作項可以是一個也可以是多個。
創建模式作為流程模型的構成部分在流程設計期指定，通常在任務節點的定義里進行定義，與一個任務關聯，其用來限定可執行該任務的資源范圍。系統根據創建模式限定的資源范圍生成工作項，工作項可以直接分配給人，也可以分配給角色、部門、崗位等。
1、直接分配（WRP_01:
Direct Distribution）
描述
在設計期直接為任務指定特定的資源，該任務的工作項能夠在運行期分配給它。注意，指定的資源可以為多個，如果是多個的話就會生成多個工作項，為每個資源生成一個單獨的工作項。該模式實際限制執行該任務的資源范圍。
圖 5-3
如圖5-3所示，任務A在定義時直接指定給員工甲，任務B在定義時直接指定給員工乙，當實際執行任務A和任務B時，將由員工甲和員工乙分別執行。
應用
該模式一般應用于流程里的關鍵路徑。同時，
在中小企業里，該模式是應用最多的分配模式，因為人員少，管理扁平，所以每個人的職責都非常清晰。該模式也是執行效率較高的資源模式，因為人和任務直接綁
定，所以不會產生推諉等情況，便于管理也便于追究責任，因為運行情況完全在設計期確定。而隨著企業規模的擴大，管理層次的復雜，一個任務往往需要交由特定
的部門、崗位或角色來執行，這樣無形中會影響任務執行的效率。
該模式的缺點在于一旦關鍵人物因為各種原因不能及時處理任務，那么將造成整個流程的掛起等待。
實現
最簡單的資源模式，設計期確定資源，運行期工作流引擎不需要做額外的工作。
2、基于角色的分配（WRP_02:
Role-Based Distribution）
描述
在設計期為任務指定一個或多個角色，該任務的工作項能夠在運行期分配給這些角色。實際執行該任務時，資源將從屬于這些角色的資源中產生。該模式實際限制執行該任務的資源范圍。
圖 5-4
如圖5-4所示，任務A在定義時指定給“開發人員”這一角色，該角色包括了兩名員工甲和乙。實際執行任務A時，將由員工甲或乙來執行。
應用
企業達到一定規模，就會產生人員的分組，角色是典型的分組方式，將具有相似屬性的人員定義為一個特定的角色，這些屬性通常與工作的內容相關，例如開發人員、項目經理、總經理等，而角色通常又會與權限產生關聯。
將任務分配給角色意味著將會有多個員工可以執行該任務，執行效率相比直接分配會有下降，這也是企業擴大后管理成本增大的一種表現形式。
實現
工作流系統內置的組織機構模型需要對角色進行支持。引擎運行期通過角色訪問屬于該角色的人員。
3、延遲分配（WRP_03:
Deferred Distribution）
描述
在設計期為任務指定資源的標識，典型的，在工作流系統里，該標識對應于一個數據字段變量，例如userid。即在設計期并不確定資源，資源的確定被延遲至運行期，系統運行期從該數據字段里獲取該任務分配的資源。
圖 5-5
如圖5-5所示，任務B在定義時資源的標識指定為userid，實際執行時，任務A由員工甲執行，其指定了下一任務的執行者為員工乙即設置了userid這一變量為員工乙的id，在任務B實例創建時，它訪問userid，發現該變量里是員工乙的id，于是將該任務分配給員工乙。
需要注意的是，根據具體的分配策略，運行期該數據字段不僅可以指定人員，也可以指定角色、部門等。
應用
該模式給資源的分配引入了靈活性。資源的確定延遲至運行期，即任務可以根據具體的實際情況再確定執行人。具體實施時，這個指定的數據字段可以通過一系列的規則運算得出。
在國內應用中，該模式被大量應用在人工干預流程中，例如下一任務的執行由上一任務的辦理者指定。
實現
一般通過工作流變量來包含資源的id。為了區別該id是人員id還是角色id，一般內置特殊變量，例如userid、roleid、groupid等。
4、按權限分配（WRP_04:
Authorization）
描述
能夠指定資源的范圍，只有該范圍內的資源才具有執行該任務的權限。
圖 5-6
如圖5-6所示，只有項目經理才有權限對開發人員申請軟件的要求進行批準。
應用
隨著分工的細化，每個人工作內容的不同，必然會產生權限的概念。權限實際代表著對同一件事情，每個人執行工作內容的差別。權限越大能執行的操作越多意味著需要負責的方面越多。
該模式強調通過權限對執行任務的資源加以限定。
實現
在大多數的軟件系統中，角色不僅僅代表具有相似屬性的一組人員，同時其也是最重要的權限概念，人員往往不與權限直接關聯，角色將人員與權限兩者進行關聯。所以，對任務設定權限可以通過指定角色來完成。
5、職責分離（WRP_05:
Separation of Duties）
描述
在一個流程實例里，能夠指定兩個任務必須由不同的資源執行。
圖 5-7
如圖5-7所示，任務A和任務B在設計期被指定不能由相同的資源執行，同時它們都指定分配給經理這個角色。那么在運行期，在一個流程實例里，任務A被分配給了員工甲執行，那么在進行任務B的分配時，盡管員工甲也屬于經理，但是將不能由其執行。
應用
職責分離，不能既當運動員又當裁判員，不能又當跳水隊領隊又當全運會裁判長。
典型的報銷流程里，一般員工的差旅報銷由財務人員核實，但如果某名財務人員需要報銷差旅費顯然不能由自己審批，需要另外一名具有同樣權限的財務人員審核。此時就可以對申請任務和審核任務兩個任務節點應用該模式。如下圖所示：
圖 5-8
實現
后續節點進行任務分配時，需要獲取與之關聯前續節點的分配執行信息。流程定義期，在定義任務節點屬性時建立兩者的關系。
6、流程實例整個處理（WRP_06:
Case Handing）
描述
在一個流程實例里，所有的任務都能夠分配給同一個資源執行。
圖 5-9
如圖5-9所示，流程實例中的所有任務都由同一個人執行：任務A、B、C都由員工甲執行。
應用
在應用該模式的流程里，通常流程里的任務都
是緊密關聯的。流程里的任務往往執行在一個緊密相關的上下文里，如果所有的工作都由一個人執行，那么在其了解該上下文的情況下連貫執行這些任務會具有更高
的效率；而如果執行任務的過程中換人，那么新換的人無疑還需要時間對該流程實例相關的上下文進行熟悉，這樣無疑會多付出執行成本。
同一個軟件的開發最好由同一撥開發人員完成，如果中途更換開發人員，那么新來的開發人員需要一段時間熟悉該軟件，會對開發進度產生影響。同樣的道理，在軟件上線前增加開發人員不一定會提高開發效率，很多時候甚至作用相反。
實現
可以在實現延遲分配模式的情況下實現該模式，即在第一個任務節點初始化設置參與者變量，后續任務全部使用該變量。如下圖所示：
圖 5-10
7、經驗獲取（WRP_07:
Retain Familiar）
描述
在同一個流程實例里，當存在多個資源都能執行某一工作項時，能夠將該工作項分配給執行了前某一工作項的同一資源。
圖 5-11
如圖5-11所示，任務A和任務B在設計期被指定由相同的資源執行，同時它們都指定分配給經理這個角色。那么在運行期，在一個流程實例里，任務A被分配給了員工甲執行，那么在進行任務B的分配時，任務B依舊由員工甲執行。
應用
該模式剛好與職責分離模式相反，正如它的名字所暗示的，這些任務之間存在著緊密關聯，如果執行了其中一個，那么就會熟悉這些相關聯任務的背景上下文，積累一定經驗，那么后續任務的執行相對其他人來說會變得容易。提高任務執行的效率。
圖 5-12
如圖5-12所示，在軟件銷售的過程中，售前和編寫標書是重要的兩步，這兩個任務最好由同一個人進行處理，因為參與軟件售前的人更熟悉客戶的實際情況和需求，如果分開由不同的人員執行，那么必然會存在前者與后者的交流成本。
實現
后續節點進行任務分配時，需要獲取與之關聯前續節點的分配執行信息。流程定義期，在定義任務節點屬性時建立兩者的關系。運行期可以通過參與者變量（工作流變量）建立起運行期關系。
8、基于能力的分配（WRP_08:
Capability-Based Distribution）
描述
能夠基于資源的能力進行工作項的分配，能力作為組織模型的一部分建模為資源的屬性。
圖 5-13
如圖5-13所示，任務A需要交與開發人員執行，同時其對辦理該任務的人員能力提出了要求，要求只有熟悉JAVA且工作經驗大于2年的開發人員才能執行該任務。這樣就縮小了選取資源的范圍。
應用
人力資源管理中很重要的一點就是要做到人盡
其用，每個人的能力都能得到最大的發揮，其實也就是根據能力將人放置到最合適的工作中去。從這一點看，該模式是對人盡其能的實現。但是如何定義各個人員的
能力，這本身就比較的主觀，執行各項工作需要具備的能力也具有主觀因素，更何況很多時候能力并不能與表現劃上等號，模型是固定的但人是變化的受環境影響
的，所以工具本身就是工具，工具的應用最后還是依賴于人。
實現
實現需要兩部分：一部分是組織機構對人進行建模時需要包括能力模型；另一部分是流程建模時需要給任務定義執行該任務所需的能力約束，這些約束是一系列的領域特定條件，需要有特定的解析器進行條件的解析。
很多工作流引擎提供有參與者接口，接口返回人員ID列表供給任務分配，從而將這部分工作委派到工作流實施時實現。
9、基于歷史的分配（WRP_09:
History-Based Distribution）
描述
能夠基于先前的工作歷史決定當前任務的分配。
圖 5-14
如圖5-14所示，當需要在員工甲和員工乙之間做出選擇時，會選擇此前執行類似任務時完成最好的員工。需要注意的是，這里的歷史不再是限定在同一流程實例的任務執行里，可能是同一流程模型的執行歷史，也可能是不同流程模型的執行歷史。
考慮歷史時，有很多的考慮因素，例如完成類似任務最好的員工、完成類似任務最快的員工、完成類似任務出差錯最少的員工等等。這些考慮因素依賴于具體的任務內容和背景。
應用
國家籃球隊比賽前，主教練會考察各個位置里各個球員的聯賽比賽歷史情況，其中不僅會考慮出場時間也會考慮各項數據，從而做出選擇。
實現
同基于能力的分配模式一樣，該模式的實現依賴于工作流具體應用的場景，也就是需要到實施階段結合實際實現。從某一種角度也說明，應用工作流產品時，產品實施階段也是最重要的步驟，選擇工作流產品不僅僅是選擇產品也需要考察其背后的實施團隊。同時也可見，這些模式在諸如政府OA這些應用中是根本應用不上的。
實現需要兩部分：一部分是對用戶任務執行歷史進行統計分析找出關鍵的評定因素；另一部分是流程建模時需要給任務定義執行該任務所需的歷史因素約束，這些約束同樣是一系列的領域特定條件，需要特定的解析器進行解析。
10、按組織分配（WRP_10:
Organizational Distribution）
描述
能夠基于人員在組織機構中的位置以及與其他人員的關系分配工作項。
圖 5-15
如圖5-15所示，審批任務需要由申請人的部門經理執行，即需要員工甲的部門經理執行。這種情況即基于人員之間的關系分配工作。
基于人員在組織機構中的位置分配即需要在工作流模型里建立起與用戶相匹配的組織機構模型，可以將任務分配給部門、角色、臨時組、崗位等。
應用
應用最為廣泛的模式，實際工作中幾乎所有的工作都必然和組織機構具有聯系。其他模式，如基于歷史的分配、基于能力的分配等都是基于該模式之上的擴展，直接分配、基于角色的分配則直接是該模式的簡單情況。
實現
對該模式的支持實際上是對用戶組織機構模型的支持。正如前面所提到的，很難存在一種工作流產品能夠支持所有的組織機構模型，但是大部分的產品都會提供一套元模型或擴展機制，需要在實施過程中最大限度的契合客戶業務。
11、自動執行（WRP_11:
Automatic Execution）
描述
任務的執行能夠自動完成，不需要人員參與。
圖 5-16
如圖5-16所示，請假審批后需要將情況通知給申請人，該任務由計算機完成，不需要人的參與，也不會產生工作項。
應用
隨著自動化水平的提高，越來越多的工作可以交由計算機或相應的機器設備完成。流程中的自動執行節點也會逐漸增加。
實現
實際上工作流產品對該模式的支持即是支持各種的企業集成方式，不管是通過Web服務還是消息，工作流需要驅動相應的設備機器或應用系統進行工作并傳遞給必須的數據。所以也可以看出，隨著信息化程度的提高，目前工作流應用越來越趨向于企業集成領域。這也是為什么基于Web服務編排的BPEL會逐漸取代XPDL成為工作流流行標準的原因之一。
posted @
2009-10-20 13:18 ronghao 閱讀(1503) |
評論 (2) |
編輯 收藏
在上一章里，我們談到了工作流的控制模式，控制模式強調的是對業務流程進行建模，業務流程的目標是實現一個商業目標或者管理目標，業務流程的執行往往由一系列的任務所構成，控制模式建模的實質在于合理調配這些任務，以期以最少的成本達到最大的收益。
本章將介紹工作流的資源模式，如果說控制模式更為宏觀，強調的是業務流程里各個任務的合理調配的話，那么資源模式則深入細節，將要討論單個具體任務的執行情況。提到任務的執行，那么誰能執行這些任務呢。答案很直接，是人。不管是在公司企業還是政府里，人都是最重要的資源，除去人之外，還有其他的非人力資源，例如機器、設備、計算機等。探討這些資源如何執行業務流程中的具體任務，如何調配這些資源即構成了本章的內容，即資源模式。
本章介紹工作流的資源模式，共計43種。提到模式，很多人會想到四人幫，想到他們的設計模式，但是需要與編程里的設計模式區別的是：程序里的設計模式關注的是代碼，通過應用設計模式做到代碼的職責清晰、不重復、開發人員友好等等；而工作流里的模式關注的是業務價值，通過合理調配任務和資源為組織帶來最大的業務價值，工作流模式是對實際業務的直接描述，與具體的工作流產品實現沒有直接的關系（后面我們可以看到，很多模式當前的工作流產品很難實現），兩者的出發點完全不同。
本章先會討論與資源模式相關的一些基本概念，例如資源、工作項、組織機構建模等。接下來會對具體的43種資源模式進行討論，討論的模式按照描述、應用和實現展開，分別對應著模式的介紹、模式對實際業務的映射和工作流產品對該模式的實現支持。最后是小結。
一、基本概念
1、資源
既然是資源模式，那么什么是資源。在本章的前言里，我們已經提到人是業務流程執行里最為重要的資源，除去人之外，隨著自動化水平的提高，還有其他的非人力資源，例如機器、設備、計算機等。資源指的是能夠進行工作的實體，通俗一點，就是能夠執行業務流程里任務的實體。對于需要盈利的公司而言，就是找到一種可以盈利的模式，然后找尋能夠執行這些盈利工作的資源，通過資源的工作達到盈利的目的，通過合理調配這些資源達到利益最大化。
因為人是最為重要的資源，所以在后續對資源模式的討論中，沒有特殊說明，資源指的都是人力資源，大多數的模式也將以人來說明。
典型的，人是某個組織機構里的成員。組織機構對人員進行分組，執行相關的工作以達到共同的目標。例如，企業的目標是盈利，政府的目標是為人民提供更好的公共服務。組織機構對人員的分組具有多種形式，最常見的就是部門、角色和崗位（實際上與角色相比，崗位更多體現的是一種業務職能，而角色更多體現的是管理職能，與權限相關）。對于大的跨地域的組織而言，還有分支機構的劃分，此外，還有臨時組（典型的如以交付為核心的軟件開發公司里的項目組）。在很多情況下，人可能具有多個角色、屬于多個部門，這些，增加了管理的復雜性。
對工作流產品而言，要對資源模式進行支持，則必然涉及到對資源分組的支持，在大多情況下，資源分組即組織機構模型。只有支持目標客戶的組織機構模型，才能在實施工作流產品時最大限度的契合客戶業務。當然，如果產品是某個行業的標準，讓客戶模型向產品靠攏也是另外一種方式。
2、工作流產品里的組織機構建模
所有的工作流產品都有自己的組織機構模型，其是工作流產品里一個重要的模塊。但是一套模型往往很難契合多種業務場景。在大多數的產品實現里，都會提供一套元模型，例如人（Person）和組（Group），然后建立多套與業務相關的模型向元模型適配，例如，角色、部門都是組的一種形式，它們只是擁有不同的業務語義而已。
在工作流產品實施時，很重要的一步就是進行組織機構建模，然后將建立完成的模型與工作流產品內置的模型進行適配，在適配的過程中，妥協是經常出現的。
3、工作項
一個業務流程由一系列相關的任務組成。在工作流產品里，使用圖形化的節點代表這些任務，而實際的任務被映射為工作項（work item），任務的調用被映射為工作項的執行。一般情況下，一個任務對應著一個工作項，但是存在一個任務需要多人完成的情況，這個時候一個任務就會對應著多個工作項。工作項可以看作是工作流中最小的工作單元，其代表著一個單一資源對某一任務的執行。
既然在工作流系統里任務的執行被映射為工作項的執行，那么就一定存在著人與工作項這個計算機概念的交互，在工作流系統里，這一交互通過工作項管理器來進行管理。即我們通常所見的工作項列表（任務列表），我們通過這一列表拾取任務、處理任務以及管理任務的狀態。
4、工作項的生命周期
工作項有其自己的生命周期。
圖 5-1
如圖5-1所示，當工作流系統執行某一任務節點時就會創建工作項，工作項可以是一個也可以是多個，正如上面已經提到的，工作項代表著一個單一資源對某一任務的執行即一個工作項只能由一個資源來執行，現在我們討論的是一個工作項的生命周期。
工作項被系統創建完畢后即處于創建狀態，接下來系統會選取資源來執行該工作項。有兩種狀態：一種是提供狀態，一種是指派狀態，這兩者的區別在于一個是可選的一個是必須的。如果系統提供一個工作項給你執行，這意味著你符合執行該工作的條件，但你不必為該工作負責，即你可以選擇執行該工作也可以選擇拒絕，你只是該工作的合適候選者；而如果系統指派一個工作項給你執行，則意味著你必須為該工作負責，該工作必須由你來執行。因為一個工作項只能由一個資源來執行，所以如果是指派的話，那么只能指定一個資源；而提供，則可以提供給一個資源也可以提供給多個資源來候選。通常工作項管理器會提供兩種列表來區分這兩種狀態，分別是待拾取列表和待辦列表，一旦資源對待拾取列表里的工作項進行拾取，工作項即進入到資源的待辦列表，狀態成為指派狀態。
工作項進入指派狀態即意味著執行該工作的資源已確定，那么接下來就可以由資源來開始執行該工作，執行的過程中可以將工作暫時掛起中斷處理，后續可以再恢復對該工作的執行。如果工作成功完成，則工作項成為完成狀態；如果工作因為各種原因沒有成功完成，則工作項置為失敗狀態。
posted @
2009-10-18 09:45 ronghao 閱讀(1608) |
評論 (1) |
編輯 收藏
似乎一到年末，就會忙起來。
05年的時候忙著和現在的老婆談那從來沒談過而導致過分饑渴的戀愛；06年的時候新配置了機器，忙著通關使命召喚和生化危機；07年的時候和張祖良一起翻譯
AJAX企業級開發，第一次翻譯，忙得像黃牛，慢得像蝸牛，在心里祈禱，翻譯出來的東西不被罵就好；08年的時候和丁雪峰、總司令又一起翻譯
Spring攻略，第二次翻譯，熟練了一些，但是每一個句子還是要花上很多時間，很多時候還得一個詞一個詞的確認，翻譯對我來說是個苦力活，第一次翻譯完我就告訴自己不要再翻譯了，但是Spring攻略確實是一本好書，完全是書本身吸引了我，同樣在心里祈禱，不要糟蹋了這本書。09年了，和
辛鵬一起完成這本《Head First Process-深入淺出流程》，還是祈禱，千萬不要寫出垃圾，有時候，我常想，有必要這么辛苦嗎？我是一個喜歡意淫的人，經常就把思緒拋到了多年之后，在未來里洋洋自得，于是回來時就有了動力。
我負責該書的第一部分，包括了工作流的控制模式、資源模式、數據控制模式與異常處理模式，包括了對三種流程規范的介紹、對開源工作流的介紹、對jBPM4的分析。辛鵬負責該書的后半部分，他對流程應用有著非常豐富的經驗，目前他正在杭州實施一個BPM的大項目，其中包括了完整的IBM產品套件，包括了企業集成和ESB。很多人認為工作流只是OA，這其實是一個誤區，工作流確實在OA里應用的非常多，但這僅僅只是一個方面。說實話，我對本書也非常的期待，非常期待辛鵬在書中分享他眾多的實施經驗，他是一個非常勤奮的人，這點讓我欽佩不止，常常想，等我到了30多歲，還會不會有一顆勤奮的心。
家住燕郊，上班在東直門，每天在路上四個小時，擠那傳說中的930，時常安慰自己：哥擠的不是930，哥擠的是寂寞。謝謝老婆，盡管還還著房貸存在著心理障礙，但是還是為我在東直門租了個房子，下周起就可以走路上班了，這樣也會有了更多的時間來完成這本書。
還是那句話：戰戰兢兢。
十一過完，公司的新項目也開始了，時尚網站。技術棧包括了：OSGI、JCR、REST、漸進式增強。該項目有個巨大的亮點，不是徐昊是我們的技術leader，而是開發人員中一半是女生，這樣每天pair的時候就生活在祖國的花園中了。
希望能寫些有價值的東西，征得劉江的同意，將會在博客連載部分章節。第一部分連載的將是工作流的資源模式，內容包括前言、基本概念、創建模式、推模式、拉模式、迂回模式、自動開始模式、可見性模式、多資源模式以及最后的小結。限于篇幅，將會分節進行連載。考慮到復制麻煩，將會在
開放流程社區連載所有內容，博客會連載概要并提供鏈接。
posted @
2009-10-17 23:03 ronghao 閱讀(2637) |
評論 (2) |
編輯 收藏
所謂流程設計器者，無怪乎讀取xml文件，圖形展現，操作圖形元素，改變xml文件，回寫，如此而已。
既然如此，設計器的流程結構就非常清晰：首先是xml框架解析xml文件為Model模型組件，然后Model模型組件被展現為Component視圖組件；用戶對Component視圖組件進行操作，這些操作被同步的修改到Model模型組件；最后用戶保存時，Model模型組件經過xml框架解析回xml文件，該文件被上傳到服務器或本地覆蓋原有的xml文件。
那么代碼結構就很清晰了：xml框架、Model模型組件和Component視圖組件。但是等等，Model與Component如何交互呢？這里就需要GEF框架嫁接起兩者的聯系。同時，一個流程設計器往往要同時編輯多個流程定義，相比具體的流程定義而言，設計器擁有一些全局的對象，這些全局對象包括系統菜單欄、工具條、整個設計器布局框架（ProcessDesigner）、設計器入口（ProcessEditor），還有就是負責保存全局屬性和發布/訂閱定制事件的TheModel對象。
二、 Component視圖組件
很直接，Component視圖組件指的是與用戶打交道的、與流程定義相關的視圖元素。注意這里的一個定語：與流程定義相關的，即不包括系統菜單、工具條這些東東。這些視圖元素很簡單，包括畫圖板、各種節點元素和連接線元素。
代碼位于org.jbpmside.view.component和org.jbpmside.view.component.node下。主要類SurfaceComponent、NodeComponent和ConnectionComponent。看類名就很清晰這些類分別代表著什么組件：
• SurfaceComponent代表畫圖板；
• NodeComponent代表節點；
• ConnectionComponent代表連接線；
org.jbpmside.view.component.node下的類就是NodeComponent類的子類，代表具體的單個節點類型了，包括開始節點、結束節點、Fork節點、Join節點等等。
Component視圖組件使用了degrafa來渲染表現形式。
目前缺少一個屬性彈出框組件，職責展現和修改節點/連接線屬性。
三、 Model模型組件
Xml流程定義文件解析為本地Model模型組件，本地建模和jBPM4的PVM建模一致，代碼位于org.jbpmside.model下，重要的類：
• ProcessModel代表流程定義；
• NodeModel代表節點定義；
• ConnectionModel代表連接線定義；
剩下的就是具體節點類型的模型類，例如StartNode/EndNode/TaskNode等。
目前模型類還非常簡單，因為前段時間主要關注Component視圖組件部分，接下來很快會與jPDL規范完全同步，同時ProcessModel/NodeModel/ConnectionModel會進行重構，目標是與jBPM4模型完全一致。
最新的模型位于org.jbpmside.model.common下，對jpdl4的支持位于org.jbpmside.model.jpdl4下，未來需要將Component與Model的關聯遷移至common包下。
四、 GEF框架
GEF框架嫁接Model與Component。
1、 IGraphicalEditor與IEditPart
IGraphicalEditor與IEditPart是GEF框架里最重要的兩個接口：
• IGraphicalEditor代表整個圖形編輯器，IGraphicalEditor里最重要的方法：
function get graphicViewer():GraphicViewer;
返回當前的圖形視圖。在當前的設計里，設計器支持多個TabPane，每個流程定義會擁有一個單獨的圖形視圖（即一個TabPane），這里的圖形視圖即指當前處于激活（編輯）狀態的畫圖板；很顯然IGraphicalEditor是一個全局類。
• IEditPart代表單個的圖形編輯元素，很顯然，這些元素是和Component組件一致的，IEditPart里最為重要的方法：
function get model():Object;
function set model(_model:Object):void;
Component組件繼承于IEditPart，這樣就瞬間將Component組件與Model關聯起來。IEditPart重要的實現類包括GraphicViewer與GraphicEditPart。
GraphicViewer被SurfaceComponent繼承；
GraphicEditPart被NodeComponent和ConnectionComponent繼承。
2、 Tool
Flex應用程序是基于事件驅動的，用戶對界面的操作即反映到各種鼠標和鍵盤事件上。在原先的設計里，由Component組件自己來處理各種原生事件，當需要其他組件協作時，通過TheModel發出應用定制事件。在GEF的設計里，Component組件的原生事件處理被委派到Tool類進行處理。Component組件只管理自身的圖形渲染和變化。
例如SurfaceComponent處理鼠標點擊事件代碼：
public function mouseClickHandler(event:MouseEvent):void
{
… …
this.tool.mouseClick(event, compX, compY);
}
注意this.tool方法，這個方法同樣是由GraphicViewer和GraphicEditPart分別 引入的。注意有些時候組件的Tool是需要切換的，例如鼠標點擊面板，通常會導致被選中的節點或連接線選中狀態消失，但是當工具條選中一個節點時，這個鼠標事件會導致向面板增加相應的節點。這時需要ToolManager來進行Tool卻換的管理，針對SurfaceComponent/NodeComponent/ConnectionComponent分別有SurfaceToolsManager/NodeToolsManager/ConnectionToolsManager來管理不同的Tool切換策略。需要注意的是ToolManager和Tool都是無狀態的，全局唯一，所有視圖組件共用。
3、 Command
視圖組件的變化會導致Model組件的變化。Tool處理視圖原生事件、調用CommandService執行各個Command具體操作視圖組件和Model對象實現視圖組件和Model組件的變化。
CommandService與SurfaceComponent進行一對一綁定。CommandService持有CommandStack，實現單個Tab編輯界面內Command的redo和undo。
具體操作視圖組件和Model對象必須通過Command。
五、 TheModel全局類的用途
TheModel全局唯一，職責如下：
• 負責應用所有定制事件的訂閱/分發；
• 負責持有工具條和系統菜單屬性；
• 負責持有剪貼板，實現各個畫板之間的節點拷貝/剪切。
六、 ProcessDesigner與ProcessEditor
ProcessDesigner負責整個應用的布局，目前由三部分組成，系統菜單、工具條和TabNavigator（TabBar管理器），TabBar管理器負責添加和刪除Tab，由Tab加載畫板，這樣實現對多流程定義同時編輯的支持（即多Tab）。
ProcessEditor是應用的入口，它持有ProcessDesigner，實現了IGraphicalEditor接口。目前其對graphicViewer（）方法的實現是返回當前激活狀態Tab的畫板。
同時，ProcessEditor負責統一監聽工具條/鍵盤事件，并將這些事件處理委派給當前處于激活狀態的Tab畫板處理。
七、 Xml框架
位于org.jbpmside.xml下，使用E4X，使用binding對各種類型的節點進行解析，不集中在一個文件完成解析和轉換，一個節點類型對應一個binding。使用代碼如下：
public function parse(xml:String):ProcessDefinition{
var parser:Parser=new Parser();
return parser.createParse().setString(xml).
execute().getProcessDefinition() as ProcessDefinition;
}
測試代碼位于test目錄下，是目前唯一可以進行單元測試的部分。
八、 還需要完成的工作
1、 xml框架還需要大量的解析工作完成（以支持jpdl4）
2、 第一個版本為本地應用，需要增加對本地文件操作的支持
3、 模型遷移至org.jbpmside.model.common
4、 工具條使用flexlib重寫，新的16位圖標,節點屬性彈出框
5、 Command目前只實現了對undo的支持，需要實現對redo的支持
posted @
2009-09-20 21:17 ronghao 閱讀(2235) |
評論 (4) |
編輯 收藏