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

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

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

1.信號(hào)事件

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

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

2.調(diào)用事件

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

3.修改事件

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

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

4.時(shí)間事件

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

【編輯推薦】

1. 深入學(xué)習(xí)UML狀態(tài)機(jī)視圖用法
2. UML狀態(tài)機(jī)視圖解析
3. 揭秘UML狀態(tài)機(jī)視圖中的四大事件
4. ***UML建模工具的選擇標(biāo)準(zhǔn)解析
5. 解析UML狀態(tài)機(jī)視圖狀態(tài)和轉(zhuǎn)換