本節(jié)和大家學習一下UML動態(tài)建模機制，主要包括消息，狀態(tài)圖，順序圖，合作圖和活動圖介紹及四種圖的運用等內容，相信通過本節(jié)的介紹你對UML動態(tài)建模機制一定會有深刻的認識。

UML動態(tài)建模機制

1.消息

在面向對象技術中，對象間的交互是通過對象間消息的傳遞來完成的。在UML的四個動態(tài)模型中均用到消息這個概念。通常，當一個對象調用另一個對象中的操作時，即完成了一次消息傳遞。當操作執(zhí)行后，控制便返回到調用者。對象通過相互間的通信進行合作，并在其生命周期中根據通信的結果不斷改變自身的狀態(tài)。
在UML中，消息的圖形表示是用帶有箭頭的線段將消息的發(fā)送者和接收者聯(lián)系起來，箭頭的類型表示消息的類型，如圖2所示。

UML定義中UML動態(tài)建模的消息類型有三種:

簡單消息表示簡單的控制流。用于描述控制如何在對象間進行傳遞，而不考慮通信的細節(jié)。
同步消息表示嵌套的控制流。操作的調用是一種典型的同步消息。調用者發(fā)出消息后必須等待消息返回，只有當處理消息的操作執(zhí)行完畢后，調用者才可繼續(xù)執(zhí)行自己的操作。
異步消息表示異步控制流。當調用者發(fā)出消息后不用等待消息的返回即可繼續(xù)執(zhí)行自己的操作。異步消息主要用于描述實時系統(tǒng)中的并發(fā)行為。

2.狀態(tài)圖

UML動態(tài)建模狀態(tài)圖用來描述一個特定對象的所有可能狀態(tài)及其引起狀態(tài)轉移的事件。大多數面向對象技術都用狀態(tài)圖表示單個對象在其生命周期中的行為。一個狀態(tài)圖包括一系列的狀態(tài)以及狀態(tài)之間的轉移。
狀態(tài)　所有對象都具有狀態(tài)，狀態(tài)是對象執(zhí)行了一系列活動的結果。當某個事件發(fā)生后，對象的狀態(tài)將發(fā)生變化。狀態(tài)圖中定義的狀態(tài)有:初態(tài)、終態(tài)、中間狀態(tài)、復合狀態(tài)。其中，初態(tài)是狀態(tài)圖的起始點，而終態(tài)則是狀態(tài)圖的終點。一個狀態(tài)圖只能有一個初態(tài)，而終態(tài)則可以有多個。
中間狀態(tài)包括兩個區(qū)域:名字域和內部轉移域，如圖3所示。圖中內部轉移域是可選的，其中所列的動作將在對象處于該狀態(tài)時執(zhí)行，且該動作的執(zhí)行并不改變對象的狀態(tài)。

一個狀態(tài)可以進一步地細化為多個子狀態(tài)，我們將可以進一步細化的狀態(tài)稱作復合狀態(tài)。子狀態(tài)之間有"或關系"和"與關系"兩種關系?；蜿P系說明在某一時刻僅可到達一個子狀態(tài)。例如，一個處于行駛狀態(tài)的汽車，在"行駛"這個復合狀態(tài)中有向前和向后兩個不同的子狀態(tài)，在某一時刻汽車要么向前，要么向后。與關系說明復合狀態(tài)中在某一時刻可同時到達多個子狀態(tài)。具有并發(fā)子狀態(tài)的狀態(tài)圖稱為并發(fā)狀態(tài)圖。

轉移　狀態(tài)圖中狀態(tài)之間帶箭頭的連線被稱為轉移。狀態(tài)的變遷通常是由事件觸發(fā)的，此時應在轉移上標出觸發(fā)轉移的事件表達式。假如轉移上未標明事件，則表示在源狀態(tài)的內部活動執(zhí)行完畢后自動觸發(fā)轉移。#p#

3.順序圖

UML動態(tài)建模順序圖用來描述對象之間動態(tài)的交互關系，著重體現(xiàn)對象間消息傳遞的時間順序。順序圖存在兩個軸:水平軸表示不同的對象，垂直軸表示時間。順序圖中的對象用一個帶有垂直虛線的矩形框表示，并標有對象名和類名。垂直虛線是對象的生命線，用于表示在某段時間內對象是存在的。對象間的通信通過在對象的生命線間畫消息來表示。消息的箭頭指明消息的類型。
順序圖中的消息可以是信號、操作調用或類似于C++中的RPC和Java中的RMI。當收到消息時，接收對象立即開始執(zhí)行活動，即對象被激活了。通過在對象生命線上顯示一個細長矩形框來表示激活。
消息可以用消息名及參數來標識。消息也可帶有順序號，但較少使用。消息還可帶有條件表達式，表示分支或決定是否發(fā)送消息。假如用于表示分支，則每個分支是相互排斥的，即在某一時刻僅可發(fā)送分支中的一個消息。
在順序圖的左邊可以有說明，用于說明消息發(fā)送的時刻、描述動作的執(zhí)行情況以及約束等。一個典型的例子就是用于說明一個消息是重復發(fā)送的。另外，可以定義兩個消息間的時間限制。
一個對象可以通過發(fā)送消息來創(chuàng)建另一個對象，當一個對象被刪除或自我刪除時，該對象用"X"標識。
另外，在很多算法中，遞歸是一種很重要的技術。當一個操作直接或間接調用自身時，即發(fā)生了遞歸。產生遞歸的消息總是同步消息，返回消息應是一個簡單消息。

4.合作圖

合作圖用于描述相互合作的對象間的交互關系和鏈接關系。雖然順序圖和合作圖都用來描述對象間的交互關系，但側重點不一樣。順序圖著重體現(xiàn)交互的時間順序，合作圖則著重體現(xiàn)交互對象間的靜態(tài)鏈接關系。
UML動態(tài)建模中合作圖對象的外觀與順序圖中的一樣。假如一個對象在消息的交互中被創(chuàng)建，則可在對象名稱之后標以。類似地，假如一個對象在交互期間被刪除，則可在對象名稱之后標以。對象間的鏈接關系類似于類圖中的聯(lián)系。通過在對象間的鏈接上標志帶有消息串的消息來表達對象間的消息傳遞。

鏈接　

鏈接用于表示對象間的各種關系，包括組成關系的鏈接、聚集關系的鏈接、限定關系的鏈接以及導航鏈接。各種鏈接關系與類圖中的定義相同，在鏈接的端點位置可以顯示對象的角色名和模板。

消息流　

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

5.活動圖

活動圖的應用非常廣泛，它既可用來描述操作的行為，也可以描述用例和對象內部的工作過程。UML動態(tài)建模中活動圖是由狀態(tài)圖變化而來的，它們各自用于不同的目的。活動圖依據對象狀態(tài)的變化來捕捉動作與動作的結果?；顒訄D中一個活動結束后將立即進入下一個活動。圖1給出了一個活動圖的例子。

活動和轉移

一項操作可以描述為一系列相關的活動?；顒觾H有一個起始點，但可以有多個結束點?；顒娱g的轉移答應帶有guard-condition、send-clause和action-expression，其語法與狀態(tài)圖中定義的相同。一個活動可以順序地跟在另一個活動之后，這是簡單的順序關系。假如在活動圖中使用一個菱形的判定標志，則可以表達條件關系，判定標志可以有多個輸入和輸出轉移，但在活動的運作中僅觸發(fā)其中的一個輸出轉移。
活動圖對表示并發(fā)行為也很有用。在活動圖中，使用一個稱為同步條的水平粗線可以將一條轉移分為多個并發(fā)執(zhí)行的分支，或將多個轉移合為一條轉移。此時，只有輸入的轉移全部有效，同步條才會觸發(fā)轉移，進而執(zhí)行后面的活動，如圖2所示。

泳道

活動圖告訴你發(fā)生了什么，但沒有告訴你該項活動由誰來完成。在程序設計中，這意味著活動圖沒有描述出各個活動由哪個類來完成。泳道解決了這一問題。它將活動圖的邏輯描述與順序圖、合作圖的責任描述結合起來。如圖2所示，泳道用矩形框來表示，屬于某個泳道的活動放在該矩形框內，將對象名放在矩形框的頂部，表示泳道中的活動由該對象負責。

對象

在活動圖中可以出現(xiàn)對象。對象可以作為活動的輸入或輸出，對象與活動間的輸入/輸出關系由虛線箭頭來表示。假如僅表示對象受到某一活動的影響，則可用不帶箭頭的虛線來連接對象與活動，如圖2所示。

信號

在活動圖中可以表示信號的發(fā)送與接收，分別用發(fā)送和接收標志來表示。發(fā)送和接收標志也可與對象相連，用于表示消息的發(fā)送者和接收者。

6.四種圖的運用

上面對UML中用于描述系統(tǒng)動態(tài)行為的四個圖做了簡單地介紹。UML動態(tài)建模中這四個圖均可用于系統(tǒng)的動態(tài)建模，但它們各自的側重點不同，分別用于不同的目的。下面對如何正確使用這幾個圖做一簡單的總結，在實際的建模過程中要根據具體情況靈活運用這些建議。
首先，不要對系統(tǒng)中的每個類都畫狀態(tài)圖。盡管這樣做很***，但太浪費精力，其實你可能只關心某些類的行為。正確的做法是:為幫助理解類而畫它的狀態(tài)圖。狀態(tài)圖描述跨越多個用例的單個對象的行為，而不適合描述多個對象間的行為合作。為此，常將狀態(tài)圖與其它技術組合使用。
順序圖和合作圖適合描述單個用例中幾個對象的行為。其中順序圖突出對象間交互的順序，而合作圖的布局方法能更清楚地表示出對象之間靜態(tài)的連接關系。當行為較為簡單時，順序圖和合作圖是***的選擇。但當行為比變復雜時，這兩個圖將失去其清楚度。因此，假如想顯示跨越多用例或多線程的復雜行為，可考慮使用活動圖。另外，順序圖和合作圖僅適合描述對象之間的合作關系，而不適合對行為進行精確定義，假如想描述跨越多個用例的單個對象的行為，應當使用狀態(tài)圖。

【編輯推薦】

1. UML動態(tài)建模機制詳解
2. 深入剖析UML動態(tài)建模機制中的四種動態(tài)模型
3. UML動態(tài)建模中合作圖和活動圖解析
4. UML建模時需要注意的四大問題
5. 解析九大UML建模圖形用法