111 身心障礙特考三等 資訊處理 資訊系統與分析 考古題詳解

核心觀念

本題旨在考驗考生對於物件導向分析與設計（Object-Oriented Analysis and Design, OOAD）、**統一建模語言（Unified Modeling Language, UML）的實務應用能力，以及對傳統結構化分析與設計（Structured Analysis and Design, SA/SD）**之差異比較。

1. 物件導向分析與設計（OOAD）：以現實世界的「物件（Object）」為核心，將資料（屬性）與操作（行為）封裝在一起。分析階段（OOA）著重於「做什麼（What）」，識別領域概念；設計階段（OOD）著重於「如何做（How）」，定義軟體元件與架構。
2. 統一建模語言（UML）：作為 OOAD 的標準視覺化工具，區分為靜態結構圖（如類別圖）與動態行為圖（如使用案例圖、循序圖、活動圖）。
3. 結構化分析（SA）與 OOAD 之本質差異：結構化分析採「資料與處理分離」的視點（功能分解，以 DFD 為核心）；物件導向分析則採「資料與行為結合」的視點（物件封裝，以 UML 為核心）。

---

解題方法

身為 IT 顧問，為律師事務所引進知識管理系統（Knowledge Management System, KMS）時，解題應分為三個核心部分推進：

一、 物件導向分析與設計（OOAD）的開展步驟（結合律師事務所 KMS 情境）

1. 需求擷取與使用案例塑模（Requirements Elicitation & Use Case Modeling）

• 識別系統參與者（Actors）：律師（Attorney）、法務助理（Paralegal）、知識管理專員（KM Specialist）、系統管理員（System Admin）。
• 界定系統邊界與需求：蒐集律師事務所的知識資產（如判例分析、訴狀範本、法律意見書、專家通訊錄、案件經驗），定義系統使用案例（如：檢索法律範本、上傳案件心得、審核知識物件、標記法律領域標籤）。

2. 領域塑模與概念類別識別（Domain Modeling & Class Identification）

• 採用名詞分析法（Noun Analysis），從業務需求中識別實體類別。
• 提取關鍵概念物件：Document（文件）、LegalTemplate（法律範本）、CaseBrief（案件摘要）、ExpertiseEntry（專家目錄）、Tag（分類標籤）、User（使用者）。

3. 行為塑模與物件互動分析（Behavioral Modeling & Interaction Analysis）

• 分析物件在不同業務場景下的動態訊息傳遞過程與狀態變遷（如文件從「草稿 $\rightarrow$ 審核中 $\rightarrow$ 已發佈 $\rightarrow$ 已歸檔」的生命週期）。

4. 系統架構與詳細設計（Architectural & Detailed Class Design）

• 設計多層式架構（Presentation Layer, Business Logic Layer, Data Access Layer）。
• 決定類別屬性（Attributes）、方法（Methods/Operations）及類別間關係（一般化/繼承、結合、聚合、組合）。

---

二、 物件導向分析與設計至少需繪製的 UML 圖形與說明

為完整表達律師事務所 KMS 的結構與行為，至少應繪製以下五張核心 UML 圖：

UML 圖形名稱	圖形類別	在律師事務所 KMS 中的作用與繪製焦點
使用案例圖<br>(Use Case Diagram)	動態行為圖	呈現系統邊界以及參與者（如律師、KM專員）與系統功能（如「檢索訴狀範本」、「管理知識標籤」）之間的互動關係，用於釐清系統功能範圍。
類別圖<br>(Class Diagram)	靜態結構圖	定義系統的靜態結構。展示類別（如 LegalTemplate 繼承 KnowledgeDocument）、屬性（如 documentID, securityLevel）、操作（如 searchByTag）與類別間關係（如 Document 與 Tag 之間的多對多關係）。
循序圖<br>(Sequence Diagram)	動態行為圖	著重於訊息傳遞的時間順序。詳細描述特定使用案例（如「律師檢索並下載高敏感法律範本」）中，前端介面、權限驗證物件、搜尋引擎與資料庫物件之間的互動流程。
活動圖<br>(Activity Diagram)	動態行為圖	描述業務流程的工作流（Workflow）。用於建模複雜邏輯與並行作業，例如「法律知識文件上傳、自動敏感詞過濾、KM專員審核、權限設定至正式發佈」的平行與分支流程。

核心觀念

本題評量大型組織在維護資訊安全時，針對資料庫安全（Database Security）與整體系統/網路安全（System and Network Security）的範疇差異、對 Web 數據設計（Web-based Data Design） 的影響，以及實務上應採行的資料庫安全防護措施。

1. 資安範疇與聚焦目標差異：

• 系統與網路安全：側重於邊界防護（Perimeter Security）、傳輸管道防護與主機作業系統防護，目標是阻絕未授權的外部網路連線與惡意程式入侵。
• 資料庫安全：側重於資料資產本身的防護（Data-Centric Security），關注細粒度的存取控制、資料機密性、完整性與合規性稽核，應對合法連線管道內的惡意查詢與內部權限濫用。

2. Web 數據設計架構：

• 包含三層架構（Three-tier Architecture）下的數據隔離、參數化查詢設計、動態/靜態加密設計、視圖與預存程序的封裝設計，用以防範 SQL 注入攻擊（SQL Injection）與資料洩漏。

3. 縱深防禦（Defense-in-Depth）防護措施：

• 結合存取控制（RBAC/DAC）、傳輸與靜態加密（TDE/TLS）、資料庫活動監控（DAM）、備份復原機制及補丁安全強化（System Hardening）。

---

解題方法

本題為三等特考之申論題，答題切入點應採「結構化分點論述」，針對題目提出的三個核心子問依序進行精準拆解：

1. 第一子問（資料庫安全與系統其餘部分安全之差異）：從「防護對象」、「防護邊界與層次」、「主要威脅來源」及「存取控制粒度」四個面向進行對比分析。
2. 第二子問（對基於 Web 的數據設計之影響）：從「架構分離設計」、「資料庫存取層防禦設計」、「資料庫模式（Schema）與權限封裝」及「敏感資料儲存設計」四大維度說明安全性規範對 Web 數據設計的具體要求。
3. 第三子問（有效確保資料庫安全之措施）：採用「縱深防禦（Defense in Depth）」架構，由外而內分層說明實體/網路層、身份與存取管理層、應用與資料保護層、稽核監控與備份層的具體安全控制措施。

---

選項分析

本題為非選擇題（申論題），針對題目所包含的三大問題面向（子項內容）進行詳細分析說明：

一、 資料庫安全性與系統其餘部分安全性之差異分析

分析面向	系統與網路安全性（System & Network Security）	資料庫安全性（Database Security）
防護對象	著重於實體設備、作業系統、網路通道、伺服器節點與終端設備。	著重於資料資產（Data Assets）、資料表、欄位內容及業務邏輯數據。
防護邊界	屬於外圍防禦（Perimeter Defense），透過防火牆、IDS/IPS 阻絕非法封包。	屬於核心資料防禦（Data-Centric Defense），應對通過網路防火牆後的合法連線。
存取控制粒度	粗粒度（Coarse-grained），基於 IP、連接埠、MAC 位址或 OS 帳號權限。	細粒度（Fine-grained），基於資料庫使用者角色（RBAC）、資料表（Table）、列（Row）、欄位（Column）等級存取限制。
威脅型態	DDoS 攻擊、網路掃描、中間人攻擊（MITM）、OS 漏洞利用、惡意軟體。	SQL 注入攻擊（SQLi）、內部人員權限濫用（Privilege Abuse）、資料庫稽核規避、推論攻擊（Inference Attack）。
資料生命週期	關注傳輸階段安全與主機運作狀態。	關注資料全生命週期（儲存、處理、備份、銷毀、靜態資料加密與去識別化）。

二、 對基於 Web 的數據設計之影響分析

資料庫安全需求會深刻重構 Web 數據與系統架構的設計邏輯，具體影響包含：

1. 架構層次分離（Tiered Data Architecture）：

• Web 數據設計不可採用單體式直連架構，必須嚴格區隔 Web 呈現層、應用邏輯層與資料庫層（Three-tier Architecture）。
• 資料庫伺服器必須配置於私有子網（Private Subnet），禁止分配公有 IP 地址，限制僅允許應用程式伺服器透過特定連接埠連線。

2. 資料庫存取抽象化與參數化設計（Data Access Abstraction）：

• 數據存取層（DAL / ORM）設計必須全面採用參數化查詢（Parameterized Queries）或預編譯敘述（Prepared Statements），強制將指令（Code）與資料（Data）分離，防範 SQL 注入攻擊。
• 避免在 Web 端動態拼接 SQL 字串。

3. 資料庫模式與邏輯遮蔽設計（Schema & Logic Encapsulation）：

• Web 應用帳號禁止直接操作基底表（Base Tables），數據設計應大量運用「視圖（Views）」與「預存程序（Stored Procedures）」。
• 限制 Web 連線帳號僅能執行特定的預存程序，隱藏真實資料庫 Schema 結構，實現最小存取權限。

核心觀念

本題考查資訊系統分析與設計（System Analysis and Design, SAD）中「系統設計階段（System Design Phase）」的核心產出文件——「系統設計規格書（System Design Specification, SDS）」。

在系統開發生命週期（SDLC）中，系統分析階段產出的「系統需求規格書（System Requirement Specification, SRS）」旨在說明「系統應該做什麼（What to do）」，而系統設計階段產出的「SDS」則旨在說明「系統該如何實作（How to do）」。SDS 係將抽象的邏輯需求轉化為具體的技術實作藍圖，做為後續程式撰寫（Coding）、系統測試（Testing）與系統維護（Maintenance）的實質依據。

---

解題方法

解題切入點採用「由宏觀至微觀、由架構至細節」的層次化結構進行剖析。典型的系統設計規格書需涵蓋以下六大核心區塊：

1. 系統概述與範疇（System Overview & Scope）：說明專案背景、目標與技術限制。
2. 系統架構設計（System Architecture Design）：定義軟硬體拓撲、系統分層與技術堆疊。
3. 介面與輸出入設計（Interface & Input/Output Design）：規範人機介面（UI/UX）、外部系統 API 及報表規格。
4. 資料庫與資料結構設計（Database & Data Structure Design）：建立實體關聯圖（ERD）、資料字典及 Schema 結構。
5. 模組與詳細邏輯設計（Module & Detailed Logic Design）：繪製模組結構圖，並以偽代碼（Pseudocode）或順序圖（Sequence Diagram）定義模組運算邏輯。
6. 系統控制與資安維運設計（System Control, Security & Maintenance Design）：規劃存取控制、稽核軌跡、備份備援與部署計畫。

---

選項分析

本題為問答申論題，無選項分析。答題時應避免僅條列標題，須詳細說明各部分的「名稱」與「具體描述內容」，展現系統分析師的專業素養。

---

解題技巧

1. 結構分明：採大標題搭子項目的層次化書寫，明確劃分「架構」、「資料庫」、「介面」、「模組」與「安全」五大層面，便於閱卷者快速對照採分點。
2. 釐清 SRS 與 SDS 的邊界：內容須聚焦於「技術實作細節」（如實體 Schema、API 端點、演算法與軟硬體規格），切忌寫成高階的使用者需求描述。
3. 系統化記憶口訣：可依據「總（概述）- 架（架構）- 介（介面）- 資（資料庫）- 模（模組）- 安（資安維運）」六字順序記憶答題內容。

---

【答案】

當系統分析階段完成並確定需求後，系統設計階段將產出系統設計規格書（System Design Specification, SDS）。典型的系統設計規格書主要包含以下六個核心部分及其詳細內容：

一、 系統概述與引言（System Overview & Introduction）

• 專案背景與目標：簡述系統開發背景、業務目標及系統需解決的核心問題。
• 系統範圍與限制：明確界定系統實作邊界，以及硬體資源、開發時間或技術平台等約束條件。

核心觀念

本題評量軟體工程中「需求工程（Requirements Engineering）」與「系統確認與驗證（Validation & Verification, V&V）」的核心知識，主要涵蓋三大觀念：

1. 確認與驗證（V&V）之理論定義與差異：區分 Verification（Are we building the product right?）與 Validation（Are we building the right product?）的關注焦點與檢查標的。
2. 需求可追溯性（Requirements Traceability）與手動檢查機制：雙向追溯（前向追溯 Forward Traceability 與後向追溯 Backward Traceability）的觀念，並透過「需求追溯矩陣（Requirements Traceability Matrix, RTM）」進行手動稽核。
3. 電腦輔助軟體工程（CASE）工具功能：探討自動化工具如何輔助管理需求鏈結、孤兒項目偵測（Orphan Detection）與變更衝擊分析（Impact Analysis）。

---

解題方法

本題為申論題，切入點按題目要求分為三大重點段落層層剖析：

1. 說明 V&V 的根本差異：利用經典問句與比較範疇建立清晰的觀念對比。
2. 具體說明手動檢查可追溯性的步驟與方法：包含追溯矩陣建立、雙向稽核（前向與後向）及抽樣一致性審查。
3. 列舉 CASE 工具關鍵功能：從自動化鏈結、斷鏈/孤兒檢驗、變更警示至版本追蹤，列出具體實務功能。

---

選項分析

本題為申論題型，針對題目三大子題面向（確認與驗證差異、手動可追溯性檢查、CASE工具功能）進行深度解析與判斷標準說明如下：

一、 確認（Validation）與驗證（Verification）之差異分析

• 驗證（Verification, 簡稱 $V_1$）：
• 定義與核心考量：「Are we building the product right?」（我們是否有把產品做對？）
• 檢查標的：系統開發過程中的各階段產出物（需求規格書、系統設計圖、原始碼）。
• 評估標準：產出物是否符合上一階段所定義的軟體規格與標準規範（Compliance with Specification）。
• 執行方式：靜態檢查、代碼審查（Code Inspection）、單元測試與整合測試。
• 確認（Validation, 簡稱 $V_2$）：
• 定義與核心考量：「Are we building the right product?」（我們是否有做對的產品？）
• 檢查標的：最終交付的完整系統或軟體產品。
• 評估標準：系統是否真正滿足使用者在實際營運環境中的真實需求（Satisfaction of User Needs）。
• 執行方式：動態測試、系統測試、驗收測試（Acceptance Testing）、Alpha/Beta 測試。

二、 手動檢查現有系統可追溯性（Requirements Traceability）之執行方法

手動檢查可追溯性主要依賴**需求追溯矩陣（Requirements Traceability Matrix, RTM）**的編製與人工稽核，具體步驟包含：

1. 編製需求追溯矩陣（RTM）： 建立對照表，為每一個原始需求賦予唯一識別碼（如 $\text{REQ-001}$），並對應系統規格（$\text{SPEC}$）、架構設計（$\text{DESIGN}$）、程式碼模組（$\text{CODE}$）及測試案例（$\text{TC}$）。
2. 執行前向追溯檢查（Forward Traceability Check）：