圖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聲明映射為用例包中的用例。用例包生命周期是用例包行為的準確描述，然而它難以正確表達，尤其在復雜的用例中。用例交互圖很容易表達，但它描述的僅僅是由包中用例組成的某一典型場景。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
