UML类关系个人总结

1.泛化和关联，实现在语义其实也是依赖关系，但他们有特定的含义和结果，应该使用专用的线型符号来表达。所以单分出来。

2.泛化和实现很好区分，不必细说，区分关联和依赖关系的方法：关联在语义上有表现类实例之间的对应关系，所以有重数的概念（一对一，一对多等），依赖在语义上强调类与类的关系，没有重数的概念。

3.虽然在语义上，组合是聚合的一种特殊形式，称为组合聚合（Composite Aggregation），强调组合者管理被组合者的全部生命周期，图上却把它们画成同级。因为，习惯上把没有特殊说明的聚合看成是共享聚合（Shared Aggregation），应使用空心菱形, 以与组合聚合(Composite Aggregation)进行区分。这样分类，要强调在设计阶段要严格区分一个聚合是共享聚合还是组合聚合，选择不同符号。

4.多元关联在UML图中并不常见，认为程序员习惯上把一个多元关联处理成多个二元关联，这似乎是人类大脑处理复杂关系的本能方式，大家很自然的就会这样做。

5.创建与实例化的语义很相似，许多资料没有讲清它们的区别。我认为，实例化专用于工厂类的，强调一个类的某个方法创建并返回了另一个类的实例，也就是说有工厂类中有一个方法，其行为的定义就是实例化对象。而创建关系有所不同，创建者的一个方法创建了另一个类的实例但不返回，此方法要完成其他行为需要创建这个实例而已。

6.细化关系出现在同一个概念的不同版本之间，同一个概念在不同的设计阶段可能出现不同版本，后出现的的版本是先前版本的细化，一般用不到。因为我认为一个概念的不同版本不应该出现在同一个UML图中，对同一个图，一般只表现当前设计阶段下的模型，没必要包含历史不同版本。

7.跟踪关系也是表现的不同模型中的相似概念，但不要求精确的对应关系。我总结有两种场景：不同开发阶段的模型，如设计阶段的模型中的一个类trace需求阶段模型的另一个概念；不同子系统的模型，如客户端模型的一个用于显示数据的类trace服务端模型的一个保存数据的类。

8.替代关系也挺特殊，一个东东可以替代另外一个东东，在泛化和实现中其实是隐藏了替代关系的，如继承关系中，子类能替代父类，实现同一接口的不同类也能互相替代。个人认为泛化和实现都实现替代的机制，单独列出一个替代关系，是让它用于其他机制实现的替代关系，如：C++使用运算符重载机制，自己定义一个大整数类型，可以代替内置的整数类型，这就没有使用继承机制。

9.大多数使用（usage）关系，大多数情况下，其实没有必要再细分类型。具体的使用方式叫给源代码说明就可以了。更何况，一个类使用另外一个类，可能既包含调用（call）又包含创建（creation），这时候用使用来概括就可以了。