類

類的 UML 表示是一個長方形，垂直地分為三個區，如圖 1 所示。頂部區域顯示類的名字。中間的區域列出類的屬性。底部的區域列出類的操作。當在一個類圖上畫一個類元素時，你必須要有頂端的區域，下面的二個區域是可選擇的（當圖描述僅僅用於顯示分類器間關係的高層細節時，下面的兩個區域是不必要的）。圖 1 顯示一個航線班機如何作為 UML 類建模。正如我們所能見到的，名字是 Flight，我們可以在中間區域看到Flight類的3個屬性：flightNumber，departureTime 和 flightDuration。在底部區域中我們可以看到Flight類有兩個操作：delayFlight 和 getArrivalTime。

圖 1: Flight類的類圖

繼承

在面向物件的設計中一個非常重要的概念，繼承，指的是一個類（子類）繼承另外的一個類（超類）的同一功能，並增加它自己的新功能（一個非技術性的比喻，想象我繼承了我母親的一般的音樂能力，但是在我的家裡，我是唯一一個玩電吉他的人）的能力。為了在一個類圖上建模繼承，從子類（要繼承行為的類）拉出一條閉合的，單鍵頭（或三角形）的實線指向超類。考慮銀行賬戶的型別：圖 4 顯示 CheckingAccount 和 SavingsAccount 類如何從 BankAccount 類繼承而來。

圖 4: 繼承通過指向超類的一條閉合的，單箭頭的實線表示。

在圖 4 中，繼承關係由每個超類的單獨的線畫出，這是在IBM Rational Rose和IBM Rational XDE中使用的方法。然而，有一種稱為 樹標記的備選方法可以畫出繼承關係。當存在兩個或更多子類時，如圖 4 中所示，除了繼承線象樹枝一樣混在一起外，你可以使用樹形記號。圖 5 是重繪的與圖 4 一樣的繼承，但是這次使用了樹形記號。

圖 5: 一個使用樹形記號的繼承例項

在圖 4 中，繼承關係由每個超類的單獨的線畫出，這是在IBM Rational Rose和IBM Rational XDE中使用的方法。然而，有一種稱為 樹標記的備選方法可以畫出繼承關係。當存在兩個或更多子類時，如圖 4 中所示，除了繼承線象樹枝一樣混在一起外，你可以使用樹形記號。圖 5 是重繪的與圖 4 一樣的繼承，但是這次使用了樹形記號。

圖 5: 一個使用樹形記號的繼承例項

抽象類及操作
細心的讀者會注意到，在圖 4 和 圖5 中的圖中,類名BankAccount和withdrawal操作使用斜體。這表示，BankAccount 類是一個抽象類，而withdrawal方法是抽象的操作。換句話說，BankAccount 類使用withdrawal規定抽象操作，並且CheckingAccount 和 SavingsAccount 兩個子類都分別地執行它們各自版本的操作。

然而，超類（父類）不一定要是抽象類。標準類作為超類是正常的。

雙向（標準）的關聯
關聯是兩個類間的聯接。關聯總是被假定是雙向的；這意味著，兩個類彼此知道它們間的聯絡，除非你限定一些其它型別的關聯。回顧一下Flight 的例子，圖 6 顯示了在Flight類和Plane類之間的一個標準型別的關聯。

圖 6：在一個Flight類和Plane類之間的雙向關聯的例項

一個雙向關聯用兩個類間的實線表示。線上的任一端，你放置一個角色名和多重值。圖 6 顯示Flight與一個特定的Plane相關聯，而且Flight類知道這個關聯。因為角色名以Plane類表示，所以Plane承擔關聯中的“assignedPlane”角色。緊接於Plane類後面的多重值描述0...1表示，當一個Flight實體存在時，可以有一個或沒有Plane與之關聯（也就是，Plane可能還沒有被分配）。圖 6 也顯示Plane知道它與Flight類的關聯。在這個關聯中，Flight承擔“assignedFlights”角色；圖 6 的圖告訴我們，Plane實體可以不與flight關聯（例如，它是一架全新的飛機）或與沒有上限的flight（例如，一架已經服役5年的飛機）關聯。

由於對那些在關聯尾部可能出現的多重值描述感到疑惑，下面的表3列出了一些多重值及它們含義的例子。

表 3: 多重值和它們的表示

單向關聯

在一個單向關聯中，兩個類是相關的，但是隻有一個類知道這種聯絡的存在。圖 7 顯示單向關聯的透支財務報告的一個例項。

圖 7: 單向關聯一個例項：OverdrawnAccountsReport 類 BankAccount 類，而 BankAccount 類則對關聯一無所知。

一個單向的關聯，表示為一條帶有指向已知類的開放箭頭（不關閉的箭頭或三角形，用於標誌繼承）的實線。如同標準關聯，單向關聯包括一個角色名和一個多重值描述，但是與標準的雙向關聯不同的時，單向關聯只包含已知類的角色名和多重值描述。在圖 7 中的例子中，OverdrawnAccountsReport 知道 BankAccount 類，而且知道 BankAccount 類扮演“overdrawnAccounts”的角色。然而，和標準關聯不同，BankAccount 類並不知道它與 OverdrawnAccountsReport 相關聯。2

軟體包
不可避免，如果你正在為一個大的系統或大的業務領域建模，在你的模型中將會有許多不同的分類器。管理所有的類將是一件令人生畏的任務；所以，UML 提供一個稱為 軟體包的組織元素。軟體包使建模者能夠組織模型分類器到名字空間中，這有些象檔案系統中的資料夾。把一個系統分為多個軟體包使系統變成容易理解，尤其是在每個軟體包都表現系統的一個特定部分時。3

在圖中存在兩種方法表示軟體包。並沒有規則要求使用哪種標記，除了用你個人的判斷：哪種更便於閱讀你畫的類圖。兩種方法都是由一個較小的長方形（用於定位）巢狀在一個大的長方形中開始的，如圖 8 所示。但是建模者必須決定包的成員如何表示，如下：

• 如果建模者決定在大長方形中顯示軟體包的成員，則所有的那些成員4 需要被放置在長方形裡面。另外，所有軟體包的名字需要放在軟體包的較小長方形之內（如圖 8 的顯示）。
  
• 如果建模者決定在大的長方形之外顯示軟體包成員，則所有將會在圖上顯示的成員都需要被置於長方形之外。為了顯示屬於軟體包的分類器屬於，從每個分類器畫一條線到裡面有加號的圓周，這些圓周粘附在軟體包之上（圖9）。

圖 8：在軟體包的長方形內顯示軟體包成員的軟體包元素例子

圖 9：一個通過連線線表現軟體包成員的軟體包例子

介面
在本文的前面，我建議你以類來考慮分類器。事實上，分類器是一個更為一般的概念，它包括資料型別和介面。

關於何時、以及如何高效地在系統結構圖中使用資料型別和介面的完整討論，不在本文的討論範圍之內。既然這樣，我為什麼要在這裡提及資料型別和介面呢？你可能想在結構圖上模仿這些分類器型別，在這個時候，使用正確的記號來表示，或者至少知道這些分類器型別是重要的。不正確地繪製這些分類器，很有可能將使你的結構圖讀者感到混亂，以後的系統將不能適應需求。

一個類和一個介面不同：一個類可以有它形態的真實例項，然而一個介面必須至少有一個類來實現它。在 UML 2 中，一個介面被認為是類建模元素的特殊化。因此，介面就象類那樣繪製，但是長方形的頂部區域也有文字“interface”，如圖 10 所示5

圖 10：Professor類和Student類實現Person介面的類圖例項

在圖 10 中顯示的圖中，Professor和Student類都實現了Person的介面，但並不從它繼承。我們知道這一點是由於下面兩個原因：1) Person物件作為介面被定義 -- 它在物件的名字區域中有“interface”文字，而且我們看到由於Professor和Student物件根據畫類物件的規則（在它們的名字區域中沒有額外的分類器文字）標示，所以它們是 類物件。 2) 我們知道繼承在這裡沒有被顯示，因為與帶箭頭的線是點線而不是實線。如圖 10 所示，一條帶有閉合的單向箭頭的點 線意味著實現（或實施）；正如我們在圖 4 中所見到的，一條帶有閉合單向箭頭的實線表示繼承。

更多的關聯
在上面，我討論了雙向關聯和單向關聯。現在，我將會介紹剩下的三種類型的關聯。

關聯類
在關聯建模中，存在一些情況下，你需要包括其它類，因為它包含了關於關聯的有價值的資訊。對於這種情況，你會使用 關聯類 來繫結你的基本關聯。關聯類和一般類一樣表示。不同的是，主類和關聯類之間用一條相交的點線連線。圖 11 顯示一個航空工業例項的關聯類。

圖 11：增加關聯類 MileageCredit

在圖 11 中顯示的類圖中，在Flight類和 FrequentFlyer 類之間的關聯，產生了稱為 MileageCredit的關聯類。這意味當Flight類的一個例項關聯到 FrequentFlyer 類的一個例項時，將會產生 MileageCredit 類的一個例項。

聚合
聚合是一種特別型別的關聯，用於描述“總體到區域性”的關係。在基本的聚合關係中， 部分類 的生命週期獨立於 整體類 的生命週期。

舉例來說，我們可以想象，車 是一個整體實體，而 車輪 輪胎是整輛車的一部分。輪胎可以在安置到車時的前幾個星期被製造，並放置於倉庫中。在這個例項中，Wheel類例項清楚地獨立地Car類例項而存在。然而，有些情況下， 部分 類的生命週期並 不 獨立於 整體 類的生命週期 -- 這稱為合成聚合。舉例來說，考慮公司與部門的關係。 公司和部門 都建模成類，在公司存在之前，部門不能存在。這裡Department類的例項依賴於Company類的例項而存在。

讓我們更進一步探討基本聚合和組合聚合。

基本聚合
有聚合關係的關聯指出，某個類是另外某個類的一部分。在一個聚合關係中，子類例項可以比父類存在更長的時間。為了表現一個聚合關係，你畫一條從父類到部分類的實線，並在父類的關聯末端畫一個未填充稜形。圖 12 顯示車和輪胎間的聚合關係的例子。

圖 12: 一個聚合關聯的例子

組合聚合
組合聚合關係是聚合關係的另一種形式，但是子類例項的生命週期依賴於父類例項的生命週期。在圖13中，顯示了Company類和Department類之間的組合關係，注意組合關係如聚合關係一樣繪製，不過這次菱形是被填充的。

圖 13: 一個組合關係的例子

在圖 13 中的關係建模中，一個Company類例項至少總有一個Department類例項。因為關係是組合關係，當Company例項被移除/銷燬時，Department例項也將自動地被移除/銷燬。組合聚合的另一個重要功能是部分類只能與父類的例項相關（舉例來說，我們例子中的Company類）。

反射關聯
現在我們已經討論了所有的關聯型別。就如你可能注意到的，我們的所有例子已經顯示了兩個不同類之間的關係。然而，類也可以使用反射關聯與它本身相關聯。起先，這可能沒有意義，但是記住，類是抽象的。圖 14 顯示一個Employee類如何通過manager / manages角色與它本身相關。當一個類關聯到它本身時，這並不意味著類的例項與它本身相關，而是類的一個例項與類的另一個例項相關。

14：一個反射關聯關係的例項

圖14:描繪的關係說明一個Employee例項可能是另外一個Employee例項的經理。然而，因為“manages”的關係角色有%200..*的多重性描述；一個僱員可能不受任何其他僱員管理。

UML規範並不要求屬性及操作可見性必須顯示在類圖上，但是它要求為每個屬性及操作定義可見性。為了在類圖上的顯示可見性，放置可見性標誌於屬性或操作的名字之前。雖然UML指定四種可見性型別，但是實際的程式語言可能增加額外的可見性，或不支援%20UML%20定義的可見性。表4顯示了UML支援的可見性型別的不同標誌。

表4：UML支援的可見性型別的標誌

現在，讓我們看一個類，以說明屬性及操作的可見性型別。在圖 15 中，所有的屬性及操作都是public，除了 updateBalance 操作。updateBalance 操作是protected。

圖 15：一個 BankAccount 類說明它的屬性及操作的可見性

UML 2 補充
既然我們已經覆蓋了基礎和高階主題，我們將覆蓋一些由UML 1. x增加的類圖的新記號。

例項
當一個系統結構建模時，顯示例子類例項有時候是有用的。為了這種結構建模，UML 2 提供 例項規範 元素，它顯示在系統中使用例子（或現實）例項的值得注意的資訊。

例項的記號和類一樣，但是取代頂端區域中僅有的類名，它的名字是經過拼接的:

Instance Name : Class Name

舉例來說：

Donald : Person

因為顯示例項的目的是顯示值得注意的或相關的資訊，沒必要在你的模型中包含整個實體屬性及操作。相反地，僅僅顯示感興趣的屬性及其值是完全恰當的。如圖16所描述。

圖 16：Plane類的一個例項例子（只顯示感興趣的屬性值）

然而，僅僅表現一些例項而沒有它們的關係不太實用；因此，UML 2 也允許在實體層的關係/關聯建模。繪製關聯與一般的類關係的規則一樣，除了在建模關聯時有一個附加的要求。附加的限制是，關聯關係必須與類圖的關係相一致，而且關聯的角色名字也必須與類圖相一致。它的一個例子顯示於圖 17 中。在這個例子中，例項是圖 6 中類圖的例子例項。

圖 17：圖 6 中用例項代替類的例子

圖 17 有Flight類的二個例項，因為類圖指出了在Plane類和Flight類之間的關係是 0或多。因此，我們的例子給出了兩個與NX0337 Plane例項相關的Flight例項。

角色
建模類的例項有時比期望的更為詳細。有時，你可能僅僅想要在一個較多的一般層次做類關係的模型。在這種情況下，你應該使用 角色 記號。角色記號類似於例項記號。為了建立類的角色模型，你畫一個方格，並在內部放置類的角色名及類名，作為實體記號，但是在這情況你不能加下劃線。圖 18 顯示一個由圖 14 中圖描述的僱員類扮演的角色例項。在圖 18 中，我們可以認為，即使僱員類與它本身相關，關係確實是關於僱員之間扮演經理及團隊成員的角色。

圖 18：一個類圖顯示圖14中扮演不同角色的類

注意，你不能在純粹類圖中做類角色的建模，即使圖 18顯示你可以這麼做。為了使用角色記號，你將會需要使用下面討論的內部結構記號。

內部的結構
UML 2 結構圖的更有用的功能之一是新的內部結構記號。它允許你顯示一個類或另外的一個分類器如何在內部構成。這在 UML 1. x 中是不可能的，因為記號限制你只能顯示一個類所擁有的聚合關係。現在，在 UML 2 中，內部的結構記號讓你更清楚地顯示類的各個部分如何保持關係。

讓我們看一個例項。在圖 18 中我們有一個類圖以表現一個Plane類如何由四個引擎和兩個控制軟體物件組成。從這個圖中省略的東西是顯示關於飛機部件如何被裝配的一些資訊。從圖 18 的圖，你無法說明，是每個控制軟體物件控制兩個引擎，還是一個控制軟體物件控制三個引擎，而另一個控制一個引擎。

圖 19: 只顯示物件之間關係的類圖

繪製類的內在結構將會改善這種狀態。開始時，你通過用二個區域畫一個方格。最頂端的區域包含類名字，而較低的區域包含類的內部結構，顯示在它們父類中承擔不同角色的部分類，角色中的每個部分類也關係到其它類。圖 19 顯示了Plane類的內部結構；注意內部結構如何澄清混亂性。

圖 20：Plane類的內部結構例子。

在圖 20 中Plane有兩個 ControlSoftware 物件，而且每個控制二個引擎。在圖左邊上的 ControlSoftware（control1）控制引擎 1 和 2 。在圖右邊的 ControlSoftware（control2）控制引擎 3 和 4 。

結論

至少存在兩個瞭解類圖的重要理由。第一個是它顯示系統分類器的靜態結構；第二個理由是圖為UML描述的其他結構圖提供了基本記號。開發者將會認為類圖是為他們特別建立的；但是其他的團隊成員將發現它們也是有用的。業務分析師可以用類圖，為系統的業務遠景建模。正如我們將會在本系列關於 UML 基礎的文章中見到的，其他的圖 -- 包括活動圖，序列圖和狀態圖——參考類圖中的類建模和文件化。

關於“UML 基礎”的本系列的後面的元件圖。

腳註

1 delayFlight沒有返回值，因為我作出了設計決定，不要返回值。有一點可以爭論的是，延遲操作應該返回新的到達時間，而且，如果是這種情形，操作屬性將顯示為delayFlight(numberOfMinutes : Minutes) : Date。

2可能看起來很奇怪， BankAccount 類不知道 OverdrawnAccountsReport 類。這個建模使報表類可以知道它們報告的業務類，但是業務類不知道它們正在被報告。這解開兩個物件的耦合，並因此使系統變得更能適應變化。

3 軟體包對於組織你的模型類是龐大的，但是記住重要的一點是，你的類圖應該是關於建模系統的容易交流的資訊。在你的軟體包有許多類的情況下，最好使用多個主題類圖，而不是僅僅產生一個大的類圖。

4 要理解重要一點，當我說“所有的那些成員”時，我僅僅意味著在當前圖中的類將顯示出來。顯示一個有內容的軟體包的圖，不需要顯示它的所有內容。它可以依照一些準則，顯示包含元素的子集，這個準則就是並非所有的軟體包分類器都是必需的。

5 當畫一個類圖時，在 UML 規範中，全部要做的只是把類放入長方形的頂部區域，而你同理處理介面；然而，UML 規範認為，在這個區域放置“class”文字是可選的，如果類沒有顯示，那麼它應該被假設