9.3 UML類別圖與類別的基本表示

9.3.1 類別、物件與實例

類別描述一組具有共同特徵、責任與行為的事物；物件則是某個類別的具體實例。例如，「團隊」是類別，「智慧校園隊」是某一個團隊物件。每個物件通常具有可區辨的身分、會隨業務事件改變的狀態，以及在協作中承擔的責任。類別圖（Class Diagram）主要表達類別層級的結構，不列出所有實際物件。

UML通常以矩形表示類別，並可分成三個區域：

1. 類別名稱。
2. 屬性。
3. 操作。

分析層級的領域模型可以只列類別名稱，或加入理解需求所需的重要屬性。物件的責任可先用文字、關聯與使用情境加以說明；若操作尚未獲得需求支持，可以暫時省略，避免把領域模型過早轉成程式設計圖。

9.3.2 類別與屬性的命名

類別名稱應使用具體且能被領域人員理解的名詞，例如「團隊」「報名」及「評審分派」。屬性名稱應清楚表達業務資訊，例如「報名時間」「檔案格式」及「正式送出時間」。如果使用英文，請使用單數。

良好的命名應符合下列原則：

• 採用需求文件已確認的用語。
• 避免同一概念使用多個名稱，以免讀者誤以為它們代表不同事物。
• 避免使用意義過廣的「資料」「項目」或「內容」。
• 不將畫面名稱或資料庫欄位縮寫直接當成領域名稱。
• 需要中英文對照時，應維持全章一致。

舉例來說，Case M01的正式名稱是「專題競賽報名與審查系統」，案例內容應一致使用「專題」，避免以不同名詞指稱同一概念，造成讀者誤以為它們代表不同事物。

9.3.3 屬性與資料型態

屬性描述類別實例需要保存或推導的資訊。UML可用屬性名稱：資料型態表示，例如：

classDiagram
  class Registration {
    RegistrationId: String
    SubmittedAt: DateTime
    Status: RegistrationStatus
  }

classDiagram
  class Registration {
    RegistrationId: String
    SubmittedAt: DateTime
    Status: RegistrationStatus
  }

在這個例子中，Registration類別有三個屬性：RegistrationId、SubmittedAt與Status。RegistrationId的資料型態為字串（String），SubmittedAt的資料型態為日期時間（DateTime），Status則表示目前的報名狀態，其資料型態為RegistrationStatus。屬性名稱採大寫字母開頭，以維持本章類別圖的一致格式。

屬性還可分為：

• 必要屬性： 每個實例都必須具有的資訊。
• 選擇性屬性： 在特定狀況下才有值的資訊。
• 衍生屬性： 可由其他資訊計算而得，例如評分總分。

是否必要、是否唯一及是否可修改，都應由需求或業務規則支持。

9.3.4 屬性或類別的判斷

屬性與類別都是名詞。如何分辨屬性與類別呢？一項資訊若只有簡單值，且不具有自己的關係與生命週期，通常可建為屬性；若它具有多個屬性、獨立識別、狀態變化或與其他概念的關係，則較適合建為類別。

例如，「檔案格式」通常是專題文件的屬性，因為它只是描述文件的一個值，不具有獨立識別、關係或生命週期，因此不需另建類別。相較之下，「指導教師」具有自己的身分，會與團隊建立指導關係，也涉及BR-05的利益衝突判斷，因此適合建為類別。判斷關鍵不在於某個名詞看起來是否重要，而在於系統是否必須獨立識別它、保存它，或描述它與其他概念的關係。

9.3.5 分析類別圖與設計類別圖

本書依建模目的，將類別圖區分為分析類別圖與設計類別圖。兩者可能使用相同的UML符號，但回答的問題與詳細程度不同。

• 分析類別圖著重業務語意。
• 設計類別圖則進一步描述軟體責任、方法、可見性、介面及實作方式。

分析類別圖只需表達業務上的識別需求，不必立即決定技術實作。以Case M01的報名（Registration）為例，分析人員可以確認每筆報名都需要可區別的報名編號（RegistrationId），因為團隊名稱可能重複，不能穩定識別一筆報名。至於資料庫採用何種主鍵、編號如何產生及欄位長度為何，則應留待設計階段決定。這項區分能避免分析模型太早受特定技術限制，也能確保後續設計仍有清楚的業務依據。