現在是二月，而且到如今你或許已經讀到、或聽到人們談論UML 2.0 —— 包括若干進步的 UML 的新規範，所做的變化。考慮到新規範的重要性，我們也正在修改這個文章系列的基礎，把我們的注意力從 OMG 的 UML 1.4 規範，轉移到 OMG 的已採納 UML 2.0草案規範（又名 UML 2）。我不喜歡在一系列文章的中間，把重點從 1.4 變為 2.0 ，但是 UML 2.0 草案規範是前進的重要一步，我感覺需要擴充文字。

由於一些理由，OMG 改良了 UML 。主要的理由是，他們希望 UML 模型能夠表達模型驅動架構（MDA），這意味著 UML 必須支援更多的模型驅動的符號。同時， UML 1.x 符號集合有時難以適用於較大的應用程式。此外,為了要使圖變成更容易閱讀，需要改良符號元件。（舉例來說，UML 1.x 的模型邏輯流程太複雜，有時不可能完成。對UML 2 中的序列圖的符號集合的改變，已經在序列化邏輯建模方面取得巨大的進步)。

注意我上面所述的文字：“已採納UML2.0草案規範。”確實，規範仍然處於草案狀態，但是關鍵 是草案規範已經被 OMG 採用，OMG是一個直到新標準相當可靠，才會採用它們的組織。 在 UML 2 完全地被採用之前，規範將會有一些修改，但是這些改變應該是極小的。主要的改變將會是在 UML 的內部 —— 包括通常被實施 UML 工具的軟體公司使用的功能。

本文的主要目的是繼續把我們的重點放在基礎UML圖上；這個月，我們進一步瞭解序列圖。再次請注意，下面提供的例子正是以新的 UML 2 規範為基礎。

圖的目的 
序 列圖主要用於按照交互發生的一系列順序，顯示物件之間的這些互動。很象類圖，開發者一般認為序列圖只對他們有意義。然而，一個組織的業務人員會發現，序列 圖顯示不同的業務物件如何互動，對於交流當前業務如何進行很有用。除記錄組織的當前事件外，一個業務級的序列圖能被當作一個需求檔案使用，為實現一個未來 系統傳遞需求。在專案的需求階段，分析師能通過提供一個更加正式層次的表達，把用例帶入下一層次。那種情況下，用例常常被細化為一個或者更多的序列圖。

組織的技術人員能發現，序列圖在記錄一個未來系統的行為應該如何表現中，非常有用。在設計階段，架構師和開發者能使用圖，挖掘出系統物件間的互動，這樣充實整個系統設計。

序列圖的主要用途之一，是把用例表達的需求，轉化為進一步、更加正式層次的精細表達。用例常常被 細化為一個或者更多的序列圖。序列圖除了在設計新系統方面的用途外，它們還能用來記錄一個存在系統（稱它為“遺產”）的物件現在如何互動。當把這個系統移 交給另一個人或組織時，這個文件很有用。

符號 
既 然這是我基於 UML 2的 UML 圖系列文章的第一篇，我們需要首先討論對 UML 2 圖符號的一個補充，即一個叫做框架的符號元件。在 UML 2中，框架元件用於作為許多其他的圖元件的一個基礎，但是大多數人第一次接觸框架元件的情況，是作為圖的圖形化邊界。當為圖提供圖形化邊界時，一個框架元 件為圖的標籤提供一致的位置。在 UML 圖中框架元件是可選擇的；就如你能在圖 1 和 2 中見到的，圖的標籤被放在左上角，在我將呼叫框架的“namebox”中，一種卷角長方形，而且實際的 UML 圖在較大的封閉長方形內部定義。

圖 1: 空的 UML 2 框架元件

除了提供一個圖形化邊框之外，用於圖中的框架元件也有描述互動的重要的功能, 例如序列圖。在序列圖上一個序列接收和傳送訊息（又稱互動），能通過連線訊息和框架元件邊界，建立模型（如圖 2 所見到）。這將會在後面“超越基礎”的段落中被更詳細地介紹。

圖 2: 一個接收和傳送訊息的序列圖

注意在圖 2 中，對於序列圖，圖的標籤由文字“sd”開始。當使用一個框架元件封閉一個圖時，圖的標籤需要按照以下的格式:

圖型別 圖名稱

UML 規範給圖型別提供特定的文字值。（舉例來說，sd代表序列圖，activity代表活動圖，use case代表用例圖）。

基礎 
序 列圖的主要目的是定義事件序列，產生一些希望的輸出。重點不是訊息本身，而是訊息產生的順序；不過，大多數序列圖會表示一個系統的物件之間傳遞的什麼消 息，以及它們發生的順序。圖按照水平和垂直的維度傳遞資訊：垂直維度從上而下表示訊息/呼叫發生的時間序列，而且水平維度從左到右表示訊息傳送到的物件實 例。

生命線 
當畫一個序列圖的時候，放置生命線符號元件，橫跨圖的頂部。生命線表示序列中，建模的角色或物件例項。 1 生命線畫作一個方格，一條虛線從上而下，通過底部邊界的中心（圖 3）。生命線名字放置在方格里。

圖 3: 用於一個實體名為freshman的生命線的Student類的一個例子

UML 的生命線命名標準按照如下格式:

實體名 : 類名

在如圖3所示的例子中，生命線表示類Student的實體，它的實體名稱是freshman。這 裡注意一點，生命線名稱帶下劃線。當使用下劃線時，意味著序列圖中的生命線代表一個類的特定實體，不是特定種類的實體（例如，角色）。在將來的一篇文章 中，我們將會了解結構化建模。現在，僅僅評述序列圖，可能包含角色（例如買方 和賣方 ），而不需要敘述誰扮演那些角色（例如Bill 和Fred ）。這准許不同語境的圖重複使用。簡單拖放，序列圖的例項名稱有下劃線，而角色名稱沒有。

圖 3 中我們生命線例子是一個命名的物件，但是不是所有的生命線都代表命名的物件。相反的，一個生命線能用來表現一個匿名的或未命名的實體。當在一個序列圖上， 為一個未命名的例項建模時，生命線的名字採用和一個命名例項相同的模式；但是生命線名字的位置留下空白，而不是提供一個例圖名字。再次參考圖 3，如果生命線正在表現Student類的一個匿名例圖，生命線會是: “Student”。同時, 因為序列圖在專案設計階段中使用，有一個未指定的物件是完全合法: 舉例來說，“freshman”。

訊息 
為了可讀性，序列圖的第一個訊息總是從頂端開始，並且一般位於圖的左邊。然後繼發的訊息加入圖中，稍微比前面的訊息低些。

為了顯示一個物件（例如，生命線）傳遞一個訊息給另外一個物件，你畫一條線指向接收物件，包括一 個實心箭頭（如果是一個同步呼叫操作）或一個棍形箭頭（如果是一個非同步訊號）。訊息/方法名字放置在帶箭頭的線上面。正在被傳遞給接收物件的訊息，表示接 收物件的類實現的一個操作/方法。在圖 4 的例子中，analyst物件呼叫ReportingSystem 類的一個例項的系統物件。analyst物件在呼叫系統物件的 getAvailableReports 方法。系統物件然後呼叫secSystem 物件上的、包括引數userId的getSecurityClearance 方法，secSystem的類的型別是 SecuritySystem。 2

圖 4: 一個在物件之間傳遞訊息的例項

除了僅僅顯示序列圖上的訊息呼叫外，圖 4 中的圖還包括返回訊息。這些返回訊息是可選擇的；一個返回訊息畫作一個帶開放箭頭的虛線，向後指向來源的生命線，在這條虛線上面，你放置操作的返回值。在 圖 4 中，當 getSecurityClearance 方法被呼叫時，secSystem 物件返回 userClearance 給系統物件。當 getAvailableReports 方法被呼叫時，系統物件返回 availableReports。

此外，返回訊息是序列圖的一個可選擇部分。返回訊息的使用依賴建模的具體/抽象程度。如果需要較好的具體化，返回訊息是有用的；否則，主動訊息就足夠了。我個人喜歡，無論什麼時候返回一個值，都包括一個返回訊息，因為我發現額外的細節使一個序列圖變得更容易閱讀。

當序列圖建模時，有時候，一個物件將會需要傳遞一個訊息給它本身。一個物件何時稱它本身？一個純 化論者會爭辯一個物件應該永不傳遞一個訊息給它本身。然而，為傳遞一個訊息給它本身的物件建模，在一些情境中可能是有用的。舉例來說，圖 5 是圖 4 的一個改良版本。 圖 5 版本顯示呼叫它的 determineAvailableReports 方法的系統物件。通過表示系統傳遞訊息“determineAvailableReports”給它本身，模型把注意力集中到過程的事實上，而不是系統對 象。

為了要畫一個呼叫本身的物件，如你平時所作的，畫一條訊息，但是不是連線它到另外的一個物件，而是你把訊息連接回物件本身。

圖 5: 系統物件呼叫它的 determineAvailableReports 方法

圖 5 中的訊息例項顯示同步訊息；然而，在序列圖中，你也能為非同步訊息建模。一個非同步訊息和一個同步的畫法類似，但是訊息畫的線帶一個棍形矛頭，如圖 6 所示。

圖 6: 表示傳遞到實體2的非同步訊息的序列圖片段

約束 
當 為物件的互動建模時，有時候，必須滿足一個條件，訊息才會傳遞給物件。約束在 UML 圖各處中，用於控制流。在這裡，我將會討論UML 1.x 及UML 2.0兩者的約束。在 UML 1.x 中，一個約束只可能被分配到一個單一訊息。UML 1.x中，為了在一個序列圖上畫一個約束，你把約束元件放在約束的訊息線上，訊息名字之前。圖 7 顯示序列圖的一個片段，訊息addStudent 方法上有一個約束。

圖 7:UML 1.x 序列圖的一個片段，其中addStudent 訊息有一個約束

在圖 7 中，約束是文字“[ pastDueBalance=0]”。通過這個訊息上的約束，如果應收帳系統返回一個零點的逾期平衡，addStudent 訊息才將會被傳遞。約束的符號很簡單；格式是:

[Boolean Test]

舉例來說，

[pastDueBalance = 0]

組合碎片(變體方案，選擇項，和迴圈) 
然 而，在大多數的序列圖中，UML 1.x“in-line”約束不足以處理一個建模序列的必需邏輯。這個功能缺失是 UML 1.x 的一個問題。UML 2 已經通過去掉“in-line”約束，增加一個叫做組合碎片的符號元件，解決了這一個問題。一個組合碎片用來把一套訊息組合在一起，在一個序列圖中顯示條 件分支。UML 2 規範指明瞭組合碎片的 11 種互動型別。十一種中的三種將會在“基礎”段落中介紹，另外兩種型別將會在“超越基礎”中介紹，而那剩餘的六種我將會留在另一篇文章中介紹。（嗨，這是一 篇文章而不是一本書。我希望你在一天中看完這部分！）

變體 
變體用來指明在兩個或更多的訊息序列之間的、互斥的選擇。 3 變體支援經典的“if then else”邏輯的建模（舉例來說，如果 我買三個，然後 我得到 我購買的20% 折扣；否則 我得到我購買的 10% 折扣）。

就如你將會在圖 8 中注意到的，一個變體的組合碎片元件使用框架來畫。單詞“alt”放置在框架的namebox裡。然後較大的長方形分為 UML 2 所稱的操作元。 4 操作元被虛線分開。每個操作元有一個約束進行測試，而這個約束被放置在生命線頂端的操作元的左上部。 5 如果操作元的約束等於“true”，然後那個操作元是要執行的操作元。

圖 8：包含變體組合碎片的一個序列圖片段

圖 8作為一個變體的組合碎片如何閱讀的例子，顯示序列從頂部開始，即bank物件獲取支票金額和帳戶結餘。此時，序列圖中的變體組合碎片接管。因為約束 “[balance >= amount]”，如果餘額超過或等於金額，然後順序進行bank物件傳遞 addDebitTransaction 和 storePhotoOfCheck 訊息給account物件。然而，如果餘額不是超過或等於金額，然後順序的過程就是bank傳遞addInsuffientFundFee 和 noteReturnedCheck 訊息給account物件，returnCheck 訊息給它自身。因為“else”約束，當餘額不大於或者等於金額時，第二個序列被呼叫。在變體的組合碎片中，不需要“else”約束；而如果一個操作元， 在它上面沒有一個明確的約束，那麼將假定“else”約束。

變體的組合碎片沒被限制在簡單的“if then else”驗證。可能需要大量的變體路徑。 如果需要較多的變體方案，你一定要做的全部工作就是把一個操作元加入有序列約束和訊息的長方形中。

選擇項 
選擇項組合碎片用來為序列建模，這些序列給予一個特定條件，將會發生的；或者，序列不發生。一個選擇項用來為簡單的“if then”表示式建模。（例如，如果架上的圈餅少於五個，那麼另外做兩打圈餅）。

選擇項組合碎片符號與變體組合碎片類似，除了它只有一個操作元並且永不能有“else”約束以外 （它就是如此，沒有理由）。要畫選擇項組合，你畫一個框架。文字“opt”是被放置在框架的 namebox 裡的文字，在框架的內容區，選擇項的約束被放置在生命線頂端上的左上角。 然後選擇項的訊息序列被放在框架的內容區的其餘位置內。這些元件如圖 9 所示。

圖 9：包括選擇項組合碎片的一個序列圖片段

閱讀選擇項組合碎片很容易。圖 9 是圖 7 的序列圖片段的再加工，但是這次它使用一個選擇項組合碎片，因為如果Student的逾期平衡等於0，需要傳遞更多的訊息。按照圖 9 的序列圖，如果Student的逾期平衡等於零，然後傳遞addStudent，getCostOfClass和chargeForClass訊息Ｈ綣鸖 tudent的逾期平衡不等於零，那麼在選擇項組合碎片中，序列不傳遞任何一個訊息。

例子圖 9的序列圖片段包括一個選擇項約束；然而，約束不是一個必需的元件。在高層次、抽象的序列圖中，你可能不想敘述選擇項的條件。你可能只是想要指出片段是可選擇的。

迴圈 
有時候你將會需要為一個重複的序列建模。在 UML 2 中，為一個重複的序列建模已經改良，附加了迴圈組合碎片。

迴圈組合碎片表面非常類似選擇項組合碎片。你畫一個框架，在框架的 namebox 中放置文字“loop”。在框架的內容區中，一個生命線的頂部，迴圈約束 6被 放置在左上角。然後迴圈的訊息序列被放在框架內容區的其餘部分中。在一個迴圈中，除了標準的布林測試外，一個約束能測試二個特定的條件式。特定的約束條件 式是寫作“minint = [the number]”（例如，“minint = 1”）的最小迴圈次數，和寫作“maxint = [the number]”（例如，“maxint = 5”）的最大迴圈次數。通過最小迴圈檢驗，迴圈必須執行至少指定次數，而迴圈執行次數不能達到約束指定的最大迴圈次數。

圖 10：迴圈組合碎片的一個序列圖例子 （單擊放大）

在圖 10 中顯示的迴圈執行，直到 reportsEnu 物件的 hasAnotherReport 訊息返回false。如果迴圈序列應該執行，這個序列圖的迴圈使用一個布林測試確認。為了閱讀這個圖，你和平常一樣，從頂部開始。當你到達迴圈組合碎片， 做一個測試，看看值 hasAnotherReport 是否等於true。如果 hasAnotherReport 值等於true，於是序列進入迴圈片斷。然後你能和正常情況一樣，在序列圖中跟蹤迴圈的訊息。

超越基礎

我已經介紹了序列圖的基礎，應該使你可以為將會在系統中通常發生的大部份互動建模。下面段落將會介紹用於序列圖的比較高階的符號元件。

引用另外一個序列圖 
當做序列圖的時候，開發者愛在他們的序列圖中，重用存在的序列圖。 7 在 UML 2 中開始，引進“互動進行”元件。追加互動進行的可以說是 UML 2 互動建模中的最重要的創新。互動進行增加了功能，把原始的序列圖組織成為複雜的序列圖。由於這些，你能組合（重用）較簡單的序列，生成比較複雜的序列。這 意味你能把完整的、可能比較複雜的序列，抽象為一個單一的概念單位。

一個互動進行元件使用一個框架繪製。文字“ref”放置在框架的 namebox 中，引用的序列圖名字放置在框架的內容區裡，連同序列圖的任何引數一起。引用序列圖的名字元號如下模式:

序列圖名[(引數)] [: 返回值]

兩個例子:

1. Retrieve Borrower Credit Report(ssn) : borrowerCreditReport

或者

2. Process Credit Card(name, number, expirationDate, amount : 100)

在例子 1 中，語法呼叫叫做Retrieve Borrower Credit Report的序列圖，傳遞給它引數 ssn。序列Retreive Borrower Credit Report返回變數 borrowerCreditReport 。

在例項 2 中，語法呼叫叫做Process Credit Card的序列圖，傳遞給它引數name，number，expiration date，和 amount。然而，在例子 2 中，amount引數將會是值100。因為例子2沒有返回值標籤，序列不返回值（假設，建模的序列不需要返回值）。

圖 11: 一個引用兩個不同序列圖的序列圖

圖 11 顯示一個序列圖，它引用了序列圖“Balance Lookup”和“Debit Account”。序列從左上角開始，客戶傳遞一個訊息給teller物件。teller物件傳遞一個訊息給 theirBank 物件。那時，呼叫Balance Lookup序列圖，而 accountNumber作為一個引數傳遞。Balance Lookup序列圖返回balance變數。然後檢驗選擇項組合碎片的約束條件，確認餘額大於金額變數。在餘額比金額更大的情況下，呼叫Debit Account序列圖，給它傳遞引數accountNumber 和amount。在那個序列完成後，withdrawCash 訊息為客戶返回cash。

重要的是，注意在圖 11 中，theirBank 的生命線被互動進行Balance Lookup隱藏了。因為互動進行隱藏生命線，意味著theirBank 生命線在“Balance Lookup”序列圖中被引用。除了隱藏互動進行的生命線之外，UML 2 也指明，生命線在它自己的“Balance Lookup”序列中，一定有相同的 theirBank 。

有時候，你為一個序列圖建模，其中互動進行會重疊沒有 在互動進行中引用的生命線。在那種情況下，生命線和正常的生命線一樣顯示，不會被重疊的互動進行隱藏。

在圖 11 中，序列引用“Balance Lookup”序列圖。“Balance Lookup”序列圖在圖 12 中顯示。因為例子序列有引數和一個返回值，它的標籤 —— 位於圖的 namebox 中 —— 按照一個特定模式:

圖型別 圖名 [引數型別:引數名]

[: 返回值型別]

兩個例子:

1. SD Balance Lookup(Integer : accountNumber) : Real

或

2. SD Available Reports(Financial Analyst : analyst) : Reports

圖 12 舉例說明例子 1，在裡面，Balance Lookup序列把引數 accountNumber 作為序列中的變數使用，序列圖顯示返回的Real物件。在類似這種情況下，返回的物件採用序列圖實體名。

圖 12: 一個使用 accountNumber 引數並返回一個Real物件的序列圖

圖 13 舉例說明例子 2，在裡面，一個序列圖獲取一個引數，返回一個物件。然而，在圖 13 中引數在序列的互動中使用。

圖 13: 一個在它的互動中使用引數、返回一個Reports物件的序列圖

門 
前 面的段落展示如何通過引數和返回值傳遞資訊，引用另一個序列圖。然而，有另一個方法在序列圖之間傳遞訊息。門可能是一個容易的方法，為在序列圖和它的上下 文之間的傳遞訊息建模。一個門只是一個訊息，圖形表示為一端連線序列圖的框架邊緣，另一端連線到生命線。使用門的圖 11 和 12 ，在圖 14 和 15 中可以被看到重構。圖 15 的例圖有一個叫做getBalance的入口門，獲取引數 accountNumber。因為是箭頭的線連線到圖的框架，而箭頭連線到生命線，所以 getBalance 訊息是一個入口門。序列圖也有一個出囗門，返回balance變數。出口門同理可知，因為它是一個返回訊息，連線從一個生命線到圖的框架，箭頭連線框架。

圖 14: 圖 11 的重構，這次使用門

圖 15: 圖 12 的重構，這次使用門

組合碎片（跳轉和並行） 
在本文前面“基礎”的段落中呈現的，我介紹了“變體”，“選擇項”，和“迴圈”的組合碎片。這些三個組合碎片是大多數人將會使用最多的。然而，有二個其他的組合碎片，大量共享的人將會發現有用——跳轉和並行。

跳轉 
跳 轉組合碎片幾乎在每個方面都和選擇項組合碎片一致，除了兩個例外。首先，跳轉的框架namebox的文字“break”代替了“option”。其次, 當一個跳轉組合碎片的訊息執行時，封閉的互動作用的其他訊息將不會執行，因為序列打破了封閉的互動。這樣，跳轉組合碎片非常象 C++ 或 Java 的程式語言中的break關鍵字。

圖 16: 來自圖 8 的序列圖片段的重構，片段使用跳轉代替變體

跳轉最常用來做模型異常處理。圖 16 是圖 8 的重構，但是這次圖16使用跳轉組合碎片，因為它把balance < amount的情況作為一個異常對待，而不是一個變體流。要閱讀圖 16，你從序列的左上角開始，向下讀。當序列到達返回值“balance”的時候，它檢檢視看是否餘額比金額更少。如果餘額不少於金額，被傳遞的下一個消 息是 addDebitTransaction 訊息，而且序列正常繼續。然而，在餘額比金額更少的情況下，然後序列進入跳轉組合碎片，它的訊息被傳遞。一旦跳轉組合的訊息的已經被傳遞，序列不傳送任何 其它訊息就退出（舉例來說，addDebitTransaction）。

注意有關跳轉的一件重要的事是，它們只引起一個封閉互動的序列退出，不必完成圖中描述的序列。在這種情況下，跳轉組合是變體或者迴圈的一部分，然後只是變體或迴圈被退出。

並行 
今天的現代計算機系統在複雜性和有時執行併發任務方面不斷進步。當完成一個複雜任務需要的處理時間比希望的長的時候，一些系統採用並行處理程序的各部分。當創造一個序列圖，顯示並行處理活動的時候，需要使用並行組合碎片元件。

並行組合碎片使用一個框架來畫，你把文字“par”放在框架的 namebox 中。然後你把框架的內容段用虛線分為水平操作元。框架的每個操作元表示一個在並行執行的執行緒。

圖 17: oven 是並行做兩個任務的物件例項

圖 17 可能沒有舉例說明做並行活動的物件的最好的計算機系統例項，不過提供了一個容易理解的並行活動序列的例子。序列如這樣進行：hungryPerson 傳遞 cookFood 訊息給oven 物件。當oven 物件接收那個訊息時，它同時傳送兩個訊息（nukeFood 和 rotateFood）給它本身。這些訊息都處理後，hungryPerson 物件從oven 物件返回 yummyFood 。

總結 
序列圖是一個用來記錄系統需求，和整理系統設計的好圖。序列圖是如此好用的理由是，因為它按照交互發生的時間順序，顯示了系統中物件間的互動邏輯。

參考

• UML 2.0 Superstructure Final Adopted Specification (第8章部分) http://www.omg.org/cgi-bin/doc?ptc/2003-08-02
• UML 2 Sequence Diagram Overview http://www.agilemodeling.com/artifacts/sequenceDiagram.htm
• UML 2 Tutorial http://www.omg.org/news/meetings/workshops/UML%202003%20Manual/Tutorial7-Hogg.pdf

腳註 
1 在完全建模系統中，物件（類的例項）也將會在系統的類圖中建模。

2 當閱讀這個序列圖時，假定分析師登入進入系統之內。

3 請注意，附著在不同的變體操作元上的、兩個或更多的約束條件式的確可能同時是真，但是實際最多隻有一個操作元將會在執行時發生（那種情況下變體的“wins”沒有按照 UML 標準定義)。

4 雖然操作元看起來非常象公路上的小路，但是我特別不叫它們小路。泳道是在活動圖上使用的 UML 符號。請參考The Rational Edge 早期關於 活動圖的文章。

5 通常，附上約束的生命線是擁有包含在約束表示式中的變數的生命線。

6 關於選擇項組合碎片，迴圈組合碎片不需要在它上放置一個約束條件。

7 可能重用任何型別的序列圖（舉例來說，程式或業務）。我只是發現開發者更喜歡按功能分解他們的圖。