系统架构设计-真题2015错题集

选择题

在嵌入式操作系统中，板级支持包BSP作为对硬件的抽象，实现了（ ）。
A 硬件无关性，操作系统无关性
B 硬件有关性，操作系统有关性
C 硬件无关性，操作系统有关性
D 硬件有关性，操作系统无关性

答案D
BSP（板级支持包）的核心作用:
BSP是嵌入式系统中硬件与操作系统之间的适配层，其核心职责包括：

硬件初始化：配置CPU时钟、内存控制器、外设寄存器等。
设备驱动抽象：为操作系统提供统一的硬件操作接口（如读写GPIO、中断处理）。
屏蔽硬件差异：使操作系统无需直接处理底层硬件细节。

1. “硬件有关性”的含义
   BSP必须针对特定硬件编写：
   不同硬件（如STM32、ESP32、树莓派）的电路设计、寄存器地址、外设操作方式各不相同。BSP需要精确适配这些硬件细节。
   例子：
   点亮LED时，STM32的GPIO控制寄存器地址与树莓派的完全不同，BSP需分别实现gpio_set()函数。
   初始化内存时，STM32F4需配置FSMC（Flexible Static Memory Controller），而i.MX6需配置DDR控制器，这些代码都在BSP中。

2. “操作系统无关性”的含义
   操作系统通过BSP统一接口操作硬件：
   BSP为操作系统提供标准化的API（如初始化函数、中断处理接口），操作系统无需关心底层硬件差异。
   例子：
   FreeRTOS调用BSP_UART_Send()发送数据，无论是STM32还是ESP32，BSP内部实现具体的UART寄存器操作，FreeRTOS代码无需修改。
   Linux内核通过设备树（Device Tree）描述硬件，BSP提供设备树文件，内核根据设备树加载对应驱动。

BSP必须深度绑定硬件（硬件有关性）。
操作系统通过BSP的接口适配不同硬件，自身无需修改（操作············系统无关性）。
尽管不同操作系统的BSP接口形式不同，但这是BSP层自身的适配工作，不影响操作系统的核心代码。
BSP板级支持包（board support package）
板级支持包BSP和硬件抽象层HAL的区别和关联

供应链中的信息流覆盖了从供应商、制造商到分销商，再到零售商等供应链中的所有环节，其信息流分为需求信息流和供应信息流，（ ）属于需求信息流，（ ）属于供应信息流。
问题1
A 库存记录
B 生产计划
C 商品入库单
D 提货发运单
问题2
A 客户订单
B 采购合同
C 完工报告单
D 销售报告

答案B C
供应链中的信息流覆盖了从供应商、制造商到分销商，再到零售商等供应链中的所有环节，其信息流分为需求信息流和供应信息流，这是两个不同流向的信息流。

• 当需求信息(如客户订单、生产计划和采购合同等)从需方向供方流动时，便引发物流。
• 同时，供应信息(如入库单、完工报告单、库存记录、可供销售量和提货发运单等)又同物料一起沿着供应链从供方向需方流动。

1. 需求信息流
   定义：
   需求信息流是从供应链下游（如客户、零售商）向上游（如制造商、供应商）传递的信息，反映市场需求或需方对产品、材料的要求。
   方向：下游 → 上游。
   作用：
   触发物流和生产活动，告知供方“需要什么、需要多少、何时需要”。

具体示例
客户订单（Customer Order）
定义：客户或零售商向供应商、分销商提交的购买请求。
内容：产品类型、数量、交货时间等（如“需 100 台电视，7 天内送达”）。
流向：客户 → 零售商 → 分销商 → 制造商。
作用：直接反映市场需求，启动供应链响应。
示例：超市向分销商订购 50 箱饮料。

生产计划（Production Plan）
定义：制造商根据市场需求（如客户订单）制定的生产安排，可能向上游（如供应商）传递。
内容：生产的产品、数量、时间表（如“下周生产 1000 件手机”）。
流向：制造商 → 供应商（反映原料需求）。
作用：将下游需求转化为对上游的材料或组件需求。
示例：制造商通知供应商“计划生产 1000 件衣服，需 2000 米布料”。
特别说明：生产计划本身是制造商内部计划，但向上游传递时成为需求信息。

采购合同（Purchase Contract）
定义：需方向供方（如制造商向供应商）提出的正式采购协议。
内容：采购物品、数量、价格、交货条件等（如“采购 500 个零件，单价 10 元”）。
流向：制造商 → 供应商，或零售商 → 分销商。
作用：明确需方需求，约束供方供应。
示例：汽车厂与零件供应商签订“每月供应 1000 个轮胎”的合同。

2. 供应信息流
   定义：
   供应信息流是从供应链上游（如供应商、制造商）向下游（如分销商、零售商）传递的信息，反映供应能力、库存状态或物料流动情况。
   方向：上游 → 下游。
   作用：
   伴随物流，告知需方“供给了什么、供给了多少、何时到达”。

具体示例
入库单（Goods Receipt Note）
定义：记录货物进入仓库的单据，由接收方（如分销商）生成并可能向下游传递。
内容：入库物品、数量、时间等（如“收到 100 箱牛奶”）。
流向：供应商/制造商 → 分销商 → 零售商。
作用：通知下游货物已可用。
示例：分销商通知零售商“50 台空调已入库”。

完工报告单（Completion Report）
定义：制造商完成生产后向下游报告的单据。
内容：完成的产品、数量、状态等（如“1000 件衣服已生产完成”）。
流向：制造商 → 分销商/零售商。
作用：告知下游产品可供交付。
示例：服装厂通知分销商“订单的 500 件 T 恤已完工”。

库存记录（Inventory Record）
定义：记录当前库存状态的信息，由持有方（如制造商、分销商）向下游传递。
内容：库存产品、数量、位置等（如“仓库有 200 台电视”）。
流向：制造商 → 分销商 → 零售商。
作用：通知下游可用库存情况。
示例：分销商告知零售商“当前库存有 100 箱可乐”。

可供销售量（Available-to-Sell Quantity）
定义：供方通知下游可供销售的产品数量。
内容：可销售的商品及数量（如“可供销售 300 个手机”）。
流向：制造商 → 分销商 → 零售商。
作用：告知下游当前供应能力。
示例：制造商通知分销商“本月可供销售 500 台电脑”。

提货发运单（Delivery/Shipping Note）
定义：记录货物发运信息的单据，由供方（如制造商）生成并向下游传递。
内容：发运产品、数量、运输方式等（如“已发运 50 箱牛奶”）。
流向：制造商 → 分销商 → 零售商。
作用：通知下游货物在途或已交付。
示例：分销商通知零售商“100 件衣服已发运，预计明天到达”。

商业智能系统的处理过程包括四个主要阶段：数据预处理通过（ ）实现企业原始数据的初步整合；建立数据仓库是后续数据处理的基础；数据分析是体现系统智能的关键，主要采用（ ）和（ ）技术，前者能够实现数据的上卷、下钻和旋转分析，后者利用隐藏的知识，通过建立分析模型预测企业未来发展趋势；数据展现主要完成数据处理结果的可化。
问题1
A 数据映射和关联
B 数据集市和数据立方体
C 数据抽取、转换和装载
D 数据清洗和数据集成
问题2
A 知识库
B 数据挖掘
C 联机事务处理
D 联机分析处理
问题3
A 知识库
B 数据挖掘
C 联机事务处理
D 联机分析处理

答案C D
商业智能系统的处理过程包括数据预处理、建立数据仓库、数据分析及数据展现4个主要阶段。
数据预处理是整合企业原始数据的第一步，包括数据的抽取、转换和装载三个过程。建立数据仓库则是处理海量数据的基础。数据分析是体现系统智能的关键，一般采用OLAP和数据挖掘技术。
联机分析处理不仅进行数据汇总/聚集，同时还提供切片、切块、下钻、上卷和旋转等数据分析功能，用户可以方便地对海量数据进行多维分析。
数据挖掘的目标则是挖掘数据背后隐藏的知识，通过关联分析、聚类和分类等方法建立分析模型，预测企业未来发展趋势和将要面临的问题。在海量数据和分析手段增多的情况下，数据展现则主要保障系统分析结果的可视化。

记住OLAP（联机分析） 和 OLTP（事务处理）的技巧
联想记忆法

OLAP：把 “L” 看作 “Line”（联机），“A” 看作 “Analysis”（分析），“P” 看作 “Processing”（处理）。可以想象在一个联机的环境下，对大量的数据进行分析处理，比如企业通过对多年的销售数据进行分析，来制定未来的销售策略，这就是 OLAP 的应用场景。

OLTP：可以将 “T” 联想为 “Transaction”（事务）的首字母，“P” 可以联想为 “Process”（处理）。所以 OLTP 就可以理解为处理事务的过程，就像银行转账、超市结账等日常交易场景，都是典型的事务处理，每个事务都有明确的开始和结束，要求数据的准确性和一致性

【1.系统工程与信息系统基础】1.24 商业智能（BI）

在面向对象设计的原则中、（ ）原则是指抽象不应该依赖予细节，细节应该依赖于抽象，即应针对接口编程，而不是针对实现编程。
A 开闭
B 里氏替换
C 最少知识
D 依赖倒置

答案D
依赖倒置原则是指抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。在程序代码中传递参数时或在组合(或聚合)关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明和方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。为了确保该原则的应用，一个具体类应当只实现接口和抽象类中声明过的方法，而不要给出多余 的方法，否则，将无法调用到在子类中增加的新方法。
实现开闭原则的关键是抽象化，并且从抽象化导出具体化实现，如果说开闭原则是OOD的目标的话，那么依赖倒置原则就是OOD的主要机制。有了抽象层，可以使得系统具有很好的灵活性，在程序中尽量使用抽象层进行编程，而将具体类写在配置文件中，这样，如果系统行为发生变化，则只需要扩展抽象层，并修改配置文件，而无须修改原有系统的源代码，在不修改的情况下来扩展系统功能，满足开闭原则的要求。依赖倒置原则是COM、CORBA、EJB、Spring等技术和框架背后的基本原则之一。

1. 开闭原则（Open/Closed Principle，OCP）
   定义：
   软件实体（如类、模块、函数）应该对扩展开放，对修改关闭。
   含义：
   新增功能时，通过扩展（如继承、接口实现）实现，而不修改原有代码。
   目的：
   提高系统的可扩展性和稳定性，减少因修改引入的错误。
   实现方式：
   使用抽象（如接口、抽象类）和多态。

2. 里氏替换原则（Liskov Substitution Principle，LSP）
   定义：
   子类对象应能替换父类对象，且程序的正确性不受影响。
   含义：
   继承时，子类必须遵守父类的行为约定，不能改变预期功能。
   目的：
   确保继承体系的正确性和一致性，避免因子类行为异常导致问题。
   实现方式：
   子类遵循父类的接口契约，不重写方法改变语义。

3. 最少知识原则（Law of Demeter，LoD）
   定义：
   一个对象应尽量少了解其他对象的内部细节，只与“直接朋友”通信。
   含义：
   “朋友”指：当前对象的字段、方法参数、方法创建的对象。
   不应调用“朋友的朋友”的方法。
   目的：
   降低耦合，减少对象间的依赖。
   实现方式：
   避免链式调用（如 a.getB().getC().doSomething()）。

4. 依赖倒置原则（Dependency Inversion Principle，DIP）
   定义：
   高层模块不依赖低层模块，二者都依赖抽象。
   抽象不依赖细节，细节依赖抽象。
   含义：
   通过接口或抽象类解耦，程序针对接口编程，而非具体实现。
   目的：
   降低耦合，提高灵活性和可测试性。
   实现方式：
   使用依赖注入（DI）或接口。