準則: 序列圖
序列圖是一項 UML 建構,它用來顯示實現使用案例情境行為的物件互動序列。這個準則說明這項建構的 UML 表示法。
關係
主要說明

簡介

在大部分情況下,我們都利用序列圖來說明使用案例實現化(請參閱工作成果:使用案例實現化),也就是顯示物件如何互動來執行整個或部分使用案例的行為。一或多個序列圖可以說明實現使用案例的物件互動。典型的組織是主要事件流程有一個序列圖,使用案例每個獨立的子流程也各有一個序列圖。

對設計者而言,序列圖尤其重要,因為他們會釐清物件在流程中的角色,因而提供用來判斷類別責任和介面的基本輸入。

序列圖和通訊圖不同,它包括依時間順序的序列,但不包括物件關係。序列圖和通訊圖會表示類似的資訊,但表現的方式不同。序列圖會顯現明確的訊息序列,當視覺化訊息的時間順序很重要之時,比較好用。當您對互動實例之間的結構關係感興趣時,請使用通訊圖。請參閱技術:通訊圖,以取得詳細資訊。

序列圖的內容

序列圖可以有物件和參與者實例,以及用來說明它們如何互動的訊息。這個圖藉由啟動及物件如何互相傳送訊息進行通訊來說明參與的物件發生了什麼。您可以針對使用案例事件流程的每個變式來建立一份序列圖。

圖解說明詳見隨附的文字。

說明簡式電話交換機中 Place Local Call 使用案例之部分事件流程的序列圖。

物件

物件會顯示成稱為「生命線」的垂直虛線。生命線代表物件在特定時間的存在。物件符號畫在生命線的頭,它會顯示物件名稱及其加底線的類別,中間用冒號分開:

objectname : classname

您可以依照下列方式來使用序列圖中的物件:

  • 生命線可以代表物件或它的類別。因此,您可以利用生命線來建立類別和物件行為的模型。不過,生命線通常代表特定類別的所有物件。
  • 物件的類別可能尚未指定。您在建立序列圖時,通常是先有物件,稍後再指定它們的類別。
  • 物件可能尚未命名,如果您要區分相同類別的不同物件,您應該將它們命名。
  • 相同圖中的多條生命線可能代表相同類別的不同物件;不過,如先前所說明,這些物件應該要命名,您才能區分兩個物件。
  • 代表類別的生命線可以與代表這個類別之物件的生命線同時存在。代表類別之生命線的物件名稱可以設為類別名稱。

參與者

參與者實例通常是由序列圖中的第一條(最左側)生命線來表示,作為互動的呼叫端。如果同一個圖中有多個參與者實例,請試著將它們放在最左或最右側的生命線上。

訊息

訊息是在物件之間用來傳遞資訊的通訊,且預期接著會有活動;在序列圖中,訊息顯示成一個水平實心箭頭,從一個物件的生命線指向另一個物件的生命線。當物件將訊息傳給自己時,箭頭便可能開始和結束於相同生命線。箭頭的標籤是訊息名稱及其參數。箭頭的標籤也可以是顯示訊息在整體互動中之順序的序號。序列圖通常會省略序號,這時箭頭的實體位置會顯示相對的順序。

訊息也可能並未指派,這表示它的名稱是用來說明訊息整體意義的暫時字串,而不是接收端物件的作業名稱。您可以稍後再指定訊息目的地物件的作業來指派訊息。之後,指定的作業會取代訊息名稱。

Script

Script 會在序列圖中,以文字方式來說明事件流程。

您應該將 Script 放在生命線左側,以便由上而下讀取完整的流程(請參閱上圖)。您可以將 Script 附加到特定訊息,以確保 Script 會隨著訊息而移動。

在序列圖中分配控制流程

事件流程或其中一部分的集中式控制,是指少數物件藉由傳送訊息給其他物件及接收其他物件的訊息來帶領流程。這些控制物件決定了其他物件在使用案例內的啟動順序。在其餘物件之間,互動非常少,甚至根本沒有。

範例

回收機系統中,列印每日報表使用案例會追蹤退回物件的數目和類型,且會將記錄寫在收據上。報表產生器控制物件決定總計的擷取和寫入順序。

圖解說明詳見隨附的文字。

報表產生器控制物件中,列印每日報表使用案例是集中式的行為結構。

這是集中式行為的範例。控制結構是集中式,主要是因為事件流程的不同子事件階段彼此不相依。這個方法的主要好處是每個物件都不需要追蹤下一個物件的記錄。如果要變更子事件階段的順序,您只需要在控制物件中進行變更。另外,您也可以輕易新增另一個子事件階段,例如,當併入新的退回項目類型時。這個結構的另一個好處是您可以輕易重複使用其他使用案例中的各種子事件階段,因為行為的順序並不內建在物件中。

當參與的物件不透過一或多個控制物件來通訊,而是直接互相通訊時,便產生分散式控制

範例

傳送信件使用案例中,某人利用郵局將一封信寄到另一個國家或地區。這封信最初是傳到收件人的國家或地區。在這個國家或地區,信件再傳到特定城巿。這個城市再將信件傳到收件人的家。

圖解說明詳見隨附的文字。

傳送信件使用案例是分散式的行為結構。

這個使用案例行為是一個分散式事件流程。子事件階段彼此互相屬於對方。信件的傳送端會談到「將信件傳給某方」。他不需要,也不想要知道信件在國家、地區或城市內的轉遞方式。(如果有人在相同國家或地區內郵寄信件,這些動作大概不會全部發生。)

使用的控制項類型會隨著應用程式而不同。一般而言,您應該試著實現獨立的物件,也就是說,將各種作業委派給自然最適合執行它們的物件。

集中式控制的事件流程會有一個「分岔模板」的序列圖。另一方面,「階梯模板」的序列圖則說明參與的物件是採用分散式控制結構。

圖解說明詳見隨附的文字。

事件流程的集中式控制結構會產生「分岔模板」的序列圖。分散式控制結構會產生「階梯模板」的序列圖。

使用案例實現化的行為結構通常混合集中式和分散式的行為而組成。

在下列情況下,適合採用分散式結構:

  • 如果子事件階段緊密耦合。當參與的物件符合下列情況,便是如此:
    • 形成一個組成或包含階層,如國家 - 州省 - 巿:
    • 形成資訊階層,如 CEO - 部門管理人員 - 科處長:
    • 代表固定的時間序列進度(子事件階段序列一律依照相同順序來執行),如廣告 - 訂單 - 發貨單 - 交貨 - 付款;或
    • 形成概念性的繼承階層,如動物 - 哺乳動物 - 貓。
  • 如果您要封裝功能,藉此來將功能抽象化。這非常適合一律使用全功能的使用者,因為如果是集中化的行為結構,功能會不必要地成為難以控制。

在下列情況下,適合採用集中式結構:

  • 如果子事件階段的執行次序可能會改變。
  • 如果您預期插入新的子事件階段。
  • 如果功能組件要保持能夠作為獨立的功能來重複使用。