UML 基础：用例图、类图、序列图
一、UML 的用途与常用图
UML（Unified Modeling Language）是一套统一的建模符号与图法，用来表达需求、设计、结构与时序，便于人之间沟通、也便于从设计落到代码。不必画满所有图，按需选：用例图看「谁用系统做什么」；类图看「有哪些类、什么关系」；序列图看「对象之间按时间顺序怎么调用」；活动图看「流程与分支」。下面先总览四种图各解决什么问题。
二、用例图（Use Case Diagram）
用例图展示参与者（Actor）与用例（Use Case）、以及用例与系统边界的关系。参与者画在系统外（小人或 stereotype），用例画在系统边界内（椭圆），连线表示「谁参与哪个用例」。适合在需求阶段快速呈现「系统给谁提供哪些功能」。
画法要点：系统边界用矩形；参与者在边界外，与相关用例连线；用例之间若有「包含」「扩展」关系，可用带箭头的虚线标注。不必画得太细，能表达「谁用哪些功能」即可。
三、类图（Class Diagram）
类图展示类（Class）及其属性、方法，以及类之间的关系：继承（三角箭头）、组合/聚合（菱形、实心/空心）、依赖（虚线箭头）、关联（实线）。适合表达领域模型或模块的静态结构，便于讨论「谁依赖谁、谁拥有谁」。
画法要点：类用矩形分三格（类名、属性、方法）；关系用箭头和多重性（1、*、1..* 等）。不必把每个 getter 都画上，画对设计讨论和实现有影响的核心类与关系即可。
四、序列图（Sequence Diagram）
序列图按时间顺序展示对象之间如何发消息。每个对象一条竖线（生命线），消息用水平箭头表示调用方向，从上到下即时间顺序。适合表达「一个场景下谁先调谁、传什么、返回什么」，便于对齐接口与流程。
画法要点：参与交互的对象横排，各自一条竖线；请求消息用实线箭头、返回可用虚线；按时间从上到下读。序列图特别适合讨论接口与流程，画完再落代码或写 API 文档会清晰很多。
五、活动图（Activity Diagram）简述
活动图用「活动」（圆角矩形）、「判断」（菱形）、「开始/结束」（圆）和「泳道」表达流程与分支。适合描述业务流程、算法步骤或状态流转。和流程图类似，但支持泳道（谁做哪一步）、并发分支等。需求或设计里遇到「先 A 再 B，若 C 则 D」时，可以画一张活动图把分支说清楚。
六、何时画图、何时不画
图是手段不是目的：能减少歧义、能辅助讨论或评审时就画；简单到口头能说清、或代码即文档时可以不画。常见适合画的情况：需求评审（用例图）、设计评审（类图、序列图）、跨团队对齐接口（序列图）、新人 onboarding（几张核心图）。不必追求「所有模块都有类图」——优先画容易误解、经常被问、或变更频繁的部分。
- 适合画：需求/设计评审、跨团队对齐、复杂流程或关系、新人理解系统、变更频繁的模块。
- 可不画：逻辑极简单、口头能说清、代码即文档（且大家会看）、一次性脚本。
七、图与代码的同步
图一旦画出来，就面临「和代码会不会脱节」的问题。设计改了、代码改了，图没改，图就变成误导。建议：把图当「设计快照」，重要变更后顺手更新图，或把图放在能随代码一起 review 的地方（例如文档即代码、或 PR 里贴图）；不必追求图与代码逐行一致，但核心结构、接口、流程应对得上。若团队用「代码即文档」（例如 OpenAPI、类型定义），图可以只保留高层架构和关键流程，细节以代码为准。
一句话： UML 用例图表达「谁对系统做什么」，类图表达「有哪些类与关系」，序列图表达「对象间按时间顺序的调用」，活动图表达「流程与分支」。按需画图、以沟通和减少歧义为准；图要与代码或设计保持同步，至少核心部分一致。
八、小结
UML提供统一的建模符号；常用四图：用例图（参与者与用例）、类图（类、属性、方法、关系）、序列图（对象、生命线、消息顺序）、活动图（流程与分支）。何时画以「能否减少歧义、辅助沟通」为准；图要与代码或设计同步，核心结构应对得上。下一章讲架构设计入门：分层架构、组件划分与架构决策的文档化。