为了完整地说明一个系统，有必要采用多种模型。需求规格说明以叙述性的用户需求作为输入，构造出规格说明模型作为输出。
需求规格说明涉及对需求确定期间定义的客户需求进行严格的建模，重点放在那些系统将要提供的所期望的服务（功能性需求）上。软件体系结构定义了系统中相互作用的软件构件及子系统的结构和组织形式。模式—视图—控制器（MVC）框架支持大多数现代体系结构框架及相关模式，模型对象表示数据对象——应用问题域中的业务实体和业务规则。MVC几乎是所有现代框架的骨架，后来进一步扩展到企业和电子商务系通过。对象的状态由它的属性值和关联决定。因为对象状态是由数据结构确定，所以数据结构模型就称为状态规格说明书。类模型是面向对象系统开发的基础，类建立了一个基础，在这个基础上，系统的状态和行为才是可见的。关联连接着系统中的对象，它们使对象间的协作变得更容易。聚合及其更强的形式——复合，表示复合类和一个构建类之间的“整体—部分”语义。泛华关系是一个或多个类的公共特征（属性和操作）可以抽象到一个更一般化的类中，将一般类与特殊类连接起来。接口虽然没有实现，但却提供了某些最强大的建模能力，接口没有属性、关联或状态，所有操作都隐含是公共的和抽象的。建模涉及系统的定义，模型不是一个可执行系统，不显示实例对象。
行为规格说明提供系统的操作视图，主要任务是定义应用领域中的用例，并确定在这些用例的执行中将涉及哪些类，标志类操作和对象之间的消息传递。一个用例表示：一个完整的功能，一个外部可见的功能，一个正交功能，由一个参与者启动的一个功能，给参与者传递确切值的一个功能。活动模型广泛地应用于设计中。顺序图和通信图是两种交互图，它们展现了对象之间为完成一个用例、一项活动、一个操作或其他行为构件所需的交互模式。类将一组操作作为服务提供给系统中的其他类，这组操作就确定了类的公共接口。状态图是表示状态及状态转换的图，可以为每个具有令人感兴趣的动态行为的类建立状态模型，但并不是类图中所有的类都属于这个范畴。
软件开发的实际情况要复杂得多，复杂的问题不会有简单的解决方案，对象为构造当前的复杂系统提供了一种流行技术。我们所讨论的分析建模概念足以产生完整的分析模型，但这些模型处于一个较高的抽象层次上，没有对分析建模阶段允许的所有可能的细节进行详尽的描述。在使用UML时，有超出其固有能力的需求，为了这个目的，UML标准提供了扩展机制，如构造型、约束、标签定义和标签值。可见性的概念和相对的封装思想在附录有关类内部的可见性，类属性和操作的整套可见性标志是：公共可见性、私有可见性、保护可见性、包可见性。导出信息是一种应用于属性或关联的约束，导出信息在模型中是冗余的。限定关系是在二元关联的一端，有一个属性框，框中包含一个或多个属性，这些属性可以作为一个索引码，用于穿越从被限定的源类到关联另一端的目标类的关联，有些人喜欢，有些人不喜欢。类之间的关系有：关联、聚合、泛化。泛化引入了额外的类，并将它们分为一般类和较特殊的类，在模型中建立超类—子类关系。封装要求只能通过对象接口中的操作才能访问对象的状态（属性值），封装与继承和查询能力是正交的，他不得不与这两个特性一起折中考率。当以可替换性为目标来使用泛化时，他就同接口继承概念是同一词了。聚合是一种包含关系。一个复合类包含一个或多个构件类，构件类是其复合类的元素。现在的程序设计环境普遍忽视聚合，在这种情况下，虽然对象应用开发方法将聚合结合进来作为一个建模选择，但却很少重视它。泛化是超类—子类的关系，聚合更接近超集—子集的关系。聚合提供了关注点的分离—允许每个类保持封装，他关注类的特定行为，使其不受父类实现的约束。
