類別圖 (Class Diagram)

簡介

類別圖通常是描述類別的重要屬性(attribute)及操作(operation)，對應到物件導向程式設計就是變數及方法(如圖四)。然而，由於目前還是在系統分析的階段，所以，一個操作未來有可能對應多個方法。一般而言，在系統分析的階段會先根據每個使用個案所需要的資料來定義類別以及類別所需要的屬性。通常找出系統所需要的類別是透過分析使用者故事、使用個案情境說明及活動圖裡的所有名詞，通常那些名詞就是類別的來源(細節請參考Ashrafi & Ashrafi, 2009,pp.260-276)。不管是不是採用物件導向程式設計，類別圖都可以成為產生實體關聯圖(ERD)之前的基礎。當利用類別圖找出所有的資料需求之後，可以轉換為實體關聯圖，再進行正規化的動作。只是當我們不採用物件導向程式設計時，類別裡的操作就不需要了。

通常會在找出類別時，也初步的列出所需要的屬性及操作。屬性及操作的分析往往需要透過動態模型來分析。

類別間的關係

另外，類別圖最主要的是描述類別之間的關係，類別間的關係有：關聯(Association)、聚合(Aggregation)、組成(Composition)、一般化(Generalization) / 特定化(Specialization)。如果兩個類別互相會使用到，那就是構成關聯(如：老師、學生)，如果，一個類別包含另一種類別，那就是Aggregation (如：訂單、產品)，如果，一個類別包含另一種類別，而且當包含的類別物件不存在時，被包含的類別物件也不會存在時，兩個類別的關係就是Composition (細節請參考課本pp.281-282)。所以，Aggregation和Composition)都是特殊的Association，而Composition是一種特殊的Aggregation。

一般化(Generalization)是指將不同類別的共同部份抽取為父類別(super class / parent class)，原本的類別就成為子類別(sub class / child class) ，特定化(Specialization)是將一個類別的特定部份分為不同的子類別。事實上一般化就是由上而下的過程，特定化是由上而下的過程，結果會是一致的。例如，分析師可能會認為系統需要「RegularTrip」及「HolidayTrip」兩個類別，因為計價方式不同，但發現兩種旅程有共同的資料結構，所以，決定新加一個「Trip」的類別(細節請參考Ashrafi & Ashrafi, 2009,pp.283-284)。

另外兩種類別間的關係通常是在設計階段才會出現，一種是實作(Realization)，是當一個類別成為抽象類別(Abstract Class)或介面(Interface)，表示實作這些Abstract Class及Interface的類別與這些Abstract Class及Interface的關係。另一種是依賴(Dependency)，這樣的關係是一個類別在傳遞參數或本地變數時使用到另一個類別，這樣的關係像是Association，但關係卻又沒有這麼緊密。

當系統所使用的類別相當多的時候，通常就隱藏其屬性與操作，並且利用不同的圖示來表達該類別的角色(stereotype)，讓看的人可以很快的了解類別間的關係，這些Stereotype會在設計的部份詳述。

延伸閱讀

• 4.11_Finding Classes
  • 從以下的五項找類別 (6:04)
    • Tangible things
    • Roles
    • Incidents
    • Interactions
    • Specifications
• Fundamental UML Class Diagram
  • 如何使用Astah畫Class diagram (3:01)
• 4.01_Classifiers Classes & Objects (4:18)
• 4.04_Associations & Multiplicity (6:21)
• 4.06_Aggregation & Composition (5:15)
• 4.07_Generalization (2:34)
• 4.08_Realization (4:56)
• 4.09_Dependency (2:35)