《uml用户手册》（中文版）第10章，第97页：
“在语义上，包括泛化、关联和实现在内的所有关系都是某种依赖关系。”
第5章，46页：“其实聚合是一种特殊的关联。”
因此，
- aggregation是一种association。
- association是一种dependency。
association和dependency的区别： (《uml用户手册》)"给定一个连接两个类的关联，可以从一个类的对象导航到另一个类的对象，反之亦然。" 关联，必然是可以连到
一个完整的对象实例，而非MyClass::Foo()之类的单个操作。因此，association就只能实现为成员变量，或者A::getB()，如果是A::op(B b)就只能是dependency了。
aggregation和association的区别：《UML Distilled 3rd ed.》上说，aggregation没什么实际语义。(“So the UML included aggregation, but with hardly any semantics. ”)
而且，在建模时建议不要使用aggregation，因为不同的人对aggregation这一模糊概念常有不同的理解。("Aggregation is strictly meaningless; as a result, I recommend that you ignore it in your own diagrams. If you see it in other people's diagrams, you'll need to dig deeper to find out what they mean by it. Different authors and teams use it for very different purposes.")
那么，为什么UML还包含了aggregation呢？为什么UML meta model里没有明说association继承自dependency呢？请看下面的摘录：
UML Reference Manual:
The distinction between aggregation and association is often a matter of taste
rather than a difference in semantics. Keep in mind that aggregation is association.
Aggregation conveys the thought that the aggregate is inherently the sum of its
parts. In fact, the only real semantics that it adds to association is the constraint
that chains of aggregate links may not form cycles, which is often important to
know, however. Other constraints, such as existence dependency, are specified by
the multiplicity, not the aggregation marker. In spite of the few semantics attached
to aggregation, everybody thinks it is necessary (for different reasons). Think of it
as a modeling placebo.
(placebo: 安慰剂, 某些没有内在补救作用的东西，仅仅用来安慰他人)
UML Reference Manual:
Note that association and generalization fit within the general definition of dependency, but they have their own model representation and notation and are not
usually considered to be dependencies.
UML User Guide:
Semantically, all relationships, including generalization, association, and realization,
are kinds of dependencies. Generalization, association, and realization have enough
important semantics about them that they warrant treatment as distinct kinds of
relationships in the UML. The stereotypes listed above represent shades of
dependencies, each of which has its own semantics, but each of which is not so
semantically distant from plain dependencies to warrant treatment as distinct kinds of
relationships. This is a judgment call on the part of the UML, but experience shows
that this approach strikes a balance between highlighting the important kinds of
relationships you’ll encounter and not overwhelming the modeler with too many
choices. You won’t go wrong if you model generalization, association, and realization
first, then view all other relationships as kinds of dependencies.
