全国计算机技术与软件专业技术资格（水平）考试
高级 系统架构设计师 2020 年 下半年 下午试卷 案例
试题一 某公司拟开发一套在线软件开发系统，支持用户通过浏览器在线进行软件开发活 动。该系统的主要功能包括代码编辑、语法高亮显示、代码编译、系统调试、代码仓库管 理等。在需求分析与架构设计阶段，公司提出的需求和质量属性描述如下：
(a)根据用户的付费情况对用户进行分类，并根据类别提供相应的开发功能；
(b)在正常负载情况下，系统应在 0.2 秒内对用户的界面操作请求进行响应；
(c)系统应该具备完善的安全防护措施，能够对黑客的攻击行为进行检测与防御；
(d)系统主站点断电后，应在 3 秒内将请求重定向到备用站点；
(e)系统支持中文昵称，但用户名必须以字母开头，长度不少于 8 个字符；
(f)系统宕机后，需要在 15 秒内发现错误并启用备用系统；
(g)在正常负载情况下，用户的代码提交请求应该在 0.5 秒内完成；
(h)系统支持硬件设备灵活扩容，应保证在 2 人·天内完成所有的部署与测试工作；
(i)系统需要为针对代码仓库的所有操作情况进行详细记录，便于后期查阅与审计；
(j)更改系统的 Web 界面风格需要在 4 人·天内完成；
(k)系统本身需要提供远程调试接口，支持开发团队进行远程排错。
在对系统需求、质量属性和架构特性进行分析的基础上，该公司的系统架构的给出了两种候选的架构设计方案，公司目前正在组织相关专家对候选系统架构进行评估。
(13 分)
针对该系统的功能，李工建议采用管道-过滤器(pipeandfilter)的架构风格，而王工则建 议采用仓库(reposilory)架构风格。请指出该系统更适合采用哪种架构风格，并针对系统 的主要功能，从数据处理方式、系统的可扩展性和处理性能三个方面对这两种架构风格进 行比较与分析，填写表 1-1 中的( )~( )空白处。
(12 分)
在架构评估过程中，质量属性效用树(utilitytree)是对系统质量属性进行识别和优先级排 序的重要工具。请将合适的质量属性名称填入图 1-1 中( )、( )空白处，并选择题干描述 的(a)~(k)填入( )~( )空白处，完成该系统的效用树。
试题二 某企业委托软件公司开发一套包裹信息管理系统，以便于对该企业通过快递收发 的包裹信息进行统一管理。在系统设计阶段，需要对不同快递公司的包裹单信息进行建 模，其中，邮政包裹单如图 2-1 所示。
(14 分)
请说明关系型数据库开发中，逻辑数据模型设计过程包含哪些任务？该包裹单的逻辑数据 模型中应该包含哪些实体？并给出每个实体的主键属性。
(6 分)
请说明什么是超类实体？结合图中包裹单信息，试设计一种超类实体，给出完整的属性列 表。
(5 分)
请说明什么是派生属性，并结合图 2-1 的包裹单信息说明哪个属性是派生属性。
试题三 某公司一直从事宇航系统研制任务，随着宇航产品综合化、网络化技术发展的需 要，公司的业务量急剧增加，研制新的软件架构已迫在眉睫。公司架构师王工广泛调研了 多种现代架构的基础，建议采用基于 FACE (FutureAirborneCapabilityEnvironment)的宇 航系统开放式软件架构，以实现宇航系统的跨平台复用，实现宇航软件高质量、低成本的 开发。公司领导肯定了王工的提案，并指出公司要全面实施基于 FACE 的开放式软件架构， 应注意每个具体项目在实施中如何有效实现从需求到架构设计的关系，掌握基于软件需求 的软件架构设计方法，并做好开放式软件架构中各段间的接口标准化设计工作。
(9 分)
王工指出，软件开发中需求分析是根本，架构设计是核心，不考虑软件需求便进行软件架 构设计很可能导致架构设计的失败，因此，如何把软件需求映射到软件架构至关重要。请 从描述语言、非功能性需求描述、需求和架构的一致性等三个方面，用 300 字以内的文字 说明软件需求到架构的映射存在哪些难点。
(10 分)
图 3-1 是王工给出的 FACE 架构布局，包括操作系统、 I/O 服务、平台服务、传输服务和可 移植组件等 5 个段；操作系统、 I/O 和传输等 3 个标准接口。请分析图 3-1 给出的 FACE 架 构的相关信息，用 300 字以内的文字简要说明 FACE5 个段的含义。
(6 分)
FACE 架构的核心能力是可支持应用程序的跨平台执行和可移植性，要达到可移植能力，必 须解决应用程序的紧耦合和封装的障碍。请用 200 字以内的文字简要说明在可移植性上， 应用程序的紧耦合和封装问题的主要表现分别是什么，并给出解决方案。
试题四 某互联网文化发展公司因业务发展，需要建立网上社区平台，为用户提供一个对 网络文化产品(如互联网小说、电影、漫画等)进行评论、交流的平台。该平台的部分功能 如下：
(a)用户帖子的评论计数器；
(b)支持粉丝列表功能；
(c)支持标签管理；
(d)支持共同好友功能等；
(e)提供排名功能，如当天最热前 10 名帖子排名、热搜榜前 5 排名等；
(f)用户信息的结构化存储；
(g)提供好友信息的发布/订阅功能。
该系统在性能上需要考虑高性能、高并发，以支持大量用户的同时访问。开发团队经过综 合考虑，在数据管理上决定采用 Redis+数据库(缓存+数据库)的解决方案。
(10 分)
Redis 支持丰富的数据类型，并能够提供一些常见功能需求的解决方案。请选择题干描述 的(a)~(g)功能选项，填入表 4-1 中( )~( )的空白处。
(7 分)
该网上社区平台需要为用户提供 7X24 小时的不间断服务。同时在系统出现宕机等故障时， 能在最短时间内通过重启等方式重新建立服务。为此，开发团队选择了 Redis 持久化支持。 Redis 有两种持久化方式，分别是 RDB(RedisDataBase)持久化方式和 AOF(AppendOnlyFile) 持久化方式。开发团队最终选择了 RDB 方式。
请用 200 字以内的文字，从磁盘更新频率、数据安全、数据一致性、重启性能和数据文件 大小五个方面比较两种方式，并简要说明开发团队选择 RDB 的原因。
(8 分)
缓存中存储当前的热点数据， Redis 为每个 KEY 值都设置了过期时间，以提高缓存命中 率。为了清除非热点数据， Redis 选择“定期删除+惰性删除”策略。如果该策略失效， Redis 内存使用率会越来越高，一般应采用内存淘汰机制来解决。
请用 100 字以内的文字简要描述该策略的失效场景，并给出三种内存淘汰机制。
试题五 某公司拟开发一款基于 Web 的工业设备监测系统，以实现对多种工业设备数据的 分类采集、运行状态监测以及相关信息的管理。该系统应具备以下功能： 现场设备状态采集功能：根据数据类型对设备监测指标状态信号进行分类采集； 设备采集数据传输功能：利用可靠的传输技术，实现将设备数据从制造现场传输到系统后 台; 设备监测显示功能：对设备的运行状态、工作状态以及报警状态进行监则并提供相应的图 形化显示界面； 设备信息管理功能：支持设备运行历史状态、报警记录、参数信息的查询。 同时，该系统还需满足以下非功能性需求：
(a)系统应支持大于 100 个工业设备的并行监测；
(b)设备数据从制造现场传输到系统后台的传输时间小于 1s;
(c)系统应 7X24 小时工作;
(d)可抵御常见 XSS 攻击：
(e)系统在故障情况下，应在 0.5 小时内恢复；
(f)支持数据审计。
面对系统需求，公司召开项目组讨论会议，制定系统设计方案，最终决定采用三层拓扑结 构，即现场设备数据采集层、 Web 监测服务层和前端 Web 显示层。
(6 分)
请按照性能、安全性和可用性等三类非功能性需求分类，选择题干描述的(a)~(f) 填入( )~( )。
(14 分)
该系统的 Web 监测服务层拟采用 SSM (spring+springMVC+Mybatis)框架进行系统研发。 SSM 框架的工作流程图如图 5-1 所示，请从下面给出的(a)~(k)中进行选择，补充完善图 5-1 中( )~( )处空白的内容。
(a)Connection Pool
(b)Struts2
(c)Persistent Layer
(d)Mybatis
(e)HTTP
(f)MVC
(g)Kafka
(h)View Layer
(i)JSP
(j) Controller Layer
(k) Spring
(5 分)
该工业设备检测系统拟采用工业控制领域中统一的数据访问机制，实现与多种不同设备的 数据交互，请用 200 字以内的文字说明采用标准的数据访问机制的原因。
参考答案
试题一 答案： 解析：
【问题】
该系统更适合采用仓库架构风格。
( )数据存储在中心仓库，处理流程独立，支持交互式处理。
( )数据与处理紧密关联，调整处理流程需要系统重新启动。 ( )数据与处理分离，需要加载数据，性能降低。
( )数据处理组件之间一般无依赖关系，可并发调用，提高性能。
本题考查软件架构评估方面的知识与应用，主要包括质量属性效用树和架构分 析两个部分。 此类题目要求考生认真阅读题目对系统需求的描述，经过分类、概括等方法， 从中确定软件功能需求、软件质量属性、架构风险、架构敏感点、架构权衡点 等内容，并采用效用树这一工具对架构进行评估。 本问题考查考生对影响系统架构风格选型的理解与掌握。根据系统要求，李工 建议采用管进-过滤器(pipeandfilter)的架构风格，而王工则建议采用仓库( repositoiy)架构风格。考生需要从系统的主要功能和要求，从数据处理方式、 系统的可扩展性和处理性能三个方面对这两种架构风格的优势和劣势进行比较 与分析。具体如下表所示。
经过综合比较与分析，可以看出该系统更适合使用仓库风格。
【问题】
( )安全性 ( )可修改性 ( )(g)
( )(i)
( )(f)
( )(j)
在架构评估过程中，质量属性效用树(utilitytree)是对系统质量属性进行识别 和优先级排序的重要工具。质量属性效用树主要关注性能、可用性、安全性和 可修改性等四个用户最为关注的质量属性，考生需要对题干的需求进行分析， 逐一找出这四个质量属性对应的描述，然后填入空白处即可。
经过对题干进行分析，可以看出：
(a)根据用户的付费情况对用户进行分类，并根据类别提供相应的开发功能(功 能需求)；
(b)在正常负载情况下，系统应在 0.2 秒内对用户的界面操作请求进行响应(性能)；
(c)系统应该具备完善的安全防护措施，能够对黑客的攻击行为进行检测与防御 (安全性);
(d)系统主站点断电后，应在 3 秒内将请求重定向到备用站点(可用性)；
(e)系统支持中文昵称，但用户名必须以字母开头，长度不少于 8 个字符(功能 需求);
(f)系统宕机后，需要在 15 秒内发现错误并启用备用系统(可用性)；
(g)在正常负载情况下，用户的代码提交请求应该在 0.5 秒内完成(性能)；
(h)系统支持硬件设备灵活扩容，应保证在 2 人?天内完成所有的部署与测试工 作(可修改性)； (i)系统需要为针对代码仓库的所有操作情况进行详细记录，便于后期查阅与审 计(安全性);
(j)更改系统的 Web 界面风格需要在 4 人?天内完成(可修改性)；
(k)系统本身需要提供远程调试接口，支持开发团队进行远程排错(可测试性)。
试题二 答案： 解析： 逻辑数据模型设计过程包含的任务：
( )构建系统上下文数据模型，包含实体及实体之间的联系； ( )绘制基于主键的数据模型，为每个实体添加主键属性；
( )构建全属性数据模型，为每个实体添加非主键属性； ( )利用规范化技术建立系统规范化数据模型。 包裹单的逻辑数据模型中包含的实体：
( )收件人(主键：电话)； ( )寄件人(主键：电话)； ( )包裹单(主键：编号)。
本题考查数据库设计与建模相关知识及应用。 数据库设计过程包括了逻辑数据建模和物理数据建模，逻辑数据建模阶段主要构造实体联 系图表达实体及其属性和实体间的联系，物理数据建模阶段主要根据所选数据库系统设计 数据库模式。实体联系图(EntityRelationshipDiagram)指以实体、联系、属性三个基本概 念概括数据的基本结构，从而描述静态数据结构的概念模式。实体是具有公共性质的可相 互区別的现实世界对象的集合，可以是具体的，也可以是抽象的概念或联系。属性是实体 所具有模拟特性，一个实体可由若干个属性来刻画。联系是数据对象彼此之间存在的相互 关系。 此类题目要求考生认真阅读题目对问题的描述，准确理解数据库设计的主要任务和实体联 系图中各个元素的含义，结合图中所给出的包裹单示意图中所描述的数据项，分析其关系 确定实体、属性和联系。 在关系型数据库开发中，逻辑数据模型建设的主要任务是构建实体联系图。构建过程中， 首先通过上下文数据模型确定实体及其联系，为每个实体确定其标识性属性并添加完整属 性，在此基础上利用规范化技术对所建立逻辑数据模型进行优化，一般需要满足第三范式 3NF 要求。对图 2-1 所示包裹单中所有数据项进行分析，主要涉及的实体包括收件人、寄 件人及其之间的关联实体包裹单，其余数据项设计为上述三个实体的属性即可。
【问题】 超类实体是将多个实体中相同的属性组合起来构造出的新实体。 用户(姓名、电话、单位名称、详细地址)
数据库建模中可以对属性相似的实体进行进一步的抽象，通过将多个实体中相同的属性组 合起来构造出新的抽象实体，即超类实体，原有多个实体称之为子类实体，通过两者之间 的继承关系来表达抽象实体和具体实体的关系。图 2-1 中收件人和寄件人的属性都包括了 姓名、电话、单位名称、详细地址和邮政编码等信息，可以设计出一个超类实体“用户” 来实现通用属性的抽象表示。
【问题】
派生属性是指某个实体的非主键属性由该实体其他非主键属性决定。 包裹单中的总计是由资费、挂号费、保价费、回执费计算得出，所以是派生属性。
在数据库优化过程中，第三范式要求消除派生属性，即某个实体的非主键属性由该实体其 他非主键属性决定，那么该属性可以称之为派生属性。图 2-1 所示属性中，包裹单的属性 “费用总计”是由资费、挂号费、保价费、回执费等计算得出，所以是派生属性。
试题三 答案： 解析： ( )需求和架构描述语言存在差异：软件需求是频繁获取的非正 规的自然语言，而软件架构常用的是一种正式语言。
( )非功能属性难于在架构中描述：系统属性中描述的非功能性需求通常很难在架构模型中 形成规约。
( )需求和架构的一致性难以保障：从软件需求映射到软件架构的过程中，保持一致性和可 追溯性很难，且复杂程度很高，因为单一的软件需求可能定位到多个软件架构的关注点。 反之，架构元素也可能有多个软件需求。
FACE 是近年来宇航领域提出的一种面向服务的、安全可靠、可移植、可扩展的开放式嵌入 式系统架构，可实现宇航软件的跨平台复用以及高质量、低成本的开发工作。从图 3-1 可 以看出， FACE 将宇航软件分为 5 个功能服务段，各段之间通过标准的服务接口或传输服务 实现功能间的相互调用。架构设计是软件系统开发中的重要环节，其架构的优劣直接接影 响着软件系统的功能实现，因此，架构能否全面反映需求是架构设计的重中之重。 通常在软件开发过程中，需求会随着开发深入而有所变化，而架构又不能完全地将需求全 部反映出来，因此，如何把软件需求映射到软件架构是至关重要一个问题，在架构设计 时，架构设计师应密切关注需求到架构的映射存在以下 5 方面的难点：
( )需求和架构描述语言存在差异：软件需求是频繁获取的非正规的自然语言，而软件架构 常用某种正式语言。
( )非功能属性难以在架构中描述：系统属性中描述的非功能性需求通常很难在架构模型中 形成规约。
( )需求和架构的一致性难以保障：从软件需求映射到软件架构的过程中，保持一致性和可 追溯性很难，且复杂程度很高，因为单一的软件需求可能定位到多个软件架构的关注点。 反之，架构元素也可能有多个软件需求。
( )用迭代和同步演化方法开发软件时，由于需求的不完整而带来的架构设计困难：架构设 计必须基于一个准确的需求开展，而有些软件需求只能在建模后甚至是在架构实现时才能 被准确理解。
( )难以确定和细化包含这些需求的架构相关信息：大规模系统必须满足数以千计的需求， 会导致很难确定和细化包含这些需求的架构相关信息。
【问题】
操作系统服务段：为 FACE 架构其他段提供操作系统、运行时和操作系统级健康监控等服 务。通过开放式 OSGi 框架为上层功能提供 OS 标准接口，并可实现上层组件的即插即用能力。I/O 服务段：主要针对专用 I/O 设备进行抽象，屏蔽平台服务段软件与硬件设备的关系。 由于图形服务软件和 GPU 处理器紧密相关，因此 I/O 服务段不对 GPU 驱动进行抽象。 平台服务段：主要是指用户需要的共性软件，如：系统级健康监控(HM)、配置、日志和流媒体等服务。本段可包括平台公共服务、平台设备服务和平台图像服务等三类。 传输服务段：主要为上层可移植组件段提供平台性的数据交换服务。可移植组件将通过传 输服务段提供的服务实现交换，禁止组件间直接调用。 可移植组件段:提供了多组件使用能力和功能服务。主要包括公共服务和可移植组件两类。
从图 3-1 可知， FACE 架构由 5 个基本段组成，每段内又分为多个功能服务，从这些服务可 以看出每段的基本能力。例如，操作系统段是 FACE 架构的基本功能，除基本操作系统外， 还涵盖了运行库，操作系统的健康监控(HM)，图中所给出的 OSGi 框架，实现功能组件“即 插即用”能力。如果考生掌握了面向服务的架构风格，就不难给出各个段的具体含义。
( )操作系统服务段：为 FACE 架构其他段提供操作系统、运行时和操作系统级健康监控等 服务。通过开放式 OSGi 框架为上层功能提供 OS 标准接口，并可实现上层组件的即插即用 能力。本段是 FACE 架构的基本服务段。
( )I/O 服务段：主要针对专用 I/O 设备进行抽象，屏蔽平台服务段软件与硬件设备的关 系，形成一种虚拟设备，这里隐含着对系统中的所有硬件 I/O 的虚拟化。由于图形服务软 件和 GPU 处理器紧密相关，因此 I/O 服务段不对 GPU 驱动进行抽象。
( )平台服务段：主要是指平台/用户需要的共性服务软件，主要涵盖跨平台的系统管理、 共享设备服务，以及健康管理等。如：系统级健康监控(HM)、配置、日志和流媒体等服 务。本段主要包括平台公共服务、平台设备服务和平台图像服务等三类。
( )传输服务段:通过使用传统跨平台中间件软件(如 CORBA 、 DDA 等)，为平台上层可移植 组件段提供平台性的数据交换服务，可移植组件将通过传输服务段提供的服务实现交换， 禁止组件间直接调用。本段应具备 QoS 质量特征服务、配置能力服务以及分布式传输服务 等。
( )可移植组件段：为用户软件段，提供了多组件使用能力和功能服务。主要包括公共服务 和可移植组件两类。
【问题】
紧耦合问题主要表现在： I/O 问题、业务逻辑问题和表现问题。 解决方案：可采用分离原则，通过隔离实现硬件特定信息和少数模块的代码，减少耦合性。 封装问题主要表现在： ICD 硬编码问题、组件的紧耦合问题、直接调用问题。 解决方案：可以通过提供数据源或槽的软件服务的方法，将紧耦合组件分解出应用程序， 并将平台相关部分加入计算环境中，在计算平台内提供数据源或槽的软件服务，并实现接 口标准化。
紧耦合和封装是软件模块化设计中最难以解决的两个问题，要使软件具备良好的可移植 性、可复用性，就必须清楚其问题的表现形式。 紧耦合是应用程序移植的一个障碍，进一步说，就是计算平台的硬件设备和软件模块及其 沟通之间的耦合代表了一个应用程序的可移植性方面的障碍。原因是便携性使得每个平台 设备都有一个接口控制文件(ICD),描述了由硬件所支持的消息和协议，应用程序对消息和 协议的支持将紧密耦合于硬件。若要移植，需要太多的工作来修改应用程序以支持不同的 结构元素。 为了尽量减少支持新的硬件设备所需要的工作，可采用分离原则，通过隔离实现硬件特定 信息和少数模块的代码，来减少耦合性。通常紧耦合问题主要表现在 I/O 问题、业务逻辑问题和表现问题。 传统的应用程序不可移植的另一个原因是这些应用程序被紧密耦合到组固定的接口，而这 些数据的每个数据源或槽(sinks)都暴露出了设备的特殊接口，这些特殊接口在每个平台中 都是不同的。这样，支持平台设备的接口控制文件(ICD)是被硬编码到应用程序中，就导致 应用程序不能成功在不同计算平台上执行。 为了解决这种接口控制文件(ICD)被硬编码而难以封装的问题，可以通过提供数据源或槽的 软件服务的方法，从紧耦合组件分解出应用程序，并将平台相关部分加入计算环境中，在 计算平台内提供数据源或槽的软件服务，并实现接口标准化。
通常封装问题主要表现在： ICD 硬编码问题、组件的紧耦合问题、直接调用问题。
试题四 答案： 解析：
【问题】
(1)(a)
(2)(b)、(g)
(3)(c)、(d)
(4)(f)
(5)(e)
本题考查数据库缓存的基本概念和具体应用。
本问题考查 Redis 数据库缓存产品基本数据类型的常见应用。 (1)STRING 类型：常规的 key/value 缓存应用，常规计数如粉丝数等； (2)LIST 类型：各类列表应用，如关注列表、好友列表、订阅列表等；
(3)SET 类型：与 LIST 类似，但提供去重操作，也提供集合操作，可实现共同关注、共同 喜好、共同好友等功能；
(4)HASH 类型：存储部分变更数据，如用户数据等；
(5)ZSET 类型：类似 SET 但提供自动排序，也可实现带权重的队列，勿各类排行榜等。
【问题】
磁盘更新频率： AOF 比 RDB 文件更新频率高。 数据安全： AOF 比 RDB 更安全。
数据一致性： RDB 间隔一段时间存储，可能发生数据丢失和不一致； AOF 通过 append 模式 写文件，即使发生服务器岩机，也可通过 redis-check-aof 工具解决数据一致性问题。 重启性能:RDB 性能比 AOF 好。
数据文件大小： AOF 文件比 RDB 文件大。 综合上述五个方面的比较，考虑在系统出现宕机等故障时，需要在最短时间内通过重启等 方式重新建立服务，因此开发团队最终选择了 RDB 方式。
本问题考查 Redis 持久化存储的基本概念及应用。
Redis 提供了两种持久化存储的机制，分别是 RDB(Redis DataBase)持久化方式和 AOF( Append Only File)持久化方式。 RDB 持久化方式是指在指定的时间间隔内将内存中的数据 集快照写入磁盘，是 Redis 默认的持久化方式。 AOF 方式是指 redis 会将每一个收到的写 命令都通过 write 函数追加到日志文件中。
两种方式各有优缺点，大致的比较如下 ： (1)磁盘更新频率： AOF 比 RDB 文件更新频率高。 (2)数据安全： AOF 比 RDB 更安全。
(3)数据一致性:RDB 间隔一段时间存储，可能发生数据丢失和不一致;AOF 通过 append 模式 写文件，即使发生服务器宕机，也可通过 redis-check-aof 工具解决数据一致性问题。 (4)重启性能： RDB 性能比 AOF 好。
(5)数据文件大小:AOF 文件比 RDB 文件大。 该项目的实际需求是：在系统出现宕机等故障时，需要在最短时间内通过重启等方式重新 建立服务，因此重启性能是最需要考虑的因素，故该开发团队选样 RDB 方式。
【问题】
失效场景：如果“定期删除”没删除 KEY,也没即时去请求 KEY,也就是说“惰性删除”也没 生效。这样， Redis 默认的“定期删除+惰性删除”策略就失效了。 对此，可采用内存淘汰机制解决： (1)从已设置过期时间的数据集最近最少使用的数据淘汰。 (2)从已设置过期时间的数据集将要过期的数据淘汰。 (3)从已设置过期时间的数据集任意选择数据淘汰。 (4)从数据集最近最少使用的数据淘汰。
(5)从数据集任意选择数据淘汰。
本问题考查 Redis 使用过程中数据清除相关的概念。 缓存中一般用来存储当前的热点数据， Redis 为每个 KEY 值都设置了过期时间，以提高缓 存命中率。为了清除非热点数据， Redis 选择“定期删除+惰性删除”策略。 “定期删除+惰性删除”策略也会存在失效的可能。比如，如果“定期删除”没删除 KEY, 也没即时去请求 KEY,也就是说“惰性删除”也没生效。这样， Redis 默认的“定期删除+ 惰性删除”策略就失效了。
如果该策略失效， Redis 内存使用率会越来越高，一般应采用内存淘汰机制来解决。常见 的内存淘汰机制有：
(1)从已设置过期时间的数据集最近最少使用的数据淘汰。 (2)从已设置过期时间的数据集将要过期的数据淘。 (3)从已设置过期时间的数据集任意选择数据淘汰。 (4)从数据集最近最少使用的数据淘汰。 (5)从数据集任意选择数据淘汰。
试题五 答案： 解析： ( )(a) (b) ( )(d) (f)
( )(c) (e)
本题考查 Web 系统架构设计相关知识及如何在实际问题中综合应用。 此类题目要求考生认真阅读题目对现实系统需求的描述，结合 Web 系统设计相关知识、实 现技术等完成 Web 系统分析设计。 软件质量属性有可用性、可修改性、性能、安全性、可测试性、易用性等。可用性关注的 是系统产生故障的可能性和从故障中恢复的能力；性能关注的是系统对事件的响应时间： 安全性关注的是系统保护合法用户正常使用系统、阻止非法用户攻击系统的能力；可测试 性关注的是系统发现错误的能力；易用性关注的是对用户来说完成某个期望任务的容易程 度和系统所提供的用户支持的种类。
【问题】
( )(a)
( )(c)
( )(d)
( )(k)
( )(j)
( )(h)
( )(i)
SSM 框架是 springMVC, spring 和 Mybatis 框架的整合，是标准的 MVC 模式。其使用 springMVC 负责请求的转发和视图管理； spring 实现业务对象管理； Mybatis 作为数据对 象的持久化引擎。
因此，基于 SSM 的工业设备监测系统设计架构如下图所示。
【问题】 该工业设备检测系统需与不同设备进行数据交互，采用标准的数据访问机制可以在硬件供 应商和软件开发商之间建立一套完整的规则。只要遵循这套规则，数据交互对两者来说都 是透明的，硬件供应商只需考虑应用程序的多种需求和传输协议，软件开发商也不必了解 硬件的实质和操作过程，实现对设备数据采集的统一管理。
标准的数据访问机制可以在硬件供应商和软件开发商之间建立一套完整的规则。只要遵循 这套规则，数据交互对两者来说都是透明的，硬件供应商只需考虑应用程序的多种需求和 传输协议，软件开发商也不必了解硬件的实质和操作过程，实现对设备数据采集的统一管 理。
例如， OPC (OLEforProcessControl)即用于过程控制的 OLE,是一个工业标准。 OPC 是为了 不同供应厂商的设备和应用程序之间的软件接口标准化，使其间的数据交换更加简单化的 目的而提出的。作为结果，可以向用户提供不依赖于特定开发语言和开发环境且可以自由 组合使用的过程控制软件组件产品。利用 OPC 的系统，是由按照应用程序(客户程序)的要 求提供数据采集服务的 OPC 服务器，使用 OPC 服务器所必需的 OPC 接口，以及接受服务的 OPC 应用程序所构成。 OPC 服务器是按照各个供应厂商的硬件所开发的，使之可以吸收各 个供应厂商硬件和系统的差异，从而实现不依存于硬件的系统构成。同时利用一种叫作 Variant 的数据类型，可以不依存于硬件中固有数据类型。
