企业官网建设流程全解析

写类图这么多年，我发现一个很有意思的现象：UML类图本身不难，难的是让大家在同一张图上讲同一件事。前面几个人在评审会上各说各的，无非就是因为依赖、关联、聚合、组合这几根线画得含糊。六大关系——依赖、关联、聚合、组合、泛化、实现——说到底是面向对象设计语言里最基础的语法，但如果你把它当成“背符号”来学，那画出来的图基本没法用于后续设计决策。这篇我就从实际建模和代码反推的角度，把这六大关系彻底捋清楚，也聊聊那些踩过的坑。

1. 类图关系为什么容易画错：语义与符号之间的三道坎

先说个我的判断：类图画不好，绝大多数不是因为记不住符号，而是因为没想明白“这条线到底在表达什么”。UML类图里的关系是从代码语义推导出来的转译结果，不是美术题，也不是纯粹的记忆题。你只要把这层逻辑理顺，箭头就是水到渠成的事。

1.1 第一道坎：箭头符号本身的记忆负担

我对新人培训的时候，发现挂在墙上的那张符号表几乎人人都能背下来，但一动手就乱画。原因是符号太多了，还分实线、虚线、空心三角、实心三角、空心菱形、实心菱形。先把这个基础矩阵夯实，后面才好讲判断逻辑。

这里最容易记混的是两个三角形和两个菱形。泛化（继承）是“实线三角”，实现是“虚线三角”；聚合是“实心线配空心菱形”，组合是“实心线配实心菱形”。如果再往上走一层，你会发现规律：虚线表达“弱”，三角表达“类型”，菱形表达“整体部分”。弱关系用虚线（依赖、实现），强关系用实线（关联、聚合、组合、泛化），凡是牵扯到分类归属的用三角（泛化、实现），凡是牵扯到整体部分的用菱形（聚合、组合）。这个规律比死记符号管用得多。

1.2 第二道坎：关系强度与代码落点的对应

大多数人的问题不是不知道泛化怎么画，而是面对一段真实代码时不知道选哪条线。这条线必须能在代码里找到证据。方法参数里出现某个类，这就是依赖；类里有一个字段是这个类型，这是关联；如果是整体内部创建并负责销毁的对象，这是组合；对象从外部传入，整体只持引用但不负责其生死，这是聚合。

我见过太多人画图时“凭感觉”，结果图里一组类之间的箭头方向和代码里的实际依赖方向完全相反。代码里明明是EmailService依赖TemplateEngine，图上却画成TemplateEngine指向EmailService。说白了，类图不是“谁认识谁”的关系图，它更像一张依赖地图，每一条线都要能对应到一行具体代码上。

1.3 第三道坎：一致性——图和代码必须讲同一个故事

还有一个隐蔽的坎：设计阶段画的类和后续代码实现对不上。设计时为了表现“松耦合”，把所有关系都画成依赖，结果代码里字段满天飞；反过来，为了让图显得“够完整”，又把所有临时使用都画成关联，导致类图上到处是实线，看久了根本分不清哪些是核心领域关系，哪些只是偶发调用。

我的建议是：画图之前先明确视图的用途。如果是给系统架构评审看的，重点画稳定的依赖边界和生命周期关系；如果是给模块开发人员看的，再补充详细的多重性和实现细节。不要指望一张图把所有信息都塞进去，这是类图被画乱的根源之一。

2. 六大关系逐个拆解：从符号、语义到代码信号

这一部分我把六大关系逐一拆开讲。每个关系都从定义、代码形式、UML画法、典型场景、易错点这五个角度去分析，尽量把“抽象定义”翻译成“代码长什么样”。

2.1 依赖（Dependency）：最弱的关系，临时用一下

依赖在六大关系里是最弱的一种，表示类A在某个操作中“用到”了类B，但不会把B作为自己的状态保存下来。代码里的常见信号是：

• 方法参数类型 类A的方法接收了一个B类型的参数
• 方法内部局部变量B b = new B();或者工厂方法返回B
• 方法的返回类型 A的方法返回B，临时构造或由别处获取
• 静态方法调用B.someStaticMethod()也被认为是依赖，但通常建模时不会画这种依赖，粒度太细

一段示例代码：

public class ReportGenerator { public Report generate(ReportData data, ReportFormatter formatter) { String body = formatter.format(data); // 用到了 formatter return new Report(body); // 用到了 Report } }

这里ReportGenerator在generate方法里使用了ReportFormatter和Report，但它没有把它们存成字段。UML画法就是一条虚线箭头，从ReportGenerator指向ReportFormatter，再指向Report。

依赖关系最常见的误用是把它和关联混在一起。区分方法很简单：关联往往是“字段级持有”，依赖往往是“动作级使用”。如果类里声明了private ReportFormatter formatter;，那就不是依赖，而是关联了。反过来，如果只是调用链里“路过”的类型，画成依赖已经足够，画成关联反而会让图失真。

依赖还有一个特点：它是单向的。A依赖B，不代表B依赖A。不要在一条依赖线上加双向箭头，这会模糊调用方向，评审时也容易引发争议。曾经我见过有人把依赖画成无箭头实线，说“反正有关系”，之后这张图没人能看懂到底谁调用谁。

2.2 关联（Association）：长期持有一份引用

关联表示一个类“长期知道”另一个类，并通过字段或其他形式的持久引用来建立连接。这是业务对象之间最常见的稳定关系。

代码信号非常明显：

public class Order { private Customer customer; public Order(Customer customer) { this.customer = customer; } }

Order保存了Customer的引用，那么这个订单和客户之间就是关联关系。UML画法是一根实线箭头，从Order指向Customer，表示导航方向。如果这段关联是双向的，也就是说客户也能拿到订单列表：

public class Customer { private List<Order> orders; }

那么在类图上应该用一根实线连接，两端都画箭头，或者线上标注双向导航。很多工具允许你给关联线标注多重性（multiplicity），比如Customer 1 —— * Order，含义是一个客户可以关联多个订单。

关联的强度介于依赖和聚合之间，但它本身不负责生命周期。关联只回答“谁持有谁”，不回答“谁销毁谁”。你在评审时经常被问“这个关联是单向还是双向”，这就是在考察你是否清楚导航方向。

这里还有一个实用技巧：双向关联在编码上往往意味着相互引用，序列化、并发、缓存都要额外处理循环引用问题。如果领域模型并不需要这种双向导航，尽量保持单向关联。类图里少一条反向箭头，代码里就少一堆麻烦。

2.3 聚合（Aggregation）：整体和部分，但各自独立存活

聚合描述的是“整体拥有部分”，但部分可以脱离整体独立存在。整体端用空心菱形表示，菱形画在整体那一侧。典型例子是公司和员工：公司倒闭了，员工这个对象在系统里不一定消亡，可能只是解除关系；班级和学生、车和轮子也是常见的类比。

代码层面怎么判断聚合？看对象是怎么进来的，以及整体是否负责销毁它：

public class Team { private List<Developer> members; // Developer 从外部传入，Team 不负责创建和销毁 public Team(List<Developer> developers) { this.members = developers; } public void addDeveloper(Developer d) { this.members.add(d); } public void removeDeveloper(Developer d) { this.members.remove(d); } }

Team聚合Developer，但Developer对象自己活着，离开Team以后还可以去别的团队。UML画法是：实线连接Team和Developer，在Team那一端加上空心菱形，同时可以在箭头端标注0..*等多重性。

最容易踩的坑是只看创建位置。构造器注入、setter注入这些方式，对象虽然是从外部传进来的，看起来“整体拿到了部分”，但如果不负责销毁/释放，这就是聚合而不是组合。在Java这类没有显式析构的语言里，销毁责任要靠业务规则来判断，比如“Team被删除时，是否同时把Developer从系统中移除？”如果不会，就是聚合。

2.4 组合（Composition）：生是我的人，死是我的死人

组合是“整体和部分”里最强的关系，表示部分不能脱离整体而独立存在，整体的生命周期直接决定了部分的生命周期。整体端用实心菱形表示。

代码里的信号很直白：

public class Order { private List<OrderLine> lines = new ArrayList<>(); public void addLine(Product product, int quantity) { this.lines.add(new OrderLine(product, quantity)); } // Order 被删除时，OrderLine 没有独立存在的意义 }

OrderLine是由Order自己创建、自己管理的，订单没了，订单行自然也没了。UML画法是实线连接，Order那一端画实心菱形。

组合关系在实际系统里最常见的证据是级联操作：删除订单时，ORM 会级联删除order_line表；关闭外层文件流时，内层流也会被关闭；Spring 事务里对象被移除时，关联的子实体一并失效。

组合和聚合的边界问题，我会在下一章专门展开。这里先记住一个核心判断：组合关系中，部分不能同时被两个整体共享；聚合关系中，部分可以被多个整体共享。一个订单行不可能同时属于两个订单，这是组合；一个员工可以被多个项目组引用，这是聚合。

2.5 泛化（Generalization）：类与类之间的继承

泛化就是继承关系，子类继承父类的属性和方法，表达的是“is-a”语义。UML画法是实线加空心三角，三角指向父类。

public class Cat extends Animal { @Override public void speak() { System.out.println("Meow"); } }

UML图上，Cat连向Animal，Cat那一端是普通实线，Animal那一端是空心三角。很多人把箭头画反，这是大忌。记住方向：子类指向父类。

泛化里还有一个容易混淆点：抽象类和接口。继承抽象类使用的是泛化（实线三角），实现接口使用的是实现关系（虚线三角）。抽象类本质上是“类”，它有状态、构造器、具体的实现方法；接口本质上是“契约”，它约束能力，不管理状态。如果一个类继承了一个抽象基类，那就该画实线三角，不要因为“这玩意儿不能直接new”就画成虚线三角。

2.6 实现（Realization）：类和接口之间的契约

实现关系表示一个类实现了某个接口，表达的是“满足能力约定”的语义。UML画法是虚线加空心三角，三角指向接口。

public class EmailNotifier implements Notifier { @Override public void send(String message) { // ... } }

UML图上，EmailNotifier连向Notifier，Notifier那一端是虚线空心三角。

在依赖倒置原则下，实现关系通常出现在“领域接口”和“外部适配器”之间。比如你定义了一个PaymentGateway接口，然后有AlipayAdapter、WechatPayAdapter来实现它。类图上如果适配器很多，不需要把所有实现关系都画出来，挑核心接口和几个典型实现画即可，其余可以注一句“其余实现类同理”，避免图面污染。

另外Go语言和Java不太一样，Go没有显式的implements关键字，只要结构体方法集合满足接口即可，但建模时仍然可以用实现关系来表达两者的绑定，只是代码层面并没有显式声明。这并不影响你画图。

3. 聚合与组合的边界：生命周期、所有权与异常场景

聚合和组合是六大关系里被讨论最多的两个，几乎所有考试和评审都绕不开它们。两者的符号差异只是一个实心、一个空心，但真正的难点在语义判定，下面从生命周期、所有权和异常场景三个维度把它说透。

3.1 判定问题清单：比“创建位置”可靠的三连问

很多文章告诉你，“对象是在整体内部new出来的就是组合，从外部传进来的就是聚合”。这个说法在大多数简单场景下成立，但到了真实业务里经常翻车。比如一个Team有一种管理模式，队员完全由Team招聘、培养、开除，代码里也是Team负责创建Member，但如果Member对象同时被HR系统引用，那它显然还能独立存在。这时如果你只看“内部new”，就会误判成组合。

我实际画图时用的是一组更可靠的判断问题：

• 同一个部分能被多个整体同时拥有吗？如果能，聚合；如果不能，组合。
• 整体销毁后，部分是否还需要继续存在或被其他对象继续使用？如果是，聚合；如果不是，组合。
• 部分对象的关键业务操作是否必须依赖整体提供的上下文？比如订单行需要订单的税率和客户信息才能计算金额，这是组合倾向。
• 删除整体时，你期望系统级联删除部分吗？如果答案是“会”，组合；答案是“不会”，聚合。

这组问题背后其实是一个核心概念：所有权（ownership）。组合的本质是“整体拥有部分的生命周期”，聚合的本质是“整体只在某段时间内管理部分的归属，但不掌握生死”。

3.2 语言差异带来的建模陷阱

同一个关系在不同语言里，代码表现很不一样。

C++中，如果你把部分直接作为成员变量，比如class Car { private Engine engine; };，那么Car的析构函数会连带析构Engine，这是标准组合。如果成员是裸指针或智能指针，那就要看析构时是否delete或是否随容器释放。裸指针且由外部传入，通常就是聚合。C++的RAII思想让“所有权”变得很明确，这也正是C++开发者看Java代码时常觉得“生命周期模糊”的原因。

Java没有析构函数，对象由GC统一回收，所以你不能只看语法来判断组合还是聚合。你需要靠业务规则来理解：一个对象是否只属于一个整体；整体删除时是否要主动解除引用、关闭资源、从集合中移除等。如果整体里只是持有一个List<Sub>并且从不负责删除，那这个引用其实只是关联，甚至连聚合都算不上——不过从领域建模角度，整体-部分语义明确时，画成聚合是合理的，因为UML表达的是设计意图，不只是代码事实。

Go语言里组合的概念更容易被混淆，因为Go的struct嵌入常被叫做“组合”。但那是代码复用上的“组合”，和UML的组合关系不是一回事。建模时建议比照Java的判定思路，看对象生命周期和领域归属，不要被语言特性带偏。

3.3 现实业务中的模糊地带：自关联、共享对象和跨聚合引用

在真实的项目里经常出现自关联：一个组织下面有子组织，子组织下面还有子组织，比如部门树。这种关系是聚合还是组合？我的判断标准是：子部门离开父部门是否还能存在？在很多企业组织架构里，子部门必须归属一个父部门（至少逻辑上如此），根部门除外，这种约束更像组合。但如果你的系统允许“待分配部门”存在，那更像聚合。

另一种常见情况叫跨聚合引用：订单行引用了商品Product，但Product是商品目录聚合的根。这时不能因为OrderLine持有Product引用，就画成组合或聚合，它应该只是关联，因为商品的生命周期完全不由订单行掌控。用“引用关系 + 归属关系”分开建模，能避免把一张类图画成一张巨型蜘蛛网。

还有一个建议：拿不准的时候，选更弱的关系。因为类图是一种设计承诺，画成组合意味着你承诺“整体销毁时部分必须销毁”，这个约束很强，如果实现做漏了，后续重构代价会很大。在跨模块边界上尤其要谨慎。但在高内聚模块内部，组合往往可以帮助你明确边界：哪些对象是模块私有的，哪些对象只是外部世界的入口。聚合则适合一些“上下文相关”的场景，比如某种临时装配关系。

4. 从代码反推关系：五步判定法，不再纠结箭头

回归到最接地气的问题：拿到一段代码，到底怎么画线？我给团队内部总结过一套五步判定法，按顺序查一遍，基本不会错。如果你要准备系统架构师考试或者做项目设计文档，这套方法可以直接套用。

4.1 五步判定流程

判定顺序非常关键，不要上来就想“这是依赖还是关联”，要先从语法上最显式的关系开始查：

注意步骤3和4之间还有一个“关联”的兜底位置。如果生命周期语义不明确，不存在“整体-部分”的领域语义，那就退到关联，不要硬套聚合和组合。很多画错的图就是因为在步骤3、4里纠结太久，最后画了一个错误的组合。

4.2 实例：一个小订单系统的关系推导

我拿一个精简的订单系统来说明五步判定法怎么用。

public class Customer { private List<Order> orders; } public class Order { private Customer customer; private List<OrderLine> lines = new ArrayList<>(); public void addLine(Product product, int quantity) { this.lines.add(new OrderLine(product, quantity)); } public BigDecimal pay(PaymentService service) { return service.charge(this); } } public class OrderLine { private Product product; private int quantity; } public class Product { private String name; } public class PaymentService { public BigDecimal charge(Order order) { // 处理支付 return BigDecimal.ZERO; } }

逐条判定：

• Customer有List<Order>字段，导航方向从Customer到Order，这是关联，多重性一对多。
• Order有Customer字段，这是关联，单向导航或多重性标注0..1。
• Order自己创建OrderLine，而且订单行离开订单没有业务意义，删除订单应该级联删除这些行，因此Order到OrderLine是组合，菱形画在Order端。
• OrderLine持有Product字段，但商品的生命周期由商品目录管理，订单行只是引用它，因此是关联，不是聚合也不是组合。
• Order只在pay方法参数中用到PaymentService，字段里没有持久引用，因此Order到PaymentService是依赖。
• PaymentService的charge方法接收Order参数，同样只是临时使用，所以从PaymentService到Order也是依赖，除非它有List<Order>字段用来记录所有需要重试的订单，那才升级为关联。

这样一个图画下来，每根线都有代码出处。评审时有人质疑，你直接指着一行代码说“这就是为什么画成组合”，争论立刻消失。

4.3 工具生成的类图只能算初稿

IDEA、StarUML这类工具自动生成的类图很方便，但它们对聚合和组合的区分基本是零——工具不知道你是否负责销毁对象，也不能理解业务上“离开整体就没意义”的语义。IDEA能识别继承、实现和字段引用，但依赖关系往往需要你手动补。

我的建议是：把工具生成图当作“代码地图的第一版”，基于它做增删改查，再人工用五步判定法过一遍。这一步千万别省，否则等于帮你画了一张充满歧义的图，反而比不画更危险。

5. 常见错误：从评审现场见过的五个典型画法

这些错误不是书上编出来的，都是我在代码评审和设计评审现场真实见过的。把它们单列出来，就是希望大家画完图后能对着自查一遍。

5.1 双向关联画成两根单向箭头

场景：Order需要知道Customer，Customer也需要List<Order>，于是有人画两根实线箭头，一根指向Customer，一根指向Order。

UML里这是错误或至少是不标准的做法。双向关联应该用一根实线、两端带箭头来表达。两根单向箭头容易让人误以为这是两条独立关系，实际上表达的是同一个关联的两个导航方向。当然，有些工具渲染出来的可能默认就是一根线两端带箭头，但很多人手动画图时会犯这个错。

评审时的正确问法是：这个关联是单向还是双向导航？如果代码里只有Order持有Customer，那就要画成单向，不要为了对称画成双向。双向关联意味着双方都要维护引用的一致性，复杂度会明显上升。

5.2 菱形画在部分那一端

聚合和组合的菱形必须画在“整体”那一侧。比如Team聚合Developer，空心菱形要贴在Team旁边，不是贴在Developer旁边。我见过不止一个团队把菱形画反，导致整张图语义全部颠倒。

这个坑在考试里也经常被用作细节点。很多工具可以自动把菱形放在线的起始端，所以画图时注意线的拖拽方向：从整体拖向部分，菱形就会在整体端。如果发现方向不对，用右键的“Reverse”调整，不要硬画。

5.3 把方法参数里的类型都画成关联

依赖和关联的边界是新人最容易模糊的地方。我见过有人把pay(PaymentService service)这样的参数画成关联，理由是“方法里确实用了它”。但从代码持久性来看，Order并没有保留PaymentService的任何状态，下次调用还是要重新传入。这种关系应该画成虚线箭头（依赖）。

反方向也常见：字段里明明持有Config对象，按字段声明应该画关联，却因为“只是配置不是业务”就画成依赖。这也不对，只要长期持有引用，至少是关联。你可以用一个简单的类比：关联是“家里长期雇的阿姨”，依赖是“今天临时叫的维修师傅”。是不是长期留住，决定了你该画哪条线。

5.4 接口实现画成泛化

接口实现是虚线空心三角，类继承是实线空心三角。有人画图时为了省事，把所有实现关系的线都画成实线，乍一看还以为是继承。这在图面上会造成致命误解：看图的人会以为EmailNotifier从Notifier继承了具体实现，而实际上只是实现了契约。

还有一种高级误用：一个类继承了一个抽象类，而这个抽象类实现了某个接口，于是画图的人把“实现类到接口”的关系也画成泛化。正确做法是分两层：具体类到抽象类是泛化，抽象类到接口是实现。

5.5 全图皆线，关系爆炸

我见过一张20个类的图，上面画了40多条关系线，几乎所有依赖都被画出来了。结果评审现场没一个人能说清模块边界。原因是画图的人把“严谨”理解成了“穷举”：方法参数里出现的类型全画依赖，局部变量里new出来的类也画依赖，结果核心业务关系被淹没在一堆临时访问关系里。

类图的目的是表达设计意图，不是统计代码里所有的类型接触点。我给自己定的标准是：只画跨稳定边界、有维护语义的长期关系；临时使用的关系靠注释或者在代码里体现。如果一个依赖关系只是调用链中一个特别具体的实现细节，它不值得占一根线。

6. 工具实操：StarUML与IntelliJ IDEA生成类图的正确姿势

最后说点工具层面的实操经验。毕竟很多同学是从StarUML或者IDEA才开始真正接触类图的，工具用对了，能省不少心。

6.1 StarUML画类图关系时容易被忽略的操作

StarUML里创建类图，可以在主界面选择“Class Diagram”，然后从左侧的工具栏拖出Class节点。画关系时，注意工具栏上不同图标的区分：

• Dependency：用于画依赖和实现关系（虚线系列）
• Association：用于画普通关联（实线无菱形）
• Aggregation：画聚合，起点端自动生成空心菱形
• Composition：画组合，起点端自动生成实心菱形
• Generalization：画泛化（继承），终点端生成空心三角
• Realization：画实现，终点端生成虚线空心三角

画聚合和组合时有一个关键动作：线要从“整体”往“部分”拖，这样才能保证菱形出现在整体那一端。如果你拖反了，选中关系线条，右键菜单里通常有“Reverse Direction”之类操作，不要删了重画。在关联线上双击可以设置多重性、角色名等信息。保存成图片时建议使用导出PNG/SVG，分辨率更高。

很多人在StarUML里画的图很有“工具感”：节点不对称、线歪歪扭扭。提示一个小技巧：画完关系后，选中多个节点，使用布局（Arrange）功能自动对齐一下，观感会专业很多。

6.2 IntelliJ IDEA自动生成类图的用法

如果你用的是Java，IDEA自带的Diagram功能非常好用。选中一个类，右键选择Diagrams -> Show Diagram Popup（快捷键Ctrl+Shift+Alt+U），IDEA会生成这个类相关的继承结构和关联引用。在生成的类图上，右键可以开关显示字段、构造器、方法、依赖、实现等。

IDEA生成图有几个特点：

• 继承（泛化）和接口实现会自动识别，这是最可靠的部分。
• 字段引用自动画成实线关联，但工具没法区分聚合还是组合。
• 方法参数和局部变量里的依赖不会自动生成，需要手动添加。

所以我的习惯是：先让IDEA生成骨架，再用五步判定法人工检查每一根线。特别是聚合和组合，工具完全不知道你的领域语义，你需要手动把线调整成空心菱形或实心菱形。这个手动修正过程同时也是对自己设计的一次复盘。

6.3 从代码到最终图的完整工作流

我目前带项目时，标准流程是这样的：

1. 先盘点核心稳定类型，排除DTO、请求体、工具类、配置类这些“噪音”类型。
2. 用五步判定法，对核心类型逐一标记关系类型和方向。
3. 在StarUML或IDEA里画出/修正关系线，把多重性、角色名、菱形位置全部检查一遍。
4. 做一个反向走查：对着图，用代码逐行对照每个关系。如果发现某根线在代码里找不到支撑，说明要么图画错了，要么代码结构有问题。

这套流程走完，评审会上通常能省掉大量无意义争论。关系线背后的歧义少了，大家才能把注意力放在真正的设计问题上。

我自己还有一个不成文的习惯：如果一张类图上有超过三分之一的关系被评审者怀疑，那问题大概率不在画图上，而在代码本身的依赖结构上。关系画不清楚，往往是设计边界没理清的前兆。与其把精力花在争论箭头方向，不如回到代码把模块边界重新梳理一遍。