试题一 面向对象需求分析

问题1（6分）

列举六种需求获取技术，并进行简要说明。

答案要点：

需求获取技术	简要说明
问卷调查	通过问卷向大量涉众收集需求，成本低、易量化，适合初步摸底与优先级统计。
访谈	与用户、专家一对一或小组面谈，深入挖掘动机与约束，适合关键干系人。
现场观摩	到用户工作现场观察实际操作，发现未说出的需求和隐性规则。
联合需求开发（JRD）/联合应用设计（JAD）	集中关键干系人在主持下讨论、确认需求，缩短周期、减少理解偏差。
历史文档与资料整理	从现有制度、手册、旧系统文档中提取需求，作为补充和校验依据。
抽样调查	在用户群体中抽样发放问卷或访谈，用统计方法推断整体需求。

教材中还可写：情节串联板（故事板）、参加实践（跟班作业）等，任选六种即可。

---

问题2（10分）

根据用例图和顺序图，补充填空：用例描述、参与者、处理过程、前置条件和成功条件。

答案要点：

• 用例描述：对用例的名称、目标、范围、主要参与者的文字说明，是填空的总体对象。

• 参与者：与系统交互的角色（人、外部系统），在用例图中与用例相连。

• 处理过程（事件流/基本流）：主成功场景下参与者与系统的交互步骤，顺序图描述的就是该流程。

• 前置条件：执行用例前系统与外界必须满足的条件（如用户已登录、数据已就绪）。

• 成功条件（后置条件）：用例正常结束时系统应达到的状态或产出（如“订单已生成并持久化”）。

从题目给出的用例图、顺序图中对应摘取或概括上述五项填入即可。

---

问题3（9分）

三种设计类对象分别是什么，并进行简要说明。

答案要点：

类型	说明
边界类（Boundary）	位于系统与外界交界，负责与参与者交互（如界面、接口适配）。
控制类（Control）	协调用例中的业务逻辑与流程，协调实体与边界，常一个用例一个控制类。
实体类（Entity）	表示业务领域中的核心概念与持久化数据，对应领域对象和数据库表。

三者关系：参与者 ↔ 边界类 ↔ 控制类 ↔ 实体类，符合 MVC 及“用例—分析类”划分。

---

试题二 Web 应用开发

问题

分析 HTTP 和 WebSocket 连接的异同。

答案要点：

维度	HTTP	WebSocket
连接方式	请求—响应、短连接（或 Keep-Alive 复用）	一次握手后保持长连接、全双工
发起方向	通常由客户端发起请求	握手由客户端发起，建立后双方均可主动发数据
数据形式	文本协议（请求行/头/体）	建立后以帧形式传输文本或二进制
典型用途	页面请求、REST API	实时推送、即时通讯、实时监控
相同点	均基于 TCP；均可加密（HTTPS/WSS）；均可在浏览器中使用

---

试题三 结构化分析（停车场智能管理）

问题1

针对 10 个需求描述，通过代码编号填写至功能需求、非功能需求和设计约束。

答案要点：

功能需求对应“做什么”（如进出识别、计费、报表）；非功能需求对应“做到什么程度”（性能、可用性、安全等）；设计约束对应“必须遵守的限定”（技术选型、标准、合规）。按每条需求的语义归类填代码即可。

---

问题2

根据需求描述补充数据流图顶层图（实体与数据流）；判定表是什么、简要描述；10 个需求中哪个适合判定表。

答案要点：

• 顶层图：识别外部实体（如车主、管理人员、道闸等）、系统（停车场智能管理系统）、数据流（如车牌图像、进出记录、缴费请求等）。

• 判定表：用条件与动作的矩阵表示复杂业务规则，每一列对应一条规则（条件组合+执行动作），适合条件多、组合多的决策逻辑。

• 适合判定表的需求：条件清晰、分支多、组合复杂的需求（如“根据车型、时段、会员等级计算停车费”）。

---

问题3

说明设计数据流图需要遵循的基本原则有哪些。

答案要点：

• 数据流只能由数据存储、外部实体或处理逻辑产生，且必须流入处理逻辑、数据存储或外部实体；不能从外部实体直接到外部实体等。

• 处理逻辑至少有一个输入流和一个输出流。

• 数据存储与外部实体之间不能直接有数据流，须经处理逻辑。

• 分层平衡：父图与子图输入输出一致，编号一致。

• 命名清晰：数据流、处理、实体、存储的命名应具有业务含义，便于理解与审查。

---

试题四 数据库（系统分析与建模·结构化）

问题1（9分）

(1) 请说明每个关系模式满足的范式。

答题方法（教材通用）：

• 1NF：属性不可再分，每列是原子值。

• 2NF：在 1NF 基础上，非主属性完全依赖于候选键（无部分依赖）。

• 3NF：在 2NF 基础上，非主属性不传递依赖于候选键。

• BCNF：每个决定因素都是候选键（即不存在“非候选键决定其他属性”）。

对题目给出的每个关系模式：先写出函数依赖，求候选键，再按上述顺序判断最高满足到哪一范式。

示例：若 R(员工ID, 部门ID, 部门名)，FD 为 {员工ID→部门ID, 部门ID→部门名}，候选键为 员工ID，则存在“部门ID→部门名”且 部门ID 不是候选键，不满足 BCNF；非主属性 部门名 传递依赖于 员工ID，故满足 3NF。可写为：“R 满足 3NF，不满足 BCNF。”

考试时对“五个关系模式”逐个按此步骤写结论即可。

---

(2) 请对不满足 BCNF 的关系模式进行规范化，给出满足 BCNF 的关系模式。

BCNF 分解步骤（教材常用）：

1. 写出最小函数依赖集与候选键。

1. 找出违反 BCNF 的 FD：X→A，其中 X 不是候选键，A∉X。

1. 分解为：R1 = X∪{A}，R2 = R−{A}（或 R2 = 属性集−A，且保留 R 的键以保证无损）。

1. 对 R1、R2 分别再求 FD 与候选键，若仍不满足 BCNF 则继续分解，直到全部满足。

示例：

R(员工ID, 部门ID, 部门名)，FD：员工ID→部门ID，部门ID→部门名。

违反 BCNF：部门ID→部门名，部门ID 不是候选键。

分解：R1(部门ID, 部门名)，R2(员工ID, 部门ID)。R1、R2 的决定因素均为候选键，满足 BCNF。

考试时对每个不满足 BCNF 的模式按上述步骤写出分解后的关系模式即可。

---

问题2（8分）

(1)(2) 请在 (1)、(2) 空白处补充完善该 SQL 语句。

题干中通常会给出表名和查询意图（如“查询满足项目技能需求的员工姓名及技能水平”）。常见形式为：

• (1) 多出现在 SELECT 子句，多为需要查询的列名或表达式（如 员工姓名、t1.姓名 等）。

• (2) 多出现在 FROM/JOIN 子句，多为表名或表别名（如 员工技能表、员工技能表 t3 等）。

示例（与前面“员工—项目—技能”场景一致）：

SELECT 项目名称, (1) 员工姓名, 技能ID, 技能水平

FROM 员工表 t1, 项目表 t2, (2) 员工技能表 t3, 项目技能需求表 t4

WHERE t3.员工ID = t1.员工ID AND t4.项目ID = t2.项目ID

  AND t3.技能水平 >= t4.需求水平 AND t3.技能ID = t4.技能ID

(1) = 员工姓名（或 t1.姓名）；(2) = 员工技能表。考试时按试卷表名与字段名填写。

---

(3) 张工认为该 SQL 语句频繁执行导致频繁关联操作，建议采用反规范化方法解决。李工认为张工方案存在缺点。请给出张工解决方案的基本思路、说明其缺点，并给出解决该缺点的方法。

张工方案的基本思路：

通过反规范化减少多表连接：将经常一起查询的列冗余到一张表或少量表中（如把“项目名称、员工姓名、技能水平、需求水平”等冗余到一张“项目—员工—技能”汇总表），或增加冗余列、派生列、汇总表。查询时只需扫描单表或少量表，用空间换时间，降低频繁 JOIN 带来的开销。

反规范化的缺点：

• 数据不一致：同一信息多处存储，更新时若未同步会导致不一致。

• 存储增加：冗余占用更多空间。

• 更新复杂：插入、更新、删除需维护多处，事务更长、逻辑更复杂，易遗漏。

解决该缺点的方法：

• 触发器：在基表上设置 AFTER INSERT/UPDATE/DELETE 触发器，在事务内自动维护冗余或汇总表，保证实时一致；但逻辑隐蔽、与 DBMS 绑定、高并发下可能成为瓶颈。

• 应用层维护：在同一事务中先更新基表再更新冗余/汇总表，由应用保证一致性；便于测试和移植，但易遗漏、需严格规范。

• 定期批处理：基表按需更新，冗余/汇总表通过定时任务或存储过程批量刷新；适用于对实时性要求不高的场景，可避免触发器与长事务的问题。

---

问题3（8分）

(1) 请说明李工的触发器方案中，两个触发器应该采用什么类型的触发器？

答案要点：

若李工用触发器维护“关系表”一致（如基表与冗余表/汇总表同步），通常需要在发生数据变更的表上，在数据已写入之后再去更新其他表，因此两个触发器一般均为 AFTER 触发器，具体类型取决于业务：

• 表 A（如订单明细、员工技能表）：在插入、更新、删除后需同步到汇总表 → 采用 AFTER INSERT、AFTER UPDATE、AFTER DELETE（或根据题目只涉及“新增与修改”则用 AFTER INSERT、AFTER UPDATE）。

• 表 B（如另一张关联表或汇总表所依赖的基表）：同样在变更后同步 → 采用 AFTER INSERT、AFTER UPDATE、AFTER DELETE（或按题目要求取其中几种）。

常见答法：“两个触发器均采用 AFTER 触发器：一个在 XX 表上使用 AFTER INSERT 与 AFTER UPDATE（及必要时 AFTER DELETE），另一个在 YY 表上使用 AFTER INSERT 与 AFTER UPDATE（及必要时 AFTER DELETE），用于在数据变更后自动维护关联表或冗余数据。” 考试时按题目中“两个表”的名称和操作类型写具体表名与事件即可。

---

(2) 请说明李工方案的缺点，并给出不采用触发器方案的基本思路。

李工（触发器）方案的缺点：

• 逻辑隐蔽：业务规则藏在数据库中，应用开发者难以察觉，调试和排错困难。

• 与 DBMS 耦合：语法与行为依赖具体数据库，迁移、换库成本高。

• 性能与扩展：触发器在事务内执行，复杂逻辑会拉长事务、占锁，高并发下易成瓶颈；多表多触发器时执行顺序难控，易产生意外级联。

• 可测试性与版本管理：不如应用代码便于单测、代码评审和版本控制。

不采用触发器方案的基本思路：

• 应用层维护：在业务代码的同一事务中，先更新主表/基表，再更新从表/冗余表/汇总表，由应用保证原子性与一致性。

• 存储过程：将“更新基表 + 维护关联表”封装成存储过程，由应用调用；逻辑仍在库内但集中、可控，便于保证顺序与一致性。

• 异步维护：基表更新后发消息到消息队列，由独立服务消费并更新汇总/冗余表，实现最终一致性，适合对实时性要求不极端的场景。

• 物化视图/汇总表 + 定时刷新：若允许短暂延迟，可用定时任务或数据库自带刷新机制更新派生数据，避免触发器与长事务。

---

试题五 嵌入式

问题1（10分）

描述中间件的定义和特点，并列举 4 类，举例 Kafka、Apache、Redis、SOAP。

答案要点：

• 定义：中间件是位于 OS、网络与应用程序之间的软件层，为分布式或复杂系统提供通用服务（通信、数据访问、消息、事务等），使应用专注业务逻辑，屏蔽异构与重复开发。

• 特点：屏蔽异构、复用与标准化、解耦、支持分布式。

• 四类及举例：

• 消息/消息队列中间件 → Kafka；

• Web/应用服务器中间件 → Apache（如 Tomcat）；

• 缓存/数据中间件 → Redis；

• 面向服务/集成中间件 → SOAP。

---

问题2（8分）

选择通信中间件而不选择实时操作系统的 8 个理由。

答案要点（8 条）：

1. 更侧重通信与集成，中间件提供现成消息、协议、服务发现。
2. 跨平台与标准化，易与多种 OS、硬件对接。
3. 降低开发复杂度，封装连接、重试、序列化等。
4. 易与现有企业/云系统对接。
5. 功能丰富（管理、监控、安全、集群）。
6. 团队与生态成熟，文档与案例多。
7. 实时性非首要时，通信中间件更合适。
8. 引入成熟中间件可缩短周期、降低成本。

---

问题3（7分）

三种服务发现、通信机制的原理。

答案要点：

1. 集中式注册中心（如 Consul、Nacos）：服务注册地址与元数据，调用方查询得到实例列表再直连通信。
2. 基于 DNS 的服务发现：通过域名解析得到实例地址列表，再选实例直连。
3. 基于消息总线/发布订阅：服务通过 Topic 发布/订阅，由中间件路由与投递，发现体现为“谁订阅哪个 Topic”或服务与 Topic 的映射。

相关推荐

软件需求工程的软件需求概述、需求获取、需求分析https://shuaici.blog.csdn.net/article/details/155570041数据库系统-数据库管理系统&关系数据库&非关系型数据库https://shuaici.blog.csdn.net/article/details/1496765622024年11月案例真题及参考答案（回忆版本）https://shuaici.blog.csdn.net/article/details/158430468