关联和链接关系在很多情况下是对称的，即被关联的两个类都有以自己为源端对方为目标端的角色存在，而且角色与源端类的属性是等价的，即在关联一端的关联端（角色）等价于另外一端的属性。例如，在下图中，我们可以认为author:Person是类Book的一个属性，而myBooks:Person是类Person的一个属性。
关于关联的详细信息，可参阅《UML之关联》一文。
如果希望表达一种非对称的关系，可以使用“组合”或“聚合”关系进行建模。UML使用实心菱形（组合）或空心菱形（聚合）表达这种关系，菱形放置在关联线上并靠近关系中的占主导地位的元素。
1.组合
组合表达整体与部分的关系，表示组合的实心菱形放置于表示整体的元素的那一端，如下图所示。
在上图表示的组合关系中，靠近Cover的一端给出了多重性值2，而靠近Book的一端未给出多重性，此时它的多重性值将默认为1。这张图描画的模型表明封面（Cover）是书（Book）的一部分，并且一本书包含有两个封面（封面和封底）。
使用组合关系时，“整体”的生命周期将决定“部分”的生命周期。例如在上例建模的场景下，如果我们删除（或者在现实世界中我们焚毁）一本书（Book），则封面（Cover）也将被删除（或焚毁）。
“整体”端一侧的多重性值只能是[1]或者[0..1]（注意：在组合关系建模时多重性不需要前后的中括号[ ]，参见上图）。例如在上例中，首先一个封面（Cover）不能被用于多本书（Book）；其次，如果封面（Cover）不可以从书（Book）中移除，则菱形所在一侧的多重性值只能为[1]，如果允许封面（Cover）从书（Book）中移除，则菱形所在一侧的多重性值只能为[0..1]。
“部分”端一侧的多重性允许是任意的合法值，上例中的封面（Cover）是两个，即封面和封底。上述多重性也可以使用独立的组合关系替代，即在Book与Cover之间分别为封面与封底建立组合关系，如下图所示。
组合作为关联的一种类型，理论上关联的所有修饰符都可以应用于组合，不过通常不需要给出组合的名称，而在理解或描述组合时允许有类似以下的说法：
一本书由两个封面组成。
一本书有两个部分是封面。
一个封面是一本书的一部分。
组合是一种非对称的关系：一本书（Book）可以有封面（Cover）作为它的一部分，而一个封面（Cover）不能将同一本书（Book）作为它的一部分。
组合具有传递性，这意味着如果类C是类B的一部分，而类B是类A的一部分，则类C也是类A的一部分。例如某个类（Class）由名称（Name）和属性（Attribute）组成，而属性（Attribute）又有它的组成部分。如果删除类（Class），则不只是名称（Name）和属性（Attribute）会被删除，组成属性（Attribute）的Name、Type、Mult也将被删除。
使用类似上图的树形结构在描述组合或聚合关系非常常见，例如对材料清单、元模型或过程分解建模时都可以使用树形结构。
2.聚合
聚合是组合的一种较弱形式，或者说是关联的一种较强形式。
相对于组合，聚合的目标端可以与多个源端建立关联，即目标端是可以“共享”的。例如在下图中，一本书（Book）可以有多名作为作者（author）的人（Person），而一个人（Person）也可能是多本书（Book）的作者（author）。
此外，组合的“整体“决定了”部分“的生命周期，而聚合不存在这种约束。当聚合的”整体“消失时，”部分“依旧存在，它并不随”整体”而消失。例如当一本书（Book）被销毁时（甚至所有已印刷的书都被销毁时），作为这本书（Book）作者（author）的人（Person）依然健在；反之，当作为作者（author）的一个人（Person）死亡后，并不会影响这本书（Book）的完整性。
可以看到，聚合的语义与常规关联的语义几乎相同。当我们使用聚合时，通常可以直接使用关联来替代它。如果需要强调类似部分的关系而它又不像组合那样紧密与强烈时，则可以选择使用聚合。
最后，特别补充一点，从UML技术角度来说，关联有一个名为AggregationKind的属性，普通关联其值为None，对于组合其值为Composite，对于聚合，其值为Shared。