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

操作性需求（Operational Requirements）：指系统完成任务所需的操作环境要求及如何满足系统将来可能的需求变更的要求。
性能需求（Performance Requirements）：针对系统性能要求的指标。常见的包括：系统响应请求的速度（响应时间）和单位时间内处理请求的能力（吞吐率）。
安全性需求（Security Requirements）：这涉及一系列保护措施或预防措施，旨在防止系统崩溃和确保数据的安全性。
文化需求（Cultural Requirements）：使用本系统的不同用户群体对系统提出的特有要求。

【解析】
本题考到了一个极为少见的非功能性需求分类方式：
操作性需求（Operational Requirements）：指系统完成任务所需的操作环境要求及如何满足系统将来可能的需求变更的要求。
性能需求（Performance Requirements）：针对系统性能要求的指标。常见的包括：响应时间、吞吐率。
安全性需求（Security Requirements）：防止系统崩溃和保证数据安全所需要采取的保护措施或预防措施。
文化需求（Cultural Requirements）：使用本系统的不同用户群体对系统提出的特有要求。
这些需求进一步可拆分为：
操作性需求包括：技术环境需求、系统集成需求、可移植性需求、维护性需求
性能需求包括：速度需求、容量需求、可靠性需求
安全性需求包括：系统价值需求、访问控制需求、加密/认证需求、病毒控制需求
文化需求包括：多语言需求、个性化定制需求、规范性描述需求、法律需求

（1）（b）（d）
（2）（c）（f）
（3）（e）（g）
（4）（a）（h）

【解析】
本问题主要要求考生在理解软件的特殊性基础上，深刻认识软件可靠性一般是致力于系统性地减少和消除对软件程序性能有不利影响的系统故障。除非被修改，否则软件系统不会随着时间的推移而发生退化。在掌握这一特征的基础上，可以回答硬件可靠性特征与其对应的软件可靠性特征之间的差异或相似之处。

瘦客户端C/S架构能更好满足：（a）（b）（d）（h）

【解析】
问题3主观性比较强，其实题目中提到的这些要求，如果要做，两种架构都是能完成的。所以在此对比一下相对优势。
（a）无论胖还是瘦，要做到用户界面的个性化都没有问题，但从更新的角度来看，胖客户端针对新增的个性化要求，更新起来比较困难。所以相对来说，瘦客户端更有优势。
（b）从单次实现来看，都能实现，但要随时保持最新，瘦客户端更有优势。
（c）胖客户端，在客户端的运算能力上强一些。
（d）瘦客户端将业务逻辑迁移到应用服务器上，所以有故障只要修复服务器上的内容，而胖客户端要更新所有客户端，工作量大，所以此情况下瘦客户端有优势。
（e）瘦客户端与胖客户端无明显差异。
（f）胖客户端做到2G数据缓存很容易，而瘦客户端不容易实现。
（g）瘦客户端与胖客户端无明显差异。
（h）瘦客户端与胖客户端均可做到，但若涉及更新，瘦客户端有优势。

E1：房主 E2：租赁者
P1：登记房主信息 P2：登记房屋信息
P3：登记租赁者信息 P4：查询租赁房屋信息
P5：安排看房 P6：变更房屋状态
D1：房主信息文件 D2：租赁者信息文件
D3房屋信息文件 D4：看房记录文件

【解析】
外部实体可以是和系统交互的人或角色，以及和系统交互的外部系统或服务。根据题目中的描述，与本系统进行交互的角色是房主和租赁者。根据E1和P1之间的数据流 “房主信息”，结合题目描述可知，E1表示的是房主，E2表示的是租赁者。
题目的描述中已经明确给出了系统的6个功能，需要将这些功能与加工P1-P6进行对应，这需要借助于各个加工的输入输出数据流进行分析，根据E1和P1之间的数据流“房主信息”可知，这条数据流符合“登记房主信息”功能的描述，因此可以确定P1是“登记房主信息”，同时可以确定D1是“房主信息文件”。E1和P2之间的数据流“房屋信息”“费用单”，这些都与房屋登记相关，因此P2是“登记房屋信息”。同时可以确定，D3对应的是“房屋信息文件”。同理，根据数据流及题干描述，可以推断出：P3对应“登记租赁者信息”、P4对应“查询租赁房屋信息”、P5对应“安排看房”以及P6对应“变更房屋状态”。

（1）房主 （2）房屋 （3）房屋类型 （4）租赁者 （5）看房安排

【解析】
本问题考查信息工程方法中的模型ER图。ER图中包含两个主要元素：实体和联系。实体是现实世界中可以区别于其他对象的“事件”或“物体”，本题要求补充图2-2中的实体。根据题目描述和实体之间的联系可知，（1）和（2）分别对应房主和房屋，两者之间的联系为“房主拥有房屋”。同理可以推断出，（3）~（5）分别是实体“房屋类型” “租赁者”和“看房安排”。

（1）实体用于数据建模，而类用于面向对象建模。实体只有属性，而类有属性和操作。
（2）Essential Use Cases 可翻译为抽象用例，而Real Use Cases可翻译为基础用例。
他们的区别在于：Essential Use Cases 用于分析阶段，Real Use Cases 用于设计阶段。
Essential Use Cases 描述用例的本质属性，它与如何实现这个用例无关，独立于实现该用例的软硬件技术。
Real Use Cases 描述的是用例的实现方式，表达了设计和实现该用例时所采用的方法和技术。

【解析】
Essential Use Cases和Real Use Cases是按照开发阶段来进行划分的。Essential Use Cases是在面向对象分析阶段使用的，Real Use Cases是在面向对象设计阶段使用的。Essential Use Cases 描述的是用例的本质属性，它与如何实现这个用例无关，独立于实现该用例的软硬件技术。
Real Use Cases 描述的是用例的实现方式，表达了设计和实现该用例时所采用的方法和技术。

（1）（c） （2）（d） （3）（o） （4）（p）
（5）（g） （6）（h） （7）（k） （8）（l）
（9）（i） （10）（j） （11）（n） （12）（m）
（13）（e） （14）（f）

【解析】
简单任务和复杂任务的特征区分主要表现为以下十个方面：
（1）静态/动态特性：简单任务的时序关系是确定不变的，不会随时间偏移而变化。而随着复杂系统任务多样化发展，复杂任务将会随着时间、状态变化而变化。
（2）连续性/非连续性：简单任务仅仅考虑变量的随机性，而不考虑数据的继承性。而复杂任务由于受环境影响，其变量域需要考虑时间上的连续特性，及数据的继承关系。
（3）系统间的独立性：简单任务由于功能单一，仅仅需要考虑内部任务间交联关系，具备独立性。而复杂任务间有很高的交互操作，要把一个任务的行为隔离开是非常困难的。
（4）顺序/并行性：简单任务由于功能单一、时序简单，通常情况下任务是顺序执行的，缺少并行性。而复杂任务功能、状态复杂，其属性与时间紧密相关，必然存在许多并行执行因子，并行性强。
（5）单一/混合性：简单任务由于功能单一，其内部算法、执行策略都是单一的、不会随状态变迁而改变。而由于复杂任务的多样化，其任务内会存在不同构型、策略和算法，甚至对于不同状态任务需要综合考虑影响因子后方能决策，其混合性比较强。
（6）工作原理：简单任务执行时仅仅考虑上下因果关系，无需考虑结果。而复杂任务必须考虑根据上下文反馈信息来决策处理流程。
（7）线性/非线性：简单任务执行的功能一般呈现线性关系，功能间的上下关系是线性的。而复杂任务必须考虑根据多个上下文功能的结果决策处理流程，是非线性的。
（8）上下文相关性：简单任务由于功能简单并呈现线性特征，其功能原理必然与上下文无关。而复杂任务属于非线性特征，其功能原理必然与上下文相关。
（9）规律/不规律：简单任务的特征是规则整齐、原则清晰。而复杂任务由于上下文相关，其规则与上下文存在关系，缺少规律性。
（10）表面属性：简单任务对外特征明显，比较好识别。而复杂任务由于其多样化，其外表特征被覆盖或抽象，对外表现不明显，不好识别。

BMTS的消息通信网络主要特征为：一个计算组件传输消息到另一个或多个接收组件，传输可靠性高，延迟低，抖动微小。
事件触发消息：以事件作为触发方式，事件发生便触发相应消息。
速率约束消息：消息偶发性产生，而不考虑发送者承诺消息不超出最大消息速率。
时间触发消息：发送者和接收者遵循一个精确的时间片周期完成消息的发送与接收。
具有时间触发消息能力的网络总线：
航空电子全双工交换式以太网（Avio nics Full Duplex Switched Ethernet，AFDX）
时间触发以太网（Time-Triggered Ethernet，TTE）
FC（Fiber Channel）总线

【解析】
BMTS支持事件触发消息、速率约束消息和时间触发消息等三种基本消息传输。
（1）事件触发消息（Event-Triggered Messages）： 事件触发消息是在发送端发生特定重要事件时产生的。这类消息是偶发的，并且没有固定的发送间隔或最小时间要求。因此，从消息产生到接收之间的延迟是不可预测的。当发送这类消息时，BMTS系统可能需要同时处理多个消息，因此必须确保在发送者或消息丢失时能够采取适当的处理措施。
（2）速率约束消息（Rate-Constrained Messages）： 速率约束消息是偶发性产生的，但发送者会确保消息发送的速率不会超过一个预定的最大值。在正常的系统操作条件下，BMTS系统会确保这类消息的传输时延不会超过一个设定的上限（Latency）。然而，实际的传输时延可能会因为网络负载的变化而有所不同，从而产生一定的抖动。抖动的范围通常取决于网络负载以及在最坏情况下的传输时延和最小传输时延之间的差异。
（3）时间触发消息（Time-Triggered Messages）： 时间触发消息是基于一个精确的时间片周期进行发送和接收的。发送者和接收者都会遵循这个周期来确保消息的同步性。在正常的系统操作条件下，BMTS系统会确保这类消息在指定的时间片和一定的抖动条件下进行发送或接收。这种同步性对于需要高精度控制和协调的应用场景至关重要。

当前，具有时间触发消息能力的网络总线：TTE总线、FC总线、AFDX总线。

分布式数据库缓存指的是在高并发环境下，为了减轻数据库压力和提高系统响应时间，在数据库系统和应用系统之间增加的独立缓存系统。
（1）key/value，list，set，string，sorted 或 丰富/多种数据结构
（2）不支持
（3）客户端哈希分片/一致性哈希
（4）Redis5.0及以前版本不支持
（5）有，私有内存池
（6）不支持

【解析】
本题主要考查概念性内容。
MemCache与Redis主要的差异表现在以下方面：
1、Redis和MemCache都是将数据存放在内存中，都是内存数据库。它们都支持key-value数据类型，同时MemCache还可用于缓存其他东西，例如图片、视频等等，Redis还支持list、set、string等数据结构的存储。
2、Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。MemCache挂掉之后，数据就没了。
3、灾难恢复-MemCache挂掉后，数据不可恢复； Redis数据丢失后可以恢复。
4、在Redis中，并不是所有的数据都一直存储在内存中的。这是和MemCache相比一个最大的区别。当物理内存用完时，Redis可以将一些很久没用到的value交换到磁盘。
5、Redis在很多方面支持数据库的特性，可以这样说他就是一个数据库系统，而MemCache只是简单地K/V缓存。
所以在选择方面如果有持久方面的需求或对数据类型和处理有要求的应该选择Redis。如果简单的key/value存储应该选择MemCache。

（1）MemCache没有持久化功能，所以掉电数据会全部丢失，而且无法直接恢复，这存在可靠性问题。
（2）MemCache不支持事务，所以操作过程中可能产生数据的不一致性。
同步方案：
读取数据时，先读取Redis中的数据，如果Redis没有，则从原数据库中读取，并同步更新Redis中的数据。写回时，写入到原数据库中，并同步更新至Redis中。

【解析】
MemCache和Redis在数据可靠性和一致性方面存在显著的差异，这些差异对于选择哪种工具作为缓存系统至关重要。
首先，MemCache是一个纯内存缓存系统，它不支持数据的持久化。这意味着当MemCache服务重启或服务器宕机时，所有存储在其中的数据都会丢失。相比之下，Redis则提供了更为丰富的数据结构和更为强大的功能，其中就包括数据的持久化。Redis支持将数据以快照或日志的形式保存到磁盘上，以确保在服务器重启或宕机后数据不会丢失。这种持久化机制使得Redis在数据可靠性和一致性方面要优于MemCache。
因此李工的方案存在数据可靠性和一致性问题，而刘工的方案解决了该问题。刘工的方案中，保留原有关系数据库，将Redis仅作为缓存，即热点数据缓存在Redis中，核心业务的结构化数据存储在原有关系数据库中，由于Redis只作为缓存，因此给出原关系数据库到Redis的同步方案即可。该方案的基本操作如下：
读操作，当应用程序需要读取数据时，首先会尝试从Redis缓存中读取。如果Redis中没有所需的数据（缓存未命中），那么应用程序就会从原有关系数据库中读取数据，并将读取到的数据写入到Redis缓存中。这样，在下次需要读取相同数据时，就可以直接从Redis缓存中获取，而无需再次访问关系数据库。
写操作，写原关系数据库，写成功后，更新或者失效掉缓存Redis中的值。

Redis分布式存储的常见方案：
1、主从模式（Master/Slave）
2、哨兵模式（Sentinel）
3、集群模式（Cluster）
Redis集群切片的常见方式：
1、客户端分片，即在客户端就通过key的hash值对应到不同的服务器。
2、中间件实现分片。在应用软件和Redis中间，例如：Twemproxy、Codis等，由中间件实现服务到后台Redis节点的路由分派。
3、客户端服务端协作分片。Redis Cluster模式，客户端可采用一致性哈希，服务端提供错误节点的重定向服务slot上。不同的slot对应到不同服务器。

【解析】
Redis作为一个高性能的内存数据存储系统，为了支持大规模的数据存储和访问，提供了多种分布式存储的集群拓展能力。Redis分布式存储的常见方案有主从（Master/Slave）模式、哨兵（Sentinel）模式、集群（Cluster）模式。Redis集群切片的常见方式有：
（1）客户端实现分片方式，分区逻辑在客户端实现，采用一致性哈希来决定Redis节点。
（2）中间件实现分片方式，即在应用软件和Redis中间，例如Twemproxy、Codis等，由中间件实现服务到后台Redis节点的路由分派。
（3）客户端服务端协作分片方式，Redis Cluster模式。客户端可采用一致性哈希，服务端提供错误节点的重定向服务。

SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用方式进行交互。
ESB作用于特点：
1、SOA的一种实现方式，ESB在面向服务的架构中起到的是总线作用，将各种服务进行连接与整合；
2、描述服务的元数据和服务注册管理；
3、在服务请求者和提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式如同步模式、异步模式等；
4、发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。高级一些的能力，包括对安全的支持、服务质量保证、可管理性和负载平衡等。

【解析】
从应用的角度定义，可以认为SOA是一种应用框架，它着眼于日常的业务应用，并将它们划分为单独的业务功能和流程，即所谓的服务。SOA 使用户可以构建、部署和整合这些服务，且无需依赖应用程序及其运行平台，从而提高业务流程的灵活性。这种业务灵活性可使企业加快发展速度，降低总体拥有成本，改善对及时、准确信息的访问。SOA 有助于实现更多的资产重用、更轻松的管理和更快的开发与部署。
从软件的基本原理定义，可以认为SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。

（1）（c）业务层 （2）（i）UDDI （3）（h）publish
（4）（e）企业服务总线ESB （4）（g）安全验证和质量管理 （6）（j）组件层

【解析】
通过阅读题目中银行信息系统的实际需求可知，在信息整合的过程中，银行使用企业服务平台构建全行应用系统的整合平台。在纵向上，连接总分行各个系统；在横向上，连接各业务应用系统和业务系统等。企业服务平台采用分级部署的方式，包括两个部分：一部分是部署在总行系统间的企业服务平台；另一部分是部署在分行系统间的企业服务平台。这两个企业服务平台之间互联互通，形成企业应用集成的总体框架。
银行信息系统的SOA架构模型中，通过ESB进行连接整合，能很好地支撑各业务流程。在操作客户关系管理中，客户信息是分散在各个业务子系统中，是不能共享的，通过基于ESB的体系架构整合后，可以实现全方位的客户管理。客户经理可以通过整合后的客户关系管理系统，一次性地查阅目标客户的基本信息、产品账户信息、地址联系信息、事件信息、资源信息、关系信息、风险信息、统计分析信息等，这就真正实现了以客户为中心的转变过程，摆脱了从前以账户为中心的局部模式。

1、引入https协议或采用加密技术对数据先加密再传输
2、采用信息摘要技术对重要信息进行完整性验证
3、防火墙系统
4、安全检测
5、网络扫描

【解析】
在SOA（面向服务的架构）环境中，确保服务的安全性是至关重要的，这涉及多个层面的保护措施。
（1）数据保密性（机密性）：保密性旨在防止未经授权的用户访问敏感数据，从而避免数据泄露。在SOA中，数据在传输和消息交换过程中均需要保护。通过实施数据加密技术，可以在不同层面（如传输层和消息层）确保数据不被未授权人员查看。
（2）数据完整性：完整性确保数据在传输或存储过程中保持其原有的正确性、一致性和完整性，防止数据被篡改或损坏。使用数字签名技术可以验证数据的来源和完整性，确保接收方收到的数据是完整且未被篡改的。
（3）审计追踪（可审计性）：审计是一种事后监控机制，用于跟踪和记录系统的访问活动。通过审计，可以及时发现并响应非法访问行为，增强系统的安全防范能力。不同的系统根据其安全需求，可能需要不同级别的审计记录和监控。
（4）身份认证管理：身份认证是确保服务请求者和服务提供者之间交互安全的首要步骤。通过相互认证对方的身份，可以防止非授权实体访问服务。这种认证过程构成了系统安全的第一道防线，对于保护服务不被非法利用至关重要。
（5）访问权限控制：授权管理涉及对Web服务访问权限的严格控制，以防止未授权用户访问敏感服务。通过实施细粒度的授权策略，可以确保只有经过授权的用户或服务才能访问特定的Web服务，从而维护系统的安全性和稳定性。
（6）身份信息管理：在SOA架构中，身份信息管理对于确保服务请求者和服务提供者之间的信任关系至关重要。与传统系统相似，SOA架构也需要有效管理服务请求者和服务提供者的身份信息，以防止身份冒充和数据篡改等安全风险。通过集中管理和验证身份信息，可以增强系统的整体安全性。
所以可以采取的措施有：引入https协议或采用加密技术对数据先加密再传输、采用信息摘要技术对重要信息进行完整性验证、防火墙系统、安全检测、网络扫描等。