案例分析

试题一

阅读以下关于 Web 系统架构设计的叙述,在答题纸上回答问题1至问题3。

【说明】

某公司拟开发一套基于边缘计算的智能门禁系统,用于如园区、新零售、工业现场等存在来访、被访业务的场景。来访者在来访前,可以通过线上提前预约的方式将自己的个人信息记录在后台,被访者在系统中通过此请求后,来访者在到访时可以直接通过“刷脸”的方式通过门禁,无需做其他验证。此外,系统的管理员可对正在运行的门禁设备进行管理。 基于项目需求,该公司组建项目组,召开了项目讨论会。会上,张工根据业务需求并结合边缘计算的思想,提出本系统可由访客注册模块、模型训练模块、端侧识别模块与设备调度平台模块等四项功能组成。李工从技术层面提出该系统可使用 Flask 框架与 SSM 框架为基础来开发后台服务器,将开发好的系统通过 Docker 进行部署,并使用 MQTT 协议对 Docker 进行管理。

【问题1】(5分)

MQTT 协议在工业物联网中得到广泛的应用,请用300字以内的文字简要说明 MQTT 协议。

答案：

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输协议）是一种基于发布/订阅模式的轻量级物联网消息传输协议，工作在 TCP/IP 之上，由 IBM 于 1999 年发布，现为 OASIS 标准。

核心特点：

1. 发布/订阅模式：通过 Broker（代理）解耦生产者与消费者，支持一对多消息分发；
2. 轻量级：最小报文仅 2 字节头部，开销极小，适合窄带、嵌入式设备；
3. 三种 QoS 等级：QoS 0（至多一次）、QoS 1（至少一次）、QoS 2（恰好一次），按业务可靠性需求选择；
4. 基于主题（Topic）路由：订阅者按通配符（+/#）订阅感兴趣的主题；
5. 心跳与遗嘱机制：Keep Alive 检测连接活性，Last Will 在异常断连时通知订阅者。

应用场景：工业物联网、远程监控、智能家居、设备状态上报等低带宽、不稳定网络环境。

💡 延伸学习：MQTT vs HTTP 在 IoT 场景的对比

维度	MQTT	HTTP
模式	发布/订阅（双向推送）	请求/响应（客户端拉取）
报文头	最小 2 字节	数百字节（含 Header/Cookie 等）
长连接	天然长连接（Keep Alive）	默认短连接，每次都要建/拆 TCP
实时性	服务器可主动推送	需轮询或 WebSocket 改造
适用场景	设备状态上报、指令下发、控制消息	用户端 Web/小程序请求、查询类操作

📌 MQTT 的"灵魂"——为什么 IoT 都用它

• 省电：嵌入式设备可长期休眠，被推送唤醒（HTTP 只能轮询）
• 省带宽：弱网/卫星网络下也能用
• 解耦：新增订阅者不改生产者，适合云边协同、千万级设备管理
• 弱网友好：QoS + 离线消息 + 持久化会话，断网恢复不丢关键指令

🎯 面试常考点：为什么智能门禁场景用 MQTT 管设备（控制指令 + 状态上报），而用户刷脸/管理后台用 HTTP（请求-响应）——这正是本题图 5-1 (1)~(6) 协议选型的核心判据

【问题2】(14分)

在会议上,张工对功能模块进行了更进一步的说明:访客注册模块用于来访者提交申请与被访者确认申请,主要处理提交来访申请、来访申请审核业务,同时保存访客数据,为训练模块准备训练数据集;模型训练模块用于使用访客数据进行模型训练,为端侧设备的识别业务提供模型基础,端侧识别模块在边缘门禁设备上运行,使用训练好的模型来识别来访人员,与云端服务协作完成访客来访的完整业务;设备调度平台模块用于对边缘门禁设备进行管理,管理人员能够使用平台对边缘设备进行调度管理与状态监控,实现云端协同。

图 5-1 给出了基于边缘计算的智能门禁系统架构图,请结合 HTTP 协议和 MQTT 协议的特点,为图 5-1中(1) ~ (6)处选择合适的协议;并结合张工关于功能模块的描述,补充完善图 5-1中(7) ~ (10)处的空白。

答案：

(1) ~ (6) 协议选择：

(7) ~ (10) 模块名：

💡 延伸学习：协议选型的通用判据

HTTP 适合的场景（请求-响应、用户端、无状态查询）：

• 用户端 Web / 小程序 / App 与后端
• 局域网内服务调用
• 一次性查询、操作

MQTT 适合的场景（发布-订阅、设备端、长连接推送）：

• 设备状态上报、心跳、控制指令下发
• 云边 / 边边消息总线
• 弱网、低带宽、高延迟网络
• 一对多广播（一个事件多个订阅者）

📌 IoT 架构的"3 个 MQTT 高频出现位置"

1. 设备 ↔ 云平台：状态 / 指令（本题 (2)(4)）
2. 云平台 ↔ 应用：事件驱动（订单事件触发后续业务）
3. 设备 ↔ 设备：M2M 通信（车联网 V2X、智能家居联动）

🎯 避坑点：云平台内部模块间通信（本图 (6)）通常仍用 HTTP/REST，除非业务是事件驱动（用消息队列或 MQTT）。不要一看"通信"就选 MQTT，要看语义是请求-响应还是事件广播

【问题3】(6分)

请用 300字以内的文字,从数据通信、数据安全和系统性能等方面简要分析在传统云计算模型中引入边缘计算模型的优势。

答案：

在传统云计算模型中引入边缘计算模型，可从数据通信、数据安全、系统性能三方面获得显著优势：

1. 数据通信：传统云计算需将所有原始数据上传至远端云中心处理，链路长、带宽压力大；边缘计算在数据源侧就近完成识别、推理与预处理，减少广域网数据传输量，降低链路故障影响，提升通信效率。

2. 数据安全：人脸图像等敏感原始数据在边缘侧就地处理，仅特征值或脱敏结果上传云端，减少敏感数据在公网传输的暴露面；同时边缘节点分散部署，单点被入侵的影响范围小、隔离性强。

3. 系统性能：将计算任务（人脸识别、推理）下沉到边缘，降低云中心负载与端到端响应时延（刷脸开门需毫秒级响应）；边缘节点具备自治能力，断网时仍可独立运行，提升系统整体可用性与可扩展性。

💡 延伸学习：边缘计算 vs 云计算的"四象限"分工

维度	云计算（中心）	边缘计算（端侧）
算力位置	远端数据中心，资源池化	数据源侧，资源受限
典型任务	模型训练、大数据分析、长期存储	实时推理、预处理、即时响应
数据流向	数据上行（汇聚到云）	数据本地化（特征提取后选择性上传）
时延	几十~数百毫秒（受网络影响）	毫秒级（局域网内）

📌 “云边端"协同的三层架构

• 云（Cloud）：训练、全局决策、长期存储
• 边（Edge）：推理、预处理、协议转换、本地自治
• 端（Device）：采集、执行（摄像头/传感器/门禁设备）

🎯 典型场景对照

• 智能门禁：云训练 → 边推理（端侧识别）→ 端采集（摄像头）
• 自动驾驶：云训练模型 → 车端（边）实时推理 → 传感器（端）采集
• 工业质检：云分析良率 → 产线 PLC（边）做实时控制 → 相机（端）抓拍

🛑 误区警示：边缘计算不是“小型云计算”。边缘节点资源有限、异构化严重，不能把云原生架构直接下沉；需要专门优化（模型量化、剪枝、推理框架适配）

试题二

阅读以下关于数据库缓存的叙述,在答题纸上回答问题1至问题3。

【说明】

某大型电商平台建立了一个在线 B2B 商店系统,并在全国多地建设了货物仓储中心,通过提前备货的方式来提高货物的运送效率。但是在运营过程中,发现会出现很多跨仓储中心调货从而延误货物运送的情况。为此,该企业计划新建立一个全国仓储货物管理系统,在实现仓储中心常规管理功能之外,通过对在线 B2B 商店系统中订单信息进行及时的分析和挖掘,并通过大数据分析预测各地仓储中心中各类货物的配置数量,从而提高运送效率,降低成本。当用户通过在线 B2B 商店系统选购货物时,全国仓储货物管理系统会通过该用户所在地址、商品类别以及仓储中心的货物信息和地址,实时为用户订单反馈货物起运地(某仓储中心)并预测送达时间。反馈送达时间的响应时间应小于1秒。为满足反馈送达时间功能的性能要求,设计团队建议在全国仓储货物管理系统中采用数据缓存集群的方式,将仓储中心基本信息、商品类别以及库存数量放置在内存的缓存中,而仓储中心的其它商品信息则存储在数据库系统。

【问题1】(9分)

设计团队在讨论缓存和数据库的数据一致性问题时,李工建议采取数据实时同步更新方案,张工则建议采用数据异步准实时更新方案。而请用 200字以内的文字,简要介绍两种方案的基本思路,说明全国仓储货物管理系统应该采用哪种方案,并说明采取该方案的原因。

答案：

数据实时同步更新方案：对数据库的写操作在同一个事务中同时更新缓存，保证缓存与数据库的强一致性。优点是数据一致性强；缺点是写性能受缓存牵制（缓存写失败需回滚），分布式场景下实现复杂，可扩展性差。

数据异步准实时更新方案：写操作先提交数据库，缓存通过异步消息队列、定时任务或 binlog 订阅等方式准实时同步，实现最终一致性。优点是读写解耦、写性能高、可用性好；缺点是存在秒级数据延迟窗口。

本系统应采用数据异步准实时更新方案。原因：系统需实时为用户反馈送达时间（响应时间 < 1 秒），对读性能要求高；题干已将仓储中心基本信息、商品类别及库存数量全部放入内存缓存加速读取，写操作相对低频；异步方案读写解耦，既能保证读性能，又能通过消息重试保证最终一致性，避免实时同步方案在分布式场景下的复杂性和写性能瓶颈。

💡 延伸学习：缓存一致性的 4 种经典模式

• Cache-Aside（旁路缓存）：应用读时先查缓存，未命中回源数据库后回填缓存；写时先更新数据库再失效缓存（最常用，本题场景也适用）
• Read/Write-Through：缓存作为主读写入口，应用只与缓存交互，缓存负责同步底层数据库（强一致但写性能差）
• Write-Behind：写操作只写缓存，缓存异步批量落库（写性能最高，但宕机可能丢数据）
• 选型决策树：业务允许最终一致 + 读多写少 → 异步准实时（Cache-Aside + MQ/binlog）；强一致 + 低并发 → 实时同步（Write-Through）；极致写性能 + 可容忍丢数 → Write-Behind

【问题2】(9分)

随着业务的发展,仓储中心以及商品的数量日益增加,需要对集群部署多个缓存节点,提高缓存的处理能力。李工建议采用缓存分片方法,把缓存的数据拆分到多个节点分别存储,减轻单个缓存节点的访问压力,达到分流效果。

缓存分片方法常用的有哈希算法和一致性哈希算法,李工建议采用一致性哈希算法来进行分片。请用 200字以内的文字简要说明两种算法的基本原理,并说明李工采用一致性哈希算法的原因。

答案：

哈希算法：通过 hash(key) % N（N 为缓存节点数）将数据映射到对应节点，原理简单、查询高效。但当节点增删时，N 值变化会导致几乎所有 key 的映射关系重新计算，引发大规模缓存失效和数据迁移。

一致性哈希算法：将哈希空间组织为 0~2³² 的环形空间，节点与数据均通过哈希映射到环上，每个数据沿环顺时针找到最近的节点存储。节点增删时仅影响环上相邻节点的部分数据，需迁移的数据量极小。

李工采用一致性哈希的原因：仓储与商品规模持续扩张，缓存节点需要频繁扩缩容；一致性哈希能最大限度减少节点变化时的数据迁移和缓存失效范围，避免哈希算法因节点变化引发的大规模缓存雪崩。

💡 延伸学习：一致性哈希的两个工程问题

1. 数据倾斜：节点少时分布不均 → 引入虚拟节点（每个真实节点映射 100~200 个虚拟节点到环上），让数据均匀分布
2. 工业级实现：Memcached 客户端 Ketama 算法（libmemcached 内置），用 MD5 + 160 个虚拟节点/真实节点

📌 Redis Cluster 用的是另一种分片：哈希槽（Hash Slot）

• 固定 16384 个槽位，key 按 CRC16(key) % 16384 映射到槽
• 槽分配到节点，节点增删时只迁移部分槽（不重算所有 key）
• 是一致性哈希和普通哈希的折中：实现简单 + 迁移粒度可控
• 面试高频考点：一致性哈希（Memcached 生态）和哈希槽（Redis 生态）的区别要分清

【问题3】(7分)

全国仓储货物管理系统开发完成,在运营一段时间后,系统维护人员发现大量黑客故意发起非法的商品送达时间查询请求,造成了缓存击穿。张工建议尽快采用布隆过滤器方法解决。请用200字以内的文字解释布隆过滤器的工作原理和优缺点。

答案：

布隆过滤器（Bloom Filter）工作原理：由一个长度为 m 的位数组（初始全 0）和 k 个独立的哈希函数组成。添加元素时，通过 k 个哈希函数计算出 k 个数组位置并置为 1；查询元素时，若 k 个位置全为 1 则判定”可能存在"（存在误判），若任一位置为 0 则判定"一定不存在"。

优点：

1. 空间效率高（仅用位数组存储，空间远小于实际数据集）
2. 查询时间复杂度 O(k)，与数据量无关，适合海量数据场景
3. 可有效拦截不存在的 key，防止非法查询穿透缓存直达数据库

缺点：

1. 存在误判率（假阳性）：可能把"不存在"判为"存在"，但不会漏判
2. 标准布隆过滤器不支持删除元素（Counting Bloom Filter 可解决但空间开销大）
3. 误判率随元素填充率上升而增大，需在初始化时合理预估容量

💡 延伸学习：缓存"三大杀手"区分

问题	触发条件	后果	典型解法
缓存穿透	查询不存在的 key	请求绕过缓存直击 DB	布隆过滤器（本题方案）/ 空值缓存
缓存击穿	某个热点 key 过期瞬间被高并发访问	大量请求同时回源 DB	互斥锁（只让一个请求回源）/ 永不过期
缓存雪崩	大量 key 同时过期或缓存集群宕机	DB 被瞬时流量打垮	过期时间加随机偏移 / 多级缓存 / 熔断降级

📌 布隆过滤器的工程参数选择（面试加分项）

• 位数组长度 m = -(n × ln p) / (ln 2)²（n 为元素数，p 为期望误判率）
• 哈希函数个数 k = (m/n) × ln 2
• 例：1 亿元素 + 1% 误判率 → m ≈ 9.6 亿 bit ≈ 120 MB，k ≈ 7
• 实战库：Google Guava BloomFilter、Redis 4.0+ 自带 BF.ADD/BF.EXISTS（基于 ReBloom 模块）

试题三

阅读以下关于嵌入式系统故障检测和诊断的相关描述,在答题纸上回答问题1至问题3.

【说明】

系统的故障检测和诊断是宇航系统提高装备可靠性的主要技术之一,随着装备信息化的发展,分布式架构下的资源配置越来越多、资源布局也越来越分散,这对系统的故障检测和诊断方法提出了新的要求。为了适应宇航装备的分布式综合化电子系统的发展,解决由于系统资源部署的分散性,造成系统状态的综合和监控困难的问题,公司领导安排张工进行研究。张工经过分析、调研提出了针对分布式综合化电子系统架构的故障检测和诊断的方案。

【问题1】(8分)

张工提出:宇航装备的软件架构可采用四层的层次化体系结构,即模块支持层、操作系统层、分布式中间件层和功能应用层。为了有效、方便地实现分布式系统的故障检测和诊断能力,方案建议将系统的故障检测和诊断能力构建在分布式中间件内,通过使用心跳或者超时探测技术来实现故障检测器。请用300字以内的文字分别说明心跳检测和超时探测技术的基本原理及特点。

答案：

心跳检测：被监控节点按固定周期向监控节点（或反向）发送"心跳"报文，报文携带节点标识、状态字与时间戳；监控节点为每个被监控节点维护"最后心跳到达时间"，若在"心跳周期 × 容错倍数"窗口内未收到新心跳，则判定该节点故障。其特点是被动接收、开销与节点数 × 心跳频率成正比且可预测、最坏检测延迟≈一个心跳周期、协议简单易实现；但无法区分"心跳丢包"与"节点真死"，可能产生误报，且仅能反映节点"存活"，不能验证业务可用性。

超时探测：监控节点按需向被监控节点主动发送探测请求（如 ping/health check 或业务级探针）并启动超时定时器；在阈值时间内收到符合预期的应答则健康，超时或应答异常则判定故障。其特点是按需触发、灵活，可与业务请求复用通道，不仅能识别节点存活，还能识别"存活但功能失效"；但监控端负载随探测频率上升，且探测策略需要根据业务 SLO 精细设计。

【问题2】(8分)

张工针对分布式综合化电子系统的架构特征,给出了初步设计方案,指出每个节点的故障监测 与诊断器主要负责监控系统中所有的故障信息,并将故障信息进行综合分析判断,使用故障诊断器分析出故障原因,给出解决方案和措施。系统可以给模块的每个处理机器核配置核状态监控器、给每个分区配置分区状态监控器、给每个模块配置模块状态监控器、给系统配置系统状态监控器,如下表所示。

请根据下面给出的分布式综合化电子系统可能产生的故障(a) ~ (h),判断这些故障分别属于哪类监控器检测的范围,完善表中的(1) ~ (8)的空白。

(a)应用程序除零(b)看门狗故障(c)任务超时(d)网络诊断故障(e)BIT 检测故障(f)分区堆栈溢出(g)操作系统异常(h)模块掉电

答案：

归类依据：

• 核状态监控器（CPU 核级）盯核内执行健康度：看门狗绑定核，未按时"喂狗"直接反映核运行卡死；除零是 CPU 算术异常，触发核级 trap。两者都是核内/紧耦合核的故障。
• 分区状态监控器（软件分区级）盯分区私有资源：堆栈是分区的独占内存资源，溢出即分区资源耗尽。
• 模块状态监控器（处理模块级 = 多核 + OS + 电源）盯模块整体行为：任务调度、OS 内核状态、模块物理电源均属模块范畴。
• 系统状态监控器（跨模块/系统级）盯系统级健康：网络互联覆盖模块间通信，BIT（Built-In Test）是系统上电/周期级自检，覆盖跨模块的整机健康。

【问题3】(9分)

张工在方案中指出,本系统的故障诊断采用故障诊断器实现,它可综合多种故障信息和系统状态,依据智能决策数据库提供的决策策略判定出故障类型和处理方法。智能决策数据库中的策 略可以对故障开展定性或定量分析。通常,在定量分析中,普遍采用基于解析模型的方法和数据驱动的方法。张工在方案中提出该系统定量分析时应采用基于解析模型的方法。但是此提议受到王工的反对,王工指出采用数据驱动的方法更适合分布式综合化电子系统架构的设计。请用300字以内的文字,说明数据驱动方法的基本概念,以及王工提出采用此方法的理由。

答案：

数据驱动方法的基本概念：通过对系统运行过程中的监测数据进行分析，在无精准系统数学模型的情况下实现故障诊断；具体方法包括机器学习、统计分析法和信号分析法。

王工提出采用此方法的理由：

1. 无需精准建模：宇航系统是一个非常复杂的系统，解析模型方法必须建立在精准数学模型基础上才能进行故障诊断，而对于如此复杂的系统难以精确建模；数据驱动方法不需要精准系统数学模型，直接从监测数据中学习故障模式，因此更适合本系统；
2. 数据资源丰富：系统配备多级监控体系，长期运行积累了海量带标签的故障/正常样本，为数据驱动方法提供充足训练数据；
3. 泛化能力强：不依赖系统先验知识，对解析模型难以描述的未知故障模式也具备识别能力；
4. 适配架构动态演化：系统支持模块热插拔与动态重构，数据驱动模型可基于新数据增量训练/在线学习，灵活适应架构持续演进，而解析模型在架构变更时往往需重新推导。

试题四

阅读以下关于软件系统设计与建模的叙述,在答题纸上回答问题1至问题3。

【说明】

煤炭生产是国民经济发展的主要领域之一,其煤矿的安全非常重要。某能源企业拟开发一套煤矿建设项目安全预警系统,以保护煤矿建设项目从业人员生命安全。本系统的主要功能包括如下(a)~(h)所述。

(a)项目信息维护 (b) 影响因素录入 (c)关联事故录入 (d) 安全评价得分 (e)项目指标预警分析 () 项目指标填报 (g)项目指标审核 (h)项目指标确认

【问题1】(9分)

王工根据煤矿建设项目安全预警系统的功能要求,设计完成了系统的数据流图,如图2-1所示。请使用题干中描述的功能(a) ~ (h),补充完善空(1) ~ (6)处的内容,并简要介绍数据流图在分层细化过程中遵循的数据平衡原则。

答案：

问题 1 参考答案：

数据流图分层细化遵循的数据平衡原则：

数据流图在分层细化（父图分解为子图）过程中，输入数据流与输出数据流必须保持守恒，具体原则如下：

1. 父图与子图平衡：父图中某加工的输入/输出数据流，必须与其子图加工的输入/输出数据流在数量和名称上一致（“数据守恒”），子图不得无故增删进出父图边界的数据流。
2. 子图内部平衡：每个加工既有输入数据流也有输出数据流，输入数据流应足以产生输出数据流。
3. 加工守恒：加工不能有"输入黑洞”（有输入无输出）或"输出奇迹"（有输出无输入）。
4. 数据守恒：任何数据存储（文件）必须通过加工进行读写，不能被外部实体直接读写。
5. 数据连续性：同一数据流的命名、属性在各层之间应保持一致。

【问题2】(9分)

请根据【问题1】中数据流图表示的相关信息,补充完善煤矿建设项目安全预警系统总体E-R图(见图2-2) 中实体(1)~(6)的具体内容,将正确答案填在答题纸上。

答案：

问题 2 参考答案：

【问题3】(7分)

在结构化分析和设计过程中,数据流图和数据字典是常用的技术手段,请用200字以内的文字简要说明它们在软件需求分析和设计阶段的作用。

答案：

问题 3 参考答案：

数据流图（DFD）和数据字典（DD）在结构化分析和设计中是互为补充的核心技术手段：

在需求分析阶段：

• 数据流图用图形化方式描述系统的逻辑模型——描述数据在系统中如何流动、被加工、被存储，刻画系统的功能边界与外部交互。
• 数据字典对数据流图中出现的所有数据流、数据存储、数据项、外部实体、加工进行精确的定义与说明——含名称、别名、类型、取值范围、存储位置等，是 DFD 的"文字注释"，消除二义性。

在设计阶段：

• 数据流图作为概要设计和详细设计的输入——加工的分解对应模块的划分，模块接口与数据流对应。
• 数据字典作为数据库设计的依据——数据存储结构、数据项的字段定义直接来源于 DD；也作为模块详细设计（数据结构、文件格式）的一致性参考。

二者配合保证需求到设计的可追溯性，避免设计与需求脱节。

试题五

阅读以下关于软件架构设计与评估的叙述,在答题纸上回答问题1和问题2。

【说明】

某电子商务公司拟升级其会员与促销管理系统,向用户提供个性化服务,提高用户的粘性。在项目立项之初,公司领导层一致认为本次升级的主要目标是提升会员管理方式的灵活性,由于当前用户规模不大,业务也相对简单,系统性能方面不做过多考患。新系统除了保持现有的四级固定会员制度外,还需要根据用户的消费金额、偏好、重复性等相关特征动态调整商品的折扣力度,并支持在特定的活动周期内主动筛选与活动主题高度相关的用户集合,提供个性化的打折促销活动。在需求分析与架构设计阶段,公司提出的需求和质量属性描述如下:

(a)管理员能够在页面上灵活设置折扣力度规则和促销活动逻辑,设置后即可生效;

(b)系统应该具备完整的安全防护措施,支持对恶意攻击行为进行检测与报警;

(c)在正常负载情况下,系统应在0.3秒内对用户的界面操作请求进行响应;

(d)用户名是系统唯一标识,要求以字母开头,由数字和字母组合而成,长度不少于6个字符。

(e)在正常负载情况下,用户支付商品费用后在3秒内确认订单支付信息;

(f)系统主站点电力中断后,应在5秒内将请求重定向到备用站点；

(g)系统支持横向存储扩展,要求在2人天内完成所有的扩展与测试工作；

(h)系统宕机后,需要在10秒内感知错误,并自动启动热备份系统；

()系统需要内置接口函数,支持开发团队进行功能调试与系统诊断；

(G)系统需要为所有的用户操作行为进行详细记录,便于后期查阅与审计;

(k)支持对系统的外观进行调整和配置,调整工作需要在4人天内完成。

在对系统需求、质量属性描述和架构特性进行分析的基础上,系统架构师给出了两种候选的架构设计方案,公司目前正在组织相关专家对系统架构进行评估。

【问题1】(12分)

在架构评估过程中,质量属性效用树 (utility tree)是对系统质量属性进行识别和优先级排序的重要工具。请将合适的质量属性名称填入图1-1 中(1)、(2)空白处,并选择题干描述的(a) ~ (k)填入(3) ~ (6)空白处,完成该系统的效用树。

答案：

问题 1 参考答案：

备选理由：

• (3)(4) 也可填 (c) + (e)（都是性能）
• (5) 也可填 (b) 安全防护+报警（安全）
• (6) 也可填 (a) 灵活设置规则 或 (k) 4 人天调整外观（可修改性）

【问题2】(13 分)

针对该系统的功能,李工建议采用面向对象的架构风格,将折扣力度计算和用户筛选分别封装为独立对象,通过对象调用实现对应的功能:王工则建议采用解释器(interpreters)架构风格,将折扣力度计算和用户筛选条件封装为独立的规则,通过解释规则实现对应的功能。请针对系统的主要功能,从折扣规则的可修改性、个性化折扣定义灵活性和系统性能三个方面对这两种架构风格进行比较与分析,并指出该系统更适合采用哪种架构风格。

答案：

问题 2 参考答案：

从折扣规则可修改性、个性化折扣定义灵活性、系统性能三方面对比如下：

该系统更适合采用：解释器架构风格（王工方案）。

理由：

1. 业务核心需求是"灵活"：题干明确"管理员能够在页面上灵活设置折扣力度规则和促销活动逻辑，设置后即可生效"——只有解释器架构能做到"修改规则无需重新编译部署"。
2. 规则多样性高：4 个维度（消费金额/偏好/重复性/活动周期）× 多种组合 → DSL 表达比代码类层次结构更自然。
3. 性能要求可满足：题干说"用户规模不大，业务相对简单，系统性能方面不做过多考虑"——解释器性能足够。
4. 业务长期演进：电商促销规则常变（双 11/618/会员日等），DSL 让运营人员直接改规则文件，不依赖开发排期。
5. 风险可控：可保留 OO 架构作为底层（业务组件），在其上叠加解释器（规则引擎 Drools / Aviator / QLExpress）——业界成熟方案。

业界参考：Drools（基于 Rete 算法）、Aviator（表达式求值）、Easy Rules（@Rule 注解）、QLExpress（阿里）——都是解释器架构在规则引擎场景的成熟实现。