1. 类图到底在解决什么问题很多人第一次接触UML都是从类图开始的。打开画图工具拖几个方框写上类名画几条线连起来感觉像是完成了一项任务。但真正做过几个项目之后你会发现类图这东西画得对不对、有没有用跟画得好不好看完全是两码事。我见过太多团队把类图画成了“给领导看的装饰品”画完之后没人再看第二眼代码该乱还是乱。问题出在哪出在画图的人自己就没想清楚类图到底在解决什么问题。类图的核心价值用一句话概括它是在编码之前把系统里“有哪些东西”“这些东西各自能干什么”“它们之间怎么打交道”这三件事用图形化的方式固定下来。注意我的用词——“固定下来”。这意味着类图是一种契约一种共识一种在团队之间传递设计意图的载体。你画了一个订单类里面有一个计算总价的私有方法那写代码的人就知道这个方法不应该被外部直接调用你画了订单和商品之间是一对多关系那建表的人就知道外键该放在哪一边。这些信息如果只存在于某个人的脑子里项目稍微大一点就会出问题。那为什么是类图而不是别的图UML一共有十几种图用例图描述的是系统能做什么时序图描述的是某个具体场景下对象之间怎么交互状态图描述的是单个对象在生命周期里的状态变化。类图是唯一一种静态结构图它不关心“什么时候发生什么”只关心“有什么、长什么样、怎么连”。这个定位决定了它的使用场景当你需要向别人解释系统的骨架时类图是最直接的表达方式。比如新同事入职你给他看十张时序图他可能还是不知道系统里有哪些核心实体但你给他看一张类图五分钟他就能把主要概念和它们之间的关系理清楚。还有一个常见的误解类图只适用于面向对象编程。实际上不是。类图描述的是“概念模型”它跟具体用什么语言实现没有必然关系。你用Java写类图里的类可以直接映射到Java类你用Python写类图里的类可以映射到Python的类或者模块哪怕你用C写过程式代码类图依然可以用来描述数据结构之间的关系。我做过一个嵌入式项目底层全是C代码但我们在设计阶段依然画了类图把传感器、控制器、通信模块这些概念之间的关系理清楚后面写代码的时候结构非常清晰。所以不要把类图跟“面向对象”绑死它本质上是一种概念建模工具。适合看这篇内容的人我大致分三类。第一类是刚学UML的学生或者转行的开发者课本上的类图符号一大堆什么聚合、组合、依赖、关联看得头晕不知道哪些在实际工作中真正用得上。第二类是有一定经验但没系统画过类图的开发者平时写代码靠直觉设计靠拍脑袋想补上设计表达这一课。第三类是技术负责人或者架构师需要给团队建立设计规范想知道类图应该画到什么颗粒度、哪些该画哪些不该画。这三类人的需求不一样但核心诉求是相同的让类图真正服务于开发而不是走个形式。2. 类图的核心元素与关系拆解2.1 一个类框里到底该放什么类图里最基本的元素就是类框一个矩形分成三格类名、属性、方法。看起来简单但实际画的时候问题最多。先说类名类名应该是一个名词而且应该是业务领域里的概念不是技术实现细节。我见过有人把类名写成“OrderServiceImpl”这就把实现细节暴露在概念模型里了不好。概念模型应该叫“Order”至于它背后是不是有一个ServiceImpl的实现那是代码层面的事类图不关心。属性那一格写的是这个类“知道什么”。比如订单类有订单号、下单时间、总金额、状态这些属性。这里有一个关键决策属性写到什么颗粒度。如果你把订单里每一个字段都列出来类图会变得极其臃肿而且很多字段是技术性的比如创建人ID、更新时间戳对理解业务概念没有帮助。我的经验是只写那些对理解业务规则有意义的属性。比如“状态”这个属性很重要因为订单状态决定了它能做什么操作“总金额”很重要因为它是计算出来的核心结果。至于“创建时间”这种审计字段除非业务逻辑依赖它否则可以不写。这个取舍没有绝对标准但原则是看类图的人能不能通过属性理解这个类的核心职责。方法那一格写的是这个类“能做什么”。这里最常见的错误是把所有getter/setter都写上去。完全没有必要。方法应该只写那些体现业务行为的。比如订单类有“计算总价”“提交订单”“取消订单”这些方法这些是业务行为值得写。而“setStatus”“getStatus”这种纯数据访问方法写上去只会让图变得嘈杂。还有一个技巧如果某个方法是私有的可以在方法名前面加一个减号-公开的加加号保护的加井号#。这个可见性标记在团队协作时很有用它告诉读图的人哪些方法是内部实现细节哪些是对外暴露的接口。注意类图不是代码的逐行翻译。如果你发现类图里的方法和代码里的方法一一对应那说明你画得太细了。类图应该比代码高一个抽象层级它描述的是设计意图不是实现细节。2.2 六种关系哪些真正常用类图里的关系符号是最让人头疼的部分。依赖、关联、聚合、组合、泛化、实现六种关系每种都有不同的箭头和线条样式。很多教程会花大量篇幅讲这些符号的区别但实际工作中真正高频使用的只有三四种。我先把六种关系过一遍然后告诉你哪些值得花时间搞清楚。泛化就是继承画成一条实线加空心三角箭头箭头指向父类。这个最直观没什么歧义。实现是类实现接口画成虚线加空心三角箭头箭头指向接口。这两个在Java、C#这类语言里天天用画起来也简单。依赖画成虚线加普通箭头表示一个类“临时使用”另一个类。比如订单服务在处理支付的时候临时需要一个支付网关对象来发请求但订单服务本身不持有支付网关的引用。依赖关系的特点是短暂、偶然通常体现在方法参数或者局部变量里。关联画成实线加普通箭头表示一个类“长期持有”另一个类的引用。比如订单类里有一个客户对象的成员变量这就是关联。关联和依赖的区别在于生命周期关联是长期的、结构性的依赖是临时的、行为性的。聚合和组合是关联的两种特殊形式都表示“整体-部分”关系。聚合画成实线加空心菱形菱形在整体那一端组合画成实线加实心菱形菱形也在整体那一端。区别在于部分能否独立于整体存在。聚合的例子一个团队有多个成员团队解散了成员还在这就是聚合。组合的例子一个订单有多个订单项订单删除了订单项也没有意义了这就是组合。组合的耦合度比聚合高整体负责管理部分的创建和销毁。实际工作中我的建议是泛化、实现、关联、依赖这四个必须搞清楚聚合和组合知道概念即可画图时不必过分纠结。为什么因为聚合和组合的区分在代码层面往往体现为“部分对象是不是在整体对象内部new出来的”这个细节在概念模型阶段并不重要。很多团队画图时干脆把聚合和组合都画成普通关联然后在旁边加文字注释说明生命周期关系这样反而更清晰。我见过有人为了区分聚合和组合争论半小时最后代码写出来发现两种方式都行得通那争论的意义就不大。关系类型线条样式语义代码体现使用频率泛化实线空心三角继承extends高实现虚线空心三角实现接口implements高关联实线普通箭头长期持有引用成员变量高依赖虚线普通箭头临时使用方法参数/局部变量高聚合实线空心菱形整体-部分可独立成员变量外部传入中组合实线实心菱形整体-部分不可独立成员变量内部创建中2.3 多重性标注别小看那个数字关系线两端的数字标注学名叫多重性。常见的有1、0..1、、1..、0..。这个标注看起来不起眼但它传递的信息量非常大。比如订单和订单项之间标了1对1..意思是“一个订单至少有一个订单项”这个“至少一个”就是业务规则。如果开发人员没注意到这个约束写代码的时候就可能允许创建一个空订单这就是bug的源头。多重性标注的常见错误是只标一边。比如画了订单到客户的关联只在订单那边标了“*”客户那边什么都没标。这就有歧义了一个客户可以有多少个订单是0个、1个还是多个读图的人只能猜。正确的做法是两端都标清楚。还有一个错误是标注跟业务规则不一致。比如业务上规定一个客户可以有多个订单但画图的时候随手标了个1后面开发就按1对1来设计等到需求变更的时候才发现要改表结构。这种坑我踩过不止一次后来养成了习惯每画一条关系线先问自己两端的多重性分别是什么写下来再画。提示多重性标注是类图里性价比最高的信息。一个数字就能表达一条业务约束比写一段文字说明直观得多。画图时宁可多花十秒钟确认多重性也不要留空。3. 从零画一张能用的类图3.1 先定边界再找实体画类图最怕上来就画。打开工具就开始拖方框画到一半发现漏了核心概念或者画了一堆不需要的类返工成本很高。我的做法是分三步走定边界、找名词、筛实体。定边界的意思是先明确这张类图描述的是哪个范围。是整个系统还是某个子系统还是某个业务模块范围不同类图的颗粒度完全不同。如果画整个电商系统那类图里可能有几十个类根本看不清如果只画订单模块那类图里可能就七八个类清晰明了。我的经验是一张类图控制在5到15个类之间超过15个就拆成多张用包图或者分组框来组织。这个数量不是拍脑袋定的而是基于人的认知负荷一张图里超过15个元素读图的人就很难在脑子里建立完整的结构关系。找名词的方法很土但很有效把需求文档或者用户故事里所有的名词圈出来。比如“用户下单后系统生成订单订单包含多个商品每个商品有价格和数量订单关联收货地址和支付方式”。这段话里的名词有用户、订单、商品、价格、数量、收货地址、支付方式。这些名词就是候选实体。注意“价格”和“数量”在这里是商品的属性还是独立实体如果价格会随时间变化、需要记录历史价格那它可能是一个独立的“价格记录”实体如果只是下单那一刻的快照那它就是订单项的一个属性。这个判断需要结合业务需求来做。筛实体的标准有三个有身份标识、有生命周期、有业务行为。有身份标识的意思是它能被唯一区分比如订单有订单号商品有商品编码。有生命周期的意思是它从创建到销毁有一个过程比如订单从创建到完成或取消。有业务行为的意思是它不只是数据的容器还有自己的逻辑比如订单能计算总价、能取消、能退款。三个条件满足两个以上就值得作为独立类画出来。只满足一个的大概率是另一个类的属性。3.2 关系梳理的实操顺序实体找出来之后下一步是梳理关系。我的习惯顺序是先泛化再组合后关联最后依赖。为什么是这个顺序因为泛化关系决定了类的层次结构它是最稳定的先定下来后面不容易变。组合关系决定了哪些类必须一起存在它影响模块划分。关联关系是类之间的引用相对灵活。依赖关系最临时放在最后画而且很多依赖关系在概念模型阶段可以省略。具体操作时拿一张纸或者打开工具把筛选出来的类先摆开然后逐个问三个问题这个类跟哪个类有“是一种”的关系这个类跟哪个类有“整体-部分”的关系这个类需要知道哪个类的信息才能完成自己的职责第一个问题找出泛化第二个问题找出组合或聚合第三个问题找出关联。依赖关系不用刻意找画完关联之后那些没有关联但有交互的类之间自然就是依赖。这里有一个容易忽略的点关系的方向。关联关系是有方向的箭头从“知道对方”的类指向“被知道”的类。比如订单知道客户是谁但客户不需要知道订单从客户这个类的职责来看它不负责管理订单那箭头就从订单指向客户。方向搞反了读图的人会误解类的职责划分。我见过一张图客户和订单之间画了双向箭头问画图的人为什么双向他说“客户能查自己的订单啊”。这就是把“查询操作”和“结构关系”混为一谈了。客户能查订单是通过订单服务或者订单仓库来查的不代表客户类里要持有一个订单列表的引用。结构关系要看类的成员变量不是看业务操作。3.3 属性与方法的填充策略关系和结构定下来之后再往类框里填属性和方法。这个顺序很重要先定关系后填细节。因为关系决定了类的职责边界职责边界清楚了属性和方法自然就知道该放哪。如果先填属性和方法很容易出现“这个属性到底该放A类还是B类”的纠结因为职责边界还没定。填属性的时候我遵循一个原则只写业务属性不写技术属性。业务属性是业务人员能看懂的比如订单金额、商品名称、收货地址。技术属性是开发人员关心的比如主键ID、创建时间、版本号、删除标记。技术属性在类图里写不写我的做法是不写或者最多写一个“id”作为身份标识。原因很简单类图是给团队看的包括产品经理和测试人员技术属性对他们来说是噪音。而且技术属性往往跟具体的持久化方案绑定概念模型阶段还没定用MySQL还是MongoDB写这些属性没有意义。填方法的时候只写public的业务方法。私有方法除非特别重要比如某个核心算法否则不写。构造方法不写。getter/setter不写。方法的命名用动词名词的形式比如“计算总价”“提交订单”“取消订单”。参数和返回值在概念模型阶段可以省略或者只写类型不写参数名。如果某个方法特别关键可以在方法名后面加一个简短的注释说明它的业务规则比如“计算总价含运费和折扣”。这个注释比画一堆细节更有用。注意类图里的方法不是越多越好。一个类如果列了十几个方法读图的人根本记不住。我的经验是每个类的方法控制在5个以内只保留最核心的业务行为。那些辅助性的、工具性的方法在类图里省略不影响理解。4. 类图落地时的常见坑与排查4.1 画完没人看问题出在哪类图画完没人看这是最常见也最致命的问题。我分析过原因大概有三种。第一种是画得太细把类图当成了代码的图形化版本每个字段每个方法都列上去读图的人一看就头大直接跳过。第二种是画得太抽象只有类名和几条线没有任何属性和方法读图的人不知道这些类到底干什么用看了等于没看。第三种是画完就锁进文档库后续代码改了类图不改类图和代码脱节慢慢就没人信了。针对第一种解决办法是分层画图。概念层只画类名和关系不画属性和方法用于跟产品经理对齐业务概念设计层画核心属性和关键方法用于指导开发实现层才画完整的属性和方法用于生成代码或者写详细设计文档。大部分场景下设计层就够了。针对第二种解决办法是给每个类写一句话职责说明放在类名下方或者用注释框标注。这句话不用长十个字以内比如“订单管理订单生命周期和金额计算”。这一句话就能让读图的人快速理解类的定位。针对第三种解决办法是把类图纳入代码评审流程每次有结构性变更的时候先改类图再改代码让类图成为设计讨论的起点而不是事后补的作业。还有一个容易被忽略的点类图的可读性。同样一张图布局好坏对理解成本影响巨大。我的布局原则是继承关系从上到下关联关系从左到右核心类放中间辅助类放边缘。线条尽量不要交叉如果交叉不可避免用跳线或者调整布局来减少视觉干扰。颜色不要用太多两三种就够了比如核心领域类用一种颜色辅助类用另一种颜色。这些细节看起来是小事但实际用起来差别很大。4.2 类图与代码不一致怎么破类图和代码不一致几乎是所有团队的通病。原因很简单代码是活的类图是死的。代码天天改类图改一次管半年。要解决这个问题靠“提高意识”没用得靠机制。我试过几种做法说下效果。第一种是代码生成类图。很多IDE和建模工具支持从代码反向生成类图比如IntelliJ IDEA的Diagrams功能、PlantUML的代码扫描插件。这个做法的好处是类图永远跟代码一致坏处是生成的图往往太细包含大量技术细节可读性差。我的用法是用反向生成做差异检查定期跑一次看看代码里多了哪些类、少了哪些关系然后手动更新设计层的类图。这样既保证了准确性又保持了可读性。第二种是类图即代码。用PlantUML或者Mermaid这样的文本化建模工具把类图写成代码跟项目代码一起提交到版本库。这样类图的变更历史可追溯而且修改成本低。PlantUML的语法很简单画一个类就几行代码改起来比拖拽工具快得多。我现在的习惯是设计讨论的时候直接在文档里写PlantUML代码讨论完了代码也写完了直接提交。这个做法特别适合敏捷团队因为类图可以跟着迭代快速更新。第三种是只画核心结构。不是所有类都值得画进类图。我的做法是只画领域模型也就是业务核心概念之间的关系那些技术性的类工具类、配置类、框架适配类不画。领域模型相对稳定变更频率低维护成本也就低。至于技术类的结构用包图或者模块图来表达就够了不需要精确到类级别。问题现象根因解决思路实操建议类图太细没人看把实现细节画进去了分层画图概念层/设计层/实现层分开设计层只画核心属性和关键方法类图太抽象看不懂缺少职责说明每个类加一句话职责注释注释控制在10字以内类图与代码脱节缺少更新机制文本化建模版本库管理用PlantUML写类图跟代码一起提交关系方向画反混淆结构关系和操作关系看成员变量定方向不看业务操作问自己“这个类里有没有对方的引用”多重性标注缺失画图时没想清楚业务规则每条关系线两端都标多重性标注前先跟业务方确认约束4.3 团队协作中的类图规范团队一起画类图最怕风格不统一。A画的类图用圆角矩形B画的用直角矩形A把属性写在方法上面B反过来A用中文命名B用英文命名。这些不一致看起来是小事但放在一起就是灾难。我的建议是团队在开始画类图之前先花半小时定一个最小规范不用太复杂覆盖以下几点就够了。命名规范类名用单数名词首字母大写不用下划线属性名用小驼峰方法名用动词开头的小驼峰。语言上统一用英文还是中文团队自己定但必须统一。我倾向于用英文因为跟代码一致减少翻译成本。但如果团队的产品经理需要直接读图用中文也完全可以关键是统一。颗粒度规范明确哪些类必须画哪些可以不画。比如领域实体必须画工具类不画接口画不画看情况。属性和方法写到什么程度也定一个标准比如“只写业务属性和public业务方法”。这个标准写在一页纸的文档里新成员进来先看这个文档。工具规范统一用同一个工具。PlantUML、draw.io、StarUML、Visual Paradigm选一个团队用得顺手的不要混用。混用会导致格式不兼容合并的时候很麻烦。如果团队用Git管理文档强烈建议用PlantUML这种文本化工具diff和merge都方便。提示规范不用追求完美先定一个能用的版本跑一两个迭代再调整。最怕的是花两周时间讨论规范结果一张图都没画。5. 类图在不同场景下的变通用法5.1 快速沟通场景白板类图不是所有类图都需要用工具画。很多时候最快的沟通方式是在白板上画草图。白板类图的特点是快、糙、够用。不用纠结线条样式不用管多重性标注甚至不用写全类名写个缩写就行。关键是快速把结构关系表达出来让讨论有焦点。我常用的白板类图画法是方框代表类里面只写类名关系用箭头表示箭头旁边写个数字表示多重性如果某个类特别重要在方框下面写一行职责说明。就这些。五分钟能画完一个模块的结构然后大家对着图讨论哪里有问题。讨论完了拍张照片会后用工具整理成正式版本。这个流程比直接上工具画效率高得多因为白板允许犯错允许涂改思维不会被工具束缚。白板类图还有一个好处它天然是协作的。工具画图往往是一个人画、其他人看白板画图是大家一起画、一起改。我见过很多设计决策是在白板前争论出来的而不是在文档里写出来的。所以如果你的团队还在用“一个人画完发群里”的方式做设计可以试试改成“白板前一起画”效果会好很多。5.2 文档沉淀场景PlantUML文本化类图需要把类图沉淀到文档里的时候我首选PlantUML。原因很简单文本格式版本可控修改成本低。一段PlantUML代码几十行放在Markdown文档里跟文字混排阅读体验很好。而且PlantUML的语法很直观没学过的人也能看懂个大概。画一个订单模块的类图PlantUML代码大概长这样startuml class Order { - orderId: String - status: OrderStatus - totalAmount: BigDecimal calculateTotal(): BigDecimal submit(): void cancel(): void } class OrderItem { - quantity: int - unitPrice: BigDecimal subtotal(): BigDecimal } class Customer { - customerId: String - name: String } class Address { - province: String - city: String - detail: String } Order 1 *-- 1..* OrderItem Order 0..* -- 1 Customer Order 1 -- 1 Address enduml这段代码渲染出来的图结构清晰关系明确。关键是它可以跟代码一起放在版本库里每次修改都有记录。如果团队用Confluence或者语雀写文档PlantUML插件可以直接渲染不需要额外装工具。如果团队用GitHub或者GitLabMarkdown里的PlantUML代码块也能通过插件渲染。这个方案的迁移成本很低值得推广。5.3 代码审查场景用类图做设计评审类图还有一个被低估的用法做代码审查的辅助工具。代码审查的时候如果只看diff很难判断一个改动对整体结构的影响。但如果有一张类图审查者可以快速判断新增的这个类放在哪个位置合适它跟现有类的关系是否合理有没有引入不必要的耦合我的做法是在提交涉及结构性变更的代码时附带一张更新后的类图。不需要很详细标出新增的类、修改的关系就行。审查者对着类图看代码比只看代码效率高得多。这个做法还有一个副作用它倒逼开发者在写代码之前先想清楚结构因为如果结构不合理类图上一眼就能看出来。我试过一段时间之后团队里“先写代码再补设计”的情况明显减少了。6. 我踩过的坑和总结出的几条经验说几个我实际踩过的坑都是教科书上不会写的。第一个坑过度设计。刚开始画类图的时候总想把所有可能性都考虑到画了一堆抽象类和接口结果代码写出来发现根本用不上。后来我学乖了类图只画当前迭代需要的东西未来的扩展点用注释标一下就行不用真的画出来。YAGNI原则在类图设计上同样适用。第二个坑关系画得太满。每个类之间都画关系图看起来密密麻麻实际上很多关系是间接的、可以推导出来的。比如A关联BB关联C那A和C之间就不需要再画一条线。类图应该表达直接关系间接关系让读图的人自己推导这样图才清爽。第三个坑忽略非功能需求。类图只表达了结构但性能、并发、事务这些非功能需求在类图上是看不出来的。比如订单和库存之间类图上画一条关联就完了但实际代码里要考虑并发扣减、分布式事务。这些信息如果不在类图旁边用注释说明开发人员可能会忽略。我的做法是在关键类或者关键关系旁边加一个注释框写清楚非功能约束比如“扣减库存需要加锁”。第四个坑把类图当文档交付物。有一段时间项目要求每个模块都必须提交类图作为交付物结果大家为了交差而画图画完就扔没有任何实际价值。后来我们改了做法类图只在设计讨论和代码评审两个场景下使用不强制交付。反而大家画得更认真了因为画图是为了解决问题不是为了交作业。最后分享一个我觉得最实用的经验类图的价值在于画的过程不在于画的结果。你花两个小时画一张类图最大的收获不是那张图本身而是画图过程中你对系统结构的思考。哪些类该合并、哪些关系该拆开、哪些职责放错了位置这些问题在画图的时候会自然浮现出来。所以我的建议是不管最终画得好不好看先画起来。画完再改改完再画迭代两三轮之后你对系统的理解会完全不一样。至于那张图最后是贴在墙上还是锁进文档库反而不重要了。 
长河君 · 2026/11/3 20:28:29 · 阅读 1.2k UML类图实战指南：从核心元素到落地避坑
1. 类图到底在解决什么问题很多人第一次接触UML都是从类图开始的。打开画图工具拖几个方框写上类名画几条线连起来感觉像是完成了一项任务。但真正做过几个项目之后你会发现类图这东西画得对不对、有没有用跟画得好不好看完全是两码事。我见过太多团队把类图画成了“给领导看的装饰品”画完之后没人再看第二眼代码该乱还是乱。问题出在哪出在画图的人自己就没想清楚类图到底在解决什么问题。类图的核心价值用一句话概括它是在编码之前把系统里“有哪些东西”“这些东西各自能干什么”“它们之间怎么打交道”这三件事用图形化的方式固定下来。注意我的用词——“固定下来”。这意味着类图是一种契约一种共识一种在团队之间传递设计意图的载体。你画了一个订单类里面有一个计算总价的私有方法那写代码的人就知道这个方法不应该被外部直接调用你画了订单和商品之间是一对多关系那建表的人就知道外键该放在哪一边。这些信息如果只存在于某个人的脑子里项目稍微大一点就会出问题。那为什么是类图而不是别的图UML一共有十几种图用例图描述的是系统能做什么时序图描述的是某个具体场景下对象之间怎么交互状态图描述的是单个对象在生命周期里的状态变化。类图是唯一一种静态结构图它不关心“什么时候发生什么”只关心“有什么、长什么样、怎么连”。这个定位决定了它的使用场景当你需要向别人解释系统的骨架时类图是最直接的表达方式。比如新同事入职你给他看十张时序图他可能还是不知道系统里有哪些核心实体但你给他看一张类图五分钟他就能把主要概念和它们之间的关系理清楚。还有一个常见的误解类图只适用于面向对象编程。实际上不是。类图描述的是“概念模型”它跟具体用什么语言实现没有必然关系。你用Java写类图里的类可以直接映射到Java类你用Python写类图里的类可以映射到Python的类或者模块哪怕你用C写过程式代码类图依然可以用来描述数据结构之间的关系。我做过一个嵌入式项目底层全是C代码但我们在设计阶段依然画了类图把传感器、控制器、通信模块这些概念之间的关系理清楚后面写代码的时候结构非常清晰。所以不要把类图跟“面向对象”绑死它本质上是一种概念建模工具。适合看这篇内容的人我大致分三类。第一类是刚学UML的学生或者转行的开发者课本上的类图符号一大堆什么聚合、组合、依赖、关联看得头晕不知道哪些在实际工作中真正用得上。第二类是有一定经验但没系统画过类图的开发者平时写代码靠直觉设计靠拍脑袋想补上设计表达这一课。第三类是技术负责人或者架构师需要给团队建立设计规范想知道类图应该画到什么颗粒度、哪些该画哪些不该画。这三类人的需求不一样但核心诉求是相同的让类图真正服务于开发而不是走个形式。2. 类图的核心元素与关系拆解2.1 一个类框里到底该放什么类图里最基本的元素就是类框一个矩形分成三格类名、属性、方法。看起来简单但实际画的时候问题最多。先说类名类名应该是一个名词而且应该是业务领域里的概念不是技术实现细节。我见过有人把类名写成“OrderServiceImpl”这就把实现细节暴露在概念模型里了不好。概念模型应该叫“Order”至于它背后是不是有一个ServiceImpl的实现那是代码层面的事类图不关心。属性那一格写的是这个类“知道什么”。比如订单类有订单号、下单时间、总金额、状态这些属性。这里有一个关键决策属性写到什么颗粒度。如果你把订单里每一个字段都列出来类图会变得极其臃肿而且很多字段是技术性的比如创建人ID、更新时间戳对理解业务概念没有帮助。我的经验是只写那些对理解业务规则有意义的属性。比如“状态”这个属性很重要因为订单状态决定了它能做什么操作“总金额”很重要因为它是计算出来的核心结果。至于“创建时间”这种审计字段除非业务逻辑依赖它否则可以不写。这个取舍没有绝对标准但原则是看类图的人能不能通过属性理解这个类的核心职责。方法那一格写的是这个类“能做什么”。这里最常见的错误是把所有getter/setter都写上去。完全没有必要。方法应该只写那些体现业务行为的。比如订单类有“计算总价”“提交订单”“取消订单”这些方法这些是业务行为值得写。而“setStatus”“getStatus”这种纯数据访问方法写上去只会让图变得嘈杂。还有一个技巧如果某个方法是私有的可以在方法名前面加一个减号-公开的加加号保护的加井号#。这个可见性标记在团队协作时很有用它告诉读图的人哪些方法是内部实现细节哪些是对外暴露的接口。注意类图不是代码的逐行翻译。如果你发现类图里的方法和代码里的方法一一对应那说明你画得太细了。类图应该比代码高一个抽象层级它描述的是设计意图不是实现细节。2.2 六种关系哪些真正常用类图里的关系符号是最让人头疼的部分。依赖、关联、聚合、组合、泛化、实现六种关系每种都有不同的箭头和线条样式。很多教程会花大量篇幅讲这些符号的区别但实际工作中真正高频使用的只有三四种。我先把六种关系过一遍然后告诉你哪些值得花时间搞清楚。泛化就是继承画成一条实线加空心三角箭头箭头指向父类。这个最直观没什么歧义。实现是类实现接口画成虚线加空心三角箭头箭头指向接口。这两个在Java、C#这类语言里天天用画起来也简单。依赖画成虚线加普通箭头表示一个类“临时使用”另一个类。比如订单服务在处理支付的时候临时需要一个支付网关对象来发请求但订单服务本身不持有支付网关的引用。依赖关系的特点是短暂、偶然通常体现在方法参数或者局部变量里。关联画成实线加普通箭头表示一个类“长期持有”另一个类的引用。比如订单类里有一个客户对象的成员变量这就是关联。关联和依赖的区别在于生命周期关联是长期的、结构性的依赖是临时的、行为性的。聚合和组合是关联的两种特殊形式都表示“整体-部分”关系。聚合画成实线加空心菱形菱形在整体那一端组合画成实线加实心菱形菱形也在整体那一端。区别在于部分能否独立于整体存在。聚合的例子一个团队有多个成员团队解散了成员还在这就是聚合。组合的例子一个订单有多个订单项订单删除了订单项也没有意义了这就是组合。组合的耦合度比聚合高整体负责管理部分的创建和销毁。实际工作中我的建议是泛化、实现、关联、依赖这四个必须搞清楚聚合和组合知道概念即可画图时不必过分纠结。为什么因为聚合和组合的区分在代码层面往往体现为“部分对象是不是在整体对象内部new出来的”这个细节在概念模型阶段并不重要。很多团队画图时干脆把聚合和组合都画成普通关联然后在旁边加文字注释说明生命周期关系这样反而更清晰。我见过有人为了区分聚合和组合争论半小时最后代码写出来发现两种方式都行得通那争论的意义就不大。关系类型线条样式语义代码体现使用频率泛化实线空心三角继承extends高实现虚线空心三角实现接口implements高关联实线普通箭头长期持有引用成员变量高依赖虚线普通箭头临时使用方法参数/局部变量高聚合实线空心菱形整体-部分可独立成员变量外部传入中组合实线实心菱形整体-部分不可独立成员变量内部创建中2.3 多重性标注别小看那个数字关系线两端的数字标注学名叫多重性。常见的有1、0..1、、1..、0..。这个标注看起来不起眼但它传递的信息量非常大。比如订单和订单项之间标了1对1..意思是“一个订单至少有一个订单项”这个“至少一个”就是业务规则。如果开发人员没注意到这个约束写代码的时候就可能允许创建一个空订单这就是bug的源头。多重性标注的常见错误是只标一边。比如画了订单到客户的关联只在订单那边标了“*”客户那边什么都没标。这就有歧义了一个客户可以有多少个订单是0个、1个还是多个读图的人只能猜。正确的做法是两端都标清楚。还有一个错误是标注跟业务规则不一致。比如业务上规定一个客户可以有多个订单但画图的时候随手标了个1后面开发就按1对1来设计等到需求变更的时候才发现要改表结构。这种坑我踩过不止一次后来养成了习惯每画一条关系线先问自己两端的多重性分别是什么写下来再画。提示多重性标注是类图里性价比最高的信息。一个数字就能表达一条业务约束比写一段文字说明直观得多。画图时宁可多花十秒钟确认多重性也不要留空。3. 从零画一张能用的类图3.1 先定边界再找实体画类图最怕上来就画。打开工具就开始拖方框画到一半发现漏了核心概念或者画了一堆不需要的类返工成本很高。我的做法是分三步走定边界、找名词、筛实体。定边界的意思是先明确这张类图描述的是哪个范围。是整个系统还是某个子系统还是某个业务模块范围不同类图的颗粒度完全不同。如果画整个电商系统那类图里可能有几十个类根本看不清如果只画订单模块那类图里可能就七八个类清晰明了。我的经验是一张类图控制在5到15个类之间超过15个就拆成多张用包图或者分组框来组织。这个数量不是拍脑袋定的而是基于人的认知负荷一张图里超过15个元素读图的人就很难在脑子里建立完整的结构关系。找名词的方法很土但很有效把需求文档或者用户故事里所有的名词圈出来。比如“用户下单后系统生成订单订单包含多个商品每个商品有价格和数量订单关联收货地址和支付方式”。这段话里的名词有用户、订单、商品、价格、数量、收货地址、支付方式。这些名词就是候选实体。注意“价格”和“数量”在这里是商品的属性还是独立实体如果价格会随时间变化、需要记录历史价格那它可能是一个独立的“价格记录”实体如果只是下单那一刻的快照那它就是订单项的一个属性。这个判断需要结合业务需求来做。筛实体的标准有三个有身份标识、有生命周期、有业务行为。有身份标识的意思是它能被唯一区分比如订单有订单号商品有商品编码。有生命周期的意思是它从创建到销毁有一个过程比如订单从创建到完成或取消。有业务行为的意思是它不只是数据的容器还有自己的逻辑比如订单能计算总价、能取消、能退款。三个条件满足两个以上就值得作为独立类画出来。只满足一个的大概率是另一个类的属性。3.2 关系梳理的实操顺序实体找出来之后下一步是梳理关系。我的习惯顺序是先泛化再组合后关联最后依赖。为什么是这个顺序因为泛化关系决定了类的层次结构它是最稳定的先定下来后面不容易变。组合关系决定了哪些类必须一起存在它影响模块划分。关联关系是类之间的引用相对灵活。依赖关系最临时放在最后画而且很多依赖关系在概念模型阶段可以省略。具体操作时拿一张纸或者打开工具把筛选出来的类先摆开然后逐个问三个问题这个类跟哪个类有“是一种”的关系这个类跟哪个类有“整体-部分”的关系这个类需要知道哪个类的信息才能完成自己的职责第一个问题找出泛化第二个问题找出组合或聚合第三个问题找出关联。依赖关系不用刻意找画完关联之后那些没有关联但有交互的类之间自然就是依赖。这里有一个容易忽略的点关系的方向。关联关系是有方向的箭头从“知道对方”的类指向“被知道”的类。比如订单知道客户是谁但客户不需要知道订单从客户这个类的职责来看它不负责管理订单那箭头就从订单指向客户。方向搞反了读图的人会误解类的职责划分。我见过一张图客户和订单之间画了双向箭头问画图的人为什么双向他说“客户能查自己的订单啊”。这就是把“查询操作”和“结构关系”混为一谈了。客户能查订单是通过订单服务或者订单仓库来查的不代表客户类里要持有一个订单列表的引用。结构关系要看类的成员变量不是看业务操作。3.3 属性与方法的填充策略关系和结构定下来之后再往类框里填属性和方法。这个顺序很重要先定关系后填细节。因为关系决定了类的职责边界职责边界清楚了属性和方法自然就知道该放哪。如果先填属性和方法很容易出现“这个属性到底该放A类还是B类”的纠结因为职责边界还没定。填属性的时候我遵循一个原则只写业务属性不写技术属性。业务属性是业务人员能看懂的比如订单金额、商品名称、收货地址。技术属性是开发人员关心的比如主键ID、创建时间、版本号、删除标记。技术属性在类图里写不写我的做法是不写或者最多写一个“id”作为身份标识。原因很简单类图是给团队看的包括产品经理和测试人员技术属性对他们来说是噪音。而且技术属性往往跟具体的持久化方案绑定概念模型阶段还没定用MySQL还是MongoDB写这些属性没有意义。填方法的时候只写public的业务方法。私有方法除非特别重要比如某个核心算法否则不写。构造方法不写。getter/setter不写。方法的命名用动词名词的形式比如“计算总价”“提交订单”“取消订单”。参数和返回值在概念模型阶段可以省略或者只写类型不写参数名。如果某个方法特别关键可以在方法名后面加一个简短的注释说明它的业务规则比如“计算总价含运费和折扣”。这个注释比画一堆细节更有用。注意类图里的方法不是越多越好。一个类如果列了十几个方法读图的人根本记不住。我的经验是每个类的方法控制在5个以内只保留最核心的业务行为。那些辅助性的、工具性的方法在类图里省略不影响理解。4. 类图落地时的常见坑与排查4.1 画完没人看问题出在哪类图画完没人看这是最常见也最致命的问题。我分析过原因大概有三种。第一种是画得太细把类图当成了代码的图形化版本每个字段每个方法都列上去读图的人一看就头大直接跳过。第二种是画得太抽象只有类名和几条线没有任何属性和方法读图的人不知道这些类到底干什么用看了等于没看。第三种是画完就锁进文档库后续代码改了类图不改类图和代码脱节慢慢就没人信了。针对第一种解决办法是分层画图。概念层只画类名和关系不画属性和方法用于跟产品经理对齐业务概念设计层画核心属性和关键方法用于指导开发实现层才画完整的属性和方法用于生成代码或者写详细设计文档。大部分场景下设计层就够了。针对第二种解决办法是给每个类写一句话职责说明放在类名下方或者用注释框标注。这句话不用长十个字以内比如“订单管理订单生命周期和金额计算”。这一句话就能让读图的人快速理解类的定位。针对第三种解决办法是把类图纳入代码评审流程每次有结构性变更的时候先改类图再改代码让类图成为设计讨论的起点而不是事后补的作业。还有一个容易被忽略的点类图的可读性。同样一张图布局好坏对理解成本影响巨大。我的布局原则是继承关系从上到下关联关系从左到右核心类放中间辅助类放边缘。线条尽量不要交叉如果交叉不可避免用跳线或者调整布局来减少视觉干扰。颜色不要用太多两三种就够了比如核心领域类用一种颜色辅助类用另一种颜色。这些细节看起来是小事但实际用起来差别很大。4.2 类图与代码不一致怎么破类图和代码不一致几乎是所有团队的通病。原因很简单代码是活的类图是死的。代码天天改类图改一次管半年。要解决这个问题靠“提高意识”没用得靠机制。我试过几种做法说下效果。第一种是代码生成类图。很多IDE和建模工具支持从代码反向生成类图比如IntelliJ IDEA的Diagrams功能、PlantUML的代码扫描插件。这个做法的好处是类图永远跟代码一致坏处是生成的图往往太细包含大量技术细节可读性差。我的用法是用反向生成做差异检查定期跑一次看看代码里多了哪些类、少了哪些关系然后手动更新设计层的类图。这样既保证了准确性又保持了可读性。第二种是类图即代码。用PlantUML或者Mermaid这样的文本化建模工具把类图写成代码跟项目代码一起提交到版本库。这样类图的变更历史可追溯而且修改成本低。PlantUML的语法很简单画一个类就几行代码改起来比拖拽工具快得多。我现在的习惯是设计讨论的时候直接在文档里写PlantUML代码讨论完了代码也写完了直接提交。这个做法特别适合敏捷团队因为类图可以跟着迭代快速更新。第三种是只画核心结构。不是所有类都值得画进类图。我的做法是只画领域模型也就是业务核心概念之间的关系那些技术性的类工具类、配置类、框架适配类不画。领域模型相对稳定变更频率低维护成本也就低。至于技术类的结构用包图或者模块图来表达就够了不需要精确到类级别。问题现象根因解决思路实操建议类图太细没人看把实现细节画进去了分层画图概念层/设计层/实现层分开设计层只画核心属性和关键方法类图太抽象看不懂缺少职责说明每个类加一句话职责注释注释控制在10字以内类图与代码脱节缺少更新机制文本化建模版本库管理用PlantUML写类图跟代码一起提交关系方向画反混淆结构关系和操作关系看成员变量定方向不看业务操作问自己“这个类里有没有对方的引用”多重性标注缺失画图时没想清楚业务规则每条关系线两端都标多重性标注前先跟业务方确认约束4.3 团队协作中的类图规范团队一起画类图最怕风格不统一。A画的类图用圆角矩形B画的用直角矩形A把属性写在方法上面B反过来A用中文命名B用英文命名。这些不一致看起来是小事但放在一起就是灾难。我的建议是团队在开始画类图之前先花半小时定一个最小规范不用太复杂覆盖以下几点就够了。命名规范类名用单数名词首字母大写不用下划线属性名用小驼峰方法名用动词开头的小驼峰。语言上统一用英文还是中文团队自己定但必须统一。我倾向于用英文因为跟代码一致减少翻译成本。但如果团队的产品经理需要直接读图用中文也完全可以关键是统一。颗粒度规范明确哪些类必须画哪些可以不画。比如领域实体必须画工具类不画接口画不画看情况。属性和方法写到什么程度也定一个标准比如“只写业务属性和public业务方法”。这个标准写在一页纸的文档里新成员进来先看这个文档。工具规范统一用同一个工具。PlantUML、draw.io、StarUML、Visual Paradigm选一个团队用得顺手的不要混用。混用会导致格式不兼容合并的时候很麻烦。如果团队用Git管理文档强烈建议用PlantUML这种文本化工具diff和merge都方便。提示规范不用追求完美先定一个能用的版本跑一两个迭代再调整。最怕的是花两周时间讨论规范结果一张图都没画。5. 类图在不同场景下的变通用法5.1 快速沟通场景白板类图不是所有类图都需要用工具画。很多时候最快的沟通方式是在白板上画草图。白板类图的特点是快、糙、够用。不用纠结线条样式不用管多重性标注甚至不用写全类名写个缩写就行。关键是快速把结构关系表达出来让讨论有焦点。我常用的白板类图画法是方框代表类里面只写类名关系用箭头表示箭头旁边写个数字表示多重性如果某个类特别重要在方框下面写一行职责说明。就这些。五分钟能画完一个模块的结构然后大家对着图讨论哪里有问题。讨论完了拍张照片会后用工具整理成正式版本。这个流程比直接上工具画效率高得多因为白板允许犯错允许涂改思维不会被工具束缚。白板类图还有一个好处它天然是协作的。工具画图往往是一个人画、其他人看白板画图是大家一起画、一起改。我见过很多设计决策是在白板前争论出来的而不是在文档里写出来的。所以如果你的团队还在用“一个人画完发群里”的方式做设计可以试试改成“白板前一起画”效果会好很多。5.2 文档沉淀场景PlantUML文本化类图需要把类图沉淀到文档里的时候我首选PlantUML。原因很简单文本格式版本可控修改成本低。一段PlantUML代码几十行放在Markdown文档里跟文字混排阅读体验很好。而且PlantUML的语法很直观没学过的人也能看懂个大概。画一个订单模块的类图PlantUML代码大概长这样startuml class Order { - orderId: String - status: OrderStatus - totalAmount: BigDecimal calculateTotal(): BigDecimal submit(): void cancel(): void } class OrderItem { - quantity: int - unitPrice: BigDecimal subtotal(): BigDecimal } class Customer { - customerId: String - name: String } class Address { - province: String - city: String - detail: String } Order 1 *-- 1..* OrderItem Order 0..* -- 1 Customer Order 1 -- 1 Address enduml这段代码渲染出来的图结构清晰关系明确。关键是它可以跟代码一起放在版本库里每次修改都有记录。如果团队用Confluence或者语雀写文档PlantUML插件可以直接渲染不需要额外装工具。如果团队用GitHub或者GitLabMarkdown里的PlantUML代码块也能通过插件渲染。这个方案的迁移成本很低值得推广。5.3 代码审查场景用类图做设计评审类图还有一个被低估的用法做代码审查的辅助工具。代码审查的时候如果只看diff很难判断一个改动对整体结构的影响。但如果有一张类图审查者可以快速判断新增的这个类放在哪个位置合适它跟现有类的关系是否合理有没有引入不必要的耦合我的做法是在提交涉及结构性变更的代码时附带一张更新后的类图。不需要很详细标出新增的类、修改的关系就行。审查者对着类图看代码比只看代码效率高得多。这个做法还有一个副作用它倒逼开发者在写代码之前先想清楚结构因为如果结构不合理类图上一眼就能看出来。我试过一段时间之后团队里“先写代码再补设计”的情况明显减少了。6. 我踩过的坑和总结出的几条经验说几个我实际踩过的坑都是教科书上不会写的。第一个坑过度设计。刚开始画类图的时候总想把所有可能性都考虑到画了一堆抽象类和接口结果代码写出来发现根本用不上。后来我学乖了类图只画当前迭代需要的东西未来的扩展点用注释标一下就行不用真的画出来。YAGNI原则在类图设计上同样适用。第二个坑关系画得太满。每个类之间都画关系图看起来密密麻麻实际上很多关系是间接的、可以推导出来的。比如A关联BB关联C那A和C之间就不需要再画一条线。类图应该表达直接关系间接关系让读图的人自己推导这样图才清爽。第三个坑忽略非功能需求。类图只表达了结构但性能、并发、事务这些非功能需求在类图上是看不出来的。比如订单和库存之间类图上画一条关联就完了但实际代码里要考虑并发扣减、分布式事务。这些信息如果不在类图旁边用注释说明开发人员可能会忽略。我的做法是在关键类或者关键关系旁边加一个注释框写清楚非功能约束比如“扣减库存需要加锁”。第四个坑把类图当文档交付物。有一段时间项目要求每个模块都必须提交类图作为交付物结果大家为了交差而画图画完就扔没有任何实际价值。后来我们改了做法类图只在设计讨论和代码评审两个场景下使用不强制交付。反而大家画得更认真了因为画图是为了解决问题不是为了交作业。最后分享一个我觉得最实用的经验类图的价值在于画的过程不在于画的结果。你花两个小时画一张类图最大的收获不是那张图本身而是画图过程中你对系统结构的思考。哪些类该合并、哪些关系该拆开、哪些职责放错了位置这些问题在画图的时候会自然浮现出来。所以我的建议是不管最终画得好不好看先画起来。画完再改改完再画迭代两三轮之后你对系统的理解会完全不一样。至于那张图最后是贴在墙上还是锁进文档库反而不重要了。