模型包含两个主要方面：语义方面的信息（语义）和可视化的表达方法（表示法）。
语义方面用一套逻辑组件表达应用系统的含义，如类、关联、状态、用例和消息。语义模型元素携带了模型的含义即，它们表达了语义。语义建模元素用于代码生成、有效性验证、复杂度的度量等，其可视化的外观与大多数处理模型的工具无关。语义信息通常被称作模型。
一个语义模型具有一个词法结构、一套高度形式化的规则和动态执行结构。这些方面通常分别加以描述（定义UML 的文献即如此），但它们紧密相关，并且是同一模型的一部分。可视化的表达方式以可使人观察、浏览和编辑的形式展示语义信息。表示方式元素携带了模型的可视化表达方式，即语义是用一种可被人直接理解的方式来表达的。它们并未增添新的语义，但用一种有用的方式对表达式加以组织，以强调模型的的排例。因此它们对模型的理解起指导作用。表达式元素的语义来自于语义模型元素。但是，由于是由人来绘制模型图，所以表达式元素并不是完全来自于模型的逻辑元素。表达式元素的排列可能会表达出语义关系的另外含义，这些语义关系很不明显或模棱两可，以至于在模型中不能形式化地表达，但可给人启迪模。
上下文（语境）。模型自身是一个计算机系统的制品，被应用在一个给出了模型含义的大型语境中。这个包括模型的内部组织、整个开发过程中对每个模型的注释说明、一个缺省值集合、创建和操纵模型的假定条件以及模型与其所处环境之间的关系。模型需要有内部组织，允许多个工作小组同时使用某个模型而不发生过多的相互牵涉。这种对模型的分解并不是语义方面所要求的—与一个被分解成意义前后连贯的多个包的模型相比，一个大的单块结构的模型所表达的信息可能会同样精确，因为组织单元的边界确定会使准确定义语义的工作复杂化，故这种单块模型表达的信息可能比包结构的模型表达得更精确。但是要想有效地工作于一个大的单块模型上的多个工作组不彼此相互妨害是不可能的。其次，单块模型没有适用于其他情况的可重用的单元。最后，对大模型的某些修改往往会引起意想不到的后果。如果模型被适当分解成具有良好接口的小的子系统，那么对其中一个小的、独立的单元所进行的修改所造成的后果可以跟踪确定。不管怎样，将大系统分解成由精心挑选的单元所构成的层次组织结构，是人类千百年来所发明的设计大系统的方法中最可靠的方法。
模型捕获一个应用系统的语义信息，但还需记录模型自身开发过程中的各种信息，如某个类的设计者、过程的调试状态和对各类人员的使用权限的规定。这些信息至多是系统语义的外围信息，但对开发过程非常重要。因此，建立一个系统的模型必须综合考虑两方面。最简便的实现方法是将项目管理信息作为注释加入到语义模型中—，即可以对模型元素用非建模语言进行任意描述。在UML 中用文本字符串来表示注释。文本编辑器或浏览器所使用的命令不是程序设计语言的一部分，同样，用于创建和修改模型的命令也不是建模语言语义的一部分。模型元素的属性没有缺省值，在一个特定的模型中，它们均具有值。然而，对于实际的开发过程，人们要求建立与修改模型时无须详细说明有关的所有细节。缺省值存在于建模语言和支持这种语言的建模工具的边界处。在建模工具所使用的创建模型的命令中，它们是真正的缺省值，尽管它们可能会超过单个的建模工具并用户所期望的那样成为建模工具所使用的通用语言。
模型不是被孤立地建造和使用的。它们是模型所处的大环境中的一部分，这个大环境包括建模工具、建模语言和语言编译器、操作系统、计算机网络环境、系统具体实现方面的限制条件等等。系统信息应该包括环境所有方面的信息。系统信息的一部分应被保存在模型中，即使这些信息不是语义信息，例如项目管理注释（在上面已经讨论过）、代码生成提示、模型的打包、编辑工具缺省命令的设置。其他方面的信息应分别保存，如程序源代码和操作系统配置命令。即使是模型中的信息，对这些信息的解释也可以位于多个不同地方，包括建模语言、建模工具、代码生成器、编译器或命令语言等等。本书用UML 自身对模型进行解释。但是当进行系统的具体物理实现时，要用到其他用于解释的资源，这些资源对UML 来说是不可见的。