UML类图关系总结

对于uml的类图的理解几乎一直停留在一知半解的层面，也就在考试的时候会临时抱佛脚对一些知识有很好的理解，考完之后遍抛在脑后，时间久了便忘得一干二净，很不好也不应该，一些被证明是正确的东西应该强化记忆被永久的记下来。所以，趁现在时间不是特别的紧张，好好的总结整理一下，方便理解和记忆。整理的主要的意图是根据类图将类代码化或者根据代码类画成类图。

依赖（Dependency）

依赖关系是UML中最基本的关系，下边这个图在某种方式上类A依赖于类B。

依赖还有更多的广泛的含义，最好不要过度的使用依赖关系

依赖关系所代表的到底是什么你，在上边的UML图中，类A使用了类B，但是类A不把B的实例作为A的一部分。

import B; 
public class A { 
	public void method1(B b) { 
		// . . . 
	} 
	public void method2() { 
		B tempB = new B()
	}
}

事实上，不管类B在方法中作为参数使用还是在方法中作为一个本地的实例的引用，都是依赖关系的正确的使用。

import B;
public class A {
  private B b; // 错误的

  public B getB() {
    return b;
  }
}

上边的例子中，类B通过在类A中声明类B的实例来定义类A的状态，但是这却是依赖关系的一个错误的使用。

关联(Association)

下边这个类图是一个类和另一个类的关联。

关联定义了依赖，但是要比上边描述的依赖关系更强。在这个例子中，类A和类B相关联，换句话说类A使用和包含了类B的实例，但是类B不知道或者包含类A的实例。

import B;
public class A {
  private B b1;
  public B getB() {
    return b1;
  }
}

关联关系定义了依赖类的实例状态，类A必须在它的实例范围中定义类B的实例。
还有更多的关联关系，我们已经讨论了状态，然而还有必要定义实例的声明周期和有多少个实例是想关联的。 聚合（Aggregation）和组合(Composition)就可以用来解决这个问题。例如下边这个图就是描述了两个类的聚合关系

对应的代码的实现类：

import B;
public class A{
	List Bs;
	public void AddB(B b) { 
		Bs.Add(b); 
	}
}

上边这个图意味着A聚合B，聚合描述了实例A中包含实例B的引用的关系而且是作为A的状态，但是特定的实例B也可能被其他的聚合者所共享。在这个例子中，A的生命周期结束了，实例B的生命周期不一定结束。
组合另一方面定义了A的生命周期包含了B的生命周期。如下图：

对应是代码实现类：

import B;
public class A{
	List b = new B(); 
}

泛化（Generalization）

泛化是相对好理解的一个概念，描述了子类实现了特定的超类，下边是类图。

对应的代码实现类

import B;
public class A extends B {
	// . . . 
}

实现（Realization）

是一种类与接口的关系，表示类是接口所有特征和行为的实现，下边是类图

对应的代码类

import B;
public class A implements B {
  // . . .
}

参考资料：https://vaughnvernon.co/?page_id=31
http://www.open-open.com/lib/view/open1328059700311.html
https://nirajrules.wordpress.com/2011/07/15/association-vs-dependency-vs-aggregation-vs-composition/