✍️ 第五章：高分期末大题特训与详解#

🎯 题型一：分析模型设计（Use Case + Use Case Specification + SSD）#

📝 题目背景#

某共享电动车租用系统中，用户扫码开锁时，系统必须强制进行押金余额校验。如果用户信用分大于 700 分，则可选择性触发免押金骑行（免除校验）。成功开锁骑行后，若用户已开启“骑行意外险自动续保”，系统将自动完成保单生成（包含用例）。请完成：

绘制用例图。

为“扫码租车”写一份关键用例规约。

绘制该场景的系统顺序图（SSD）。

💡 详尽步骤解析#

第一步：绘制用例图#

参与者（Actor）：用户
主用例：扫码租车
被包含用例（<<include>>）：押金余额校验、自动生成保单（根据题干，保单生成是“必须执行”的步骤）。
扩展用例（<<extend>>）：免押金骑行（触发条件：信用分 > 700）。

Rendering diagram...

第二步：编写用例规约#

规约项	详细内容说明
用例名称	扫码租车
主要参与者	用户
前置条件	用户已登录系统，且系统处于就绪状态。
主要流程（Basic Flow）	1. 用户扫描车辆上的二维码。 2. 系统读取车辆编码并上传。 3. 系统触发 [包含：押金余额校验] 流程，验证用户押金充足。 4. 系统向电锁发送指令，成功开锁。 5. 系统触发 [包含：自动生成保单] 流程。 6. 系统开始计费并提示用户开始骑行。
扩展流程（Alternative）	3a. 信用分免押金（`<<extend>>`）：如果用户信用分 > 700，则跳过押金余额校验，直接进入步骤4。
后置条件	车辆电锁已开启，系统生成预约订单并开始计费。

NOTE
深度解析：为什么带有“若…”的条件分支，还能画成 <<include>>？
仔细看题干：“若用户已开启‘骑行意外险自动续保’，系统将自动完成保单生成（包含用例）。” 很多同学的第一直觉是：既然有“若”（If）这个前置条件，为什么不是画成 <<extend>>（条件触发），而是强制要求画成 <<include>>？
这涉及到了系统设计中业务逻辑封装（高内聚、低耦合）的架构思想：

如果画成 <<extend>>：代表由“扫码租车”主流程来判断用户是否开启了保险。这会让主流程耦合太多复杂的保险前置逻辑。

画成 <<include>> 的真实含义：对于主流程而言，“把骑行事件推送给保险处理模块”是每一单 100% 必须强制执行 的。主流程无条件调用“生成保单”子用例。至于“若用户已开启”这个判断条件，其实是被封装在了“生成保单”子用例的内部逻辑中（即子用例的第一步先查用户配置，没开启就直接结束退出，开启了才继续生成保单）。

总结：主用例无条件（Include）抛出任务，子模块内部自己处理“若…”的条件判断。这是 UML 建模中为了解耦业务模块 of 经典高分画法。

第三步：绘制系统顺序图（SSD）#

要点：必须把系统视为一个整体黑盒。

Rendering diagram...

🎯 题型二：面向对象详细设计（GRASP 推导 + DCD）#

📝 题目背景#

某预约宠物服务系统中，用户可通过页面进行“宠物预约挂号”。系统操作如下： inquirePetServices(serviceType)：查询服务详情。 makeAppointment(userId, serviceId, time)：确认创建预约。请应用 GRASP 设计原则，分析并推导创建预约订单（Appointment 实体）的职责归属，画出完整的设计类图（DCD）。

💡 详尽步骤解析#

第一步：职责分配推导过程（以 GRASP 原则进行推理论述）#

确定创建者（Creator）：
- 我们需要决定谁来实例化 Appointment。
- 系统业务逻辑由 AppointmentServiceImpl（业务实现类）控制，它接收了创建预约所需的一切输入数据（userId, serviceId, time），且需要将生成的 Appointment 实例传给 AppointmentRepository 进行持久化。
- 因此，根据 GRASP 创建者模式，应将创建 Appointment 实例的职责分配给 AppointmentServiceImpl。
降低耦合度（Low Coupling）：
- AppointmentController 不应直接去 new 实体类或直接操作数据库，而应仅依赖业务层抽象接口 AppointmentService，从而将表现层与业务处理解耦。
信息专家（Information Expert）：
- 如果需要验证用户是否有冲突的预约，该校验职责应分配给 AppointmentRepository，因为其作为数据访问专家，完整持有着该用户在数据库中的所有预约详情记录。

第二步：绘制设计类图（DCD）#

注意要点：方法、属性可见性，带空心三角的实线箭头表示接口实现（Realization），带箭头的实线表示依赖（Dependency）。

Rendering diagram...

🎯 题型三：微服务及分布式软件架构设计方案#

📝 题目背景#

某大型全国连锁银行的在线支付交易系统，每日面临数千万级别的支付结算请求。为了支持多元化的支付场景，系统支持微信支付渠道（WeChatPay）与支付宝支付渠道（AliPay）。支付路由计算模块同样支持最快路由选择算法 and 最低费率通道选择算法。为了支撑高并发交易、保障系统的高可用、可扩展与低耦合，请结合提供的课件架构知识：

利用策略模式（Strategy Pattern），画出支付通道选择模块的设计类图。

为该系统设计一个微服务分布式拓扑结构图。

详细设计交易流程中，系统运行日志与操作审计日志的具体逻辑架构及存储结构设计。

💡 详尽步骤解析#

第一步：支付通道选择模块策略模式类图设计#

要点：通过策略模式，在运行时动态切换“微信支付”与“支付宝支付”渠道，彻底满足开闭原则（OCP） [PDF 1]。

Rendering diagram...

第二步：微服务分布式拓扑结构图#

要点：微服务拓扑图应完整展示客户端、网关、服务注册中心、各领域微服务和隔离数据库层 [PDF 3]。

Rendering diagram...

第三步：运行日志与操作审计日志存储方案设计 [PDF 1]#

1. 系统运行日志（Running Log）结构设计#

存储引擎：Elasticsearch（分布式近实时搜索引擎），适合海量半结构化日志查询。
文档结构定义：

日志字段	类型	说明
`timestamp`	Date	日志记录的精确时间戳（UTC）
`level`	String	日志级别（INFO / WARN / ERROR / DEBUG）
`traceId`	String	分布式全链路追踪 ID（串联整个分布式调用栈）
`serviceName`	String	当前抛出日志的微服务名称
`thread`	String	执行当前业务的系统线程名称
`message`	String	精简的业务异常/运行信息描述
`stackTrace`	String	出现异常时记录的详细错误堆栈（可选）
`context`	Object	当前调用参数上下文（如 `paymentChannel`, `merchantId` 等）

2. 操作审计日志（Audit Log）物理表设计#

存储引擎：MySQL 等关系型数据库，要求 ACID 强一致性，不允许任意丢失审计记录。
关系表字段设计：

物理字段名	数据类型	约束条件	业务字段含义说明
`audit_id`	BIGINT	PRIMARY KEY, AUTO_INCREMENT	审计流水号主键
`user_id`	BIGINT	NOT NULL	执行敏感操作的用户唯一 ID
`username`	VARCHAR(50)	NOT NULL	操作人用户名（便于列表直观检索）
`operation_desc`	VARCHAR(100)	NOT NULL	业务操作描述（如：执行跨行敏感大额转账）
`api_path`	VARCHAR(255)	NOT NULL	请求的后台 API 接口路由路径
`client_ip`	VARCHAR(45)	NOT NULL	发起请求的客户端 IP 地址（支持 IPv6）
`execution_status`	VARCHAR(10)	NOT NULL	执行状态（SUCCESS / FAILED）
`error_msg`	TEXT	DEFAULT NULL	失败时记录的精简业务异常信息
`cost_time`	INT	NOT NULL	此次操作的执行处理耗时（毫秒数）
`create_time`	TIMESTAMP	DEFAULT CURRENT_TIMESTAMP	日志记录生成的客观物理时间