統一建模語言（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用用例和用例實例來描述，用例根據目標、職責、前置條件和后置條件來描述；用例對象是具體的事件序列。工作流是自動化的業務流程，用帶有構造型 <<workflow>> 的用例或用例實例描述。在UML中用類和對象描述團隊角色（team roles），用類來描述團隊角色的類型，對象描述擔任該角色的具體工人（worker）。所有的符號可以用相應的構造型來修飾，如 <<business object>>、<<business process>>和<<team role>> 。每一個構造型都可以用文字或一個特定的圖標表示。

　　假設業務流程是在業務系統中的業務對象、角色和其他的實例之間協作完成的。請參看詳細介紹“跟蹤業務流程到軟件設計”。


圖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}或依賴關系 <<precedes>> 。類似的關系同樣存在于OML（OPEN modeling language），參看[3]，Robert C. Martin建議使用關鍵字follows替代precedes，參看[6]。這樣替代的原因是依賴關系 <<follows>>與依賴關系<<preceds>>的指向相反，依賴關系<<follows>> 指向通常的依賴方向——從依賴元素指向獨立元素，至于哪一個更直觀仍是個未解決的問題。然而，帶約束或依賴的圖仍然是靜態結構圖，并不描述特定場景。


圖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]。然后，其他開發過程可能以其它方式定義用例包生命周期。例如，用例包生命周期的目的在用例包的范圍內可被指定為子系統接口操作允許的順序。

　　用例交互模型和用例生命周期還有一個顯著的區別——它們在項目知識庫中的位置不同，并且與其它設計工件的關系不同。工件用例交互模型與工件用例模型相關，工件用例包生命周期與工件用例包相關，后者的抽象級別比相對應的用例模型和用例交互模型高。


圖8 在項目知識庫里的用例視圖中工件之間的關系。

　　符號用UML表示，為了更加清楚，依賴關系用role ends3表示。

項目知識庫的結構化

　　在開發流程中，軟件構架師、設計者和開發者確認軟件產品的某些信息，如用例、軟件構架、對象協作和類描述。這些信息可能十分抽象，如產品前景，也可能非常具體，如源代碼。在本文中，我們把這些信息叫作軟件產品設計工件（design artifacts）。

　　我們必須認識到設計工件與它的表達之間的區別：設計工件決定業務系統的信息，而表達決定如何把這些信息表示出來。有些設計工件用UML表示，有些用文字或表格表示，例如，類的生命周期可以用UML狀態圖、活動圖、狀態轉移表或Backus-Naur范式表示。類庫用文字來表示。

　　工作流管理系統的規格說明是定義在精確定義的設計工件基礎上的，而不是在圖上。這一節和下一節將討論設計工件的結構，此結構可以明確業務流程、業務規則、軟件構架和業務系統設計之間的關系，并且很容易擴展到覆蓋業務系統的其他方面，如團隊結構和項目計劃。

　　業務系統可被描述為多級的抽象和多種視圖。多級的抽象如組織級、系統級、構架級、類級；多種視圖如邏輯視圖、用例視圖、分析視圖、測試視圖或文檔視圖。在抽象的每一級和在每一視圖里，軟件產品可以用四個設計工件來描述：分類器之間的靜態關系、分類器之間的動態交互、分類器職責和分類器生命周期。每個工件可用UML圖或文字來表示。如圖9和圖10。


圖9 結構化項目知識庫的設計工件模式


圖10 在每一抽象級的每一視圖中，都可以用四種設計工件描述軟件產品。

　　UML分類器是：類、接口、用例、節點、子系統和組件。

　　分類器模型(classifier model)指定了分類器之間的靜態關系。分類器模型可以是一組靜態結構圖（如果分類器是子系統，類或接口），可以是一組用例圖（如果分類器是用例和執行者），可以是一組部署圖（如果分類器是節點），還可以是一組組件圖（如果分類器是組件）。

　　分類器交互模型（classifier interaction model）指定了分類器之間的交互。分類器交互模型可以用交互圖表示：序列圖或協作圖。UML表示指南（UML Notation Guide）僅僅描述了那些分類器是對象的交互圖，并不描述那些分類器是用例、子系統、節點或組件的交互圖。

　　設計工件叫做分類器（classifier），指定了分類器的職責、角色和分類器接口的靜態屬性（例如，分類器的操作表，有前置條件和后置條件）。分類器還可以用結構化的文字表示，如CRC卡。

　　分類器生命周期（classifier lifecycle）指定了分類器狀態機和分類器接口的動態屬性（例如所允許的有順序的操作和事件）。分類器生命周期可以用狀態圖、活動圖和狀態轉移表來表示。

　　可以把分類器模型的一個實例鏈接到分類器交互模型的幾個實例上，所有這些實例都鏈接到分類器的實例上，分類器的實例鏈接到分類器生命周期的實例上。
跟蹤業務流程到軟件設計

　　在結構良好的設計文檔中，有關業務流程和軟件產品的信息可以很容易定位，并且相關信息鏈接在一起，同時結構還體現了不同設計工件的完整性和一致性，它是業務專家、顧問和軟件開發者溝通的基礎。此結構還提供了明顯的關注點，由業務人員而不是開發者定義所有的業務規則。這一節討論業務流程和軟件設計工件之間的關系，用它把項目知識庫結構化，給出了把業務流程的以及它們與軟件設計工件的關系的構造信息。參看[4]獲得知識庫結構化的具體實例。

　　結構是基于業務系統中業務對象、角色、工人協作的業務流程（在UML中用用例表示）。業務流程（用例）定義為協作類型，指明了協作職責、目標、前置條件、后置條件和協作中調用的系統操作。業務流程實例（用例實例）為協作實例，指明了在協作中的行為和事件、系統狀態和狀態轉移的具體順序。


圖11 設計工件在邏輯和業務流程視圖中描述了軟件系統

　　圖11指明了業務流程的設計工件和軟件系統的邏輯設計之間的關系，工件是按照不同的抽象級別組織起來的：組織級、系統級、構架級和對象級

　　組織級（organization level）指定了一個組織（如公司、學校和政府機關）的職責，以及該組織的業務環境。工件組織（organization）指定了組織的職責和相關的靜態屬性。工件組織模型（organization model）指定了組織與其他組織之間的關系。工件組織用例（organization use case）用流程目標、前置條件、后置條件和業務流程必須符合與其相關的靜態屬性的業務規則來指定組織范圍的業務流程。這個業務流程是組織與其他組織之間的協作，這種協作是在工件組織用例模型（organization use model）中指定的，見圖11中的依賴關系協作。組織業務流程的實例是由組織交互模型（organization interaction model）用組織與其他組織間的交互來指定的。組織業務流程可以精化到更具體的系統業務流程，見圖11中的依賴關系精化。工件組織用例生命周期（organization use case life cycle）指定了所允許的系統業務流程。組織用例交互模型（organization use case interaction model）指定了典型的業務流程實例序列，見圖11中的實例依賴關系。組織業務流程的實現用軟件系統和它的用戶（團隊角色）之間的交互來指定，見圖11和12中實現依賴關系。

　　系統級（system level）指定了軟件系統的環境以及與它的角色之間的關系。工件系統（system）用職責、前置條件、后置條件、參數和返回值來指明系統的接口和操作。若角色職責和接口是相關的，并由工件角色（actor）指定。系統生命周期（system lifecycle）指定了所允許的系統操作和事件。系統模型（system model）指定了軟件系統和角色（其他系統和用戶）之間的關系，系統交互模型（system interaction model）指定了軟件系統和角色之間的交互。這些交互是系統業務流程的實例，見圖11中依賴關系實例。工件系統用例（system use case）用流程的目標、前置條件、后置條件、非功能性需求、業務規則和其他相關靜態屬性指定了在系統范圍內的業務流程。這個業務流程是系統與其它系統或用戶的協作。

　　這些系統與它的角色之間的協作是在工件系統用例模型（system use case model）中描述的，見圖11中的依賴關系協作。業務流程接口的動態屬性，如在業務流程范圍內所允許的系統操作順序，是在系統用例生命周期（system use case life cycle）中指定的。系統用例交互模型（system use case interaction model）指定了典型的業務流程實例的序列。系統業務流程可以精化到子系統業務流程中，見圖11中的依賴關系精化。系統業務流程的實現用構架級的子系統間的交互來指定，見圖11中的依賴關系實現。

　　構架級（architectual level）定義了子系統（組件）、子系統的職責、接口、關系和交互。工件子系統（subsystem）職責、前置條件、后置條件、參數和返回值指定了子系統接口和子系統操作。子系統生命周期（subsystem lifecycle）指定了所允許的子系統的操作和事件的順序。子系統模型（subsystem model）指定了子系統和其他子系統之間的關系，子系統交互模型（subsystem interaction model）指定了子系統之間的交互，這些交互是子系統業務流程的實例，見圖11中依賴關系<<實例>>。工件子系統用例（subsystem use case）指定了在子系統范圍內的業務流程，這個業務流程是子系統與其它子系統、系統和用戶之間的協作。子系統和它的角色之間的所有協作是在系統用例模型（system use case）中描述的，見圖11中的依賴關系<<協作>>。子系統業務流程接口的動態特性，如在業務流程范圍里所允許的子系統操作順序是在子系統用例生命周期（subsystem use case life cycle）中指定的。子系統用例交互模型（subsystem use case interaction model）指定了業務流程實例的典型序列。子系統業務流程的實現用類級別上對象之間的交互來描述，見圖11中的依賴關系<<實現>>。

　　對象級（object level）用業務對象、業務對象的職責、關系和交互來描述子系統的設計。業務對象模型（business object model）指定業務對象之間的靜態關系。業務對象交互模型（business object interaction model）用業務對象之間的交互指定子系統操作的設計。工件業務對象（business object）指定業務對象的職責和業務對象接口的靜態屬性，如用前置條件和后置條件描述的接口操作。業務對象生命周期（business object lifecycle）指定了所允許的接口操作順序。

　　圖12中，設計工件描述了組織團隊結構。事實上，它與描述軟件子系統結構的工件沒有什么太大的區別。團隊的角色可以表示成UML構造型的類，工件角色（role）指定工人角色的職責及其它相關的靜態屬性。工件角色生命周期（role lifecycle）指定了角色的動態屬性、它們的狀態以及它們所響應的事件。工件角色模型（role model）指定角色之間的靜態關系。成員級業務流程（member level business process）指定團隊成員角色與其它團隊成員角色之間的協作，見圖12中的依賴關系<<協作>>。這些業務流程的實例是在工件角色交互模型（role interaction model）用角色實例之間的交互指定的，見圖12中的依賴關系<<實例>>。


圖12 在團隊和業務流程視圖中，設計工件描述了軟件系統

　　稱為團隊（team）的設計工件是一個角色包，指明了團隊的職責以及相關的靜態屬性。團隊的動態屬性是在工件團隊生命周期（team life cycle）中指定的。工件團隊模型（team model）指定了團隊之間的靜態關系。團隊級業務流程（team level business process）指定了團隊和其它團隊之間的協作，見圖12中的依賴關系<<協作>>。團隊級業務流程的實例是在團隊交互模型（team interaction level）中指定的，見圖12中的依賴關系<<實例>>。團隊級業務流程的實現用團隊成員之間的交互以及團隊成員與軟件系統之間的交互來指定，如圖12中的依賴關系<<實現>>。設計工件的模式可以用相似的方法應用在更高的抽象級4上。

　　這一節描述的設計工件的結構可以通過兩種方式簡化：

　　· 只使用設計工件的子集；
　　· 把緊密相關的一些設計工件結合起來，構成更大的設計工件單元。

　　使用設計工件的子集不會導致信息的丟失，因為UML圖系統不是正交的。意思是同樣的信息可以用兩個或更多不同的UML圖來描述。例如，兩個靜態結構圖和對象協作圖描述對象之間的關系。兩個狀態圖和交互圖描述對象之間的消息。因為同樣的信息可以從幾個方位來描述，開發者所提供的僅僅是設計工件的特定子集，否則此工件必須接受關于一致性的檢查。

　　由于實際的原因，設計者可以創建一個更大的可交互工件來包含幾個緊密相關的工件。例如，分類器職責和生命周期總是與某一文檔相關和結合。也可以把組織、系統、子系統和類用例圖結合成一個大用例圖，以清晰地區別用例級。同樣的，系統、子系統和業務對象靜態結構和相對應的所有級別里的交互圖可以結合成一個文檔，也可用UML語義把靜態結構圖、組件、節點和每一級的用例圖結合起來表示。用這種方法，設計者可以在一個大的靜態結構圖中表達用例、角色、子系統、業務對象、團隊成員和業務流程之間的關系，然而“UML表示法指南”沒有清楚地提到這樣結合的靜態結構圖。

　　小 結

　　本文討論了用UML表示面向對象工作流管理系統，給出了如何把典型工作流概念映射到UML概念的方法，并建議結構化設計工件，從而跟蹤業務流程的定義和面向對象軟件設計之間的信息。此結構展示了業務流程可表示為業務對象、團隊角色和業務系統中其它實例的協作，此結構基于四種相關的設計工件的模式，這四種設計工件為分類器關系、交互、職責和生命周期。此模式可以應用于一個業務系統的不同抽象級和不同的視圖，也可應用于業務和軟件系統設計的其它方面