类图（class diagram）是一种静态结构图（structure diagram），强调的是系统式的建模。是一种面向对象的模型，采用对象，属性，操作，关联等概念展示系统的结构和基础。
类描述对象，是对象的蓝图，而对象是类的可用实例。我们使用类来创建对象。举个例子，我们说马是一种类，一匹白马就是一个对象。
参考《软件工程——实践者的研究方法》第8版
[美]罗杰s.普莱斯曼(Rogers.Pressman), 布鲁斯R.马克西姆(BruceR.Maxim)
机械工业出版社
1.识别分析类
通过检查需求模型开发的使用场景，并对系统开发的用例进行“语法解析”[Abb83], 我们就可以开始进行类的识别了。每个名词或名词词组可以确定为类。如果要求某个类(名词)实现一个解决方案，那么这个类就是解决方案空间的一部分;否则，如果只要求某个类描述一个解决方案，那么这个类就是问题空间的一部分。
问题：分析类要怎么表现出是解决方案空间的一部分？
得到潜在类后
考虑包含在需求模型中的合法类，潜在类应全部(或几乎全部)满足这些特征。判定潜在类是否应包含在分析模型中多少有点主观，而且后面的评估可能会舍弃或恢复某个类。然而，基于类建模的首要步骤就是定义类，因此必须进行决策( 即使是主观的)。
2.描述属性（attributes)
类的属性对应面向对象编程中的成员变量。属性描述了已经选择包含在需求模型中的类。实质上，属性定义了
类，以澄清类在问题空间的环境下意味着什么。
为了给分析类开发一个有意义的属性集合，软件工程师应该研究用例并选择那些合理的“属于”类的“事物”。此外，每个类都应回答如下问题:什么数据项(组合项或基本项)能够在当前问题环境内完整地定义这个类?
3.定义操作（operation）
类的操作对应面向对象编程中的成员函数（自己的理解，不知道对不对）
操作定义了某个对象的行为。尽管存在很多不同类型的操作，但通常可以粗略地划分为4种类型: (1)以某种方式操作数据(例如添加、删除、重新格式化、选择); (2)执行计算的操作; (3)请求某个对象的状态的操作; (4) 监视某个对象发生某个控制事件的操作。这些功能通过在属性或相关属性上的操作来实现。因此，操作必须“理解”类的属性和相关属性的性质。
可以研究语法解析并分离动词。这些动词中的一部分将是合法的操作并能够很容易地连接到某个特定类。这些动词可能就是我们要找的操作。
4.类的组成结构
类中属性和操作名称前面的+，-和＃符号表示该属性和操作的可见性。
- +表示公共属性或操作
- -表示私有属性或操作
- ＃表示受保护的属性或操作
操作（方法）中的每个参数都可以表示为in,out或inout，它们指定了相对于调用者的方向。该方向性显示在参数名称之前。
5.类与类之间的关系
1.关联关系（association)
两个对等类之间的连接，表明两个类之间存在关系。
举例
每个用户有0张或无数张银行卡，但每张银行卡只属于一个用户。
2.泛化关系（generalization）
即一般的类和基于此更具体的类之间的关系，可以说是一种继承关系。
举例
vip用户和svip也是用户，但是更具体。
3. 实现关系（realization）
接口与实现类的关系
参考 https://blog.csdn.net/rl529014/article/details/48552755
类：表示子类与父类的继承关系。
接口：接口与子类继承比较相似，主要区别在于继承上面。从面向对象来说可能更好理解类和接口的区别吧：
类：描述了一个实体，包括实体的状态，也包括实体可能发出的动作。
接口：定义了一个实体可能发出的动作。但是只是定义了这些动作的原型，没有实现，也没有任何状态信息。
举例：
其中“车”是接口，“汽车”和“火车”分别是“车”的实现。
4. 依赖关系（dependency）
一个类的对象可能在方法的代码中使用另一个类的对象，如果对象未存储在任何字段中，则将其建模为依赖关系。
举例：
用户消费需要卡号，而卡号是银行卡的属性，所以说用户依赖银行卡。
5. 聚合关系（aggregation）
聚合关系表示整体与部分的关系，但整体与部分都具有单独的生存周期，部分不会因为整体的消失而消失。
举例
引擎是汽车的一部分，当汽车报废后，引擎可能仍能使用。
6. 组合关系（composition）
组合关系也是表示整体与部分的关系，但关系更强，整体与部分是不可分的。部分会随整体的消失而消失。
举例
大脑是人的组成部分，当人不存在时，大脑也没有存在的意义了。