UML类图
概述
类图是面向对象式的建模。他们一般都被用于概念建模（conceptual modelling）的系统分类的应用程序，并可将模型建模转译成代码
- 最上面是类名称
- 中间部分包含类的属性
- 底部部分包含类的方法
成员
UML提供机制，以代表类的成员，如属性和方法，对他们的其他信息。
指定一个类成员（即任何属性或方法）的可见性有下列符号，必须摆在各成员的名字之前：
| 符号 | 含义 |
|---|---|
| + | 公共 |
| - | 私有 |
| # | 保护 |
| ~ | 包（即对包内其他成员可见） |
| / | 推导（即由其他属性推导得出 ，不需要直接给定其值） |
| 下划线 | 静态 |
关系
UML类图中常用关系如下：
泛化
泛化（Generalization），即继承的反方向，指的是一个类（称为父类、父接口）具有另外的一个（或一些）类（称为子类、子接口）的共有功能。子类可视为其父类的特例，并可以增加新功能。用带空心三角形箭头的实线表示。
java代码表示为子类继承父类（包括抽象类）
实现
实现（Realization）指的是一个class类实现interface接口（可以是多个）的功能；在Java中此类关系通过关键字implements明确标识。用带空心三角形箭头的虚线表示。
java代码表示为实现接口
依赖
依赖关系（Dependency）可以简单的理解为一个类A使用到了另一个类B，" ... uses a ..."，被依赖的对象只是作为一种工具在使用，而并不持有对它的引用。而这种使用关系是具有偶然性、临时性的、非常弱的，但是B类的变化会影响到A；表现在代码层面，为类B作为参数被类A在某个method（方法）中使用。用带燕尾箭头的虚线表示。表示一个类依赖于另外一个类的定义；依赖关系仅仅描述了类与类之间的一种使用与被使用的关系。
关联
一个关联（Association）代表一个家族的联系。关联可以命名，可以饰以角色名称，有权指针，多重性，可视性，以及其他属性（如相互关联和有方向的（带燕尾箭头的实线表示）关联）。在语义上是两个类之间、或类与接口之间一种强依赖关系，是一种长期的稳定的关系，" ... has a ..." 。关联关系使一个类知道另外一个类的属性和方法；通常含有“知道”、“了解”的含义。某个对象会长期的持有另一个对象的引用，关联的两个对象彼此间没有任何强制性的约束，只要二者同意，可以随时解除关系或是进行关联，它们在生命期问题上没有任何约定。被关联的对象还可以再被别的对象关联，所以关联是可以共享的。 在代码层面上，被关联类以类属性的形式出现在关联类中，也可能是关联类引用了一个类型为被关联类的全局变量。当前定义有五种不同类型的关联。双向（Bi-directional）和单向（uni-directional）的关联是最常见的。
聚合
聚合（Aggregate）是表示整体与部分的一类特殊的关联关系，是“弱”的包含（" ... owns a ..." ）关系，成分类可以不依靠聚合类而单独存在，可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享（sharable）。例如，池塘与（池塘中的）鸭子。再例如教授与课程就是一种聚合关系。又例如图书馆包含(owns a) 学生和书籍。即使没有图书馆，学生亦可以存在，学生和图书馆之间的关系是聚集。聚集可能不涉及两个以上的类。图形以空心的菱形箭尾与实线来表示。
组成
组成（Composition）关系，是一类“强”的整体与部分的包含关系（" ... is a part of ..."）。成分类必须依靠合成类而存在。整体与部分是不可分的，整体的生命周期结束也就意味着部分的生命周期结束。合成类别完全拥有成分类别，负责创建、销毁成分类别。例如汽车与化油器，又例如公司与公司部门就是一种组成关系。图形以实心的菱形箭尾与实线表示。
总结
关联、聚合和组成的差异
关联 描述的是类的成员变量，表示A has B
聚合描述的是整体与部分的“弱”的包含（" ... owns a ..." ）关系，成分类可以不依靠聚合类而单独存在，部分可以脱离整体单独存在。
组成描述的是整体与部分的“强”的包含关系（" ... is a part of ..."）整体与部分是不可分的，整体的生命周期结束也就意味着部分的生命周期结束
聚合和组成举例：员工聚合成部门，部门组成为公司。部门撤销后员工依然能独立存在，所以员工和部门是聚合；公司倒闭后部门不复存在，部门和公司是组成关系