【用VS2010動手學UML第21回】上手UML循序圖的初級概念

圖1 循序圖的初級概念
其實，UML循序圖中瑣瑣碎碎的概念不算少，不過你只要稍微瞄一下圖1的循序圖工具箱，就會知道VS2010/UML對循序圖的支援不多。不過，還可以啦，剛剛好夠用，就是了。

存活線
還記得我們在本章的一開始曾說過，循序圖其實結合了用例圖文與類別圖的動靜觀點。所以，存活線主要反映了類別圖的靜態結構，也就是說，存活線依據類別的定義而誕生，依據類別內部的操作而提供服務。當然，類別圖中有這麼多登記在案的類別，我們正可以從用例的角度決定要誕生哪些物件。

因此，在VS2010/UML的循序圖中，我們要新增一個存活線可以有兩種操作方法：

1. 直接選定所屬類別：打開VS2010/UML的「UML模式瀏覽器」（UML Model Explorer），滑鼠左鍵點選之前已經新增過的類別，拖曳至循序圖面空白處，VS2010/UML便會自動幫我們新增一個屬於該類別的物件存活線了，如圖2所示。

圖2 直接選定所屬類別

圖4 設定存活線的型別
2. 新增後再設定所屬類別：如果，你遇到UML模式瀏覽器中的元素密密麻麻一堆的話，另一種方式可以先新增一個未指定所屬類別的存活線，從VS2010/UML循序圖工具箱找到「存活線」（Lifeline），新增到循序圖面上，如圖3所示。接著，才點選新增的存活線，打開它的性質表，設定該存活線的「型別」（Type）為某一個類別，就如圖4所示。

圖3 新增未指定類別的存活線

不過，你要是仔細比較一下上述兩種方式所產生出來的存活線時，會發現兩種不同的圖示，我特別把它們重新並列在圖5中。但是，這兩個小圖其實是有小錯誤的，如下：

圖5 不正確的存活線名稱表示法

圖6 UML1的存活線圖示[StarUML]

● 名稱底下不需要加底線：存活線的名稱採用「物件名稱：類別名稱」的表示法，並且在UML2改成名稱底下沒有底線，有底線的是UML1的舊表示法。例如，在StarUML中的存活線就是UML1的舊表示法，名稱有底線，如圖6所示。

圖7 UML2的存活線圖示[Visual Paradigm]
● 類別名稱前頭要加冒號：再者，大部分時候，我們不會特別幫存活線命名，但是通常一定會指定存活線所屬類別，所以就會出現僅標示出類別名稱的現象。在這種情況下，類別名稱前方的冒號是不能省略的，所以圖5右圖名稱前方應該出現冒號才對，否則看起來會像是存活線的名稱。請你看到圖7的Visual Paradigm範例，這是最正確的UML2的存活線名稱表示法。

● 由於，這是UML改版的問題，所以很多UML工具也都像VS2010/UML一樣混用，有時存活線名稱有底線，有時沒有底線。不過，無傷大雅啦，總之你只要知道在循序圖中有虛線尾巴的矩形是存活線的圖示，就可以了。
圖8 參與者的存活線
對了，如果是參與者的存活線，通常會特別採用參與者原本的人型圖示。不過，VS2010/UML只是在矩形上頭額外加個人型小圖示，如圖8所示。比較常見的做法是像圖9的Visual Paradigm或StarUML的表示法，直接採用參與者的人型圖示，讓觀看者一目了然。

圖9 參與者的存活線[Visual Paradigm/StarUML]

最後，我們打開存活線的性質表來查看一下，如圖10所示。比較特別的欄位是「參與者」（Actor）欄位，可以讓我們設定該存活線所屬的型別是一般的類別還是參與者。一旦，我們將參與者欄位改成「真」（True）時，存活線的矩形上方就會出現代表參與者的人型小圖示了。

圖10 存活線的性質表
同步呼叫與回覆訊息
循序圖內的重要元素主要有兩種：其一是柵欄狀的存活線，另外就是橫跨在存活線上頭的訊息了。UML依照通訊動作（Communication Action）的不同，將訊息分成了六類，不過VS2010/UML只支援其中四款，分別為：

1. 同步呼叫（Synchronous Call）：VS2010/UML有支援。

2. 回覆訊息（Reply Message）：VS2010/UML有支援。但是，開發人員無法自行產生回覆訊息，而是在新增同步呼叫的同時，由VS2010/UML自動產生。

3. 非同步呼叫（Asynchronous Call）：VS2010/UML有支援。

4. 非同步信號（Asynchronous Signal）：VS2010/UML沒有支援。

5. 誕生訊息（Create Message）：VS2010/UML有支援，但是圖示不太標準。

6. 刪除訊息（Delete Message）：VS2010/UML沒有支援。

此處，我們會先談到同步呼叫與回覆訊息，在後續文章中，才會依序談到非同步呼叫和誕生訊息。由於，VS2010/UML並未支援同步信號（Asynchronous Signal）和刪除訊息（Delete Message），所以此處我們也就不談論這兩個小主題了。

同步呼叫是最常見的一種訊息。一般，我們在編碼時，所寫的操作（Operation）通常都屬於同步呼叫。它的通訊動作是，發送端會停止動作，直到接收端執行完，返回控制權之後，發送端才會繼續執行下一個動作。仔細看到圖11的訊息箭頭，同步訊息是實心箭頭，由發送端射向接收端。

圖11 同步呼叫

有趣的是，VS2010/UML不允許我們將訊息名稱移到別的地方，只能安安穩穩地貼在箭頭旁。我記得知名的《The Elements of UML 2.0 Style》一書中，第170條指導方針曾提到「訊息名稱貼在箭頭旁」（Justify Message Names Beside the Arrowhead.）最佳，看起來VS2010/UML倒是實作了這條指導方針呢。

再者，我們可以打開訊息的性質表，為這個訊息設定背後所啟動的操作，如圖12所示。

圖12 同步呼叫的性質表

設定完成後，VS2010/UML會自動將訊息名稱放置訊息線段上方，操作名稱放置訊息線段下方，如圖圖13所示。不過，特別提醒你，並列訊息名稱和操作名稱是VS2010/UML特有的貼心功能，並非UML標準表示法。

圖13 訊息與操作

圖14 滑鼠左鍵雙擊長條矩形
另外，如果物件要發送訊息給自己的話，你可以點選VS2010/UML循序圖工具箱中的訊息圖示後，再用滑鼠左鍵雙擊長條矩形，如圖14所示。這時，就會出現一條打折射向自己的訊息線段了，如圖15所示，操作上還挺便利的。

圖15 發送訊息給自己

此外，我們來討論一個跟「能見度」（Visibility）有關的問題。還記得私有等級的操作應該只有物件本身可以使用，其他外界的物件都無法視見，當然也就無法使用了。

這麼說起來的話，以圖15為例，訪客發送訊息給註冊時，應該無法視見並啟動註冊私有等級的操作才對。但是，請你看到圖16的範例，其實VS2010/UML在此處並沒有限制。

圖16 私有操作

圖17 註冊類別[Visual Paradigm]
接著，我們來對比Visual Paradigm的做法，這是比較正確的支援。請看到圖17，註冊類別中有一個公開操作，以及一個私有操作。然後，在圖18的循序圖中，只出現公開等級的操作讓我們挑選，這是非常正確又貼心的做法。

圖18 只能挑選公開操作[Visual Paradigm]

至於，物件發送訊息給自己的話，當然可以呼叫自己的公開操作或者私有操作了。

所以，在圖19的循序圖中，註冊物件發送訊息給自己時，Visual Paradigm同時提供了公開等級和私有等級的操作，供我們挑選。我想此處的支援，是VS2010/UML可以加強的啦！

圖19 可以挑選公開操作或私有操作[Visual Paradigm]

最後，我們來談「回覆訊息」（Reply Message），它的圖示為反向的虛線箭頭，特別注意它的箭頭是開放性箭頭，而不是實心箭頭喔，如圖20所示。

圖20 回覆訊息

回覆訊息有幾個特色，我們簡單條列如下：

● 帶開放性箭頭的虛線線段，而且是反向指回發送端，記得它是指回發送端，而不是其他的存活線。

● 通常伴隨著同步呼叫成對出現，但不會伴隨著「非同步訊息」（Asynchronous Message）出現。雖然，很多UML工具會因為淨化版面的因素，因而在繪製同步呼叫的同時，省略了回覆訊息，但不意味著回覆訊息不存在。

● 回覆訊息上頭可以標示「回傳值」（Return Value），但不需要標示<>字眼，如圖21所示。在UML的標準表示法中，回覆訊息並沒有標示<>字眼，也不需要標示。看起來，<>字眼似乎是VS2010/UML自己額外的標示。

圖21 回傳值

別忘了打開回覆訊息的性質表查看一下，如圖22所示，看起來沒有其他特別的小性質需要認識了。不過，你可以稍微看一下「訊息性質」（Message Sort）的欄位，這個反白欄位標示了「回覆」（Reply），代表這是回覆訊息。你要是回頭去看同步呼叫性質表的訊息性質，會是標示「同步呼叫」（SynchCall）。

圖22 回覆訊息的性質表
非同步呼叫
除了同步呼叫外，其實「非同步呼叫」（Asynchronous Call）也很實用，譬如網站應用程式（Web Application）的設計之中，有很多時候，發送給伺服端的訊息很多都是非同步呼叫。

簡單來說，發送端發出非同步呼叫時，並不需要等待接收端反向發出回覆訊息，便可以繼續往下發送其他訊息。因此，相較於同步呼叫總是伴隨著回覆訊息，此處的非同步呼叫卻總是單獨出現，不會有成對出現的回覆訊息。

所以，你要仔細看到VS2010/UML的循序圖工具箱中的小圖示，可以發現同步呼叫的小圖示是成對的訊息線，但是非同步呼叫的小圖示卻是單一個訊息線，正因如此，如圖23所示。

圖23 回傳值

當然，非同步呼叫除了沒有伴隨的回覆訊息外，它本身的訊息箭頭也長得不一樣，它是開放性的箭頭，不同於同步呼叫的實心箭頭，如圖24所示。

圖24 非同步呼叫

接著，我們打開非同步呼叫的性質表來查看，除了訊息性質欄位標示為「非同步呼叫」（AsynchCall）以外，性質表上其餘的欄位都和同步呼叫相同，如圖25所示。

圖25 非同步呼叫的性質表

不過，這裡有個有趣的地方，請你仔細看到圖25的非同步呼叫性質表中，它的性質欄位上方有一個「訊息種類」（Message Kind）欄位，標示為「完整」（Complete）。這個欄位同樣是反白欄位，代表看得到卻無法修改。

我來解釋一下，在UML標準中，依據訊息的發送端與接收端的存在與否，將訊息分為四種，分別為：

● 完整訊息（Complete Message）：完整的訊息應該是有發送端，同時也有接收端的，像前面提到的同步呼叫和回覆訊息，以及此處的非同步呼叫多半都是完整訊息，所以你要是回頭查看一下這三種訊息的性質表，會發現它們的訊息種類都是「完整」（Complete）。

圖26 拖曳至空白處
● 漏失訊息（Lost Message）：該訊息有發送端，但是沒有接收端，也就是說，不知道這訊息該由哪個物件來接收。在VS2010/UML的循序圖中，怎麼產生「漏失訊息」呢？這有點像是發現隱藏版的功能一樣有趣。

首先，請你先點選非同步呼叫，然後滑鼠左鍵再點選訪客存活線，拖曳至圖面的空白處，代表這條訊息線沒有接收端，如圖26所示。

接著，循序圖面上就會出現一條非同步呼叫的開放性箭頭線，但是在箭頭端點多了一個實心小圓，代表缺少接收端，這就是漏失訊息的圖示了，如圖27所示。

圖27 漏失訊息

怎麼能夠確定這個就是漏失訊息了，點選該訊息線打開它的性質表，如圖28所示，這不就看到它的種類欄位上頭，標示為「漏失」（Lost）。

圖28 漏失訊息的性質表

圖29 由空白處開始拖曳
● 發現訊息（Found Message）：如果反過來，缺少發送端，但是有接收端的話，這類的訊息則稱為「發現訊息」（Found Message）。聰明的你一定猜想到在VS2010/UML怎麼產生發現訊息了吧！一樣點選非同步呼叫，這次是先用滑鼠左鍵點選圖面的空白處，然後拖曳至註冊網頁存活線，就如圖29所示。

發現訊息的圖示剛好跟前述的漏失訊息相反，它的實心小圓擺在非箭頭端，代表沒有發送端，如圖30所示。

圖30 發現訊息

最後，同樣點選發現訊息打開它的性質表查看一下，證實這是一個發現訊息，如圖31所示。

圖31 發現訊息的性質表

● 未知訊息（Unknown Message）：缺少發送端，也缺少接收端，這種訊息稱為「未知訊息」（Unknown Message）。很怪的訊息吧，難以想像，所以在UML規格書中，自己便記載著「應該不會出現」（should not appear）這種訊息，當然VS2010/UML也不知道該怎麼支援吧。

誕生訊息
圖32 誕生訊息[Visual Paradigm]
VS2010/UML支援的最後一種訊息，稱為「誕生訊息」（Create Message）。顧名思義，誕生訊息用來誕生別的存活線，它的圖示是一條帶開放性箭頭的虛線，指向新誕生下來的存活線頂端的矩形。我們先來看另一套UML工具Visual Paradigm的範例，如圖32所示。

然後，我們在回過頭來看VS2010/UML如何表現誕生訊息，如圖33所示。VS2010/UML的誕生訊息有兩個特別的地方：首先是開放性箭頭沒有指向存活線頂端的矩形，另外則是又自動出現了回覆訊息。

圖33 誕生訊息

其實，在UML規格書中，僅提到誕生訊息的圖示是帶開放性箭頭的虛線（Object creation Message has a dashed line with an open arrow.）。文字中並沒有說明箭頭必須指向存活線頂端的矩形，像Visual Paradigm，也沒有說必須帶<>字眼，而且需要伴隨著回覆訊息出現，像VS2010/UML。

但是，在UML規格書中，卻出現了一個範例，其中的誕生訊息是指向存活線頂端的矩形，而且並未伴隨著回覆訊息，如圖34所示。

圖34 誕生訊息[UML規格書]

我特別擷取了在圖34中跟誕生訊息有關的局部，放在圖35中。你可以從圖35的局部放大中，很明確地看到誕生訊息的圖示，可能得像Visual Paradigm所展示的，會比較符合UML規格書的期待。

圖35 局部放大[UML規格書]

最後，我們打開誕生訊息的性質表來查看一下，特別看到它的性質欄位標示著「誕生訊息」（Create Message），其餘就沒什麼特別之處了，跟前頭看到的訊息性質表大同小異。