如果只挑一个必须拿分的点我一定会把类图放在最前面。软件工程复习里类图不仅是UML各类图表的起点也是几乎所有课程设计文档里的必备图更是笔试和面试里最容易拉开分差的知识点。很多同学觉得类图简单不过是一个方框加几条线结果一到真画的时候箭头方向、空心菱形和实心菱形的区别、虚线和实线的取舍各种细节全乱套。这篇复习笔记会从类图在软件工程流程中的定位讲起把语法基础、六种关系判定、综合题推导、工具实操和冲刺阶段的失分点一次性整理完适合正在备考软件工程期末、准备课程设计文档或者想用类图快速梳理已有代码的同学参考。1. 复习类图前先搞明白它在软件工程流程里到底解决什么问题1.1 从需求到代码类图承担的是“结构翻译”软件工程课程一般绕不开这样一个流程需求分析、概要设计、详细设计、编码、测试。类图最活跃的阶段是概要设计和详细设计之间它要把需求文档里那些口语化的描述翻译成开发人员能直接落地的“类结构”。你可以把类图理解成一套建筑的施工结构图——需求分析只告诉你这里要盖一栋楼但楼里有多少房间、承重墙在哪、房间之间怎么连接这些信息要靠结构图来明确。类图做的正是这件事告诉开发团队系统里有哪些类、每个类承担什么职责、类与类之间是什么关系。我在实际项目里复盘过很多次凡是设计阶段偷懒没画类图或者画得含糊的项目后期沟通成本一定高。新同事接手代码库如果有一张清晰的类图他很快就能知道入口类是谁、核心服务类在哪、数据层怎么隔离如果没有这张图就只能一个类一个类地点开看效率低得让人抓狂。1.2 类图不只是画给老师看的它有三种真实用途复习的时候千万不要抱着“类图只是应付作业”的心态至少有三个场景你会频繁用到它设计新系统开工前把脑子里零散的类抽象出来先画关系再写代码可以避免写到一半发现设计不合理。代码评审和重构讨论“这里要不要加一层接口”“这个类是不是太胖了”的时候直接打开类图说话比在代码里翻来翻去直观得多。逆向梳理遗留项目接手一套没有文档的旧系统用工具从代码反向生成类图能快速定位核心模块和依赖关系。类图之所以被放在复习的首位正是因为它连接了“问题域”和“代码域”。你不在这个层面建立思维后面学的设计模式、架构分层都会缺一根主心骨。1.3 类图和其他UML图的分工不要搞混还有一点很容易在考试里被顺带一考类图属于静态结构图它只表达“某个时刻系统的结构长什么样”不表达“某个动作发生的前后顺序”。顺序图、活动图、状态图解决的是动态行为问题。有些同学拿到题明明问的是类图却写出了方法调用的顺序这就是没有分清静态和动态的范畴。遇到这类题先在草稿纸上写一句“只画结构不画流程”能有效防止跑偏。2. 类图语法基础类框、可见性、静态抽象这些细节别丢分2.1 标准类框由三部分组成一个类在类图里就是一个矩形框从上到下分成三个区域类名、属性区、操作区。类名不能省略属性区和操作区即使在简化场景下也尽量保留因为考试往往根据属性和方法来判断类之间的关联性质。属性的标准写法是这样的可见性 属性名: 类型 默认值举个例子- title: String 未命名表示这是一个私有属性类型是String默认值是“未命名”。操作的标准写法是在属性格式基础上加上参数和返回类型可见性 方法名(参数名: 参数类型): 返回类型比如 borrowBook(bookId: int): boolean表示一个公有的借书方法接收整数类型的bookId返回布尔类型。这个书写格式几乎是所有教材的统一约定考试画图时哪怕类名取得简单只要格式写对了就能拿基础分。2.2 可见性符号必须形成肌肉记忆可见性符号是最基础也最容易混淆的知识点我建议直接背成歌诀符号英文含义public公有所有类都可以访问-private私有只有本类内部能访问#protected受保护子类可以访问~package包内可见同一个包里的类可以访问这里有个复习小技巧不要把可见性当成孤立符号要把它和“谁是访问者”联系起来。看到#就意识到这个属性是要留给子类扩展的看到-就意识到这个类想隐藏内部状态。理解到这个层面后面学设计模式时“开闭原则”“信息隐藏”这些概念就有了直观载体。2.3 抽象类、接口和静态成员的特殊表达考试画图时经常会考特殊类型的表示方式主要有三类抽象类类名和抽象方法名使用斜体或者在类名上方标注«abstract»。接口在类框的第一个区域标«interface»接口名下通常只有操作没有属性。静态成员在属性名或方法名下方加下划线表示它属于类而不是某个实例。抽象类和接口的区别在类图里非常清楚抽象类可以有具体属性和实现方法接口只表达能力契约。画图时如果发现某个类只有一堆方法声明、一个属性都没有你就要考虑它是不是应该画成接口。这个判断在综合题里经常决定你后续的关系线怎么连。2.4 类框里的属性要精不要多很多同学画类图时恨不得把类的所有字段全塞进去结果框子大得离谱。实际上考试中的类图是设计层面的表达不是代码级报表。属性写关键的状态字段方法写对外能提供的行为那些临时变量、内部缓存字段完全没必要画。复习时多做减法一个类用三到五个核心属性和两到三个核心方法表达清楚就已经很专业了。这样画出来的图不仅清晰也给关系线和多重性标注留出了空间。3. 六种关系的判定是重头戏从箭头形态到代码特征3.1 泛化和实现一个“空心三角”就能看明白两种关系UML类图的关系一共有六种泛化、实现、依赖、关联、聚合、组合。考试最爱考的区分题就是给你一段描述让你判断该画哪种关系、箭头朝哪边。先说泛化。泛化对应代码里的extends关键词是继承关系。它的画法是实线加空心三角箭头三角一定要指向父类。举个最简单的例子学生是父类大学生继承学生那么箭头从大学生指向学生。很多同学第一次画都容易画反记住一句口诀三角箭头是儿子的“枪口”永远指向父亲。实现关系对应代码里的implements画法是虚线加空心三角箭头三角形指向接口。和泛化唯一的区别就是那条线是虚的。为什么是虚线你可以这样理解接口只是契约并不是真正的实例化结构实体会通过具体类实现所以用虚线表示“不完全实在”的关系。3.2 依赖关系最弱的关系却最容易被漏判依赖的画法是虚线箭头比如A .. B表示A依赖于B。它对应代码里“某个方法内部临时使用了B”的情况具体包括方法参数中声明了B类型的对象。方法内部创建一个B类型的局部变量。方法返回类型是B。方法内部调用了B的静态方法。依赖是六种关系里最弱的一种它不要求A长期持有B的引用只要“临时用过一次”就算依赖。考试里最容易漏判的就是它。如果一个类只是在某个方法里调用了一下另一个类的工具方法很多同学会忽略掉导致整个关系图缺线。依赖和关联的区分也是高频错点。区分标准很简单如果B只是方法参数、返回值或局部变量画依赖如果B是A的成员变量画关联。复习时可以反复用这个题自测“老师类和学生类之间如果老师类里有一个List类型的学生属性应该画什么”答案是关联因为老师长期持有学生列表。如果只是某个方法里临时创建了一个学生对象才是依赖。3.3 关联关系实线箭头表达“长期持有”关联的画法是实线可以有箭头也可以没有箭头箭头表示导航方向。如果A类里有一个属性是B类型那么A和B之间就是关联关系箭头从A指向B表示A知道B的存在B不一定知道A的存在。如果两边都有对方的属性那就是双向关联两边都画箭头甚至可以不画箭头只画一条实线。关联关系还可以表达多重性这是考试里必须拿分的地方。多重性标注在线的两端表示“一个类对应多少个对象”。比如1恰好一个。0..1零个或一个。*零个或多个。1..*一个或多个。画法上有个容易混淆的小地方多重性要写在对面的类旁边。比如“一个读者可以借阅多本图书”那么读者那端写1图书那端写*也就是在图书类旁边标注*在读者类旁边标注1。我复习时一度把这两个写反每次都是靠“靠近谁就说明谁的数量”这个规律纠正过来。关联关系还有一个自关联的情况就是类自己连自己。典型例子是员工和上级经理一个员工对象里有一个属性指向另一个员工对象。这时候画一条从类到它自身的实线线上标好角色名和多重性就可以。3.4 聚合和组合空心菱形和实心菱形的“生命周期”判断聚合和组合都是表达“整体-部分”关系画法都是实线加上菱形菱形画在“整体”那一端。区别在于菱形是空心的还是实心的。聚合用空心菱形表达整体和部分可以分离。比如“班级”和“学生”班级解散了学生依然存在仍然有学籍能转去别的班级。再比如“出版社”和“图书”出版社倒闭了书依然在市场上流通。这类关系的特点就是整体消失后部分不跟着消失。组合用实心菱形表达整体和部分同生共死部分离开整体就没有独立意义。最典型的例子是“订单”和“订单项”订单删除订单项必须一起删除订单项脱离订单没有任何业务价值。再比如“窗口”和“滚动条”窗口销毁滚动条自然消失。这种强绑定的生命周期就是组合。很多同学会在这两个关系上纠结我提供一个快速判定法想象把整体删掉然后再问一句“部分还剩不剩”。如果部分还在聚合如果部分必须跟着没组合。这个判定法在考场上特别好用几乎不需要在语义层面反复绕。3.5 六种关系对比速查表把六种关系整理成一张表贴在笔记首页复习效率会高很多关系线型关键符号代码特征强度一句话判定泛化实线空心三角指向父类extends强儿子继承父亲实现虚线空心三角指向接口implements强类实现契约依赖虚线普通箭头方法参数/局部变量/返回值最弱临时用了一下关联实线普通箭头可选成员变量弱长期持有引用聚合实线空心菱形在整体端成员变量中整体没了部分还在组合实线实心菱形在整体端成员变量强同生共死这张表最大的价值在于把符号和代码特征对应起来。考试时即使一时想不起来图形长什么样先回忆代码里是什么关系再反推符号基本上不会跑偏。4. 综合题怎么破一个图书管理系统的类图推导全过程4.1 先看一段典型题目描述综合题通常给你一段系统描述让你画出类图。我们用一个经典简化的图书管理系统来做推导。题目描述可以设计成这样读者分为普通读者和VIP读者普通读者和VIP读者都继承自抽象类Reader。读者可以借阅多本图书一本图书也可以被多个读者借阅。一次借阅会产生一个借阅订单订单项属于订单且订单一旦删除订单项必须删除。出版社可以出版多本图书出版社即使暂时没有图书也可以存在。借阅服务BorrowService实现了接口IBorrowService执行借阅操作时该方法内部会临时调用罚款计算器FineCalculator计算滞纳金。这段描述虽然不长但六种关系全部覆盖到了非常适合用来梳理推导逻辑。4.2 第一步把所有名词抓出来得到候选类做这种题的第一步不是画线而是先抓名词。把上面描述里的名词列出来Reader普通读者VIP读者Book借阅订单订单项PublisherBorrowServiceIBorrowServiceFineCalculator这里有个过滤技巧并不是所有名词都要变成类。“系统”“接口”“订单”这类业务概念一般要“计算过程”“调用过程”这类动词名词化的概念不一定要。候选类可以初步定为上面这十个。4.3 第二步逐对分析关系逐条落实画法接下来就是最核心的关系分析。我习惯拿一张草稿纸把类名先摆开然后逐对分析普通读者和VIP读者都继承自Reader这两条是泛化关系实线加空心三角三角指向Reader。又因为Reader是抽象类所以类名用斜体。BorrowService实现IBorrowService这是实现关系虚线加空心三角三角指向接口IBorrowService。BorrowService在方法内部临时调用了FineCalculator这是依赖关系虚线箭头指向FineCalculator。注意题目特意说了“方法内部临时调用”这个措辞就是依赖关系的信号。普通读者和图书是多对多借阅关系直接用关联线连接会显得太粗糙更好的设计是引入一个“借阅记录”关联类BorrowRecord。这时Reader和BorrowRecord之间、Book和BorrowRecord之间各画一条关联实线多重性分别写成1和1..*就合理了。Publisher和Book是“整体-部分”关系但出版社挂了书还在所以是聚合。空心菱形画在Publisher那一端。借阅订单和订单项是同生共死的关系所以是组合。实心菱形画在BorrowOrder那一端多重性可以标1和1..*。这样一轮分析下来六种关系全部落位每一条都有明确的文字依据而不是拍脑袋乱画的。4.4 第三步补充属性和方法让类图更完整关系确定后再给每个类补充关键属性和方法。这里不需要全够表达职责就行。比如Reader类里加readerId、name、borrowBooks()Book类里加bookId、title、availableBorrowOrder里加orderId、createTimeBorrowService里加borrow(readerId, bookId)。属性只写几个核心状态方法只写对外行为避免把类框撑得太大。补充属性和方法还有一个作用就是反过来验证关系。比如你发现BorrowService类里加了一个FineCalculator类型的成员变量那刚才画的依赖关系就错了应该改成关联。反过来如果BorrowService只是在方法局部用到FineCalculator那依赖关系才成立。这就是画图时“类框和关系线互相校验”的意义。4.5 第四步按正确顺序落笔先主干后细节考试或作业里画图我推荐的落笔顺序是先画抽象类和接口它们是整个图的结构骨架。再画继承泛化线把父子关系铺开。后画实现线把接口和实现类连起来。再处理聚合和组合这类整体部分关系。接着画普通关联线并标注多重性。最后补依赖关系。为什么要这个顺序因为依赖关系最弱、最细画在最后不容易被其他粗线干扰抽象类和接口是整个图的起点先把它们画出来后续的类往周围扩展时布局会合理很多。我自己复习的时候发现很多人栽在布局上画着画着线就交叉成一团。先画骨架、再逐步延伸可以大大减少交叉。5. 常见绘制场景实操StarUML、IDEA、Visio这样用最有效率5.1 StarUML课程设计和复习画图的主流选择StarUML是课程设计里最常见的工具也适合复习时手动画图。它的基本操作流程是新建一个UML项目在Model里右键添加Class Diagram然后从左侧工具箱拖入Class、Interface等元素。双击元素就能添加属性和方法右侧面板中可以设置可见性、是否抽象、是否静态。画关系线时工具箱里有Association、Aggregation、Composition、Generalization、Dependency、Realization这些工具拖到两个类之间即可。线的类型选好之后如果需要调整方向或端点样式可以通过线两端的圆形控制点来设置。多重性的标注也在这里操作右键点击靠近目标类的那条线端选择Multiplicity再选对应的数量范围。这里有个小提醒StarUML的评估版在导出图片时可能带水印不过用在本地复习或交作业截图问题不大。5.2 IDEA自动生成类图复习比手画更快的方法如果你想快速验证自己对代码结构的理解或者需要梳理已有项目的类关系IDEA自带的Diagram功能非常高效。操作方式很简单在项目树中选中一个包或一个类右键选择Diagrams再选Show Diagram。Windows和Linux下的快捷键通常是CtrlAltShiftDmacOS下是CmdOptionShiftD。生成出来的图会自动显示泛化、实现、关联等关系线你可以通过工具栏开关控制是否显示属性、方法、依赖等细节。图片可以通过右键菜单导出为PNG或复制到剪贴板方便贴到复习文档里。IDEA生成类图适合做“代码的反向梳理”比如你突然想搞明白一个老模块的类结构用它生成一张图比手动翻代码快得多。但要注意自动生成的类图通常信息过多类名和关系线密密麻麻复习考试时还是要手动整理一遍关键类不能直接拿自动图当答案。5.3 Eclipse查看类图适合老项目的快速浏览Eclipse本身不自带类图视图但可以通过安装插件来实现。比较常见的是ObjectAid UML Explorer插件。装好之后把Java文件直接拖到ObjectAid的视图里类图就会自动生成。对于老项目或者还在用Eclipse做课程设计的同学这个插件可以帮你快速看到类之间的继承和关联关系。ObjectAid有一个特点它默认显示的是代码里的实际关系而不是你自己手动画的关系。所以在复习时我建议把它当成“参考答案生成器”用来对照自己手画的类图看有没有漏掉关联或依赖。不过插件生成的图不会主动替你做设计判断它只是代码事实的投影。5.4 Visio画UML类图适合论文插图但不适合设计迭代用Visio画UML类图也是很多同学的刚需尤其是毕业论文和课程设计文档插图。操作上打开Visio后选择“类别”里的“软件和数据库”再选“UML模型图”或“UML类图”。左侧形状窗格中会提供类、接口、关联、聚合、组合等模板形状直接拖到画布上即可。Visio的优势是排版的精细度和文档兼容性画出来的图放进Word里很工整。缺点是几乎全手动类的属性、方法需要右键逐个编辑关系线也要自己逐条连线。如果项目类很多用Visio画图会非常耗时而且一旦设计变更整张图要重新调整。所以我的经验是Visio适合“最终交付文档”这个环节不适合在方案还没稳定时做迭代设计。5.5 工具选型对照表把几个常见工具放在一起对比可以帮助你根据不同场景快速做选择工具上手速度自动化程度适合阶段主要缺点StarUML中等中课程设计、复习手画评估版有水印IDEA Diagrams快高代码反向梳理、复习对照信息过多需要整理Eclipse ObjectAid中等高老项目快速浏览需要装插件Visio中等低论文文档插图手动操作量大6. 冲刺阶段的失分点与自检清单6.1 高频错误前三名复习到最后我会把高频错误浓缩成三句话随时提醒自己依赖和关联混淆。看到“属性里持有对方”才画关联看到“方法里临时用了一下”就画依赖。多重性标注反了。口诀是“靠近谁就表示谁的数量”比如一个出版社对应多本书书那一端写*。聚合和组合的菱形方向画错。菱形永远在整体那一端空心是聚合、实心是组合不要画在一对多关系里属于“多个”的那一端。6.2 三个临时记忆锚点如果考试状态紧张短时记忆特别容易乱我建议在草稿纸上快速写下三个锚点空心三角父子关系是泛化或实现三角指向父亲或接口。虚线要么是依赖要么是实现。带三角的是实现不带三角的是依赖。菱形整体部分关系。看到菱形先问“整体删了部分还在吗”在就是空心不在就是实心。这三个锚点覆盖了六种关系中的五种剩下一个普通关联只要看到实线、没有三角、没有菱形就基本可以往关联上靠。6.3 考前自检清单每次画完一张类图我都按下面这个清单检查一遍发现问题就当场改每个类名是否有明确业务含义有没有出现“Data”、“Manager”这类为了凑数而建的类。属性和操作的可见性符号是否都标了是否和需求描述一致。泛化和实现的三角箭头是否指向父类或接口。依赖线是否画成了虚线关联线是否画成了实线。聚合和组合的菱形是否在整体端空心和实心是否正确。多重性是否写在对面的类旁边是否和描述里的“一个对多个”对应。整体到整体、部分到部分之间的线有没有出现交叉过多的情况。最后把题目描述盖住只读类图看能不能把业务故事顺下来如果读不通说明图里有漏线或错线。这套清单我考前反复用了很多遍每次都能抓出至少一两个细节错误。尤其是最后一条“回读”非常管用。类图不是画完就算完它本质上是一个模型模型最重要的品质是自洽。把图当故事读一遍很多逻辑错误自己就暴露了。复习类图这件事最忌讳的就是只背符号不练推导。符号只是语言真正值钱的是“看到文字描述能快速联想到正确关系”的能力。我在实际开发里画类图的机会不比考试少但每次画都还会有一点点新理解。先把这篇笔记里的推导方法吃透再动手画上三五张综合题类图这门课的分数基本就稳了。