抽象是一种依赖关系，它将两个命名元素或一组命名元素联系起来，这些命名元素代表同一概念，但处于不同的抽象层次或来自不同的观点。

由于抽象是依赖关系，它通常被定义为客户和供应商之间的关系，其中客户（源的子集）依赖于供应商（目标的子集）。将抽象关系中更抽象的元素视为供应商，这与常见的 OOAD 约定相对应。尽管如此，uml modeler可能会决定，对于某些特定的领域或任务，让一个更抽象的供应商元素依赖于更具体的客户元素更合适。

抽象允许供应商和客户之间的映射是正式的或非正式的，以及单向的或双向的，这取决于抽象的特定子类或原型。例如，派生可以是正式的和单向的，而跟踪可以是非正式的和双向的。

如果一个抽象有多个客户端，那么供应商作为一个组映射到一组客户端中。例如，一个分析级类可以作为一个或多个设计级类的抽象。用例可以是几个协作的抽象。

抽象语法

抽象有两个子类——实现和表示。显示用关键字《manifest》标记，并在部署图中使用。

抽象是一种依赖，它是由实现和表现子类化的，
并且有标准的原型 <<Derive>>, <<Refine>>,<<Trace>>

抽象也很少有标准的原型-<<Derive>>, <<Refine>>,<<Trace>>定义在标准配置文件中。

符号

抽象关系以依赖关系箭头的形式显示，从尾部的客户端到箭头处的供应商，带有<<abstract>>关键字或其他一些预定义的原型名称。

例如，一个分析级别的类Customer (supplier，目标的子集)可能被实现为设计级别的类CustomerInfo (client，源的子集)。

Domain的Customer是DataTransfer的CustomerInfo的抽象。
（通用约定示例-作为供应商的更抽象元素。）

如果某些UML建模者决定最好显示一个依赖于更具体元素的抽象元素，则该关系将被逆转。

Domain的Customer是DataTransfer的CustomerInfo的抽象。
（反符号示例-不太抽象的元素作为供应商。）

派生-<<Derive>>

<<<Derive>>是一个标准的抽象原型，用于指定模型元素之间的派生关系，这些元素通常（但不一定）属于同一类型。这个派生在UML中定义为“客户可以从供应商处计算”。拥有这种“计算客户端”的原因可能是实现效率。抽象关系的映射指定了计算。

派生关系与派生属性相关，派生属性的值由其他信息生成或计算，例如，使用其他属性的值。

如果某些UML建模者决定最好显示一个依赖于更具体元素的抽象元素，则该关系将被逆转。

Age类源自BirthDate类。

修订版

从UML 1.3开始，“派生”关系的定义没有改变。与其他原型一样，直到小写UML 2.4.1“ derive”为止。

精化<<Refine>>

“refine”是一个标准的抽象原型，用于指定不同语义级别（如分析、设计和实现）的模型元素之间的精化关系。它可以用来对从分析到设计、从设计到实现的转换进行建模。抽象映射可以是可计算的，也可以不是可计算的，它可以是单向的，也可以是双向的。

模型之间可以有精化依赖关系，通常由模型中包含的元素之间的依赖关系表示。

设计模型中的客户类从分析模型中提炼出客户类。

修订版

UML 1.4.2词汇表的细化定义为：

一种关系，表示已在某种详细程度下指定的某些东西的完整说明。例如，设计类是对分析类的改进。

与其他构造型一样，直到UML 2.4.1<< refine>>使用小写形式。

跟踪<<Trace>>

Trace是一个标准的抽象原型，主要用于跟踪不同模型中表示相同概念的元素或元素集的需求和跨模型的变更。因此，跟踪是“模型间”的关系。

模型之间的这些跟踪/映射依赖关系通常由模型中包含的元素之间的依赖关系表示。

以下是使用Trace的一些例子:

• 用例模型中的用例可以跟踪到相应设计模型中的协作或包。
• 设计模型中的接口和类可以跟踪到实现模型中的组件。
• 实现模型中的组件可能会跟踪到部署模型中的工件。但在这种情况下，另一种选择是使用专门的表现关系。

在用例模型跟踪中提取现金用例在设计模型中提取现金协作。

跟踪的方向(即客户和供应商的指定)由建模者决定，并且由于模型变化可以在两个方向上发生，依赖的方向通常可以被忽略。映射指定了两者之间的关系，但它很少是可计算的，通常是非正式的。

修订

在UML 1.4.2中，“跟踪”的定义与当前版本几乎相同，而跟踪的词汇表定义是：

一种依赖关系，表示两个元素之间的历史或过程关系，这两个元素表示同一概念，但没有从另一个元素派生出一个概念的特定规则。

与其他原型一样，直到UML2.4.1“trace”是小写的。