第十一章、互動圖

11.1 互動圖的目的 靜態觀點只是呈現物件如何被定義以及物件與物件的關聯性 （很類似 ERD），並不能透露出物件與物件之間是如何來互相溝通、傳遞訊息。 而動 態觀點，則是在捕捉這一方面的性質，它可以呈現出系統如何對來自使用者 的行動/要求做出反應，並且呈現出資料如何由儲存的地方移動到使用者的 畫面。

UML 2.0 定義了四種描述物件之間彼此互動情形的圖形，它們分別是： 循序圖 （Sequence Diagram）：塑模出問題領域中物件之間互動的情形，重點放在描述一個使用案例執行的過程中，參與該案例之物件 與物件之間傳遞訊息的先後順序，強調訊息傳遞的時間性。 通訊圖 （C o m m u n i c a t i o n D i a g r a m）：塑模出問題領域中物件之間互動的情形，重點放在描述一個使用案例執行的過程中，有哪些物件 必須參與該案例，並且透過合作，傳遞訊息，以完成一個使用案例； 強調合作物件之間的結構 （註：通訊圖在UML 1.0 時稱為合作圖） 。 互動概觀圖 （Interaction Overview Diagram）：是一種活動圖的變形，用來描述高層次的控制流程以及它們之間的互動。 時序圖 （Ti m i n g D i a g r a m）：當互動圖中的主要探討重點是有關於時間時。時序圖將焦點放在生命線或者生命線之間在時間軸上狀態的 改變。

在這四種互動圖中，以循序圖及通訊圖最為重要，因此，在互動圖這一 部分，本書將焦點放在這兩個圖形上。之前有提到循序圖是用來塑模動態模 型，該圖形強調的是時間，顯示參與一個使用案例的物件們，它們彼此之間 傳遞訊息時間上的執行順序；通訊圖也是用來塑模動態模型，但是它與循序 圖不同的地方在於它強調的是參與一個活動之物件之間的關聯以及結構。由 於市面上有許多的CASE 工具可以讓循序圖與通訊圖互相直接轉換，所以繪 製互動圖時只需要畫一種圖形即可。

11.2 互動圖符號 在循序圖與通訊圖中，我們使用跟物件圖相同的記號來表示參與的物件，你可以將物件圖當作是表達物件互動的靜態觀點，而將循序圖或是通訊 圖看作是物件互動的動態觀點。這裡所說的物件指的是從類別所建構出來的 具體實例 （Instance），從物件圖中，我們知道物件的表法如圖 11.1 所示。

圖11. 1表示一個沒有名字的實例，它的型別為Object。而圖 11 圖11.1表示一個沒有名字的實例，它的型別為Object。而圖 11.2則是表示 一個有名字的實例。在此，這個物件的名稱為a B o o k，它的型別或者我們說 它的類別型態為Book。

11.2.2 生命線 在互動圖中，我們稱參與互動的物件為生命線（Lifeline）。在循序圖中 表達生命線的方式不同於通訊圖。在循序圖中，生命線表法如圖11.x所示。 我們可以看到在循序圖中，生命線多了一條垂直虛線的尾巴。

11.2.3 連結線 我們知道循序圖主要是用來顯示參與一個使用案例的物件們，它們彼此 之間傳遞訊息的順序。當一個物件發送一個訊息給另一個物件時，傳送者必 須知道被傳送者的存在；在意義上，也就是說它們之間存在著某種關聯的關 係。所以，在通訊圖的表法中，使用一條直線來連結這兩端的物件用以表示（某種程度的） 關聯即連結線（Link）。

在訊息傳遞的表達上，採用一條帶有箭頭的直線來表示物件A傳送一個 訊息給物件B，物件A可以傳送訊息給其他的物件當然表示物件A知道它的存 在。值得一提的是在循序圖中我們是無法表達關聯關係，只能表達出訊息由 那個物件傳遞給那個物件；當我們把循序圖轉換成通訊圖時，關聯關係的直 線才會顯現出來。圖11.4是物件obj1與obj2的通訊圖，圖中顯示出物件obj1送 了一個名為message的訊息給物件obj2。

11.2.4 啟動生命線 前面有提到，市面上已經有許多的CASE 工具可以讓循序圖與通訊圖互 相直接轉換，因此，如果應用有這種轉換功能的C A S E工具，上面的通訊圖 可以轉換成如圖11.5的循序圖。

我們可以發現到在物件的生命線中出現了長條方形的圖形，這個圖形叫做啟動生命線（Activation Lifeline），或者就稱為啟動（Activation）；在 UML 2.0 中，也稱其為控制焦點 （Focus of Control），這代表著系統在執 行的過程中，某物件在某個時間點上因為接收到某種訊息而被啟動並且擁有 了控制權。另外，值得注意的是，循序圖中無法顯示出物件與物件之間的關連線。

11.2.5 訊息 在循序圖與通訊圖中，訊息是一條帶有實心三角形箭頭的直線，此類訊 息（Message）稱為同步訊息。在此訊息上我們可以寫上一些簡述用以描述 該訊息所要表達的語意，對於訊息的描述可以只是簡短的文字敘述。例如在圖 11.6的循序圖中，物件obj1傳遞了一個名稱為message的訊息給obj2。

有許多的書比較喜歡用通訊圖來表示動態模型，一個簡單的原因是因為 通訊圖在繪製上所佔用的空間一般來說都比循序圖來得少。關於這一點，你 可以用圖11.4和11.5來做比較，當參與的物件變得很多的時候，循序圖就會佔 據較長的篇幅，因為在循序圖中，生命線是以水平的方式依序排列出來。

一個物件可以傳送訊息給其他的物件，當然也可以傳送訊息給它自己， 如圖11.7所示，這個時候連結線是從自己連結到物件自己本身。

一個物件可能傳送不只一個訊息給另一個物件，那麼根據它傳遞的時間順序，我們可以為每個訊息加上所謂的序號來顯示呼叫的次序，圖 11 一個物件可能傳送不只一個訊息給另一個物件，那麼根據它傳遞的時間順序，我們可以為每個訊息加上所謂的序號來顯示呼叫的次序，圖 11.8顯示 了obj1傳送訊息message1給obj2，過了一段時間之後，obj1又傳送了另一個訊 息message2給obj2。它所表達的含意是obj1請求obj2 執行 message1，執行完 畢之後，過了一段時間，obj1又傳遞了另一個訊息 message2 請求 obj2 執行。

另外，從圖11.8中我們看到有一條虛線從obj2 指向 obj1。在循序圖中， 此虛線代表回傳訊息 （return message），對於一個啟動的回傳訊息並不一 定要繪製出來，所以，對於 message2() 我們刻意不畫出回傳訊息。

上面所說的訊息是指同步的訊息 （S y n c h r o n o u s M e s s a g e）。然而對 於 某 些 系 統 來 說 ， 除 了 同 步 的 訊 息 之 外 ， 系 統 有 可 能 產 生 非 同 步 的（Asynchronous） 訊息以處理其他的事項。非同步訊息的表法為一條帶有 箭頭的直線，如圖11.9所示。所謂的同步訊息是指當該訊息一旦被啟動，則 只有等到啟動生命線結束之後，訊息才會回傳給呼叫者；而非同步訊息是一 旦啟動之後，會立刻返回呼叫者，呼叫者會繼續執行接下來該執行的動作而 不會等待非同步訊息的回傳。

在此，我們舉一個非同步訊號的應用例子。在一般典型的We b 2.0 應用 網站上我們常見到採用Ajax 技術來執行非同步的請求。 基本的Ajax請求之循序圖可以塑模如圖11.10。從此圖中，我們可以看到使用者在執行登入 的案例，登入的訊息在J a v a s c r i p t中被啟動，而這個啟動的過程中，它會執 行一個非同步的動作 send()將使用者的資訊傳送到伺服器端去驗證。然而， 在等待伺服器驗證的同時，使用者還是可以繼續其動作而不會有影響 （例 如：繼續瀏覽畫面等等）。一旦伺服器處理完畢，回傳到客戶端，客戶端的 Javascript 回呼函數會接著執行接下來所必須的工作 （例如：改變使用者的 畫面變成會員的畫面）。

11.2.6 產生 / 消滅訊息 一個物件在可以開始它的生命之前必須被產生，一旦完成它所付與的任 務之後可能需要被從系統中消滅掉，於循序圖中，我們也可以表達這兩種情 況。產生與消滅（Create and Destroy Message）這兩個訊息的圖形與一般 的同步訊息一樣，均為一條帶有實心三角形箭頭的直線。對於產生訊息，我 們只是在訊息上面多加了一個造型 <<c re a t e>>用以表示這是一個產生的訊 息；而對於消滅訊息則是在訊息的上面加上造型 <<destroy>> 並且在生命線 的尾端劃上一個大叉叉，如圖 11.11所示。此圖說明object2 首先被 object 1建 立，接著object1 傳送了一個 process() 的訊息給object2，最後，object1 消滅了 object2。

11.2.7 訊息參數 當一個物件傳遞訊息給另一個物件的同時，訊息也可以一起傳送參數， 這就好比像在程式中當我們呼叫一個函數時， 我們也會將這個函數所需的引 數一起傳遞。因此，如果你把訊息想像成結構化程式中所謂的副程式呼叫， 那就對了！唯一不同的是，在物件導向的語言中不存在所謂的副程式這種說 法。一般來說，參數的表法是採用下列的格式： 參數名稱：型態

圖 11.12顯示一個叫做john的學生送了「註冊課程」這個訊息給系統，連 同這個訊息一起傳送的是他所想要註冊的課程；這個課程物件叫做cour， 並 且在傳送的訊息中，我們也顯示出它的類別型態－ 課程 （Course）。

11.2.8 訊息回傳值 假如一個訊息有回傳值（Return Value）的話，你也可以將它在循序圖中表示出來。以圖 11.12 為例，當註冊課程成功時，我們希望這個訊息能夠 傳回一個整數，並且將這個整數存放在一個名為result的變數中，如此一來， 我們可以用如圖 11.13 所示的表法：

11.3 進階符號

11.3.1 框架 UML 2.0中定義了框架（Frame）的圖形，如圖 11.14，框架為一個長方 矩形，在其左上角有一個五邊形的標題區域，在標題區域內，我們可以給定 此框架所包含之元素的種類以及框架名稱，框架名稱基本上描述該框架所要 表達的語意。

應用於互動圖中的框架，UML 2.0定義其種類表法使用sd。例 如：圖11.15是一個使用框架的「下訂單」互動圖。

11.3.2 組合片段 當我們描述一序列的互動過程時，有某些特定的步驟可能需要滿足某些條件才會繼續進行下去，或者是我們可能必須要使用迴圈來處理某個集 合類中的元素，這些片段稱為互動片段 （Interaction Fragment）。UML2.0 中定義了一種新的圖形稱為組合片段（C o m b i n e d F r a g m e n t）用來包含這些互動片段。組合片段的主要用途在於分解循序圖，讓循序圖中可以表達更豐富的語意。根據U M L 2.0的定義，組合片段定義了互動片段的表 達式（E x p r e s s i o n），因此，組合片段包含兩部分：一個稱為互動運算子（Interaction Operator），互動運算子由簡單的英文字母所組成；另一個稱 為互動運算元（Interaction Operand），互動運算元包含一個或多個互動片 段，組合片段結構如圖11.16所示。

下面我們列出幾個比較常用的互動運算子並且以例子來說明如何在塑模 互動的過程中使用它們。

1. opt：用於只有當條件成立時，才會執行單一運算元。此運算子很類似 於程式語言中的：if (條件) then 動作。 範例：「⋯當我們去提款機提款時，我們首先會插入卡片，系統這時候會 驗證卡片的有效性，當卡片是有效時（Valid），系統會要求我們輸 入密碼⋯」。對於這段描述，我們可以使用o p t組合片段表達於循 序圖中，如圖11.17 所示。

2. alt：用於表達多種選擇，當條件成立時，才會執行相關的運算元。此運算子很類似於程式語言中的： if (條件1) then 動作 1 else if (條件2) then 動作2 else 動作3 範例：「⋯當我們去提款機提款時，我們首先會插入卡片，系統這時候會 驗證卡片的有效性，當卡片是有效時（Valid），系統會要求我們輸 入密碼；而當卡片是無效時，系統會顯示無效訊息⋯」。對於這段 描述，我們可以使用alt組合片段完整地表達於循序圖中，如圖11.18 所示。

3. loop：用於表達迴圈，被包含之互動運算元會被執行許多次，loop的 條件式表法為 minint, maxint [條件]，或者是 [for each 物件]。 範例： 「⋯計算購物車中訂購項目的總金額⋯」這句描述可以利用l o o p 組合片段表達如圖 11.19所示。當購物車接收到計算總金額的訊息 時，購物車首先將其總價歸零，然後對於購物車中所包含之各項訂 購項目，依序執行「取出單價，將單價加入總價」的動作。

4. break：用於跳出迴圈。一般來說，會在break 後面加上條件，用於表達當條件為真時，被包含之運算元會被執行。另外，break組合片段的 繪製必須涵蓋到所有被包含之生命線。 範例：「 ⋯ 顧 客 搜 尋 產 品 ⋯ 」 。 假 設 說 所 有 的 產 品 目 前 放 在 集 合 物 件 products 中，而搜尋產品時，必須逐一比對各產品之產品編號是否 與想要搜尋之產品相同；如果是的話，則回傳此產品，不是的話， 回傳空物件（Null）。利用loop 以及break，我們可以將此描述以 循序圖表達如圖11.20。

5. ref：參照其他的互動。對於複雜的流程步驟，我們可以將其互動的流程繪製於某個組合片段，然後在需要參照到這些組合片段的步驟中使 用re f。 例如在圖11.21中，當AT M系統顯示選擇畫面給顧客時，顧客 可能有的動作包括選擇提款或是選擇查詢餘額的動作，提款與查詢餘 額這兩個案例的執行細節我們可以從目前的流程中獨立出來，並且於 互動圖中使用ref組合片段來說明請參考相關的互動圖。在UML 2.0 中 稱ref組合片段為「互動使用」（Interaction use）。互動使用不僅可 以出現在循序圖中，它們也常常出現在互動概觀圖上。

除了上述幾個常見的的組合片段之外，組合片段還包括有： 6. critical ：表達一個critical 區域，亦即是運算元在此組合片段中執行時 不可被中斷。 7. neg ：表達此組合片段為無效，不可能參與互動。 8. assert ：表達斷言以確保某個動作的執行。 9. ignore ：表達那個訊息在互動中應該被忽略。 10. consider ：表達那個訊息在互動中應該被考慮。

11.3.3 互動概觀圖 本章一開始有介紹到互動概觀圖（Interaction Overview Diagram）是活動圖的一種變形，其作用在於描述高層次的控制流程以及它們之間的互 動。在互動概觀圖中，除了動作（Action） 圖形之外，均使用與活動圖中相 同的圖形，例如活動開始、活動結束、分叉、決策等等；而被取代的動作圖 形改用「互動使用」（Interaction Use）或者是其他的互動圖元件。

圖11.22是一個使用互動概觀圖來描述借書的執行流程。圖中使用到互動 使用元素來告訴讀者這個部分請參考其他相關的互動圖以了解其細部內容以 及互動流程。

另外，在循序圖繪製過程中，如果我們發現到某些互動流程會重複出 現，那麼我們可以使用「互動使用」來表達此片段活動。舉例來說，圖11 另外，在循序圖繪製過程中，如果我們發現到某些互動流程會重複出 現，那麼我們可以使用「互動使用」來表達此片段活動。舉例來說，圖11.23 表示一個登入的互動圖，而在圖11.24中之瀏覽書籍互動中，我們繪製登入的 互動使用，其意思代表著對於登入這個互動的過程請參閱登入的互動圖。

11.4 系統循序圖

11.4.1 系統循序圖 我們知道使用案例所描述的是系統所提供的功能，而使用者與系統之間 的互動細節，可以用使用案例規格書敘述下來，除此之外，使用案例規格書中記載著執行一個使用案例的正常路徑、例外路徑等等資訊。一個系統外 部的使用者與系統之間的互動以及訊息傳遞，基本上都可以利用循序圖來表 達；有時候，我們就稱這種循序圖為「系統循序圖」。 讓我們用「 顧客訂購C D」使用案例來說明系統循序圖的概念。顧客訂 購CD使用案例的基本路徑如下：

1. 顧客選擇其中的一個CD以查看更多的資訊 2. 系統顯示顧客該CD的基本資訊 3. 顧客把CD放入到購物車. 4. 系統顯示購物車內容 5. 顧客結帳 （Check-out） 6. 系統顯示登入畫面 7. 顧客提供登入資料E-mail跟密碼 8. 系統驗證登入資料 9. 系統驗證顧客的信用卡資料 10. 系統儲存訂單交易資訊 11. 系統寄發訂單確認函（E-mail）給顧客 12. 系統顯示訂單交易明細資訊

在此，我們再重複一次何謂路徑：路徑是描述在一個使用案例中，使用者與系統之間的互動以完成這個使用案例的流程。所以，在一開始繪製循序 圖時，我們可以繪製兩個簡單的物件：一個物件代表使用者，另一個物件代 表系統（圖11.25）。因為在我們的使用案例中，使用者其實是泛指所謂的顧 客，所以用顧客 （Customer） 來代表我們的使用者；不過，這兩個物件都 是無名的 （Anonymous） 物件。

接著，我們可以就使用案例規格書中的每一條敘述利用訊息傳遞的方式來表達。基本上，訊息的寫法以動詞為開端，系統回應給使用者的部分則可 以採用「顯示⋯」以代表系統的回應。利用這個做法，我們將上述的使用案 例基本路徑繪製成如圖 11.26 （系統） 循序圖。

在分析階段時，循序圖應該捕捉到使用案例的正常路徑；而對於使用案 例中的場景 （Scenario） ，我們可以進一步地利用循序圖來做分析。對於不同的場景，它也應該有一個對應的循序圖，或者是利用組合片段將其畫於同一張循序圖上。

這裡，我們來看一下循序圖與其他圖的差異： 循序圖捕捉特定的場景， 而使用案例描述一般來說包含多個場景。 對於一個使用案例，我們可以利用活動圖來顯示多個路徑或是平行的工作，在以往UML 1.x 中，循序圖只能表達出一個使用案例的某個特 定路徑，所以對於不同的場景，我們必須要繪製不同的循序圖。而從U M L 2.0開始，使用組合片段或是互動概觀圖，我們可以只使用一張 循序圖來表達整個使用案例的執行流程與細節。

11.4.2 精練系統循序圖 讓我們以自動提款機 （ATM） 的轉帳使用案例做為範例來說明，如圖11.27所示。

如圖 11.27的初步的循序圖勾勒出使用者與系統的基本互動，但是也帶給 我們有更多的疑問。例如說，使用者是如何要求轉帳的？系統是如何知道以 及提供客戶的帳戶？⋯等等，這些疑問都是必須仔細地加以分析以及檢驗。 由於循序圖的繪製不會一次就完成，以上所提的問題，也會隨著對領域問題 有更深的了解後，在接續的過程中慢慢得出答案。圖 11.28是在與領域專家仔 細討論過後，再加以精練所得之轉帳系統循序圖。