110 中華郵政招考專業職(一) 程式設計 中華郵政專業職(一) (資訊系統開發與維護概要) 考古題詳解

核心觀念

本題考查以下觀念：

1. 階乘定義

對非負整數 $N$：

$N! = N \times (N-1) \times \cdots \times 2 \times 1$

且：

$0! = 1$

2. 遞迴

階乘具有遞迴關係：

$N! = N \times (N-1)!$

當 $N=0$ 時，遞迴必須停止，回傳 $1$。

3. 迴圈累乘

使用變數保存累積乘積，逐步將 $N$、$N-1$、……、$1$ 相乘。

4. 結束條件

當輸入值為 999 時停止輸入與計算，因此 999 不可送入 fac1 或 fac2。

解題方法

一、遞迴函式 fac1

函式宣告如下：

static int fac1(int n, int s)

其中：

• n：目前尚未處理的階乘數值。
• s：累積乘積，稱為累加器（accumulator）。

初始呼叫為：

fac1(n, 1)

遞迴規則為：

fac1(n, s) = fac1(n - 1, n * s)

當 n == 0 時，所有乘法已完成，直接回傳 s：

if (n == 0)
 return s;

以 fac1(4, 1) 為例：

因此結果為：

$4! = 24$

二、迴圈函式 fac2

先令累積變數：

int s = 1;

再從 n 逐步乘到 $1$：

for (int i = n; i >= 1; i--)
 s = s * i;

最後回傳 s。

以 fac2(4) 為例：

完整程式

核心觀念

本題考查兩種常見軟體開發模型：

• 瀑布模型（Waterfall Model）：依序完成需求分析、系統設計、程式實作、測試、部署與維護，各階段具有明確先後關係。
• 敏捷模型（Agile Model）：以短週期、反覆迭代、持續交付及快速回應需求變更為核心，透過團隊協作逐步完成軟體。

作答時應分別掌握「流程特性、適用情境、優點、缺點」，並比較兩者對需求變更及使用者參與程度的差異。

（一）瀑布模型及其優劣處【15 分】

1. 瀑布模型的定義與流程

瀑布模型是一種線性、循序式的軟體開發模型。系統開發按照固定階段逐步進行，前一階段完成並經確認後，才進入下一階段。

典型流程如下：

1. 需求分析
2. 系統分析與設計
3. 程式設計與實作
4. 整合與測試
5. 部署與交付
6. 運作與維護

其概念可表示如下：

瀑布模型強調文件完整、階段清楚、審查程序明確，以及開發成果可依階段進行管理。

2. 瀑布模型的優點

（1）流程明確，容易規劃與管理

每個階段都有明確目標、輸入、輸出及完成條件，管理者可依據里程碑掌握進度、成本與人力配置。

（2）文件完整，便於溝通與維護

需求規格書、系統設計文件、測試文件等通常會在各階段建立，有助於：

• 團隊成員溝通；
• 後續人員接手；
• 系統維護與稽核；
• 開發成果留存。

對大型組織、政府機關及重視審查紀錄的專案，文件化尤其重要。

（3）責任分工清楚

各階段通常由不同角色負責，例如分析人員負責需求分析，設計人員負責架構設計，程式人員負責實作，測試人員負責驗證，因此組織分工較容易建立。

（4）適合需求穩定且明確的專案

若系統需求在開發前已相當明確，且技術成熟、變更幅度小，瀑布模型可以透過事前規劃降低開發過程中的管理複雜度。

（5）容易進行階段性審查

每完成一個階段，即可進行審查與核准，適合需要正式簽核、合約驗收及品質管制的專案。

3. 瀑布模型的缺點

（1）難以因應需求變更

瀑布模型在前期即要求明確定義需求。若進入設計、實作階段後才發現需求錯誤，通常必須回頭修改先前文件、設計與程式，造成時間及成本增加。

（2）使用者較晚才能看到可運作系統

系統通常要到實作及測試完成後，使用者才會看到完整成果。因此，使用者無法在早期透過實際操作發現需求認知差異。

（3）錯誤可能延後至後期才被發現

需求分析或系統設計階段的錯誤，若未在早期被察覺，可能一直延續到程式實作及測試階段。錯誤發現越晚，修正成本通常越高。

（4）階段間容易形成隔閡

各階段依序進行，團隊成員可能過度依賴文件與階段交接，造成分析、設計、程式及測試人員之間的溝通不足。

（5）開發週期較長，商業價值較晚產生

在系統完成前，使用者通常無法取得可直接使用的功能，導致需求變化、競爭環境或組織政策可能已經改變。

（6）不適合高度不確定或創新性高的專案

若需求尚未成熟、技術風險高，或使用者必須透過實際使用才能逐步確認需求，瀑布模型的固定流程容易降低應變能力。

4. 適用情境

瀑布模型較適用於：

• 需求明確且穩定；
• 技術成熟；
• 系統規模大且需完整文件；
• 合約規格固定；
• 需嚴格審查、驗收及稽核；
• 安全性、法規遵循要求較高的系統。

（二）敏捷模型及其優劣處【10 分】

1. 敏捷模型的定義與流程

敏捷模型是一種以反覆、增量方式進行軟體開發的方法。系統不必等到全部完成才交付，而是將大型專案拆分為多個短週期的迭代（Iteration）或衝刺（Sprint），每一週期完成一部分可運作功能。

其基本流程如下：

完成一個迭代後，再依使用者回饋與最新需求規劃下一個迭代，持續循環：

核心觀念

本題考查 UML 類別圖轉換為 ER Diagram 的方法，重點包括：

1. 類別（Class）轉換為實體（Entity）。
2. 類別屬性轉換為實體屬性。
3. <<PK>> 轉換為主鍵（Primary Key）。
4. UML 關聯多重度轉換為 Crow’s Foot 的基數。
5. <<identifying>> 關聯表示弱實體或識別關聯。
6. 泛化／繼承關係轉換為超類型（Supertype）與子類型（Subtype）。

解題方法

一、類別轉換為實體

由圖三可辨識出下列實體：

Customer

• CustomerNo：主鍵
• Name
• Tel
• Address

Order

• OrderNo：主鍵
• Date
• AStateattribute6：圖中文字即如此呈現，作為一般屬性

OrderDetail

• OrderLine：主鍵
• Price
• Quantity

Item

• ItemNo：主鍵
• Price
• Name

Customer 的子類型

Customer 分為：

• VIP：VIPLevel
• Normal：StartDate、EndMonth、MonthFee

二、關聯與基數轉換

1. Customer 與 Order

UML 顯示：

• 一個 Customer 可以沒有或有多筆 Order：$0..*$
• 一筆 Order 必須屬於一個 Customer：$1$

因此 Crow’s Foot 表示為：

這是非識別關聯（<<Non-identifying>>），所以 Customer 的主鍵不因該關聯而成為 Order 的主鍵；實作時通常在 Order 增加 CustomerNo 作為外鍵。

2. Order 與 OrderDetail

UML 顯示：

• 一個 Order 必須包含一筆以上 OrderDetail：$1..*$
• 一筆 OrderDetail 必須隸屬於一個 Order：$1$

因此 Crow’s Foot 表示為：

此關聯標示 <<identifying>>，表示 OrderDetail 的識別需要依賴 Order。實體設計上，OrderDetail 通常使用：

作為複合主鍵，其中 OrderNo 同時也是參照 Order 的外鍵。

3. Item 與 OrderDetail

UML 顯示：

• 一個 Item 可以出現在零筆或多筆 OrderDetail：$0..*$
• 一筆 OrderDetail 必須對應一個 Item：$1$

因此 Crow’s Foot 表示為：

此關聯標示 <<identifying>>。實體設計上，OrderDetail 應增加 ItemNo 作為參照 Item 的外鍵；

核心觀念

本題考查 SQL 的下列觀念：

• GROUP BY：依地區、月份、ATM 代號或帳號分組。
• 聚合函數：
• SUM：計算交易金額總和。
• COUNT(*)：計算交易筆數。
• WHERE：先篩選指定日期範圍。
• HAVING：對分組後的聚合結果進行條件篩選。
• 視窗函數 ROW_NUMBER：取得每個月份交易次數排名前三名的 ATM。
• CAST(交易日期 AS date)：忽略時間，只保留交易日期。

表四欄位可依圖辨識為：

• ATM 代號：ATM代號
• 客戶帳號：帳號
• 地區：地區
• 交易金額：交易金額
• 交易日期：交易日期
• 交易序號：交易序號

以下 SQL 以 SQL Server 語法撰寫，日期及欄位名稱依表四內容處理。

解題方法

（一）列出各地區的交易總金額

依「地區」分組，再使用 SUM(交易金額) 加總各組交易金額。

SELECT
 地區,
 SUM(交易金額) AS 交易總金額
FROM ATM_TRANS
GROUP BY 地區
ORDER BY 地區;

關鍵步驟

同一地區可能有多筆交易，因此必須：

GROUP BY 地區 會將相同地區的資料歸為同一組，SUM 再計算每組的總金額。

（二）列出 2020 年各月份交易次數前三高的 ATM 代號

本小題有兩層分組：

1. 先依「月份、ATM 代號」分組，計算每台 ATM 每月交易次數及交易總金額。
2. 再以月份為分區，依交易次數排序，取每月前三名。

WITH ATM_MONTHLY AS
(
 SELECT
 MONTH(交易日期) AS 交易月份,
 ATM代號,
 COUNT(*) AS 交易次數,
 SUM(交易金額) AS 交易總金額
 FROM ATM_TRANS
 WHERE 交易日期 >= '20200101'
 AND 交易日期 < '20210101'
 GROUP BY
 MONTH(交易日期),
 ATM代號
),
ATM_RANKING AS
(
 SELECT
 交易月份,
 ATM代號,
 交易次數,
 交易總金額,
 ROW_NUMBER OVER
 (
 PARTITION BY 交易月份
 ORDER BY 交易次數 DESC, ATM代號
 ) AS 排名
 FROM ATM_MONTHLY
)
SELECT
 交易月份,
 ATM代號,
 交易總金額
FROM ATM_RANKING
WHERE 排名 <= 3
ORDER BY
 交易月份,
 排名;

關鍵步驟

先計算每月每台 ATM 的交易次數：

再計算該 ATM 當月的交易總額：

PARTITION BY 交易月份 表示每個月份獨立排名；ORDER BY 交易次數 DESC 表示交易次數最多者排名第一。

日期條件使用：

交易日期 >= '20200101'
AND 交易日期 < '20210101'

可完整涵蓋 2020 年，且不會因為 交易日期 包含時間而漏掉 2020 年 12 月 31 日的資料。