在分析阶段，关联表示对象之间的逻辑关系。没有必要指定方向或者关心如何去实现它们。应该尽量避免多余的关联，因为它们不会增加任何逻辑信息。在设计阶段，关联用来说明关于数据结构的设计决定和类之间职责的分离。此时，关联的方向性很重要，而且为了提高对象的存取效率和对特定类信息的定位，也可引入一些必要的多余关联。然而，在该建模阶段，关联不应该等于 C++ 语言中的指针。在设计阶段带有导航性的关联表示对一个类有用的状态信息，而且它们能够以多种方式映射到程序设计语言当中。关联可以用一个指针、被嵌套的类甚至完全独立的表对象来实现。其他几种设计属性包括可见性和链的可修改性。 图 4 – 5 表示了一些关联的设计特性。
图 4–5 关联的设计特性
1. 聚集和组成
聚集表示部分与整体关系的关联，它用端点带有空菱形的线段表示，空菱形与聚集类相连接。组成是更强形式的关联，整体有管理部分的特有的职责，它用一个实菱形物附在组成端表示。每个表示部分的类与表示整体的类之间有单独的关联，但是为了方便起见，连线结合在一起，现在整组关联就像一棵树。 图 4 – 6 表示了聚集关联和组成关联。
图 4–6 聚集和组成
2. 链
链是关联的一个实例。链即所涉及对象的一个有序表，每个对象都必须是关联中对应类的实例或此类后代的实例。系统中的链组成了系统的部分状态。链并不独立于对象而存在，它们从与之相关的对象中得到自己的身份（在数据库术语中，对象列表是链的键）。在概念上，关联与相关类明显不同。而在实际中，关联通常用相关类的指针来实现，但它们可以作为与其相连的类分离的包含体对象来实现。
3. 双向性
关联的不同端很容易辨认，哪怕它们都是同一种类。这仅仅意味着同一个类的不同对象是可以相互联系的。正是因为两端是可区分的，所以关联是不对称的（除了个别的例子外），且两个端点也是不能互相交换的。在通常情形下这是一个共识：就像动词短语中的主语和宾语不能互换一样。关联有时被认为是双向性的，这意味着逻辑关系在两个方向上都起作用。这个观点经常被错误理解，甚至包括一些方法学家。这并不意味着每个类“了解”其他类，或者说在实现中类与类之间可以互相访问。这仅仅意味着任何逻辑关系都有其反向性，无论这个反向性容不容易计算。如果关联只在一个方向横穿而不能在另一个方向横穿，那么关联就被认为有导航性。
为什么使用基本模型，而不用编程语言中流行的指针来表示关联？原因是模型试图说明系统实现的目的。如果两个类之间的关系在模型中用一对指针来表示，那么这两个指针仍然相关。关联方法表明关系在两个方向都有意义，而不管它们是如何实现的。将关联转化成一对用于实现的指针很容易，但是很难说明这两个指针是彼此互逆的，除非这是模型的一部分。
