1. 冲刺第6天拆题UML类图和对象图在软考中的真实分量学习任何考点之前先搞懂它在考卷里占多少分、以什么形式出现否则很容易出现背了一整本书考场上一道题没押中的现象。我翻了近五年软考中级软件设计师、系统分析师和系统架构设计师的真题UML的出镜率是真的高上午选择题里少则两三道、多则四五道一定会落在UML相关图上下午案例题里结构建模和设计模式相关题目也几乎都会拿类图做载体。换句话说类图和对象图不是你了解一下就好的章节而是实打实的得分命脉。如果你是从DAY01开始跟这个系列走到现在的前面应该已经把数据流图、数据字典和用例图的套路理得差不多了。今天这站我们就专门把UML静态建模的核心——类图和对象图——彻底盘明白。这篇我会按自己的冲刺节奏来写先讲考点分量和命题形式再拆类图元素然后是关系判断的速查表接着是对象图实战最后给出一套适合碎片时间的记忆清单。如果你今天时间紧可以直接跳到第6章把口诀过一遍再回头精读中间的内容。1.1 三种典型考法选择题、场景判断题、案例补全题第一类是纯符号选择题。题目给出一张类图或几个孤立的关系符号问哪个描述正确考的是符号记忆聚合是不是空心菱形、实现是不是虚线、多重度写在哪一端、可见性符号是不是用对了。这种题最基础只要能把符号表背熟基本不会丢分。第二类是场景映射题。题干用一百多字描述一个业务需求让从四个候选类图中选出映射最准确的那一个。这种题不是纯背符号它考的是从文字需求到对象模型的转换能力。我见过很多考生符号背得滚瓜烂熟一遇到根据描述重构类图就发懵原因就是平时只看图、不练建模脑子里没有需求到模型的翻译过程。第三类是下午案例补全题。题目给出一张半成品类图留出空位让你填类名、属性、多重度或关系类型。这种题看起来最稳妥实战中最容易翻车因为既要理解需求又要兼顾符号规范。近年的趋势也很明显同样的业务场景选择题考选择案例题直接让你动手补图难度自然往上走。注意软考下午案例题越来越喜欢用不完整类图一段需求说明的组合来出题。评分不看你解释得多漂亮只看空格填得对不对。所以平时练习必须强迫自己写得规范关系方向、多重度数字、菱形位置都要做到和标准答案一致。1.2 类图是其他UML模型的“地基”牵一发动全身我备考初期也犯过战略错误觉得类图不过是众多图里的一种优先级没那么高。直到做时序图真题时才发现自己错了时序图里对象之间的消息往来本质上是类图关系的运行时体现状态图描述的对象生命周期也建立在类图定义的状态字段之上。没有类图基础你根本不知道某个消息该从哪个对象发往哪个对象也很难判断一个交互序列画得对不对。所以第6天宁可进度慢一两成也要把类图和对象图彻底焊死。UML的知识有一个特点前期贪快留下的漏洞后期要用成倍时间填。你不信可以试试不背关系符号直接去做三道下午补全题大概率会卡在这里该实线还是虚线、菱形放在哪头这种最基础的问题上。我自己第一遍就吃了这个亏后来把所有关系符号全部重背做题速度才提上来。1.3 90天冲刺的时间分配建议别再平均用力90天冲刺不像长线备考每天能挤出的整块时间有限。如果你每天只有1.5小时我的建议是前40分钟精读类图符号与关系中间30分钟做对象图真题最后20分钟对着知识点清单自我检测。这个比例我实测下来比平均分配到每张UML图更高效因为类图和对象图本来就是连续知识点分开背容易造成断层。今天我自己安排的是先连续做了两套真题里的类图题再回教材查漏。做完发现一个规律教材喜欢把各种关系画得非常规范整齐真题却喜欢给一个小场景然后问A类对B类这样画箭头对吗。两者视角差别很大所以你们刷题时不要只盯教材示例一定要逼自己多做场景衍生题建立业务语义和符号之间的映射感。2. 把类图画对类本身的核心元素逐个拆开讲类图画得对不对一半在类自身的写法一半在关系符号。很多跨领域类图题出错并不是关系方向判断错了而是最基础的可见性符号写错、属性格式混乱说明基础元素没过关。这一节我们先解决代表类的方框内部的内容。2.1 类的三格画法与可见性符号标准类图符号是一个矩形框分成三个格子第一格写类名第二格写属性第三格写操作。类名大小写问题软考判卷一般不纠结真正要死磕的是属性、方法前的可见性符号。可见性一共四种常考写法表示 public公开可见任何其他类都能访问-表示 private私有只有本类自己能访问#表示 protected受保护本类和子类可以访问~表示 package包内可见考试频率低。考试选择题经常会在一张类图里混着出现这几种符号让你判断某个字段应该用哪种可见性。判断依据不是看起来合理而是封装性原则能私有就私有需要被子类重写或访问的才用 protected。这个原则在下午设计题里尤为重要因为标准答案通常按最小化访问权限来设计。注意类图中的不是数学加号-也不是减号。我见过考场上有人把方法签名里的-当成负号来理解其实那只是可见性标记。出题人偶尔也会故意用返回类型为负数这种离谱选项来制造干扰虽然看着好笑但真有人会错。2.2 属性和操作的书写规范一个冒号都不能错规范写法是这样的属性表达式可见性 属性名 : 类型操作表达式可见性 操作名(参数名 : 参数类型) : 返回类型举一个例子- studentId: int表示私有的整型学号 getScore(courseId: int): float表示传入课程号返回浮点型成绩。为什么说一个冒号都不能错因为软考选择题经常把 getScore(courseId: int): float改写成 getScore(int courseId) : float或者 getScore(courseId, int) : float这种错误格式考的就是你知不知道参数位置的写法和冒号分隔规则。很多同学做这类题时靠整体感觉猜其实完全有迹可循参数列表放在操作名后面的圆括号里多个参数用逗号分隔返回类型放在整个方法签名最右侧用冒号连接。把这条固定语法背下来就能秒掉一票迷惑项。属性与操作的区别还有一个实用判断技巧属性是这个类知道什么操作是这个类能做什么。考试给出一堆候选字段让你决定放进属性格还是操作格时就用这个标准去筛。比如订单总额是属性计算总额是操作这个区分在案例题里几乎是必考的送分点。2.3 抽象类、接口与模板类三种特殊形态要认得类图里除了普通类还经常出现三种特殊形态。软考案例题尤其喜欢用它们来考察面向对象设计的基本功。抽象类表示是在类名上方或旁边加abstract标记类名有时也用斜体。抽象类的特点是没有实例但可以同时拥有抽象方法和普通方法。考试陷阱常常出现在这里有人看到抽象类就以为所有方法都没有方法体这个理解是错的。抽象类可以有已经实现的具体方法只是不允许被直接实例化。接口用interface表示接口中的方法只有声明没有实现。接口与类之间是实现关系符号是带空心三角形的虚线箭头。往年真题出过抽象类和接口的区别这种概念送分题但案例题会把它升级让你判定某个类在实现接口时该画实线还是虚线。区分方法很简单类之间是继承关系就画实线空心三角类和接口之间是实现关系就画虚线空心三角。模板类在软考中出现频率较低一般出现在较高级的高级科目题里用bind或参数化类表示知道它是用类型参数表达一类通用结构就可以不必深挖。3. 六种关系一表速查软考命题的重心也是失分的重灾区类之间的关系是类图考点的绝对核心。为什么说是失分重灾区因为六种关系的符号相似度太高单纯背符号很容易混必须结合语义去记。这一节把关系从符号到语义一次讲透。3.1 六大关系符号与关键特征速查表下面这张关系速查表我每天睡前都会扫一遍基本能覆盖软考选择题九成以上的关系判断需求关系图形画法语义要点判定关键词泛化实线空心三角箭头指向父类is-a 关系子类继承父类是一种、子类化实现虚线空心三角箭头指向接口类实现接口的方法实现接口、实现了依赖虚线普通箭头指向被依赖方临时使用关系多作参数或局部变量用到了、临时依赖关联实线可带箭头或角色名长期稳定的结构关系一方持有另一方字段持有、字段成员聚合实线空心菱形菱形画在整体侧整体与部分部分可脱离整体存在包含、可分离组合实线实心菱形菱形画在整体侧整体与部分部分生命周期随整体密不可分、同生共死这个表里最容易被忽略的细节是聚合和组合不仅菱形实心空心不同菱形所在位置也必须画在整体那一侧。例如公司聚合员工空心菱形画在公司这一端箭头指向员工。出题人特别喜欢把菱形挪到部分那一侧再问你哪边画错了。你只看菱形实心空心不看位置照样会踩坑。3.2 逐一摸清概念依赖、关联、聚合、组合怎么区分先看依赖和关联。依赖是短暂的用一下关系典型场景是方法内部 new 了别的类对象或者把对象当作参数传进来关联是相对稳定的长期持有关系典型场景是类里有一个成员变量指向对方。判断标准就一句话看它是写在字段位置还是只出现在方法参数和局部变量里。聚合和组合这组容易混我习惯用是否同生共死来记。聚合关系下整体销毁时部分可以继续存活比如班级和学生班级解散了学生依然存在所以用空心菱形组合关系下整体的生命周期直接决定部分的生命周期比如人和心脏人没了心脏也就没有独立存在的意义所以用实心菱形。软考场景题常考订单与订单项这类业务关系。订单删除以后订单项没有存在意义应该判定为组合关系课程与选课学生则是聚合关系因为课程删除后学生还是学生这个业务语义一旦理解符号就不会记错。再补充一个判断技巧如果题目描述里出现了创建这个词大概率是组合关系因为部分由整体创建并随之销毁如果只提到拥有或包含则更可能是聚合。组件树结构、订单明细、人的器官这类场景基本都能套进这个规律。3.3 多重度与角色名类图上数字里藏着的得分点多重度用来表示一个类的对象能和对方多少个对象发生关联常见写法有1、0..1、*、1..*、0..*。很多考生案例题栽在多重度上关系类型判对了数字写错照样扣分。有一个通用推导套路先定主语再问一个主语对应多少个宾语。例如一个学生可以选多门课程、一门课程可以被多个学生选择那么学生到课程一端的数字写*课程到学生一端的数字也写*。注意数字写在对侧不是自己旁边。再比如一个订单只有一个订单项明细表头那订单到订单项一端写1订单项到订单一端写1..*。角色名也是软考偶尔会考的点。角色名写在关联线两端表达在这个关联中该类扮演什么角色。比如 Person 和 Company 之间有一条关联两端角色名可能是 employee 和 employer。选择题里如果出现角色名与类名混排的选项先看清标签靠近哪条线通常能立刻排除掉一部分错误项。判断原则很简单角色名是给关联双方的身份标签不是类名本身。4. 对象图类图的实例快照考场上最容易拿分也最容易丢分对象图在很多人眼里是类图的附属品实际出题量不大但一出就是好得分点。为什么容易拿分因为对象图只比类图多了一个实例化概念理解到位后几乎不需要额外背符号。为什么容易丢分因为考生习惯用类图的规则去套对象图忽略了对象图在命名、属性和关系语义上的特殊要求。4.1 对象图与类图三个一眼看穿的差异第一个差异是对象名的写法。类图里直接写Student对象图里写student: Student或者: Student而且整个名字要带下划线。凡是在UML图中看到带下划线的名称说明画的一定是对象图这个标志可以快速帮你在考场分辨图型。第二个差异是属性栏。类图的属性格式是name: String对象图的属性栏里必须填入具体的值格式是name 张三。也就是说类图描述的是有什么属性对象图描述的是此刻属性等于什么。这个等号的出现是对象图和类图最直观的区别之一。第三个差异是关系表达。类图画的是关联线对象图画的是链接线。链接线本质上也是实线但语义变成这两个对象之间此刻存在一条通路。对象图里的每条链接都必须在类图里有对应的关联关系否则就是凭空生成的连线。真题里常考一种判断给出一张看起来非常像类图的图问这张图能不能表示系统中的两个具体用户张三和李四答案是否定的因为类图标的是概念层只有对象才能表达具体实例。这类题其实在考你有没有注意到类名写的是User还是user1: User。一眼看穿图型就能直接得分。4.2 对象图考试的两种主流题型与答题顺序第一种是看图判断正误。给你一张对象图和一段需求描述让选哪个说法正确。这种题的核心解法是回到属性值去验证。比如图里订单对象的属性status paid就说明这个订单已经支付不要根据图里画了几个对象就推出系统一共有两个订单。对象图是某一瞬间的快照不代表系统全状态这个知识点必须背到位。第二种是补全对象图。给一张不完整的对象图要求补上对象名、属性值或链接线。这种题需要结合类图定义来判断对象名的下划线不能丢属性值要能对上类图属性列表链接线两端必须都是已经存在或能够合理解释的对象。常见的错误答案是把多个对象的属性值写成一模一样看起来像复制粘贴在判卷老师眼里等于没有建模思路。建议答题顺序是先标出所有对象名再核对属性值最后看链接线有没有漏画或乱画。按照名称—属性—关系三步走基本不会漏掉关键得分点。4.3 对象图经常跟设计模式结合出题别慌软考高级科目近年喜欢把对象图跟设计模式结合。比如观察者模式中同一时刻存在多个观察者对象它们的属性值各不相同用对象图可以直观呈现哪个观察者收到了通知、哪个没有收到。这种跨知识点题其实非常考验基本功你如果不知道对象图只是快照就容易在这个对象属性是不是最新状态这类问题上犯迷糊。我的经验是拿到这种题先圈出所有对象名和属性值再看题目问的是哪个对象状态已更新。画对象图快照的实际价值就是把某个时刻的系统状态冻结下来供人观察谁收到了消息、谁支付了订单、谁处于待处理状态都能从属性值里读出来。理解了这个本质对象图就不是一个孤立的图而是类图的现场直播截图。5. 真题解题流程从读图到填多重度手把手走一遍这一节不空谈理论我用一套典型的命题套路把读图动作拆开。注意以下不是真实考题原文而是把近年的考法规律整理成等价模拟场景核心考点完全对应真题风格你可以当作练习来做。5.1 第一步先看类图的整体骨架题目给了五个类Order订单、OrderItem订单项、Product商品、Customer客户、Payment支付。图中的连线包括Customer 与 Order 之间实线Order 与 OrderItem 之间实心菱形OrderItem 与 Product 之间虚线箭头Order 与 Payment 之间空心菱形。拿到图不要马上抠细节先做整体分类谁是全局核心哪条线是组合、哪条线是聚合、哪条线是依赖快速扫一眼就要有结论Order 是核心类Customer 通过关联和 Order 连接Order 组合 OrderItemOrderItem 依赖 ProductOrder 聚合 Payment。这样动手填任何空格时心里就有一张完整的关系地图。5.2 第二步逐条检查关系判断语义是否一致先看 Customer 和 Order。业务逻辑是一个客户可以有多份订单一份订单只属于一个客户所以 Customer 到 Order 一端写*Order 到 Customer 一端写1关系类型用关联更合理不需要画菱形。如果题图在 Customer 这一端画了一个空心菱形那就要立刻判定多重度或关系类型不匹配。再看 Order 和 OrderItem。订单删除之后订单项失去存在意义这是典型的组合关系实心菱形画在 Order 这一端多重度应该是1和1..*。第三条是 OrderItem 和 Product。订单项对商品通常只是用一下、长期持有商品信息的场景较少所以用虚线箭头方向指向 Product这是依赖关系。5.3 第三步判断对象图与类图的匹配关系如果题目再追加一张对象图order1: Order、item1: OrderItem、product1: Product并且order1的属性写着customerName 李四这时候要判断order1里有customerName字段是否合理。原始类图里如果 Order 类没有customerName属性那这张对象图就违背了类图定义。对象图是类图实例属性必须一一对应不允许凭空多字段。这个类图定义属性上限、对象图填充属性值的认知就是解题的核心。很多考生看到对象图里有信息就兴奋忘了先回去对类图白白丢分。类似的如果对象图里少了一个属性那也是错误因为实例不能比类图缺斤短两。提示下午案例题如果要求补全类图注意题干通常会提供候选字段列表。先排必然字段再排可选字段最后检查多重度两端数字。节奏一定是关系类型→方向→多重度→属性名按这个顺序检查一遍几乎不会漏分。5.4 第四步对答案时重点检查漏画了关系还是多画了关系我做完题对照标准答案有个习惯重点看标准答案里存在但自己没画的关系以及自己画了但标准答案没有的关系。前者说明漏了业务语义后者说明给两个类之间强加了不该有的耦合。很容易出现的例子是在顾客—订单场景里额外画一条 Product 到 Customer 的虚线理由看起来是顾客通过订单买了商品。但这个场景里 Customer 并不直接使用 Product顾客选择商品是通过 OrderItem 间接索引的。多画这条关系在下午设计题里会被扣耦合度分。这条经验是我自己复盘时踩过的坑拿出来提醒各位比盲目背图有用得多。6. 冲刺记忆法一页纸速记清单与碎片时间自测技巧到了第6天你需要的不只是会读图最好能合上教材自己在白纸上画出标准类图的完整骨架然后闭眼背出符号关系。下面这套记忆法来自我的实际冲刺适合每天挤地铁、等电梯的碎片时间反复过。6.1 五句话背完类图关系符号我用五句话把六种关系全部串起来背熟以后正确率能稳定在八成以上。第一句实线是强关系虚线是弱关系第二句空心三角箭头表示继承和实现方向实线三角是继承、虚线三角是实现第三句菱形一定画在整体那一侧空心聚合、实心组合第四句普通箭头指向被依赖方第五句多重度写在对方那一端先定主语再数数量。这五句话之外还可以加一套生活化比喻帮助记忆继承等于父债子还实现等于签了合同照章办事依赖等于临时借个火关联等于长期合伙人聚合等于房东和房客组合等于脑袋和身体。我第一次用这套比喻帮朋友复习关系辨析他说比死记硬背牢靠得多。6.2 对象图的三个必须下划线、属性值、类图对应对象图有且只有三个硬性要求每次做题前默念一遍。第一对象名必须带下划线第二属性必须给具体值第三所有字段都必须能在类图里找到对应定义。只要看见对象图题先拿这三点去筛选项大部分干扰项会立刻现形。举一个实战例子题干说employee 和 Employee 是同一个概念吗看起来像文字游戏实际考的就是对象名规范。employee: Employee是对象图Employee是类图。两者不在同一层抽象上不能混为一谈。题目如果问下图中出现的student是类还是对象答案一定是对象因为名字里带了冒号并且有下划线。6.3 用 StarUML 和 IDEA 辅助理解但别被工具带偏很多考生纠结要不要专门学一个UML工具。我的建议是如果目标是软考不必须精通工具但可以用工具来验证理解。StarUML 免费且轻量画类图时选择不同类型的连线它会自动展示对应符号能帮你建立符号—形状的肌肉记忆。IDEA 用户也可以装 PlantUML 插件用几行代码生成类图适合快速验证自己手绘的图对不对。但有一点要提醒工具生成的类图不一定完全符合软考答题规范。比如工具里生成的依赖箭头风格、多重度默认值都可能和官方教材有差异。备考一定要以真题和教材版式为准工具只用来辅助理解不能当作标准答案来源。7. 第6天结束前把这张自查表再扫一遍今天的内容到这里基本讲完了但第6天还没有真正结束。我的习惯是当天晚上把今天所有知识点压缩成一张自查表第二天早上一睁眼先自问几个关键问题。类图的三个格子分别写什么可见性符号有哪些聚合和组合的菱形怎么区分多重度怎么写、画在哪一端对象图的名字格式是什么对象图的属性值格式是什么对象图和类图能不能有不一样的属性如果有一半答不上来说明今天的内容还没有变成长期记忆建议不要带着疑问往下走。从 DAY01 到现在你每天积累的知识点应该已经能拼出一张不小的知识网了。第7天我们要开始啃用例图和时序图这两张图和类图联动性很强基础打牢了后面的路会顺很多。我个人在备考时最深的体会是UML这种图形化考点特别适合睡前回忆闭上眼把类图在脑子里画一遍比反复翻书巩固得多。今晚不妨就试着关灯后在脑子里默画一张包含五六个类和两三种关系的类图画不下去的地方就是明天需要回炉的地方。