1、首先来认识下类图？以及类图的作用

类图(Class diagram)由许多（静态）说明性的模型元素（例如类、包和它们之间的关系，这些元素和它们的内容互相连接）组成。类图可以组织在（并且属于）包中，仅显示特定包中的相关内容。

类图(Class diagram)是最常用的UML图，显示出类、接口以及它们之间的静态结构和关系；它用于描述系统的结构化设计。

类图(Class diagram)最基本的元素是类或者接口。

为系统词汇建模型

为系统的词汇建模实际上是从词汇表中发现类，发现它的责任。

模型化简单的协作

协作是指一些类、接口和其他的元素一起工作提供一些合作的行为，这些行为不是简单地将元素相加能得到的。例如：当你为一个分布式的系统中的事务处理过程建模型时，你不可能只通过一个类来明白事务是怎样进行的，事实上这个过程的执行涉及到一系列的类的协同工作。使用类图来可视化这些类和他们的关系。

模型化一个逻辑数据库模式

想象模式是概念上设计数据库的蓝图。在很多领域，你将想保存持久性数据到关系数据库或面向对象的数据库。你可以用类图为这些数据库模式建立模型。

2、怎么画类图？用什么工具？

使用工具：Visio或者processon在线作图

在类图中一共包含了以下几种模型元素，分别是：类（Class）、接口（Interface）以及类之间的关系。

2.1 类（Class)

在面向对象（OO) 编程中，类是对现实世界中一组具有相同特征的物体的抽象。

一般包含3个组成部分。第一个是类名；第二个是属性（attributes）；第三个是该类提供的方法（ 类的性质可以放在第四部分；如果类中含有内部类，则会出现第五个组成部分）。类名部分是不能省略的，其他组成部分可以省略。

类名书写规范：正体字说明类是可被实例化的，斜体字说明类为抽象类。

属性和方法书写规范：修饰符 [描述信息] 属性、方法名称 [参数] [：返回类型|类型]

属性和方法之前可附加的可见性修饰符：

加号（+）表示public；减号（-）表示private；井号(#)表示protected；省略这些修饰符表示具有package（包）级别的可见性。

如果属性或方法具有下划线，则说明它是静态的。

描述信息使用 << 开头，使用 >> 结尾。

类的性质是由一个属性、一个赋值方法和一个取值方法组成。书写方式和方法类似。

2.2 接口（Interface）

接口是一种特殊的类，具有类的结构但不可被实例化，只可以被实现（继承）。在UML中，接口使用一个带有名称的小圆圈来进行表示。

2.3、类图中关系（relation）

在UML类图中，常见的有以下几种关系: 泛化（Generalization）, 实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)

关系	形状
泛化（Generalization）	带三角箭头的实线，箭头指向父类
实现（Realization）	带三角箭头的虚线，箭头指向接口
关联（Association)	带普通箭头的实心线，指向被拥有者，双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。
聚合（Aggregation）	带空心菱形的实心线，菱形指向整体
组合(Composition)	带实心菱形的实线，菱形指向整体
依赖(Dependency)	带箭头的虚线，指向被使用者

（1）泛化（Generalization）

泛化关系：是一种继承关系，表示一般与特殊的关系，它指定了子类如何特化父类的所有特征和行为。

例如：老虎是动物的一种，即有老虎的特性也有动物的共性。

（2）实现（Realization）

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

（3）关联（Association)

关联关系：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，

老师与学生关联可以是双向的，也可以是单向的。

上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。

但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。

下图为自身关联:

（4）聚合（Aggregation）

聚合关系：是整体与部分的关系，且部分可以离开整体而单独存在。

如车和轮胎是整体和部分的关系，轮胎离开车仍然可以存在。

聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。

（5）组合(Composition)

组合关系：是整体与部分的关系，但部分不能离开整体而单独存在。组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。

如公司和部门是整体和部分的关系，没有公司就不存在部门。

（6）依赖(Dependency)

依赖关系：是一种使用的关系，即一个类的实现需要另一个类的协助，所以要尽量不使用双向的互相依赖.

代码表现：局部变量、方法的参数或者对静态方法的调用

各种关系的强弱顺序：泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖

下面这张UML图，比较形象地展示了各种类图关系：

类图绘制的要点

1类的操作是针对类自身的操作，而不是它去操作人家。比如书这个类有上架下架的操作，是书自己被上架下架，不能因为上架下架是管理员的动作而把它放在管理员的操作里。

2两个相关联的类，需要在关联的类中加上被关联类的ID，并且箭头指向被关联类。可以理解为数据表中的外键。比如借书和书，借书需要用到书的信息，因此借书类需包含书的ID，箭头指向书。

3由于业务复杂性，一个显示中的实体可能会被分为多个类，这是很正常的，类不是越少越好。类的设计取决于怎样让后台程序的操作更加简单。比如单看逻辑，借书类可以不存在，它的信息可以放在书这个类里。然而借还书和书的上架下架完全不是一回事，借书类对借书的操作更加方便，不需要去重复改动书这个类中的内容。此外，如果书和借书是1对多的关系，那就必须分为两个类。

4类图中的规范问题，比如不同关系需要不同的箭头，可见性符号等。

3、类图的分类

软件在分析与设计两个阶段各自会绘制一套UML类图，而且是由分析师和设计师两个不同的角色绘制的。那么这两套UML类图有什么异同呢？

领域UML类图和实现UML类图

领域UML类图：产生于分析阶段，由系统分析师绘制，主要作用是描述业务实体的静态结构，包括业务实体、各个业务实体所具有的业务属性及业务操作、业务实体之间具有的关系。

虽然这个UML类图也叫“UML类图”，但是说实话，它和编程中的“类”实在是没啥关系，因为最后的系统中可能根本没有类和它们对应，而且很多最后系统中的类如控制类和界面类这套UML类图中也没有。也就是说这套图和具体技术无关，也不是画给程序员看的，它只是表达业务领域中的一个静态结构。下面给个例子：

这是一个选课系统的简单领域分析UML类图。可以看到，主要实体有教师、学生、课程和开课安排。每个实体标注了其在业务上具有的属性和方法。而且图中还表明了实体间的关系。

实现UML类图：产生于设计阶段，由系统设计师绘制，其作用是描述系统的架构结构、指导程序员编码。它包括系统中所有有必要指明的实体类、控制类、界面类及与具体平台有关的所有技术性信息。

总结

最后，我们总结一下要点：

1.软件分析与设计是编码前的两个阶段，其中分析仅与业务有关，而与技术无关。设计以分析为基础，主要与具体技术有关。

2.分析阶段由分析师绘制领域UML类图，设计阶段由设计师绘制实现UML类图。

3.领域UML类图表示系统的静态领域结构，其中的类不与最终程序中的类对应；设计UML类图表示系统的技术架构，是程序员的编码依据，其中的类与系统中的类对应。

4.领域UML类图中类的属性与操作仅关注与业务相关的部分，实现UML类图中的属性与操作要包括最终需要实现的全部方法与操作。