110 關務升官等考試簡任 技術類（選試系統分析研究） 系統分析研究 考古題詳解

核心觀念

本題是五個名詞的定義與應用範圍題，分別涵蓋系統建模、需求工程、專案管理、資料庫及資訊安全。作答時先寫出各名詞的核心定義，再補充其目的、主要構成或作用；避免只翻譯英文名稱。

解題方法

每小題可依「是什麼 → 用來做什麼 → 重要特性」三層作答。名詞解釋不需長篇列舉，但須指出能與相近概念區分的關鍵特徵。

名詞解釋

（一）統一建模語言（Unified Modeling Language, UML）

UML 是用來描述、視覺化、建構及記錄軟體系統的標準化圖形建模語言。它提供共同的符號與語法，使需求人員、分析設計人員、程式開發者及使用者能以一致方式溝通系統的結構與行為。

UML 圖形可概分為兩類：

• 結構圖：呈現系統的靜態構造，例如類別圖、物件圖、元件圖及部署圖。
• 行為圖：呈現系統的動態行為，例如使用案例圖、循序圖、活動圖及狀態機圖。

UML 是建模語言，不是特定的系統開發方法，也不是程式設計語言；它可搭配不同的軟體開發流程使用。

（二）需求分析（Demand Analysis）

需求分析是系統分析與開發過程中，釐清利害關係人需求並將其轉化為明確、可檢驗系統需求的工作。其目的在確認系統應提供的功能、品質及限制，作為後續設計、建置、測試與驗收的依據。

需求分析通常包括需求蒐集、分類與分析、優先排序、衝突協調、文件化及確認。需求可分為：

• 功能性需求：系統應提供的功能或服務，例如使用者登入、資料查詢及報表產生。
• 非功能性需求：系統須符合的品質或限制，例如效能、安全性、可用性、法規遵循及操作環境。

良好的需求應清楚、一致、可追溯、可驗證，並經相關利害關係人確認。需求分析不等同於直接決定技術方案；它首先回答「系統要滿足什麼需要」。

（三）專案管理知識體系（Project Management Body of Knowledge, PMBOK）

PMBOK 是由美國專案管理協會（Project Management Institute, PMI）提出的專案管理知識體系，整理專案管理的共同概念、術語、原則與實務，提供專案管理者規劃及執行專案時參考。PMBOK 本身是知識指引，不是單一、不可變更的專案管理方法；實際作法須依專案規模、產業、組織及情境調整。

傳統 PMBOK 架構常以專案管理流程群組及知識領域說明管理工作。流程群組包括啟動、規劃、執行、監控與管制、結束；

核心觀念

本題考查關聯式資料庫的交易管理，重點有二：說明交易的 ACID 四項特性，以及說明資料庫管理系統如何藉由這些特性處理失敗回復與並行控制。ACID 是交易必須遵守的正確性要求；回復處理與並行控制則是資料庫用來維持這些要求的機制。

**交易（Transaction）**是由一組資料庫操作構成的邏輯工作單位。交易成功完成時，執行 COMMIT；若發生錯誤或取消，則執行 ROLLBACK，將交易所做的異動撤銷。

ACID 特性

1. 原子性（Atomicity） 一筆交易中的操作視為不可分割的整體：不是全部成功，就是全部不生效。 例如轉帳交易須同時完成「甲帳戶扣款」與「乙帳戶存款」；若扣款後系統故障，不能只留下扣款結果。

2. 一致性（Consistency） 交易開始前及完成後，資料庫都必須符合既定的完整性限制與業務規則。交易執行的中間狀態可以暫時不一致，但提交後必須回到合法狀態。 例如轉帳前後總存款應維持不變，且帳戶餘額不得違反資料庫設定的限制。

3. 隔離性（Isolation） 多筆交易同時執行時，其效果應如同依某種順序逐一執行，避免彼此未完成的中間結果互相干擾。隔離性不必然要求交易實際上完全序列執行，而是要求並行執行的結果符合可序列化等正確性標準。 常見需防止的異常包括：讀取未提交資料（dirty read）、不可重複讀取（non-repeatable read）、幻影讀取（phantom read）及更新遺失（lost update）。

4. 持久性（Durability） 交易一旦成功提交，其結果即使在之後發生當機、斷電等故障，也必須保存。資料庫通常以日誌、穩定儲存設備及檢查點等方式確保提交結果可重建。

解題方法：由兩類故障對應 ACID

作答時先界定 ACID 的功能，再分別從「交易或系統故障」與「多筆交易同時執行」說明資料庫如何維持 ACID。回復處理主要落在原子性與持久性；並行控制主要落在隔離性，並以一致性作為正確性目標。

回復處理（Failure Recovery）

資料庫管理系統利用日誌與復原程序，使故障後的資料庫仍符合原子性及持久性。

• 預寫式日誌（Write-Ahead Logging, WAL）：資料頁面寫入磁碟前，先將相關異動紀錄寫入穩定儲存設備；交易提交前，也須確保足以重建提交結果的日誌已保存。

核心觀念

本題考查系統開發生命週期中的兩種分析方法：結構化分析法（Structured Analysis）與物件導向法（Object-Oriented Method）。作答重點是說明兩者如何描述需求與系統，以及比較其分析觀點、模型工具、開發銜接和適用情境。

結構化分析法以「系統要處理哪些資料，以及資料如何被處理」為核心，將系統分解為一組逐步細化的處理程序。它通常把資料與處理程序分開描述，並以功能分解建立由整體到細部的模型。

物件導向法以「系統由哪些物件構成，以及物件如何互動」為核心。物件結合資料與操作，透過類別、物件及其關係描述系統，並以封裝、繼承與多型等機制支援重用及擴充。

解題方法

先從兩種方法的分析焦點切入，再分別說明主要模型及特性，最後比較適用時機。這種寫法能呈現方法間的核心差異，也能說明選擇方法時應考量的系統特性。

一、結構化分析法

結構化分析法（Structured Analysis, SA）以流程與功能分解來掌握需求，通常由系統整體逐層分解，呈現「輸入資料如何經由處理轉成輸出資料」。

常見分析工具包括：

• 資料流程圖（Data Flow Diagram, DFD）：描述外部實體、處理程序、資料流與資料儲存，呈現資料在系統中的流向及轉換。
• 資料字典（Data Dictionary）：定義資料流程、資料儲存及資料項目的內容、格式與組成，避免模型中的資料名稱含義不一致。
• 程序規格（Process Specification）：細述 DFD 中較低層處理程序的邏輯，可使用結構化中文、決策表或決策樹等方式表示。
• 實體關係圖（Entity-Relationship Diagram, ERD）：描述資料實體及其關係，支援資料需求與資料庫設計。

結構化分析通常由高層 DFD 開始，逐層分解複雜處理程序；各層模型須保持輸入、輸出與資料流的一致性。分析成果可進一步銜接至結構化設計，將功能轉化為模組與程序。

其優點是流程清楚、分解步驟明確，適合掌握以處理程序為主的需求；限制是資料與程序分開建模，當資料結構或業務規則變動頻繁時，可能需要在多處同步修改，也較不直接呈現物件間的互動。

二、物件導向法

物件導向法（Object-Oriented Method, OOM）將系統視為一組具有狀態與行為的物件。**類別（class）**定義一類物件的共同屬性與操作；**物件（object）**則是類別的具體實例。物件透過訊息或介面互動，以合作方式完成系統功能。

其重要概念包括：

• 封裝（Encapsulation）：將資料與操作資料的行為置於同一物件，並透過介面控制存取。
• 繼承（Inheritance）：讓子類別沿用父類別的屬性與操作，並可擴充或改寫，支援共通功能重用。
• 多型（Polymorphism）：相同操作可依物件類型呈現不同執行行為，降低呼叫端對細節的依賴。
• 抽象化（Abstraction）：保留問題領域重要特徵，省略與目前分析目的無關的細節。

常見建模工具為統一塑模語言（Unified Modeling Language, UML），例如：

核心觀念

本題考查物聯網軟體架構的兩種設計取向，以及物聯網雲平台與一般雲平台在架構需求上的差異。作答時應先比較「主要運算與控制邏輯放在哪裡」，再說明物聯網平台為支援大量設備與即時資料流所需的架構能力。

解題方法

以運算位置、控制方式、網路依賴、資料處理與適用情境比較 Cloud-centric 與 Device-centric；接著從連線管理、資料攝取、即時處理、設備管理及安全性，對照物聯網雲平台與一般雲平台的基礎架構。

一、以雲為中心（Cloud-centric）

以雲端平台作為物聯網系統的主要運算、儲存與管理中心。設備端通常負責感測、資料蒐集、初步格式化及透過網路傳送資料；較複雜的分析、決策、應用服務與設備管理則集中在雲端執行。

其典型資料流程為：

優點：

• 雲端資源可依需求擴充，適合大量設備集中管理及長期資料分析。
• 可集中部署應用程式、更新模型與管理設備。
• 設備端所需運算能力較低，硬體成本及維護複雜度較容易控制。

限制：

• 對網路連線品質依賴較高，傳輸延遲或斷線會影響服務。
• 大量資料送往雲端會增加頻寬使用、傳輸成本與雲端負載。
• 若控制決策須往返雲端，難以滿足嚴格的即時反應需求。

**適用情境：**資料可容忍一定延遲、需要跨設備或跨區域整合分析，且網路連線穩定的應用，例如設備群的歷史趨勢分析及集中式營運管理。

二、以設備為中心（Device-centric）

將較多運算、判斷與控制邏輯放在設備端，或放在靠近設備的閘道器與邊緣節點。設備可以先在本地處理資料、判斷事件並採取控制措施；只有必要的摘要、事件或資料才送往雲端。

其典型資料流程為：

優點：

• 可降低端到端延遲，適合即時性要求高的控制工作。
• 網路中斷時，設備仍可執行預先設定的本地功能。
• 可減少上傳資料量、頻寬占用及雲端處理負載。
• 部分資料留在本地，有助於降低敏感資料外傳的需求。

限制：

• 設備須具備較高的運算、儲存與電力能力，增加硬體成本。
• 設備種類與軟硬體版本多樣，部署、更新、監控及維護較複雜。
• 本地設備若未妥善防護，容易形成分散的安全管理風險。
• 若各設備各自處理，跨設備或全域資料分析仍須另行整合。

**適用情境：**需低延遲、網路不穩定或須在本地維持安全控制的應用，例如工業設備保護、車載控制及即時告警。