2020 年下半年（11 月）系统架构设计师 · 真题套卷#

一、本卷元信息#

答案与可信度标注体系#

二、综合知识（选择题）#

（一）操作系统（1—4、9—11）#

1.（设备管理 · 假脱机） CPU 输出数据的速度远高于打印机，为解决该矛盾可采用（）。
A. 并行技术　B. 缓存技术　C. Spooling 技术　D. 虚拟技术

答案 B（机构答案）
解析：在 CPU 与低速外设之间设置缓冲区，CPU 把数据送入缓冲区后即可继续运行，由设备控制器在适当时机输出，是缓冲技术解决的典型矛盾。（Spooling 是把独占设备改造成共享设备的技术，用于打印机共享排队，不解决 CPU 与外设速度差。）
陷阱：见"打印机"就选 Spooling（假脱机解决的是"独占设备共享"，不是速度匹配）。

2.（多线程共享） 进程 P 创建线程 T1、T2、T3，下列说法正确的是（）。
A. 该进程中已打开的文件不能被 T1、T2、T3 共享
B. 该进程中已打开的文件不能被 T1、T2、T3 共享
C. 该进程中 T1 的栈指针不能被 T2 和 T3 共享
D. 该进程中某线程的栈指针可以被 T1、T2、T3 共享

答案 C（机构答案）
解析：同一进程内线程共享代码段、数据段（全局变量）、打开的文件、信号、定时器；但每个线程有独立的栈和栈指针、寄存器上下文、程序计数器。
陷阱：把"栈"当成共享资源（栈是线程私有，这也正是线程切换代价小的原因）。
注：来源 A、B 两项文字重复，属回忆误差，不影响判断。

3.（位示图容量） 字长 32 位，磁盘容量 300GB，物理块 4MB，位示图大小为（）个字。
A. 2400　B. 3200　C. 6400　D. 9630

答案 A（机构答案）
解析：块数 = 300GB ÷ 4MB = 300×1024MB ÷ 4MB = 76800 块；每字 32 位可表示 32 块 → 76800 ÷ 32 = 2400 字。
陷阱：把 1GB 当 1000MB（得 2343.75）；忘记除以字长（得 76800）；把位示图当"每块 1 位"后又多乘 8。

4.（实时系统） 在实时操作系统中，对于来自外部的事件必须在（）。
A. 一个时间片内处理　B. 一个周转时间内处理　C. 一个机器周期内处理　D. 被控对象允许的时间范围内处理

答案 D（机构答案）
解析：实时系统的正确性不仅取决于结果正确，还取决于是否在规定的截止时间（deadline）内完成，该时间由被控对象的物理过程决定（硬实时/软实时）。
陷阱：选"时间片"（时间片是分时系统轮转调度的概念）。

9.（微内核） 关于操作系统微内核架构特征，不正确的是（）。
A. 结构清晰，利于协作开发　B. 代码量少，可移植性好　C. 良好的伸缩性、扩展性　D. 功能代码可以互相调用，性能很高

答案 D（机构答案）
解析：微内核只保留进程调度、内存管理、中断处理、进程间通信等最基本功能，其余（文件系统、驱动、网络）以用户态服务运行，通过消息传递交互。优点是可靠、可移植、可扩展、易裁剪；缺点是服务间通信开销大、性能低于宏内核。
陷阱：把"功能代码互相调用、性能高"当优点——那正是宏内核的特征，微内核恰恰要减少这种直接调用。

10.（页式地址变换） 页面大小 4KB，CPU 发出虚拟地址 0010 0000 0000 0100，访问的物理地址是（）。
A. 1100 0000 0000 0100　B. 0100 0000 0000 0100　C. 1100 0000 0000 0000　D. 1100 0000 0000 0010
〔图缺失：页表页号 2→物理块 4〕 > 答案 B（机构答案）

解析：4KB = 2¹²，低 12 位为页内偏移，高 4 位为页号。虚拟地址 = 页号 0010（2） + 偏移 0000 0000 0100；查页表得物理块号 4（0100）；物理地址 = 0100 拼接偏移 = 0100 0000 0000 0100。
陷阱：把页号与块号直接相加；只换高位却把低位写成 0（选项 C）；把块号写成 12（1100）。

11.（段页式） 属于段页式内存管理的描述是（）。
A. 一个程序就是一段，使用基址—极限对管理
B. 一个程序分为许多固定大小的页面，使用页表管理
C. 程序按逻辑分为多段，每一段内又进行分页，使用段页表管理
D. 程序按逻辑分成多段，用一组基址—极限对管理，基址—极限对存放在段表里

答案 C（机构答案）
解析：A 是单一连续/分区式（基址—极限）；B 是纯页式；D 是纯段式（段表存基址—极限对）；C 才是段页式：先按逻辑分段，段内再分页，用段表 + 页表（段页表）两级映射。
陷阱：把 D 当段页式（D 只有段表、没有页表）。

（二）数据库（5—8）#

5.（派生属性） 学生关系 Students（学号，姓名，性别，出生日期，年龄，家庭地址），按"派生属性不存储"原则，正确设计是（）。
A.（学号，性别，出生日期，年龄，家庭地址）
B.（学号，姓名，性别，出生日期，年龄）
C.（学号，姓名，性别，出生日期，家庭地址）
D.（学号，姓名，出生日期，年龄，家庭地址）

答案 C（机构答案）
解析：年龄可由出生日期推算，属派生属性，规范化为 3NF 时应删除；其他属性均须保留（B 丢地址、D 丢性别、A 丢姓名且保留年龄）。
陷阱：见到"年龄"就删，却连带删掉了非派生属性（姓名/家庭地址/性别）。

6—7.（函数依赖 · 候选键） R(U,F)，U={A,B,C,D,E}，F={A→B, D→C, BC→E, AC→B}。求属性闭包等式成立的是（），R 的候选关键字为（）。

第 1 空 答案 存疑（来源四个选项均为空白，无法对应）
第 2 空 答案 A（AD）（机构答案）
解析：候选键须能推出全部属性。计算 (AD)⁺：A→B ⇒ 得 B；D→C ⇒ 得 C；已有 B、C ⇒ BC→E 得 E；故 (AD)⁺ = {A,B,C,D,E} = U，且 A、D 均不能单独决定全部属性 → AD 为候选键。（(AC)⁺ = {A,B,C,E}，缺 D；(AB)⁺ 缺 C、D。）
陷阱：只看"出现在箭头左边"就选 A 或 D 单属性；忘记 BC→E 需要 B、C 同时具备。

8.（分布式数据库透明性） 用户无需知道数据存放的物理位置，属于（）。
A. 分片透明　B. 逻辑透明　C. 位置透明　D. 复制透明

答案 C（机构答案）
解析：分片透明——不必知道数据如何分片；位置透明——不必知道分片存放在哪个站点；复制透明——不必知道副本的存在与位置；逻辑透明（局部映像透明）——不必知道局部数据库的数据模型。
陷阱：分片透明与位置透明混淆（"怎么切"vs"放哪里"）。

（三）安全、区块链、网络（12—17）#

12.（分层架构脆弱性） 嵌入式分层架构常见的脆弱性包括（）等两个方面。
A. 底层错误导致整个系统无法运行、层间功能引用导致功能失效
B. 底层错误导致整个系统无法运行、层间引入通信机制势必造成性能下降
C. 上层错误导致整个系统无法运行、层间引入通信机制势必造成性能下降
D. 上层错误导致整个系统无法运行、层间功能引用导致功能失效

答案 B（机构答案）
解析：分层架构下层为上层提供服务，底层故障会向上传导导致整体失效（A/C/D 说"上层错误导致整个系统无法运行"不成立）；同时层间必须通过协议/接口通信，逐层转换带来性能开销。
陷阱：把依赖方向搞反（上层依赖下层，故下层出错影响面更大）。

13.（区块链挖矿） 关于区块链"挖矿"，错误的是（）。
A. 矿工挖矿取得记账权，同时获得代币奖励
B. 挖矿本质上是尝试计算一个 Hash 碰撞
C. 挖矿是一种工作量证明机制
D. 可以防止比特币的双花攻击

答案 D（机构答案，存疑）
解析：挖矿 = 不断调整随机数 nonce，使区块头哈希满足难度目标，本质是工作量证明（PoW），胜出者获得记账权 + 代币奖励。防止双花靠的是"最长链共识 + 多区块确认"这一共识机制，而非挖矿动作本身；且严格说挖矿求的是"哈希值小于目标值"，并非"哈希碰撞"。故 B、D 均有可争议之处，考试按"挖矿≠防双花机制"选 D。
陷阱：把"挖矿"与"共识机制"混为一谈；把 Hash 碰撞（找相同摘要）与 Hash 难题（找小于目标的摘要）混淆。

14.（Linux DNS 配置） Linux 中 DNS 的配置文件是（），包含域名搜索顺序与 DNS 服务器地址。
A. /etc/hostname　B. /dev/host.conf　C. /etc/resolv.conf　D. /dev/name.conf

答案 C（机构答案）
解析：/etc/resolv.conf 配置 nameserver、search、domain；/etc/hostname 是主机名；/etc/hosts 是静态主机名映射；/etc/nsswitch.conf 决定解析顺序。
陷阱：把 /etc/hosts（静态映射）当 DNS 配置。

15.（网络延迟） 关于网络延迟，正确的是（）。
A. 对等网络中，延迟大小与终端数量无关
B. 使用路由器转发的延迟小于交换机
C. 使用 Internet 服务能最大限度减小网络延迟
D. 服务器延迟的主要影响因素是队列延迟和磁盘 I/O 延迟

答案 D（机构答案）
解析：服务器侧延迟主要来自请求排队（队列延迟）与磁盘 I/O；对等网络中终端越多、跳数与拥塞越大，延迟越大；路由器做三层查表转发，通常慢于交换机的二层硬件转发；走 Internet 只会增加不确定性。
陷阱：认为"路由器比交换机快"（路由转发需拆包查路由表，且有 NAT/ACL 开销）。

16—17.（系统监视） 系统监视有三种方式：通过（）（如 UNIX/Linux 的 ps、last）；通过系统记录文件；集成命令、文件与可视化技术的监控工具，如（）。
第 1 空：A. 系统命令　B. 系统调用　C. 系统接口　D. 系统功能
第 2 空：A. Windows 的 netstat　B. Linux 的 iptables　C. Windows 的 Perfmon　D. Linux 的 top

答案 A、C（机构答案）
解析：ps/last 属系统命令；Windows 性能监视器（Perfmon）是典型的"命令 + 日志 + 可视化"综合监控工具（Linux 对应 top/vmstat/sar，但 top 属命令行工具，不作"可视化集成工具"的代表）。
陷阱：选 top（命令行工具，不是可视化集成监控平台）；把 netstat/iptables 当监控工具（前者看连接，后者配防火墙）。

（四）电子政务（18—21）#

18—21.（G2G / G2B / G2C / B2G） 人口信息采集处理属于（）；营业执照颁发属于（）；户籍管理属于（）；参加政府工程投标属于（）。
A. 政府对企（事）业单位（G2B）　B. 政府与政府（G2G）　C. 企业对政府（B2G）　D. 政府对居民（G2C）

答案 B、A、D、C（机构答案）
解析：判断依据是"谁对谁、谁发起"：

• 人口信息采集处理 = 政府部门之间共享人口数据 → G2G；
• 营业执照颁发 = 政府面向企业提供服务 → G2B；
• 户籍管理 = 政府面向居民 → G2C；
• 参加政府工程投标 = 企业主动面向政府 → B2G（方向相反）。

陷阱：G2B 与 B2G 方向搞反（以"谁发起/谁是被服务方"区分）；把人口信息采集当 G2C（它是政府内部共享）。

（五）软件工程与过程（22—34、39—43）#

22—23.（软件文档） 软件文档分为用户文档和（）两类；用户文档主要描述（）和使用方法。
第 1 空：A. 系统文档　B. 需求文档　C. 标准文档　D. 实现文档
第 2 空：A. 系统实现　B. 系统设计　C. 系统功能　D. 系统测试

答案 A、C（机构答案）
解析：文档两分法——用户文档（功能描述、安装、使用、操作手册）与系统文档（需求、设计、测试、维护等开发过程文档）。用户文档面向使用者，描述系统功能与用法，不涉及实现细节。
陷阱：把"需求文档/设计文档"与"系统文档"并列（它们都是系统文档的子类）。

24—25.（需求基线） 需求文档经评审批准后定义了开发工作的（），它在客户与开发者之间构筑了产品功能与非功能需求的（），是需求开发与需求管理之间的桥梁。
第 1 空：A. 需求基线　B. 需求标准　C. 需求用例　D. 需求分析
第 2 空：A. 需求用例　B. 需求管理标准　C. 需求约定　D. 需求变更

答案 A、C（机构答案）
解析：需求通过评审即基线化（需求基线），此后变更须走变更控制；基线是客户与开发方之间的需求约定（契约），也是"开发"转向"管理"的分界点。
陷阱：把"需求规格说明书"与"需求基线"混（基线是经批准、受控的版本状态）。

26—28.（软件过程） 软件活动主要包括软件描述、（）、软件有效性验证和（）；其中（）定义了软件功能及使用限制。
第 1 空：A. 软件模型　B. 软件需求　C. 软件分析　D. 软件开发
第 2 空：A. 软件分析　B. 软件测试　C. 软件演化　D. 软件开发
第 3 空：A. 软件分析　B. 软件测试　C. 软件描述　D. 软件开发

答案 D、C、C（机构答案）
解析：Sommerville 软件过程四活动：软件描述（规格说明）→ 软件开发（设计与实现）→ 软件有效性验证（V&V）→ 软件演化（维护）；其中软件描述定义软件功能与使用限制（约束）。
陷阱：把"软件测试"当第四项（测试属有效性验证的子集，第四项是演化/维护）；把"需求分析"当描述。

29—30.（开发工具） 开发工具包括需求分析工具、（）、编码与排错工具、测试工具；需求分析工具按描述需求定义的方法分为基于自然语言或图形描述的工具和基于（）的工具。
第 1 空：A. 设计工具　B. 分析工具　C. 耦合工具　D. 监控工具
第 2 空：A. 用例　B. 形式化需求定义语言　C. UML　D. 需求描述

答案 A、B（机构答案）
解析：按生命周期阶段划分工具：需求分析 → 设计 → 编码排错 → 测试；需求定义方法分非形式化（自然语言/图形）与形式化（形式化需求定义语言，如 Z、VDM、B 方法）。
陷阱：把"UML"当形式化语言（UML 是半形式化的图形建模语言）。

31—32.（软件设计四活动） 软件设计包括（）、软件结构设计、人机界面设计和（）。
第 1 空：A. 用例设计　B. 数据设计　C. 程序设计　D. 模块设计
第 2 空：A. 接口设计　B. 操作设计　C. 输入输出设计　D. 过程设计

答案 B、D（机构答案）
解析：经典四活动：数据设计、软件结构（体系结构）设计、人机界面（接口）设计、过程（详细）设计，完成后得到完整的软件设计模型。
陷阱：把"接口设计"放第一空（接口设计＝人机界面设计，已在题干出现）。

33—34.（信息隐蔽） 通过信息隐蔽可以提高软件的（）、测试性和（）。
第 1 空：A. 可修改性　B. 可扩充性　C. 可靠性　D. 耦合性
第 2 空：A. 封装性　B. 安全性　C. 可移植性　D. 可交互性

答案 A、C（机构答案）
解析：信息隐蔽（每个模块隐藏内部实现细节、只暴露必要接口）降低模块间耦合，从而提高可修改性、可测试性、可移植性（教材原话），并利于并行开发。
陷阱：选"可靠性"（信息隐蔽不直接提升可靠性，它提升的是可维护性一族）。

35.（构件分类） 按外部形态构成软件系统的构件分五类，其中（）指可以进行版本替换并增加构件新功能。
A. 装配的构件　B. 可修改的构件　C. 有限制的构件　D. 适应性构件

答案 B（机构答案）
解析：教材五类：装配（装配式，直接组装）构件、有限制构件（需满足约束）、适应性构件（需适配/包装）、可修改构件（可版本替换、增加新功能）、组装式（组合）构件。
陷阱：把"适应性构件"（适配修改）与"可修改构件"（版本升级）对调。

36—38.（中间件功能） 中间件为客户端与服务器提供（）；提供（）保证交易一致性；提供应用的（）。
第 1 空：A. 连接和通信　B. 应用程序接口　C. 通信协议支持　D. 数据交换标准
第 2 空：A. 安全控制机制　B. 交易管理机制　C. 标准消息格式　D. 数据映射机制
第 3 空：A. 基础硬件平台　B. 操作系统服务　C. 网络和数据库　D. 负载均衡和高可用性

答案 A、B、D（机构答案）
解析：中间件三大基本功能：连接与通信（屏蔽异构、提供交互）、交易（事务）管理（保证 ACID 与一致性）、提供应用的负载均衡与高可用性（另有名字服务、安全服务、持久化等）。
陷阱：第三空选"网络和数据库"（那是基础设施，不是中间件提供的服务）。

39—40.（开发模型） （）将开发流程分为目标设定、风险分析、开发与有效性验证、评审四部分；（）通过重用提高可靠性与易维护性，修改时副作用较少。
第 1 空：A. 瀑布模型　B. 螺旋模型　C. 构件模型　D. 对象模型
第 2 空：A. 瀑布模型　B. 螺旋模型　C. 构件模型　D. 对象模型

答案 B、C（机构答案）
解析：螺旋模型 = 四象限（目标设定→风险分析→开发与验证→评审）循环，风险驱动；构件（构件化）模型通过可复用构件组装，构件封装良好 → 复用提高可靠性与易维护性、修改副作用小。
陷阱：把"对象模型"当复用模型（OOP 是方法学，构件模型才强调复用与组装）。

41.（敏捷） 关于敏捷开发，不正确的是（）。
A. 适应性而非预设性　B. 面向过程而非面向人　C. 迭代增量、发行版本小型化　D. 强调相关人员之间的信息交流

答案 B（机构答案）
解析：敏捷以人为本、以价值交付为导向，强调个体与交互高于流程与工具；B 与敏捷宣言第一条直接冲突。
陷阱：把 RUP/CMMI 的"过程为本"当成敏捷。

42—43.（自动化测试脚本） （）是录制手工测试用例得到的脚本；（）把测试输入存储在独立数据文件中而非脚本中。
第 1 空：A. 线性脚本　B. 结构化脚本　C. 数据驱动脚本　D. 共享脚本
第 2 空：A. 线性脚本　B. 结构化脚本　C. 数据驱动脚本　D. 共享脚本

答案 A、C（机构答案）
解析：脚本技术演进：线性脚本（录制回放，无结构）→ 结构化脚本（含控制结构、可复用）→ 共享脚本（被多用例调用）→ 数据驱动脚本（数据与脚本分离，同一脚本跑多组数据）→ 关键字驱动脚本。
陷阱：把"共享脚本"与"数据驱动脚本"混（前者复用代码，后者分离数据）。

（六）架构、评估与设计模式（44—63）#

44—47.（4+1 视图 / 视角） 展示功能组织的（）能判断质量特性，展示并发行为的（）能判断系统行为特性；视图分为逻辑视图、进程视图、实现视图和（）；使用（）记录设计元素的功能与概念接口。
第 1 空：A. 静态视角　B. 动态视角　C. 多维视角　D. 功能视角
第 2 空：A. 开发视角　B. 动态视角　C. 部署视角　D. 功能视角
第 3 空：A. 开发视图　B. 配置视图　C. 部署视图　D. 物理视图
第 4 空：A. 逻辑视图　B. 物理视图　C. 部署视图　D. 用例视图

答案 A、B、B、A（机构答案）
解析：功能组织是静态视角（结构、模块、依赖），并发行为是动态视角（时序、状态、交互）；教材的 4 个视图表述为逻辑视图、进程视图、实现（开发）视图、配置视图（配置视图即部署视图的另一称谓，本题按教材术语选"配置视图"）；逻辑视图记录设计元素的功能与概念接口，刻画其在系统中的角色（功能、性能等）。
陷阱：第 3 空选"部署视图/物理视图"（二者是同义替代说法，命题按教材用"配置视图"，属易争议点）；第 4 空选"进程视图"（进程视图管并发，不管功能接口）。

48—50.（敏感点 / 权衡点） （）是影响多个质量属性的特性，是多个质量属性的（）；如有严格时延要求，加密级别可能成为一个（）。
第 1 空：A. 敏感点　B. 权衡点　C. 风险决策　D. 无风险决策
第 2 空：A. 敏感点　B. 权衡点　C. 风险决策　D. 无风险决策
第 3 空：A. 敏感点　B. 权衡点　C. 风险决策　D. 无风险决策

答案 B、A、B（机构答案）
解析：教材定义链：敏感点是影响某一个质量属性的构件特性；权衡点是影响多个质量属性的特性，即"多个质量属性的敏感点"。加密级别同时影响安全性与性能 → 权衡点。
陷阱：三空互相定义，容易连锁错；记住"权衡点 = 多个敏感点"。

51—53.（三层 C/S） 三层 C/S 增加了（）；应用功能分为表示层、功能层和（）；其中（）是用户接口部分，负责与应用逻辑对话。
第 1 空：A. 应用服务器　B. 分布式数据库　C. 内容分发　D. 镜像
第 2 空：A. 硬件层　B. 数据层　C. 设备层　D. 通信层
第 3 空：A. 表示层　B. 数据层　C. 应用层　D. 功能层

答案 A、B、A（机构答案）
解析：三层 C/S 在二层（客户机 + 数据库服务器）之间增加应用服务器，形成表示层（用户接口）— 功能层（业务逻辑）— 数据层（DBMS）。
陷阱：第 1 空选"分布式数据库"（三层 C/S 增加的是应用服务器，数据库仍可为集中式）；第 3 空选"应用层"（教材术语为表示层）。

54—55.（设计模式分类） 23 种模式按目的分为（）型、结构型和行为型；按范围分为类模式和（）模式。
第 1 空：A. 创建　B. 实例　C. 代理　D. 协同
第 2 空：A. 包　B. 模板　C. 对象　D. 架构

答案 A、C（机构答案）
解析：两个分类维度：目的（创建型、结构型、行为型）；范围（类模式——通过继承在编译期确定；对象模式——通过组合在运行期确定）。
陷阱：把"范围"记成"包/架构"（那是架构层次的划分）。

56—58.（创建型模式） 不指定具体类、为创建一系列相关或相互依赖对象提供接口的是（）；将复杂对象构建与表示分离的是（）；在不了解确切类与创建细节的情况下创建自定义对象的是（）。
第 1—3 空选项：A. Prototype　B. Abstract Factory　C. Builder　D. Singleton

答案 B、C、A（机构答案）
解析：

• Abstract Factory（抽象工厂）：创建产品族（一系列相关/相互依赖对象）的接口，不指定具体类；
• Builder（建造者）：构建过程与表示分离，同一构建过程可得不同表示；
• Prototype（原型）：通过克隆已有实例创建新对象，无需知道具体类与创建细节；
• Singleton（单例）保证唯一实例，与题干无关。

陷阱：把"一系列相关对象"当 Factory Method（工厂方法只创建一个产品）；把 Builder 与 Prototype 混（前者分步构建，后者复制）。

59—63.（质量属性与策略 · 在线教育平台）
场景 1："并发 10 万用户，平均响应时间 < 3 秒" → 与（）相关，采用（）策略；
场景 2："主站宕机 10 秒内自动切换备用站点" → 与（）相关，采用（）策略；
场景 3："上线后少量外围功能与界面调整不超过 10 人·月" → 与（）相关。
第 1 空（属性1）：A. 性能　B. 可用性　C. 易用性　D. 可修改性
第 2 空（策略1）：A. 抽象接口　B. 信息隐藏　C. 主动冗余　D. 资源调度
第 3 空（属性2）：A. 性能　B. 可用性　C. 易用性　D. 可修改性
第 4 空（策略2）：A. 记录/回放　B. 操作串行化　C. 心跳　D. 增加计算资源
第 5 空（属性3）：A. 性能　B. 可用性　C. 易用性　D. 可修改性

答案 A、D、B、C、D（机构答案）
解析：

• "响应时间/吞吐量/并发" → 性能，策略选资源调度（负载均衡、调度、池化、并发）；
• "宕机后 N 秒切换" → 可用性，策略选心跳（故障检测）+ 主动冗余（切换）；
• "N 人·月完成功能/界面调整" → 可修改性（以人·月度量的变更成本）。

陷阱：场景 2 的策略选"主动冗余"（它是可用性策略，但题干问"自动切换"的检测手段；本卷按来源答案 C 心跳，若选项同时含主动冗余需看设问落点）；"人·月"是判断可修改性的关键词，不要误判为性能。

（七）安全、知识产权与数学（64—70）#

64.（SYN Flooding） SYN Flooding 攻击的原理是（）。
A. 利用 TCP 三次握手，恶意造成大量 TCP 半连接，耗尽服务器资源，导致拒绝服务
B. 协议栈不能处理 TCP 序列号紊乱，导致系统崩溃
C. 协议栈不能处理 IP 分片重叠，导致系统崩溃
D. 协议栈处理超大 IP 包时缓存溢出，导致系统崩溃

答案 A（机构答案）
解析：攻击者伪造大量源地址发送 SYN，服务器回 SYN-ACK 并分配半连接队列资源，但不回 ACK → 队列耗尽 → 正常用户无法建连。防御：SYN Cookie、缩短超时、增大队列、限速与清洗。
陷阱：与"泪滴（Teardrop，分片重叠）""Ping of Death（超大包）"混淆——那是 B/C/D 描述的其他攻击。

65.（Kerberos） 关于 Kerberos 认证，错误的是（）。
A. 在开放网络中提供身份认证
B. 用户相互访问必须首先向 CA 申请票据
C. KDC 保存所有用户的账号和密码
D. 使用时间戳防止重放攻击

答案 B（机构答案）
解析：Kerberos 基于 KDC（AS + TGS） 的对称密钥体制：客户端先向 AS 申请 TGT，再向 TGS 申请服务票据——票据由 KDC 签发，与 CA 无关（CA 属 PKI 体系）。时间戳用于防重放，票据有有效期。
陷阱：把 Kerberos（对称密钥、KDC）与 PKI（非对称、CA）混为一谈。

66—67.（软件著作权 · 商业秘密） 研发人员将公司软件算法与部分代码公开发表。该研发人员（），公司丧失了该软件的（）。
第 1 空：A. 与公司共同享有著作权，是正常行使发表权
B. 与公司共同享有著作权，是正常行使信息网络传播权
C. 不享有该软件著作权，其行为涉嫌侵犯公司的专利权
D. 不享有该软件著作权，其行为涉嫌侵犯公司的软件著作权
第 2 空：A. 计算机软件著作权　B. 发表权　C. 专利权　D. 商业秘密

答案 D、D（机构答案）
解析：职务作品（为完成单位任务、利用单位物质技术条件开发）的软件著作权归单位，开发者仅享有署名权与奖励报酬权 → 擅自发表构成侵权；且已签保密协议，公开发表使算法与代码丧失商业秘密（非公知性），但著作权并不因公开而丧失。
陷阱：第 2 空选"发表权"（发表权是著作权的一项，著作权仍归公司，未"丧失"）；选"专利权"（软件算法本身多不授予专利）。

68.（著作权保护期） 按《著作权法》，（）受到永久保护。
A. 发表权　B. 修改权　C. 复制权　D. 发行权

答案 B（机构答案）
解析：署名权、修改权、保护作品完整权的保护期不受限制（永久）；发表权与财产权（复制、发行、出租、信息网络传播等）为作者终生加死后 50 年（法人作品为首次发表后 50 年）。
陷阱：把"发表权"当永久（发表权是一次性权利，但有 50 年期限）。

69.（随机模拟） 近似计算三圆柱相交体体积，最易理解、最易编程实现的是（）。
A. 近似计算二重积分　B. 分解为简单形状分别求体积再求和
C. 利用并集/差集计算交集体积　D. 在包含 V 的正立方体内均匀撒随机点，用落在 V 中的比例估算

答案 D（机构答案）
解析：蒙特卡洛（随机模拟）法：V ⊂ 立方体 m，V ≈ V(m) ×（落入 V 的随机点数 / 总点数）。实现只需"生成随机数 + 判断是否满足三个不等式 + 计数"，最易编程。
陷阱：选 A/B（需要处理复杂积分区域与几何分解，编程难度高）。

70.（盈亏平衡点） 售价 2500 元/台，去年销量 25000 台，固定成本 250 万元，可变成本总额 4000 万元，税率 16%，年销量盈亏平衡点为（）台。
A. 5000　B. 10000　C. 15000　D. 20000

答案 A（机构答案）
解析：单位可变成本 = 4000 万 ÷ 25000 = 1600 元；单位税金 = 2500 × 16% = 400 元；单位边际贡献 = 2500 − 1600 − 400 = 500 元；盈亏平衡点 = 固定成本 ÷ 单位边际贡献 = 2,500,000 ÷ 500 = 5000 台。
陷阱：把"可变成本总额"直接当单位成本；忘记扣除税金（得 2500000/900≈2778）；用总成本除以单价（把固定成本重复计入）。

（八）专业英语（71—75）#

71—75.（系统设计 · 英文填空）
The purpose of systems design is to specify a(n) ( 71 ) which defines the technologies to be used to build the proposed information systems. This task is accomplished by analyzing the data models and process models that were initially created during requirements analysis. The ( 73 ) is used to establish physical processes and data stores across a network. To complete this activity, the analyst may involve a number of system designers and ( 74 ), which may be involved in this activity to help address business data, process, and location issues. The key inputs to this task are the facts, recommendations, and opinions that are solicited from various sources and the approved ( 75 ) from the decision analysis phase.

解析：系统设计的目的是确定应用架构（application architecture），即构建目标信息系统所用技术的蓝图；该任务通过分析需求分析阶段产生的数据模型与过程模型完成；物理数据流图用于在网络范围内建立物理过程与数据存储；完成该活动需要系统设计人员与系统用户参与，以澄清业务数据、流程与地点问题；关键输入是从各方收集的事实、建议、意见，以及决策分析阶段批准的系统提案（system proposal）。
陷阱：73 选"数据流图"（DFD 是逻辑模型，物理 DFD 才含物理过程/存储与网络分布）；75 选"系统架构"（决策分析阶段的输出是提案）。
注：原英文段落的第 2 个空（"during ___"）在公开源中未单独编号，标准答案对应 requirements analysis（需求分析），不计入 75 题。

三、收录说明#

四、案例分析（1 必做 + 4 选 2）#

试题一（必做）：在线软件开发系统 —— 仓库 vs 管道-过滤器 + 效用树（25 分）#

题面要点
系统功能：代码编辑、语法高亮、代码编译、系统调试、代码仓库管理。质量属性描述：(a) 按付费情况分类并提供相应功能；(b) 正常负载下界面操作请求 0.2 秒内响应；(c) 安全防护，检测与防御黑客攻击；(d) 主站点断电后 3 秒内重定向到备用站点；(e) 用户名规则（字母开头、≥8 字符）；(f) 宕机后 15 秒内发现错误并启用备用系统；(g) 代码提交请求 0.5 秒内完成；(h) 硬件扩容 2 人·天完成部署与测试；(i) 代码仓库所有操作详细记录以便审计；(j) 更改 Web 界面风格 4 人·天；(k) 提供远程调试接口。

问题

1. （13 分）李工建议管道-过滤器、王工建议仓库，判断更适合哪种，并从数据处理方式、可扩展性、处理性能三方面填表比较。
2. （12 分）效用树中填质量属性名称，并把 (a)—(k) 填入对应位置。

解题框架

第 1 问：更适合仓库（repository）风格。

• 判断理由：系统核心是"编辑器 + 编译器 + 调试器 + 代码仓库"围绕同一份代码数据反复读写、且需交互式操作 → 数据结构是中心、处理是多个独立工具 → 仓库风格。
• 得分点：结论 + 三维度逐项对照 + 用"交互式处理/数据与处理分离"作理由。
• 典型失分：只说"仓库好"不比较；把"仓库性能更高"写反（仓库有数据加载开销）。

第 2 问（效用树归类）：

〔图缺失〕原题给出效用树骨架，只需把属性名与编号落到叶子。注意：(a)(e) 是功能需求，不应塞进质量属性分支，这是本题最易失分处。

试题二：包裹信息管理系统 —— 逻辑数据模型 + 超类实体 + 派生属性（25 分，14+6+5）#

题面要点
为企业统一管理快递包裹信息，需对不同快递公司的包裹单建模，给出邮政包裹单样例（含寄件人/收件人姓名、电话、单位、地址、邮编，包裹单编号、资费、挂号费、保价费、回执费、费用总计等）。

问题

1. （14 分）说明关系型数据库逻辑数据模型设计过程包含哪些任务；逻辑模型中应包含哪些实体及各自主键。
2. （6 分）什么是超类实体？结合包裹单设计一种超类实体，给出完整属性列表。
3. （5 分）什么是派生属性？指出包裹单中的派生属性。

解题框架

第 1 问（四步法，按教材）：

1. 构建系统上下文数据模型：识别实体及实体间联系（不含属性细节）；
2. 绘制基于主键的数据模型：为每个实体确定标识性属性（主键）；
3. 构建全属性数据模型：为每个实体补充非主键属性；
4. 利用规范化技术建立规范化数据模型（一般达到 3NF）。

实体与主键：

• 收件人（主键：电话；属性含姓名、单位、地址、邮编）；
• 寄件人（主键：电话；同上）；
• 包裹单（主键：包裹单编号；属性含资费、挂号费、保价费、回执费、费用总计等）。

说明：若认为"电话"不唯一，可用"收件人编号/寄件人编号"作代理键，考试以来源答案为准。

第 2 问：

• 定义：超类实体是把多个实体中相同的属性抽取出来构成的抽象实体，原有实体成为其子类，通过继承表达抽象与具体的关系。
• 本案例：设计超类实体 用户（姓名，电话，单位名称，详细地址，邮政编码），收件人、寄件人作为子类继承之。
• 得分点：定义中必须出现"抽取公共属性 + 抽象 + 继承"；属性列表要覆盖图中公共项。

第 3 问：

• 定义：派生属性是指某实体的非主键属性可由本实体其他非主键属性计算得出（规范化为 3NF 时应消除）。
• 本案例：费用总计（= 资费 + 挂号费 + 保价费 + 回执费）为派生属性。
• 陷阱：把"年龄/总价"之外的可计算结果漏掉；把主键当派生属性。

试题三：宇航系统 FACE 开放式架构 —— 需求到架构的映射（25 分，9+10+6）#

题面要点
公司拟采用 FACE（Future Airborne Capability Environment） 开放式软件架构，实现宇航软件跨平台复用。FACE 架构布局含 5 个段（操作系统、I/O 服务、平台服务、传输服务、可移植组件）与 3 类标准接口。

问题

1. （9 分）从描述语言、非功能性需求描述、需求和架构的一致性三方面，说明需求到架构映射的难点。
2. （10 分）说明 FACE 5 个段的含义。
3. （6 分）说明可移植性上紧耦合与封装问题的主要表现及解决方案。

解题框架

第 1 问（三点 + 可补充两点）：

1. 描述语言存在差异：需求多为非正式的自然语言、频繁变更；架构描述使用正式（半形式化）语言，两者难以自动对应；
2. 非功能需求难以在架构中描述：性能、安全、可用性等系统属性很难在架构模型中形成可验证的规约；
3. 一致性与可追溯性难以保障：一条需求可能对应多个架构关注点，一个架构元素也可能支撑多条需求，映射复杂、难追溯。

（可补：④ 迭代/演化开发时需求不完整带来的架构设计困难；⑤ 大规模系统需求数以千计，难以确定与细化相关架构信息。）

第 2 问（5 段含义）：

• 操作系统服务段：为其他段提供操作系统、运行时、操作系统级健康监控（HM）等服务；通过 OSGi 等开放式框架提供 OS 标准接口，支持组件即插即用；
• I/O 服务段：对专用 I/O 设备抽象/虚拟化，屏蔽平台服务与硬件的直接关系（GPU 驱动因与图形服务强相关而不做抽象）；
• 平台服务段：提供跨平台的共性服务（系统级 HM、配置、日志、流媒体等），含平台公共服务、平台设备服务、平台图像服务；
• 传输服务段：为上层可移植组件提供平台性数据交换服务（基于 CORBA/DDS 等中间件），组件间禁止直接调用，须经传输服务；具备 QoS、配置、分布式传输能力；
• 可移植组件段：用户软件段，提供多组件使用能力与功能服务，含公共服务与可移植组件，是跨平台复用的核心载体。

第 3 问：

• 紧耦合表现：I/O 问题、业务逻辑问题、表现问题——应用直接依赖具体硬件接口与协议（ICD 描述的消息/协议被应用硬编码）。
• 解决：采用分离原则，把硬件相关代码隔离到少数模块，减少耦合。
• 封装问题表现：ICD 硬编码、组件紧耦合、直接调用——平台接口控制文件（ICD）被写死进应用，换平台即失效。
• 解决：在计算平台内提供数据源/数据槽（source/sink）软件服务，把平台相关部分移出应用，接口标准化，应用只面向标准服务编程。
• 得分点：两组"表现 + 方案"分开写；关键词 ICD、分离原则、数据源/槽、接口标准化。

试题四：网上社区平台 —— Redis 数据类型 + 持久化 + 淘汰机制（25 分，10+7+8）#

题面要点
功能：(a) 帖子评论计数器；(b) 粉丝列表；(c) 标签管理；(d) 共同好友；(e) 排名（当天最热前 10 帖子、热搜前 5）；(f) 用户信息结构化存储；(g) 好友信息发布/订阅。高并发场景，采用 Redis + 数据库。

问题

1. （10 分）把 (a)—(g) 填入表 4-1 对应的 Redis 数据类型。
2. （7 分）从磁盘更新频率、数据安全、数据一致性、重启性能、数据文件大小五方面比较 RDB 与 AOF，并说明选 RDB 的原因。
3. （8 分）说明"定期删除 + 惰性删除"的失效场景，并给出三种内存淘汰机制。

解题框架

第 1 问（映射表）：

• 得分点：类型 + 理由成对；指出 SET 的"去重 + 集合运算"、ZSET 的"按分值排序"。
• 陷阱：用 LIST 做排行榜（需手工排序）；用 STRING 存用户对象（无法局部更新）。

第 2 问（RDB vs AOF）：

• 选 RDB 的原因：系统要求"7×24 不间断、故障后最短时间重启恢复"→ 重启性能是第一优先级；且缓存数据可重建，允许少量丢失。
• 得分点：五维度逐项对比 + 用"重启性能优先"解释选型。
• 陷阱：只写"RDB 快"不列五维；认为 AOF 一定更好（AOF 恢复慢、文件大）。

第 3 问：

• 失效场景：某个 KEY 已过期，但"定期删除"的随机抽样没抽到它，"惰性删除"又因为再没被访问而未触发 → 该 KEY 长期占用内存；大量此类 KEY 堆积 → 内存使用率持续升高。
• 三种（及以上）淘汰机制（maxmemory-policy）：

1. volatile-lru：从设置了过期时间的键中淘汰最近最少使用的；
2. volatile-ttl：从设置了过期时间的键中淘汰将要过期的；
3. volatile-random：从设置了过期时间的键中随机淘汰；
4. allkeys-lru：从所有键中淘汰最近最少使用的；
5. allkeys-random：从所有键中随机淘汰；
6. noeviction：不淘汰，写入报错（默认）。

• 得分点：失效场景要讲清"定期没抽到 + 惰性没访问"两个条件同时成立。

试题五：工业设备监测系统 —— 非功能需求分类 + SSM 架构 + 标准数据访问（25 分，6+14+5）#

题面要点
功能：现场设备状态采集、数据传输、监测显示、设备信息管理。非功能需求：(a) 支持 >100 个设备并行监测；(b) 现场到后台传输时间 < 1s；(c) 7×24 工作；(d) 抵御常见 XSS 攻击；(e) 故障情况下 0.5 小时内恢复；(f) 支持数据审计。采用三层拓扑：现场采集层、Web 监测服务层、前端显示层，服务层用 SSM（Spring + SpringMVC + MyBatis）。

问题

1. （6 分）按性能、安全性、可用性分类填入 (a)—(f)。
2. （14 分）从 (a)—(k) 中选择补全 SSM 工作流程图。
3. （5 分）说明采用标准数据访问机制的原因。

解题框架

第 1 问：

• 性能：(a) 100 设备并行、(b) 传输 < 1s；
• 安全性：(d) 抗 XSS、(f) 数据审计；
• 可用性：(c) 7×24、(e) 0.5 小时恢复。
• 得分点：(a)(b) 是"容量/时延"→性能；(d)(f) 是"防护/审计"→安全性；(c)(e) 是"持续服务/恢复"→可用性。
• 陷阱：把"数据审计"当性能或可用性（审计属安全）。

第 2 问（SSM 流程，7 空）：

• 请求链路：浏览器 →（Controller Layer）→（Spring）→（Service/业务）→（Persistent Layer）→（MyBatis）→（Connection Pool）→ 数据库 →（View Layer）→（JSP）。
• 按来源答案对应：(1) Connection Pool(a)；(2) Persistent Layer(c)；(3) MyBatis(d)；(4) Spring(k)；(5) Controller Layer(j)；(6) View Layer(h)；(7) JSP(i)。
• 未使用的干扰项：Struts2(b)（SSM 用 SpringMVC 不用 Struts2）、HTTP(e)（协议，非组件）、MVC(f)（模式名，非具体层）、Kafka(g)（消息队列，图中无）。
• 得分点：把"SpringMVC 负责请求转发与视图、Spring 管理业务对象、MyBatis 做持久化"三句说清；干扰项要能说出"为什么不用"。

第 3 问：

• 原因：标准数据访问机制（如 OPC）在硬件供应商与软件开发商之间建立统一规则，使数据交互对双方透明：硬件厂商只需按标准提供服务，软件方无需了解硬件实质与操作过程 → 屏蔽设备差异、降低耦合、便于扩展多种设备、降低开发与维护成本。
• 得分点：透明性、解耦、可扩展、统一管理四个词。

五、论文（4 选 1）#

本卷论文附官方写作要点，是复习论文的最佳样本。以下保留要点并补充结构。

试题一：论数据分片技术及其应用#

三问：①项目背景与本人工作；②Hash 分片、一致性 Hash 分片、按数据范围分片的原理；③项目中采用了哪些分片方式、实现过程与应用效果。

要点（来源）

• Hash 分片：按数据某一特征 key 计算哈希值，与节点建立映射，不同哈希值分布到不同节点。优点：映射简单、元数据极少（只需记录节点数与 Hash 函数）。缺点：增删节点导致大量数据迁移；难以解决数据倾斜（特征值分布不均、单条记录变大）。
• 一致性 Hash：数据与节点都映射到首尾相接的 Hash 环，数据从其环上位置顺时针找到第一个节点即为存储节点。元数据只多出"节点在环上的位置"；增删节点只影响相邻区间，不会大规模迁移（可配虚拟节点解决倾斜）。
• 按数据范围（Range Based）：按关键值划成区间，每个物理节点负责一个或多个区间；区间大小不固定，以数据量为划分标准；工程上一个节点负责多个"块"，块达阈值即分裂，便于新节点加入后快速均衡。
• 写作补充：项目中可写"用户表按 user_id 取模分库 + 订单表按时间范围分表 + 一致性 Hash 做缓存节点定位"，并给效果（如"单表 2 亿降至 2000 万，查询 P99 从 1.2s 降到 80ms"）。

试题二：论云原生架构及其应用#

三问：①项目与本人工作；②服务化、弹性、可观测性、自动化四类设计原则的内涵；③项目如何转向云原生、遇到什么问题如何解决。

要点（来源）

• 服务化：代码规模超出小团队协作范围时拆分（微服务/小服务），按不同生命周期分离模块、独立迭代，避免慢模块拖慢整体；面向接口编程、功能高内聚，提取公共模块提升复用。
• 弹性：部署规模随业务自动伸缩，无需按峰值做固定容量规划，提高资源利用率、降低成本。
• 可观测：通过日志、链路追踪、度量，使每次请求背后的多次服务调用（耗时、返回值、参数）清晰可见，可下钻到三方调用、SQL、节点拓扑、网络响应，支撑关联分析与持续优化。
• 自动化：以标准化交付流程为基础，用配置数据"描述"并面向终态交付，让工具理解目标与环境差异，实现交付与运维自动化。
• 写作补充：落地技术栈（容器 + K8s + 服务网格 + 声明式 API + 不可变基础设施）；问题可写"弹性伸缩引发冷启动/雪崩 → 预热 + 限流"、"可观测数据量爆炸 → 采样 + 分级存储"。
• 注意：官方要点把"韧性"也列为原则（提升 MTBF、抵御硬件故障/流量超限/攻击），答题时可写"服务化、弹性、可观测、自动化、韧性"五点更稳。

试题三：论软件测试中缺陷管理及其应用#

三问：①项目与本人工作；②常见缺陷种类与级别、缺陷管理基本流程；③项目中的缺陷管理实施过程与效果。

要点（来源）

• 缺陷种类（IEEE）：输入/输出错误、逻辑错误、计算错误、接口错误、数据错误；按测试角度分五类：功能缺陷、系统缺陷、加工缺陷、数据缺陷、代码缺陷（不同企业分类不同）。
• 缺陷级别：按后果严重程度分级，如 Beizer 十级（轻微、中等、使人不悦、影响使用、严重、非常严重、极为严重、无法容忍、灾难性、传染性）；工程上常用 致命/严重/一般/轻微/建议 五级。
• 管理目标：保证信息一致、缺陷有效跟踪、缩短沟通时间、收集数据作为缺陷度量依据。
• 基本流程：缺陷提交 → 缺陷审查（定问题、种类、级别）→ 修复流程（分派开发）→ 验证流程（回归测试验证）→ 缺陷关闭（部分流程含状态跟踪）。
• 写作补充：度量指标（缺陷密度、缺陷检出率、重开率、平均修复时长 MTTR、遗留缺陷数）；工具（Jira/ZenTao）；效果量化。

试题四：论企业集成架构设计及应用#

三问：①项目与本人工作；②数据集成、应用集成、企业集成三类技术分别解决什么问题、含义、各含哪些集成模式；③项目采用了哪些、效果如何。

要点（来源）

1. 数据集成：解决不同应用/系统间的数据共享与交换。含三部分：共享信息管理（统一集成服务模型与共享信息访问机制，做共享、分发、存储）、共享模型管理（数据资源配置、集成资源关系、资源生命周期、业务数据协同监控）、数据操作管理（多通道异构模型间的数据转换、映射、传递与操作）。

• 模式：数据联邦、数据复制、基于结构的数据集成。

2. 应用集成：两个或多个应用按业务逻辑需要进行功能互调用与互操作，建立在数据集成之上，实现应用层互操作。

• 模式：集成适配器、集成信使、集成面板、集成代理。

3. 企业集成：企业应用从功能逻辑分表示、业务逻辑、数据三层；集成平台多采用多层结构以提高柔性，并按功能通用程度对实现模块分层。

• 模式：前端集成、后端集成、混合集成。
• 写作补充：技术演进"点对点 → ESB 总线 → 微服务 + API 网关 → 事件驱动"；效果写"接口数量从 N² 降到 N、集成上线周期缩短"。

六、使用建议#

1. 本卷综合知识 + 案例 + 论文三部分皆有答案或要点，是历年套卷中资料最完整的一份，建议作为第一套模考卷。
2. 高频送分点：Spooling 与缓冲的区别、位示图计算、页式地址变换、段页式、候选键推导、位置透明、分层架构脆弱性、系统性文档分类、需求基线、软件设计四活动、信息隐蔽、中间件三功能、螺旋模型、敏捷、脚本技术、4+1 视图、敏感点/权衡点、三层 C/S、设计模式分类、质量属性场景、SYN Flooding、Kerberos、著作权保护期、盈亏平衡点、蒙特卡洛。
3. 案例一与 2021 下必做题同型（效用树 + 风格对比），两卷对照可掌握"数据处理方式/可扩展性/性能"三栏对比模板。
4. 案例四（Redis 数据类型 + 持久化 + 淘汰）与 2021 下案例三（反规范化 + 缓存）构成"缓存专题"，建议合并复习。
5. 论文四题（数据分片、云原生、缺陷管理、企业集成架构）覆盖"数据/新型架构/测试/集成"四类素材，优先背数据分片三种方式与云原生四原则（定义式内容，最容易考）。

七、来源#

说明：

1. 第 6 题选项在公开源中为空、第 13 题答案存在学理争议，均已标存疑，不作为背诵依据。
2. 试题一效用树依赖原图骨架，本卷给出"属性 → 需求编号"对照，原图未保留处标〔图缺失〕。
3. 论文部分为来源的写作要点摘录 + 结构补充，非逐字范文。