下午卷里UML 这道题属于那种你以为稳了、分数出来却打脸的存在。我身边不少一起备考的朋友上午题的基础知识做得七七八八一到下午的 UML 填空就开始犯迷糊类名填错、箭头方向画反、多重度写成1..n最后满分十五分只拿到个位数。其实这道题的知识范围非常窄翻来覆去就是用例图、类图、状态图、顺序图那几张图考点也高度重复。真正的问题往往不在于你不懂 UML而在于没搞明白出题人到底想让你在空格里填什么、用什么措辞写。这篇就把软考下午题里 UML 这道题的出题习惯、破题链路、答题书写和画图实操按我自己复习和应考的经验完整捋一遍。适合零基础刚接触 UML 的同学也适合考过一次、偏偏卡在这道题上的老考生。我会尽量把为什么这么判断讲透而不是只给结论——因为考场上你一定会遇到没见过的题干只有掌握了判断逻辑才能现场推出来。1. 下午卷里UML这道题的脾气先搞清它到底要你填什么1.1 UML题在下午卷中的固定座位与分量软考中级软件设计师的下午卷多年来都是5道大题、共75分、考试时长150分钟。以近几年常见的题型分布来看试题一考数据流图结构化分析方向试题二考数据库设计E-R图与关系模式转换试题三基本锁定在面向对象建模也就是 UML试题四考算法C 语言代码填空或算法设计试题五是 Java 或 C 的面向对象程序设计二选一。也就是说UML 这道题通常处在试卷的腰眼位置一旦在这里卡壳后面的算法题时间就被挤压连锁反应很明显。从分值看UML 题一般是15分。这15分里往往不是一道纯设计题而是半图半文给你一幅残缺的 UML 图再配一段业务场景描述让你在图上补名称、在答题纸上补关系类型或者文字说明。填空位置通常分布在三个地方——类的名称、关系线两端的角色名或类名、以及一对多的多重度标注。所以你会看到很多真题的答案就是几个词字数少得可怜但每个词都卡在对业务的准确理解上。我个人的体会是这道题的难度曲线很平但得分率波动很大。原因很简单它很少考纯记忆更多是考你把一段中文需求翻译成模型元素的能力。业务场景一换死记硬背的模板就不好使了。所以别指望把 UML 语法表背下来就能拿满得练读需求—圈名词—判关系这条链路。1.2 三张高频图的出题习惯差异把近十年的真题拉出来看UML 题最常出现的是用例图和类图其次是状态图顺序图和活动图相对少一些但也不是没考过。它们各自的出题人格差别挺大复习时的侧重点完全不同。图形类型常见考查形式典型空格内容难度体感用例图给业务描述补全图Actor 名称、用例名称、include/extend 关系偏易易错在关系方向类图给类图框架补属性/方法/关系类名、多重度、关系类型、方法名中等考对业务抽象状态图给状态迁移框架状态名、事件名、迁移条件中等考事件顺序顺序图给交互场景对象名、消息名、消息类型中等偏难考时序用例图那道题很多时候是给你一段某图书馆借还书系统之类的描述让你从文字里找出系统外部跟系统打交道的人或外部系统也就是 Actor再判断某些行为是用例还是内部步骤。它的坑在于边界——什么算系统内、什么算系统外新手特别容易把系统内部的模块当成 Actor。类图的坑则在关系。同一段描述里一个订单包含多个订单项到底是聚合还是组合一枚戒指镶嵌若干宝石是关联还是组合这些判断题没有绝对公式得靠对业务生命周期和所有权关系的理解。多重度也是重灾区很多同学上来就写1..n其实 UML 规范里常用的是1..*写成 1..n 有时候会被判不规范。状态图的坑是事件。题目会给你一段设备或订单状态流转的文字你要判断哪一步是状态、哪一步是触发迁移的事件。比如订单支付成功后由待支付变为已支付这里待支付已支付是状态支付成功是事件。新手容易把状态和事件写反。1.3 为什么看着简单、写起来丢分UML 题最大的迷惑性就在于图长得很直观看一遍好像都懂。但真到落笔才发现自己对很多细节只有模糊印象。我总结下来丢分主要集中在这几类关系判定靠猜聚合、组合、关联三个概念混在一起凭感觉连一条线。箭头方向记反泛化的三角箭头指向父类、实现的三角箭头指向接口、include 箭头从基用例指向被包含用例这些方向一旦记混直接判错。多重度只写一个端点只标了一端的1..*另一端空着。术语用中文大白话题目要求填 UML 术语你写了包含关系却没按图上的规范标注或者把拓展写成扩展虽然意思对但不符合标准答案的措辞。忽视题干里的限定词题干说必须一定往往暗示 include说可选在特定条件下往往暗示 extend。这些信号词没抓住判断就会跑偏。提示UML 题的答案往往高度依赖题干措辞。做题时养成一个习惯——先把题干里的必须/可选一对多/多对多继承/实现这类信号词圈出来再回头连图。这一步花不了两分钟能省下大量反复思考的时间。2. 类图填空的完整破题链路从名词扫描到关系落笔2.1 第一遍只圈名词别急着连线拿到类图题我强烈建议第一次读题时什么都别写只做一件事把题干里所有像实体的名词圈出来。这一步对应的是找类。题干里出现的名词大致分三类一类是系统要管理的对象比如订单客户商品这些大概率是类一类是对象的属性比如订单编号客户姓名这些不该建成类还有一类是描述关系动作的词比如提交审核这些可能是方法或者用例。区分实体类和属性的一个实用判断法是它有没有自己的属性、有没有需要单独维护的数据、有没有独立的行为。比如收货地址如果系统里只是把它当作客户的一个字段存着那它就是属性但如果系统要求对地址做单独的增删改查、要维护多个地址那它就值得独立成类。这个原则在真题里反复出现是拉开区分度的关键。圈完名词之后通常还会要求你补方法名。方法名的回答技巧是看题干里的动词加宾语比如系统需要根据订单号查询订单详情那对应的类方法很可能就是查询订单详情或者按题目给的命名风格写成英文。注意有些真题明确要求用英文命名这时候得留意题目有没有给命名规范比如首字母大写的驼峰式或者全英文小写。命名风格不统一也可能被扣分。2.2 关联、聚合、组合的判定标准这三种关系是类图题的核心考点也是新手最容易含糊的地方。我习惯用一个层层递进的判断法先看两个类之间有没有长期的结构性连接如果没有那可能只是依赖如果有再判断它是不是整体—部分关系如果是整体—部分最后判断部分能不能脱离整体独立存在。关联Association两个类之间一般的结构关系比如老师和课程、客户和订单。用实线表示可以有方向导航性也可以没有方向。聚合Aggregation整体—部分关系但部分可以独立于整体存在。用空心菱形表示菱形画在整体那一端。典型例子是班级和学生——班级解散了学生还在还能加入别的班级。组合Composition更强的整体—部分关系部分的生命周期依附于整体整体没了部分也就不该单独存在。用实心菱形表示菱形同样在整体那一端。典型例子是订单和订单项——订单被删除它下面的订单项通常也一起删掉单独留一个订单项没有意义。这个生命周期是否绑定的判断口径我觉得比背口诀靠谱得多。考试时你只要问自己一句整体消失之后这个部分还能独立存在、还有意义吗能就是聚合不能就是组合。这句话我练习时反复用几乎没判错过。2.3 多重度标注四个常用取值与判断口诀多重度是另一个高频填空点。它标在关系线两端表示这一端能连多少个另一端的对象。常用的取值其实就那么几个真正需要理解的是每个取值的业务含义。标注写法含义业务例子1恰好一个一个身份证对应一个人0..1零个或一个一个员工最多有一个直属主管0..* 或 *零个或多个一个客户可以有零到多个订单1..*一个或多个一份订单至少有一个订单项判断的时候一个 X 对应几个 Y这句话先在心里念出来。题干里如果有多个若干通常就是 0..* 或 1..*如果强调至少一个那就是 1..*如果出现可选可以为空那就是 0 打头。我见过不少同学一律写1..n其实 UML 里用星号 * 表示多写成 n 是不标准的虽然有些阅卷会宽容但能写规范就写规范。注意多重度是标在关系两端的两个端点都要考虑别只标一端就交卷。很多真题的整体里会有一个空专门等你填另一端的多重度漏填直接丢分。2.4 泛化与实现箭头方向和线型的死记点泛化和实现是纯记忆题但记混的人特别多。我给你一个不会记错的框架三角箭头永远指向父或接口剩下的区别只在线是实线还是虚线。泛化Generalization类与类之间的继承关系用实线 空心三角箭头箭头指向父类。可以读成子类是一种父类。实现Realization类与接口之间的关系用虚线 空心三角箭头箭头指向接口。可以读成这个类实现了这个接口的约定。记忆小技巧接口是个抽象契约所以要虚虚线父类是个实体模板所以要实实线。两者箭头方向都朝上、朝父、朝接口方向感就统一了。我在草稿纸上会先画好一个方向箭头再套到题目里避免临场手忙脚乱。3. 用例图题的取舍逻辑Actor边界与include/extend判定3.1 Actor该划几个系统内外的边界判断用例图的第一类填空就是 Actor也就是参与者。判断标准只有一条硬线Actor 一定在系统边界之外是主动或被动与系统交互的人、外部系统或外部设备。系统内部的模块、类、定时任务本身都不是 Actor。题干里出现的人或角色比较好认比如管理员会员游客。难一点的是外部系统和外部设备比如支付网关短信平台扫码枪传感器——这些如果被描述成系统需要调用它来完成某功能那就是 Actor如果只是系统内部的一个组件就不是。还有个小坑是时间或定时器。有些系统描述里会出现每天凌晨系统自动结算这里的定时触发在 UML 里有时会被建模成一个 Actor常叫定时器Time。但这类要谨慎得看题目语境。如果题干明确把它当作一个外部触发源来画那就填如果只是描述内部逻辑就别画。判断依据依然是它在不在系统边界之外。我的一般做法是只要题目把它作为一个独立触发源明确写出来并且图上留了 Actor 的空位就按 Actor 处理。3.2 include与extend的箭头方向和触发条件这是用例图里最容易翻车的地方。先记方向再记语义。包含include虚线 开口箭头标注«include»箭头从基用例指向被包含用例。含义是基用例执行时一定会执行被包含用例是被包含用例被无条件复用。扩展extend虚线 开口箭头标注«extend»箭头从扩展用例指向基用例。含义是在满足特定条件时扩展用例才插入到基用例中是被扩展用例有条件地增强基用例。看方向你会发现二者恰好相反include 是基用例 → 被包含用例extend 是扩展用例 → 基用例。为什么因为 include 是我把你包含进来主语是基用例所以箭头从基用例出去extend 是我来扩展你主语是扩展用例所以箭头从扩展用例指向基用例。想清楚谁是主动方方向就不会错。判断用 include 还是 extend密钥在题干措辞。出现必须每次都要一定执行这类词选 include出现可选可以在某某情况下特殊情况下才这类词选 extend。举个典型例子用户登录时系统必须进行身份校验——登录是基用例身份校验被无条件执行用 include。用户下单时如果余额充足可以选择使用优惠券——使用优惠券是有条件的用 extend。3.3 用例描述表事件流的填写要点有些真题除了让你补图还会给一张用例描述表让你填表格里一般分基本事件流和备选事件流。这里的填空诀窍是基本流写一切顺利时的正常步骤顺序备选流写出现异常或分支时怎么处理。两者都要按时间顺序、用主动句式来描述比如用户输入账号密码系统校验通过系统返回订单列表。措辞上我建议直接沿用题干里的动词别自己发明新说法。阅卷是按关键词给分的你用题干原词的命中率最高。另外事件流里每条尽量写清楚谁做了什么、系统如何响应这样即使个别措辞不同逻辑对了也能拿到基本分。4. 动态建模的三张图顺序图、状态图、活动图各自考什么4.1 顺序图填空对象、生命线与消息顺序图也叫序列图用来描述对象之间按时间顺序的交互。它的基本元素包括对象Object、生命线Lifeline、激活Activation和消息Message。顺序图的填空一般落在三个位置缺失的对象名、缺失的消息名、以及消息的类型。消息类型是容易被忽略的得分点。同步消息用实线 实心箭头表示调用方要等对方返回异步消息用实线 开口箭头表示调用方发出去就继续往下走、不等返回返回消息用虚线 开口箭头表示方法调用结果的回传。判断题干时会看到调用请求返回结果这类词基本就能对上。顺序图的时间轴是从上到下的越靠下的消息发生得越晚所以填消息时一定要结合上下位置别把返回消息填到调用之前。提示顺序图里对象的命名有个约定——对象名:类名的形式比如order:Order。如果题目给的是冒号前的部分让你补你补对象名冒号后的部分让你补你补类名。这个格式细节很容易被忽略但恰恰是填空题的常客。4.2 状态图填空状态、事件与迁移条件的层次状态图描述一个对象在其生命周期内随事件触发而在不同状态之间迁移的过程。它的核心是状态和迁移两部分。迁移线上一般可以标三段信息触发事件、守卫条件方括号里的条件、迁移动作中间用斜杠分隔。比如支付成功[余额充足]/生成订单这里支付成功是事件余额充足是条件生成订单是动作。状态图题的做法是先找稳定状态再找触发事件。一段业务描述里像待审核已审核已发布已关闭这种名词通常就是状态像提交审核通过发布关闭这种动词短语通常是事件。判断时留意一点状态是停在那里等的事件是让状态动起来的。这个区分一建立状态图的填空基本就顺了。初始状态用一个实心圆表示终止状态用一个带圈的实心圆牛眼形表示这两个基本是画图题里默认要补的。别看它们简单位置放错——比如把终态放到一个还能继续迁移的状态后面——也是会扣分的。4.3 活动图与状态图的最小区分点活动图和状态图长得有点像很多同学分不清。给你一个最简区分状态图盯着一个对象的若干状态活动图盯着一个流程的若干步骤。状态图里节点叫状态活动图里节点叫动作/活动。活动图里有判定节点菱形、分叉与汇合粗横线表示并发和泳道按角色分区的纵向通道这些是状态图没有的。如果题目要求你画泳道图那基本就是活动图因为泳道是用来区分谁负责哪一步的。分叉与汇合则用来表达并行执行比如下单成功后系统同时发送短信通知并扣减库存这两条线可以并行画在分叉线下。判断并发还是顺序就看题干是同时还是然后。包图Package Diagram虽然不如前几张图高频但也可能出现在选择题或简答里。它用于对模型元素分组包与包之间最常用的是依赖关系用虚线加开口箭头表示箭头从依赖的包指向被依赖的包。记住方向也是关键谁用谁箭头指向被用的那个。5. 我用Visio画UML的真实现场从草稿到能交的图5.1 模板与形状库的选择虽然软考下午的 UML 题多半是在纸上画或直接在图上填但很多人会用 Visio 做练习和整理笔记所以这里也说清楚怎么用 Visio 快速画一张规范的类图。新建文档时别用通用模板直接在类别里找软件和数据库里面有两个非常实用的模板UML 类图和UML 序列图顺序图。选对模板左侧形状库里就会自动带上类、接口、包、关系线这些现成形状省去手动画框的麻烦。类图模板里的形状有类接口包以及关联聚合组合泛化实现依赖几种关系线。拖一个类形状到画布双击就能填类名、属性、方法三个分区比手动画矩形写字规整得多。我一般在做笔记时会把典型真题的类图都按这个方式重新画一遍标注上多重度和关系类型复习翻看时一眼就能回忆起来。注意Visio 里不同版本的中文译名不太一样有的把聚合叫共享聚集把组合叫复合聚集。画之前先在形状库里点几下确认一下别把两种菱形用反了——空心菱形是聚合实心菱形是组合这个和前面讲的判断标准要对应上。5.2 连线、箭头与多重度的实操细节Visio 画 UML 最容易出问题的环节是关系线的两个端点。以聚合和组合为例菱形必须画在整体那一端而很多新手顺手就把它画在了部分那一端。解决方法是用形状库里的专用关系线自带的端点形状而不是用普通的连接线去拼。专用线的端点形状是固定的你只需把有菱形的一端拖到整体类上就行不会画错。多重度标注在 Visio 里是手动加的。做法是选中关系线用文本框在线的两端分别写1、1..*这样的取值然后拖到贴近线端的位置。位置要贴住线但不压住箭头否则打印或截图时容易糊成一团。我习惯把所有多重度统一用一个字号、一个颜色看起来干净复盘时也方便对照。泛化和实现的三角箭头在 Visio 里同样是专用线自带的别自己画三角形去拼。实线三角是泛化虚线三角是实现只要选对了形状线型和箭头方向都会自动正确。这里再次强调方向端点要拖到父类或接口上别拖反。5.3 画完后的自检清单我画完任何一张 UML 图都会用一张固定清单过一遍这个习惯帮我在练习阶段揪出过无数方向性错误检查项检查内容常见错误关系类型聚合/组合的菱形在不在整体端菱形画在部分端箭头方向泛化指向父类、实现指向接口箭头指向子类/实现类多重度关系两端是否都标注只标一端命名规范类名首字母大写、属性小写大小写混用图例完整是否漏画初始/终止状态状态图缺终态这张表看着简单但用熟了以后你甚至能在读题时下意识地预判出题人会在哪个位置设空。因为真题里那些坑基本都踩在关系端点、箭头方向和多重度这几处。6. 考场上的时间分配与答题书写6.1 15分钟做完UML题的节奏下午卷总共150分钟要做5道大题平均每题30分钟但题目难度不均。我的建议是给 UML 题留15到20分钟超过20分钟就果断往前推回头再补。具体节奏可以这么切读题和圈名词3到5分钟判断关系和多重度5到8分钟书写和检查3到5分钟。这套节奏的前提是你在平时练习时已经把常见关系判断练到接近条件反射否则读题时间会无限拉长。我练习时的一个笨办法是限时做真题把题目打印出来掐表15分钟做一道做完对照答案把判错的地方记到一个专门的错题本上。这个错题本不用写得多工整就记哪张图、哪个空、我当时怎么判的、正确答案为什么对。坚持两三周你会发现自己对题干信号词越来越敏感必须一出现条件反射就是 include可选一出现就是 extend。6.2 文字填空的措辞规范UML 题里有很多空是文字填空这时候措辞的规范程度直接影响得分。有几条经验值得记住第一优先使用题干里的原词别自己改写第二填关系类型时用规范术语比如聚合关系组合关系泛化关系而不是包含继承这种口语化说法除非题目明确要求第三涉及英文命名的空严格按题目给的风格来是驼峰还是下划线照抄风格就行。另外注意答题纸和试卷的分工。有些题要求在试卷的图上直接标注有些要求把答案写在答题纸上并标明题号。这两种操作别搞混画错了位置可能白做。上考场前把答题卡的填涂规则看清楚尤其是填空题怎么编号对应这属于不丢冤枉分的范畴。6.3 遇到陌生场景时的保底策略真题里偶尔会出现你没见过的业务领域比如某种工业设备的状态流程、某种金融产品的交易流程。这时候别慌因为 UML 考的是建模能力不是业务知识。你要做的还是那套从描述里抽名词定状态或类从动词里找事件或方法从题干信号词判关系类型。把不认识的业务当成黑盒只看它和别的东西怎么交互、怎么流转。如果某个空实在拿不准我给的建议是写出你最可能正确的那一版并在旁边留出空间别纠结太久因为后面还有算法题和程序设计题在等你。UML 题的15分里靠基础填空通常能稳拿10分左右剩下那几分属于区分度题性价比不如把时间投到算法题上。最后再分享一个我自己反复验证的小技巧复习 UML 时别只看图一定要动笔把每一道真题的答案完整写一遍包括关系方向和多重度。看懂和写对是两码事只有动手写你才会发现那些平时没注意的细节——而这恰恰是下午题里拉开分数的地方。