软件设计师-软考知识复习（3）

在磁盘上存储数据的排列方式会影响I/O服务的总时间。假设每个磁道被划分成10个物理块，每个物理块存放1个逻辑记录。逻辑记录R1,R2…R10存放在同一个磁道上，记录的排列从1到10。

假定磁盘的旋转速度为10ms/周，磁头当前处在R1的开始处。若系统顺序处理这些记录，使用单缓冲区，每个记录处理时间为2ms，则处理这10个记录的最长时间为（）。若对存储数据的排列顺序进行优化，处理10个记录的最少时间为（）。

A.30ms
B.60ms
C.94ms
D.102ms

A.30ms
B.60ms
C.102ms
D.94ms

参考答案：D、A

问题描述回顾

我们有以下信息：

磁道划分：每个磁道被划分成10个物理块，每个物理块存放1个逻辑记录。逻辑记录R1, R2, …, R10存放在同一个磁道上。
旋转速度：磁盘的旋转速度为10ms/周，即磁盘旋转一周需要10毫秒。
初始磁头位置：磁头当前位于R1的开始处。
处理方式：系统顺序处理这些记录，使用单缓冲区。
处理时间：每个记录的处理时间为2ms。

问题：

处理这10个记录的最长时间为（）。
若对存储数据的排列顺序进行优化，处理10个记录的最少时间为（）。

理解磁盘I/O的基本原理

在磁盘存储中，数据的访问时间主要由以下几个部分组成：

寻道时间（Seek Time）：磁头移动到正确磁道的时间。但本题中所有记录都在同一个磁道，所以寻道时间为0。
旋转延迟（Rotational Latency）：磁头到达正确磁道后，等待所需数据块旋转到磁头下方的时间。
传输时间（Transfer Time）：数据从磁盘传输到内存的时间。对于单个记录，可以认为是一个物理块的读取时间。
处理时间（Processing Time）：CPU处理读取的数据的时间。

在本题中：

没有寻道时间（同一磁道）。
旋转速度：10ms/周，即每个物理块之间的旋转时间为1ms（因为一周有10个物理块）。
传输时间：可以假设为读取一个物理块的时间，即1ms（因为旋转一个物理块需要1ms，传输时间与旋转时间重叠）。
处理时间：每个记录处理时间为2ms。

单缓冲区的处理模式

使用单缓冲区意味着：

读取一个记录到缓冲区（需要传输时间）。
处理该记录（处理时间）。
在此期间，磁盘继续旋转，不能同时进行下一个记录的读取。

因此，处理顺序和时间安排需要考虑磁盘旋转和处理时间的重叠。

最长时间的计算（未优化顺序）

初始顺序：R1, R2, …, R10。

初始磁头位于R1的开始处。

处理过程：

读取R1：
- 磁头已经在R1开始处，立即开始读取。
- 读取时间：1ms（传输时间）。
- 读取完成后，开始处理R1：2ms。
- 总时间：1 + 2 = 3ms。
- 在这3ms内，磁盘旋转：3ms / 1ms per block = 3 blocks。
- 从R1开始，旋转3块：R1 → R2 → R3 → R4。所以3ms后，磁头位于R4的开始处。
读取R2：
- 当前磁头在R4开始处，R2已经过去。
- 需要等待磁盘旋转到R2。
- R4 → R5 → … → R10 → R1 → R2：需要旋转8块（从R4到R2）。
- 旋转时间：8ms。
- 然后读取R2：1ms。
- 处理R2：2ms。
- 总时间：8 + 1 + 2 = 11ms。
- 磁盘旋转：11块（因为11ms / 1ms per block = 11 blocks）。
- 从R4开始，旋转11块：
  - R4(0), R5(1), R6(2), R7(3), R8(4), R9(5), R10(6), R1(7), R2(8), R3(9), R4(10), R5(11)。
  - 11ms后，磁头位于R5的开始处。
读取R3：
- 磁头在R5，R3已经过去。
- 需要从R5旋转到R3：
  - R5 → R6 → R7 → R8 → R9 → R10 → R1 → R2 → R3：8块。
- 旋转时间：8ms。
- 读取R3：1ms。
- 处理R3：2ms。
- 总时间：8 + 1 + 2 = 11ms。
- 磁盘旋转：11块。
- 从R5开始，旋转11块：
  - R5(0), R6(1), …, R5(11)。
  - 11ms后，磁头位于R6的开始处。

观察到每次读取R_i（i > 1）的模式：

磁头总是在读取R_i后移动到一个位置，使得下一个R_{i+1}需要等待几乎一整圈。
每次处理R_i（i > 1）需要11ms。

因此：

R1：3ms。
R2到R10：每个11ms，共9个。
总时间：3 + 9 * 11 = 3 + 99 = 102ms。

验证：
让我们验证前几个记录以确保模式正确：

R1: 0-1ms读取，1-3ms处理。位置：R4。
R2: 3-11ms旋转（8ms），11-12ms读取，12-14ms处理。位置：R5。
R3: 14-22ms旋转（8ms），22-23ms读取，23-25ms处理。位置：R6。
…
每次R_i（i>1）需要11ms。

因此，总时间确实是102ms。

最少时间的计算（优化顺序）

为了最小化总处理时间，我们需要安排记录的排列顺序，使得在处理完一个记录后，下一个要读取的记录刚好旋转到磁头下方或即将到达，减少旋转等待时间。

理想情况下，我们希望：

读取一个记录（1ms）。
处理该记录（2ms）。
在这3ms内，磁盘旋转3个块。
因此，下一个要读取的记录应该位于当前记录后的第3个位置。

即，记录的顺序应满足：R_i的下一个是R_{i+3}（模10）。

构造这样的顺序：
从R1开始：
R1 → R4 → R7 → R10 → R3 → R6 → R9 → R2 → R5 → R8。

验证：

初始磁头在R1开始处。

R1：
- 读取R1：1ms。
- 处理R1：2ms。
- 总时间：3ms。
- 旋转：3块 → R1 → R2 → R3 → R4。
- 磁头位于R4开始处。
R4：
- 磁头在R4开始处，立即读取。
- 读取R4：1ms。
- 处理R4：2ms。
- 总时间：3ms。
- 旋转：3块 → R4 → R5 → R6 → R7。
- 磁头位于R7开始处。
R7：
- 立即读取R7：1ms。
- 处理R7：2ms。
- 旋转：3块 → R7 → R8 → R9 → R10。
- 磁头位于R10开始处。

…

每次读取和处理一个记录需要3ms，且下一个记录刚好旋转到位，无需额外等待。

因此，10个记录的总时间为：10 * 3ms = 30ms。

验证排列顺序：
初始顺序：R1, R4, R7, R10, R3, R6, R9, R2, R5, R8。

每次处理一个记录后，磁头移动3个块，刚好到达下一个记录的开始处。

可能的误区

在最初的计算中，可能会忽略磁盘旋转和处理时间的重叠，或者误解旋转延迟的计算。例如：

忽略旋转时间：可能错误地认为每次读取后立即可以开始下一个读取，而忽略了磁盘的连续旋转。
错误的旋转计算：在未优化顺序中，可能错误计算从当前位置到下一个记录的位置的旋转时间。
缓冲区的影响：单缓冲区意味着在处理当前记录时不能同时读取下一个记录，必须等待处理完成后再开始读取。

结论

最长时间（未优化顺序）：102ms。
- 第一个记录：3ms。
- 后续每个记录：11ms（因为需要等待几乎一整圈的旋转）。
- 总时间：3 + 9 * 11 = 102ms。
最少时间（优化顺序）：30ms。
- 将记录按照R1, R4, R7, R10, R3, R6, R9, R2, R5, R8的顺序排列。
- 每个记录的处理周期为3ms（1ms读取 + 2ms处理），且下一个记录刚好旋转到位。
- 总时间：10 * 3 = 30ms。

最终答案

处理这10个记录的最长时间为 102ms。若对存储数据的排列顺序进行优化，处理10个记录的最少时间为 30ms。

以下关于数据库两级映像的叙述中，正确的是（）。
A、模式/内模式映像实现了外模式到内模式之间的相互转换
B、模式/内模式映像实现了概念模式到内模式之间的相互转换
C、外模式/模式的映像实现了概念模式到内模式之间的相互转换
D、外模式/内模式的映像实现了外模式到内模式之间的相互转换
参考答案：B

数据库两级映像（Two-Level Mapping）

数据库两级映像是数据库系统三级模式结构（三级模式：外模式、概念模式、内模式）的重要组成部分，用于实现数据的逻辑独立性和物理独立性。它主要包括：

外模式/概念模式映像（External/Conceptual Mapping）
概念模式/内模式映像（Conceptual/Internal Mapping）

1. 数据库三级模式结构

在理解两级映像之前，先回顾数据库的三级模式：

级别	模式名称	描述
外部级（External Level）	外模式（External Schema）	用户视图，描述数据库的局部逻辑结构（如SQL视图）。
概念级（Conceptual Level）	概念模式（Conceptual Schema）	全局逻辑结构，描述所有数据的逻辑关系（如表、约束）。
内部级（Internal Level）	内模式（Internal Schema）	物理存储结构，描述数据在存储介质上的组织方式（如索引、文件结构）。

2. 两级映像的作用

(1) 外模式/概念模式映像

定义：描述外模式与概念模式之间的对应关系。
作用：
- 保证数据的逻辑独立性（Logical Data Independence）。
- 当概念模式（如表结构）改变时，只需调整映像，而外模式（用户视图）可以保持不变。

示例：

假设有一个 Employee 表（概念模式）：

CREATE TABLE Employee (EmpID INT, Name VARCHAR(50), Salary DECIMAL(10,2));

用户可以定义一个视图（外模式）：

CREATE VIEW EmpView AS SELECT EmpID, Name FROM Employee;

如果 Employee 表结构调整（如增加 Department 列），只需修改映像，而 EmpView 可以保持不变。

(2) 概念模式/内模式映像

定义：描述概念模式与内模式之间的对应关系。
作用：
- 保证数据的物理独立性（Physical Data Independence）。
- 当内模式（如存储方式、索引）改变时，只需调整映像，而概念模式（表结构）可以保持不变。

示例：

数据库管理员（DBA）可以更改存储结构（如从堆文件改为B+树索引），而应用程序仍然使用相同的SQL查询（概念模式不变）。

3. 数据独立性的实现

独立性类型	描述	依赖的映像
逻辑独立性	外模式不受概念模式变化的影响	外模式/概念模式映像
物理独立性	概念模式不受内模式变化的影响	概念模式/内模式映像

示例场景：

逻辑独立性：
- 原 Employee 表有 (EmpID, Name, Salary)。
- 新增 Department 列，但用户视图 EmpView 仍然只显示 EmpID 和 Name，无需修改应用程序。
物理独立性：
- 原数据存储在堆文件中，后来改用B+树索引。
- SQL查询 SELECT * FROM Employee 仍然有效，无需修改。

4. 两级映像的存储与管理

外模式/概念模式映像：
- 通常存储在数据字典（Data Dictionary）中。
- 由DBMS在编译或运行时解析。
概念模式/内模式映像：
- 由数据库管理员（DBA）定义和维护。
- 通常在数据库初始化时配置（如 CREATE TABLESPACE）。

5. 总结

映像类型	作用	独立性类型
外模式/概念模式映像	保证用户视图不受全局逻辑结构变化的影响	逻辑独立性
概念模式/内模式映像	保证逻辑结构不受物理存储变化的影响	物理独立性

关键点：

两级映像是数据库三级模式结构的桥梁。
逻辑独立性：外模式不受概念模式变化影响（通过外模式/概念模式映像）。
物理独立性：概念模式不受内模式变化影响（通过概念模式/内模式映像）。
DBMS通过这两级映像实现数据的灵活管理和高效访问。

在采用 UML（Unified Modeling Language） 进行软件设计时，可以使用以下关系表示不同的语义：

表示特殊/一般关系（继承、泛化）：
- 泛化关系（Generalization）（用 空心三角形箭头 表示，箭头指向父类）
- 示例：
```
┌──────────┐       ┌──────────┐
│  父类    │<|-----│  子类    │
└──────────┘       └──────────┘
```
- 说明：子类继承父类的属性和方法，如 Student 继承 Person。
表示整体/部分关系（组合/聚合）：
- 聚合关系（Aggregation）（用 空心菱形 表示，菱形在整体端）
  - 示例：
```
┌──────────┐       ┌──────────┐
│  汽车    │<>-----│  发动机  │
└──────────┘       └──────────┘
```
  - 说明：部分可以独立于整体存在（如 汽车 和 发动机，发动机可以单独更换）。
- 组合关系（Composition）（用 实心菱形 表示，菱形在整体端）
  - 示例：
```
┌──────────┐       ┌──────────┐
│  公司    │◆-----│  部门    │
└──────────┘       └──────────┘
```
  - 说明：部分的生命周期依赖于整体（如 公司 和 部门，公司解散则部门消失）。

总结

关系类型	UML表示	适用场景	示例
泛化（Generalization）	`◁─`（空心三角箭头）	特殊/一般关系（继承）	`Student` 继承 `Person`
聚合（Aggregation）	`◇─`（空心菱形）	弱整体/部分关系（部分可独立）	`汽车` 包含 `发动机`
组合（Composition）	`◆─`（实心菱形）	强整体/部分关系（部分依赖整体）	`公司` 拥有 `部门`

泛化关系（◁─） 用于表示 特殊/一般关系（继承），如 子类 extends 父类。
聚合（◇─）或组合（◆─） 用于表示 整体/部分关系，其中：
- 聚合表示部分可独立存在（弱关系），如 汽车 和 发动机。
- 组合表示部分依赖整体（强关系），如 公司 和 部门。

软件测试中的灰盒测试和白盒测试的区别？

在软件测试中，**灰盒测试（Gray Box Testing）和白盒测试（White Box Testing）**是两种不同的测试方法，主要区别体现在测试者对系统内部结构的了解程度、测试目标和技术手段上。以下是它们的核心区别：

1. 定义与核心思想

白盒测试
- 定义：测试者完全了解被测系统的内部代码、逻辑结构和实现细节。
- 目标：验证代码逻辑、路径覆盖、分支覆盖等，确保每一行代码或条件都按预期执行。
- 别名：结构测试、透明盒测试（Clear Box Testing）。
灰盒测试
- 定义：测试者仅了解部分内部结构（如接口、架构或有限代码知识），但主要基于外部行为进行测试。
- 目标：结合黑盒的功能验证和白盒的部分逻辑分析，重点关注输入输出的正确性和系统交互。
- 别名：半透明盒测试。

2. 关键区别

维度	白盒测试	灰盒测试
内部知识	完全了解代码和实现细节	部分了解（如接口、数据库结构等）
测试重点	代码逻辑、路径覆盖、边界条件	功能与部分内部逻辑的结合（如API、集成）
测试层级	单元测试、集成测试	集成测试、系统测试（尤其适合模块交互）
技术手段	语句覆盖、分支覆盖、静态代码分析等	基于需求的测试、数据库测试、接口测试等
执行者	开发者、测试工程师（需编程能力）	测试工程师或懂部分代码的测试人员
工具举例	JUnit, PyTest, Coverity	Postman（API测试）, Selenium（部分场景）

3. 适用场景

白盒测试：
- 需要深度验证代码质量（如安全关键系统）。
- 单元测试或复杂逻辑的缺陷检测（如算法验证）。
灰盒测试：
- 模块间集成测试（如API、微服务交互）。
- 数据库测试（验证SQL查询与结果）。
- 性能测试（结合部分内部逻辑优化性能）。

4. 优缺点对比

白盒测试
- 优点：高覆盖率，能发现隐藏的代码缺陷。
- 缺点：成本高，依赖编程能力，可能忽略用户视角的需求。
灰盒测试
- 优点：平衡效率与深度，适合复杂系统集成。
- 缺点：无法覆盖全部代码路径，依赖部分内部知识。

5. 示例说明

白盒测试：测试一个排序函数时，检查所有分支（如空输入、重复值等）。
灰盒测试：测试用户登录功能时，既验证界面输入输出，又检查数据库是否正确存储密码哈希值。

总结

白盒测试是“从里到外”的测试，聚焦代码；灰盒测试是“半透明”的测试，兼顾功能与部分内部逻辑。
实际项目中，两者常结合使用（如单元测试用白盒，集成测试用灰盒）。

UML中的用例图主要用于描述系统的哪些内容？

在UML（统一建模语言）中，用例图（Use Case Diagram）主要用于描述系统的功能需求，重点关注系统与外部参与者（Actor）之间的交互。它从用户的角度展示系统的行为，而不涉及具体的实现细节。

用例图的核心描述内容：

系统的功能（Use Cases）
- 表示系统提供的具体功能（如“登录系统”“下单支付”）。
- 每个用例代表一个用户目标或系统服务。
参与者（Actors）
- 与系统交互的外部实体（如用户、管理员、其他系统）。
- 参与者可以是人、设备或外部软件系统。
交互关系（Relationships）
- 参与者与用例之间的关联（用直线表示，如用户“使用”登录功能）。
- 用例之间的关系：
  - 包含（Include）：一个用例必须调用另一个用例（如“支付”必须包含“验证身份”）。
  - 扩展（Extend）：一个用例在特定条件下扩展另一个用例（如“订单”可能扩展“使用优惠券”）。
  - 泛化（Generalization）：用例或参与者的继承关系（如“普通用户”和“VIP用户”继承自“用户”）。
系统边界（System Boundary）
- 用一个矩形框表示系统的范围，内部包含用例，外部是参与者。