【用VS2010動手學UML第14回】快速上手UML類別圖的初級概念：類別（二）

在類別圖中，一個類別（Class）代表一群相同的物件（Object），這群物件在四種特性上具有同質性，包括語意、屬性、操作和關係，上一回介紹過類別的語意定義和屬性，這一回則要介紹類別的操作（operation）特性。

圖1 操作

通常，真實事物的靜態資料會抽象成類別中的屬性，而它們的行為則會抽象成類別中的操作。所以，屬性和操作是類別最重要的兩個組成元素。前頭我們談過了屬性，接下來繼續來看圖1的操作吧，操作的格式跟程式語言中的寫法幾乎一樣。

操作的性質表很大一張，我們先來看一般區（Common）的設定，請你順便把「回傳型別」（Return Type）欄位打開，如圖2所示。一般性質中的靜態操作、能見度這兩個概念，前面我們已經學過了，就不再說明了。

圖2 操作的一般性質

由於，只能有一個回傳參數，所以我們可以直接在操作性質表中設定回傳型別相關的設定。回傳參數裡頭的排序、唯一、個體數目的概念，我們在屬性處都談過了，就不重複說明了。

至於，參數的性質其實跟回傳參數的性質幾乎一樣，只是因為不方便同時列出多個輸入參數，才會需要再打開一層的參數設定，如圖3所示。除了輸入參數可以設定「預設值」（Default Value），以及多了一個參數「方向」（Direction）外，其餘的資料型別（Type）和多值（Multi-Value）設定都跟回傳參數相同。

圖3 參數的性質表

圖4 參數方向

你要是順手打開參數方向欄位，會發現VS2010/UML預設了三個參數方向，供我們挑選，選項有：輸入（in）、輸入輸出（inout）、輸出（out），如圖4所示。

不過，在UML母模中，參數方向其實有四種：輸入（in）、輸入輸出（inout）、輸出（out）和回傳（return），如圖5所示。這也是為什麼回傳參數和輸入參數的性質幾乎一樣，那是因為對於UML而言，它們都是參數，只不過方向不同罷了。

圖5 參數方向[UML母模]

● 輸入（in）：由呼叫端（caller）傳給操作的參數。

● 輸入輸出（inout）：先由呼叫端傳給操作，然後，操作再還給呼叫端的參數。

● 輸出（out）：由操作傳出給呼叫端的參數。

● 回傳（return）：操作執行結束的回傳給呼叫端的參數。

圖6 操作的行為性質

接著，我們來看操作的行為性質設定，如圖6所示。針對操作本身，我們可以設定三種限制條件，如下：

● 主體條件（Body Conditions）：操作的產出值必須滿足主體條件。

● 後置條件（Postconditions）：操作執行完畢後，系統狀態必須滿足後置條件。

● 前置條件（Preconditions）：當操作被呼叫之際，系統狀態必須滿足前置條件。

特別注意到，主體條件最多只能設置一個，不過後置條件和前置條件都可以設置數個，如圖7所示。

圖7 限制條件[UML母模]

圖8 操作的雜項性質

在圖7的UML母模中，操作還有一個「可否查詢」（isQuery）用來標示該操作執行後，是否會改變系統狀態。可否查詢的預設值是「否」（false），意謂著操作執行後，可能會改變系統狀態。這項設定放置在操作性質表的雜項區，如圖8所示。

操作性質表的雜項區中，還收錄著操作模版，我們打開來看，一共有兩個操作模版，分別為：

● 創建（create）：創建操作用來產生個體（instance）。

● 消滅（destroy）：消滅操作用來刪除個體（instance）。

其實，創建和消滅模版本來是「行為特徵」（BehavioralFeature）的模版，在UML規格書中都定義的很清楚，如圖9所示。

圖9 創建與消滅模版[UML規格書]

看大圖

操作之所以也可以擁有這兩個模版，純粹是因為操作繼承了行為特徵，如圖10所示，所以才一併繼承了創建和消滅模版。

圖10 操作[UML母模]

最後，我們剩下操作的同步（Concurrency）性質還沒看，如圖11所示。UML預設了操作有三種同步種類，分別為：

● 依序（Sequential）：沒有同步管理的機制，這是預設值。

● 監視（Guarded）：操作可以被同時呼叫多次，但只有某一次呼叫會被允許開始，其餘呼叫會被鎖住，直到此次呼叫執行完畢，才會解開執行下一個呼叫。

● 同步（Concurrency）：同一個操作可以被同時呼叫多次，而全部的呼叫可以同步執行，如圖11所示。

圖11 同步

前一回介紹類別時，我們介紹過公用類別（utility class）和抽象類別（abstract classs）。一般人對抽象類別最主要的印象，多半是抽象類別不能誕生個體（instance）。其實，雖然公用類別不是抽象類別，但是它跟抽象類別一樣，是沒有個體的。抽象類別的類別名稱是斜體字，公用類別則是在類別名稱上方標示了《utility》字眼。

抽象類別「不能夠」誕生個體，通常是因為有不完整，像是擁有缺乏完整的實作或規格之類的抽象操作（abstract operation），所以不能夠誕生個體。但是，公用類別是「不需要」誕生個體，因為它的屬性和操作都是靜態的（static），不需要誕生個體，直接呼叫公用類別，便可以使用它的靜態屬性和操作。抽象操作的也是使用斜體字，公用類別則是擁有靜態屬性和靜態操作，以底線標示出靜態。

在使用上，抽象類別通常會搭配一般化關係一塊出現，並且由底下的子類別來實作抽象操作。但是，公用類別通常會獨立存在，其他類別不需要跟公用類別建立特別的關係，就可以直接使用它。

但是，公用類別也可以同時具有抽象特性。一旦公用類別擁有了抽象操作之後，它其實也就同時是個抽象的公用類別，需要透過一般化關係來讓它的子類別實作抽象操作，如此一來其他類別才能夠使用公用子類別。列舉型別
在實務上，列舉型別（enumeration）十分常見並且實用，它是一種特殊的資料型別，可以讓開發人員自行定義數個列舉值（enumeration literals），做為一種自訂的資料型別。

圖12 列舉型別

請你看到圖12的範例，我定義了一個名稱為「身分別」的列舉型別，裡頭的列舉值有新生和舊生兩個。然後，在學員類別的身分屬性中，我就可以挑選身分別列舉型別做為這個屬性的資料型別。

通常，列舉型別裡頭只會放置列舉值，鮮少出現屬性和操作，因此你可以仔細看到VS2010/UML類別圖工具箱中，列舉型別的小圖示是一個比較扁平的矩形，正因如此，如圖13所示。

圖13 列舉型別的扁平矩形

雖然，在VS2010/UML的列舉型別中，不能新增屬性和操作，只能新增列舉值。但是，在UML規格書中，列舉型別其實是可以擁有屬性和操作的，而且在矩形圖示中，會依序出現列舉型別名稱、屬性、操作，最後一格才是放列舉值。只不過因為大部分的列舉型別都沒有設置屬性和操作，所以在圖示上會將屬性和操作格子隱藏起來，僅列出名稱和列舉值。

如何證明這一點呢？我們可以看到UML母模中，列舉型別繼承了資料型別（DataType），所以一併繼承了原先資料型別與屬性和操作的結合關係，如圖14所示。

圖14 列舉型別[UML母模]

圖15 列舉型別[Visual Paradigm]

再者，我們也可以打開另一套UML工具：Visual Paradigm來看，我們可以看到Visual Paradigm可以讓我們為列舉型別新增屬性和操作，如圖15所示。

最後，我們打開列舉型別的性質表來看看，如圖16所示。樣版的概念我們留待中高級概念小節才談。至於，列舉型別的實現模版和規格模版，你可否感到十分眼熟呢？

圖16 列舉型別[Visual Paradigm]

啊哈，想起來了嗎？這兩個模版其實是類詞（Classifier）的模版，由於列舉型別繼承了類詞，所以才會一併繼承了這兩個模版，你可以參考前面的圖14。這兩個模版我們前面已經談過了，沒有其他新鮮之處，所以此處我們就不再老調重彈了。

註解
在UML中，「註解」（Comment）算是一個共用性的元素，用途很簡單，就是拿來記錄一些備註說明文字，而且可以出現在任何UML圖款中，而且任何其他的UML元素都可以擁有註解。其實，我們在活動圖章節中稍微介紹過註解，不過當時沒有正式地看它在UML母模中的位置，所以現在來補看一下，如圖17所示。

圖17 註解[UML母模]

在使用註解時，我們可以將文字放置於註解圖示內部，並且使用連接線連接註解與元素。之前我們也提過了，VS2010/UML此處的連接線圖示有誤，應該為單純的虛線，端點不需要出現小圓，如圖18所示。

圖18 連接線為虛線

最後，我們打開註解的性質表來看，如圖19所示，發現一個很奇怪的性質：透明（Transparent）。我搜尋了整份UML規格書，沒有搜尋到這個字眼，在其他的UML工具中也沒見到，所以推測這個性質應該是VS2010/UML獨有的，如果選了透明的選項，註解的圖示就會變成透明的，如圖20所示。

圖19 註解的性質表

圖20 註解圖示變透明了

不過，把註解圖示變透明，有點怪，因為這樣就無法得知它是註解文字了。請看到圖21的UML規格書中有提到，可以把註解的連接虛線隱藏起來，所以或許我們可以善用透明這個性質，把虛線隱藏起來，降低圖面的複雜度，如圖22所示。

圖21 註解的表示法[UML規格書]

看大圖

圖22 虛線隱藏起來了