包是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>>包难度很大，并且可能会引入可移植性等问题。