圖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）僅僅描述了那些分類器是對象的交互圖，并不描述那些分類器是用例、子系統、節點或組件的交互圖。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
