马上快进行uml考试，整理了一些笔记，和大家分享一下。类图
一、类图是什么？
类图是 UML中最重要的静态结构图，用来描述系统中有哪些类/接口、它们有什么属性和方法，以及它们之间是如何关联的。说人话：类图用于描述系统中所包含的类以及它们之间的相互关系
如果说用例图回答的是"系统对外提供什么功能"（从用户视角看），那类图回答的就是"系统内部由哪些东西组成、它们怎么搭在一起"（从开发者视角看）。
一句话：类图 = 系统的骨架蓝图，类似于建筑图纸中的结构框架图。
二、类图的作用
| 层面 | 作用 |
|---|
| 需求分析 → 设计 | 把业务领域的概念（实体）固化成软件世界里的类，是OOP设计的起点 |
| 沟通工具 | 让开发、架构师、甚至产品在同一张图上对齐"数据结构长什么样" |
| 代码生成的依据 | 很多IDE/工具可以从类图直接生成类骨架（或反向——读代码生成类图） |
| 理解遗留系统 | 拿到一堆旧代码，先拉出类图就能快速看清全局结构 |
| 指导编码 | 类图定了，代码里的 class、interface、extends、import基本就定了 |
类在UML图中被画成一个三层矩形：类名层、属性层、 方法层
类名层：放类的名称，一般首字母大写
属性层：类的静态特征，即描述该类的每个实例的具体信息，也被称为字段，变量。这些属性的开头也会放一个可见性符号。属性名称以小写字母开头，后面跟冒号和数据类型
方法层：类的动态行为，即该类可能会有哪些行为，也称为方法或者函数，方法也需要设置可见性，方法以小写字母开头
三、类图中类的分类
1. 实体类（Entity Class / Model Class）
定义：实体类对应系统需求中的每个实体，它们通常需要保持在永久存储体中，一般使用数据库表或文件来记录，实体类既包括存储和传递数据的类，还包括操作数据的类。实体类来源于需求说明中的名词，如学生、商品等；
特点：
包含属性（数据）
包含与业务相关的核心方法
一般由“领域模型”演化而来
举例：
Customer（客户）
Order（订单）
Product（商品）
Student（学生）
✅ 常见于：领域层 / 实体层 / 业务模型
2. 控制类（Control Class）
定义：控制类用于体现应用程序的执行逻辑，提供相应的业务操作，将控制类抽象出来可以降低界面和数据库之间的耦合度。控制类一般是有动宾结构的短语（动词+名词）转化来的名词，如增加商品对应有一个商品增加类，注册对应有一个用户注册类等。
表示“控制逻辑”“业务流程”
用于协调实体类和边界类
体现用例的实现逻辑
特点：
一般不直接存储业务数据
负责调度、判断、协调，指挥别人干活
举例：
OrderController （订单相关请求）
LoginService （登录业务逻辑）
PaymentProcessor （支付流程）
RegisterManager （注册流程）
✅ 常见于：业务层 / 服务层 / 控制逻辑
3. 边界类（Boundary Class）
定义：边界类用于对外部用户与系统之间的交互对象进行抽象，主要包括界面类，如对话框、窗口、菜单等。
表示系统与外部参与者的交互界面
负责输入和输出
隔离内外系统变化
特点：
举例：
LoginForm （登录界面）
OrderUI （订单相关界面）
UserController （接收用户请求）
PaymentAPI （对接外部支付系统）
✅ 常见于：表现层 / 接口层
四、关于可见性符号（前缀）
-：private（私有，仅类内部可见）
+：public（公有，完全开放可以被任何类访问）
#：protected（受保护，只能由同一个类或子类可见）
~：package/default（包内可见,使用较少）
五、类之间的关系
关联关系
泛化关系（继承关系）
表示：空心三角 + 实线（三角指向父类）。
含义：子类继承父类的属性和方法。
专业描述：从一般到特殊的关系。
示例：动物◁——— 猫（猫是一种动物）。
聚合关系
组合关系
依赖关系
语义：一个类在方法内部临时使用另一个类（如作为方法参数、局部变量）。关系最弱，是临时性的。
专业描述：一个类的方法的参数的数据类型是另一个类的定义，或者一个类的方法使用了另一个类的属性或方法。
说人话：特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时使用依赖关系。大多数情况下，依赖关系体现在某个类的方法使用另一个类的对象作为参数。在UML中，依赖关系用带箭头的虚线表示，由依赖的一方指向被依赖的一方。
实现关系
六、关系的多重性
类的多重性（Multiplicity）指的是：
一个类对象与另一个类对象之间，在某种关联关系下，可以存在的实例数量（个数）范围。说人话就是一个类的实例能与另一个类的多少个实例相关联。
多重性标注在关联关系（Association）的两端，格式为 min..max（表示从 min 到 max 的数量范围）。
| 常见符号 | 含义 | 代码实现参考 |
|---|
| 1 | 恰好 1 个（一对一，必须存在） | private Order order; |
| 0..1 | 0 个或 1 个（可选，最多一个） | private Order optionalOrder; |
| * | 0 个或多个（无限，集合） | private List orders; |
| 0..* | 同上，0 个或多个 | private Set orderSet; |
| 1..* | 1 个或多个（至少一个，非空集合） | private List nonEmptyOrders; |
| m..n | 范围（如 2..4表示 2 到 4 个） | private Order[] fixedSizeArray; |
多重性不仅用于普通关联，也用于聚合、组合等关系，用于描述整体与部分的数量配比。
| 关系类型 | 示例 | 多重性含义 |
|---|
| 聚合 (Aggregation) | Company "1" ◇--> "*" Employee | 一家公司拥有多名员工（公司没了，员工还在）。 |
| 组合 (Composition) | Order "1" ◆--> "1..*" OrderItem | 一个订单必须包含至少一个订单项（订单删除，项随之删除）。 |
| 双向关联 | User "1" --> "0..*" Account | 一个用户有多个账号，但一个账号只属于一个用户（Account端为 1）。 |
七、类图绘制
找类 → 写属性 → 写方法 → 连关系
1. 找类（提取系统对象）
画类图首先要从需求中提取“类”。通常通过分析需求描述中的名词来寻找系统对象，例如“学生借阅图书”中可提取出“学生、图书、借阅记录”等类。一般来说，人、物、业务对象都可能成为类，而界面、控制逻辑也可进一步抽象成边界类和控制类。此步骤决定类图结构，是整个建模的基础。
2. 写属性（确定类的数据）
确定类后，需要分析每个类“具有什么信息”，即类的属性。属性通常来源于对象的特征描述，例如学生具有“姓名、学号、班级”等属性，图书具有“书名、作者、编号”等属性。属性一般写在类图中部，格式为“可见性+属性名:类型”，通常使用私有（-）表示，以体现封装思想。
3. 写方法（确定类的行为）
方法用于描述类“能够做什么”，通常从需求中的动词提取。例如学生可执行“登录、借书、查询成绩”等操作，图书可执行“更新状态、查询库存”等操作。方法写在类图底部，格式为“可见性+方法名(参数):返回值”。方法不必写得过细，应突出类的核心职责和功能。
4. 连关系（分析类之间联系）
最后分析类与类之间的关系并连接。常见关系包括：关联关系（有联系）、继承关系（is-a）、聚合/组合关系（整体与部分）以及依赖关系（临时使用）。例如学生与图书是关联关系，班级与学生是聚合关系。绘图时还需标注多重性，如“1”“”“1..”，用于说明对象数量关系。
最后绘制成的图书馆管理系统如下：
