2025系统架构师（一考就过）：（2020-2021）案例+论文历年真题及解析系列四
62、管道-过滤器、仓库风格对比（2020年）
| 架构风格 | 数据处理方式 | 系统可扩展性 | 处理性能 |
|---|---|---|---|
| 管道-过滤器 | 数据驱动机制，处理流程事先确定，交互性差 | 数据与处理紧密关联，调整处理流程需要系统重新启动 | 劣势:需要数据格式转换，性能降低 优势:支持过滤器并发调用，性能提高 |
| 仓库 | 数据存储在中心仓库，处理流程独立，支持交互式处理 | 数据与处理解耦合，可动态添加和删除处理组件 | 劣势:数据与处理分离，需要加载数据，性能降低 优势:数据处理组件之间一般无依赖关系，可并发调用，提高性能 |
63、数据模型设计过程、超类实体、派生属性（2020年）
数据库设计过程包括了逻辑数据建模和物理数据建模,逻辑数据建模阶段主要构造实体 联系图表达实体及其属性和实体间的联系，物理数据建模阶段主要根据所选数据库系统设计数据库模式。
实体联系图(Entity Relationship Diagram)指以实体、联系、属性三个基本概 念概括数据的基本结构，从而描述
静态数据结构的概念模式。
实体是具有公共性质的可相互 区别的现实世界对象的集合，可以是具体的，也可以是抽象的概念或联系。
属性是实体所具有的模拟特性，一个实体可由若干个属性来刻画。
联系是数据对象彼此之间存在的相互关系。
数据库建模中可以对属性相似的实体进行进一步的抽象,通过将多个实体中相同的属性 组合起来构造出新的抽象实体，即超类实体，原有多个实体称之为子类实体，通过两者之间 的继承关系来表达抽象实体和具体实体的关系。
逻辑数据模型设计过程包含的任务
(1)构建系统上下文数据模型，包含实体及实体之间的联系;
(2)绘制基于主键的数据模型，为每个实体添加主键属性;
(3)构建全属性数据模型，为每个实体添加非主键属性;
(4)利用规范化技术建立系统规范化数据模型。
超类实体是将多个实体中相同的属性组合起来构造出的新实体。
在数据库优化过程中，第三范式要求消除派生属性，即某个实体的非主键属性由该实体 其他非主键属
性决定，那么该属性可以称之为派生属性。
64、从描述语言、非功能性需求描述、需求和架构的一致性等三个方面，说明软件需求到架构的映射的难点（2020年）
通常在软件开发过程中,需求会随着开发深入而有所变化,而架构又不能完全地将需求全部反映出来,因此，如何把软件需求映射到软件架构是至关重要一个问题。在架构设计时,架构设计师应密切关注需求到架构的映射存在以下5方面的难点:
(1)需求和架构描述语言存在差异:软件需求是频繁获取的非正规的自然语言，而软件架构常用某种正式语言。
(2)非功能属性难以在架构中描述:系统属性中描述的非功能性需求通常很难在架构模型中形成规约。
(3)需求和架构的一致性难以保障:从软件需求映射到软件架构的过程中，保持一致性 和可追溯性很难，且复杂程度很高，因为单一的软件需求可能定位到多个软件架构的关注点。反之，架构元素也可能有多个软件需求。
(4)用迭代和同步演化方法开发软件时，由于需求的不完整而带来的架构设计困难:架构设计必须基于一个准确的需求开展，而有些软件需求只能在建模后甚至是在架构实现时才能被准确理解。
(5)难以确定和细化包含这些需求的架构相关信息:大规模系统必须满足数以千计的需求，会导致很难确定和细化包含这些需求的架构相关信息。
65、FACE 架构 5 个基本段含义（2020年）
(1)操作系统服务段:为FACE架构其他段提供操作系统、运行时和操作系统级健康监控服务。通过开放式 OSGi框架为上层功能提供 OS标准接口，并可实现上层组件的即插即用能力。本段是 FACE 架构的
基本服务段。
(2)I/O服务段:主要针对专用I/O设备进行抽象，屏蔽平台服务段软件与硬件设备的关系，形成一种虚拟设备，这里隐含着对系统中的所有硬件I/O的虚拟化。由于图形服务软件和GPU处理器紧密相关，因此 I/O 服务段不对 GPU 驭动进行抽象。
(3)平台服务段:主要是指平台/用户需要的共性服务软件，主要涵盖跨平台的系统管理、共享设备服务，以及健康管理等。如:系统级健康监控(HM)、配置、日志和流媒体等服务。本段主要包括平台公共服务、平台设备服务和平台图像服务等三类。
(4)传输服务段:通过使用传统跨平台中间件软件(如CORBA、DDA等)，为平台上层可移植组件段提供平台性的数据交换服务，可移植组件将通过传输服务段提供的服务实现交换，禁止组件间直接调用木段应具备 QoS 质量特征服务、配置能力服务以及分布式传输服务等。
(5)可移植组件段:为用户软件段，提供了多组件使用能力和功能服务。主要包括公共服务和可移植组件两类。
66、紧耦合和封装问题（2020年）
紧耦合和封装是软件模块化设计中最难以解决的两个问题,要使软件具备良好的可移植性、可复用性,就必须清楚其问题的表现形式。
紧耦合是应用程序移植的一个障碍，进一步说，就是计算平台的硬件设备和软件模块及 其沟通之间的耦合代表了一个应用程序的可移植性方面的障碍。原因是便携性使得每个平台设备都有一个接口控制文件
(ICD),描述了由硬件所支持的消息和协议,应用程序对消息和协议的支持将紧密耦合于硬件。若要移植,需要太多的工作来修改应用程序以支持不同的结构元素。
为了尽量减少支持新的硬件设备所需要的工作，可采用分离原则，通过隔离实现硬件特定信息和少数模块的代码，来减少耦合性。
通常紧耦合问题主要表现在 I/O问题、业务逻辑问题和表现问题。
传统的应用程序不可移植的另一个原因是这些应用程序被紧密耦合到一组固定的接口，而这些数据的每个数据源或槽(sinks)都暴露出了设备的特殊接口，这些特殊接口在每个平 台中都是不同的。这样,支持平台设备的接口控制文件(ICD)是被硬编码到应用程序中，就导致应用程序不能成功在不同计算平台上执行。
为了解决这种接口控制文件(ICD)被硬编码而难以封装的问题，可以通过提供数据源或槽的软件服务的方法，从紧耦合组件分解出应用程序，并将平台相关部分加入计算环境中，在计算平台内提供数据源或槽的软件服务，并实现接口标准化。
通常封装问题主要表现在:ICD硬编码问题、组件的紧