学习设计模式的过程中，发现相关的作者们都会用UML类图来表示一个模式的整体脉络，这种方式确实直观明了，既能体现宏观思路、又能兼顾实现细节。真的是很妙的工具。在开始正式学习设计模式之前，有必要对UML有个大概的掌握。然后，日后有望解锁更多关于UML方面的技能，比如说：建模。哈哈，有点小兴奋呢。
UML全称Unified Modeling Language(统一标准建模语言)，旨在为软件开发提供可视化、模型化的工具。可见，UML既是一种建模工具，也是一种“交流语言”。
一、UML类图的基本元素
1 类的结构
UML用内含三层“格子”的矩形框表示类，如图：
最上层为类的名称；中间为类的字段和属性；最下层为类的行为和方法。
如果为抽象类，类名用斜体标识。
2 访问修饰符
public、private、protected分别用 + - # 来表示
至于C#中的 internal、protected internal修饰符，则没有对应的符号。（UML是通用的标记语言，而后两种修饰符属C#等少数语言）
3 接口表示
有两种方法矩形表示法和棒棒糖表示法（截图来自《大话设计模式》）
二、 相互关系
UML类图中，类与类、接口与类之间的关系一共有泛化(Generalize)、实现(Realization)、依赖(Dependency)、关联(Association)、聚合(Aggregation)、组合(Composition)六种。这几种表示的相互作用关系依次加强。
1 泛化（Generalize）
泛化即子类、子接口继承父类、父接口的功能，并能扩张自己新的功能的能力，是一种 is-a（一般与特殊）的关系。猫继承了动物，那么就可以说猫是动物的泛化，猫 is a 动物。
UML用空心的三角箭头+实线来表示泛化或继承。
2 实现（Realization）
即类实现接口的功能。
对于矩形表示法，用空心三角箭头加虚线表示；对于棒棒糖表示法，则把棒棒糖直接插在实现接口的类上（JUDE的棒棒糖不太好看）。
3 依赖(Dependency)
一个类依赖另一个类的定义。比如人需要用手机打电话，那么人依赖手机。依赖关系总是单向的。依赖具有偶然性、临时性，且关系非常弱。依赖在具体的代码层面，表现为（类A依赖类B）：
类B作为参数被类A使用；
类B以局部变量的形式存在于类A的方法中；
类A调用类B的静态方法。
UML中用简单箭头加虚线表示依赖：
4 关联（Association）
一个类需要知道另一个类的状态（属性、方法）。关联体现的是类与类或接口之间的强依赖关系，相比于依赖关系，这种关系是长期性的，而且双方的关系一般是平等的。在代码层面（A关联B），B以类属性的形式出来在A中，或A引用了一个类型为B的全局变量。
UML中，用简单实线箭头表示单向关联，用双箭头或不使用箭头表示双向关联。但为了降低耦合，双向关联不建议使用。
关联箭头的头和尾都可以添加基数标识，用来表示有几个实例。
5 聚合(Aggregation)
关联关系的一种特例，是强的关联关系，也是一种是整体和个体的关系（has-a）。普通的关联关系的两个类处于同一层级，但聚合关系的两个类处于不同层级，比如公司和员工。同时这又是一种弱的拥有(has-a)关系。因为整体和个体之间是可分离的，他们有各自独立的生命周期。个体可以属于多个整体，也可以被多个整体共享。关于在代码层面的的实现，没有特定的标准，最可靠的识别方法为通过语义。如下为一种实现了聚合的代码：
public class Company
{
List<Employee> list;
}
UML中使用空心菱形加实线来表示
6 组合结合(Composition)
组合也属与关联的特例，是比聚合更强的关联关系，而且整体与部分的生命周期一致(contains-a)。比如胳膊与人体。如下为一种代码实现：
public class Body
{
private Arm arm;
public Body()
{
arm=new Arm();
}
}
UML中用实心菱形加实线来表示
三、总结
六种关系的关联程序从低到高为：泛化<实现<依赖<关联<聚合<组合
泛化为is-a关系，关联为has-a关系，其中，聚合、组合为关联的特例，组合代表的关系最为紧密，是一种contains-a关系
聚合与组合的区别：
1）主要体现在关系成员的生命周期是否相同；
2）被聚合的类，还可以继续被其他类聚合；但被组合的类则不能再属于其他类。
关联和聚合的区别：
主要的差别在于抽象层级，关联在同一抽象层级，聚合在不同层级。
关于UML，目前就学这点皮毛吧。