一般情况下，使用关联（association）来表示像类中的字段等。这个关系是始终存在的，因此你可以随时针对关联项进行访问调用，例如可以始终从 Customer 对象获取 Order 对象。但事实上它并不需要是一个字段，如果从更偏向于接口建模的角度来看，它只是表示 Customer 中存在了一个可以返回 Order 的方法。
此处引用《UML Distilled》一书中的定义：
a dependency exists between two elements if changes to the definition of one element (the supplier) may cause changes to the other (the client)
两个元素之间存在依赖关系，是指如果改变其中一个元素（supplier）的定义可能会导致另一个元素的变化（client）
这是一个模糊和普通的关系定义，这就是为什么对 UML 有许多不同形式的依赖（dependency）定义。而在代码术语中，诸如命名一个参数类型和创建一个临时变量对象等也暗示着依赖关系。
你可能不想在 UML 图中显示所有的依赖 - 因为有太多的依赖。你需要有选择性地显示那些对你的沟通表达非常重要的依赖。
我倾向于不频繁的使用多种依赖形式定义。我发现大部分情况下我要展现的关键点是依赖的存在，而使用哪种形式来表述已经不是那么重要。
关联（association）也意味着依赖（dependency），如果两个类之间存在关联关系，则也存在依赖关系。但我无法想象你可能会用一条额外的线来表示这种情况。关联已经暗示了依赖，因此无需再泛化（generalization）了。
这种混淆的原因之一就是在 UML 1.0 中使用了瞬态链接（transient links），这似乎是由于 UML 1.0 的元模型的定义问题，通过使用关联关系形式来体现它们自身的依赖，例如参数。我一直不喜欢这种表示方式，因为我觉得一个永久的关系和一个仅在当前方法中存在的上下文关系之间存在着重要的区别。因此我会以依赖的形式来表示而非关联。在 UML 2.0 中这个问题不会再出现，因为元模型中采用了不同的形式来表示方法上下文的关系，所以上述的表示形式在 UML 2.0 中不在有效。
翻译自 Martin Fowler 文章 《Dependency And Association》。