【用VS2010動手學UML第 9 回】上手UML用例圖的初級概念

用例圖是元素最少的一款UML圖，全部元素和概念都屬於初級概念，沒有區分中級和高級概念。上一回介紹過參與者（Actor），現在來介紹其他概念。其實，前面我們已經看過橢圓圖示的「用例」了，它包含了一組依序的動作；這組依序的動作中，其實記錄了參與者與系統為了達成某一個特定的目標，兩者彼此傳遞訊息的互動過程。

由於，圖像不容易表達細部的互動過程，所以除了用例圖外，我們才會額外需要文字模式的「用例敘述」（Use Case Narrative），來描述互動細部，下一回我們再來詳細地介紹它。

圖1 用例圖的工具箱

至於，前一回提到的一般化關係，在用例之間也可以使用，如圖1所示。其實，這邊我發現到VS2010/UML有一個小錯誤，請你看到圖2的用例性質表，我已經把「下載教材」用例設定為抽象用例，可是圖1中的用例名稱處，並沒有呈現斜體字，這是有誤的。

圖2 用例的性質表

圖3 抽象用例[StarUML]

請你看到圖3的抽象用例，這是用StarUML繪製出來的用例圖。在UML中，所有抽象元素的表示法都相同，一律採用斜體字標示元素名稱，如同我們前面看過的抽象參與者，或者此處的抽象用例，以後還會有機會看到抽象類別。由於，用例跟參與者同樣繼承類詞，所以用例之間可以有一般化關係，也可以設定抽象用例，如圖4所示。

圖4 用例[UML母模]

再者，原先類詞所具備的實現模版和規格模版，用例同樣繼承下來了，你可以打開用例性質表中的模版欄位確認一下。請你看到圖5的範例，發送電郵用例套用了規格模版，意謂著我們的系統並沒有具體實作「發送電郵」這個用例。先別管用例之間的包含關係（Include），稍後會詳加解釋的。

圖5 規格模版

還記得我們前面怎麼解讀模版的概念嗎？先理解用例，然後進一步在用例概念上頭套上「實現」（realization）和「規格」（specification）的概念即可，如下：

● 實現（realization）：有定義「具體實作」（physical implementation）的物件。套上用例來看，我們可以說《realization》的用例，是指有定義具體實作內容的用例。你一定發現到了，理解套用實現模版的用例，幾乎不用費力，只要把前面《realization》參與者中的「參與者」概念替換成「用例」就能夠立即重用之前所學習到的知識。

● 規格（specification）：其實，規格和實現是相對的，規格是指沒有定義具體實作的物件，因此兩者不能同時套到同一個用例上頭。雖然，VS2010/UML可以讓我們同時勾取這兩個模版，但真正理解兩者的定義後，應該避免在實務上的誤用。

不過，老實說，我不認為實務上需要把參與者或用例搞得這麼複雜，其實簡單使用參與者和用例最原始且基本的概念就足夠了。所以，此處的實現和規格模版概念，稍微認識一下就可以了；除非你的專案真的有需要用到，否則請盡量保持單純的溝通，千萬別忘了，UML是一個溝通的工具。

最後，回過頭看到圖2的用例性質表中，我們還有「主體」（Subject）和「能見度」（Visibility）這兩個性質還沒談，同樣留待下回介紹子系統時才談。結合關係
等我們學到類別圖的相關元素時，你就會知道，「結合關係」（Association）其實是類別之間非常重要的一種關係。

圖6 結合關係

不過，對於用例圖而言，雖然參與者與用例之間的關係，仍採用結合關係，但是它並沒有在用例圖中扮演極為重要或深具價值的角色。請你看到圖6，參與者與用例之間的結合關係，僅僅只是指出課務人員和電郵伺服器這兩個參與者，在系統執行發送上課通知用例期間，將會參與其中。

如果你打開結合關係的性質表來看，就會發現實現和規格這兩個模版又出現了，如圖7所示。喔，老實說，這真是件討厭的事情，因為套上實現模版或規格模版概念的結合關係，實務上也沒什麼機會用到。

圖7 結合關係的性質表

圖8 結合關係[UML母模]

但是，怎麼結合關係也會出現實現模版和規格模版呢？或許聰明的你已經推想到了，這是因為結合關係繼承了類詞，所以才會同時繼承了原先屬於類詞的模版，如圖8所示。

好吧，雖然討厭，但是剛才的現象指出了兩件重要的事情：

1. VS2010確實有遵守UML規格書。

2. 雖然，VS2010和其他許多UML工具都有確實遵守UML規格；但是，UML規格中包含大量的概念，很多時候，會比實務上能夠派得上用場的概念，多很多。

最後，請你打開結合關係性質表中的兩個「角色」（Role）特性，會看到藏在裡頭密密麻麻的小性質，如圖9所示。

圖9 角色的性質表

之所以會有這麼多的性質，其實主要不是用在用例圖的。還記得我在這個次小節一開始曾提到結合關係主要用在類別圖中，也因此這麼多的小性質，其實是用在類別圖的。所以，此處我們只會談到其中的「角色名稱」（Role Name）、「可航性」（Is Navigable）和「個體數目」（Multiplicity），其餘特性我們會留待類別圖的回合中，才會來介紹。

圖10 角色

● 角色名稱（Role Name）：結合關係的端點，稱為「結合端」（Association End），也稱為「角色」（Role），如圖10所示。如果有需要，我們可以設定角色名稱，來讓觀看者更清楚兩個端點是以什麼樣的角色，來參與這個結合關係的。當然，更多時候，我們可能根本也沒注意到這麼小的細節，所以有些UML工具就會自動把結合關係連接的端點元素名稱，拿來當作角色名稱，比如VS2010/UML正是這麼做。

圖11 可航性

● 可航性（Is Navigable）：仔細看到圖9中的可航性，課務人員端設定為「否」（False），而發送上課通知端設定為「真」（True）。再請你看到圖11，有箭頭的結合端代表具有可航性，沒有箭頭則代表不可航。可航性代表著溝通的方向，所以圖11意謂著課務人員可以主動傳送資料或信號與系統進行互動。

圖12 個體數目

● 個體數目（Multiplicity）：還記得我們曾在活動圖中，學習過個體數目的概念嗎？溫故而知新，如果忘了的話，可以回頭翻找關於輸入栓和輸出栓的主題，複習一下。UML個體數目的表示法是「下限..上限」，最小下限是0，最大上限是無限（*）。請你看到圖12，我們可以設定個體數目，指出一個課務人員可以參與多次的發送上課通知用例。

圖13 主動性

雖然，此處介紹了結合關係的角色名稱、可航性和個體數目，但實務上，大概只有可航性比較實用，其餘兩個特性，倒是沒什麼實用價值，所以可以不去更改它們的特性。如圖13的範例，我們可以使用可航性來表達課務人員會主動參與系統執行發送上課通知，而電郵伺服器則是被動地等待系統發送訊息給它。

參與者與用例之間的結合關係，價值不高，但是用例之間的「包含關係」（Include）和「擴充關係」（Extend），可就非常重要了。包含關係
其實，前面我們已經看過包含關係的範例了；包含關係是一條帶箭頭虛線，旁邊標示《include》字眼，如圖14所示，代表發送上課通知用例的流程中，包含了一小段發送電郵的流程。

圖14 包含關係

包含關係很容易理解，只不過就是大流程中的某一段可以共用的流程被切割出來了，方便日後共用。你可以看到圖15的示意圖，本來在發送上課通知用例中，有一段發送電郵的流程，獨立出來之後，我們就在兩個用例之間建立了包含關係。

圖15 示意圖[非UML標準]

怎麼重用「發送電郵」用例呢？還記得在我們的企業規則中，只要是開課日前三周報名並繳付訂金的學員，就可以額外獲得電子書，所以課務人員會發送電子書的下載帳號給符合資格的學員，這時就可以重用發送電郵用例了，如圖16所示。

圖16 共用「發送電郵」用例

圖17 包含關係的性質表

最後，我們打開包含關係的性質表看看有沒有什麼特殊的性質，如圖17所示，看起來VS2010/UML對包含關係的支援不多。不過，這樣也不錯，簡單使用，別把溝通搞複雜了。

擴充關係
除了包含關係外，用例之間還有另一個擴充關係，也是十分重要，而且實用。包含關係指向的用例，是一定會執行，但是如果我們想要重用的用例是條件成立才執行，這時就可以改用擴充關係了。

請看到圖18的範例，意謂著課務人員在執行發送上課通知時，一定會連帶執行發送電郵用例，但是只有有填寫手機號碼的學員，才會收到上課通知的簡訊。

圖18 包含關係的性質表

擴充關係的圖示和包含關係一樣，都是帶箭頭虛線，只是它旁邊標示的關鍵字是《extend》。不過，要特別注意兩者的箭頭方向，剛好是相反的，在UML初級認證的官方考試中，特別愛用箭頭方向來測驗考生。從關係線的箭頭可以清楚辨識出，擴充關係指出小用例擴充大用例的流程，而包含關係指出大用例包含了小用例的流程。

從UML母模來看，包含關係和擴充關係都是一種具有方向性的關係（DirectedRelationship），所以它們的圖示才會都帶有箭頭，用來指出方向性，如圖19所示。

圖19 包含關係與擴充關係[UML母模]

圖20 擴充關係的性質表

最後，按照慣例，我們還是要打開擴充關係的性質表來查看，如圖20所示。嗯，看起來是沒別的概念了，就跟包含關係一樣，簡單使用就好。