對象級（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概念的方法，并建議結構化設計工件，從而跟蹤業務流程的定義和面向對象軟件設計之間的信息。此結構展示了業務流程可表示為業務對象、團隊角色和業務系統中其它實例的協作，此結構基于四種相關的設計工件的模式，這四種設計工件為分類器關系、交互、職責和生命周期。此模式可以應用于一個業務系統的不同抽象級和不同的視圖，也可應用于業務和軟件系統設計的其它方面。
