115 年 國立成功大學資訊管理研究所甲組《管理資訊系統》

這題考驗 UML 類別圖 (Class Diagram) 的繪製能力，包含屬性 (attributes) 的定義、建構子 (constructors) 的設計，以及方法的 (methods) 實作。

核心觀念：
UML 類別圖是物件導向分析與設計 (OOAD) 中用來表示系統結構的重要工具。它描述了系統中的類別、屬性、操作 (方法) 以及類別之間的關係。

解題步驟：

1. 類別名稱與可見性： 類別名稱為 "Professor"，通常放在類別圖的頂部區域。屬性通常是私有的 (private)，前面加上 '-' 符號。方法通常是公有的 (public)，前面加上 '+' 符號。

2. 屬性定義： 根據題目要求，列出所有私有屬性，並標示其資料型態。

   • teacher ID: string (key) -> - teacherID: String
   • first name: string -> - firstName: String
   • last name: string -> - lastName: String
   • address: string -> - address: String
   • cell phone number: string (default value +886+900000000) -> - cellPhoneNumber: String = "+886+900000000"
   • college: string -> - college: String
   • department: string -> - department: String
   • office phone number: string -> - officePhoneNumber: String
   • date of birth: date -> - dateOfBirth: Date
   • date employed: date -> - dateEmployed: Date

3. 建構子定義：

   • 第一個建構子：接受 firstName, lastName, address 作為參數。建構子通常與類別名稱相同，但 UML 中一般寫成 + Professor(...)。
     + Professor(firstName: String, lastName: String, address: String)

這題考驗 UML 溝通圖 (Communication Diagram) 的繪製能力，用於展示物件之間的互動順序。

核心觀念：
溝通圖（舊稱協作圖 Collaboration Diagram）強調物件之間的訊息傳遞，它會顯示物件的連結以及傳遞的訊息。雖然 UML 2.x 後推薦使用互動圖 (Interaction Diagram) 中的時序圖 (Sequence Diagram)，但溝通圖仍能清晰地展現訊息流。

解題步驟：

1. 識別參與者 (Lifelines)：

   • 需要一個物件來觸發更新操作，例如一個 Professor 物件或一個管理介面物件。我們假設有一個 Professor 物件來進行自我更新。
   • Professor 物件本身。

2. 識別訊息 (Messages)：

   • 觸發更新：可能是一個使用者透過介面輸入新手機號碼，然後呼叫 Professor 物件的某個方法。
   • 更新屬性：Professor 物件接收到新手機號碼後，會更新其 cellPhoneNumber 屬性。

3. 繪製溝通圖 (文字描述)：
   溝通圖的結構通常是物件（表示為矩形）和它們之間的連結線，訊息沿著連結線標示，並附有序列號。

   假設我們有一個 prof: Professor 物件，並且有一個外部的 UI (使用者介面) 來觸發更新。

   +-------+       +-----------------+
   |  UI   |------>|   prof:Professor|
   +-------+       +-----------------+
       |               |
       | 1: updateCellPhoneNumber(newNumber: String) |
       |-------------------------------------------->|
       |               |
       |               | 2: setCellPhoneNumber(newNumber: String)
       |               |-------------------------------------------->|
       |               |               |
       |               |               | 3: cellPhoneNumber = newNumber
       |               |               |----------------------------->|
   

   說明：

   • prof: Professor：表示一個 Professor 類別的物件實例，命名為 prof。
   • UI：代表使用者介面，是觸發訊息的來源。
   • 1: updateCellPhoneNumber(newNumber: String)：UI 發送訊息給 prof 物件，呼叫 updateCellPhoneNumber 方法，傳入新的手機號碼。這個方法可能是一個公共方法，它負責驗證或處理更新邏輯。

這題考驗對現代電子商務架構的理解，特別是可組合式商業 (Composable Commerce) 架構。

核心觀念：
可組合式商業架構是一種現代的電子商務架構模式，它將電子商務功能分解為獨立、可替換的服務（通常是微服務），以便企業可以根據自身需求靈活地組合這些服務，從而快速創新和適應市場變化。

解題步驟：

1. 解釋可組合式商業架構 (Composable Commerce Architecture)：

   • 定義： 可組合式商業是一種架構模式，將電子商務平臺的功能模組化、服務化（通常是 API-first 的微服務），允許企業從不同的供應商選擇最佳的服務，並將它們組合起來，構建高度客製化且靈活的電商解決方案。
   • 核心理念： "Best-of-breed"（選用各領域最優的服務），"API-first"（所有功能都透過 API 暴露，便於集成），"Headless"（前端與後端分離，允許使用多種前端介面）。

2. 說明其關鍵原則 (Key Principles)：

   • 模組化 (Modularity)： 將電商功能（如目錄管理、購物車、訂單管理、支付、推薦引擎等）分解為獨立的、可獨立部署和擴展的模組或微服務。
   • API-Driven (API-First)： 每個模組或服務都必須透過標準化的 API（通常是 RESTful API）進行暴露，以便其他服務或前端應用程式能夠輕鬆地進行調用和集成。
   • 前後端分離 (Decoupled Frontend/Backend)： 前端（使用者介面，如網站、行動應用程式）與後端（業務邏輯、數據處理）完全分離。這使得前端可以獨立更新，並支援多個前端體驗（如網站、APP、IoT 設備）。
   • 最佳服務選擇 (Best-of-Breed Selection)： 企業可以自由選擇來自不同供應商的、最適合其特定需求的服務，而不是被單一供應商綁定。
   • 靈活性與可擴展性 (Flexibility and Scalability)： 由於模組化和 API 驅動的特性，企業可以更容易地替換、升級或添加新的服務，以及獨立擴展各個服務，以應對流量變化。
   • 快速創新 (Agility and Innovation)： 企業能夠更快地響應市場變化，測試新功能，並將其部署到生產環境中，因為他們可以獨立地更新或替換個別服務。

3. 與傳統電子商務架構的差異 (Difference from Traditional E-commerce Architecture)：

這題考驗對資訊系統中輸入驗證 (Input Validation) 方法的理解。

核心觀念：
輸入驗證是資訊安全和資料完整性的重要環節，旨在確保輸入系統的資料是正確、完整、安全且符合預期格式的。

解題步驟：
以下介紹三種常見的輸入驗證方法：

1. 類型檢查 (Type Checking)：

   • 說明： 檢查輸入資料是否符合預期的資料型態。例如，數字欄位是否真的只包含數字，日期欄位是否為有效的日期格式，布林值是否為 true 或 false。
   • 範例：
     • 使用者輸入年齡，系統應檢查該輸入是否為一個整數。
     • 日期欄位，應檢查是否為 YYYY-MM-DD 的格式，且月份和日期是有效的。
   • 目的： 防止因資料型態不符而導致的程式錯誤或意外行為。

2. 範圍檢查 (Range Checking)：

   • 說明： 檢查數值型或日期型資料是否落在預定義的有效範圍內。
   • 範例：
     • 折扣百分比，應檢查是否在 0% 到 100% 之間。
     • 學生的分數，應檢查是否在 0 到 100 分之間。
     • 註冊時的出生年份，應限制在一個合理的範圍內（例如，不早於 1900 年，不晚於今年）。
   • 目的： 確保輸入的數值或日期在邏輯上是合理的。

3. 格式檢查 (Format Checking) / 模式檢查 (Pattern Matching)：

   • 說明： 檢查輸入資料是否符合特定的字串模式或結構。這通常使用正規表達式 (Regular Expressions) 來實現。
   • 範例：

這題考驗對人工智慧 (AI)、密碼學、資料科學和區塊鏈等領域的基礎概念的掌握。

核心觀念：
本題為克漏字題，需要填入最適合描述該句子的術語。

解題步驟：

1. 分析句子 (1)：

   • 關鍵詞：「AI 應用程式」、「自己的心智模型 (mental models)」、「多模態真實世界數據 (multimodal real-world data)」、「理解真實世界的動態 (comprehending the dynamics of the real world)」。
   • 這描述了一種 AI 的高級目標，即讓 AI 能夠像人類一樣建立內部表徵來理解和互動世界。這與「具身智慧 (Embodied AI)」、「通用人工智能 (AGI)」或「世界模型 (World Model)」的概念有關。在 AI 領域，"World Model" 是最常與此類描述相關聯的術語。
   • 填空： World Model

2. 分析句子 (2)：

   • 關鍵詞：「加密演算法 (encryption algorithm)」、「將訊息分割成固定長度明文 (divides the message into a number of fixed-length plaintexts)」、「產生相同長度的密文 (generate a corresponding ciphertext of the same length)」。
   • 這描述了一種加密方式，將明文塊處理後生成對應的密文塊。這與「分組密碼 (Block Cipher)」的概念非常吻合，因為分組密碼就是將明文分割成固定大小的區塊進行加密。

這題考驗對「社會資本 (Social Capital)」概念的理解，以及過度追求關係數量的潛在風險。

核心觀念：
社會資本是指個體或組織透過其社會網絡（人際關係、信任、互惠等）所獲得的資源和利益。過度強調關係的「數量」而忽略「質量」或「其他因素」，可能導致問題。

解題步驟：

1. 理解社會資本： 社會資本不僅僅是認識多少人，還包括關係的質量、信任程度、信息獲取能力、資源獲取能力等。
2. 分析題目情境： 組織「僅僅」專注於增加網絡中的「關係數量」(Number of Relationships)。
3. 評估選項：
   • a) It leads to "Analysis Paralysis" by generating too much data.
     • 增加關係數量確實可能帶來更多資訊，但「分析癱瘓 (Analysis Paralysis)」更常與決策過程中的資訊過載、過度分析有關，不一定是單純關係數量多就必然導致。這個選項與「社會資本」的直接關聯性較弱。
   • b) A large network with limited resources is less valuable than a smaller, well-resourced one.
     • 這句話點出了「質量」與「數量」的權衡。

這題考驗對 NoSQL 資料庫與 ACID 特性之間關係的理解。

核心觀念：
ACID 是指資料庫交易 (transaction) 的四個核心屬性：原子性 (Atomicity)、一致性 (Consistency)、隔離性 (Isolation)、持久性 (Durability)。傳統的關聯式資料庫 (RDBMS) 非常強調 ACID，以確保資料的準確性和可靠性。NoSQL 資料庫則通常為了某些其他目標而犧牲部分 ACID 屬性。

解題步驟：

1. 理解 ACID：

   • Atomicity (原子性)： 交易是不可分割的工作單元，要么全部完成，要么全部不執行。
   • Consistency (一致性)： 交易完成後，資料庫從一個有效狀態轉換到另一個有效狀態。
   • Isolation (隔離性)： 並發執行的交易之間不會相互影響。
   • Durability (持久性)： 一旦交易被提交，其結果就是永久性的，即使系統故障也不會丟失。

2. 理解 NoSQL 的設計目標：
   NoSQL 資料庫（如 MongoDB, Cassandra, Redis）通常追求以下目標：

   • 高可擴展性 (Scalability)： 能夠輕鬆地水平擴展（增加更多伺服器）來處理大量數據和高併發請求。
   • 高性能 (High Performance)： 快速的讀寫速度，尤其是在處理大量數據時。
   • 高可用性 (High Availability)： 系統能夠持續運行，即使部分節點故障。
   • 靈活的資料模型 (Flexible Data Model)： 支援非結構化或半結構化數據，易於改變 schema。

3. 分析選項：

   • a) They are designed for "Personal" scope information systems where data duplication is not a concern.
     • NoSQL 系統不僅用於個人系統，更廣泛應用於大型、企業級的分散式系統。

這題考驗對「企業應用整合」(Enterprise Application Integration, EAI) 概念的理解。

核心觀念：
EAI 的目標是將企業內部的不同應用系統（如 ERP, CRM, SCM, 會計系統等）連接起來，實現數據和流程的共享與協同，打破部門之間的資訊孤島（silos）。

解題步驟：

1. 理解「部門孤島」(Departmental Silos)： 指的是企業內部各部門的資訊系統獨立運作，數據難以共享，流程不暢通，導致效率低下和決策困難。
2. 理解 EAI 的核心目的： 整合分散的系統，實現信息流動，提高整體運營效率。
3. 評估選項：
   • a) It replaces all existing systems with a single, integrated ERP database.
     • 這描述的是 ERP (Enterprise Resource Planning) 系統的導入，而不是 EAI。EAI 的重點是「整合現有」系統，而非用單一系統完全替換。

這題涵蓋了軟體開發的新興概念「vibe coding」以及「數位來源 (Digital Provenance)」的理解，並從 CIO 的角度評估風險。

核心觀念：

• Vibe Coding： 是一種新興的軟體開發方法，強調利用 AI 助手（如 Copilot, ChatGPT 等）來輔助程式碼編寫，以提高開發效率。它不僅是自動完成，更可能涉及 AI 根據開發者意圖生成程式碼、解釋程式碼、甚至進行測試。
• Digital Provenance (數位來源)： 指的是數位資產（如文件、程式碼、數據、媒體等）的創建、修改、傳播和使用歷史記錄。它追溯了數位內容的來源、作者、時間、地點、所使用的工具和過程，確保其來源的可靠性和可追溯性。
• CIO 的風險管理： 資訊長 (CIO) 負責企業的資訊技術策略和風險管理，需要評估新技術導入可能帶來的營運、安全、合規等風險。

解題步驟：

a. Define vibe coding and identify the core technology that enables it. (6%)

• 定義 (Definition of Vibe Coding)：
  Vibe coding 是一種軟體開發範式，它利用人工智慧（AI）驅動的程式碼助手（如 GitHub Copilot, OpenAI Codex, ChatGPT 等）來輔助開發人員編寫程式碼。這種方法旨在透過 AI 提供程式碼建議、自動生成程式碼片段、自動完成函數，甚至根據自然語言描述生成整個模組，從而顯著提高開發效率、減少重複性工作，並可能幫助開發人員探索新的解決方案。它強調的是一種「協作式」的開發模式，其中開發人員與 AI 共同創作程式碼。

• 核心技術 (Core Technology)：
  Vibe coding 的核心技術是大型語言模型 (Large Language Models, LLMs)，特別是那些經過大量程式碼數據訓練的 LLMs。這些模型能夠理解程式碼的語法、結構、常見模式，並根據上下文生成邏輯上合理且語法正確的程式碼。

  • 具體技術包括：
    • Transformer 架構： 這是現代 LLMs 的基礎，使其能夠處理長序列的文本（包括程式碼）。
    • 預訓練 (Pre-training)： 在海量程式碼數據集（如 GitHub 上的公開程式碼）上進行無監督學習，使模型學會程式碼的模式和結構。
    • 微調 (Fine-tuning)： 在特定任務或領域的數據上進一步訓練模型，以提高其在特定編碼任務上的表現。
    • 自然語言處理 (NLP) 和程式碼生成 (Code Generation)： 模型能夠理解開發者的自然語言指令，並將其轉換為相應的程式碼。
    • 上下文理解 (Contextual Understanding)： 模型能分析周圍的程式碼，提供與當前上下文相關的建議。

b. Explain the concept of digital provenance using an example other than vibe coding. (6%)

• 概念解釋 (Concept Explanation)：
  數位來源 (Digital Provenance)，又稱數位血統 (digital lineage) 或數位出處 (digital origin)，是指一個數位資產（如一份文件、一張圖片、一段影片、一項數據、一塊程式碼）的完整生命週期記錄。它追溯了該資產從創建開始，經過的所有修改、轉換、複製、傳播和使用的歷史軌跡。這些記錄通常包括：

  • 創建者/作者 (Creator/Author)： 誰創建了這個資產。
  • 創建時間與地點 (Timestamp and Location)： 何時何地創建。
  • 所用工具/軟體 (Tools/Software Used)： 使用了哪些軟體或工具進行創建或編輯。
  • 修改歷史 (Modification History)： 誰在何時對其進行了哪些修改。
  • 數據來源 (Data Source)： 如果是數據，其原始來源是什麼。
  • 傳播路徑 (Propagation Path)： 如何傳播到不同的地方。
  • 使用記錄 (Usage Records)： 在何處、以何種方式被使用。

  數位來源的目的是為了驗證資訊的真實性、完整性、來源的可靠性，以及在出現問題時進行追溯和問責。

• 範例 (Example other than vibe coding)：
  例子：新聞圖片的數位來源
  假設一張新聞圖片顯示了某個重要事件的現場。為了驗證這張圖片的真實性，我們可以追溯其數位來源：

  1. 原始拍攝： 攝影師使用特定型號的相機（記錄了相機型號、拍攝時間、GPS 位置等 EXIF 數據）在特定時間和地點拍攝了照片。
  2. 初步編輯： 攝影師將照片導入到 Lightroom 等編輯軟體中，進行了基本的亮度、對比度調整，並可能添加了水印。這些編輯操作會被記錄在元數據中。
  3. 傳輸至新聞機構： 照片透過安全的文件傳輸協議（如 SFTP）傳送給新聞機構的編輯部。傳輸記錄可以證明文件的來源和時間。

核心觀念

• 網路效應 (Network Effects)：使用者數量 $N$ 與平台價值呈正相關，常用 $V = \alpha N^\beta$（$\beta>1$ 為正向網路效應）。
• 使用者終生價值 (Lifetime Value, LTV)：$LTV = \sum_{t=0}^{T} \frac{R_t}{(1+r)^t}$，其中 $R_t$ 為第 $t$ 期貢獻收入，$r$ 為貼現率。
• 資料之策略價值：資料可分為 行為資料（使用行為、互動）與 特徵資料（人口統計、偏好）。資料品質與樣本多樣性直接影響機器學習模型的泛化能力。
• 資訊系統重設 (MIS Redesign)：資訊系統的功能與流程會因外部規範變更而重新配置，分為 成本 (Cost of Doing Business, CDB) 與 策略機會 (Strategic Redesign, SR) 兩種處理方式。

a. 網路效應觀點分析未滿 16 歲使用者被排除的長期影響（6%）

1. 使用者基數減少

   • 假設 16 歲以下佔總使用者 $p_{<16}$（約 15%），則平台新加入使用者 $N_{new}$ 減少 $p_{<16}N_{new}$。
   • 新增使用者的成長率 $g$ 下降至 $g' = g(1-p_{<16})$。

2. 正向網路效應衰減

   • 原平台價值 $V = \alpha N^\beta$。排除未滿 16 歲後，$N' = (1-p_{<16})N$，故
     $\frac{V'}{V} = \left(1-p_{<16}\right)^\beta.$
   • 若 $\beta = 1.5$（常見的強網路效應），則 $V'/V \approx (0.85)^{1.5} \approx 0.78$，平台整體價值下降約 22%。

3. 使用者黏著度與互動指標

   • 青少年用戶的 高互動率（貼文、分享）對活躍度 $A$ 有較大貢獻，排除後 $A$ 下降 $\Delta A \approx p_{<16}\times \text{互動係數}$。
   • 活躍度下降進一步抑制新用戶的 口碑效應，形成負向迴圈。

4. 長期價值主張 (Value Proposition) 變化

   • 廣告商依賴人口結構與活躍度決策 CPM，年輕族群的 CPM 較高，排除後 CPM 均值下降。
   • 平台必需將 LTV 重新估算，因為 $LTV_{<16}$ 佔總 LTV 約 $p_{<16}\times \frac{R_{<16}}{R_{total}}$，若 $R_{<16}$ 大於比例貢獻，$LTV$ 下降幅度更大。

結論：排除未滿 16 歲使用者會削弱正向網路效應，減少平台規模與互動密度，最終導致平台長期價值主張下降約 15–25%。

b. 策略資訊系統觀點：未成年資料與成年資料的價值差異（7%）