软考系列（系统架构师）- 2020年系统架构师软考案例分析考点

试题一 软件架构（架构风格、质量属性）

【问题1】（13分）
针对该系统的功能，李工建议采用管道-过滤器（pipe and filter)的架构风格，而王工则建议采用仓库（reposilory)架构风格。请指出该系统更适合采用哪种架构风格，并针对系统的主要功能，从数据处理方式、系统的可扩展性和处理性能三个方面对这两种架构风格进行比较与分析，填写表1-1中的(1)~(4)空白处。

该系统更适合采用仓库架构风格。
(1)数据存储在中心仓库，处理流程独立，支持交互式处理。
(2)数据与处理紧密关联，调整处理流程需要系统重新启动。
(3)数据与处理分离，需要加载数据，性能降低。
(4)数据处理组件之间一般无依赖关系，可并发调用，提高性能。

试题二 数据库（逻辑设计、关系模式、主键、超类实体、派生属性）

【问题1】（14分）
请说明关系型数据库开发中，逻辑数据模型设计过程包含哪些任务？该包裹单的逻辑数据模型中应该包含哪些实体？并给出每个实体的主键属性。

逻辑数据模型设计过程包含的任务：
(1)构建系统上下文数据模型，包含实体及实体之间的联系；
(2)绘制基于主键的数据模型，为每个实体添加主键属性；
(3)构建全属性数据模型，为每个实体添加非主键属性；
(4)利用规范化技术建立系统规范化数据模型。
包裹单的逻辑数据模型中包含的实体：
(1)收件人（主键：电话)；
(2)寄件人（主键：电话)；
(3)包裹单（主键：编号）。

【问题2】（6分）
请说明什么是超类实体？结合图中包裹单信息，试设计一种超类实体，给出完整的属性列表。

超类实体是将多个实体中相同的属性组合起来构造出的新实体。
用户（姓名、电话、单位名称、详细地址）

【问题3】（5分）
请说明什么是派生属性，并结合图2-1的包裹单信息说明哪个属性是派生属性。

派生属性是指某个实体的非主键属性由该实体其他非主键属性决定。
包裹单中的总计是由资费、挂号费、保价费、回执费计算得出，所以是派生属性。

试题三 嵌入式（需求到架构映射、FACE 架构）

【问题1】（9分）
王工指出，软件开发中需求分析是根本，架构设计是核心，不考虑软件需求便进行软件架构设计很可能导致架构设计的失败，因此，如何把软件需求映射到软件架构至关重要。请从描述语言、非功能性需求描述、需求和架构的一致性等三个方面，用300字以内的文字说明软件需求到架构的映射存在哪些难点。

(1)需求和架构描述语言存在差异：软件需求是频繁获取的非正规的自然语言，
而软件架构常用的是一种正式语言。
(2)非功能属性难于在架构中描述：系统属性中描述的非功能性需求
通常很难在架构模型中形成规约。
(3)需求和架构的一致性难以保障：从软件需求映射到软件架构的过程中，
保持一致性和可追溯性很难，且复杂程度很高，
因为单一的软件需求可能定位到多个软件架构的关注点。
反之，架构元素也可能有多个软件需求。

操作系统服务段：为FACE架构其他段提供操作系统、运行时和操作系统级健康监控等服务。
通过开放式OSGi框架为上层功能提供OS标准接口，并可实现上层组件的即插即用能力。
I/O服务段：主要针对专用I/O设备进行抽象，屏蔽平台服务段软件与硬件设备的关系。
由于图形服务软件和GPU处理器紧密相关，因此I/O服务段不对GPU驱动进行抽象。
平台服务段：主要是指用户需要的共性软件，
如：系统级健康监控（HM)、配置、日志和流媒体等服务。
本段可包括平台公共服务、平台设备服务和平台图像服务等三类。
传输服务段：主要为上层可移植组件段提供平台性的数据交换服务。
可移植组件将通过传输服务段提供的服务实现交换，禁止组件间直接调用。
可移植组件段:提供了多组件使用能力和功能服务。主要包括公共服务和可移植组件两类。

【问题3】（6分）
FACE架构的核心能力是可支持应用程序的跨平台执行和可移植性，要达到可移植能力，必须解决应用程序的紧耦合和封装的障碍。请用200字以内的文字简要说明在可移植性上，应用程序的紧耦合和封装问题的主要表现分别是什么，并给出解决方案。

紧耦合问题主要表现在：I/O问题、业务逻辑问题和表现问题。
解决方案：可采用分离原则，通过隔离实现硬件特定信息和少数模块的代码，减少耦合性。
封装问题主要表现在：ICD硬编码问题、组件的紧耦合问题、直接调用问题。
解决方案：可以通过提供数据源或槽的软件服务的方法，将紧耦合组件分解出应用程序，
并将平台相关部分加入计算环境中，在计算平台内提供数据源或槽的软件服务，并实现接口标准化。

试题四 数据库（内存数据车 redis，内存淘汰机制）

【问题2】（7分）
该网上社区平台需要为用户提供7X24小时的不间断服务。同时在系统出现宕机等故障时，能在最短时间内通过重启等方式重新建立服务。为此，开发团队选择了Redis持久化支持。Redis有两种持久化方式，分别是RDB(Redis DataBase)持久化方式和AOF(Append Only File)持久化方式。开发团队最终选择了RDB方式。
请用200字以内的文字，从磁盘更新频率、数据安全、数据一致性、重启性能和数据文件大小五个方面比较两种方式，并简要说明开发团队选择RDB的原因

磁盘更新频率：AOF比RDB文件更新频率高。
数据安全：AOF比RDB更安全。
数据一致性：RDB间隔一段时间存储，可能发生数据丢失和不一致；AOF通过append模式写文件，即使发生服务器岩机，也可通过redis-check-aof工具解决数据一致性问题。
重启性能:RDB性能比AOF好。
数据文件大小：AOF文件比RDB文件大。
综合上述五个方面的比较，考虑在系统出现宕机等故障时，需要在最短时间内通过重启等方式重新建立服务，因此开发团队最终选择了RDB方式。

【问题3】（8分）
缓存中存储当前的热点数据，Redis为每个KEY值都设置了过期时间，以提高缓存命中率。为了清除非热点数据，Redis选择“定期删除+惰性删除”策略。如果该策略失效，Redis内存使用率会越来越高，一般应采用内存淘汰机制来解决。
请用100字以内的文字简要描述该策略的失效场景，并给出三种内存淘汰机制。

失效场景：如果“定期删除”没删除KEY,也没及时去请求KEY,也就是说“惰性删除”也没生效。
这样，Redis默认的“定期删除+惰性删除”策略就失效了。
对此，可采用内存淘汰机制解决：
(1)从已设置过期时间的数据集最近最少使用的数据淘汰。
(2)从已设置过期时间的数据集将要过期的数据淘汰。
(3)从已设置过期时间的数据集任意选择数据淘汰。
(4)从数据集最近最少使用的数据淘汰。
(5)从数据集任意选择数据淘汰。

试题五 Web应用（非功能性需求，SSM框架，数据访问机制）

【问题3】（5分）
该工业设备检测系统拟采用工业控制领域中统一的数据访问机制，实现与多种不同设备的数据交互，请用200字以内的文字说明采用标准的数据访问机制的原因。

该工业设备检测系统需与不同设备进行数据交互，
采用标准的数据访问机制可以在硬件供应商和软件开发商之间建立一套完整的规则。
只要遵循这套规则，数据交互对两者来说都是透明的，
硬件供应商只需考虑应用程序的多种需求和传输协议，
软件开发商也不必了解硬件的实质和操作过程，实现对设备数据采集的统一管理。