軟件設計師-軟考知識復習（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）
- 用一個矩形框表示系統的范圍，內部包含用例，外部是參與者。