目录

1、术语和概念

1.1、注解（note）

1.2、修饰

1.3、衍型

1.4、标记值

1.5、约束

1.6、标准元素

1.7、外廓（profile）

2、对新特性建模

3、对新语义建模

---

注解 （note）是附加在元素或元素集上用来表示约束或注释的图形符号。在图形上，把注解画成带有一个折叠角的矩形，在矩形中填写文字的或者图形的注释。

衍型 （stereotype）是对UML的词汇的扩展，用于创建与已有的构造块相似但针对特定问题的新种类的构造块。在图形上，把衍型表示成用双尖括号（«»）括起来的名字，放在其他的元素名之上。作为一种选择，可以用一种与衍型相关的新图标来表示被衍型化元素。

标记值 （tagged value）是衍型的一种特性，允许在带有衍型的元素中创建新的信息。在图形上，把标记值表示成形如name = value的串，放在一个附加到对象上的注解中。

约束 （constraint）是对UML元素语义的文字说明，用来增加新的规则或修改已有的规则。在图形上，把约束表示成用花括号括起来的串，并把它放在相关的元素附近，或者通过依赖关系连接到这个（或这些）元素。作为一种选择，可以在注解中表示约束。

UML由于存在着4种运用于整个语言的公共机制而得以简化，它们是：规约、修饰、公共划分和扩展机制

1、术语和概念

1.1、注解（note）

注解是一种最重要的能单独存在的修饰。
 

衍型、标记值和约束是UML提供的用以增加新的构造块、创建新的特性和说明新的语义的机制。

例如，如果对网络建模，可能需要路由器和集线器的表示符号，可以用衍型化结点来表示它们，使它们就好像原有的构造块一样；

类似地，项目发布组的成员要负责装配、测试和部署发布，可能要跟踪版本号和各个主要子系统的测试结果，对此就可以用标记值把这些信息附加到模型上；最后，如果对硬实时系统建模，可能要用时间预算和最后完成期限来修饰模型，可以使用约束捕获这些计时需求。
 

1.2、修饰

修饰是附加到元素的基本表示法之上的文字或图形项，用于对元素规约的细节进行可视化。例如，关联的基本表示法是一条线，但是可以用各端的角色或多重性等细节来修饰它。

可以在它们平常的分隔栏的底部增加额外的分隔栏，以填写这种信息

1.3、衍型

把衍型看作元类型（一种定义其他类型的类型），因为每一个衍型将创建一个相当于 UML 元模型中新类的等价物。

例如，如果对商业过程建模，则将引入像职工、文档和政策这样的事物；类似地，如果正在进行像Rational统一过程这样的开发过程，则将使用边界、控制和实体类来建模。这是衍型的实际价值所在。

当对结点或类这样的元素建立衍型时，实际上是通过创建类似于已有的构造块的新构造块来扩展UML，但新构造块有自己的具体特性（各个衍型可以提供自己的标记值集合）、语义（各衍型可以提供自己的约束）和表示法（各衍型可以提供自己的图标）。

1.4、标记值

UML 中的每个事物都有它们自己的一组特性：类有名称、属性和操作，关联有名称和两个或两个以上的端点（每个端点都有自己的特性）等。

用衍型可为UML增加新的事物，用标记值可为UML的衍型增加新的特性。

标记值的最常见的用途之一是说明与代码生成或配置管理相关的特性。

例如，用标记值指明特定类所映射到的编程语言；可以用标记值描述一个构件的作者或版本。

1.5、约束

UML中的每一个事物都有它自己的语义。泛化（通常，如果知道什么对你有好处）意味着运用Liskov 替代原理，而连接到一个类的多个关联则表示不同的关系。使用约束，可以增加新的语义或扩展已存在的规则。约束指明了运行时的配置必须满足与模型一致的条件。

1.6、标准元素

对于类目、构件、关系和其他一些建模元素，UML 定义了一些标准衍型。有一个主要为工具建造者准备的标准衍型，使他们可对衍型本身建模。

stereotype——指明类目是一个可以应用到其他元素的衍型。

当要显式地对那些为项目定义的衍型建模时，则使用这个衍型。

1.7、外廓（profile）

为特定的用途或领域定义一个合适的UML版本常常是有用的。

它具有一组预定义的衍型、标记值、约束和基类。它还选择了UML元素的一个子集，使得建模者不被那些在这个特定领域不需要的元素所迷惑。

2、对新特性建模

如果要扩展这些基本构造块的特性，就需要定义衍型和标记值。

下图展示了3个子系统，每个子系统都用«versioned»衍型做了扩展，从而含有其版本号和状态。
 

可以用工具设置像version和status这类标记的值。可以把配置管理工具和建模工具结合起来作为开发环境，以此来维护这些值，这样做要胜于手工设置模型中的这些值。

3、对新语义建模

需要表达UML中不存在的新的语义，或需要修改UML中的规则，就需要写一个约束。

用OCL书写新语义

上图表明，每个Person可以是零个或多个Team的成员，每个Team至少有一个

Person作为成员。该图还指出了每个Team必须恰好有一个Person作为队长，而每个

Person可以是零个或多个Team的队长。所有这些语义都可以用基本的UML表达。然而

，为了断定队长也必须是相应的Team的一个成员，就要涉及到多个关联，这无法用基

本的UML表达。为了说明这个不变式，必须写一个约束，以表明队长是Team的成员的

一个子集，用一个约束连接这两个关联。其中还包含了一个约束：队长必须做过至少

一年的成员。