【用VS2010動手學UML第25回】33條UML循序圖的最佳實務

循序圖是UML圖中非常重要的一款圖。下列是我多年來繪製循序圖，自己所累積的9條最佳實務，條列出來與你分享，希望對你有所幫助，條列如下：

1. 循序圖的抽象層級：
這是實務上最困擾的問題，到底循序圖要繪製到多細膩的程度，眾說紛紜。依照UML官方另一個標準MDA（Model-Driven Architecture）的角度，可以依照是否考慮實體平台來切分UML圖的抽象程度。所以，一般我會建議將循序圖簡單分為未考慮實體平台的分析階段的循序圖、考慮程式語言的高階設計階段的循序圖、最後是考慮「應用框架」（Application Framework）的細部設計階段的循序圖。

2. 加入「應用框架」的細部設計圖：
通常，應用框架會有固定的運作模式，所以如果要節省成本的話，應用框架層級的細部設計圖只要繪製個幾張，做為示範案例，就可以了。其實，並不需要一直重複繪製相同的設計，耗費成本。

3. 套用「BCE樣式」（Boundary-Control-Entity Pattern）：
可以快速提升分析設計的品質。BCE樣式是由用例技術創辦人Ivar Jacobson大師所提出來的，許多UML工具都有支援BCE樣式。BCE樣式主要將物件分為主管系統內外界線的「邊界物件」（Boundary Object）、掌控用例流程的「控制物件」（Control Object）、以及負責維護領域概念的「實體物件」（Entity Object）。關於BCE樣式的概念與應用，你要是有興趣的話，可以參考Ivar Jacobson大師的著作。或者，也可以把我出版的《學會UML/OOAD這樣開始就對了》一書找來看看，我在這本書中有應用BCE樣式建構物件導向分析設計模式。

4.一張循序圖展現一個用例的主要流程：
除非替代流程很簡單，否則的話，盡量保持一張循序圖呈現一條主要流程的範圍。這樣一來，不僅好維護，也好管理。

5. 善用「互動引用」（Interaction Use）：
互動引用片段可以放置用例的「子流程」（Subflow），方便其他循序圖共用。還有，替代流程的部分，也可以放在獨立的循序圖中，並且讓主要流程的循序圖來引用這個互動片段，這樣也是一個挺不錯的處理方式。

6. 存活線放置的位置：
最好是從左到右依序放置啟動角色的參與者、系統內部物件、支援性角色的參與者。如果有套用BCE樣式，在系統內部物件的地方還可以依序放置邊界物件、控制物件、實體物件。

7. 訊息由左射向右：
盡量讓訊息方向是由左向右射出，因為英文和橫式中文的閱讀和書寫習慣都是由左向右的方向。

8.一條訊息對應一個操作：
訊息的細膩程度，也是實務上比較困擾的問題。原則上，盡量可以保持一個訊息對應一個操作，方便對應實作。

9.傳物件還是傳資料：
訊息或操作傳遞參數時，如果只是傳遞少數兩三個參數，那就傳遞一般的資料項目即可。但是，如果一次需要傳遞多個參數時，那就可以考慮是不是直接傳遞物件。

24條循序圖最佳指南
學者Scott W. Ambler曾用條列式的指南列出了繪製UML的最佳實務，我們也來看看跟循序圖有關的24條最佳指南，下面將依作者原書中的指南編號逐一列出說明。

第158條指南由左向右依序放置訊息。

第159條指南依層級放置物件存活線。

如果有採用層級（layer）的設計概念的話，可以依層級擺放物件存活線。比方說，經典的三層式架構設計概念，將系統內部物件分為三個層級，分別為：負責使用介面的介面層（UI layer）、管理企業邏輯的企業層（business layer）、維護資料的永續層（persistence layer），所以在擺放物件存活線時，就可以依照介面層、企業層、永續層順序擺放。

或者是我們前面提到的BCE樣式，也是可以按照邊界物件、控制物件、實體物件依序擺放。

第160條指南如果需要的話，參與者與類別可以同名。

由於，參與者代表系統外部、真實世界裡頭的物件，而其餘物件則代表系統內部的軟體物件，所以即便兩者同名，也代表不同的概念。

第161條指南包含邏輯敘述。

在循序圖面上，可以於最左方放置文字敘述，描述整張圖的邏輯控制，便於理解與溝通。在VS2010/UML中，我們可以在循序圖的最左邊放置一個長條狀的註解，就可以在註解裡頭擺放邏輯敘述了。

第162條指南將主動性的系統參與者放置在循序圖的最左側。

第163條指南將被動性的系統參與者放置在循序圖的最右側。

第164條指南避免繪製物件的消滅狀況。

第165條指南避免繪製活動期的長條框。

第164條所謂的消滅狀況，就是存活線底端的大叉叉圖示，代表物件被消滅了、不再存活了。而活動期（Activation）的圖示就是放置在存活線上的長條矩形，代表該物件在接收到訊息之後，會有一段執行期間。不過，活動期是UML1的名稱，到UML2後，活動期就改名成「執行發起」（Execution Occurrence）了。

第166條指南在訊息中有參考使用到某物件時，才為該物件命名。

第167條指南當存在數個相同型別的物件時，才為這些物件命名。

第168條指南在存活線上，一致性地使用文字模版。（Apply Textual Stereotypes to Lifelines Consistently）

第169條指南聚焦於關鍵性的互動上。

通常，我們會希望循序圖可以聚焦企業邏輯上頭，也就是這條指南所建議的關鍵性互動，而不是把所有瑣碎的細節照單全收地表達在循序圖中。這樣一來，不僅可以提高建模的產能，也可以提高模式的可讀性。

第170條指南將訊息名稱放置於訊息箭頭旁。

第171條指南直接建立物件。

UML標準的表示法是誕生訊息直接指向存活線頂端的矩形。不過，VS2010採用間接表示法，比較無法一目瞭然。

第172條指南以操作簽名做為軟體訊息的名稱。

第173條指南涉及人類或組織參與者的訊息，以一般的散文體命名。

如果，該訊息涉及到人類參與者或組織參與者，無論是這兩類參與者扮演發出端或接收端物件，都以一般日常對話的方式簡短命名訊息。但是，倘若該訊息發生在兩軟體物件之間的話，訊息名稱可以和操作簽名相同，而且採用程式語言的表達方式。

第174條指南列出參數的名稱，優於列出參數的型別。

第175條指南標示出型別，代替參數名稱。

只列出參數的型別，而沒有列出參數的名稱的話，經常無法知道這是個什麼樣的參數，所以列出參數名稱優先於型別。不過，也並非總是如此，有些型別本身就含有詳細的資訊時，採用型別反而比參數名稱更適當。

第177條指南不要在圖中表達明顯的回傳值。

第178條指南需要參考到回傳值時，才在圖中表達回傳值。

圖並不是要百分之百表達真實情況，套上80／20法則來說，圖所呈現的資料量只有百分之二十，但是我們用圖來強調百分之八十的關鍵性資訊。所以了，明顯的回傳值不需要表達出來就可以聯想到，這就不要表達了，除非是遇到其他訊息需要參考到該回傳值，這就另當別論了。

最後還有4條指南如下：

第179條指南將回傳值放置於回覆訊息箭頭旁。

第180條指南把回傳值視為方法的一部分。

第181條指南標示出型別，代替回傳值。

第182條指南簡單的回傳值，可以直接標示出實際數值。