【用VS2010動手學UML第24回】操控聯合片段的12種互動操作子（下）

在UML循序圖中，定義了12種互動操作子，可以控制聯合片段，讓整個圍住的互動片段執行相同的操作。

在上一回文章中介紹過了「替代」、「選擇」、「並行」、「迴圈」、「中斷」、「否定」、「關鍵」這幾種互動操作子，接下來介紹「弱序」和「嚴序」。

聯合片段：弱序和嚴序
在說明「弱序」（seq，weak sequencing）和「嚴序」（strict，strict sequencing）這兩個互動操作子之前，我們要先說明事件發生的順序規則。

首先，我們先來解釋事件，一條訊息線的兩個端點處，各會發生一個事件。其實，這還蠻容易理解的，訊息的底端是「發送事件」（Send Event），而訊息的箭頭端就是「接收事件」（Receive Event）。請你看到圖1，為了方便說明，這張循序圖是我改用StarUML畫的圖。

圖1 發送事件與接收事件[StarUML]

一般，如果沒有額外的特殊規定的話，事件發生的順序都會遵守下列三條共同規範：

1. [共同] 成對的事件中，發送事件一定在接收事件前面。比方說，圖1的訊息p中，發送事件p!一定會發生在接收事件p*之前，這挺合理，不需要我多做解釋。所以，p!在p*前，r!也會發生在r*前。

2. [共同] 在同一條存活線上，事件發生的順序是由上而下的。所以，圖1的發送事件p!會發生在發送事件r!前面。

3. [共同] 如果位於不同存活線上，事件發生的順序是互不相干的。所以，圖1的接收事件p*可能發生在r*前面，也可能發生在r*後面，總之因為p*和r*位於不同的存活線上，所以誰先誰後互不相干。再者，p*和r!兩事件的發生順序，也不一定，有可能還沒發生p*時，就先發生r!了；也有可能已經發生了p*之後，r!才發生，這都有可能，因為p*和r!位於不同存活線上。

因此，排列組合一下會發現，

和

這兩種事件發生順序是合法的，有遵守事件發生順序的一般性規定。

回過頭來看「弱序」，弱序其實跟之前談過的「並行」很像，只是多了一道限制。因為前面已經認識了「並行」，所以此處我們可以同時來看並行的事件發生順序規則。並行的規則有兩條，弱序則多出了一條規則，如下：

1. [並行|弱序] 在同一個互動操作區中，事件發生的順序遵守前述的三條共同規範。簡單來說，共同規範就是：

● [共同] 成對事件中，發送事件發生在接收事件前。

● [共同] 同存活線上，事件由上而下依序發生。

● [共同] 不同存活線，事件順序不確定。

2. [並行|弱序] 在不同的存活線上，且位於不同的互動操作區中，所發生的事件，沒有一定的順序。簡而言之，不同區的事件可以彼此交錯發生。
3. [弱序] 在同一條存活線上，但位於不同的互動操作區中，所發生的事件，必須按照互動操作區的順序，由上而下依序發生。

以上來看，並行的限制條件比弱序還要少。在並行中，不同互動操作區中，其實就是並行執行的。所以，即使在同一條存活線上，只要是不同的互動操作區，其實事件發生的順序就彼此不會相干了。

對了，順便提醒一下，循序圖上事件的發生順序，這是UML初級認證和中級認證中的必考題型，如果你有興趣報考UML認證的話，這些都是一定要搞清楚的地方。

接著，請你看到圖2的範例，這張循序圖是我用StarUML混著Word畫出來的，因為到目前為止，我還沒找到可以繪製斜訊息線的UML工具，我是指圖2中的訊息q。其實，圖2不是我自個創作的，而是參考自《UML2 Certification Guide：Fundamental and Intermediate Exams》一書中的圖3.151。還有，等一下我們談到強序時，所使用的範例一樣參考自這本原文書的圖3.152。

圖2 弱序（seq）[參考自UML2 Certifi cation Guide書中的圖3.151]

引用的主要原因在於，弱序和強序的觀念少用，我個人在實務上真是從來也沒用過。而且，UML規格書雖然有定義，但是沒有提供範例，實在不好懂。一般的UML書中也沒見提過，我就僅看到這本講UML初級中級認證的書中談到，要讓我舉例子，大概也是會偷學這本書的範例，所以乾脆就厚臉皮地引用這本原著了。

講這麼多，我們還沒解釋圖2的事件發生順序，現在馬上來解釋一下。如果，圖2是並行的話，就簡單了，總之兩個互動操作區內的事件發生順序，可以混著交錯發生。但是，因為標示著弱序，所以S存活線上的三個事件，必須按照

依序發生，就如圖3所示。

圖3 遵守弱序規則

對了，

依序發生，不代表這三個事件一定要連續發生，其他事件當然可以穿插其中。

所以，在《UML2 Certification Guide：Fundamental and Intermediate Exams》書中，就提到了<「p!」, p*, t!, t*, q!, 「r!」, r*, 「q*」>和<「p!」, t!, t*, p*, 「r!」, r*, 「q*」>都是合法的事件順序，正是因為這個理由。

至於，強序的話，則是規定事件發生順序要完全依照存活線由上而下依序發生，無論是否位於不同的存活線上，或者位於不同的互動操作區內，全都遵守由上而下的順序。所以，請你看到圖4的範例，可以判斷出事件發生的順序嗎？

圖4 強序（strict）[ 參考自UML2 Certifi cation Guide書中的圖3.152]

最後，請你看到圖5，我跟《UML2 Certification Guide：Fundamental and Intermediate Exams》書中的答案相同，都是

。不知道你的答案是否也跟我們一樣嗎？

圖5 完全由上而下依序

聯合片段：考慮與忽視
在循序圖中，「考慮」（consider）與「忽視」（ignore）會擇一出現，而且在這兩個互動操作子後面都會列出一組受限制的訊息。比方說：

● consider {q,v,w}：在標示考慮（consider）的聯合片段中，「只能」出現q、v和w這三個訊息，其餘的訊息「不可以」出現在這個考慮片段中。

● ignore {r,s,t}：在標示忽視（ignore）的聯合片段中，「不能」出現r、s以及t這三個訊息，其餘的訊息「都可以」出現在忽視片段中。

請你看到圖6，這個範例是我參考UML規格書的例子，但是經過局部簡化而來。由於，consider後面列出q、v、w這三個訊息，指定只有這三個訊息可以出現在考慮的聯合片段中。

圖6 考慮（consider）[UML規格書]

再者，請你打開考慮的聯合片段性質表來查看，其中有一個訊息列（Messages）的欄位，可以讓我們列出只能出現的訊息，如圖7所示。注意，要列出多個訊息時，訊息跟訊息之間必須使用逗號隔開。

圖7 考慮聯合片段的性質表

接著，再看到圖8的例子，忽視聯合片段標示出不可以出現r、s和t這三個訊息。所以，在這個例子裡，忽視聯合片段中出現訊息v和q這是沒問題的，只要不出現訊息r、s和t，就可以了。

圖8 忽視（ignore）

最後，請看到圖9的忽視聯合片段性質表，也是在訊息列（Messages）欄位，以逗號做為訊息的分隔符號。

圖9 忽視聯合片段的性質表

聯合片段：斷言
最後一個，「斷言」（assert）標示出一定要出現在該處的聯合片段，若是在該處沒有出現斷言片段的內容，則代表這個互動有問題，是個無效的互動。

請看到圖10的範例，這個範例也是UML規格書中的範例，但是有經過我的簡化。在圖10中，斷言片段指出在訊息v之後，一定要出現一個訊息q，否則整個考慮片段就是有問題的，是個無效的互動片段。

圖10 斷言（assert）[UML規格書]

循序圖的價值
我個人的認為，循序圖不僅困難、重要，而且更是深具「價值」。我經常打趣著說，循序圖的價值甚至可以直接折算現金呢！

怎麼說？市場上有很多UML工具，有些是開源軟體、有些是免費軟體、有些是有提供受限的免費公眾版（Community Edition），這些可以免費使用的UML工具，有很多都有提供依據類別圖自動產碼的功能。

但是，我們可以發現一個有趣的現象就是：或許我們可以免費獲得依據類別圖自動產碼的功能，可是如果想要獲得依據循序圖自動產碼的功能時，嘿嘿，就得乖乖地付費，才能獲得這項功能。所以，我才會這麼說，循序圖深具「價值」啊！

好了，下面我們就來看看循序圖具備的幾項重要價值，條列如下：

● 檢驗類別圖的可行性：從單方向來設計類別圖，是很難甚至無法判斷類別圖的可行性的。此處所謂的可行性是指，程序員按照類別圖編寫程式碼，其實是否真的能夠順暢運作，以及可以支撐所有用例。這是系統分析師很難從類別圖面上直接檢驗出來的，必須藉助一張又一張的循序圖，一次又一次地檢驗類別圖，才能夠獲得真正可以執行的類別圖。

● 支援用例的流程運作：在用例背後，真正在支撐其流程運作的，其實是一群物件的互動，而這正是循序圖所呈現的內容。

● 檢驗用例敘述的可行性：同樣的，系統分析師在編寫用例敘述時，也是無法直接驗證用例敘述是否可行，所以我們還是要藉助循序圖表達系統內部物件的互動，才能夠獲知系統內部是否能夠支援用例。

● 呈現物件的行為細節：物件的行為細節記錄在它的「操作」（Operation）中，但是在類別圖中，我們只能獲知物件具有哪些操作，卻無法記錄在每一個操作中，會執行哪些重要的動作。而這部分的物件行為細節，則必須藉助循序圖來構思與呈現。

● 決定物件互動的效率：循序圖不僅可以呈現物件的行為細節，由於它呈現了一群物件之間的互動，所以物件之間是否能夠進行有效率的互動，當然也是可以從調整循序圖的設計而得。

UML官方將互動引用與聯合片段都列為循序圖的中級概念，這兩者的圖示都相同，主體也採用大方框圖示。主要的辨識方式是，查看左上角五角型內所標示的關鍵字，如果是sd和ref則是互動引用，其餘的就是12個互動操作子的縮寫。這兩者都是UML2才提出的新觀念。所以，你要是想判斷一個UML工具或書籍是否真的得支援到UML2，直接查看對互動引用與聯合片段的支援，就立即可以得知了。下一回將進一步介紹繪製循序圖的最佳實務，包括9條我自己累積的循序圖繪製實務，以及專家推薦的最佳實務。最後，同樣和前面幾種UML圖的介紹一樣，我會用課務系統作為例子，並且用以前介紹過的用例圖，以及類別圖，來繪製循序圖。