前言

 public class Person {
     private Integer id;
     private String name;
 ?
     public String getName() {
         return name;
     }
 ?
     public void setName(String name) {
         this.name = name;
     }
 }

• 现在我给你一个类，假如这个类很抽象别人无法理解或者别人现在不想看代码去理解，你如何快速让别人看懂结构呢？UML就是这个作用。那么对于上面Person类我们该如何绘制类图呢
• 这个类很简单，一个类名，两个属性，两个方法。我们只要知道UML类图中如何表示类，如何表示属性如何表示方法即可。

• 我们只需要如上表示即可。每个软件显示的风格不一样。我们不需要在意那些细节。有的软件属性和方法前面不全是+号表示的。这里自己注意下就好。总体分位三块，第一块表示类名，第二块表示属性，第三块表示方法

类之间关联关系

依赖

• 你可能在好奇关联不就是依赖吗。其实我也觉得关联就是依赖。产生关联一定是依赖。存在依赖也一定是关联。这句话没毛病。
• 但是设计模式大佬们非要较真，那咱也只能按照大佬的意思来理解了。
• 非要说出个区别来，那就只能指出他们两者的方向性了。依赖在UML种是带箭头的虚线。而关联是一条实线，这应该就是他们之间的区别了。
• 上面我们也通过案列来说明判定是依赖的三种情况。只要使用过不管是不是永久的都叫做依赖。俗称一日为师终生为师。

• 准确的说关联是存在三种关联关系的，一种是没有方向属于从属关系（实际也是单向关联），双向关联和单向关联。
• 单向关联就是A种有B，B种无A；
• 双向关联是AB中互相依赖对方。
• 到这里你也会发现，这个关联实际上就是依赖关系呀。对！没错，实际就是对依赖的细化。还是上面的代码我们照样可以将虚线箭头

泛化&实现

• 剩下就是聚合和组合了。其实真的不是很理解为什么要搞出这么多的名词，徒增烦恼罢了！
• 聚合更像是一个集体，集体可以解散，解散后个体仍然存在；而组合更像是组装，组装解散后个体的零散零件将会失去整体的意义
• 比如一个国家有很多人组成，假如国家倒闭了，人还是一样的存在，这就叫聚合；
• 比如一个猫是由头，爪子，尾巴组成，这些在一起是一只猫，这就叫组合，这里面任何一个脱离了猫都将是残缺的。

聚合

 public class AggregationAndComposition {
     public static void main(String[] args) {
         Cat cat = new Cat();
     }
 }
 class Cat{
     private Appendage appendage = new Appendage();
 }
 class Appendage{
 ?
 }

• 在代码层面上只需要将代码稍作修改，聚合的关系就变成了组合。理论上我们知道组合是不可分割的。在代码中翻译过来就是依赖的类一起被创建。
• 组合和聚合UML也很好区分。聚合是空心菱形，组合是实心菱形。

小结

• 这里需要注意下，图中也指出了聚合和组合的箭头并不是必须的。有没有箭头都是表示聚合或者组合。看个人喜好吧。我个人比较带上箭头比较有方向感。
• 如果像上面关联一样如果双向聚合呢？理论上是不会出现也不应该出现这种情况的。但是保不齐就有人这么搞。如果真的这样我猜测两端都用对应的菱形表示即可。这时候就没有箭头一说了。

出处：https://www.cnblogs.com/zhangxinhua/p/16275772.html