【動手學UML第 8 回】所有UML使用者都必須學會用例圖

前面幾回所介紹的活動圖，可以讓開發團隊大致理解了企業流程的運作；接下來，我們要進一步透過UML的「用例圖」（Use Case Diagram）來捕捉並釐清需求。

用例圖可以表達系統對外提供的服務或功能，也是開發人員用來和使用者溝通的最主要圖款。但是，只透過用例圖的圖形化表達，是不足夠的，還有許多繁瑣的需求細節需要透過一般的文字，細膩地記錄下來才行。

因此，在實務上，除了用例圖，我們還會產出文字格式的「用例敘述」（Use Case Narrative）。所以說，用例圖與用例敘述，圖文相依，缺一不可。

不過，由於用例敘述不是UML標準的一部分，因此並沒有標準的用例敘述格式可以使用。至於VS2010/UML，也理所當然地，並沒有提供任何的用例敘述格式了。

所以，我只會在稍後內容中簡單說明用例敘述，但不深入討論。你要是對用例敘述有興趣深入，可以參考《寫給SA的UML/UseCase實務手冊》一書，該書花了許多篇幅細談用例圖與用例敘述。

VS2010中的用例圖
用例圖是元素最少的一款UML圖，所以並沒有區分中級和高級概念，它的全部元素和概念都屬於初級概念。因此我們可以推論，UML官方的專家學者認為用例圖屬於入門且常用圖款，所有的UML學習者都必須學習用例圖。

圖1 用例圖的工具箱

不過，請你看到圖1的VS2010/UML用例圖工具箱，很有趣的是，我標示了一個中級概念「產出物」（Artifact）。其實，產出物不只是中級概念，而且它還是「部署圖」（Deployment Diagram）內的元素，它並不是用例圖的元素。

先簡單說明一下「產出物」，它代表一種實際存在的實體資訊片段，其內記錄著重要的規格，通常使用於或產出於軟體開發過程中，或者是部署或操作系統時需要使用到或產出的實體產出物。
最常見的產出物，像是：

● UML模式的電子檔（model files）

● 原始程式碼的電子檔（source files）

● 批次執行的腳本檔（scripts）

● 二進元的可執行檔（binary excutable files）

● 資料庫中的資料表（table）

● 開發過程中產出的可交付物

● word文件的電子檔

● 電子郵件

在初步認識產出物後，我們可以合理的推想，VS2010/UML特別將「產出物」放到用例圖的工具箱中，是為了方便我們連結某一個用例與它的敘述文件檔（用例敘述），或者是根據用例所產出的其他細部設計圖。

接下來，我們先回過頭來看用例圖中的初級概念，談完初級概念之後，我們才來繼續討論產出物和用例敘述的概念。

用例圖初級概念：參與者
由於，用例圖主要用來表達系統對外提供的功能或服務，所以在用例圖中會出現位於系統外部的物件，這些系統外部的物件會跟系統互動，以便獲取期望的產出。

因此，我們會用「參與者」（Actor）來代表位於系統外部的物件，它會跟系統交換資料或信號（signal）。常見的參與者有下列三種：

● 角色（role）：一般會直接使用系統的人類使用者，但參與者指得不是某一個實體的人，而是指人所扮演的角色。

● 實體（entity）：像是其他的連線系統、主機、外部資料庫、硬體設備。

● 服務（service）：近年來新興的虛擬參與者，像是網路服務（Web Service）或是雲端服務（Cloud Service）。

其實，UML預設的參與者圖示，只是個簡單的樹枝狀人型圖示，不像VS2010/UML設計的人像圖示。請你比較圖2的VS2010/UML的參與者圖示，和圖3的StarUML參與者圖示，StarUML中的樹枝狀人型圖示才是UML真正預設的圖示。

圖2 VS2010的參與者

圖3 參與者[StarUML]

在用例圖的定位上，我們會希望可以拿用例圖來跟使用者溝通需求，所以如果能夠用更多樣且豐富的圖像來代表參與者，可以讓溝通更活潑有趣，也更貼近使用者。在這個圖示的擴充性上頭，UML是允許開發人員自行設計專屬的圖示的。

那麼，我們可不可以在VS2010/UML中直接使用自訂的參與者圖示呢？想像一下，假設我們開發一套財務系統，主要的參與者有財務專員和部門主管，那我們乾脆拿某一位人氣最高的財務專員以及該部門主管的大頭照來當參與者圖示，這樣的溝通一定會更直接有力。

這個自訂參與者圖示的功能，其實很簡單，但是貼心又有趣，VS2010/UML輕易就可以做到了。請你打開參與者的性質表，如圖4所示，在「圖片路徑」（Image Path）處選定你自訂的參與者圖示。

圖4 設定圖片路徑

最後，我們再回過頭來看圖4的參與者性質表中，有一個是否為「抽象」（Is Abstract）參與者的設定，這個性質要配合「一般化關係」（Generalization）來談，比較有意義，所以我們稍後再來討論。

再者，參與者性質表中的「能見度」（Visibility）欄位，也不適合單獨談論，配合「子系統」（Subsystem）元素來談，會更容易理解，所以我們也暫時把這個概念挪後討論。模版
圖5 模版

接著，你可以試著點開參與者性質表中的「模版」（Stereotype）欄位，VS2010預設了兩種模版可以選擇。假設，我們勾選了「實現」（realization），如圖5所示。這時你會發現，用例圖面上的參與者名稱上方多了一排放在雙角括號中的模版名稱，如圖6所示。

圖6 模版名稱放置在雙角括號中

之前，我們在談活動圖的元素時，也曾多次打開性質表來看，或許你當時就已經注意到，每個元素的性質表中都有模版一欄。當時，我們都沒解釋，那是因為VS2010/UML活動圖並沒有提供任何模版讓我們使用，所以我也就沒有特別解釋模版的概念了。既然，現在遇到了模版，那我們就趁機來學習一下模版的概念。

模版是UML的擴充機制，開發人員可以用它來增加額外的意涵。UML本身也預設了一組數十個的模版，我們在參與者性質表中看到的「實現」（realization）和「規格」（specification）正是UML預設的模版。

模版並不難懂，我們只要先找出模版套用在哪個UML元素上頭，先理解原始的UML元素概念，然後再額外增添上模版的概念。遇到雙角括號的模版時，只要簡單拆成兩個概念來看，馬上就能夠理解了。更棒的是，我們也可以自訂模版，無須等待UML本身的改版，我們立即就可以產出一個套用自訂模版的UML方言。

也就是說，面對參與者的這兩項模版，我們在理解參與者之後，只要進一步在參與者概念上頭套上「實現」（realization）和「規格」（specification）的概念即可，如下：

● 實現（realization）：
有定義「具體實作」（physical implementation）的物件。套上參與者來看，我們可以說《realization》的參與者，是指有定義具體實作內容的參與者。

還記得前面我們提到，常見的參與者有角色、實體、服務這三類，因此我們可以推論《realization》參與者比較適用在實體類的參與者，提供具體實作的實體類參與者，就可以套上《realization》模版。

● 規格（specification）:
其實，規格和實現是相對的，規格是指沒有定義具體實作的物件，因此兩者不能同時套到同一個參與者上頭。

雖然，VS2010/UML可以讓我們同時勾取這兩個模版，但真正理解兩者的定義後，應該避免在實務上的誤用。同樣的，我們也可以進一步推論，並未提供具體實作的服務類參與者，應該比較適合套上《specification》模版。

有趣的是，如果你好奇翻出UML規格書來看看的話，你或許會發現UML規格書中的實現和規格模版，套用在「類詞」（Classifier）上頭，而不是套用在參與者上頭。

怎麼會這樣呢？其實，那是因為類詞是參與者的父類別，所以參與者可以繼承類詞的特性，因此繼承了類詞的實現和規格模版。

至於，「類詞」（Classifier）到底是什麼？簡單來說，它代表了某一群具備相同特性的個體（instance），比方說我們常提到的「類別」，其實就是類詞的一種，當然此處的參與者或者後續的用例，也都是類詞的一種。一般化關係
如果，我們再把範圍放大些，就可以看到參與者之間之所以可以有「一般化關係」（Generalization），其實同樣是繼承自類詞，如圖7所示。

圖7 一般化關係[UML母模]

圖8 參與者之間的一般化關係

雖然，我們現在才要正式來談「一般化關係」，但其實前面我們已經在UML母模中看到很多次了。一般化關係是一種分類關係，它的圖示是帶空心三角形的實線，三角形端標示出一般化的類詞，而另一實線端則標示出特殊化的類詞。如果套上參與者來看的話，三角形端放置一般化的參與者，而實線端則放置特殊化的參與者，如圖8所示。

一般化關係之所以好用，原因在於特殊化的參與者可以繼承一般化參與者的特性。也就是說，一般化參與者可以參與的用例，特殊化參與者都可以透過一般化關係繼承下來。

圖9 訪客與學員

請你看到圖9的範例，我們並沒有特別標示出學員跟「查看課程細節」用例之間的關係，但是透過一般化關係的繼承機制，學員其實是可以查看課程細節的。但是，反向卻是不成立的，也就是說，訪客不能下載上課用的教材簡報，只有具備學員身分的使用者才能夠下載簡報檔。

還記得前頭的參與者性質表中，有一個是否為「抽象」（Is Abstract）參與者的設定，這個特性其實繼承自類詞，我在圖7中有特別標示出來。抽象參與者意謂著它只是個概念性的角色、實體或服務，並沒有實際存在的使用者、連線系統或網路服務。

圖10 抽象參與者

請你看到圖10的例子，假設簡報檔並不是放在我們自己的系統中，而是放在外部的網路空間，所以我們可以新增一個名為「網路空間」的參與者。再者，網路空間其實只是個概念，因為我們還不知道實際上會放在哪裡的網路空間中，所以我們把它標示成抽象參與者。

抽象參與者的圖示跟普通的參與者一樣，只有在名稱的地方不同，有沒有注意到，抽象參與者的名稱是斜體字。回過頭來看參與者的性質表，你可以發現在圖11中的抽象欄位已經被改成「真」（True）了。

圖11 抽象性質

如果，只是拿抽象參與者來代表一個抽象概念，這樣還展現不出它的價值。其實，我們可以搭配一般化關係，把抽象參與者當作是一個共同的介面（Interface），並且透過一般化關係的繼承機制來抽換實際的參與者。

延續剛才的範例，我們可以新增兩個特殊化的參與者，分別為：免費網路硬碟和雲端儲存空間，意謂著我們的系統真正上線時，簡報檔是放在某一個免費網路硬碟，或者某一個雲端儲存空間，如圖12所示。

圖12 免費網路硬碟與雲端儲存空間

但是，無論我們的簡報檔是放在哪個外部系統中，我們的系統都不需要改寫程式，因為我們統一使用「網路空間」這個一般化的參與者做為共通介面。如此一來，抽象化的機制再配合上一般化關係的繼承機制，便可以為我們的系統帶來抽換的彈性了。