简介2025年下半年软件设计师下午真题及参考答案面向软考中级软件设计师考生适合备考冲刺与案例题专项训练。内容涵盖四道典型试题订单处理系统的数据流图分析包括顶层图与0层图实体、数据存储及缺失数据流补全小区物业收费管理系统的数据库设计涉及关系模式完善、主外键确定及范式判断网上药店的UML建模要求补充类图、多重度和处方状态图还有堆数据结构的大顶堆调整C代码题。每道题均配有参考答案与解析可帮助考生梳理解题步骤掌握数据流图、ER图、关系模式规范化、UML状态图等高频考点的答题方法。资源包共1个doc文件约1.42MB方便直接打开或打印练习。已有955人学习使用可作为考前实战演练和查漏补缺的重要参考。1. 软件设计师下午真题背答案没用得学会按采分点答题软考软件设计师的下午题看着像是考案例实际上考的是一套固定的分析套路。2025年下半年这套真题一共六道大题覆盖数据流图、数据库设计、UML建模、优先队列的C代码填空和组合模式的C/Java实现。首次接触这套卷的人容易觉得“题目文字很长、图形很乱”尤其是数据流图里少一条数据流、关系模式里缺几个属性这种题不掌握分析方法靠死记硬背肯定翻车。这份真题资源的价值不在于把答案背下来去碰原题而在于拿它训练采分点意识每个空该填什么词、从哪里找依据、为什么不能换成自己的说法。适合正在备考软考、想做下午题专项突破的从业者也适合把它当作模拟练习按考试时间掐表做一遍。2. 数据流图题从实体判断到缺失流定位的三个关键动作订单处理系统的数据流图题是整套下午题里最考验“词汇复用能力”的一道。题干给出了八项功能顶层数据流图和0层数据流图各有缺失要求填实体、数据存储、加工名称还要找出一条缺失的数据流。表面看是在考图实际上考的是“能不能从需求描述里原样找出图中每个符号的依据”。2.1 先从功能清单里区分外部实体和数据存储外部实体的判断标准是看它是否和系统之间有交互但又不属于系统内部的数据文件。对照题干功能描述客户通过电话、传真、邮件或Web站点下订单这属于系统外部发起者功能(4)把配货单发送给仓库仓库备好货之后返回备货就绪告知这属于外部协作方功能(8)产生应收账户报表发送给财务部门这也属于外部接收方。常见做法是先列一张交互表把功能编号、交互对象、方向都标出来。功能编号功能描述交互对象方向(1)(2)(3)客户下单、查询商品客户入(4)发送配货单、接收备货告知仓库出/入(7)发送客户账单客户出(8)发送应收账户报表财务部门出这样看下来顶层图里的 E1~E3 就对应客户、仓库、财务部门。需要注意题干里还提到“若现货不足则需向供应商订货”这容易让人误把供应商也当成顶层实体。但这道题只要求填三个实体说明供应商要么被归入仓库的备货流程要么在0层图中并没有单独建模。答题时严格按题干词汇填写不要自创“订货方”这类说法。数据存储的判断相对直接。题干反复出现“从商品文件中查询商品的价格和可订购数量”“将新客户信息添加到客户文件”“产生订单并添加到订单文件”D1~D3 基本就是商品文件、客户文件、订单文件。判断依据主要是“文件”二字凡是系统内部需要持久化保存的数据集合都是数据存储不是外部实体。2.2 加工P1和P2的输入输出流怎么推导0层图中的加工是由顶层图的处理过程细化出来的。题干功能(2)是查询商品信息客户提交商品信息请求系统从商品文件查询后返回功能(3)是增加订单记录根据客户的订购请求和已有客户记录产生订单写入订单文件。这两个功能在0层图中往往就是P1和P2。实际答题时我会先在草稿纸上把每个加工连接的数据流列成一张表。P1的名称为“查询商品信息”输入流是“商品信息请求客户”输出流是“商品信息客户”。P2的名称为“增加订单记录”输入流是“订购请求客户”和“客户记录客户文件”输出流是“订单记录订单文件”。这里有一个容易忽略的点P2的输入输出涉及数据存储输入流用“客户记录”比“客户信息”更贴近题干。而且数据流的起点和终点必须写图中的符号或题干词汇比如“D2”可以写“客户文件”“P2”可以写“增加订单记录”但不能写“根据客户的情况算一下订单”——阅卷时是按关键词给分的。2.3 缺失数据流盯住“写操作”和“加工平衡”找缺失数据流有两个方向。第一个方向是检查每个加工是否有输入和输出如果一个加工只有输出没有输入或者只有输入没有输出基本可以断定问题出在附近。第二个方向是重点盯题干里带“更新”“修改”“删除”字样的功能描述这些描述一定会对应一条数据流图中如果没画出来就是缺失。这道题的关键线索是功能(7)创建客户账单时“同步更新商品文件中的商品数量和订单文件中的订单状态”。订单文件的状态更新可以由创建客户账单这个加工直接发数据流到D3但商品文件的数量更新是一条从加工到数据存储的写数据流。0层图里如果只有从商品文件读取数据的流没有写回商品文件的流那缺失的就是这条。定位方法很简单找到创建客户账单对应的加工看它是否有一条指向商品文件的输出流。如果没有这条缺失流的起点就是“创建客户账单”加工终点是“商品文件D1”。答题时起点和终点都要用图中的词汇不能写“扣库存流程”这种自己发明的词。还有一个小技巧检查数据流时把所有数据流都标上方向箭头然后从起点沿着箭头走一遍看每个加工的数据能不能闭环。走不通的那一段基本就是缺失流的位置。3. 数据库设计题物业收费系统里的ER补全与关系模式推导小区物业收费管理系统这道题是典型的“需求分析概念模型关系模式”综合题。题干给了大量实体属性也给了收费计算原则但关系模式缺了五处ER图缺了若干联系和类型还要判断范式。做这类题的核心是先画ER草图再对照关系模式逐项填空不要直接在模式上凭空补。3.1 从需求句里识别实体、属性和联系基数先把题干中的名词都圈出来业主、房号、房屋面积、部门、员工、收费信息、收费类型、收费原则。其中业主、部门、员工、房屋、收费信息是实体房屋面积、收费金额、数量这些是属性业主和房屋之间的关系是“一个业主可以有一套或多套房屋”这是1:n联系。注意题干里那句“房号可唯一标识一条业主信息且一个房号仅对应一套房屋”。答题时可以不去纠结这里为什么用“房号”标识关键是认清一个事实业主和房屋之间是1:n那么业主和房屋的关联需要用两个属性共同标识。所以业主关系模式的第一空需要同时填入“业主编号,房号”或者按题目模式写法把“业主编号”和“房号”都放进括号里。画ER图时我习惯先在草稿纸上画三个核心实体业主、部门、员工。员工属于一个部门一个部门只有一个负责人所以部门和员工之间是1:n联系收费信息关联到业主的某套房屋同时也关联到执行收费的员工。收费类型作为弱实体或者收费信息的判别属性在ER图中要根据题目给出的图2-1的已有结构来补不要自己重新设计一张表。3.2 关系模式填空主键和外键的确定顺序关系模式填空和ER图是联动关系。每填一个空都要想清楚这个属性放在哪个关系里、它承担什么角色。下面按一般答题顺序展开。-- 业主关系 CREATE TABLE 业主 ( 业主编号 VARCHAR(20), 房号 VARCHAR(20), 姓名 VARCHAR(50), 房屋面积 DECIMAL(10,2), 工作单位 VARCHAR(100), 联系电话 VARCHAR(20), PRIMARY KEY (业主编号, 房号) );这段SQL表达的是补全后的业主关系。主键采用(业主编号, 房号)是因为一个业主可以拥有多套房屋只有这两个属性组合起来才能唯一定位一条具体的房屋持有记录。如果只把业主编号作为主键同一业主的多套房数据会互相冲突如果只把房号作为主键就无法表达业主和房屋的一对多关系。员工和部门的关系模式也遵循同样的逻辑。员工关系里“所在部门号”是外键指向部门关系的主键“部门号”而部门关系的主键就是部门号本身。权限关系比较简单主键是“职务”因为题干明确说不同职务有不同的操作权限。收费信息关系的主键要小心最好使用(房号, 收费类型, 收费日期)因为同一套房在同一个月份、同一种收费类型下只会有一条记录。收费原则关系里缺的是“收费类型”和对应的“计费单价”主键是收费类型。物业费、卫生费、水费、电费这四类计费方式不同但都属于“按单价计算”所以只要用收费类型就能唯一定位一条计费规则。3.3 范式判断业主关系为什么在1NF题目要求判断业主关系属于第几范式并说明存在的问题。标准判断路径是先看主键再看是否存在部分函数依赖。业主关系的主键是(业主编号, 房号)那么“房屋面积”实际上依赖于“房号”不依赖于“业主编号”“姓名”依赖于“业主编号”不依赖于“房号”。也就是说非主属性对候选键存在部分函数依赖按照范式的定义这只满足第一范式不满足第二范式。答题时不能只写“它是1NF”还要说明存在的问题。最直接的问题是数据冗余同一个业主名下如果有三套房他的姓名、联系电话、工作单位就要在三条记录里重复出现同时会引发更新异常比如业主换了电话号码需要同步修改多条记录如果漏改一条数据就不一致了。删除房屋记录时还可能把业主的唯一联系方式也删掉这就是删除异常。遇到这类题目写范式的标准句式是先给结论再写一条具体的函数依赖关系最后补一个实际场景说明后果。阅卷时往往看“部分函数依赖”这个关键短语给分所以这个词一定要落在答题纸上。4. UML建模题类图、多重度、状态图一起抓网上药店这道题题干描述很长注册、登录、录入处方、提交处方、验证处方的流程串成一条完整业务链。题目给了类图的框架让填C1~C5类名和多重度还给了处方状态图让填状态名和迁移名。做这类题不能一上来就猜类名要把文字描述当成业务流程图来过一遍。4.1 类名补全从句子主语里找线索类图中的类基本都是需求描述里反复出现的主体名词。题干里出现过顾客、医生、处方、药物、订单、付款方式这几个角色类图C1~C5就应从这些词里选。常规答案是C1对应顾客C2对应医生C3对应处方C4对应药物C5对应付款方式或支付账户。如果题目给的类图片段里有“处方”已经单独画出那么C1~C5的分配会相应调整但核心逻辑不变顾客要注册并登录顾客下处方处方关联医生处方包含药物顾客使用付款方式进行结算。拿到这类题先把题干中的每个“谁做了什么事”标出来。比如“顾客必须与药店签订授权协议书”说明顾客类和授权协议有关“顾客按照处方录入界面填写医生的信息和处方上的药物信息”说明处方类要关联医生类和药物类。类和类之间的关系是靠行为动词串起来的不是靠名词堆出来的。4.2 多重度判断从业务规则反向推导多重度是UML题的高频失分点。判断依据是规则句里的数量词而不是主观想象。关系题干依据多重度顾客和处方已经注册的顾客可以登录购买药物一个顾客可以多次买药1 : 1..*医生和处方顾客录入医生信息多个处方可能对应同一医生1 : 1..*处方和药物处方上可以填写多种药物一种药物也可能出现在多个处方中* : *先看“顾客—处方”一个顾客可以下多个处方一个处方只属于一个顾客所以顾客端是1处方端是1..。再看“医生—处方”一个医生可以被多个处方关联每个处方只能写一个医生所以医生端是1处方端是1..。最后是“处方—药物”一个处方包含多种药物一个药物也会出现在多个处方里所以两端都是*。多重度的写法要注意符号1..*表示一个到多个不要写成一个星号就完事。题干里明确说“处方上的药物信息”没有限制单种药物所以必须用多对多表达。4.3 状态图填充把流程约束转成迁移处方状态图考的是流程理解。题干把状态切换写得很清楚提交处方后状态是“处方已提交”然后验证医生信息。医生信息不正确状态变成“医生信息无效”处方取消医生信息正确系统向医生发送确认请求状态变成“审核中”。接下来有三个分支医生答复无效状态置为“无效处方”医生7天内没答复状态置为“无法审核”医生7天内给出确认答复状态置为“准许付款”。所以S1~S4对应的就是“医生信息无效、无效处方、无法审核、准许付款”这几个状态。迁移名要从题干动词里找。状态从“处方已提交”到“审核中”迁移名可以是“验证医生信息通过”从“审核中”到“准许付款”迁移名是“医生确认处方有效”从“审核中”到“无效处方”迁移名是“医生答复无效”从“审核中”到“无法审核”迁移名是“超过7天未答复”。这里有一个常见误区把“7天内给出答复”单纯理解成一个时间事件而忽略它的前置条件是医生信息首先要验证通过。状态图里的迁移必须标注触发事件像“超过7天未答复”这样的约束是迁移名的一部分不能省掉。5. 堆与组合模式代码填空高频失分点排查代码填空题在这套下午题里占两道大题的分量一道是优先队列的大顶堆操作一道是组合设计模式的C和Java实现。代码填空主要不是考语法而是考数据结构的数组下标规律和面向对象的抽象层次。5.1 优先队列三个函数数组下标和边界条件才是核心堆在优先队列里用数组存储父节点和子节点的下标关系是固定的。PARENT(i) i / 2这个宏是整套题的钥匙。int heapMaximum(ARRAY *A) { return A-int_array[0]; } int heapExtractMax(ARRAY *A) { int max A-int_array[0]; A-int_array[0] A-int_array[A-array_size - 1]; A-array_size--; heapify(A, A-array_size, 0); return max; } int maxHeapInsert(ARRAY *A, int key) { int i, *p; if (A-array_size A-capacity) { p (int*)realloc(A-int_array, A-capacity * 2 * sizeof(int)); if (!p) return -1; A-int_array p; A-capacity 2 * A-capacity; } A-array_size; i A-array_size - 1; while (i 0 key A-int_array[PARENT(i)]) { A-int_array[i] A-int_array[PARENT(i)]; i PARENT(i); } A-int_array[i] key; return 0; }三个函数的填空点分别是返回堆顶元素、把最后一个元素提到堆顶、新元素插入位置的下标初始化、上滤循环的父节点比较条件、最后把key写入数组。逻辑上heapExtractMax 必须先把最后一个元素挪到堆顶再缩小array_size否则堆顶元素覆盖后最后一个位置的数据会残留破坏堆结构。heapify 的作用是从堆顶开始向下调整所以要传长度和下标0。maxHeapInsert 的循环条件要特别注意“key 父节点”而不是“子节点 父节点”。因为大顶堆要求父节点不小于子节点新插入元素放在数组末尾后需要不断和父节点比较如果比父节点大就向上移动。每移动一次当前插入位置就更新为父节点位置直到遇到不小于key的父节点或者到达堆顶。时间复杂度方面heapMaximum 直接访问数组首元素紧致上界是 O(1)heapExtractMax 删除堆顶后要执行一次heapify复杂度 O(log n)maxHeapInsert 最坏情况下要沿着树高一直上滤到根复杂度也是 O(log n)。最后一道小问是典型的堆插入位置计算。堆 A 有 12 个元素数组下标从0开始插入10后先放在下标12。12的父节点是6A[6]710大于7所以10上移到下标66的父节点是3A[3]510大于5继续上移到下标33的父节点是1A[1]1310小于13停止。最终新元素停在数组下标3也就是从1开始的第4个位置。这一类题只要手动画出一棵完全二叉树逐层标下标基本不会错。5.2 组合模式补全C和Java各有一处易混点组合模式的组织结构题核心是树形结构。ConcreteCompany 是分支节点HRDepartment 和 FinanceDepartment 是叶子节点。C版和Java版的代码骨架几乎一样但C用指针和纯虚函数Java用抽象类和List。C版的空位通常是构造函数里给name赋值、Add和Delete声明为纯虚函数、list的泛型类型填Company*、Add实现里写成children.push_back(c)、Delete实现里写children.remove(c)。这里最容易错的是list泛型如果只填Company编译都过不了因为存储的是指针必须是listCompany*。Java版的空位对应关系类似第一空是abstract class继承关系用extendschildren的泛型是CompanyAdd调用children.add(c)Delete调用children.remove(c)。Java版不需要指针概念所以List 就够了。两道题的主函数里还有两处对象树组装代码。C版和Java版分别是root-Add(comp)和comp-Add(comp1)这类调用目的是把上海分公司挂到总部下面再把南京办事处挂到上海分公司下面。这考察的是对组合模式“整体-部分”结构的理解每个分支节点都能添加子节点叶子节点不能添加。5.3 高频失分点排查五个踩坑记录答题时最容易踩的坑集中在以下几个地方。现象一答案写对了但分数被扣掉一半。原因是用自己的话重写了题干词汇比如把“客户文件”写成“客户信息表”。解决所有填空都从题干原文复制关键词题干怎么叫答案就怎么写。现象二数据流图上找不到缺失的数据流。原因是只盯着加工看没检查文件更新类描述。解决先把题干里所有带“更新”“修改”“删除”的句子标出来再去图里找对应的输出流找不到就是缺失流。现象三关系模式主键填成单一属性。原因是忽略了“一个业主可以有多套房”这类数量描述。解决先判断实体间是1:n还是n:m再决定主键是单属性还是组合属性不要凭直觉定主键。现象四状态图迁移漏了超时分支。原因是把注意力全放在正常流程上忽略了时间约束。解决题干里出现“7天”“超过”“未在”这类字眼时立刻把对应迁移补进状态图。现象五C语言填空题把i初始化写成array_size。原因是没注意数组下标从0开始新增元素的下标等于array_size-1。解决所有数组下标计算都先画一个长度为3的小数组把下标和长度对着看一遍超过再填代码。6. 按采分点自查用真题参考答案做三轮错题复盘真题资源最好的用法不是从头到尾看一遍答案而是做严格的三轮采分点复盘。第一轮按考试状态做第二轮按采分点批改第三轮把错题重做并对照标准答案核对表述。批改时建议把所有大题按小题拆开给每个答案点打分。比如数据流图题实体名占1分数据存储名占1分加工的输入和输出流各占0.5分缺失流的起点和终点各占0.5分。这样批出来的分数不是卷面总分而是“采分点命中率”能直接看出哪类题型没掌握。我自己常用一张错题复盘表每道错题一行手工画表格也行题号题型丢分点原因分析纠正动作试题一数据流图缺失流起点写错只看了写操作没核对加工名称重画0层图标出所有加工和数据流试题二数据库设计主键填成房号没考虑业主多套房场景默写1:n判断口诀再做题试题三UML状态迁移漏超时分支没把时间约束当成事件把题干所有约束句摘抄到草稿纸上三轮复习的节奏可以这样安排第一天做整卷并批改把错题原因列进表里第三天只看错题重新做一遍不看答案第七天把仍然重错的题整理成一张新表用默写的方式把正确答案的关键词写下来。这个习惯特别适合软考下午题因为它不像选择题那样能靠排除法蒙对每个空都在考你对规范词汇和分析顺序的记忆。这个复盘方法帮我解决了一个很实际的问题看答案时觉得都会合上答案做题时又不知道从哪下手。从那以后我每次练习下午题都强制走一遍“限时做题、按采分点批改、三天后重做错题”的流程数据流图和关系模式题的正确率稳定了很多。这套2025年下半年真题里的题型分布和往年基本一致可作为下半年下午题的重点复习材料。希望帮到你。本文还有配套的精品资源点击获取
简介2025年下半年软件设计师下午真题及参考答案面向软考中级软件设计师考生适合备考冲刺与案例题专项训练。内容涵盖四道典型试题订单处理系统的数据流图分析包括顶层图与0层图实体、数据存储及缺失数据流补全小区物业收费管理系统的数据库设计涉及关系模式完善、主外键确定及范式判断网上药店的UML建模要求补充类图、多重度和处方状态图还有堆数据结构的大顶堆调整C代码题。每道题均配有参考答案与解析可帮助考生梳理解题步骤掌握数据流图、ER图、关系模式规范化、UML状态图等高频考点的答题方法。资源包共1个doc文件约1.42MB方便直接打开或打印练习。已有955人学习使用可作为考前实战演练和查漏补缺的重要参考。1. 软件设计师下午真题背答案没用得学会按采分点答题软考软件设计师的下午题看着像是考案例实际上考的是一套固定的分析套路。2025年下半年这套真题一共六道大题覆盖数据流图、数据库设计、UML建模、优先队列的C代码填空和组合模式的C/Java实现。首次接触这套卷的人容易觉得“题目文字很长、图形很乱”尤其是数据流图里少一条数据流、关系模式里缺几个属性这种题不掌握分析方法靠死记硬背肯定翻车。这份真题资源的价值不在于把答案背下来去碰原题而在于拿它训练采分点意识每个空该填什么词、从哪里找依据、为什么不能换成自己的说法。适合正在备考软考、想做下午题专项突破的从业者也适合把它当作模拟练习按考试时间掐表做一遍。2. 数据流图题从实体判断到缺失流定位的三个关键动作订单处理系统的数据流图题是整套下午题里最考验“词汇复用能力”的一道。题干给出了八项功能顶层数据流图和0层数据流图各有缺失要求填实体、数据存储、加工名称还要找出一条缺失的数据流。表面看是在考图实际上考的是“能不能从需求描述里原样找出图中每个符号的依据”。2.1 先从功能清单里区分外部实体和数据存储外部实体的判断标准是看它是否和系统之间有交互但又不属于系统内部的数据文件。对照题干功能描述客户通过电话、传真、邮件或Web站点下订单这属于系统外部发起者功能(4)把配货单发送给仓库仓库备好货之后返回备货就绪告知这属于外部协作方功能(8)产生应收账户报表发送给财务部门这也属于外部接收方。常见做法是先列一张交互表把功能编号、交互对象、方向都标出来。功能编号功能描述交互对象方向(1)(2)(3)客户下单、查询商品客户入(4)发送配货单、接收备货告知仓库出/入(7)发送客户账单客户出(8)发送应收账户报表财务部门出这样看下来顶层图里的 E1~E3 就对应客户、仓库、财务部门。需要注意题干里还提到“若现货不足则需向供应商订货”这容易让人误把供应商也当成顶层实体。但这道题只要求填三个实体说明供应商要么被归入仓库的备货流程要么在0层图中并没有单独建模。答题时严格按题干词汇填写不要自创“订货方”这类说法。数据存储的判断相对直接。题干反复出现“从商品文件中查询商品的价格和可订购数量”“将新客户信息添加到客户文件”“产生订单并添加到订单文件”D1~D3 基本就是商品文件、客户文件、订单文件。判断依据主要是“文件”二字凡是系统内部需要持久化保存的数据集合都是数据存储不是外部实体。2.2 加工P1和P2的输入输出流怎么推导0层图中的加工是由顶层图的处理过程细化出来的。题干功能(2)是查询商品信息客户提交商品信息请求系统从商品文件查询后返回功能(3)是增加订单记录根据客户的订购请求和已有客户记录产生订单写入订单文件。这两个功能在0层图中往往就是P1和P2。实际答题时我会先在草稿纸上把每个加工连接的数据流列成一张表。P1的名称为“查询商品信息”输入流是“商品信息请求客户”输出流是“商品信息客户”。P2的名称为“增加订单记录”输入流是“订购请求客户”和“客户记录客户文件”输出流是“订单记录订单文件”。这里有一个容易忽略的点P2的输入输出涉及数据存储输入流用“客户记录”比“客户信息”更贴近题干。而且数据流的起点和终点必须写图中的符号或题干词汇比如“D2”可以写“客户文件”“P2”可以写“增加订单记录”但不能写“根据客户的情况算一下订单”——阅卷时是按关键词给分的。2.3 缺失数据流盯住“写操作”和“加工平衡”找缺失数据流有两个方向。第一个方向是检查每个加工是否有输入和输出如果一个加工只有输出没有输入或者只有输入没有输出基本可以断定问题出在附近。第二个方向是重点盯题干里带“更新”“修改”“删除”字样的功能描述这些描述一定会对应一条数据流图中如果没画出来就是缺失。这道题的关键线索是功能(7)创建客户账单时“同步更新商品文件中的商品数量和订单文件中的订单状态”。订单文件的状态更新可以由创建客户账单这个加工直接发数据流到D3但商品文件的数量更新是一条从加工到数据存储的写数据流。0层图里如果只有从商品文件读取数据的流没有写回商品文件的流那缺失的就是这条。定位方法很简单找到创建客户账单对应的加工看它是否有一条指向商品文件的输出流。如果没有这条缺失流的起点就是“创建客户账单”加工终点是“商品文件D1”。答题时起点和终点都要用图中的词汇不能写“扣库存流程”这种自己发明的词。还有一个小技巧检查数据流时把所有数据流都标上方向箭头然后从起点沿着箭头走一遍看每个加工的数据能不能闭环。走不通的那一段基本就是缺失流的位置。3. 数据库设计题物业收费系统里的ER补全与关系模式推导小区物业收费管理系统这道题是典型的“需求分析概念模型关系模式”综合题。题干给了大量实体属性也给了收费计算原则但关系模式缺了五处ER图缺了若干联系和类型还要判断范式。做这类题的核心是先画ER草图再对照关系模式逐项填空不要直接在模式上凭空补。3.1 从需求句里识别实体、属性和联系基数先把题干中的名词都圈出来业主、房号、房屋面积、部门、员工、收费信息、收费类型、收费原则。其中业主、部门、员工、房屋、收费信息是实体房屋面积、收费金额、数量这些是属性业主和房屋之间的关系是“一个业主可以有一套或多套房屋”这是1:n联系。注意题干里那句“房号可唯一标识一条业主信息且一个房号仅对应一套房屋”。答题时可以不去纠结这里为什么用“房号”标识关键是认清一个事实业主和房屋之间是1:n那么业主和房屋的关联需要用两个属性共同标识。所以业主关系模式的第一空需要同时填入“业主编号,房号”或者按题目模式写法把“业主编号”和“房号”都放进括号里。画ER图时我习惯先在草稿纸上画三个核心实体业主、部门、员工。员工属于一个部门一个部门只有一个负责人所以部门和员工之间是1:n联系收费信息关联到业主的某套房屋同时也关联到执行收费的员工。收费类型作为弱实体或者收费信息的判别属性在ER图中要根据题目给出的图2-1的已有结构来补不要自己重新设计一张表。3.2 关系模式填空主键和外键的确定顺序关系模式填空和ER图是联动关系。每填一个空都要想清楚这个属性放在哪个关系里、它承担什么角色。下面按一般答题顺序展开。-- 业主关系 CREATE TABLE 业主 ( 业主编号 VARCHAR(20), 房号 VARCHAR(20), 姓名 VARCHAR(50), 房屋面积 DECIMAL(10,2), 工作单位 VARCHAR(100), 联系电话 VARCHAR(20), PRIMARY KEY (业主编号, 房号) );这段SQL表达的是补全后的业主关系。主键采用(业主编号, 房号)是因为一个业主可以拥有多套房屋只有这两个属性组合起来才能唯一定位一条具体的房屋持有记录。如果只把业主编号作为主键同一业主的多套房数据会互相冲突如果只把房号作为主键就无法表达业主和房屋的一对多关系。员工和部门的关系模式也遵循同样的逻辑。员工关系里“所在部门号”是外键指向部门关系的主键“部门号”而部门关系的主键就是部门号本身。权限关系比较简单主键是“职务”因为题干明确说不同职务有不同的操作权限。收费信息关系的主键要小心最好使用(房号, 收费类型, 收费日期)因为同一套房在同一个月份、同一种收费类型下只会有一条记录。收费原则关系里缺的是“收费类型”和对应的“计费单价”主键是收费类型。物业费、卫生费、水费、电费这四类计费方式不同但都属于“按单价计算”所以只要用收费类型就能唯一定位一条计费规则。3.3 范式判断业主关系为什么在1NF题目要求判断业主关系属于第几范式并说明存在的问题。标准判断路径是先看主键再看是否存在部分函数依赖。业主关系的主键是(业主编号, 房号)那么“房屋面积”实际上依赖于“房号”不依赖于“业主编号”“姓名”依赖于“业主编号”不依赖于“房号”。也就是说非主属性对候选键存在部分函数依赖按照范式的定义这只满足第一范式不满足第二范式。答题时不能只写“它是1NF”还要说明存在的问题。最直接的问题是数据冗余同一个业主名下如果有三套房他的姓名、联系电话、工作单位就要在三条记录里重复出现同时会引发更新异常比如业主换了电话号码需要同步修改多条记录如果漏改一条数据就不一致了。删除房屋记录时还可能把业主的唯一联系方式也删掉这就是删除异常。遇到这类题目写范式的标准句式是先给结论再写一条具体的函数依赖关系最后补一个实际场景说明后果。阅卷时往往看“部分函数依赖”这个关键短语给分所以这个词一定要落在答题纸上。4. UML建模题类图、多重度、状态图一起抓网上药店这道题题干描述很长注册、登录、录入处方、提交处方、验证处方的流程串成一条完整业务链。题目给了类图的框架让填C1~C5类名和多重度还给了处方状态图让填状态名和迁移名。做这类题不能一上来就猜类名要把文字描述当成业务流程图来过一遍。4.1 类名补全从句子主语里找线索类图中的类基本都是需求描述里反复出现的主体名词。题干里出现过顾客、医生、处方、药物、订单、付款方式这几个角色类图C1~C5就应从这些词里选。常规答案是C1对应顾客C2对应医生C3对应处方C4对应药物C5对应付款方式或支付账户。如果题目给的类图片段里有“处方”已经单独画出那么C1~C5的分配会相应调整但核心逻辑不变顾客要注册并登录顾客下处方处方关联医生处方包含药物顾客使用付款方式进行结算。拿到这类题先把题干中的每个“谁做了什么事”标出来。比如“顾客必须与药店签订授权协议书”说明顾客类和授权协议有关“顾客按照处方录入界面填写医生的信息和处方上的药物信息”说明处方类要关联医生类和药物类。类和类之间的关系是靠行为动词串起来的不是靠名词堆出来的。4.2 多重度判断从业务规则反向推导多重度是UML题的高频失分点。判断依据是规则句里的数量词而不是主观想象。关系题干依据多重度顾客和处方已经注册的顾客可以登录购买药物一个顾客可以多次买药1 : 1..*医生和处方顾客录入医生信息多个处方可能对应同一医生1 : 1..*处方和药物处方上可以填写多种药物一种药物也可能出现在多个处方中* : *先看“顾客—处方”一个顾客可以下多个处方一个处方只属于一个顾客所以顾客端是1处方端是1..。再看“医生—处方”一个医生可以被多个处方关联每个处方只能写一个医生所以医生端是1处方端是1..。最后是“处方—药物”一个处方包含多种药物一个药物也会出现在多个处方里所以两端都是*。多重度的写法要注意符号1..*表示一个到多个不要写成一个星号就完事。题干里明确说“处方上的药物信息”没有限制单种药物所以必须用多对多表达。4.3 状态图填充把流程约束转成迁移处方状态图考的是流程理解。题干把状态切换写得很清楚提交处方后状态是“处方已提交”然后验证医生信息。医生信息不正确状态变成“医生信息无效”处方取消医生信息正确系统向医生发送确认请求状态变成“审核中”。接下来有三个分支医生答复无效状态置为“无效处方”医生7天内没答复状态置为“无法审核”医生7天内给出确认答复状态置为“准许付款”。所以S1~S4对应的就是“医生信息无效、无效处方、无法审核、准许付款”这几个状态。迁移名要从题干动词里找。状态从“处方已提交”到“审核中”迁移名可以是“验证医生信息通过”从“审核中”到“准许付款”迁移名是“医生确认处方有效”从“审核中”到“无效处方”迁移名是“医生答复无效”从“审核中”到“无法审核”迁移名是“超过7天未答复”。这里有一个常见误区把“7天内给出答复”单纯理解成一个时间事件而忽略它的前置条件是医生信息首先要验证通过。状态图里的迁移必须标注触发事件像“超过7天未答复”这样的约束是迁移名的一部分不能省掉。5. 堆与组合模式代码填空高频失分点排查代码填空题在这套下午题里占两道大题的分量一道是优先队列的大顶堆操作一道是组合设计模式的C和Java实现。代码填空主要不是考语法而是考数据结构的数组下标规律和面向对象的抽象层次。5.1 优先队列三个函数数组下标和边界条件才是核心堆在优先队列里用数组存储父节点和子节点的下标关系是固定的。PARENT(i) i / 2这个宏是整套题的钥匙。int heapMaximum(ARRAY *A) { return A-int_array[0]; } int heapExtractMax(ARRAY *A) { int max A-int_array[0]; A-int_array[0] A-int_array[A-array_size - 1]; A-array_size--; heapify(A, A-array_size, 0); return max; } int maxHeapInsert(ARRAY *A, int key) { int i, *p; if (A-array_size A-capacity) { p (int*)realloc(A-int_array, A-capacity * 2 * sizeof(int)); if (!p) return -1; A-int_array p; A-capacity 2 * A-capacity; } A-array_size; i A-array_size - 1; while (i 0 key A-int_array[PARENT(i)]) { A-int_array[i] A-int_array[PARENT(i)]; i PARENT(i); } A-int_array[i] key; return 0; }三个函数的填空点分别是返回堆顶元素、把最后一个元素提到堆顶、新元素插入位置的下标初始化、上滤循环的父节点比较条件、最后把key写入数组。逻辑上heapExtractMax 必须先把最后一个元素挪到堆顶再缩小array_size否则堆顶元素覆盖后最后一个位置的数据会残留破坏堆结构。heapify 的作用是从堆顶开始向下调整所以要传长度和下标0。maxHeapInsert 的循环条件要特别注意“key 父节点”而不是“子节点 父节点”。因为大顶堆要求父节点不小于子节点新插入元素放在数组末尾后需要不断和父节点比较如果比父节点大就向上移动。每移动一次当前插入位置就更新为父节点位置直到遇到不小于key的父节点或者到达堆顶。时间复杂度方面heapMaximum 直接访问数组首元素紧致上界是 O(1)heapExtractMax 删除堆顶后要执行一次heapify复杂度 O(log n)maxHeapInsert 最坏情况下要沿着树高一直上滤到根复杂度也是 O(log n)。最后一道小问是典型的堆插入位置计算。堆 A 有 12 个元素数组下标从0开始插入10后先放在下标12。12的父节点是6A[6]710大于7所以10上移到下标66的父节点是3A[3]510大于5继续上移到下标33的父节点是1A[1]1310小于13停止。最终新元素停在数组下标3也就是从1开始的第4个位置。这一类题只要手动画出一棵完全二叉树逐层标下标基本不会错。5.2 组合模式补全C和Java各有一处易混点组合模式的组织结构题核心是树形结构。ConcreteCompany 是分支节点HRDepartment 和 FinanceDepartment 是叶子节点。C版和Java版的代码骨架几乎一样但C用指针和纯虚函数Java用抽象类和List。C版的空位通常是构造函数里给name赋值、Add和Delete声明为纯虚函数、list的泛型类型填Company*、Add实现里写成children.push_back(c)、Delete实现里写children.remove(c)。这里最容易错的是list泛型如果只填Company编译都过不了因为存储的是指针必须是listCompany*。Java版的空位对应关系类似第一空是abstract class继承关系用extendschildren的泛型是CompanyAdd调用children.add(c)Delete调用children.remove(c)。Java版不需要指针概念所以List 就够了。两道题的主函数里还有两处对象树组装代码。C版和Java版分别是root-Add(comp)和comp-Add(comp1)这类调用目的是把上海分公司挂到总部下面再把南京办事处挂到上海分公司下面。这考察的是对组合模式“整体-部分”结构的理解每个分支节点都能添加子节点叶子节点不能添加。5.3 高频失分点排查五个踩坑记录答题时最容易踩的坑集中在以下几个地方。现象一答案写对了但分数被扣掉一半。原因是用自己的话重写了题干词汇比如把“客户文件”写成“客户信息表”。解决所有填空都从题干原文复制关键词题干怎么叫答案就怎么写。现象二数据流图上找不到缺失的数据流。原因是只盯着加工看没检查文件更新类描述。解决先把题干里所有带“更新”“修改”“删除”的句子标出来再去图里找对应的输出流找不到就是缺失流。现象三关系模式主键填成单一属性。原因是忽略了“一个业主可以有多套房”这类数量描述。解决先判断实体间是1:n还是n:m再决定主键是单属性还是组合属性不要凭直觉定主键。现象四状态图迁移漏了超时分支。原因是把注意力全放在正常流程上忽略了时间约束。解决题干里出现“7天”“超过”“未在”这类字眼时立刻把对应迁移补进状态图。现象五C语言填空题把i初始化写成array_size。原因是没注意数组下标从0开始新增元素的下标等于array_size-1。解决所有数组下标计算都先画一个长度为3的小数组把下标和长度对着看一遍超过再填代码。6. 按采分点自查用真题参考答案做三轮错题复盘真题资源最好的用法不是从头到尾看一遍答案而是做严格的三轮采分点复盘。第一轮按考试状态做第二轮按采分点批改第三轮把错题重做并对照标准答案核对表述。批改时建议把所有大题按小题拆开给每个答案点打分。比如数据流图题实体名占1分数据存储名占1分加工的输入和输出流各占0.5分缺失流的起点和终点各占0.5分。这样批出来的分数不是卷面总分而是“采分点命中率”能直接看出哪类题型没掌握。我自己常用一张错题复盘表每道错题一行手工画表格也行题号题型丢分点原因分析纠正动作试题一数据流图缺失流起点写错只看了写操作没核对加工名称重画0层图标出所有加工和数据流试题二数据库设计主键填成房号没考虑业主多套房场景默写1:n判断口诀再做题试题三UML状态迁移漏超时分支没把时间约束当成事件把题干所有约束句摘抄到草稿纸上三轮复习的节奏可以这样安排第一天做整卷并批改把错题原因列进表里第三天只看错题重新做一遍不看答案第七天把仍然重错的题整理成一张新表用默写的方式把正确答案的关键词写下来。这个习惯特别适合软考下午题因为它不像选择题那样能靠排除法蒙对每个空都在考你对规范词汇和分析顺序的记忆。这个复盘方法帮我解决了一个很实际的问题看答案时觉得都会合上答案做题时又不知道从哪下手。从那以后我每次练习下午题都强制走一遍“限时做题、按采分点批改、三天后重做错题”的流程数据流图和关系模式题的正确率稳定了很多。这套2025年下半年真题里的题型分布和往年基本一致可作为下半年下午题的重点复习材料。希望帮到你。本文还有配套的精品资源点击获取
