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

在軟體開發過程中，「Stub」或「Method Stub」是一種程式設計的技巧，主要用於模擬（mock）或代表一個函數（function）或方法（method）的行為，但實際上並未實現其完整的功能。

Stub/Method Stub 的定義與目的：

1. 定義： Stub 是一個預先寫好的、簡化的函數或方法，它通常只包含最基本的邏輯，例如：

   • 返回一個預設值（如 null、0、false，或一個預定義的物件）。
   • 執行一些基本的日誌記錄（logging）以確認函數被呼叫。
   • 拋出一個例外（exception）指示該功能尚未實作。
   • 甚至可能只是簡單地結束執行。

2. 目的：

   • 模組化開發與測試： 當開發一個大型系統時，各個模組或組件可能需要相互呼叫。如果某些模組尚未完成，開發者可以使用 Stub 來代替這些未完成的模組。這樣，其他模組的開發和測試就可以繼續進行，而不會被尚未完成的依賴模組所阻礙。
   • 隔離測試 (Isolation Testing)： 在單元測試（Unit Testing）中，Stub 用於模擬被測試函數所依賴的其他函數或服務。這使得測試能夠專注於被測試單元的邏輯，而不會受到外部依賴項（如資料庫、網路服務）的影響，從而提高測試的穩定性和準確性。

統一塑模語言（Unified Modeling Language, UML）是一種標準化的塑模語言，用於視覺化、規格化、建構及文件化軟體系統的各種組件。UML 圖表主要分為結構圖（Structure Diagrams）和行為圖（Behavior Diagrams）。行為圖用於描述系統的動態行為，例如物件之間的互動、狀態的變化以及系統的執行流程。

以下選擇三種 UML 的行為圖，並簡述其用途：

1. Use Case Diagram (用例圖)

   • 用途： 用例圖是描述系統功能需求的最常用圖之一。它展示了系統與外部參與者（Actors）之間的互動。用例（Use Case）代表了系統提供的一項功能，而參與者則代表了與系統互動的使用者或外部系統。用例圖的主要目的是理解和定義系統的功能範圍，以及使用者如何與系統互動以達成特定目標。它幫助開發團隊、分析師和客戶之間建立對系統功能的共同理解。

2. Sequence Diagram (循序圖)

   • 用途： 循序圖是一種互動圖，用來展示物件之間在時間順序上的互動。它強調訊息（message）在物件之間的傳遞順序。圖中，物件沿著水平軸排列，時間沿著垂直軸向下流逝。循序圖非常適合用來描述一個特定用例（Use Case）的執行流程，或者特定操作（Operation）的詳細步驟，以及物件之間如何協同工作來完成任務。它能清晰地展示訊息的發送者、接收者、訊息內容以及訊息發生的先後順序。

3. State Machine Diagram (狀態機圖 / 狀態圖)

   • 用途： 狀態機圖（或稱狀態圖）用於描述一個物件在其生命週期內可能經歷的各種狀態，以及在接收到特定事件（event）時，如

核心觀念

本題考查：

1. 實體關聯模型（Entity-Relationship Model, ER Model）
2. 主鍵（Primary Key, PK）與外鍵（Foreign Key, FK）
3. 多對多關係的轉換
4. 基數／多重度（Multiplicity）
5. 第三正規化（Third Normal Form, 3NF）

題目已明確限定：

• 一位音樂家同一時間只能屬於一個樂團。
• 一位音樂家只有一項專長。

因此：

• Band 與 Musician 是一對多關係。
• MusicianSpecialty 與 Musician 是一對多關係。
• Concert 與 Band 是多對多關係，必須透過 PerformingBand 拆解。

---

解題方法

先辨識主要實體：

• 演唱會：Concert
• 樂團：Band
• 音樂家：Musician
• 音樂家專長：MusicianSpecialty

再分析關係：

• 一場演唱會可有多個樂團演出。
• 一個樂團可參加多場演唱會。
• 一個樂團可有多位音樂家。
• 一位音樂家只能屬於一個樂團。
• 一項專長可被多位音樂家擁有。
• 一位音樂家只有一項專長。

因此，演唱會與樂團之間的多對多關係，新增關聯實體 PerformingBand。

---

關聯式資料表設計

1. Concert

欄位	說明
ConcertID	主鍵
ConcertName	演唱會名稱
ConcertDate	演唱會日期
Venue	演出場地

Concert(
    ConcertID PK,
    ConcertName,
    ConcertDate,
    Venue
)

---

2. Band

欄位	說明
BandID	主鍵
BandName	樂團名稱
FormationDate	成團日期

Band(
    BandID PK,
    BandName,
    FormationDate
)

---

3. MusicianSpecialty

欄位	說明
SpecialtyID	主鍵
SpecialtyName	專長名稱

MusicianSpecialty(
    SpecialtyID PK,
    SpecialtyName
)

SpecialtyName 可設定為候選鍵，避免相同專長名稱重複，例如：

UNIQUE(SpecialtyName)

---

4. Musician

欄位	說明
MusicianID	主鍵
MusicianName	音樂家姓名
BandID	外鍵，參照 Band(BandID)
SpecialtyID	外鍵，參照 MusicianSpecialty(SpecialtyID)

Musician(
    MusicianID PK,
    MusicianName,
    BandID FK → Band(BandID),
    SpecialtyID FK → MusicianSpecialty(SpecialtyID)
)

由於題目限定一位音樂家只能屬於一個樂團，因此 BandID 放在 Musician 表中即可，不需要額外建立樂團成員表。

同理，由於一位音樂家只有一項專長，因此 SpecialtyID 放在 Musician 表中即可。

---

5. PerformingBand

Concert 與 Band 是多對多關係，因此建立中介表：

欄位	說明
ConcertID	主鍵的一部分，也是外鍵
BandID	主鍵的一部分，也是外鍵

PerformingBand(
    ConcertID PK, FK → Concert(ConcertID),
    BandID PK, FK → Band(BandID)
)

複合主鍵為：

PK(ConcertID, BandID)

此設計可避免同一樂團在同一場演唱會中被重複登錄。

---

ER Diagram

一、核心觀念概述

1. 企業資源規劃（ERP）系統

   • 定義：ERP 是整合公司內部所有功能（如財務、採購、製造、庫存、人事、銷售等）於同一套資訊平台之套裝軟體。
   • 目的：消除資訊孤島、統一資料格式、即時共享作業資訊，提升營運效率。

2. 網路詐騙手法 – Phishing

   • 定義：利用偽造的網頁或電子郵件，誘使使用者主動提供個人機密（帳號、密碼、信用卡資訊等）。
   • 特色：外觀與合法網站高度相似，常以「安全性警告」或「帳號驗證」為誘因。

3. 客戶關係管理（CRM）系統

   • 定義：CRM 旨在收集、分析、管理與客戶互動的所有資訊，支援行銷、服務、銷售與產品開發等流程。
   • 功能：客戶資料庫、需求回饋機制、線上展示、意見收集與分析，協助企業以客戶需求為導向改進產品。

4. 基礎設施即服務（IaaS）

   • 定義：雲端服務模型之一，服務供應商提供虛擬化硬體資源（伺服器、儲存、網路）以及作業系統，使用者可自行安裝應用程式。
   • 與 PaaS、SaaS 差異：IaaS 授予使用者最底層的控制權，僅負責自行管理上層軟體與資料。

---

二、解題方法與逐項推論

題號	題目敘述	解析步驟	正確填入詞彙
(1)	「公司欲將所有營運整合於單一數位平台」	先辨識「整合所有營運」的範疇，若僅是資料庫或介面整合，常稱為 Enterprise Application Integration (EAI)；但題目強調「單一數位平台」即「一套完整的商務功能」全部被納入，同時符合 MIS 課程常考的核心系統——ERP。	Enterprise Resource Planning (ERP)
(2)	「線上詐騙行為，設立假網站誘導訪客提供機密資訊」	「設立假網站」且「誘導提供資訊」正是 phishing（釣魚）行為的核心描述。其他選項如 spam（大量垃圾郵件）或 malware（惡意軟體）不符合「偽網站」的情境。	phishing
(3)	「線上展覽系統讓外國客戶觀看產品樣本、提供回饋以提升產品開發效率」	系統的目的是 收集客戶回饋、 促進產品開發，屬於 CRM 的「客戶需求收集」與「產品服務改進」模組。若以供應鏈或 ERP 描述，則較偏向內部作業，無法說明「客戶於線上給意見」的屬性。	Customer Relationship Management (CRM)

本題考查的是機器學習中的一種對抗性攻擊（Adversarial Attack）手法：資料投毒（Data Poisoning）。

核心概念：
資料投毒是一種惡意攻擊，攻擊者透過向機器學習模型的訓練資料集中注入錯誤、誤導性或惡意的資料，以破壞模型的訓練過程，進而影響模型的準確性、可靠性或安全性。

選項分析：

• a) To steal sensitive information from a dataset.

  • 這是資料洩漏（Data Leakage）或資料竊取（Data Theft）的目標，與資料投毒的機制不同。資料投毒是改變資料的「內容」以影響模型，而不是竊取資料本身。

• b) To corrupt training data in order to manipulate the behavior of a machine learning model.

  • 這是資料投毒的典型目標。攻擊者故意污染訓練資料，使得模型在學習過程中產生偏差，例如：
    • 降低模型的整體準確性。

本題考查的是量子計算（Quantum Computing）的潛在應用領域。量子計算利用量子力學原理（如疊加態、糾纏態）來進行計算，理論上能在特定問題上提供遠超傳統電腦的計算能力。

核心概念：
量子計算在解決某些特定類型的問題時具有指數級的優勢，例如：

1. 因數分解： Shor 演算法能有效破解目前廣泛使用的 RSA 等公開金鑰密碼系統。
2. 搜尋： Grover 演算法能以平方根的速度加速無結構數據庫的搜尋。
3. 模擬： 量子模擬（Quantum Simulation）可以精確模擬分子、材料的量子行為。
4. 優化問題： 量子退火（Quantum Annealing）或 QAOA (Quantum Approximate Optimization Algorithm) 等方法可用於解決複雜的優化問題。

選項分析：

• a) Drug discovery and materials science:

  • 這是量子計算最被看好的應用之一。透過精確模擬分子的量子行為，量子電腦可以加速新藥物的設計和發現，以及新材料的研發。這是量子模擬的範疇。

• b) Breaking modern encryption algorithms:

  • 這是量子計算最著名且最令人擔憂的應用之一。

本題考查的是大型語言模型（LLM）安全領域的一種攻擊手法：Prompt Injection（提示注入）。

核心概念：
Prompt Injection 是一種攻擊技術，攻擊者透過精心設計的輸入（prompt）來操縱大型語言模型（LLM）的行為。攻擊者試圖讓 LLM 忽略其原始的指令或安全防護機制，並執行攻擊者期望的、通常是惡意的或非預期的操作。

選項分析：

• a) To bypass authentication mechanisms and gain unauthorized access to a system.

  • 這描述的是典型的系統安全漏洞利用，如 SQL 注入（SQL Injection）或密碼破解，與 Prompt Injection 針對 LLM 的機制不同。雖然 Prompt Injection 有時可能間接導致未授權訪問，但這不是其「主要」目標。

• b) To inject malicious code into a running application, causing it to malfunction.

  • 這描述的是程式碼注入攻擊（Code Injection），如 SQL Injection 或 Cross-Site Scripting (XSS)。Prompt Injection 的目標是操縱 LLM 的 輸出 或 行為，而不是直接在應用程式中執行惡意程式碼。雖然 LLM 的輸出可能包含惡意內容，但攻擊的直接對象是 LLM 本身。

本題考查的是 Transformer 架構的核心組件——「注意力機制」（Attention Mechanism）的主要功能。Transformer 架構在自然語言處理（NLP）領域取得了巨大成功，尤其是在大型語言模型（LLM）中。

核心概念：
注意力機制是一種讓模型在處理序列資料時，能夠動態地權衡輸入序列中不同部分的重要性。它允許模型在生成輸出時，將「注意力」集中在輸入序列中最相關的部分。

選項分析：

• a) To apply mathematical operations to numerical data within the model.

  • 這是神經網路的通用功能，無論是線性層、卷積層還是其他計算單元，都會執行數學運算。注意力機制本身也包含數學運算，但這不是其「主要」功能，而是實現主要功能的手段。

• b) To selectively focus on relevant parts of the input sequence when processing information.

  • 這是注意力機制的定義和核心作用。例如，在機器翻譯中，當模型翻譯一個單詞時，注意力機制會幫助模型關注輸入句子中與該單詞最相關的其他單詞。在處理長序列時，這能有效解決傳統 RNN/LSTM 的長距離依賴問題。

這是一道關於低程式碼/無程式碼（Low-Code/No-Code, LCNC）平台的綜合題，共包含三個子題，分別探討 LCNC 平台的定義與互動設計、成本效益，以及潛在挑戰。

a. What are Low-Code/No-Code platforms, and how are they designed to enable user interaction? (6%)

• 定義：

  • 無程式碼 (No-Code, NC) 平台： 允許沒有程式設計背景的使用者（通常是業務分析師、領域專家或「公民開發者」）透過視覺化介面（如拖放式組件、預設模板、圖形化流程設計器）來建立應用程式。使用者無需編寫任何程式碼。
  • 低程式碼 (Low-Code, LC) 平台： 支援幾乎無需程式碼的開發，但也允許開發者編寫少量程式碼來實現更複雜的客製化、集成或特定功能。它為專業開發者提供了更快的開發速度，同時也讓非專業開發者能夠參與。
  • 總結： LCNC 平台旨在降低應用程式開發的門檻，加速開發週期，讓更多人能夠參與到應用程式的創建過程中。

• 如何設計以啟用使用者互動 (Enable User Interaction)：

  • 視覺化開發環境 (Visual Development Environment)：
    • 拖放式介面 (Drag-and-Drop Interface)： 使用者可以從預定義的組件庫（如按鈕、表單欄位、圖片、圖表）中選擇元素，並將其拖曳到畫布上進行佈局。
    • 圖形化流程設計器 (Graphical Flow Designers)： 用於設計應用程式的業務邏輯、工作流程、使用者導航流程，通常以流程圖的形式呈現。
    • 預設模板與組件 (Pre-built Templates & Components)： 提供大量現成的應用程式模板（如 CRM、專案管理、資產管理）和功能組件，用戶可以直接使用或稍作修改。
  • 模型驅動開發 (Model-Driven Development)： LCNC 平台通常基於模型來定義應用程式的結構、資料、邏輯和介面，而非直接編寫程式碼。使用者透過修改這些模型來驅動應用程式的生成。
  • 內建資料管理 (Built-in Data Management)： 許多平台提供內建的資料庫或簡便的資料模型建立工具，讓使用者可以輕鬆定義和管理應用程式所需的數據。
  • 即時預覽與測試 (Real-time Preview & Testing)： 開發過程中可以即時預覽應用程式的樣貌，並進行測試，快速迭代。
  • 自動化程式碼生成 (Automated Code Generation)： 雖然使用者不寫程式碼，但平台會在後台自動生成底層的程式碼，並將其部署為可運行的應用程式。
  • 協作功能 (Collaboration Features)： 允許團隊成員共同開發、審查和部署應用程式。

b. Explain how these platforms contribute to cost reduction for enterprises, providing specific examples where possible. (8%)

LCNC 平台透過多種方式幫助企業降低成本：

1. 降低開發人力成本 (Reduced Development Labor Costs)：

   • 減少對專業開發者的依賴： 由於公民開發者（非專業開發者）也能參與開發，企業可以減少對昂貴的專業軟體工程師的需求，或者讓專業開發者專注於更複雜的任務。
   • 加速開發週期： LCNC 的開發速度遠快於傳統編碼，這意味著項目可以更快完成，減少了項目管理和開發時間相關的成本。
   • 例： 一個中小型企業需要一個簡單的客戶報價單系統。傳統方式可能需要 2-3 個月、2-3 名開發者，成本數十萬。使用 LCNC 平台，一個業務分析師可能在 2-4 週內完成，成本僅為平台授權費加上該分析師的時間成本，節省了大量的開發人力和時間。

2. 降低維護成本 (Reduced Maintenance Costs)：

   • 標準化與自動化： LCNC 平台通常會自動生成符合標準的程式碼，並處理許多底層的技術細節（如安全補丁、相容性更新）。這減少了因技術債、程式碼不規範而產生的維護負擔。
   • 易於修改與擴展： 視覺化介面使得修改和擴展應用程式更加容易，即使是原始開發者離開，後續接手的人也能較快理解和修改。
   • 例： 一個企業使用 LCNC 平台開發的內部 HR 申請系統。當需要增加一個新的請假類型時，傳統方式可能需要開發者修改程式碼、重新測試和部署。使用 LCNC，HR 部門的負責人可能只需在視覺化流程中添加一個新的選項和相關邏輯，幾天內即可完成，大大降低了修改成本。

3. 加速業務創新與上市時間 (Faster Time-to-Market for Innovation)：

   • 快速原型驗證： LCNC 使得企業能夠快速構建和測試新的業務想法或應用程式原型，驗證其可行性，從而避免在不可行的項目上投入過多資源。

這是一道關於大型語言模型（LLMs）的題目，聚焦於 Meta 公司將其 LLM 開源的策略，以及 LLM 的技術細節和與通用人工智能（AGI）的關係。

a. What are Meta's potential business motivations for releasing their LLM as open source? (8%)

Meta 將其 LLM（如 Llama 系列）開源，這看似與大多數公司將 LLM 作為專有產品銷售的策略不同。然而，這背後有著多重商業動機：

1. 加速生態系統發展與採用 (Accelerating Ecosystem Development and Adoption)：

   • 吸引開發者社群： 開源模型鼓勵全球的開發者、研究人員和企業在其基礎上進行創新、構建應用程式和服務。這能快速擴大 Llama 的生態系統，使其成為業界標準之一。
   • 增加市場滲透率： 讓更多人能夠免費使用和修改模型，可以快速推廣 Llama 的技術，使其在市場上獲得更廣泛的應用，這對 Meta 來說是一種長期的戰略投資。

2. 推動技術標準與影響力 (Driving Technical Standards and Influence)：

   • 樹立技術領導者形象： 透過開源先進的模型，Meta 可以展現其在 AI 領域的技術實力，吸引頂尖人才，並在 AI 技術的發展方向上產生更大的影響力。
   • 引導業界標準： 如果 Llama 成為廣泛使用的開源模型，其架構、訓練方法等可能被視為行業標準，這對 Meta 的長期戰略有利。

3. 降低開發與研究成本 (Reducing Development and Research Costs)：

   • 集體智慧與社群貢獻： 開源模型可以讓社群發現 bug、提出改進建議、開發新的應用，這相當於 Meta 獲得了免費的「眾包」研發團隊，能夠更快地迭代和完善模型。
   • 專注於核心優勢： Meta 可以將資源集中在開發更先進的模型、更高效的訓練技術，或開發基於 Llama 的增值服務，而不是重複構建基礎模型。

4. 為未來商業化鋪路 (Paving the Way for Future Monetization)：

   • 雲端部署與託管服務： 雖然模型本身開源，但 Meta 或其合作夥伴（如雲服務提供商）可以提供基於 Llama 的託管服務、企業級支援、微調服務、API 訪問等，從而實現商業變現。
   • 數據與硬體生態： 廣泛的 Llama 使用者可能會產生大量的數據，這些數據對 Meta 的其他業務（如廣告、元宇宙）可能具有價值。同時，對高性能 GPU 等硬體的需求也會間接推動相關產業發展。
   • 競爭策略： 對抗其他專有模型（如 OpenAI 的 GPT 系列），開源策略可以吸引那些不願被單一供應商鎖定的用戶。

5. 促進 AI 倫理與安全研究 (Promoting AI Ethics and Safety Research)：

   • 開放模型允許獨立研究人員更深入地審查模型的行為、潛在偏見和安全風險，這有助於推動 AI 的負責任發展，並可能為 Meta 贏得良好的聲譽。

b. Meta's Llama 3.1 comes in several versions (8B, 70B, and 405B). What do the numbers and the letter "B" represent? How do these differences affect the performance and capabilities of the LLM? (6%)

• 數字和字母 "B" 的含義：

  • 數字（8, 70, 405）和字母 "B" 代表的是模型中的參數數量。
  • "B" 是 "Billion" 的縮寫，表示「十億」。
  • 因此，8B 表示該模型約有 80 億個參數，70B 表示約有 700 億個參數，405B 表示約有 4050 億個參數。

• 參數數量對性能和能力影響：

  • 模型規模 (Model Size)： 參數數量是衡量模型大小和複雜度的重要指標。通常來說，參數越多的模型，其容量越大，能夠學習更複雜的模式和更細緻的語言特徵。
  • 性能 (Performance)：
    • 準確性與理解能力： 更大的模型（更多的參數）通常在各種 NLP 任務上表現出更高的準確性，例如文本生成、問答、翻譯、摘要等。它們能更好地理解上下文、捕捉細微的語義差異，並生成更連貫、更符合邏輯的文本。
    • 知識儲存： 參數數量也與模型能「記憶」的知識量有關。更大的模型可以儲存更多的世界知識和語言規則。
  • 計算資源需求 (Computational Resource Requirements)：
    • 訓練成本： 訓練更大的模型需要更多的計算資源（GPU 數量、訓練時間）和數據，成本也更高。
    • 推理成本： 運行（推理）更大的模型也需要更強大的硬體（更多記憶體、更快的處理器），這意味著更高的部署成本和更長的響應時間（延遲）。
  • 應用場景：