案例分析

试题一

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

[说明]

某公司拟开发-套机器学习应用开发平台,支持用户使用浏览器在线进行基于机器学习的智能应用开发活动。该平台的核心应用场景是用户通过拖拽算法组件灵活定义机器学习流程，采用自助方式进行智能应用设计、实现与部署，并可以开发新算法组件加入平台中。在需求分析与架构设计阶段,公司提出的需求和质量属性描述如下:

(a)平台用户分为算法工程师、软件工程师和管理员等三种角色，不同角色的功能界面有所不同；

(b)平台应该具备数据库保护措施，能够预防核心数据库被非授权用户访问；

(c)平台支持分布式部署,当主站点断电后，应在 20 秒内将请求重定向到备用站点；

(d)平台支持初学者和高级用户两种界面操作模式，用户可以根据自己的情况灵活选择合适的模式；

(e)平台主站点宕机后，需要在 15 秒内发现错误并启用备用系统；

(f)在正常负载情况下，机器学习流程从提交到开始执行，时间间隔不大于5秒；

(g)平台支持硬件扩容与升级，能够在 3 人天内完成所有部署与测试工作；

(h)平台需要对用户的所有操作过程进行详细记录，便于审计工作；

(i)平台部署后，针对界面风格的修改需要在 3 人天内完成;

(j)在正常负载情况下，平台应在 0.5 秒内对用户的界面操作请求进行响应；

(k)平台应该与目前国内外主流的机器学习应用开发平台的界面风格保持一致；

(l)平台提供机器学习算法的远程调试功能，支持算法工程师进行远程调试。

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

[问题 1] (9 分)

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

回答：

问题 1 参考答案：

辅助理解：质量属性六大类——可用性、性能、安全性、可修改性（可维护性）、易用性、可移植性。本题考"识别-归类-优先级排序"三步法。

[问题 2] (16 分)

针对该系统的功能，赵工建议采用解释器(interpreter)架构风格，李工建议采用管道过滤器(ppe-and-hlter)的架构风格，王工则建议采用隐式调用(implicitinvocation)架构风格。请针对平台的核心应用场景，从机器学习流程定义的灵活性和学习算法的可扩展性两个方面对三种架构风格进行对比与分析，并指出该平台更适合采用哪种架构风格。

回答：

问题 2 参考答案：

(1) 机器学习流程定义的灵活性对比：

• 解释器风格：将机器学习流程定义为一门 DSL/脚本，由解释器逐条执行。灵活性高，可表达复杂逻辑；但要求用户学习 DSL 语法，对"拖拽式"自助场景不够友好。
• 管道-过滤器风格：把每个算法组件封装为"过滤器"，数据在组件间顺序/并行流动。流程 = 组件 + 连接关系，与"拖拽"天然契合，定义灵活直观。
• 隐式调用风格：组件通过事件触发/订阅-发布机制协作。流程=事件流，灵活但事件依赖关系不直观，新人难理解。

结论：管道-过滤器风格在"拖拽定义流程"上最灵活；隐式调用次之；解释器最弱。

(2) 学习算法的可扩展性对比：

• 解释器风格：新增算法必须修改解释器核心或新增指令，扩展成本高、需深入内核，违反开闭原则。
• 管道-过滤器风格：新增算法 = 实现一个标准接口的过滤器，平台只需注册即可使用；扩展成本低、符合"对扩展开放、对修改关闭"原则。
• 隐式调用风格：新增算法只需注册监听器/发布器，扩展性好；但要保证事件命名空间一致，否则易混乱。

结论：管道-过滤器和隐式调用扩展性都好；解释器最差。

(3) 平台更适合采用：管道-过滤器风格（李工方案）。

理由：

1. “拖拽算法组件定义流程” = 数据在多个组件间流动 = 管道-过滤器天然契合；
2. 算法的可扩展 = 新增过滤器，符合开闭原则；
3. 各算法组件可独立开发、测试、复用；
4. 解释器需要用户写脚本，不适合"自助拖拽"；
5. 隐式调用的事件流对普通用户不直观，调试困难。

试题二

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

[说明]

某医院拟委托软件公司开发一套预约挂号管理系统，以便为患者提供更好的就医体验，为医院提供更加科学的预约管理。本系统的主要功能描述如下：

(a)注册登录,(b)信息浏览，(c)账号 管理，(d)预约挂号，(e)查询与取消预约，(F)号源管理，(g)报告 查询，(h)预约管理，(i)报表管理和(j)信用管理等。

[问题 1] (6 分)

若采用面向对象方法对预约挂号管理系统进行分析,得到如图2-1所示的用例图。请将合适的参与者名称填入图 2-1 中的(1)和(2)处，使用题干给出的功能描述(a)-(j)，完善用例(3)-(12)的名称。

回答：

问题 1 参考答案：

[问题 2] (10 分)

预约人员(患者)登录系统后发起预约挂号请求，进入预约界面。进行预约挂号时使用数据库访问类获取医生的相关信息，在数据库中调用医生列表，并调取医生出诊时段表，将医生出诊时段反馈到预的界面，并显示给预约人员;预约人员选择医生及就诊时间后确认预的，系统返网预约结果，并向用户显示是否预约成功。

采用面向对象方法对预约挂号过程进行分析，得到如图2-2 所示的顺序图，使用题干中给出的描述，完善图 2-2 中对象(1),及消息(2)~(4)的名称，将正确答案填在普题纸上请简要说明在描述对象之间的动态交互关系时，协作图与顺序图存在哪些区别。

回答：

问题 2 参考答案：

（1）对象与消息：

（2）协作图 vs 顺序图的区别：

[问题 3] (9 分)

采用面向对象方法开发软件，通常需要建立对象模型、动态模型和功能模型，请分别介绍这 3 种模型,并详细说明它们之间的关联关系，针对上述模型，说明哪些模型可用于软件的需求分析？

回答：

问题 3 参考答案：

（1）三种模型：

（2）三者关联关系：

• 对象模型是基础（最根本），它确定系统的静态结构
• 动态模型展示对象模型中对象的状态变化（对象 = 动态模型中状态机的主体）
• 功能模型展示对象上的操作（DFD 中的加工 ≈ 对象模型中类的方法；DFD 中的数据存储 ≈ 对象模型中的属性）
• 三者相互独立又相互依赖：
  • 对象模型：静态"骨架"
  • 动态模型：在骨架上跑"时序"
  • 功能模型：在骨架上做"变换"
• 一个完整的面向对象分析必须三者并建，缺一不可

（3）需求分析阶段用哪些：

• 功能模型：需求分析最核心（DFD 直接描述系统功能需求）
• 对象模型：用于需求分析（识别候选对象和类）
• 动态模型：用于系统分析阶段（控制流、状态转换），但部分用例的动态行为也会在需求分析中初步识别

结论：功能模型主要用于需求分析；对象模型和动态模型同时用于系统分析（OOA 阶段）。

试题三

阅读以下关于数据库设计的叙述，回答问题1 至问题3。

[说明]

某医药销售企业因业务发展，需要建立线上药品销售系统，为用户提供便捷的互联网药品销售服务、该系统除了常规药品展示、订单、用户交流与反馈功能外, 还需要提供当前热销产品排名、评价分类管理等功能。

通过对需求的分析，在数据管理上初步决定采用关系数据库(MySQL)和数据库缓存(Redis) 的混合架构实现。经过规范化设计之后，该系统的部分数据库表结构如下所示。

供应商(供应商 ID,供应商名称，联系方式，供应商地址) ;

药品(药品 ID，药品名称，药品型号,药品价格,供应商ID) ;

药品库存(药品 ID,当前库存数量) ;

订单(订单号码，药品 ID,供应商 ID,药品数量，订单金额) ；

[问题 1] (9 分)

在系统初步运行后，发现系统数据访问性能较差。经过分析，刘工认为原来数据库规范化设计后，关系表过于细分,造成了大量的多表关联查询，影响了性能。例如当用户查询商品信息时，需要同时显示该药品的信息、供应商的信息、当前库存等信息。

为此，刘工认为可以采用反规范化设计来改造药品关系的结构，以提高查询性能。修改后的药品关系结构为:

药品(药品 ID,药品名称，药品型号，药品价格,供应商ID,供应商名称，当前库存数量) ;

请用 200 字以内的文字说明常见的反规范化设计方法，并说明用户查询商品信息应该采用哪种反规范化设计方法。

回答：

问题 1 参考答案：

（1）常见反规范化设计方法：

1. 增加冗余列：在多个表中保存相同字段，避免 JOIN 查询（如本题）
2. 增加派生列：存储计算结果（如总数、均值、累计金额、当前库存）
3. 重新组表：把经常一起访问的字段合并到一张宽表（垂直合并）
4. 分割表：水平拆分（按行/用户/时间）或垂直拆分（按字段冷热）

（2）用户查询商品信息应采用：增加冗余列

理由：用户查商品时需同时显示"药品信息 + 供应商信息 + 当前库存"——原本要 3 表 JOIN，关联多、性能差。把"供应商名称"“当前库存数量"冗余到"药品"表里，一次单表查询就能拿到全部展示数据。

[问题 2] (9 分)

王工认为，反规范化设计可提高查询的性能，但必然会带来数据的不一致性问题。请用 200 字以内的文字说明在反规范化设计中，解决数据不一致性问题的三种常见方法，并说明该系统应该采用哪种方法。

回答：

问题 2 参考答案：

（1）三种常见方法：

1. 触发器：在数据库端写触发器，当主表数据变更时自动同步冗余字段
2. 应用层代码：业务代码在更新主表时同时更新冗余字段
3. 批处理同步：定时任务扫描数据差异，定时修复不一致记录

（2）该系统应采用：触发器

理由：

• 实时性强：主表每次变更立即同步冗余字段，不一致窗口几乎为 0
• 自动同步：对应用代码透明，不会因业务代码遗漏导致不一致
• 数据一致性好：数据库层面保证，不依赖业务方写代码

备选：应用层代码（更可控、避免数据库触发器性能开销）——但软考标准答案通常是触发器，因实时性和自动化更高。

[问题 3] (7 分)

该系统采用了 Redis 来实现某些特定功能(如当前热销药品排名等)，同时将药品关系数据放到内存以提高商品查询的性能，但必然会造成Redis 和MySQL的数据实时同步问题。

(1) Redis 的数据类型包括 String、 Hash、 List、 Set 和ZSet 等，请说明实现当前热销药品排名的功能应该选择使用哪种数据类型。

(2)请用 200 字以内的文字解释说明解决 Redis 和 MySQL 数据实时同步问题的常见方案。

回答：

问题 3 参考答案：

(1) 数据类型：ZSet（Sorted Set，有序集合）

理由：热销排名 = 按销售量/热度排序。

• 成员 = 药品 ID
• 分数 = 销量/热度值
• ZADD 添加或更新药品的销量分数
• ZINCRBY 增加某药品的销量（原子操作）
• ZRANGE 取出 Top N 排行榜（如 ZRANGE hot:drug 0 9 WITHSCORES 取 Top 10）
• ZSet 天然支持按分数排序，O(log N) 性能

(2) Redis-MySQL 数据同步方案：

软考答题优先答 Cache-Aside + 延迟双删 两个点；进阶可提 Canal 订阅 binlog（阿里开源方案）。

试题四

阅读以下关于 Web 系统架构设计的教述，回答问题1 至问题3。

[说明]

某公司拟开发-个智能家居管理系统，该系统的主要功能需求如下：

1)用户可使用该系统客户端实现对家居设备的控制，且家居设备可向客户端反馈实时状态；

2)支持家居设备数据的实时存储和查询；

3)基于用户数据，挖掘用户生活习惯，向用户提供家居设备智能化使用建议。

基于上述需求，该公司组建了项目组，在项目会议上,张工给出了基于家庭网关的传统智能家居管理系统的设计思路，李工给出了基于云平台的智能家居系统的设计思路。经过深入讨论，公司决定采用李工的设计思路。

[问题 1] (8 分)

请用 400 字以内的文字简要描述基于家庭网关的传统智能家居管理系统和基于云平台的智能家居管理系统在网关管理、数据处理和系统性能等方面的特点，以说明项目组选择李工设计思路的原因。

回答：

问题 1 参考答案：

项目组选李工（云平台）方案的原因：

1. 需求 3 要求"基于用户数据挖掘生活习惯、提供智能化建议”——必须有大数据 + AI 算力，家庭网关做不到
2. 海量家居设备数据需要集中存储和分析
3. 集中管理降低运维成本，故障远程处理
4. 云端弹性扩展能力远超本地网关
5. 数据可靠性、跨设备联动能力云端更优

[问题 2] (12 分)

请从下面给出的(a) ~ (j) 中进行选择，补充完善图 5-1 中空(1) ~(6)处的内容，协助李工完成该系统的架构设计方案。

(a) Wi-FI (b) 蓝牙 (c)驱动程序 (d)数据库 (e)家庭网关 (f)云平台 (g)微服务 (h)用户终端 (i)鸿蒙 (j)TCP/IP

回答：

问题 2 参考答案：

备选 (4) 也可填 微服务 (g)——若强调云平台用微服务架构组织业务。但标准答案倾向"数据库"，体现云端数据持久化层。

[问题 3] (5 分)

该系统需实现用户终端与服务端的双向可靠通信，请用300 字以内的文字从数据传输可靠性的角度对比分析 TCP 和 UDP 通信协议的不同，并说明该系统应采用哪种通信协议。

回答：

问题 3 参考答案：

该系统应采用：TCP

理由：

1. 智能家居双向通信对可靠性要求高——控制指令丢失会导致设备异常、状态反馈丢失会导致用户误判
2. 对实时性要求不高（秒级延迟可接受），TCP 的可靠性优势 > 速度劣势
3. TCP 的确认 + 重传 + 排序机制保证命令不丢、有序到达
4. UDP 的"不可靠"在控制命令场景会带来安全/可靠性风险
5. 反例：实时音视频流、传感器高频数据上报等场景才优先用 UDP

参考资料

• 2021 年下半年系统架构设计师考试真题（下午案例分析）
• 《系统架构设计师教程》—— 软件架构设计、UML 建模、数据库设计、Web 架构章节