导语
UML类图是面向对象设计中最核心的可视化工具。它描述系统中的类、类的属性和方法，以及类之间的关系。无论是技术方案评审、架构设计文档，还是新人入职培训，一张清晰的类图胜过千言万语。
但在实际工作中，很多人画类图时符号混乱、关系标注错误、层级过深，导致图越画越乱，反而增加了沟通成本。
本文从类图的三要素出发，系统梳理类关系类型、绘制规范、常见错误和进阶实践，帮助你画出专业、清晰的UML类图。
更多画图教程与在线工具，尽在 星程图示
一、类图的三要素
一张UML类图由三个核心元素构成：
1. 类（Class）
用矩形表示，分三层：
| 层级 | 内容 | 示例 |
|---|---|---|
| 第一层 | 类名（居中加粗） | User |
| 第二层 | 属性（格式：可见性 名称: 类型） |
- id: Long |
| 第三层 | 方法（格式：可见性 名称(参数): 返回类型） |
+ login(username: String): Boolean |
2. 可见性修饰符
| 符号 | 含义 | 说明 |
|---|---|---|
+ |
public | 外部均可访问 |
- |
private | 仅类内部可访问 |
# |
protected | 类及其子类可访问 |
~ |
package | 同包内可访问 |
3. 多重性（Multiplicity）
标注在关联线两端，表示对象数量关系：
| 标记 | 含义 |
|---|---|
1 |
恰好一个 |
0..1 |
零或一个 |
* |
任意多个 |
1..* |
至少一个 |
0..* |
零或多个 |
二、六种类关系：从弱到强
类关系的强度排序：依赖 < 关联 < 聚合 < 组合 < 泛化(继承) < 实现。
关系对照表
| 关系 | 符号 | 含义 | 生命周期 | 示例 |
|---|---|---|---|---|
| 依赖 | 虚线 + 开放箭头 | 临时使用，不持有引用 | 独立 | 人使用筷子 |
| 关联 | 实线（可选箭头） | 结构性引用，持有引用 | 独立 | 老师教学生 |
| 聚合 | 实线 + 空心菱形 | 整体-部分（弱拥有） | 部分可独立存在 | 部门有员工 |
| 组合 | 实线 + 实心菱形 | 整体-部分（强拥有） | 部分随整体销毁 | 房屋有房间 |
| 泛化 | 实线 + 空心三角 | 继承（is-a） | — | 汽车是交通工具 |
| 实现 | 虚线 + 空心三角 | 接口实现 | — | 类实现接口 |
关键区分：聚合 vs 组合
这是类图设计中最容易混淆的一组关系。判断方法：
- 问自己："部分能否脱离整体独立存在？"
- 能 → 聚合（员工离开部门仍存在）
- 不能 → 组合（房间随房屋拆除而消失）
错误使用会导致系统设计中生命周期管理混乱，引发内存泄漏或数据完整性问题。
三、绘制类图的七步法
第一步：识别类
从需求描述中提取名词，筛选出系统中的核心实体。
示例："用户在商城下单，订单包含多个商品，商品属于某个分类。" 候选类：User、Order、Product、Category
第二步：确定属性和方法
为每个类定义必要的属性（数据）和方法（行为）。原则：只保留与当前系统相关的属性，不要把所有字段都堆上去。
第三步：分析关系
逐对分析类之间的关系类型：
- 是否存在继承关系？（is-a）
- 是否是整体-部分关系？（has-a）→ 再判断是聚合还是组合
- 是否只是临时使用？（uses-a）→ 依赖
第四步：标注多重性
在关联线两端标注数量关系，明确"一个用户可以下多少个订单""一个订单包含多少个商品"。
第五步：检查循环依赖
类A依赖类B，类B又依赖类A？考虑提取公共逻辑到第三方类。
第六步：优化布局
- 相关类就近放置，减少连线交叉
- 继承层次统一方向（箭头朝上指向父类）
- 超过15个类的图应拆分为多张子图
第七步：审查验证
对照面向对象设计原则检查：
- 单一职责：一个类是否只做一件事？
- 开闭原则：扩展时是否需要修改现有类？
- 里氏替换：子类是否能安全替换父类？
四、常见错误清单
| 错误 | 问题 | 正确做法 |
|---|---|---|
| 滥用继承 | 所有共享行为都用继承 | 优先组合，继承仅用于真正的is-a关系 |
| 混淆聚合与组合 | 部分能独立存在却用组合 | 判断生命周期依赖关系 |
| 忽略多重性 | 关联线两端不标数量 | 始终标注1、0..1、*等 |
| 过度设计 | 层级超过4层、类超过20个 | 从简单开始，按需增加复杂度 |
| 命名不规范 | 类名用动词、属性名用拼音 | 类名用名词、方法名用动词，统一英文命名 |
| 混淆依赖与关联 | 把成员变量引用标成依赖 | 持有引用→关联，临时使用→依赖 |
五、进阶建模技巧
1. 接口与抽象类
- 用
<构造型标注接口> - 抽象类用斜体类名表示
- 实现关系用虚线+空心三角
2. 关联类
当两个类之间的关联本身需要携带属性时，用虚线连接一个类到关联线上。例如"用户"和"商品"之间的"评价"就是一个关联类。
3. 自引用关系
一个类关联自身。例如"员工"的上级也是"员工"。标注角色名区分：manager 和 subordinate，多重性 1 和 0..*。
4. 约束与注释
用花括号标注约束条件，如 {age > 0}。用折角矩形添加注释说明设计决策。
六、工具选择
| 工具 | 特点 | 适合场景 |
|---|---|---|
| PlantUML | 代码生成图，版本可控 | 程序员、DevOps |
| Draw.io | 免费、拖拽式 | 快速画图 |
| StarUML | 专业UML建模 | 系统设计文档 |
| singcheng.com | 在线一站式画图，支持类图/架构图/流程图/思维导图/原型图/白板 | 团队协作、知识沉淀 |
推荐：团队协作场景下，singcheng.com 支持在线绘制UML类图、架构图、流程图、思维导图、原型图和白板，无需安装、实时协作，适合从设计到评审的完整流程。
七、最佳实践总结
- 从简单开始：先画核心类和主要关系，再逐步补充细节
- 优先组合：组合比继承更灵活，避免继承层次过深
- 标注多重性：每条关联线都必须有数量标注
- 限制图的规模：单张图不超过15个类，超出就拆分
- 统一命名规范：类名大驼峰、属性小驼峰、方法用动词开头
- 定期审查：代码变更后同步更新类图，避免文档与实现脱节
自检清单
发布类图前，逐项核对：
- 每个类的三栏结构完整（类名/属性/方法）
- 可见性修饰符正确标注（+/-/#/~）
- 六种关系符号使用正确
- 聚合与组合区分正确
- 所有关联线标注多重性
- 继承层级不超过4层
- 无循环依赖
- 命名规范统一
- 图中类数量不超过15个
- 已对照面向对象设计原则审查
总结
UML类图不是"画给老师看的作业"，是团队沟通的设计语言。一张好的类图应该让任何开发者拿起来就能理解系统结构，不需要额外解释。
记住一个原则：类图是设计工具，不是文档装饰。如果画完图发现自己也没想清楚关系，说明设计本身还有问题——回到需求，重新梳理。
更多可视化画图教程与在线工具，访问 singcheng.com —— 架构图、流程图、思维导图、原型图、白板，一站式搞定。