UML序列圖中消息和約束概念詳解
本文和大家重點討論一下UMLUML序列圖中的消息和約束，UMLUML序列圖除了在設計新系統方面的用途外，它們還能用來記錄一個存在系統（稱它為“遺產”）的對象現在如何交互。
消息
為了可讀性，UML序列圖的***個消息總是從頂端開始，并且一般位于圖的左邊。然后繼發的消息加入圖中，稍微比前面的消息低些。
為了顯示一個對象（例如，生命線）傳遞一個消息給另外一個對象，你畫一條線指向接收對象，包括一個實心箭頭（如果是一個同步調用操作）或一個棍形箭頭（如果是一個異步訊號）。消息/方法名字放置在帶箭頭的線上面。正在被傳遞給接收對象的消息，表示接收對象的類實現的一個操作/方法。在圖4的例子中，analyst對象調用ReportingSystem類的一個實例的系統對象。analyst對象在調用系統對象的getAvailableReports方法。系統對象然后調用secSystem對象上的、包括參數userId的getSecurityClearance方法，secSystem的類的類型是SecuritySystem。2
圖4：一個在對象之間傳遞消息的實例
除了僅僅顯示UML序列圖上的消息調用外，圖4中的圖還包括返回消息。這些返回消息是可選擇的；一個返回消息畫作一個帶開放箭頭的虛線，向后指向來源的生命線，在這條虛線上面，你放置操作的返回值。在圖4中，當getSecurityClearance方法被調用時，secSystem對象返回userClearance給系統對象。當getAvailableReports方法被調用時，系統對象返回availableReports。
此外，返回消息是UML序列圖的一個可選擇部分。返回消息的使用依賴建模的具體/抽象程度。如果需要較好的具體化，返回消息是有用的；否則，主動消息就足夠了。我個人喜歡，無論什么時候返回一個值，都包括一個返回消息，因為我發現額外的細節使一個UML序列圖變得更容易閱讀。
當UML序列圖建模時，有時候，一個對象將會需要傳遞一個消息給它本身。一個對象何時稱它本身？一個純化論者會爭辯一個對象應該永不傳遞一個消息給它本身。然而，為傳遞一個消息給它本身的對象建模，在一些情境中可能是有用的。舉例來說，圖5是圖4的一個改良版本。圖5版本顯示調用它的determineAvailableReports方法的系統對象。通過表示系統傳遞消息“determineAvailableReports”給它本身，模型把注意力集中到過程的事實上，而不是系統對象。
為了要畫一個調用本身的對象，如你平時所作的，畫一條消息，但是不是連接它到另外的一個對象，而是你把消息連接回對象本身。
圖5：系統對象調用它的determineAvailableReports方法
圖5中的消息實例顯示同步消息；然而，在UML序列圖中，你也能為異步消息建模。一個異步消息和一個同步的畫法類似，但是消息畫的線帶一個棍形矛頭，如圖6所示。
圖6：表示傳遞到實體2的異步消息的UML序列圖片段
約束
當為對象的交互建模時，有時候，必須滿足一個條件，消息才會傳遞給對象。約束在UML圖各處中，用于控制流。在這里，我將會討論UML1.x及UML2.0兩者的約束。在UML1.x中，一個約束只可能被分配到一個單一消息。UML1.x中，為了在一個UML序列圖上畫一個約束，你把約束元件放在約束的消息線上，消息名字之前。圖7顯示UML序列圖的一個片段，消息addStudent方法上有一個約束。
圖7：UML1.xUML序列圖的一個片段，其中addStudent消息有一個約束
在圖7中，約束是文本“[pastDueBalance=0]”。通過這個消息上的約束，如果應收帳系統返回一個零點的逾期平衡，addStudent消息才將會被傳遞。約束的符號很簡單；格式是:
[BooleanTest]
舉例來說，
[pastDueBalance=0]
組合碎片(變體方案，選擇項，和循環)
然而，在大多數的UML序列圖中，UML1.x“in-line”約束不足以處理一個建模序列的必需邏輯。這個功能缺失是UML1.x的一個問題。UML2已經通過去掉“in-line”約束，增加一個叫做組合碎片的符號元件，解決了這一個問題。一個組合碎片用來把一套消息組合在一起，在一個UML序列圖中顯示條件分支。UML2規范指明了組合碎片的11種交互類型。十一種中的三種將會在“基礎”段落中介紹，另外兩種類型將會在“超越基礎”中介紹，而那剩余的六種我將會留在另一篇文章中介紹。（嗨，這是一篇文章而不是一本書。我希望你在一天中看完這部分！）
【編輯推薦】
