刻板印象“抽象”不存在——抽象类应该使用斜体来描述。抽象意味着一个类不能被实例化。它需要一个子类来做到这一点。因此，作为伪代码约束，这意味着
for all instances i of MyAbstractClass holds: i.actualClass != MyAbstractClass
或在 ocl 为 MyAbstractClass 持有
self.allInstances()->forAll(i: MyAbstractClass | i.classifier <> self)
由于“抽象”一词未在您的第一个问题版本中显示，因此我总体上扩展了刻板印象：
首先：在学习 UML 时，刻板印象不应该是你首先考虑的事情。它们相当复杂。
刻板印象或关键字（均用 表示<<MyStereotype>>）没有一般含义。它由特定的构造型定义。通常，您不能将构造型表达为不变量。
但是 UML 的其他一些方面可以用相同的方式显示：来自 UML 元级别的类<<metaclass>>即使没有构造型甚至是不同的实际类型，也被标记为 。构造型本身用<<stereotype>>标记显示（即使它们是特殊类的实例）。
自定义构造型的一个示例可能是“服务”。您可以用它标记代表服务的类。可能有一个约束告诉您“服务”必须实现一个特殊的接口。在这种情况下，您可以将此约束表示为（无聊的）不变量。但可能它甚至只是一个标记。在后一种情况下，您可以使用关键字作为替换。
我意识到这个线程已经有几年的历史了，但是当它被其他人引用时我来到了它，因为它«abstract»支持了 UML 规范不支持构造型的断言。这种说法不太准确，我想解释一下原因。我将首先阐明什么是抽象类。
抽象类是不包括完整实现的类的定义。因此，抽象类不能直接实例化；它们必须是专门化的（继承的）。抽象类通过将类名和抽象方法加斜体来表示，另外还可选地向类名和/或操作（我们通常说的方法，但方法实际上是“方法”）添加一个 {abstract} 属性" 操作被实现) 是抽象的。
接口实际上是一种特定类型的抽象类：零实现的类。它们的表示法与其他类型的抽象类不同（不要斜体，使用«interface»关键字，并用虚线表示所有特化箭头）。所以，正如 Christian 在这里所说的，抽象类有标准的表示法——至少在类图中有。
现在，虽然正如 Christian 所说的那样，«abstract»构造型不存在是真的，但如果您愿意，也可以创建它，并且 UML 规范支持这样做。您不太可能有理由（至少在类图中），但您仍然可以。
构造型是 UML 的“可扩展性机制”（共有三种：构造型、标记值和约束）。它允许您更具体地定义某种元素。构造型应用于类（元类实际上，元类是其实例也是类的类）。许多构造型是预定义的“标准构造型”（在 UML 1.4 中它们被称为“标准元素”）。这些示例是«metaclass»（同样，其实例也是类的类）和«file»（所开发系统上下文中的物理文件）。
刻板印象是一种关键字。规范（上层建筑2.0，附件 B，第 663 页）对关键字有以下说明：
UML 关键字是保留字，它们是 UML 符号的组成部分，通常作为附加到 UML 图形元素的文本注释或作为 UML 图中文本行的一部分出现。这些词...不能用于命名用户定义的模型元素，因为这样的命名会导致对模型的解释不明确。例如，关键字“trace”是系统定义的抽象构造型（参见附录 C，“标准构造型”），因此不能用于定义任何用户定义的构造型。
在 UML 中，关键字有四种不同的用途：
要将特定的 UML 概念（元类）与共享相同通用图形形式的其他概念区分开来...
要将 UML 概念（元关联）之间的特定关系与共享相同一般图形形式的其他关系区分开来...
要指定附加到 UML 概念的某些修饰符的值（元属性值）...
表示标准的刻板印象（见附录 C，“标准的刻板印象”）...
关键字总是包含在 guillemets (
«keyword») 中，作为视觉提示，可以更容易地区分何时使用关键字......除了标识关键字之外，guillemets 还用于区分用户配置文件中定义的构造型的用法。这意味着：
- 并非所有出现在 guillemets 之间的词都一定是关键字（即保留字），并且
- guillemets 中出现的词不一定代表刻板印象。
换句话说，您可以创建任何您想要的构造型，只要它不是关键字。由于“抽象”不是关键字，因此您可以创建«abstract»构造型。
然而，为了做到这一点，您将不得不遇到一些麻烦，在 UML 2.0 及更高版本中比在 UML 1.4 中更麻烦。UML 1.4 简单地声明构造型是 UML 规范的扩展机制。可以简单地定义构造型，将其应用于想要的 UML 元模型的任何部分，并记录更改。UML 2.0 希望将构造型与 UML 元类的关系形式化（UML 图中的任何项目都是元类，并且是 UML 元模型的一部分）。所以，他们想出了 Profiles。此示例图显示了配置文件的工作原理：
现在，那个黑色箭头可能看起来有点奇怪，因为除了这个之外，您不会在任何上下文中看到它。UML 2.0 引入了扩展的概念，它定义为“用于指示元类的属性通过构造型扩展”。此黑色箭头表示扩展。
我将引用 Tom Pender（The UML Bible，Wiley Publishing，2004）来解释这个图表，因为他比规范做得更好（我当然无法改进）：
它表明 Component 由 Bean 构造型扩展，这是必需的。Bean 构造型是一种抽象类型，有两个子类型——实体和会话。因此，Component 的每个实例都必须由 Entity 构造型或 Session 构造型的实例扩展。请记住，构造型是一种可以具有属性的类 - 在这种情况下，会话构造型具有名为 state 的属性。这对应于一个标记定义，其值指定会话的状态。标记值是一个枚举 StateKind，它具有无状态或有状态值。
组件对其有一个约束，显示在附加到组件符号的注释中，它指出组件不能被概括或专门化。
该图还显示了接口元类由 Remote 和 Home 构造型扩展。EJB 包有一个约束，显示在包中的注释中，声明一个 Bean 必须完全实现一个 Home 接口。
因此，«abstract»如果您有理由不厌其烦地创建它，那么您确实可以使用刻板印象。任何人都可能想要在类图以外的某个地方表示抽象类的主要原因。