企业官网建设流程全解析

1. 类图在面向对象分析里到底站在什么位置

刚入行那会儿，我对类图的理解特别肤浅，觉得它就是一堆方框加箭头，画出来给领导看的"技术画"。直到有一次接手一个已经跑了三年的老系统改造，前任留下的文档几乎为零，唯一能找到的就是几张泛黄的类图截图，我才真正意识到——类图不是装饰品，它是整个面向对象分析过程中承上启下的骨架。今天这篇就围绕面向对象分析和类图这两个核心，把我这些年踩过的坑、总结的方法、用过的工具都摊开来聊。

先说清楚这个东西是什么。面向对象分析（OOA）本质上是一个"把现实世界翻译成对象世界"的过程，而类图（Class Diagram）是UML里用来描述系统中类、接口、它们之间的静态结构关系，以及属性、方法的一张结构化视图。它不管你代码怎么跑、时序怎么走，只管一件事：这个系统里有哪些"东西"，这些东西各自长什么样，彼此之间又是什么关系。换句话说，类图回答的是"系统由什么组成"而不是"系统怎么运转"。

它能解决什么问题？最直接的三个：第一，团队沟通有了统一语言，产品经理说"订单关联多个商品"，开发脑子里浮现的是一对多关联线，不会各说各话；第二，代码设计有了提前推演的地方，哪些类该抽象、哪些关系该用组合、哪些地方会形成循环依赖，在画图阶段就能暴露出来；第三，重构和交接有了依据，一张清晰的类图比几千行注释更能让新人快速理解系统结构。

适合谁来参考？如果你是刚学面向对象的学生，这篇能帮你把书本上抽象的概念落到具体箭头和代码上；如果你是工作两三年的开发，想从"能写代码"进阶到"会做设计"，类图是你绕不开的基本功；如果你是带团队的技术负责人，怎么让组员画出有用而不是好看的类图，这里面的取舍经验应该对你有帮助。接下来我会从设计思路、核心关系拆解、工具实操、活动图配合、实战案例、问题排查几个层面,一层层往下讲。

2. 类图的整体设计思路与建模取舍

2.1 为什么类图要先做减法再做加法

很多人画类图有个通病，一上来就想把所有类都塞进去，结果画出来像一张蛛网，密密麻麻谁也不敢看。我的经验是反过来——先做减法，再做加法。具体来说，第一轮只识别核心领域概念，把跟当前分析目标无关的类全部砍掉。比如你分析的是订单模块，那用户权限、日志埋点、缓存策略这些先别画，它们属于另一个关注点。

这个思路背后的逻辑是"关注点分离"。一张类图对应一个分析视角，视角越多图越乱。你完全可以用三张类图分别描述领域模型、服务层结构、数据访问层结构，各自清晰。我见过一个团队硬生生把整个电商系统塞进一张A4纸大小的类图里，结果开会讨论时没人能找到自己关心的那个类，这就是典型的贪多嚼不烂。

第二个取舍点是抽象层级要统一。同一个层次的东西放一起画，比如"订单""商品""用户"都是业务实体，层级一致；如果你把"订单"和"订单表的自增主键生成器"画在一起，层级就错乱了。判断标准很简单：问自己这些类是不是在同一个业务抽象层面上说话，不是的话就分开画。

2.2 类的识别：从名词到对象的翻译方法

识别类这件事，最土但最有效的办法是在需求描述里圈名词。拿起一段需求文字，把所有名词和名词短语圈出来，比如"系统需要管理客户信息，客户可以下多个订单，每个订单包含若干商品，商品属于某个分类"。圈出来的是：系统、客户、订单、商品、分类。然后做一轮筛选——"系统"这种太泛的去掉，剩下的客户、订单、商品、分类基本就是候选类。

但光靠圈名词是不够的，这只是起点。接下来要做一轮"职责校验"：这个候选对象有没有自己的状态（属性）和行为（方法）？如果它只是一个纯数据容器，可能更适合做成属性而不是独立类；如果它有明确的行为和生命周期，那它就是合格的对象。举个例子，"地址"在有些场景下就是客户表里的几个字段，但如果你需要单独管理收货地址簿、支持一个用户多个地址、地址还要做校验和格式化，那"地址"就值得单独成类。

这里有个我自己总结的判别口诀，分享给你：有状态、有行为、有身份、有生命周期，四个里占两个以上就单独成类，只占一个就考虑降级为属性。这个口诀不绝对，但能帮新手快速做判断，避免把类图画成字段的堆砌。

2.3 分析阶段和设计阶段类图的差异

同一个系统，分析阶段的类图和设计阶段的类图长得完全不一样，很多人分不清这一点。分析阶段的类图是概念类图，只描述业务概念和它们的关系，不关心技术实现。比如分析阶段只有"订单——商品"的关联，最多标个多重性（一个订单对应多个商品）。到了设计阶段，类图就要落地了，你得引入接口、抽象类、工厂类、仓储类，关联关系也要明确用集合还是数组、用组合还是聚合、要不要引入中间表。

我的建议是分两轮画：第一轮画概念类图，跟业务方对齐，确保对领域理解一致；第二轮画详细设计类图，跟开发对齐，明确每个类的方法签名和依赖方向。两轮图不要混在一起，否则业务方看不懂技术细节，开发又觉得业务图没营养。

2.4 类图的边界在哪里：什么时候该停笔

画类图最大的诱惑就是"再细化一点"。但类图不是越细越好，写到方法级别的类图其实已经接近代码了，这个时候继续画反而浪费时间，不如直接写代码。我的经验边界是：类图描述到"方法签名"这一层就够了，方法内部怎么实现不要画，那是活动图或者时序图的活儿。类、接口、属性、关键方法签名、类之间的关系，画到这，类图的使命就完成了。

3. 类图的核心元素与五种关系拆解

3.1 类、属性、方法的标准表示法

一个标准的类在UML里用三层矩形表示：最上面是类名，中间是属性，最下面是方法。属性写法一般是可见性 名称: 类型，比如- id: Long，前面的减号表示私有（private），加号是公有（public），井号是保护（protected），波浪号是包内可见。方法也是类似的格式：+ 方法名(参数): 返回值。

这里说几个新手容易忽略的细节。第一，类型可以省略，在概念类图里只写属性名就够了，但详细设计阶段建议写全类型，否则开发还得猜。第二，静态成员要加下划线，这个很多人不知道，静态属性和静态方法在UML里是用下划线标注的。第三，抽象类名和方法名要用斜体，这能一眼区分哪些是不能直接实例化的。

属性下面那块，有时候会有人写上getter/setter之类的东西，我的建议是别写，那是Java的语法糖，不是设计层面的信息，写了只会让图变脏。真正值得填进去的是业务上有意义的方法，比如订单类的calculateTotal()、canCancel()，这些才是设计要表达的内容。

3.2 五种关系对照：依赖、关联、聚合、组合、继承

这是类图最核心也最容易搞混的部分，我按耦合强度从弱到强排一下，顺便配上代码感受一下区别。

依赖（Dependency）用带开放箭头的虚线--->表示，意思是A在某个方法里临时用到了B。这是最弱的耦合，代码上通常表现为方法参数、局部变量、静态方法调用。比如一个OrderService里调用了DateUtil.format()，这就是依赖关系。

关联（Association）用实线表示，是A长期持有B的引用。比如Order里有个User user字段，这就是关联。关联可以标注多重性（1、0..1、1..、），也可以加角色名。

聚合（Aggregation）用带空心菱形的实线表示，菱形指向整体。它是一种特殊的关联，强调"整体-部分"但部分可以独立于整体存在。比如"班级"和"学生"，班级解散了学生还在，这就是聚合。

组合（Composition）用带实心菱形的实线表示，也是整体-部分，但部分不能独立于整体存在。比如"订单"和"订单项"，订单删了订单项就没意义了，这就是组合。组合是最强的关联。

继承（Inheritance/Generalization）用带空心三角的实线表示，箭头指向父类。子类继承父类的属性和方法，这是"is-a"关系。

3.3 五种关系画出类图并观察区别的实操练习

光看表格记不住，我建议你找个真实场景练一遍：设计一个"公司-部门-员工-项目"的模型。公司聚合部门（部门可以独立存在）、部门聚合员工、项目关联员工（一个员工可以参与多个项目）、项目经理是员工的子类（继承）、项目里用到了日期工具类（依赖）。把这五种关系在一张图里画全，看看箭头和菱形怎么摆。

关键是观察两个地方：一是聚合和组合的菱形方向，空心/实心菱形永远指向"整体"那一端，很多人会画反。二是多重性的位置，多重性标在关系线的两端，表示这一端的类有多少个实例对应另一端。我见过太多人把多重性标错位置，一个订单有多个商品，多重性1..*应该标在商品那一端（表示商品端有多个），而不是订单端。

代码上怎么体现区别？聚合和组合在Java代码里可能都是成员变量，区别在生命周期管理上。组合关系里，整体创建时会new出部分，整体销毁时部分跟着销毁；聚合关系里，部分由外部传入，整体只是持有引用。这一点在类图上不会直接写出来，但你画图时脑子里必须有这个生命周期概念，否则画出来的组合和聚合就是形似神不似。

3.4 接口、抽象类与泛化的表达

除了类之间的五种关系，类图里还经常出现接口和抽象类。接口用带箭头的虚线加一个「interface」标记，实线箭头指向它表示实现（Realization）。抽象类跟普通类一样画，只是类名和抽象方法用斜体。

这里有个实战经验：接口和抽象类在类图上很容易混淆，尤其是有些工具不显示构造型（stereotype）标记的时候。我的建议是用StarUML或IDEA这类工具时，确保打开构造型显示，接口一定标上「interface」，这样团队看图的歧义会少很多。如果是手绘或用Visio，就在接口名上方手写标注，别偷懒。

泛化（继承）和实现（接口）的区别也要注意：泛化是空心三角实线，实现是空心三角虚线。前者表示"是一个"，后者表示"能做一个"。一个类可以继承一个父类但实现多个接口，画的时候箭头会集中指向不同的目标，这时候图的布局就很考验功底了，建议把父类放上方、接口放右侧，让线条尽量不交叉。

4. 主流工具实操：从StarUML到IDEA的正反向出图

4.1 StarUML画类图的完整步骤

StarUML是我个人最推荐的独立建模工具，界面清爽，五种关系的符号都很规范。具体步骤：打开StarUML新建Model，右键添加Class Diagram，然后从左侧工具栏拖拽Class元素到画布。双击类可以编辑名称、添加属性和方法，在属性编辑区按照可见性 名称: 类型的格式一行一个填。

画关系的时候，工具栏上有对应的箭头按钮——Association、Aggregation、Composition、Generalization、Dependency 一字排开。点中关系按钮，从源类拖到目标类即可。画完之后右键关系线可以设置多重性、角色名、导航性。这里有个坑：StarUML默认画出来的是双向关联，如果你只想表达单向导航，需要右键关系线把Navigable勾掉一端，否则开发会误以为双向依赖。

导出方面，StarUML支持导出为图片、PDF，也支持生成Java代码骨架。我一般会把类图导出成PNG贴进设计文档，同时保留.mdj源文件，方便后续修改。注意StarUML新版本是收费的，学生可以用开源替代品如draw.io或者早期的StarUML版本。

4.2 IDEA生成类图：从代码反向出图

如果你的项目已经是写好的代码，想在IDEA里生成类图，操作其实很简单：在项目视图里选中一个包或者几个类，右键选择「Diagrams」->「Show Diagram」，IDEA就会自动生成一张类图。但这只对已编译的代码或者已索引的源码有效，如果依赖没解析成功，生成的图会缺关系。

IDEA生成的类图默认只显示当前包的类，如果要显示关联的类，需要右键图里某个类选择「Show Dependencies」，它会递归展开。快捷键方面，Ctrl+Alt+Shift+U是打开图表的常用组合，Ctrl+Alt+U是弹出预览。实测下来，IDEA的类图适合快速理解现有结构，但它对多重性、角色名的支持很弱，基本只是"谁继承谁、谁引用谁"的物理关系，不适合做正式设计文档。

另外提醒一句：IDEA社区版对UML图的支持是有限的，有些高级的依赖分析需要旗舰版。如果你的IDE是社区版打不开图表功能，别以为是项目问题，是版本限制。

4.3 Eclipse查看类图插件的配置

Eclipse本身不带类图功能，需要装插件，最常用的是ObjectAid UML Explorer。安装方式是在Help->Install New Software里添加ObjectAid的更新地址，装完之后新建一个.ucls文件，把要分析的类拖进去，它就会自动生成类图。

Eclipse这套方案的优势是实时联动，你改了Java代码，类图会跟着更新，适合做代码结构监控。缺点是只能展示已编译的类，而且关系识别比较保守，泛化、实现能识别，聚合和组合它一律当作普通关联，基本分不出来。所以用它做快速浏览可以，做正式设计还是要靠StarUML这类建模工具。

4.4 用Visio画UML类图的方法

Visio画类图，很多人第一反应是找不到模板。实际上在新版Visio里，可以搜索「UML」找到「UML类图」模板，里面已经内置了类、接口、各种关系连接线。如果搜不到，用「软件和数据库」分类下的「UML模型图」也能凑合。

用Visio画类图的流程是：拖一个Class形状到画布，在形状数据里填类名、属性、方法，然后从工具箱里选关系线连接。Visio的一个好处是排版能力强，适合画大图然后打印贴墙，团队评审的时候很直观。缺点也明显：它不生成代码，改起来纯手工，而且关系线的多重性标注需要手动添加文本框，容易漏。

我个人的工具选择建议是：要精准表达五种关系用StarUML，要看现有代码结构用IDEA或Eclipse插件，要排版好看贴文档用Visio。三者不是替代关系，看场合用。

5. 类图与活动图的配合使用

5.1 类图和活动图各自负责什么

单独说类图容易让人产生一个误解，以为一个系统画完类图就完了。其实类图只描述静态结构，它回答不了"这个下单流程怎么走"。这时候需要活动图（Activity Diagram）出场。活动图描述的是业务流程或算法步骤，用开始节点、动作、判断、合并、结束节点把流程串起来。

两者的分工可以用一个比喻概括：类图是"剧组名单"，告诉你有演员、导演、道具师这些角色以及他们之间的关系；活动图是"分镜脚本"，告诉你每一场戏谁先出场、做什么动作、遇到分支怎么走。你做面向对象分析的时候，两个都要用，先用活动图梳理业务流程，再从流程里识别出参与的对象，最后用类图固化对象结构。

5.2 从活动图反推类的实战流程

这个配合怎么落地？我拿一个"用户下单"的流程举例。先用活动图画：用户浏览商品 -> 加入购物车 -> 提交订单 -> 系统校验库存 -> 校验通过则生成订单 -> 扣减库存 -> 发起支付 -> 支付成功 -> 更新订单状态。

画完活动图，你开始从每个动作里找名词和动词。动作"生成订单"提示你需要一个Order类；"校验库存"提示需要一个InventoryService；"扣减库存"说明Inventory有deduct()方法；"发起支付"说明需要一个PaymentService和Payment对象。这样从流程节点一个个映射到类，最后再整理成类图，比凭空想象要靠谱得多。

这个方法的精髓在于活动图帮你发现了隐含的服务类。很多人画类图只画得出业务实体，画不出服务类，原因就是只从名词出发，忽略了动作。而动作往往对应服务类的方法，这个线索只有流程分析才能给出。

5.3 两种图在同一文档里的组织方式

如果要把两种图放进同一份设计文档，我的排版习惯是：先放活动图讲"业务怎么流转"，再放类图讲"对象怎么组织"，中间用一段文字过渡，说明从流程中识别出了哪些核心对象。这样读者先建立动态认知，再建立静态认知，理解成本最低。

要避免的是把活动图和类图画在同一页或者同一张画布里，那样信息密度太高，读者眼睛不知道往哪放。宁可多分几页，也别挤在一起。

6. 实战案例：从需求到类图的完整推演

6.1 需求梳理与候选项识别

我拿一个简化版的"图书馆借阅系统"做案例，需求描述是：读者可以借阅图书，一个读者可以同时借多本书，每本书有唯一ISBN，图书分为纸质书和电子书两种，借阅有借出日期和应还日期，逾期会产生罚金，管理员负责处理借还操作。

先圈名词：读者、图书、ISBN、纸质书、电子书、借阅记录、借出日期、应还日期、罚金、管理员。再做职责校验：ISBN是属性不是类；借出日期和应还日期是借阅记录的属性；罚金可以是借阅记录的方法计算出来的属性；纸质书和电子书是图书的子类；管理员是一个独立角色。最终候选类：Reader、Book、PaperBook、Ebook、BorrowRecord、Admin。

6.2 关系判定与箭头选择

接着判关系。BorrowRecord和Reader是关联（一个读者有多条借阅记录，记录持有读者引用）；BorrowRecord和Book是关联（一条记录对应一本书）；PaperBook和Ebook都继承Book（泛化，空心三角指向Book）；Admin和BorrowRecord是依赖或关联，取决于管理员是否需要长期持记录，一般用关联更稳妥。

这里有个细节要注意：借阅记录和图书到底是关联还是组合？我的判断是关联，因为书被还回来之后还在系统里，不会因为记录删除就消失。如果误判成组合，代码里就会写成"删除借阅记录时把书也删了"，那是灾难性的bug。这个判断依据就是前面说的生命周期原则。

类图的关键属性也要补上：Book有isbn、title；BorrowRecord有borrowDate、dueDate，还有一个calculateFine()方法；Reader有id、name。

6.3 布局优化与可读性处理

图画完了不代表就能交付，布局才是让图"能看"的关键。我的布局原则有三条：继承关系从上往下排（父类在上，子类在下）；强耦合的类放一起（组合、聚合的两端靠近）；关系线尽量不交叉，交叉了就把类挪一挪。

具体到这个案例，我把Book放顶部，PaperBook和Ebook并排在下方；中间放BorrowRecord，它同时连向Reader和Book；Admin放在右侧。这样线条走向清晰，读者一眼就能看懂结构。如果关系线还是乱，可以考虑拆分成两张图——一张画图书体系，一张画借阅体系，用一张简图连接。

6.4 从类图到代码骨架的落地

类图最终要能指导编码。以BorrowRecord为例，类图告诉开发：这个类关联Reader和Book，有borrowDate、dueDate属性和calculateFine()方法。翻译成Java大概是：

public class BorrowRecord { private Reader reader; private Book book; private LocalDate borrowDate; private LocalDate dueDate; public BigDecimal calculateFine(LocalDate returnDate) { if (returnDate.isAfter(dueDate)) { long overdueDays = ChronoUnit.DAYS.between(dueDate, returnDate); return FINE_PER_DAY.multiply(BigDecimal.valueOf(overdueDays)); } return BigDecimal.ZERO; } }

看到没，类图画对了，代码骨架几乎是自动生成的。这也是为什么我说类图是设计与实现之间的桥梁——它就是代码的地图，地图画准了，后面的路就好走。

7. 常见问题排查与避坑实录

7.1 类图关系画错的典型症状与修正

症状一：聚合和组合的菱形画反了。空心或实心菱形必须指向"整体"那一端。我见过很多人画"订单项-订单"关系时，菱形指向订单项，这是错的。修正方法：读一遍关系，问自己"谁包含谁"，包含方就是菱形那一端。

症状二：多重性标在了错误的一端。记住多重性描述的是"视线从这一端看向另一端时，另一端有几个实例"。一个订单有多个商品，站在订单看商品是多个，所以*标在商品端。不确定的时候就默念"这一端的类，对应另一端的几个对象"。

症状三：把依赖画成了实线。依赖必须是虚线，这个没有例外。如果两个类之间只是方法调用关系，永远是依赖，画成实线关联会让耦合关系被高估。

7.2 工具使用中的高频坑

StarUML的自动双向关联坑前面提过，再强调一次，画完一定要检查导航性。IDEA生成的类图缺关系，多半是因为依赖的jar没索引或模块没编译，重新构建一下项目通常能解决。Eclipse插件不显示组合聚合，这是插件能力限制，不是你的错，需要精确表达就换工具。Visio找不到UML模板，可以试试用"基本流程图"里的矩形加手工连接线，虽然不规范但应急能用。

7.3 我的实操心得

最后分享几条我个人沉淀下来的经验。第一，类图一定要跟代码同步，代码改了图不改，图就成了误导人的"历史文物"。我现在的做法是核心模块的类图跟着版本走，每次重构必须更新。

第二，给类图加个版本号和日期，放在图的角落。这样团队看的时候能判断这张图是不是最新的，避免拿旧图指导新开发。

第三，不要追求一张图覆盖全部，拆成多张反而更清晰。我经手过的最好的一个项目，类图分了领域模型、服务层、数据层三张，每张都干净利落，新人半天就能上手。

第四，画之前先跟业务方对一遍概念，否则你画的类名跟业务嘴里说的完全不是一回事，评审时会被反复打回。先对齐词汇表，再动笔，能省一半时间。

第五，五种关系的区别，最好的记忆方式是动手写代码。把同一个场景用依赖、关联、聚合、组合、继承分别写一遍，代码写完，你自然就记住区别了，比背十遍图形符号管用。