統一建模語言（UML）為描述面向對象系統定義了一系列的標準符號。使用UML增強了領域專家、工作流專家、軟件設計者和其他不同背景的專家之間的交流聯系。UML可以在普遍的場合使用，對工作流系統的用戶而言很直觀。除了這些，UML符號具有準確的語義，也就是說可視化的工作流描述可以作為軟件規約。本文側重討論了如何使用UML來描述工作流管理系統，如何跟蹤從業務流程到面向對象軟件設計的描述信息，如何用UML可交互工件來結構化項目知識庫。
在本文中，我們先來討論工作流產品的軟件設計者和用戶對一種通用語言的需要，然后再來介紹如何使用統一建模語言（UML）描述一般的工作流概念，最后希望和搭建一起探討如何把面向對象軟件規約與工作流系統的描述聯系起來。
下面我們先來描述一個企業在實現新工作流管理系統時的通常情形：
顧問與用戶一起描述一個軟件解決方案所支持的企業業務流程。開發隊伍獲得顧問的描述，但是他們很難理解業務術語，發現其中描述了太多的信息以至于難以用來實現此系統。開發者從技術觀點來撰寫系統規約，當把這個系統規約呈現在用戶面前時，由于過于專業，以至于用戶難以理解。然而為了進行下一步的工作，雙方被迫接受了這個系統規約。
這種方式很容易導致系統無法達到用戶的需求。用戶、顧問和開發者通常都不是用同樣的語言，這樣的交流問題導致難以保證業務流程所有部分很好溝通，并轉換為技術性的軟件規約。另外，因為使用此系統的實際用戶很難全部理解技術性的系統規約，使軟件系統變得難以使用。
其挑戰性在于能用一種既準確又友好的方法來為業務流程和業務系統建模。用來描述業務流程的每一個符號對用戶來說很直觀，并有確定的語義，因此開發者可以用它作為一般的描述，甚至用來精確的描述軟件系統規約。
UML有著豐富和復雜的符號來描述軟件系統。這些符號也許太豐富以至于不直觀、不友好。然而，恰當地用UML來描述工作流管理系統有兩大好處。首先，UML是軟件界公認的符號標準；第二，UML也可用在不需要實現細節的一般場合。在顯示的UML圖與那些領域專家已經在使用的圖在直觀上很相近，另外，它們的語義有精確的定義。如有必要，可出于軟件設計的目的給同樣的圖增加詳細的實現細節。
業務系統的描述由流程和靜態結構的描述組成。流程最直觀的模型就是一個活動或任務的序列，按照順序完成以到達某個目標。因此，UML的序列圖和活動圖很適用于友好、準確、詳細地描述業務流程，如組織圖之類的靜態結構，沒有實現細節，可以用UML的靜態結構圖描述。圖形化的實現細節往往會誤導那些不精通UML的人。例如，導航箭頭經常錯誤地表示方向，最好是僅用UML表示選項的某一特定子集。例如，把元素互相嵌套來表示組裝比用實心菱形表示關聯要好。用文字來描述各種屬性，而不用UML符號，例如《refine》就比帶三角形的虛線好理解得多。
工作流概念映射到UML概念
這里介紹了用UML來描述工作流概念的例子。這僅僅提供了一個一般的指導，如何把工作流概念映像成UML，詳細的細節很容易從UML的語義和符號指南[7]得到。工作流管理系統的每個結構都能用合適構造型的UML符號來描述。
圖1 用UML表示業務對象、業務流程、團隊角色
圖1顯示了用UML描述業務流程、業務對象、團隊角色。業務對象在UML中用類和對象表示。類描述沒有特性（identity）的業務對象，如發票(invoice)；對象描述有特性的業務對象，比如編號為VM4/55的發票(VM 4/55: invoice)。業務流程1用用例和用例實例來描述，用例根據目標、職責、前置條件和后置條件來描述；用例對象是具體的事件序列。工作流是自動化的業務流程，用帶有構造型 <
假設業務流程是在業務系統中的業務對象、角色和其他的實例之間協作完成的。請參看詳細介紹“跟蹤業務流程到軟件設計”。
圖2 UML的靜態結構圖描述團隊結構
圖2顯示了一個團隊結構的例子。團隊的角色用對象實例表示，為每個角色指定了雇員數量。一個客戶滿意團隊（Customer Satisfaction Team）有三個開發員、兩個測試員、一個產品經理和一個人擔任用戶角色。角色組叫做客戶滿意團隊（Customer Satisfaction Team），用包符號表示。角色組也可能被表示成對象——作為角色的組裝（composition）。如果團隊表示為對象，團隊和角色之間的關系為組裝關系，那么根據UML元模型概念，一個特定的角色實例不能同時屬于多于一個團隊。如果團隊表示為包，特定的角色實例可以同時屬于幾個團隊。
圖3 UML序列圖描述業務流程的實例
圖3描述了業務流程的實例。角色客戶(customer) 下了一份定單，然后銷售(sales)部門中的某個工人確認此定單。如果定單有效，此工人調用另一業務流程“公司運輸物品（company ships an item）”的實例。這個類型的圖在UML表示法指南中沒有明確的提到，然而，它符合UML的元模型。在對象生命線頂部的符號代表分類器角色，如圖3中的角色、對象角色和用例角色。
圖4 UML用例圖描述業務流程之間的靜態關系
圖4是UML用例圖，描述了業務流程之間的靜態關系。業務流程描述組織(organization)與角色客戶（customer）的協作。注意在UML的1.1版本中，用例不能相互聯系而總是由角色發送信號觸發。這給建模環境帶來困難，一個用例在運行期間，當特殊條件出現時，另一個用例也開始啟動。在這種情況下，角色通過與另一個用例的聯系初始化此用例而不需發出任何特定的開始信號。例如，如果客戶的請求被評估為有效，用例公司運輸物品（company ships an item）被組織中的對象觸發。這個用例實例不直接由客戶觸發，希望下一版本的UML將減少用例間有關聯系的限制。
UML用例圖不容易表達出用例實例的順序，例如，首先客戶請求一項物品，然后公司將傳送此物品，最后客戶付款。一個解決的方法就是在用例間使用約束{precedes}或依賴關系 <
圖5 UML序列圖描述業務流程和執行者（Actor）之間的交互
角色可以通過特殊順序啟動用例的方法來使用系統。像這樣的場景——用例實例序列——可以用順序圖或協作圖描述，參看圖5和圖6。對照對象交互圖，場景被描述為消息序列，用例交互圖把場景描述為用例序列。這個圖僅僅是由其他場景的實例組成的一個場景的UML圖。在圖5中消息調用（invoke）表示用例構造器和映射為從角色到用例的信號。根據每個用例的最開始操作，如調用請求（invoke request）, 調用運輸（invoke shipment）和調用付款（invoke payment），可以命名這些消息，除了這些消息之外，用例交互圖能表示角色與系統間其他消息的交互，并描述了用例與角色的全部交談。
圖6 UML交互圖描述業務流程和角色之間的交互和關系
用例協作圖也描述業務流程實例組成的一個場景。不象用例序列圖，用例協作圖描述用例實例和角色實例之間的用例關系和消息交互。用例協作圖如圖6所示。
圖7 UML活動圖描述業務流程的允許的順序
用例交互圖描述的僅僅是由用例實例組成的一種典型場景。因此它不能表達用例實例所有允許的順序，屬于用例包的用例實例所允許的順序可以在用例包生命周期內詳細說明。用例包的生命周期可用靜態圖、Backus-Naur范式（BNF）(請參看[4]如何使用BNF指定生命周期。)的活動圖表示，在這些狀態中，活動狀態或BNF聲明映射為用例包中的用例。用例包生命周期是用例包行為的準確描述，然而它難以正確表達，尤其在復雜的用例中。用例交互圖很容易表達，但它描述的僅僅是由包中用例組成的某一典型場景。
圖7是UML活動圖，描述了用例包訂單管理（order management）的生命周期。在活動圖中的活動與圖4、5、6中的用例相對應。
注意UML元模型沒有定義任何從狀態或行為狀態到用例實例的映射，這種映射可以在開發過程進行，與Martin和Odell方法相似，其中子系統的每個狀態都指明子系統中的一個候選類。參考[5]。然后，其他開發過程可能以其它方式定義用例包生命周期。例如，用例包生命周期的目的在用例包的范圍內可被指定為子系統接口操作允許的順序。
| 共2頁: 1 [2] 下一頁 |