標準建模語言UML的動態建模機制

1. 消息


在面向對象技術中,對象間的交互是通過對象間消息的傳遞來完成的。在UML的四個動態模型中均用到消息這個概念。通常,當一個對象調用另一個對象中的操作時,即完成了一次消息傳遞。當操作執行後,控制便返回到調用者。對象通過相互間的通信(消息傳遞)進行合作,並在其生命週期中根據通信的結果不斷改變自身的狀態。


在UML中,消息的圖形表示是用帶有箭頭的線段將消息的發送者和接收者聯繫起來,箭頭的類型表示消息的類型,如圖2所示。


 

UML定義的消息類型有三種:


簡單消息(Simple Message) 表示簡單的控制流。用於描述控制如何在對象間進行傳遞,而不考慮通信的細節。
同步消息(Synchronous Message) 表示嵌套的控制流。操作的調用是一種典型的同步消息。調用者發出消息後必須等待消息返回,只有當處理消息的操作執行完畢後,調用者纔可繼續執行自己的操作。

異步消息(Asynchronous Message) 表示異步控制流。當調用者發出消息後不用等待消息的返回即可繼續執行自己的操作。異步消息主要用於描述實時系統中的併發行爲。


2. 狀態圖
狀態圖(State Diagram)用來描述一個特定對象的所有可能狀態及其引起狀態轉移的事件。大多數面向對象技術都用狀態圖表示單個對象在其生命週期中的行爲。一個狀態圖包括一系列的狀態以及狀態之間的轉移。


(1) 狀態 所有對象都具有狀態,狀態是對象執行了一系列活動的結果。當某個事件發生後,對象的狀態將發生變化。狀態圖中定義的狀態有:初態、終態、中間狀態、複合狀態。其中,初態是狀態圖的起始點,而終態則是狀態圖的終點。一個狀態圖只能有一個初態,而終態則可以有多個。

中間狀態包括兩個區域:名字域和內部轉移域,如圖3所示。圖中內部轉移域是可選的,其中所列的動作將在對象處於該狀態時執行,且該動作的執行並不改變對象的狀態。

 

一個狀態可以進一步地細化爲多個子狀態,我們將可以進一步細化的狀態稱作複合狀態。子狀態之間有"或關係"和"與關係"兩種關係。或關係(如圖4)說明在某一時刻僅可到達一個子狀態。例如,一個處於行駛狀態的汽車,在"行駛"這個複合狀態中有向前和向後兩個不同的子狀態,在某一時刻汽車要麼向前,要麼向後。與關係( 如圖5)說明覆合狀態中在某一時刻可同時到達多個子狀態(稱爲併發子狀態)。具有併發子狀態的狀態圖稱爲併發狀態圖。

 

(2) 轉移 狀態圖中狀態之間帶箭頭的連線被稱爲轉移。狀態的變遷通常是由事件觸發的,此時應在轉移上標出觸發轉移的事件表達式。如果轉移上未標明事件,則表示在源狀態的內部活動執行完畢後自動觸發轉移。


3. 順序圖


順序圖(Sequence Diagram)用來描述對象之間動態的交互關係,着重體現對象間消息傳遞的時間順序。順序圖存在兩個軸:水平軸表示不同的對象,垂直軸表示時間。順序圖中的對象用一個帶有垂直虛線的矩形框表示,並標有對象名和類名。垂直虛線是對象的生命線,用於表示在某段時間內對象是存在的。對象間的通信通過在對象的生命線間畫消息來表示。消息的箭頭指明消息的類型。


順序圖中的消息可以是信號(Signal)、操作調用或類似於C++中的RPC(RemoteProce dure Calls)和Java中的RMI(Remote Method Invocation)。當收到消息時,接收對象立即開始執行活動,即對象被激活了。通過在對象生命線上顯示一個細長矩形框來表示激活。


消息可以用消息名及參數來標識。消息也可帶有順序號,但較少使用。消息還可帶有條件表達式,表示分支或決定是否發送消息。如果用於表示分支,則每個分支是相互排斥的,即在某一時刻僅可發送分支中的一個消息。


在順序圖的左邊可以有說明信息,用於說明消息發送的時刻、描述動作的執行情況以及約束信息等。一個典型的例子就是用於說明一個消息是重複發送的。另外,可以定義兩個消息間的時間限制。


一個對象可以通過發送消息來創建另一個對象,當一個對象被刪除或自我刪除時,該對象用"X"標識。


另外,在很多算法中,遞歸是一種很重要的技術。當一個操作直接或間接調用自身時,即發生了遞歸。產生遞歸的消息總是同步消息,返回消息應是一個簡單消息。


4. 合作圖


合作圖(Collaboration Diagram)用於描述相互合作的對象間的交互關係和鏈接關係。雖然順序圖和合作圖都用來描述對象間的交互關係,但側重點不一樣。順序圖着重體現交互的時間順序,合作圖則着重體現交互對象間的靜態鏈接關係。


合作圖中對象的外觀與順序圖中的一樣。如果一個對象在消息的交互中被創建,則可在對象名稱之後標以{new}。類似地,如果一個對象在交互期間被刪除,則可在對象名稱之後標以{destroy}。對象間的鏈接關係類似於類圖中的聯繫(但無多重性標誌)。通過在對象間的鏈接上標誌帶有消息串的消息(簡單、異步或同步消息)來表達對象間的消息傳遞。


(1) 鏈接 鏈接用於表示對象間的各種關係,包括組成關係的鏈接(Composition Li nk)、聚集關係的鏈接(Aggregation Link)、限定關係的鏈接(Qualified Link)以及導航鏈接(Navigation Link)。各種鏈接關係與類圖中的定義相同,在鏈接的端點位置可以顯示對象的角色名和模板信息。


(2)

消息流 在合作圖的鏈接線上,可以用帶有消息串的消息來描述對象間的交互。消息的箭頭指明消息的流動方向。消息串說明要發送的消息、消息的參數、消息的返回值以及消息的序列號等信息(未完待續)

 

5. 活動圖(Activity Diagram)


活動圖的應用非常廣泛,它既可用來描述操作(類的方法)的行爲,也可以描述用例和對象內部的工作過程。活動圖是由狀態圖變化而來的,它們各自用於不同的目的。活動圖依據對象狀態的變化來捕獲動作(將要執行的工作或活動)與動作的結果。活動圖中一個活動結束後將立即進入下一個活動(在狀態圖中狀態的變遷可能需要事件的觸發)。圖1給出了一個活動圖的例子。

活動和轉移


一項操作可以描述爲一系列相關的活動。活動僅有一個起始點,但可以有多個結束點。活動間的轉移允許帶有guard-condition、send-clause和action-expression,其語法與狀態圖中定義的相同。一個活動可以順序地跟在另一個活動之後,這是簡單的順序關係。如果在活動圖中使用一個菱形的判斷標誌,則可以表達條件關係(見圖1),判斷標誌可以有多個輸入和輸出轉移,但在活動的運作中僅觸發其中的一個輸出轉移。


活動圖對錶示併發行爲也很有用。在活動圖中,使用一個稱爲同步條的水平粗線可以將一條轉移分爲多個併發執行的分支,或將多個轉移合爲一條轉移。此時,只有輸入的轉移全部有效,同步條纔會觸發轉移,進而執行後面的活動,如圖2所示。

泳道
活動圖告訴你發生了什麼,但沒有告訴你該項活動由誰來完成。在程序設計中,這意味着活動圖沒有描述出各個活動由哪個類來完成。泳道解決了這一問題。它將活動圖的邏輯描述與順序圖、合作圖的責任描述結合起來。如圖2所示,泳道用矩形框來表示,屬於某個泳道的活動放在該矩形框內,將對象名放在矩形框的頂部,表示泳道中的活動由該對象負責。
對象
在活動圖中可以出現對象。對象可以作爲活動的輸入或輸出,對象與活動間的輸入/輸出關係由虛線箭頭來表示。如果僅表示對象受到某一活動的影響,則可用不帶箭頭的虛線來連接對象與活動,如圖2所示。
信號
如圖3所示,在活動圖中可以表示信號的發送與接收,分別用發送和接收標誌來表示。發送和接收標誌也可與對象相連,用於表示消息的發送者和接收者。

6. 四種圖的運用
上面對UML中用於描述系統動態行爲的四個圖(狀態圖、順序圖、合作圖和活動圖)做了簡單地介紹。這四個圖均可用於系統的動態建模,但它們各自的側重點不同,分別用於不同的目的。下面對如何正確使用這幾個圖做一簡單的總結,在實際的建模過程中要根據具體情況靈活運用這些建議。


首先,不要對系統中的每個類都畫狀態圖。儘管這樣做很完美,但太浪費精力,其實你可能只關心某些類的行爲。正確的做法是:爲幫助理解類而畫它的狀態圖。狀態圖描述跨越多個用例的單個對象的行爲,而不適合描述多個對象間的行爲合作。爲此,常將狀態圖與其它技術(如順序圖、合作圖和活動圖)組合使用。


順序圖和合作圖適合描述單個用例中幾個對象的行爲。其中順序圖突出對象間交互的順序,而合作圖的佈局方法能更清楚地表示出對象之間靜態的連接關係。當行爲較爲簡單時,順序圖和合作圖是最好的選擇。但當行爲比變複雜時,這兩個圖將失去其清晰度。因此,如果想顯示跨越多用例或多線程的複雜行爲,可考慮使用活動圖。另外,順序圖和合作圖僅適合描述對象之間的合作關係,而不適合對行爲進行精確定義,如果想描述跨越多個用例的單個對象的行爲,應當使用狀態圖。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章