UML类图小结

这篇文章也不错 http://technoboy.iteye.com/blog/998458

================闲扯的话======================

其实我一直觉得UML是个很没啥用的东西，从来也没怎么学过。偶尔看看别人画的UML图足矣了。戏剧性的是，我见过UML最多的公司（其实也是唯一的公司），是在我从业生涯里迄今为止遇到过的最烂最sb的公司，整个开发流程都要基于UML来搞，最后项目一团乱草。当然我并不是说UML本身不好。啥东西用好了都是好东西，但是对于UML来说，我觉得如果用的人或者组织本身水平不行，还非要装b用这玩意，只能更烂更sb。

现在来说我更觉得UML像是一门已经被淘汰的技术。。。至少不像是前几年这么受推崇了。不过UML图还是要看得懂的。这也是本文最主要的目的。总结一下怎么看UML。

本文图是自己画的，文字很多来自于之前摘抄的内容。

=================正文=======================

类

UML的类图首先是用来描述一个类。类用一个方框表示，方框隔成几栏。

属性在上，方法在下。名称在左，类型（返回值类型）在后。抽象类抽象方法是用“斜体”

可见性的符号表示：+public，-private，#protected，～package。

关系

类其实很简单，重要的是类与类之间的关系。

UML把类之间的关系分为以下5种.

   ● 关联：类A与类B的实例之间存在特定的对应关系（具体看下面）——    <——<>     <——<|>
   ● 依赖：类A访问类B提供的服务                     ----->
   ● 聚集：类A为整体类，类B为局部类，类A的对象由类B的对象组合而成
   ● 泛化：类A继承类B
   ● 实现：类A实现了B接口  

关联依赖和聚集含义不同，需要根据具体的业务逻辑来判断两者到底是什么关系。三者的强弱关系是聚集>关联>依赖。依赖是最弱的关系。也就是说，如果A与B关联，那么A与B肯定依赖。聚集比较复杂，也比较好和另外两种关系区分。而关联强调的是两者之间的对应关系，也就是说，如果A关联B，那么A的对象是使用到某一个B，而不是任何一个B，也就是说A的对象和B的对象两者之间是关联的。所以一般来说A如果关联B，A对象需要保存一个B对象的引用。比如Person和IDCard，就是关联关系，Person对象应该有一个指向IDCard对象的引用，不可能是任何一个IDCard都行。依赖则比关联关系要弱，仅仅表示A用到B，用到哪个B无所谓。比如System.out.println(String str)方法，依赖于String，但是并不依赖于某一个具体的String，这就是依赖关系。

关联（Association）
   关联指的是类之间的特定对应关系，在UML中用带实线的箭头表示。

按照类之间的数量对比，关联
可以分为以下三种：
   ● 一对一关联

   ● 一对多关联

   ● 多对多关联

注意：关联还要以分为单向关联和双向关联

依赖（Dependency）
   依赖指的是类之间的调用关系，在UML中用带虚线的箭头表示。如果类A访问类B的属性或者方法，或者类A负责实例化类B，那么可以说类A依赖类B。和关联关系不同，无须在类A中定义类B类型的属性。依赖是UML中很弱的一种关系，非常的普遍，哪个类补得用到十几二十个别的类呀，如果递归的算下去，依赖这个关系多了去了。

聚集（Aggregation）

 聚集是一种比组合更紧密的关系。组合是指两个类之间的对应关系。而聚集则是指这两个类被规划到了一个系统中，有着更紧密的聚合关系。

比如Person和EmployCard。如果系统需要定义一种Employ类型。那么在这个系统中，这个类型就聚集了Person和EmployCard.

或者以一个空箭头指向前面，如图

聚集指的是整体与部分之间的关系，在UML中用带实线的菱形箭头表示。
聚集关系还可以分为两种类型：
   ● 被聚集的子系统允许被拆卸和替换，这是普通聚集关系。
   ● 被聚集的子系统不允许被拆卸和替换，这种聚集称为强聚集关系，或者组成关系。
    注：强聚集（组成）可用带实线的实心菱形箭头表示。

泛化（Generalization）
   泛化指的是类之间的继承关系，在UML中用带实线的三角形箭头表示。  

实现（Realization）
   实现指的是类与接口之间的关系，在UML中用带虚线的三角形箭头表示。


==========================其它=================================
那依赖和聚合\组合、关联等有什么不同呢？关联是类之间的一种关系，例如老师教学生，老公和老婆，水壶装水等就是一种关系。这种关系是非常明显的，在问题领域中通过分析直接就能得出。依赖是一种弱关联，只要一个类用到另一个类，但是和另一个类的关系不是太明显的时候（可以说是“uses”了那个类），就可以把这种关系看成是依赖，依赖也可说是一种偶然的关系，而不是必然的关系，就是“我在某个方法中偶然用到了它，但在现实中我和它并没多大关系”。例如我和锤子，我和锤子本来是没关系的，但在有一次要钉钉子的时候，我用到了它，这就是一种依赖，依赖锤子完成钉钉子这件事情。组合是一种整体-部分的关系，在问题域中这种关系很明显，直接分析就可以得出的。例如轮胎是车的一部分，树叶是树的一部分，手脚是身体的一部分这种的关系，非常明显的整体-部分关系。上述的几种关系（关联、聚合/组合、依赖）在代码中可能以指针、引用、值等的方式在另一个类中出现，不拘于形式，但在逻辑上他们就有以上的区别。这里还要说明一下，所谓的这些关系只是在某个问题域才有效，离开了这个问题域，可能这些关系就不成立了，例如可能在某个问题域中，我是一个木匠，需要拿着锤子去干活，可能整个问题的描述就是我拿着锤子怎么钉桌子，钉椅子，钉柜子；既然整个问题就是描述这个，我和锤子就不仅是偶然的依赖关系了，我和锤子的关系变得非常的紧密，可能就上升为组合关系（让我突然想起武侠小说的剑不离身，剑亡人亡...）。这个例子可能有点荒谬，但也是为了说明一个道理，就是关系和类一样，它们都是在一个问题领域中才成立的，离开了这个问题域，他们可能就不复存在了。


依赖和关联的区别：
①     从类的属性是否增加的角度看：发生依赖关系的两个类都不会增加属性。其中的一个类作为另一个类的方法的参数或者返回值，或者是某个方法的变量而已。发生关联关系的两个类，其中的一个类成为另一个类的属性，而属性是一种更为紧密的耦合，更为长久的持有关系。②     从关系的生命期角度看：依赖关系是仅当类的方法被调用时而产生，伴随着方法的结束而结束了。关联关系是当类实例化的时候即产生，当类销毁的时候，关系结束。相比依赖讲，关联关系的生存期更长。

组合和聚合
简单来看组合与聚合A和B，如果A组合B，那么B的生命周期与A绑定，或者说是由A控制的
聚合：

public A{
    B b;
    pubic A(B b){
    // 重要：b是传进来的，不是A创建的。
    this.b=b;    }
}

组合

public A{
    B b;
    pubic A(){
    // 重要：b是A创建的。
    b = new B();
    }
}