1. 项目概览为什么 UML 类图是架构师的必修课在我参与过的十几个中大型项目里几乎每次技术方案评审都会遇到同一个问题核心领域模型一旦超过 20 个类团队讨论就会陷入“你画的是继承我理解成组合”的混乱局面。而 UML 类图的六大关系就是终结这种混乱的行业标准。所谓 UML 类图六大关系指的是类与类之间六种结构化的静态关系泛化、实现、依赖、关联、聚合、组合。这六个概念是 UMLUnified Modeling Language统一建模语言中类图建模的地基。对系统架构师考试的人来说它们是案例分析题的高频考点对普通后端程序员来说它们是面向对象设计中判断“这个类该不该依赖那个类”“这里该用继承还是组合”的核心依据。这篇内容适合谁看如果你正在准备系统架构师考试、需要绘制技术方案中的类图、或者想把项目里越来越臃肿的领域对象做一次结构化梳理那这篇文章可以直接作为手边的速查手册。我会结合实际代码和绘图工具的操作经验包括 IDEA 自动生成类图、StarUML 手工建模、PlantUML 的 startuml 画图方式把这六种关系的代码特征、图元画法、易混淆点一次讲透。2. 六大关系的整体认知与判定思路2.1 先理解关系分组的底层逻辑很多初学者第一次看到六大关系时第一反应是背箭头形状泛化是空心三角形实线实现是空心三角形虚线依赖是虚线箭头关联是实线箭头聚合是空心菱形组合是实心菱形。但硬背是撑不到真实项目里的我见过太多人画图时对着图例反复查标注出来的关系依然错误。正确的打开方式是从耦合强度这个维度去理解。六大关系本质上描述的是两个类之间联系的紧密程度从弱到强排列是依赖 关联 聚合 组合而泛化和实现是另一条独立的轴描述的是“is-a是一个”的关系不参与耦合度比较。这就像区分人与人之间的关系泛化是“他和他的父亲有遗传上的相似”依赖是“我今天要用一下你的车”组合是“我和我的心脏不可分割”观察的角度根本不同。搞清楚这条逻辑链之后在项目里看到任意两个类先问两个问题第一它们之间是“类与类之间的使用/拥有/包含”还是“接口与实现/父类与子类”的关系第二如果是拥有关系生命周期是否绑定这两个问题能过滤掉 80% 的误判。2.2 判定关系时先看代码特征再看图元表达代码特征和 UML 图元是一一对应的我在实际工作中总结了一套判定顺序基本上十次有九次能直接命中正确关系先看 Java 代码里是否有extends关键字有就是泛化再看是否有implements关键字有就是实现然后看类里面是否持有另一个类的属性字段成员变量有就是关联可能是聚合也可能是组合需要进一步看初始化方式和生命周期如果只是方法参数、局部变量、静态方法调用中出现另一个类没有作为字段持有那多半是依赖确定是关联以后再判断生命周期整体创建时部分是否一并创建、整体销毁时部分是否一并销毁是则组合否则聚合。这套流程我在 IDEA 中生成类图后复核关系时每次都会用效率很高。后面我写代码示例时也完全按这个顺序来讲。3. 六大关系逐一拆解代码与图示对照3.1 泛化Generalization泛化就是我们常说的继承描述的是“子类是父类的一种”这种语义。它是面向对象三大特性之一“继承”在 UML 中的体现。假设项目中有一个支付场景先定义了一个抽象类BasePayment然后有两个子类WechatPayment和AlipayPaymentpublic abstract class BasePayment { protected String merchantId; public abstract void pay(BigDecimal amount); public void refund(String orderId) { ... } } public class WechatPayment extends BasePayment { Override public void pay(BigDecimal amount) { ... } } public class AlipayPayment extends BasePayment { Override public void pay(BigDecimal amount) { ... } }在类图中泛化关系的表示是从子类画一条实线指向父类箭头端是空心三角形三角形的尖角指向父类方向。这条线的本质含义是“子类继承并可以覆写父类的行为两个类之间是纵向的层次关系”。实际项目中我见过最普遍的问题不是不会画而是滥用。一个经典的错误是为了复用两个方法强行让OrderService继承BaseService但二者根本没有“is-a”关系这属于设计层面的逻辑错误。系统架构师考试里也经常给出这种代码片段让考生判断类间关系是否合理如果答题时看不出这是错误泛化后面的设计题基本拿不到分。判断一个继承是不是合理泛化可以套一个替换原则的简单测试把子类对象当作父类类型来用业务逻辑是否依然成立。比如WechatPayment当作BasePayment处理支付、退款流程完全无感那就是正确的泛化如果把OrderService当作BaseService用业务上完全说不通。3.2 实现Realization实现关系描述的是类与接口之间的关系它和泛化很容易混淆因为类图上的箭头几乎一样唯一的区别是实线变成了虚线。实现关系在代码里长这样public interface Payable { void pay(BigDecimal amount); void refund(String orderId); } public class UnionPay implements Payable { Override public void pay(BigDecimal amount) { ... } Override public void refund(String orderId) { ... } }在类图中实现关系的画法是从UnionPay画一条指向Payable的虚线箭头箭头端同样是一个空心三角形。很多人在 StarUML 里画图时分不清这条线到底该选哪个工具其实记住一句话就够凡是类和接口之间的关系一律用带空心三角形的虚线。我在讲设计模式入门时经常拿支付接口做例子因为在真实的支付系统中团队往往先定一套PaymentGateway接口然后各家渠道各自实现。这种场景如果不用接口而用抽象类后期每接入一个渠道就要动继承关系改动成本极高。实现关系在架构层面存在的意义就是把“做什么”和“怎么做”彻底拆开这也是系统架构师考试中接口设计题的核心考点。3.3 依赖Dependency依赖是整个六大关系里耦合度最弱的它描述的是“一个类在某种场合下临时使用到另一个类”。划分依赖关系有一个代码层面的硬指标另一个类只出现在方法参数、方法返回值、方法内部局部变量或静态方法调用中没有成为当前类的成员变量。看这一段代码public class OrderService { public void export(ListOrder orders, ExcelExporter exporter) { exporter.export(orders); } public void sendNotify(User user) { NotifyClient.send(user.getMobile(), 订单已发货); } }OrderService在export方法中用到了ExcelExporter在sendNotify中调用了NotifyClient的静态方法。这两个类都只是临时出现在方法的执行流程里方法一结束连接就断了。这就是依赖。UML 类图中依赖关系的画法是从使用者指向被使用者一条带普通箭头的虚线。实际画图时要注意箭头方向很多人把方向画反。记住原则谁依赖谁箭头就从谁出发指向被依赖方。OrderService依赖ExcelExporter所以箭头从OrderService出发指向ExcelExporter。依赖关系在真实系统里其实大量存在但如果你画类图时把所有依赖都画上去整张图会变成一张混乱的蜘蛛网。我的建议是类图里只画关键的、跨模块的依赖同一个模块内部方法的临时调用关系可以省略。画图的目的从来不是“把所有关系堆出来”而是“让核心结构一目了然”。系统架构师考试的类图题目一般也不会考特别琐碎的依赖重点还是聚合和组合的判断这一点后面我会再展开。3.4 关联Association关联关系比依赖强一个级别它的代码标志非常明确一个类以成员变量的形式持有另一个类。关联可以是一对一、一对多、多对多方向可以是单向也可以是双向。先看一个最典型的单向关联public class Customer { private ListOrder orders; public void addOrder(Order order) { orders.add(order); } } public class Order { private String orderNo; }Customer持有ListOrder字段它知道Order的存在并能操作订单列表但Order对Customer一无所知。在类图中用一条带普通箭头的实线从Customer指向Order。如果要在图上表示一对多可以在箭头端点旁边标注1和*表示一个客户对应多个订单。关联关系本身不区分聚合和组合它是一个更宽的语义范围。判定关联的具体子类型需要进一步看生命周期这就引出我们接下来要讲的聚合和组合。我在项目实践中发现很多人分不清关联和依赖其实看代码很直接依赖是“方法结束时联系就断了”关联是“整个对象存活期间都一直知道对方存在”。一个类作为字段长期持有另一个类的引用意味着它们在生命周期上已经绑在了一起。3.5 聚合Aggregation聚合描述的是“整体与部分的关系但部分可以脱离整体而独立存在”。它是关联关系的一种强形式。代码上依然是成员变量持有但区别在于整体类创建时并不会连带创建部分类对象部分类对象在外面先创建好然后通过构造方法或 setter 方法传入。这就像汽车和轮胎的关系轮胎被拆下来以后仍然是一个可独立使用的物件。public class Car { private Engine engine; public Car(Engine engine) { this.engine engine; } } public class Engine { private String model; }Car持有Engine的引用但Engine对象在Car构造之前就已经存在了它可以被安装到另一辆车上继续使用。在 UML 类图中聚合关系是一条带空心菱形的实线空心菱形靠近整体Car这一端箭头指向部分Engine方向。可以这样记空心菱形像是一个“口”字形代表“容器”但容器没有完全锁死里面的东西是空心的。在真实的电商系统里聚合关系比较典型的例子是“购物车”和“商品条目”。购物车被清空后商品条目所指的那些商品依然存在于商品库中商品数据的生命周期完全不受购物车影响。画类图时遇到这种问题不要凭感觉先去代码里看构造逻辑是构造方法传入还是内部new出来的这一步能直接区分聚合和组合。3.6 组合Composition组合是六大关系里耦合度最强的它表示“整体与部分不可分离部分的生命周期由整体完全管理”。代码上的标志是整体类在内部直接new出部分类对象部分类无法在整体之外独立存在整体销毁时部分也随之销毁。典型例子是人和心脏的关系——心脏不能脱离人体单独工作。public class House { private Room livingRoom; private Room bedroom; public House() { this.livingRoom new Room(客厅); this.bedroom new Room(卧室); } } public class Room { private String name; public Room(String name) { this.name name; } }House在构造方法里直接new出了Room房间对象被创建出来后它的引用只存在于House实例内部House被回收时这些房间对象也失去引用随之一同被垃圾回收。UML 类图中组合关系的画法是用一条带实心菱形的实线实心菱形靠近整体端箭头指向部分方向。实心菱形就代表“整体死死锁住部分”不可分离。组合关系在业务系统里有一个非常经典的例子订单和订单项。订单被取消后订单项数据根本不可能单独留在系统里继续有意义它们随着订单的消失而消失。在系统架构师考试的类图题中组合和聚合是最容易出案例分析的地方考纲里经常给一段代码让判断是聚合还是组合判定的唯一依据就是生命周期管理方式。这一点我建议做题时养成习惯看到成员变量持有马上问一句“对方的对象是谁创建、谁销毁的”基本上不会做错。3.7 六大关系总结对照表关系类型代码特征生命周期耦合UML 图元画法典型场景泛化extends 继承抽象类/父类子类随父类结构约束实线 空心三角形箭头指向父类支付类的统一抽象实现implements 接口实现类遵循接口契约虚线 空心三角形箭头指向接口支付渠道接入接口依赖方法参数/局部变量/静态调用方法调用期间临时存在虚线 普通箭头指向被依赖方订单导出工具类关联成员变量持有整体与部分同期存活实线 普通箭头指向被持有方客户持有订单列表聚合成员变量持有 外部传入部分可独立于整体实线 空心菱形靠近整体汽车持有外部传入的引擎组合成员变量持有 内部 new部分随整体销毁实线 实心菱形靠近整体订单持有内部创建的订单项4. 从零画一张类图工具实操与常见误区4.1 先用 IDEA 自动生成类图建立坐标很多人在 StarUML 里面对空白画布不知道从哪里下手我的经验是不要在白纸上徒手画先用 IntelliJ IDEA 的类图功能把现有代码的结构反向生成出来然后再在生成结果上调整关系线。具体操作路径是在 IDEA 中选中一个包右键选择Diagrams - Show Diagram或者直接使用快捷键CtrlAltShiftU。它会自动分析包内所有类的继承、实现、关联关系然后把类图画出来。这个功能生成的图默认会把关联关系用实线标出泛化和实现用对应箭头标出省去了一大半手工绘制的体力活。你只需要在此基础上对聚合和组合关系做二次调整因为 IDE 无法从代码中智能判断生命周期语义它只能看到“持有引用”这一层至于这个引用是外部传入还是内部new需要人工根据构造逻辑去标注。我自己的习惯流程是先在 IDEA 里生成整体包结构图确认泛化和实现关系无误然后逐个类检查成员变量判断聚合和组合最后隐藏掉不重要的依赖关系线导出为图片或复制到架构设计文档中。这样画出来的类图既准确又高效比打开 StarUML 从零开始拖拽快很多。4.2 使用 StarUML 手工建模的注意点StarUML 是很多系统架构师考试考生和开发者常用的桌面建模工具。它支持直接拖拽 Class 到画布上然后通过工具栏中的各种关系线连接类。使用时有几个容易踩的坑第一关系线的连线顺序很容易搞错方向。许多初学者画聚合时把空心菱形放到了部分那端画依赖时把虚线箭头方向画反。请记住一个通用口诀菱形总是靠近“整体”三角形总是靠近“父类/接口”普通箭头总是靠近“被指向方”。第二StarUML 中类的属性可见性符号容易漏。表示 public-表示 private#表示 protected。如果画类图时这些可见性符号缺失或标错考试阅卷时会直接扣分项目中也会让看图的同事困惑。第三画完图后一定要检查关联线的 multiplicity重数也就是一对多关系中的1、*、0..*这些标注。它们直接影响数据库表的关联设计。我见过项目里因为漏标1..*导致开发阶段物理模型设计返工的情况这类小细节在画图时看起来不打眼设计评审时被 DBA 指出来相当尴尬。4.3 用 PlantUML 的 startuml 命令快速输出类图如果你更习惯用代码描述类图或者需要在 Markdown 文档中快速嵌入类图PlantUML 是很好的选择。它以文本形式定义类与关系配合 GitHub 或本地渲染环境输出图片。初始语法很简单startuml class BasePayment { # merchantId : String pay(amount: BigDecimal): void refund(orderId: String): void } class WechatPayment class AlipayPayment BasePayment |-- WechatPayment BasePayment |-- AlipayPayment interface Payable { pay(amount: BigDecimal): void refund(orderId: String): void } class UnionPay Payable |.. UnionPay enduml在 PlantUML 语法中|--表示泛化|..表示实现..表示依赖--表示关联o--表示聚合*--表示组合。这些符号在网上搜索 “staruml类图怎么画” 时很难找到这么完整的对照自己整理一份放到笔记里会非常方便。PlantUML 最让我满意的场景是技术方案评审前的快速迭代。比如评审时大家认为聚合组合关系标错了直接用文本改一行符号就能重新生成图片不需要像桌面建模工具那样去拖拽调整线条。不过它也有天然短板布局自动生成复杂的类图连线会比较乱想要精确控制位置时不如 StarUML 灵活。需要提交正式架构文档时我通常先用 PlantUML 定稿关系再在 StarUML 里微调布局。5. 系统架构师考试中的类图考点与实战经验5.1 考试中常见的三种命题形式系统架构师考试对 UML 类图六大关系的考查不是简单让你背定义而是融入案例分析和论文场景。我在备考和实际考试接触下来的经验是命题集中在三种形式第一种是“类图纠错题”。题目给出一段 Java 或 C# 代码以及一张已经画好的类图让你指出其中关系标注错误的地方。这种题考查的核心就是代码特征与关系图元的一一对应难点在于出题人往往会把聚合和组合故意标反、把依赖和关联故意混淆。应对方法是严格按前面说的判定顺序逐行读代码。第二种是“关系补全题”。给出一段业务描述和几个关键类让你补全类图的关系线。这里要注意读题时优先识别“整体-部分”语义比如“订单包含订单项”“部门包含员工”这类描述对应的是组合还是聚合要看题里是否强调部分可否独立存在。第三种是“设计评价题”。结合设计原则如单一职责、依赖倒置让你评价类图设计的合理性。这种题往往隐藏着一个陷阱候选图里泛化和实现泛滥接口被大量具体类直接实现导致系统扩展性差。解答时要从关系选择的角度说明哪里违反了什么原则。5.2 我在实际考试中总结的答题技巧考场上时间有限做类图题时我有一套固定的打草稿套路先圈出所有extends和implements把这五到六条关系线直接定死再找所有成员变量用圆圈标出持有关系最后看每个持有关系的创建逻辑是外部传入标聚合内部new标组合。整套动作在两分钟内完成正确率基本能保证。还有一个容易被忽视的点就是依赖关系在考试里经常以“工具类调用”的形式出现。比如业务类中调用了DateUtils的静态方法这种依赖关系规模小但题目要求全量标注时不能漏。我从多次模拟题中发现漏标依赖是很多考生丢分的重灾区。只要题目没有明确说“仅标注关联关系或继承关系”那么代码中出现的一切临时使用关系都要画成虚线箭头。在准备案例论文时类图也是高频素材。我的建议是准备一个自己实际做过的完整领域模型比如商城订单系统把六大关系都在这个模型里对应一遍。考试时无论论文题目怎么变都能从这个模型出发迁移。我当年是把订单、商品、用户、支付、物流五类对象的关系图背熟考场上直接复用节省了大量构思时间。5.3 工程实践中的类图维护节奏除了应付考试类图在项目里的实际维护节奏也值得说一句。很多团队在建项初期画出类图后代码迭代三个月以后类图就沦为摆设。我见过最好的实践是把类图纳入 Code Review 流程凡是涉及新增类或调整继承结构的变更必须由提交人同步更新类图。在代码评审工具中夹一张最新的类图截图这比几十行文字描述更容易让评审人理解改动影响面。另一个工程实践技巧是利用 IDEA 的类图导出功能做模块边界审计。每两周导出一次核心模块的类图然后扫描图中的依赖箭头集中区域。如果某个模块的类大量依赖另一个模块的实体这就是耦合过度的信号。我过去用这个方法发现过好几次隐藏在业务代码里的循环依赖类图上两条箭头互相指向对方一眼就能看出问题。6. 高频疑问与资料路线给不同背景读者的建议6.1 初学者常问的三个问题第一个疑问是“关联和依赖到底怎么一眼区分”。我的回答始终是直接看字段还是看方法。成员变量出现对方类型就是关联只在方法体内或参数上出现就是依赖。如果你现在负责的代码库是 PHP、Python 这类动态语言那就看__construct或__init__中是否赋值给self的属性以及类中是否有self.xxx yyy这样的语句。动态语言没有类型声明这个判断过程会费力一点但原理完全一致。第二个疑问是“聚合和组合判断时如果对象创建逻辑比较复杂怎么办”。比如对象不是直接new的而是从工厂方法里取到的甚至是通过依赖注入容器装配的。这种情况建议从业务生命周期推断如果整体删除了部分是否需要级联删除订单删掉订单项必须删这是组合购物车删掉购物车条目消失但商品仍在这是聚合。生命周期永远是最可靠的标准。第三个疑问是“画类图时依赖要不要全画”。成熟的做法是分层决策架构图层级只画跨模块的依赖模块内部的核心关系图再画详细依赖。一张图承载的信息量有限画全依赖的代价是阅读成本的指数级上升真正评审时没人会盯着几十条虚线看。考试中为了拿到全部分数才需要全画项目文档中要克制。6.2 不同身份读者的学习路线建议如果你是准备系统架构师考试的考生重点放在“给定代码判断关系”的刷题上历年真题里的类图题刷三遍以上另外注意把《系统架构设计师教程》中 UML 章节的图例背诵熟练。考试不要求你用工具但要求在限定时间内准确画出图元。如果你是后端开发工程师重点放在 sketch 级别的类图绘制上学会用 IDEA 生成类图后再人工精修。平时做技术设计时坚持先画类图再写代码两周之后你对六大关系的敏感度会有明显提升。如果你是想加深设计功底的架构师建议把六大关系作为代码评审的检查清单。每次评审时逐条检查新代码中的关系使用是否合理有没有可以被接口替换的继承、有没有可以改成组合的继承、有没有隐藏着生命周期问题的聚合。这些问题的答案本身就是代码质量的体检报告。我个人在实际项目里最大的体会是只有把六大关系内化成一种“条件反射”看到代码就能联想到图形画类图才能从一项任务变成一种沟通工具。这个过程没有捷径多画几张、多踩几个坑自然就熟了。