一、指导设计思路。在项目早期所建立的高层模型用于集中利益相关者的思路和强调一些重要的选择方案。这些模型描述了系统的需求并代表了整个系统设计工作的起点。早期的模型帮助项目发起者在把精力放在系统的细节问题之前研究项目可能的选择方案。随着设计工作的进展，早期模型被更为精确的模型所替代。没有必要详细保存早期研究过程中的种种选择方案和返工情况。早期模型的目的是帮助获得思路。但最后得到的“思路模型”要在进行详细设计前记录下来。早期模型不需要达到实现阶段的模型的精确程度，无须涉及有关系统实现的一套概念。建立这种模型只使用了UML 定义的组件的一个子
集，比后期的设计阶段的模型使用的组件要少得多。
当早期模型发展到具有一定精度的完整的视图模型时—例如，分析系统需求的模型—那么要在开发过程进入下一阶段时将其保存下来。不断向模型中填加信息的增量式开发（在这种情况下开发的推理过程也要保存和记录）与一般的针对“死端点”进行研究直到得出正确的解决方案的随意漫步式开发之间一个重要的区别。后一种情况通常使人不知怎么着手，并且根本没有必要对整个开发过程进行记录保存，除非遇到特殊情况需要对开发过程进行回溯。

二、系统基本结构的抽象说明。在分析阶段和初步设计阶段所建立的模型以关键概念和最终系统的各种机制为中心。这些模型以某种方式与最终系统匹配。但是模型中丧失了细节信息，在设计过程中必需显式地补充这些信息。使用抽象模型的目的是在处理局部细节问题前纠正系统高层次的普遍问题。通过一个仔细的开发过程，这些模型可以发展成最终模型，该过程保证最终获得的模型能够正确实现初期模型的设计意图。必须具备跟踪能力来跟踪从基本模型到完备模型的过程，否则无法保证最终系统正确包含了基本模型所要表达的关键特性。基本模型强调语义，它们不需要涉及系统实现方面的细节。有时确实会出现这种情况：在低层实现方面的差别会使逻辑语义模糊不清。从基本模型到最后的实现模型的途径必须清晰和简明，不论这个过程由代码生成器自动实现还是由设计者人工实现。
最终系统的详细规格说明。系统实现模型包含能够建造这个系统的足够信息，它不仅要包括系统的逻辑语义和语法、算法、数据结构和确保能正确完成系统功能的机制，而且还要包括系统制品的组织决定，这些制品对个人之间的相互协作和使用辅助工具来说十分必要。这种模型必须包括对模型元素进行打包的组件以便于理解和用计算机进行自动处理。这不是目标应用系统的特性，而是系统构造过程应具有的特性。典型或可能的系统范例。精心挑选的实例可以提高人们的观察能力并使系统的说明和实现有实际效果。然而，即使有非常多的例子，也起不到一段详细定义所起的效果。我们最终希望的是要让模型能够说明一般的情形，这也是程序代码所要做的事情。不过典型的数据结构、交互顺序或对象生命历程的例子对于理解复杂系统很有益处。必须小心使用例子。从逻辑上来说，从一大堆特例中归纳出最一般的情况是不可能的，但是大部分人思考某一问题时总是首先考虑一些被精心挑选出来的有关该问题的例子。范例模型仅是对模型的示例而不带有一般性的描述，因此，人们会觉得这两种模型之间有差异。范例模型一般只使用UML 定义的组件的子集。说明型模型和范例模型在建模中都很有用。
三、对系统全面的或部分的描述。模型可以完全描述一个独立系统，并且不需要参考外部信息。更通常的情况是，模型是用相互区别的、不连续的描述单元组织起来的，每个单元作为整体描述的一部分可以被单独进行存储和操纵。这种模型带有必须与系统其他模型联系在一起的散件。因为这些散件具有相关性和含义，因此它们能够与其他散件通过各种方式结合来构造不同的系统。获得重用是一个好的建模方法的重要目标。
模型要随时间发展变化。深度细化的模型源于较为抽象的模型，具体模型源于逻辑模型。例如，开始阶段建立的模型是整个系统的一个高层视图。随着时间的推进，模型中增加了一些细节内容并引入了一些变化。再随着时间的推进，模型的核心焦点从一个以用户为中心的前端逻辑视图转变成了一个以实现为中心的后端物理视图。随着开发过程的进行和对系统的深入理解，必须在各种层次上反复说明模型以获得更好的理解，用一个单一视角或线性过程理解一个大型系统是不可能的。对模型的形式无所谓“正确和错误”之分 。