关联指两个类之间的各种联系。UML使用各种单实线表示关联，这个单实线可以是直线（垂直的、水平的或者倾斜的）、折线甚至曲线。
事实上，关联也是展示类的属性的另一外的一种形式。例如在下图中，我们通过一条实线连接类Book和类Person，表示它们之间存在关联。在关联的末端，标出多重性[*]和关联端名称（通常称为“角色名称”）author。
从上图中我们可以看到关联端名称（角色名称）author是类Book的一个属性。
在上图中，类Book的属性author在类Book的属性描述中和关联的角色名称中同时出现了。一般情况下，我们不会同时使用这两种形式，它可能会带来混淆并且带来了冗余，故可将上图中类Book的属性author删除掉，以下图的形式表示即可。
上图有两种解读方法：
一本书（Book）有多位作为作者（author）的人（Person）。
或
一本书（Book）有一组由多个人（Person）组成的作者（author）。
1.属性和角色修饰符
在类图中，我们可以为属性添加一些修饰符以表达对属性的约束。类属性的表达方式与角色名称的表达方式都是表达源端类的属性信息的手段，故在使用角色名称时，同样也可以通过修饰符对角色名称进行约束。
例如在下图中，我们为角色名称author添加ordered和readOnly属性。这些属性被包含在一对大括号中（大括号表示约束）。
此时，上图可以解读为：
一本书（Book）有一个由多个人（Person）组成的只读的、有序的作者（author）集合。
或
一本书（Book）有一个由多位担任作者（author）角色的人（Person）组成的只读的、有序的集合。
我们几乎可以将能赋予属性的所有内容都赋予关联端。下表展示了属性几乎所有可用的修饰元素。
在表格中，给出了这些修饰元素的符号表示以及其多重性，即该符号可以出现的次数。0..1表示这是一个可选符号；0..*表示该符号可以根据需要出现多次。表格中各表示元素的顺序也是它们在表示时所应采取的大致顺序。
注：上述表格是不完整的，但它已经覆盖了大多数情况。
而下表则是关联端（角色名称）可以使用的修饰元素，在这个表格中也给出了修饰元素的符号表示以及其多重性，同时也给出了使用修饰符时其所处的位置。
关联具有表征类与其属性之间关系双向性的优势。当属性是一个类（而非数据类型）时，使用关联形式最为常见。各个类（或数据类型）可以进一步与类相连接，而图表则展示了它们之间关系的更完整图景。
当然，一个类也可以同时与多个类产生关联。例如对于类Person，它既可以是类Book的author，也可以是Score的composer，此时这两个关联可以用下图进行表示。
2. 解读关联
在上述说明中，我们由类Book关联到类Person、由类Score关联到类Person。但关联是两个相关类的关系，故而也应当可以由类Person关联到类Book、由类Person关联到类Score。因此，我们也可以考虑在关联的另一端提供关联端装饰。
在下图中，同时给出了两个方向的关联信息。
上图中的关联的可以分别解读为如下：
- 一本书（Book）有一个由多个人（Person）组成的有序的作者（author）集合。
- 一个人（Person）有一个由多本书（Book）组成的我的书籍（myBooks）集合。
- 一个乐谱（Score）有一个由多个人（Person）组成的有序的作曲家（composer）集合。
- 一个人（Person）有一个由多个乐谱（Score）组成的我的乐谱（myScore）集合。
当阅读一个关联关系时，从一侧开始（源侧），但只读另一侧（目标侧）上的修饰符。目标侧是远离开始端的那一侧，源侧是靠近开始端的那一侧。
请特别注意，上述关联中所涉及的名称是关联端（角色）名称，而关联关系本身也可以拥有名称，关联关系的名称独立于两端的关联端名称（角色名称），也独立于两端类或类型的名称。这些名称通常使用动词形式，例如下图中所使用的名称是“is authored by”。当为关联提供名称时，通常采用从左向右或者从上到下的形式书写。
在阅读一个关联关系时，总是以“一个”“某个”“每个”或类似的词开始，多重性只在目标侧读取，而源侧的多重性和修饰符被忽略掉。
上图是对从一本书（A Book）到多个人（many Persons）以及从一个人（A Person）到多本书（many Books）的关系进行建模。这种解读是基于关联关系与属性之间的等价性。由于属性仅是实例的属性，因此目标侧的关联端点也仅是实例的属性。
Book --> Person：一本书（Book）由多个人（Person）组成的有序的作者（author）[集合]所著。
当你反向阅读时，通常需要将动词形式从主动语态改为被动语态，或者反之。
Person --> Book：一个人（Person）有一个由多本书（Book）组成的我的书籍（myBooks）[集合]。
在下图中，关联被命名为“authors”，这是“to author”现在时第三人称主动形式。当反向阅读时，则需要使用被动形式“is authored by”。这里我们使用了另一种表示法，即使用了阅读方向指示符►或◄，这个三角形指示了关联名称预期的阅读方向。这个指示符在绘制图表（如改变关联方向）时很有用，但由于它可能需要手动维护三角形的方向而增加了困难。
下表给出了关联关系所可能使用的属性及其说明。
回顾上述说明，我们可以发现其实两个类之间可以存在多个关联，例如上例中，Person既可能是Book的author，也可能是Book的editor。此时可以描述两个关联关系，并分别描绘其关联端名称（角色名称）及关联名称等信息。但要注意的是，角色名称会被映射为属性名称，受限于在同一个类的命名空间中不允许有两个同名属性的规定，在两个类之间存在多个关联时其角色名称也不可以重复。但在使用工具描绘关联时，角色名称可以为空，此时工具会为它们生成不透明的不同名称。
3. 关联和数据类型
正如我们上文所讨论的，可以将属性表示为关联。在前述示例中，我们讨论了类型为类（例如Book、Person或Score）的属性及其工作方式。当属性为数据类型时，通常只对从源类到目标数据类型的单向关联建模，除此之外，其他都基本相同。另外，在目标是数据类型的情况下，一般也不会使用关联名称。例如，对于Book的pages属性而言，可以通过下图所示的关联表示。
4. 链接和实例
前文关联都是在类图中进行描绘，在对象图（实例图）中，也有类似的场景。我们只需使用实例代替类，用链接代替关联即可，如下图所示。
按UML规范，实例名称会带有下划线，实例之间的链接名称也应带有下划线，但与实例名称不同，链接名称的下划线是可以省略的。
特别提醒一点，链接上是不会显示多重性的，因为在对象图的链接中每一侧总是只有一个实例，多重性需要通过对多个实例建立多条链接来体现。