[软考高级-系统架构设计师-2020年下半年]下午考试主观题-案例分析真题

1.应该采用仓库风格。（5分）
2.表（1）-（4）空的空白处分别为：（8分）
（1）数据存储在中心仓库，处理流程独立，支持交互式处理
（2）数据与处理紧密关联，调整处理流程需要系统重新启动
（3）数据与处理分离，需要加载数据，性能降低
（4）数据处理组件之间一般无依赖关系，可并发调用，提高性能

【解析】
在管道-过滤器风格的软件体系结构中，每个构件都有一组输入和输出，数据输入构件，经过内部处理，然后产生数据输出。因此，这里的构件被称为过滤器，这种风格的连接件就像是数据流传输的管道，将一个过滤器的输出传到另一过滤器的输入。
在仓库（repository）风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存储上执行。一方面，若构件控制共享数据，则仓库是一传统型数据库；另一方面，若中央数据结构的当前状态触发进程执行的选择，则仓库是一黑板系统。
通过交互方式、数据结构、控制结构和扩展方法分别对仓库风格和管道过滤器风格进行对比，如下所示：
交互方式：管道-过滤器很明显是顺序结构或循环结构，数据在管理中进行传递。而仓库结构是数据在中心位置，所有的处理均是中心节点与周边节点之间的交互，从形态来看，是星型的。
数据结构：从数据结构来看，仓库风格会使用一个文件将数据保存起来，所有的操作围绕这个文件进行。而管道-过滤器则是在过滤器之间传递数据流。
控制结构：从控制结构来说仓库风格是业务功能驱动，而管道-过滤器是由数据流驱动的。
扩展方法：从扩展方法来讲，管道-过滤器是通过过滤器提供标准接口与其它过滤器对接，而数据仓库风格，要共享数据，扩展功能，只要功能的操作与数据模型本身是匹配的就行了，就像我们要共享一个数据库做系统集成，此时共享同一数据库的多个应用系统所用的数据模型一定会是一致的，否则无法去共享。

（1）安全性
（2）可修改性
（3）g
（4）i
（5）f
（6）j

【解析】
本题主要考查考生对于软件质量属性的理解、掌握和应用。本题考查的是架构设计过程中涉及的一些质量属性，以及架构风格的对比。常用的质量属性包括：
1、性能
性能（performance）是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。
2、可靠性
可靠性（reliability）是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。
3、可用性
可用性（availability）是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
4、安全性
安全性（security）是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。
5、可修改性
可修改性（modifiability）是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。
6、易用性
软件开发工具应有十分友好的用户界面，用户乐于使用；工具应能剪裁和定制，以适应特定用户的需要；工具应能提示用户的交互操作，提供简单有效的执行方式；工具还应能检查用户的操作错误，尽可能自动改正错误。
识别软件架构质量属性是进行架构设计的重要步骤。根据对相关质量属性的定义和含义，其中：“c）系统应该具备完善的安全防护措施，能够对黑客的攻击行为进行检测和防御”、“i）系统需要针对代码仓库的所有操作进行详细记录；便于后期查阅与审计”属于安全性；“h）系统支持硬件设备灵活扩容，应保证在2人•天内完成”、“j）更改系统web界面风格需要在4人•天内完成”描述的是系统的可修改性；“g）在正常负载情况下，用户的代码提交请求应在0.5s内完成”描述的是性能属性；“d）系统主站点断电后，应在3s内将请求重定向到备用站点”、“f）系统宕机后，需要在15s内发现错误，并启用备用系统” 描述的是系统的可用性。

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

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

【解析】
当较低层次上实体类型表达了与之联系的较高层次上的实体类型的特殊情况时，就称较高层次上实体类型为超类型，反之为子类型。子类到超类的过程为概化，超类到子类的过程为特化。
①子类与超类之间具有继承特点，即子类包含了超类的所有属性，并且可以比超类拥有更多的属性。
②这种继承性是通过子类实体和超类实体有相同的实体标识符实现的。

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

【解析】
可以从其它属性得来的属性就叫派生属性。包裹图中的“总计”属性是派生属性。可以从资费、挂号费、保价费、回执费累加计算出来。

（1）软件需求通常以非正规的自然语言形式频繁获取。而软件架构则更倾向于使用一种更为正式、结构化的语言来描述系统的组件、接口、通信和交互方式。
（2）非功能属性（如性能、安全性、可用性等）在软件需求中通常被描述为系统属性，但在架构模型中形成规约却较为困难。这是因为非功能属性往往涉及多个系统组件和交互，需要综合考虑多个方面，而架构模型则可能更侧重于描述系统的结构和功能。
（3）从软件需求映射到软件架构的过程中，保持一致性和可追溯性也是一个复杂的任务。由于单一的软件需求可能涉及多个软件架构的关注点，而一个架构元素也可能对应多个软件需求，因此确保它们之间的映射关系是准确且可追溯的非常重要。

【解析】
在软件开发过程中，软件需求和软件架构是两个至关重要的组成部分，但它们之间确实存在一些明显的差异和挑战。
首先，软件需求通常以非正规的自然语言形式频繁获取，这主要是因为需求往往来源于业务用户、产品经理或利益相关者，他们习惯于使用日常语言和概念来表达他们的期望和需要。而软件架构则更倾向于使用一种更为正式、结构化的语言来描述系统的组件、接口、通信和交互方式。这种语言差异可能会导致在理解和沟通上的障碍。
其次，非功能属性（如性能、安全性、可用性等）在软件需求中通常被描述为系统属性，但在架构模型中形成规约却较为困难。这是因为非功能属性往往涉及多个系统组件和交互，需要综合考虑多个方面，而架构模型则可能更侧重于描述系统的结构和功能。因此，如何在架构中准确、全面地描述非功能属性是一个挑战。
最后，从软件需求映射到软件架构的过程中，保持一致性和可追溯性也是一个复杂且困难的任务。由于单一的软件需求可能涉及多个软件架构的关注点，而一个架构元素也可能对应多个软件需求，因此确保它们之间的映射关系是准确且可追溯的非常重要。这需要采用适当的需求管理和架构设计技术，以确保需求和架构之间的紧密联系和对应关系。

操作系统服务段：这是FACE架构的基础，负责提供操作系统、运行时环境和操作系统级的健康监控服务。它通过开放式OSGi框架，为上层功能提供标准化的操作系统接口，并支持上层组件的即插即用能力。
I/O服务段：这个服务段主要负责对专用I/O设备进行抽象，以简化平台服务段软件与硬件设备之间的交互。然而，由于图形服务软件和GPU处理器的紧密关系，I/O服务段并不对GPU驱动进行抽象。
平台服务段：此服务段提供了用户所需的共性软件服务，如系统级健康监控、配置管理、日志记录和流媒体服务等。它进一步细分为平台公共服务、平台设备服务和平台图像服务三类。
传输服务段：作为数据传输的核心，该服务段主要为上层可移植组件段提供平台性的数据交换服务。它确保可移植组件之间通过标准接口进行通信，禁止组件间的直接调用。
可移植组件段：这是FACE架构中提供多组件使用能力和功能服务的部分。它主要包括公共服务和可移植组件两类。

【解析】
FACE架构由五个主要的服务段组成，每个服务段都扮演着特定的角色，以确保系统的高效、可靠和模块化运行。以下是这五个服务段的简要描述：
操作系统服务段：这是FACE架构的基础，负责提供操作系统、运行时环境和操作系统级的健康监控服务。它通过开放式OSGi框架，为上层功能提供标准化的操作系统接口，并支持上层组件的即插即用能力，使得系统的扩展和维护变得更为便捷。
I/O服务段：这个服务段主要负责对专用I/O设备进行抽象，以简化平台服务段软件与硬件设备之间的交互。然而，由于图形服务软件和GPU处理器的紧密关系，I/O服务段并不对GPU驱动进行抽象，以确保图形处理的高效性和直接性。
平台服务段：此服务段提供了用户所需的共性软件服务，如系统级健康监控、配置管理、日志记录和流媒体服务等。它进一步细分为平台公共服务、平台设备服务和平台图像服务三类，以满足不同应用场景的需求。
传输服务段：作为数据传输的核心，该服务段主要为上层可移植组件段提供平台性的数据交换服务。它确保可移植组件之间通过标准接口进行通信，禁止组件间的直接调用，从而提高了系统的可移植性和互操作性。
可移植组件段：这是FACE架构中提供多组件使用能力和功能服务的部分。它主要包括公共服务和可移植组件两类，使得开发者能够基于这些组件快速构建和部署应用程序，同时确保这些应用程序在不同平台上的可移植性。
综上所述，FACE架构的五个服务段共同协作，为开发者提供了一个高效、可靠和模块化的软件开发环境。

（1）紧耦合问题通常指的是系统中不同部分之间的高度依赖关系。主要变现在：I/O问题、业务逻辑问题、表现问题。
为了解决紧耦合问题，可以采用分离原则。这意味着将系统的不同部分（如I/O、业务逻辑、表现层等）进行隔离，使得它们之间的依赖关系尽可能少。
（2）封装通过将对象的属性和方法隐藏起来，只提供必要的接口供外部调用，主要表现在：
ICD硬编码问题、组件的紧耦合问题、直接调用问题
为了解决封装问题，可以采用提供数据源或槽的软件服务的方法。将紧耦合组件分解出应用程序，并将平台相关部分加入计算环境中，在计算平台内提供数据源或槽的软件服务，并实现接口标准化。

【解析】
紧耦合问题通常指的是系统中不同部分之间的高度依赖关系，这种依赖关系可能导致系统难以维护、扩展和测试。
I/O问题：当I/O操作（如文件读写、网络通信等）与业务逻辑紧密耦合时，任何I/O操作的更改都可能影响到整个业务逻辑，使得系统难以维护和扩展。
业务逻辑问题：如果业务逻辑与底层系统（如数据库、文件系统等）紧密耦合，那么在业务逻辑发生更改时，可能需要同时修改底层系统，这增加了系统的复杂性和维护成本。
表现问题：如果用户界面与业务逻辑紧密耦合，那么任何用户界面的更改都可能影响到业务逻辑，这限制了用户界面的灵活性和可定制性。
为了解决紧耦合问题，可以采用分离原则。这意味着将系统的不同部分（如I/O、业务逻辑、表现层等）进行隔离，使得它们之间的依赖关系尽可能少。通过定义明确的接口和协议，不同部分之间可以通过这些接口进行通信，而不需要直接访问对方的内部实现。
接下来，我们来看封装问题。封装是面向对象编程中的一个重要概念，它通过将对象的属性和方法隐藏起来，只提供必要的接口供外部调用，从而保护对象的内部状态和数据安全。然而，在某些情况下，封装可能会出现问题，如：
ICD硬编码问题：当接口控制文档（ICD）中的信息被硬编码到代码中时，任何ICD的更改都需要修改代码，这增加了系统的维护成本。
组件的紧耦合问题：如果组件之间的依赖关系过于紧密，那么一个组件的更改可能会影响到其他组件，导致系统难以维护和扩展。
直接调用问题：当组件之间直接调用彼此的接口时，如果接口发生变化，可能需要修改多个组件的代码，这增加了系统的复杂性。
为了解决封装问题，可以采用提供数据源或槽的软件服务的方法。这意味着将紧耦合的组件分解出应用程序，并将平台相关部分加入计算环境中。在计算平台内，提供数据源或槽的软件服务，这些服务可以封装底层系统的复杂性和变化性，为上层应用提供稳定、可靠的接口。同时，通过实现接口标准化，可以确保不同组件之间可以通过标准接口进行通信，降低了系统的复杂性和维护成本。

（1） (a)
（2） (b)、(g)
（3） (c)、(d)
（4） (f)
（5） (e)

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

【解析】
Redis中的两种主要持久化机制：RDB（Redis Database）和AOF（Append Only File）。RDB是通过在指定的时间间隔内将内存中的数据集快照写入磁盘来实现持久化的，而AOF则是将每一个写命令都追加到日志文件中。
两种方式的比较主要包括：（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针对过期的key使用的清除策略，策略为：定期删除+惰性删除。
1、定期删除：
redis会将每个设置了过期时间的key放入到一个独立的字典中，以后会定期遍历这个字典来删除到期的key。redis默认是每隔100ms就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。注意这里是随机抽取的。为什么要随机呢？你想一想假如redis存了几十万个key ，每隔100ms就遍历所有的设置过期时间的key的话，就会给CPU带来很大的负载。
2、惰性删除：
所谓惰性策略就是在客户端访问这个key的时候，redis对key的过期时间进行检查，如果过期了就立即删除，不会给你返回任何东西。
定期删除可能会导致很多过期key到了时间并没有被删除掉。所以就有了惰性删除。假如你的过期 key，靠定期删除没有被删除掉，还停留在内存里，除非你的系统去查一下那个 key，才会被redis给删除掉。这就是所谓的惰性删除，即当你主动去查过期的key时,如果发现key过期了，就立即进行删除，不返回任何东西。
由于redis定期删除是随机抽取检查，不可能扫描清除掉所有过期的key并删除，然后一些key由于未被请求，惰性删除也未触发。这样redis的内存占用会越来越高。此时就需要内存淘汰机制。
主要有如下一些策略：
1、volatile-lru：从设置过期时间的数据集中挑选出最近最少使用的数据淘汰。没有设置过期时间的key不会被淘汰，这样就可以在增加内存空间的同时保证需要持久化的数据不会丢失。
2、volatile-ttl：除了淘汰机制采用LRU，策略基本上与volatile-lru相似，从设置过期时间的数据集中挑选将要过期的数据淘汰，ttl值越小越优先被淘汰。
3、volatile-random：从已设置过期时间的数据集中任意选择数据淘汰。当内存达到限制无法写入非过期时间的数据集时，可以通过该淘汰策略在主键空间中随机移除某个key。
4、allkeys-lru：从数据集中挑选最近最少使用的数据淘汰，该策略要淘汰的key面向的是全体key集合，而非过期的key集合。
5、allkeys-random：从数据集中选择任意数据淘汰。
6、no-enviction：禁止驱逐数据，也就是当内存不足以容纳新入数据时，新写入操作就会报错，请求可以继续进行，线上任务也不能持续进行，采用no-enviction策略可以保证数据不被丢失，这也是系统默认的一种淘汰策略。

（1）a、b
（2）d、f
（3）c、e

【解析】
本题考查的是架构设计过程中涉及的一些质量属性。常用的质量属性包括：
1、性能
性能（performance）是指系统的响应能力，即要经过多长时间才能对某个事件作出响应，或者在某段时间内系统所能处理的事件的个数。
2、可用性
可用性（availability）是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
3、安全性
安全性（security）是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。
4、可修改性
可修改性（modifiability）是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考查这些变更的代价衡量可修改性。
5、可靠性
可靠性（reliability）是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。
6、易用性
软件开发工具应有十分友好的用户界面，用户乐于使用；工具应能剪裁和定制，以适应特定用户的需要；工具应能提示用户的交互操作，提供简单有效的执行方式；工具还应能检查用户的操作错误，尽可能自动改正错误。

（1）a
（2）c
（3）d
（4）k
（5）j
（6）h
（7）i

【解析】
Spring是一个轻量级的企业级应用开发框架，于2004年由Rod Johnson发布了1.0版本，经过多年的更新迭代，已经逐渐成为Java开源世界的第一框架，Spring框架号称Java EE应用的一站式解决方案，与各个优秀的MVC框架如SpringMVC、Struts2、JSF等可以无缝整合，与各个ORM框架如Hibernate、MyBatis、JPA等也可以无缝衔接，其他各种技术也因为Spring的存在而被很容易地整合进项目开发之中，如Redis整合、Log4J整合等等。
SpringMVC是Spring框架体系中的全功能MVC模块。SpringMVC是基于Java语言实现MVC设计模式的请求驱动类型的轻量级Web框架，目的是将Web开发模块化及代码简化。其提供了DispatcherServlet前端控制器分派请求，同时提供灵活的配置处理程序映射、视图解析，并支持文件上传，目前已经是众多MVC框架中的佼佼者。
MyBatis的前身是 Apache社区的一个开源项目iBatis，于2010年更名为MyBatis。MyBatis是支持定制化SQL、存储过程以及高级映射的优秀的持久层框架，避免了几乎所有的JDBC代码和手动设置参数以及获取结果集，使得开发人员更加关注SQL本身和业务逻辑，不用再去花费时间关注整个复杂的JDBC操作过程。
Spring+spring mvc+mybatis整合的框架组件图如下所示：

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

【解析】
在工业设备检测系统中，采用标准的数据访问机制是实现高效、可靠且灵活的数据交互的关键。这种机制通过定义一套统一的规则和接口，确保了不同设备之间的无缝连接和数据流通，无论这些设备来自不同的硬件供应商还是服务于多样化的应用场景。而标准数据访问机制在工业设备检测系统中发挥着至关重要的作用，比如：
（1）提高数据交互的透明性：对于硬件供应商和软件开发商而言，标准数据访问机制使得数据交互过程变得透明。硬件供应商只需关注如何按照标准接口提供数据，而软件开发商则只需关注如何接收和处理这些数据，无需关心背后的硬件实现。
（2）促进设备兼容性和互操作性：通过遵循统一的标准，不同品牌和型号的工业设备能够更容易地实现兼容和互操作，从而降低了系统集成和部署的复杂性。
（3）增强系统的可扩展性和可维护性：随着企业规模的扩大和业务需求的变化，可能需要引入新的设备或升级现有系统。标准数据访问机制使得这些变更更加容易实现，因为新设备或系统只需遵循相同的标准即可与现有系统无缝集成。