UML序列圖簡介

Scott W. Ambler
總裁，Ronin International
2001 年 1 月 11 日
本文來自 http://www.ibm.com/developerworks/cn

　

序列圖用于為使用方案的邏輯建模。使用方案恰如其名稱所揭示的那樣 -- 描述使用系統的潛在方法。使用方案的邏輯可以是用例的一部分，可能是備選過程。它也可以是整個用例過程，例如由基本行動過程描述的邏輯，或者部分基本行動過程再加上一個或多個替代方案描述的邏輯。使用方案的邏輯也可以是幾個用例中包含的邏輯。例如，一個學生在大學入學后，立即參加了三個研習班。序列圖以可視方式為系統中邏輯的流程建模，能夠讓您記載和驗證邏輯，這通常用于分析和設計目的。

uml/fig1.gif" target="blank">圖 1 是“參加研習班”用例的基本行動過程的模型。您可能想要現在打開該圖，并在閱讀本文時參考它。

分類器
橫貫該圖頂部的那些框表示的是分類器或它們的實例 -- 通常是用例、對象、類或參與者（往往用長方形表示，但它們也可以是符號）。

因為既可以向對象發送消息，又可以向類發送消息（對象通過調用操作來響應消息，而類則通過調用靜態操作來響應消息），所以有必要將它們都包括在序列圖中。另外，因為參與者在使用方案中發起操作并占據主動地位，因此也要將他們包括在序列圖中。對象的標簽具有標準 UML 格式 "name: ClassName"，其中的 "name" 是可選的。（在圖中沒有給出名稱的對象稱為匿名對象。）類標簽的格式為 "ClassName"，而參與者名的格式為 "Actor Name" -- 這些也都是 UML 標準。

例如在圖 1 中，"Student"（“學生”）參與者的名稱為 "A Student"，它的標簽為原型 <<actor>>。表示 "UI32 Seminar Selection Screen"（“UI32 研習班選擇屏幕”）的主要 UI 元素的實例是名稱為 ":SeminarSelector"、原型為 <<UI>> 的匿名對象。因為向 "Student" 類發送靜態消息 "isEligible(name, studentNumber)"，所以在圖中標名了該類（名稱為 "Student" 的框）。我們稍后再詳細說明。

在圖中，因為 "Student" 的實例在幾個地方都用作消息中的參數，所以為它提供了名稱 "theStudent"。與之相反，"StudentsFees" 類的實例不需要在圖中的其它任何地方引用，因此可以是匿名的。

生命線
從各個框垂下來的虛線稱為對象生命線，表示在對方案建模期間對象的生命跨度。生命線上的細長框是方法調用框，表明正在由目標對象／類執行處理，以完成消息。方法調用框底部的 X 是一種 UML 約定，表明對象已從內存中除去，這通常是接收到原型為 <<destroy>> 的消息的結果。

為消息建模
消息以帶有標簽的箭頭表示。當消息的源和目標為對象或類時，標簽是響應消息時所調用方法的簽名。不過，如果源或目標中有一方是人類參與者，那么消息就用描述正在交流的信息的簡要文本作為標簽。例如，":EnrollInSeminar" 對象向 "Seminar" 的實例發送消息 "isEligibleToEnroll(theStudent)"。請注意我是如何同時包含方法名和參數名的（如果有參數名，則傳遞給它）。

圖 1 還表明 "Student" 參與者通過標簽為 "name"（“姓名”）和 "student number"（“學號”）的消息向 ":SecurityLogon" 對象提供信息。（這些實際上并不是消息；它們實際上是用戶交互。）返回值可以使用帶有表明是返回值標簽的虛線箭頭表示。例如，標出了從 "Student" 類返回的，作為調用消息結果的返回值 "theStudent"，而沒有標出向 "seminar" 發送消息 "isEligibleToEnroll(theStudent)" 的結果的返回值。我的風格是，當返回內容很明顯時不標出返回值，這樣就不會把序列圖搞亂。（您可以發現，序列圖可以很快變得相當復雜。）

消息實現用例步驟的邏輯，圖的左側概括了這些步驟。請注意，由于步驟的描述往往太過冗長，以至于無法恰當地放在一張圖上，因此并沒有對用例步驟使用確切的措辭。關鍵是，步驟號要與用例中的步驟號對應起來，使圖的讀者能夠清楚地了解步驟的大體思想。

下面列出的是圖 1 所顯示的 UML 序列圖“參加研習班”用例的基本行動過程。

“參加研習班”用例

名稱：參加研習班

標識：UC 17

描述：允許有資格的學生參加研習班。

前提：是在校注冊學生。

結果：在學生有資格且有空位的條件下，允許該生參加他想參加的課程。

擴展：N/A

包含：N/A

繼承自：N/A

基本行動過程：

1. 學生想參加研習班。
2. 學生通過“UI23 安全登錄屏幕”將他的姓名和學號輸入系統。
3. 系統根據“BR129 確定參加資格”商業規則來驗證該學生是否有資格參加學校里的研習班。
4. 系統顯示可供選擇的研習班列表“UI32 研習班選擇屏幕”。
5. 學生指定他想參加的研習班。
6. 系統根據“BR130 確定學生參加研習班的資格”商業規則來驗證該學生是否有資格參加研習班。
7. 系統根據“BR143 驗證學生研習班課程表”商業規則來驗證研習班是否適合該學生的現有課程表。
8. 系統根據課程目錄中公布的費用、適用的學生費用和適用的稅款來計算研習班的費用。應用“BR 180 計算學生費用”和“BR45 計算研習班稅款”商業規則。
9. 系統通過“UI33 顯示研習班費用屏幕”顯示費用。
10. 系統詢問該學生是否仍然想參加研習班。
11. 學生表明他想參加研習班。
12. 系統招收該生參加研習班。
13. 系統通過“UI88 研習班注冊摘要屏幕”通知該學生注冊成功。
14. 系統根據商業規則“BR100 為學生開具研習班帳單”給該學生開出參加研習班費用的帳單。
15. 系統詢問該生是否想打印注冊報告書。
16. 學生表明他想打印報告書。
17. 系統打印注冊報告書 -“UI89 注冊摘要報告書”。
18. 當學生拿到打印的報告書后，用例結束。

備選過程 A：學生沒有資格參加研習班

1. 系統確定學生沒有資格參加研習班。
2. 系統通知該生，他沒有資格參加研習班。
3. 用例結束。

　

備選過程 B：學生不具備前提條件

1. 系統確定學生沒有資格參加他所挑選的研習班。
2. 系統通知該生，他不具備前提條件。
3. 系統通知該生他所需的前提條件。
4. 用例返回至基本行動過程的第 4 步繼續。

　

備選過程 C：學生決定不參加現有的研習班

1. 學生在查看了研習班的列表之后，發現沒有他想要參加的研習班。
2. 用例結束。

　

參考資料

• The Object Primer 2nd Edition，由 Scott W. Ambler 著。New York: Cambridge University Press, 2001。
• The Unified Process Inception Phase，由 Scott W. Ambler 和 Larry L. Constantine 合著。Gilroy, CA: R&D Books, 2000。
• The Unified Modeling Language Reference Manual，由 James Rumbaugh、Grady Booch 和 Ivar Jacobson 合著。Reading, MA: Addison-Wesley Longman, Inc., 1999。