UML序列圖詳解(1)

本文的主要目的是繼續把我們的重點放在基礎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代表用例圖）。

基礎

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

生命線

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

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

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

實體名 : 類名

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

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

消息

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

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

圖 4: 一個在對象之間傳遞消息的實例

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

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

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

為了要畫一個調用本身的對象，如你平時所作的，畫一條消息，但是不是連接它到另外的一個對象，而是你把消息連接回對象本身。

圖 5: 系統對象調用它的 determineAvailableReports 方法

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

圖 6: 表示傳遞到實體2的異步消息的序列圖片段