在學習UML的過程中，你可能會遇到UML狀態(tài)機視圖方面的問題，這里就和大家分享一下UML狀態(tài)機視圖事件方面的知識，希望本節(jié)的介紹對你的學習有所幫助。下面讓我們一起來學習UML狀態(tài)機視圖事件吧。

UML狀態(tài)機視圖事件

事件是發(fā)生在時間和空間上的一點的值得注意的事情。它在時間上的一點發(fā)生，沒有持續(xù)時間。如果某一事情的發(fā)生造成了影響，那么在狀態(tài)機模型中它是一個事件。當我們使用事件這個詞時，通常是指一個事件的描述符號，即對所有具有相同形式的獨立發(fā)生事件的描述，就像類這個詞表示所有具有相同結構的獨立類一樣。一個事件的具體發(fā)生叫做事件的實例。事件可能有參數(shù)來辨別每個實例，就像類用屬性來辨別每個對象。對類而言，信號利用泛化關系來進行組織，以使不同的類共享公用的結構。UML狀態(tài)機視圖事件可以分成明確或隱含的幾種：信號事件、調(diào)用事件、修件事件、時間事件等。表6–1是幾種事件類型及其描述。

1.信號事件

首先看一下UML狀態(tài)機視圖事件中中的信號事件。信號是作為兩個對象之間的通信媒介的命名的實體，信號的接收是信號接受對象的一個事件。發(fā)送對象明確地創(chuàng)建并初始化一個信號實例并把它發(fā)送到一個或一組對象。最基本的信號是異步單路通信，發(fā)送者不會等待接收者如何處理信號而是獨立地做它自己的工作。在雙路通信模型中，要用到多路信號，即至少要在每個方向上有一個信號。發(fā)送者和接受者可以是同一個對象。

信號可以在類圖中被聲明為類元，并用關鍵字《signal》表示，信號的參數(shù)被聲明為屬性。同類元一樣，信號間可以有泛化關系，信號可以是其他信號的子信號，它們繼承父信號的參數(shù)，并且可以觸發(fā)依賴于父信號的轉換（如圖6–1所示）。

2.調(diào)用事件

UML狀態(tài)機視圖事件中調(diào)用事件是一個對象對調(diào)用的接收，這個對象用狀態(tài)的轉換而不是用固定的處理過程實現(xiàn)操作。對調(diào)用者來說，普通的調(diào)用（用方法實現(xiàn)的調(diào)用）不會被調(diào)用事件所辨別。接收者不是用方法來實現(xiàn)操作就是觸發(fā)一個狀態(tài)轉換來實現(xiàn)這個操作。操作的參數(shù)即事件的參數(shù)。一旦調(diào)用的接收對象通過由事件觸發(fā)的轉換完成了對調(diào)用事件的處理或調(diào)用失敗而沒有進行任何狀態(tài)轉換，則控制返回到調(diào)用對象。不過，與普通的調(diào)用不同，調(diào)用事件的接收者會繼續(xù)它自己的執(zhí)行過程，與調(diào)用者處于并行狀態(tài)。

3.修改事件

UML狀態(tài)機視圖事件中修改事件是依靠特定屬性值的布爾表達式所表示的條件的滿足。這是等到特定條件被滿足的一種聲明途徑，但是一定要小心使用它，因為它表示了一種具有時間持續(xù)性的并且可能是涉及全局的計算過程（是一種遠距離的動作，因為被測試的值可能是遠距離的）。這既有好處也有壞處，它的好處在于它將模型集中在真正的依賴關系上—一種當給定條件被滿足時發(fā)生的作用—而不是集中在測試條件的機制上。缺點在于它使修改系統(tǒng)潛在值和最終效果的活動之間的因果關系變得模糊了。測試修改事件的代價可能很大，因為原則上修改事件是持續(xù)不斷的。而實際上，又存在著避免不必要的計算的方法。修改事件應該僅用在當一個具有更明確表達形式的通信形式顯得不自然時。

請注意監(jiān)護條件與修改事件的區(qū)別。監(jiān)護條件只是在引起轉換的觸發(fā)器事件觸發(fā)時和事件接收者對事件進行處理時被賦值一次。如果它為假，那么轉換將不會被激發(fā)，條件也不會被再賦值。而修改事件被多次賦值直到條件為真，這時轉換也會被激發(fā)。

4.時間事件

UML狀態(tài)機視圖事件中時間事件代表時間的流逝。時間事件既可以被指定為絕對形式（天數(shù)），也可以被指定為相對形式（從某一指定事件發(fā)生開始所經(jīng)歷的時間）。在高層模型中，時間事件可以被認為是來自整個世界的事件；在實現(xiàn)模型中，它們由一些特定對象的信號所引起，這些對象既可能是也可能是應用中的對象。
 

【編輯推薦】

1. 深入學習UML狀態(tài)機視圖用法
2. UML狀態(tài)機視圖解析
3. 揭秘UML狀態(tài)機視圖中的四大事件
4. ***UML建模工具的選擇標準解析
5. 解析UML狀態(tài)機視圖狀態(tài)和轉換