包是UML模型的組織結構，也是UML項目的配置管理結構。包存在多個層級，除了頂層包，所有包隸屬於一個且僅隸屬於一個上層包。在項目不同階段實際推進與配置過程中，通常以不同層級的包為單位進行check-in、check-out、打標籤及建立基準。許多項目會在計劃的時間點進行正式的官方評審，例如系統需求評審（SRR）、系統設計評審（SDR）、初步設計評審（PDR）、關鍵設計評審（CDR）或測試準備評審（TRR）。在這些活動就是對保存在不同包中的階段性模型進行評審，並對其建立基準，以便項目可以輸出階段性成果併為下一階段建立輸入，必要時可以回顧與審查該基準。
如果以建模類型而論，存在概念化、需求分析、分析、設計等模型，使用這些模型時，可根據項目的方法論進行調整。在這些不同類型的模型中，由於是對同一事物的建模，必然存在一些相同名稱的元素，但是模型作為包，也是命名空間，因此不同模型中使用相同名稱的元素，這不會帶來問題。而從元素本身所描述對象的角度來説，在不同模型中使用相同名稱也是合理的。
在實際工作中，很多人在使用UML建模時對各模型或圖表的前後邏輯關係感到困惑，或者只是單純地堆砌各類圖表，其最可能的根本原因是所採用的項目方法論中缺少不同階段建模要求。通常當我們構建一個系統時，要對這個系統建模，形成“系統模型”。在最簡單的情況下，系統建模至少要先建立“分析模型”，然後根據分析模型建立“設計模型”，分析模型與設計模型（及其他模型）共同構成系統模型。
可以為包指定版型（構造型）«model»表明當前包是一個模型，系統模型與分析模型、設計模型的關係可用下圖表示：

包的版型（構造型）除«model»外，其他可用的版型（構造型）簡述如下：

• «ModelLibrary»
  版型（構造型）“«ModelLibrary»”表示其大部分內容被其他包或模型使用。通常，我們使用«ModelLibrary»包來包含系統中其他包可以使用的公共類型、單元、實用工具或其他內容。«ModelLibrary»包應被標記為公開可見，並可能將其“導入”到頂級包中——這將確保«ModelLibrary»包被系統中所有包可見且可訪問。
• «Framework»
  類似於«ModelLibrary»包，版型（構造型）為“«Framework»”的包包含了許多共享的基礎設施和架構元素。«Framework»包通常包括事件和錯誤處理程序、消息傳遞、日誌記錄、自檢、內置測試、診斷和安全執行等內容。
• «Profiles»
  形式上«Profiles»包與標準包類似，只是具有«Profiles»的版型（構造型），但«Profiles»包通常包含適合於幫助執行項目方法論或制度的“元類”。我們可以在«Profiles»包中創建、刪除元類或版型（構造型），在項目實際操作中通常只允許一人對«Profiles»包進行修改，當然，«Profiles»包必須對項目中的所有人可見。一般情況下，創建«Profiles»包難度很大，並且可能會引入可移植性等問題。