2018年软考系统架构师案例分析

第1题（案例题）：

阅读以下关于软件系统设计的叙述，在答题纸上回答问题1至问题3。
【说明】
某文化产业集团委托软件公司开发一套文化用品商城系统，业务涉及文化用品销售、定制、竞拍和点评等板块，以提升商城的信息化建设水平。该软件公司组织项目组完求调研，现已进入到系统架构设计阶段。考虑到系统需求对架构设计决策的影响，项目组先列出了可能影响系统架构设计的部分需求如下：
（a） 用户界面支持用户的个性化定制；
（b） 系统需要支持当前主流的标准和服务，特别是通信协议和平台接口；
（c） 用户操作的响应时间应不大于3秒，竞拍板块不大于1秒；
（d） 系统具有故障诊断和快速恢复能力；
（e） 用户密码需要加密传输；
（f） 系统需要支持不低于2G的数据缓存；
（g） 用户操作停滞时间超过一定时限需要重新登录验证；
（h） 系统支持用户选择汉语、英语或法语三种语言之一进行操作。
项目组提出了两种系统架构设计方案：瘦客户端C/S架构和胖客户端C/S架构，经过对上述需求逐条分析和讨论，最终决定采用瘦客户端C/S架构进行设计。

【问题1】 （8分）
在系统架构设计中，决定系统架构设计的非功能性需求主要有四类：操作性需求、性能需求、安全性需求和文化需求。请简要说明四类需求的含义。
【问题2】 （8分）
根据表1-1的分类，将题干所给出的系统需求（a）~（h）分别填入（1） ~ （4）。

【问题3】 （9分）
请说明瘦客户端C/S架构能够满足题干中给出的哪些系统需求（只需要回答出三个系统需求）。

【问题1】
操作性需求（Operational Requirements）：指系统完成任务所需的操作环境要求及如何满足系统将来可能的需求变更的要求。性能需求（Performance Requirements）：针对系统性能要求的指标。常见的包括：响应时间、吞吐率。
安全性需求（Security Requirements）：防止系统崩溃和保证数据安全所需要采取的保护措施或预防措施。文化需求（Cultural Requirements）：使用本系统的不同用户群体对系统提出的特有要求。
【问题2】
（1）（b）（d）
（2）（c）（f）
（3）（e）（g）
（4）（a）（h）
【问题3】
瘦客户端C/S架构能更好满足：（a）（b）（d）（h）

所属知识点： 案例分析>系统设计
参考解析： 本题考到了一个极为少见的非功能性需求分类方式：
操作性需求（Operational Requirements）：指系统完成任务所需的操作环境要求及如何满足系统将来可能的需求变更的要求。
性能需求（Performance Requirements）：针对系统性能要求的指标。常见的包括：响应时间、吞吐率。安全性需求（Security Requirements）：防止系统崩溃和保证数据安全所需要采取的保护措施或预防措施。文化需求（Cultural Requirements）：使用本系统的不同用户群体对系统提出的特有要求。
这些需求进一步可拆分为：
操作性需求包括：技术环境需求、系统集成需求、可移植性需求、维护性需求性能需求包括：速度需求、容量需求、可信需求
安全性需求包括：系统价值需求、访问控制需求、加密/认证需求、病毒控制需求文化需求包括：多语言需求、个性化定制需求、规范性描述需求、法律需求
题目问题3主观性比较强，其实题目中提到的这些要求，如果要做，两种架构都是能完成的。所以在此对比一下相对优势。
（a） 无论胖还是瘦，要做到用户界面的个性化都没有问题，但从更新的角度来看，胖客户端针对新增的个性化要求，更新起来比较困难。所以相对来说，瘦客户端更有优势。
（b） 从单次实现来看，都能实现，但要随时保持最新，瘦客户更有优势。
（c） 胖客户端，在客户端的运算能力强一些。
（d） 瘦客户端将业务逻辑迁移到应用服务器上，所以有故障只要修复服务器上的内容，而胖客户端要更新所有客户端，工作量大，所以此情况下瘦客户端有优势。
（e） 瘦客户端与胖客户端无明显差异。
（f） 胖客户端做到2G数据缓存很容易，而瘦客户端不容易实现。
（g） 瘦客户端与胖客户端无明显差异。
（h） 瘦客户端与胖客户端均可做到，但若涉及到更新，瘦客户端有优势。

第2题（案例题）：

阅读以下关于软件系统建模的叙述，在答题纸上回答问题1至问题3。
【说明】
某公司欲建设一个房屋租赁服务系统，统一管理房主和租赁者的信息，提供快捷的租赁服务。本系统的主要功能描述如下：
1 登记房主信息。记录房主的姓名、住址、身份证号和联系电话等信息，并写入房主信息文件。
2 登记房屋信息。记录房屋的地址、房屋类型（如平房、带阳台的楼房、独立式住宅等）、楼层、租金及房屋状态（待租赁、已出租）等信息，并写入房屋信息文件。一可以在系统中登记多套待租赁的房屋。
3 登记租赁者信息。记录租赁者的个人信息，包括：姓名、性别、住址、身份证号和电话号码等，并写入租赁者信息文件。
4 安排看房。已经登记在系统中的租赁者，可以从待租赁房屋列表中查询待租赁房屋信息。租赁者可以提出看房请求，系统安排租赁者看房。对于每次看房，系统会生成房记录并将其写入看房记录文件中。
5 收取手续费。房主登记完房屋后，系统会生成一份费用单，房主根据费用单交纳相应的费用。
6 变更房屋状态。当租赁者与房主达成租房或退房协议后，房主向系统提交变更房屋状态的请求。系统将根据房主的请求，修改房屋信息文件。

【问题1】（12分）
若采用结构化方法对房屋租赁服务系统进行分析，得到如图2-1所示的顶层DFD。使用题干中给出的词语，给出图2-1中外部实体E1-E2、加工P1-P6以及数据存储D1 的名称。
【问题2】（5分）
若采用信息工程（Information Engineering）方法对房屋租赁服务系统进行分析，得到如图2-2所示的ERD。请给出图2-2中实体（1）~ （5）的名称。

【问题3】 （8分）
（1） 信息工程方法中的“实体（entity）” 与面向对象方法中的“类（class）”之间有哪些不同之处？
（2） 在面向对象方法中通常采用用例（Use Case）来捕获系统的功能需求。用例可以按照不同的层次来进行划分，其中的Essential Use Cases和Real Use Cases有区别？

【问题1】
E1：房主 E2：租赁者
P1：登记房主信息 P2：登记房屋信息
P3：登记租赁者信息 P4：查询租赁房屋信息
P5：安排看房 P6：变更房屋状态
D1：房主信息文件 D2：租赁者信息文件
D3：房屋信息文件 D4：看房记录文件
【问题2】
（1）房主 （2）房屋 （3）房屋类型 （4）租赁者 （5）看房安排
【问题3】
（1） 实体用于数据建模，而类用于面向对象建模。实体只有属性，而类有属性和操作。
（2） Essential Use Cases 可翻译为抽象用例，Real Use Cases 可翻译为基础用例。他们是区别在于：
Essential Use Cases 用于分析阶段，Real Use Cases 用于设计阶段。
Essential Use Cases 描述用例的本质属性，它与如何实现这个用例无关，独立于实现该用例的软硬件技术。
Real Use Cases 描述的是用例的实现方式，表达了设计和实现该用例时所采用的方法和技术。

所属知识点： 案例分析>系统需求分析

第3题（案例题）：

阅读以下关于嵌入式实时系统相关技术的叙述，在答题纸上回答问题1和问题2。
【说明】
某公司长期从事宇航领域嵌入式实时系统的软件研制任务。公司为了适应未来嵌入式系统网络化、智能化和综合化的技术发展需要，决定重新考虑新产品的架构问题，经证工作交给王工负责。王工经调研和分析，完成了新产品架构设计方案，提交公司高层讨论。

【问题1】 （14分）
王工提交的设计方案中指出：由于公司目前研制的嵌入式实时产品属于简单型系统，其嵌入式子系统相互独立，功能单一，时序简单。而未来满足网络化、智能化和综的嵌入式实时系统将是一种复杂系统，其核心特征体现为实时任务的机理、状态和行为的复杂性。简单任务和复杂任务的特征区分主要表现在十个方面。请参考表3-1 的实时任务特征分类，用题干中给出的（a）-（t）20个实时任务特征描述，补充完善表3-1给出的空（1）-（14）。
（a） 任务属性不会随时间变化而改变；
（b） 任务的属性与时间相关；
（c） 任务仅可以从非连续集中获取特征变量；
（d） 任务变量域是连续的；
（e） 功能原理不依赖于上下文；
（f） 功能原理依赖于上下文；
（g） 任务行为可以用step-by-step顺序分析方法来理解；
（h） 许多任务在产生访问活动时相互间是并发处理的，很难用step-by-step方法分析；
（i） 因果关系相互影响；
（j） 行为特征依赖于大量的反馈机制；
（k） 系统内构成、策略和描述是相似的；
（l） 系统内存在许多不同的构成、策略和描述；
（m） 功能关系是非线性的；
（n） 功能关系是线性的；
（o） 不同的子任务是相互独立的，任务内部仅存在少量的交互操作；
（p） 不同的子任务有很高的交互操作，要把一个单任务的行为隔离开是困难的；
（q） 域特征有非常整齐的原则和规则；
（r） 许多不同的上下文依赖于规则；
（s） 原理和规则在表面属性上很容易被识别；
（t） 原理被覆盖、抽象，而不会在表面属性上被识别。
表3-1 简单任务和复杂任务特征比较

【问题2】（11分）
王工设计方案中指出：要满足未来网络化、智能化和综合化的需求，应该设计一种能够充分表达嵌入式系统行为的、且具有一定通用性的通信架构， 以避免复杂任务些特征带来的通信复杂性。通常为了实现嵌入式系统中计算组件间的通信，在架构上需要一种简单的架构风格，用于屏蔽不同协议、不同硬件和不同结构组成所带来的性。图3-1给出了一种“腰（Waistline）” 型通信模式的架构风格。腰型架构的关键是基本消息通信（BMTS），通常BMTS的消息与时间属性相关，支持事件触发消息、约束消息和时间触发消息。
请说明基于BMTS的消息通信网络的主要特征和上述三种消息的基本含义，并举例给出两种具有时间触发消息能力的网络总线。

图3-1 “腰”型通信模式架构风格

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

第4题（案例题）：

阅读以下关于分布式数据库缓存设计的叙述，在答题纸上回答问题1至问题3。
【说明】
某企业是为城市高端用户提供高品质蔬菜生鲜服务的初创企业，创业初期为快速开展业务，该企业采用轻量型的开发架构（脚本语言+关系型数据库）研制了一套业务系开展后受到用户普遍欢迎，用户数和业务数量迅速增长，原有的数据库服务器已不能满足高度并发的业务要求。为此，该企业成立了专门的研发团队来解决该问题。
张工建议重新开发整个系统， 采用新的服务器和数据架构，解决当前问题的同时为日后的扩展提供支持。但是，李工认为张工的方案开发周期过长，投入过大，当前应该尽量小的前提下解决该问题。李工认为访问量很大的只是部分数据，建议采用缓存工具MemCache来减轻数据库服务器的压力，这样开发量小，开发周期短，比较适合初司，同时将来也可以通过集群进行扩展。然而，刘工又认为李工的方案中存在数据可靠性和一致性问题，在宕机时容易丢失交易数据，建议采用Redis来解决问题。在经论，该公司最终决定采用刘工的方案。
在李工和刘工的方案中，均采用分布式数据库缓存技术来解决问题。请说明分布式数据库缓存的基本概念。表4-1中对MemCache和Redis两种工具的优缺点进行了比较，请补充完善表 4-1中的空（1）~ （6）。

【问题2】 （8分）
刘工认为李工的方案存在数据可靠性和一致性的问题，请说明原因。
为避免数据可靠性和一致性的问题，刘工的方案采用Redis作为数据库缓存，请说明基本的Redis与原有关系数据库的数据同步方案。
【问题3】 （8分）
请给出Redis分布式存储的2种常见方案和Redis集群切片的几种常见方式。

【问题1】
分布式数据库缓存指的是在高并发环境下，为了减轻数据库压力和提高系统响应时间，在数据库系统和应用系统之间增加的独立缓存系统。
（1） key/value，list，set，hash，sorted 或 丰富/多种数据结构
（2） 不支持
（3） 客户端哈希分片/一致性哈希
（4） 不支持
（5） 有，私有内存池
（6） 不支持
【问题2】
（1） MemCache没有持久化功能，所以掉电数据会全部丢失，而且无法直接恢复，这存在可靠性问题。
（2） MemCache不支持事务，所以操作过程中可能产生数据的不一致性。同步方案：
读取数据时，先读取Redis中的数据，如果Redis没有，则从原数据库中读取，并同步更新Redis中的数据。写回时，写入到原数据库中，并同步更新至Redis中。
【问题3】
Redis分布式存储的常见方案： 1、主从模式（Master/Slave） 2、哨兵模式（Sentinel）
3、集群模式（Cluster） Redis集群切片的常见方式：
1、客户端分片，即在客户端就通过key的hash值对应到不同的服务器。
2、中间件实现分片。在应用软件和Redis中间，例如：Twemproxy、Codis等，由中间件实现服务到后台Redis节点的路由分派。
3、客户端服务端协作分片。RedisCluster模式，客户端可采用一致性哈希，服务端提供错误节点的重定向服务slot上。不同的slot对应到不同服务器。

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

第5题（案例题）：

阅读以下关于Web系统设计的叙述，在答题纸上回答问题1至问题3。
【说明】
某银行拟将以分行为主体的银行信息系统，全面整合为由总行统一管理维护的银行信息系统，实现统一的用户账户管理、转账汇款、自助缴费、理财投资、贷款管理、网付、财务报表分析等业务功能。但是，由于原有以分行为主体的银行信息系统中，多个业务系统采用异构平台、数据库和中间件，使用的报文交换标准和通信协议也不尽使用传统的EAI解决方案根本无法实现新的业务模式下异构系统间灵活的交互和集成。因此，为了以最小的系统改进整合现有的基于不同技术实现的银行业务系统，该银基于ESB的面向服务架构（SOA）集成方案实现业务整合。

【问题1】 （7分）
请说明什么是面向服务架构（SOA）以及ESB在SOA中的作用与特点。
【问题2】 （12 分）
基于该信息系统整合的实际需求，项目组完成了基于SOA的银行信息系统架构设计方案。该系统架构图如图5-1所示：

请从（a）~ （j）中选择相应内容填入图5-1的（1）~ （6），补充完善架构设计图。
（a） 数据层
（b） 界面层
（c） 业务层
（d） bind
（e） 企业服务总线ESB
（f） XML
（g） 安全验证和质量管理
（h） publish
（i） UDDI
（j） 组件层
（k） BPEL

【问题3】 （6分）
针对银行信息系统的数据交互安全性需求，列举3种可实现信息系统安全保障的措施。

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

【问题2】
（1）（c）业务层 （2）（i）UDDI （3）（h）publish
（4）（e）企业服务总线ESB （5）（g）安全验证和质量管理 （6）（j）组件层
【问题3】
1、引入https协议或采用加密技术对数据先加密再传输
2、采用信息摘要技术对重要信息进行完整性验证
3、防火墙系统
4、安全检测
5、网络扫描

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