理解類圖：以訂單管理系統為例的全面指南

一個 類圖是軟體工程與資料庫設計中的基本工具，用於以視覺化方式呈現系統的結構，顯示其類別（或實體）、屬性、方法以及它們之間的關係。它是統一模型語言（UML）的一部分，一種用於設計軟體系統的標準化建模語言。類圖廣泛應用於物件導向程式設計與資料庫設計中，用於在實作前定義系統的藍圖。

在這份全面指南中，我們將探討 類圖的關鍵概念，並以您提供的訂單管理系統範例作為實際參考。我們將剖析其組成部分、符號、關係與最佳實務，確保徹底理解。

1. 類圖概覽

類圖透過顯示以下內容來呈現系統的靜態結構：

• 類別：系統的構建模塊，代表實體（例如 Customer 或 Order 等物件）。
• 屬性：類別的屬性或資料欄位（例如 Customer 的姓名或 Order 的建立日期）。
• 方法：類別可執行的行為或操作（例如計算小計）。
• 關係：類別之間如何互動（例如 Customer 下訂單）。

類圖在軟體開發的設計階段非常有用，因為它們：

• 提供系統的高階視圖。
• 幫助開發人員與相關人員理解系統結構。
• 作為程式撰寫或資料庫結構建立的藍圖。

2. 類圖的關鍵組成部分

讓我們使用以下範例來剖析類圖的組成部分：

2.1. 類別

類別以一個被分成三個部分的矩形框來表示：

• 頂端部分：類別名稱（例如 客戶, 訂單).
• 中間部分：屬性（例如，name：字串在客戶 類別中）。
• 底部部分：方法（例如，+ getPriceForQuantity()在項目 類別中）。

來自圖示的範例

• 類別：客戶
  • 屬性:
    • name：字串
    • 送貨地址：字串
    • 聯絡方式：字串
    • 啟用：布林值
  • 方法：此情況下無。
• 類別：項目
  • 屬性:
    • 重量：浮點數
    • 描述：字串
  • 方法:
    • + getPriceForQuantity()
    • + getWeight()

符號說明

• 屬性以以下方式書寫：名稱：類型（例如，名稱：字串).
• 方法以以下方式書寫：名稱()若適用，則加上傳回類型（例如，getPriceForQuantity()).
• 在方法前的+符號表示公開存取權限（可被其他類別存取）。其他存取權限修飾符包括：
  • –用於私有（僅限於類別內部存取）。
  • #用於保護（可在類別及其子類別中存取）。

2.2. 列舉

列舉（<<列舉>>）是一種特殊類別，用於定義一組固定的常數。通常用來表示預先定義的值清單。

圖示範例

• 列舉：訂單狀態
  • 值：
    • 建立：整數 = 0
    • 運送中：int = 1
    • 已交付：int = 2
    • 已付款：int = 3

說明

• 這個<<枚舉>>方框上方的造型符號表示這是一個枚舉。
• 訂單狀態定義訂單可能的狀態（例如：已建立、運送中、已交付、已付款）。
• 每個值都會被分配一個整數（例如，建立 = 0），這可能在程式碼中用來追蹤訂單的狀態。

2.3. 屬性

屬性描述類別的資料或屬性。通常會列出其名稱、類型，有時也會列出初始值。

來自圖示的範例

• 在訂單類別中：
  • 建立日期：日期 – 訂單建立的日期。
• 在信用類別中：
  • 號碼：字串
  • 類型：字串
  • 到期日期：日期

符號說明

• 屬性遵循以下格式：名稱：類型（例如，重量：浮點數).
• 如果指定了初始值，則寫作名稱：類型 = 值（例如，在列舉中，CREATE：整數 = 0).

2.4. 方法

方法代表類別可以執行的操作或行為。它們通常用於操作類別的屬性或執行計算。

來自圖示的範例

• 在項目 類別中：
  • + getPriceForQuantity() – 可能根據訂購數量計算總價。
  • + getWeight() – 回傳項目的重量。
• 在訂單明細 類別中：
  • + calculateSubTotal() – 計算明細項目之小計（例如，價格 × 數量）。
  • + calculateWeight() – 計算明細項目之總重量（例如，重量 × 數量）。

符號說明

• 方法寫作名稱()搭配可見性修飾符（例如，+ 表示公開）。
• 如果一個方法返回一個值，可以指定返回類型（例如，getWeight(): float).

3. 類別之間的關係

關係定義了類別之間如何互動。圖表使用線條、符號和數字來表示關係的類型和數量。

3.1. 關聯

關聯表示兩個類別之間的一般關係，通常表示一個類別使用或與另一個類別互動。

圖中的範例

• 客戶至訂單:
  • 一條線連接客戶和訂單.
  • 數量: 1（客戶）至0..*（訂單）。
  • 說明：一位客戶可以下零筆或多筆訂單（0..*），但每筆訂單僅與一位客戶相關（1).

符號說明

• 實線表示關聯。
• 數量標示於線條的兩端：
  • 1: 恰好一個。
  • 0..*: 零個或更多。
  • 1..*: 一個或更多。

3.2. 聚合

聚合是一種特殊的關聯，代表「整體-部分」關係，其中部分可以獨立於整體存在。它以在「整體」側的空心菱形來表示。

來自圖示的範例

• 訂單至訂單明細:
  • 一條帶有空心菱形的線連接訂單至訂單明細.
  • 基數: 1（訂單）至1..*（訂單明細）。
  • 說明: 訂單（整體）包含一個或多個訂單明細（部分）。如果刪除訂單，訂單明細可能仍然存在（取決於系統規則）。

3.3. 組合

組合是聚合的一種更強形式，其中部分無法在沒有整體的情況下存在。它以在「整體」側的實心菱形來表示。雖然圖示並未明確使用組合，但為了完整性仍值得提及。

假設範例

如果訂單明細無法在沒有訂單（例如，刪除訂單會刪除其所有細節），菱形將被填滿以表示組合關係。

3.4. 繼承（泛化）

繼承代表一種「是一種」的關係，其中子類別從父類別繼承屬性和方法。它以指向父類別的三角形來表示。

圖中的範例

• 付款方式包括現金、支票、信用卡和電匯:
  • 一個三角形連接付款（父類）至現金, 支票, 信用卡，以及電匯（子類）。
  • 說明:
    • 現金, 支票, 信用卡，以及電匯繼承金額：浮點數屬性來自付款.
    • 每個子類別都會新增其特有的屬性（例如，現金具有現金支付金額：浮點數, 信用卡具有卡號：字串).
    • 這允許多型行為：付款可被視為付款無論其具體類型為何。

符號說明

• 實線搭配三角形（指向父類）表示繼承關係。
• 子類別會繼承父類的所有屬性和方法，但也可以新增自己的屬性或方法，或覆蓋繼承來的方法。

4. 實際範例：訂單管理系統

讓我們詳細分析所提供的類圖以了解這些概念如何在實際情境中整合。

4.1. 系統概觀

此圖表示一個訂單管理系統，其中：

• 一位顧客下了一筆訂單.
• 一筆訂單 包含一個或多個 訂單明細 項目，每個項目都與一個 項目.
• 該 訂單 是使用一個或多個 付款 方式支付（例如 現金, 支票, 信用卡，或 電匯).
• 該 訂單的狀態是透過 訂單狀態 來追蹤。

4.2. 類別及其角色

• 顧客：代表下訂單的人。屬性包括 姓名, 送貨地址，以及 聯絡儲存客戶資料。
• 訂單: 核心實體，代表客戶的訂單。它具有建立日期，並與客戶、訂單明細及付款相關聯。
• 商品: 代表具有重量及描述的商品。它具有計算價格和取得重量的方法。
• 訂單明細: 代表訂單中的一筆明細項目，將商品與數量（數量）及稅務狀態。它具有計算小計和重量的方法。
• 付款: 付款方式的父類別，包含子類別（現金, 支票, 信用卡, 電匯）以處理不同的付款類型。
• 訂單狀態: 用於追蹤訂單狀態的列舉（例如：已建立、已發貨、已送達、已付款）。

4.3. 實際關係

• 客戶至訂單: 一位客戶可以下多筆訂單（0..*），但每筆訂單僅屬於一位客戶（1).
• 訂單至訂單明細: 一筆訂單包含一筆或多筆訂單明細（1..*），且每筆訂單明細僅屬於一筆訂單（1).
• 訂單明細至商品: 每筆訂單明細對應一項商品（1），但一項商品可出現在多筆訂單明細中（0..*).
• 訂單至付款: 一筆訂單可有 multiple 付款（1..*），且每筆付款僅與一筆訂單相關（1).
• 付款繼承: 現金, 支票, 信用卡，以及電匯是特定類型的付款，繼承自金額屬性付款.

4.4. 商業邏輯

• 這個項目類別具有像getPriceForQuantity()，表示它會根據訂購數量來計算項目的成本。
• 這個訂單明細類別具有像calculateSubTotal()以及calculateWeight()，這些方法可能使用項目的價格和重量來計算每筆明細的總計。
• 這個支票類別有一個authorized()方法，表示支票付款存在某些驗證邏輯。

5. 建立類圖的最佳實務

以下是根據範例建立有效類圖的一些技巧：

5.1. 保持簡單

• 專注於核心實體和關係。範例圖表僅包含相關的屬性和方法，以避免不必要的複雜性。
• 使用枚舉（例如OrderStatus）來表示預定義值，以使圖表更易讀。

5.2. 使用正確的符號

• 明確標示可見性（+, –, #）以區分屬性和方法。
• 使用正確的符號表示關係（例如，空心菱形表示聚合，三角形表示繼承）。

5.3. 定義清晰的關係

• 明確指定基數（例如，1, 0..*, 1..*）以避免歧義。
• 當存在「整體-部分」關係時，使用聚合或組合，並確保聚合（部分可獨立存在）與組合（部分無法脫離整體而存在）之間的區別清晰明確。