UML動態建模機制詳解
UML動態建模機制你是否熟悉，這里和大家分享一下UML動態建模機制方面的知識，相信通過本節的介紹你對UML動態建模機制一定會有全面的認識。下面就是詳細介紹。
UML動態建模機制軟件工程
UML動態模型包括狀態模型、順序模型、協作模型和活動模型，通常以狀態圖、順序圖、協作圖和活動圖來表示。其中，順序圖和協作圖通常合起來稱為交互圖。狀態模型關注一個對象的生命周期內的狀態及狀態變遷，以及引起狀態變遷的事件和對象在狀態中的動作等。順序模型和協作模型強調對象間的合作關系，通過對象間的消息傳遞以完成系統的用例。活動圖用于描述多個對象在交互時采取的活動，它關注對象如何相互活動以完成一個事務。
一、消息
在面向對象技術中，對象間的交互是通過對象間消息的傳遞來完成的。在UML的4個動態模型中均用到消息這個概念。通常，當一個對象調用另一個對象中的操作時，即完成了一次消息傳遞。當操作執行后，控制便返回到調用者。對象通過相互間的通信(消息傳遞)進行合作，并在其生命周期中根據通信的結果不斷改變自身的狀態。在UML中，消息的圖形表示是用帶有箭頭的線段將消息的發送者和接收者聯系起來，箭頭的類型表示消息的類型。
UML定義的消息類型有三種：
(1)簡單消息(simplemessage)表示簡單的控制流。用于描述控制如何在對象間進行傳遞，而不考慮通信的細節。
(2)同步消息(synchronousmessage)表示嵌套的控制流。操作的調用是一種典型的同步消息。調用者發出消息后必須等待消息返回，只有當處理消息的操作執行完畢后，調用者才可繼續執行自己的操作。
(3)異步消息(asynchronousmessage)表示異步控制流。調用者發出消息后不用等待消當息的返回即可繼續執行自己的操作。異步消息主要用于描述實時系統中的并發行為。
可以將一個簡單消息和一個同步消息合并成一個消息，原同步消息的箭頭和簡單消息的箭頭分別放在合并后的消息兩端。這樣的消息意味著操作調用一旦完成就立即返回。
二、順序圖
UML動態建模機制中順序圖用來描述對象之間動態的交互關系，著重體現對象間消息傳遞的時間順序。順序圖存在兩個軸：水平軸表示不同的對象，垂直軸表示時間。在順序圖中，對象用一個帶有垂直虛線的矩形框表示，在矩形框內標有對象名和類名。垂直虛線稱為對象的生命線，代表在對象之間的交互作用中該對象的生命期。在生命線上的窄矩形條被稱作激活(activation)，表示該對象正在執行某個操作。激活矩形的長度表示計劃的持續時間，既可以直接執行，也可以通過下級過程執行。矩形條的頂部表示動作的開始，底部表示動作的結束。兩根對象的生命線之間的箭頭表示消息。消息的箭頭形狀指明消息的類型是發送還是返回。消息按發生的時間順序從上到下排列。每個消息旁標注消息名，也可加上參數并標注一些控制信息。返回自身生命線的消息箭頭叫回授(selfcall)，表示對象發送消息給自己。
控制信息由兩種。***種是條件控制信息，說明在什么情況下才會發送信息(例如，在[needsToReorder()=true]的條件下)，消息僅當條件為真時才會被發送。第二種是重復控制信息，表示消息多次發送給多個作為接收者的對象。這種控制信息通常在當一個對象向某個對象集合中的每一個對象逐個地發送消息時使用(例如*prepare())。
交互圖是一種非常簡單扼要的可視化圖解，這也正是交互圖的優勢。同時也可看到，順序圖比較適合交互規模較小的可視化圖解，如果對象很多，交互又很頻繁，則會使順序圖變得復雜起來，這是順序圖的一個弱點。在順序圖中可以使用返回(return)消息，表示從消息處理中返回，而不是一個新消息。為了畫圖清晰，經常將返回消息省略掉。一般的對象放在圖的頂部，但還有一種特殊的消息new是創建一個對象消息，由于該消息而創建的對象放在圖中中間位置合適的地方。在面向對象程序設計中，總體的控制流程往往是難以理解的。一個好的設計應當將很多小方法放入不同的類中，并且隨時能巧妙地指出總體的行為順序，這樣可以十分有效地幫助你加速了解代碼。對于***接觸面向對象程序設計的人來說尤其是如此，順序圖可以幫助你看清行為的次序。
三、協作圖
UML動態建模機制中交互圖的第二種形式是協作圖。協作圖也是用來描述對象與對象之間的消息連接關系的，但是它更側重于說明哪些對象之間有消息傳遞，而不像順序圖那樣側于在某種特定的情形下對象之間傳遞消息的時序性。在協作圖中，對象同樣是用一個對象圖符號來表示，箭頭表示消息發送的方向，而消息的執行順序則由消息的編號來標明。
與順序圖中從上而下的生命線相比，通過編號來看消息執行的時間順序顯然要困難得多。但是，協作圖中對象間靈活的空間布局使我們可以更方便地展示另外一些有用信息，不同的軟件工程師可能偏好不同形式的交互圖。例如，有些人喜歡使用順序圖，因為順序圖突出使用執行的時序，能更方便地看出事情發生的次序；有些人更喜歡協作圖，因為協作圖的布局方法能更清楚的表示出對象之間靜態的連接關系。那么如何選擇呢？一個最基本的原則是用哪種圖更簡明清楚，則選用哪種圖。
四、狀態圖
UML動態建模機制中狀態圖(StateDiagram)用來描述一個特定對象的所有可能狀態及其引起狀態轉移的事件。大多數面向對象技術都用狀態圖表示單個對象在其生命周期中的行為。一個狀態圖包括一系列的狀態以及狀態之間的轉移。所有對象都具有狀態，狀態是對象執行了一系列活動的結果。當某些事情發生后，對象的狀態將發生變化，稱改變對象狀態的事情為“事件”，狀態圖用來顯示對象對事件的反應以及對象狀態的改變。狀態圖中定義的狀態有初態、終態、中間狀態和復合狀態。其中，初態是狀態圖的起始點，而終態則是狀態圖的終點。一個狀態圖只能有一個初態，而終態則可以有多個。初態用一個黑圓點表示，終態用黑圓點外加一個圓表示(很像一只牛眼)。狀態圖中的狀態用一個圓角四邊形表示。狀態之間為狀態轉換，用一條帶箭頭的線表示。引起狀態轉換的事件可以用狀態轉換線旁邊的標簽表示。當事件發生時，狀態轉換開始。
一個狀態一般包含三個部分，***部分為狀態的名稱；第二部分為可選的狀態變量的變量名和變量值，這部分是可選的；第三部分為可選的活動表，列出有關事件和活動。在活動表中，常常使用下面三種標準事件即entry(進入)、exit(退出)和do(做)。entry事件用來指定一個狀態的活動，exit事件用來指定退出一個狀態的活動，do事件用來指定在該狀態下的活動。
活動部分的語法如下：
事件參數表“/”活動表達式
事件可以是任何事件，包括上述3種標準事件?；顒颖磉_式用來指定應該進行何種活動。有時還需要為事件指定一些參數。
狀態圖中狀態之間帶箭頭的連線被稱為轉移。狀態的變遷通常是由事件觸發的，此時應在轉移上標出觸發轉移的事件表達式。如果轉移上未標明事件，則表示在源狀態的內部活動執行完畢后自動觸發轉移。
轉移的語法表示如下：
事件說明[守衛條件]/動作表達式
其中，事件說明的語法為：事件名{參數}
守衛條件是狀態轉移的一個布爾表達式。如果將守衛條件和事件說明放在一起使用，則當且僅當事件發生且布爾表達式成立時狀態才發生轉移。如果狀態轉移只有守衛條件這一個條件，則只要守衛條件為真，狀態就發生轉移。動作表達式是一個過程表達式，當狀態轉移開始時執行。轉移中使用的術語是“動作”，而在狀態中使用的術語是“活動”。盡管它們都是一種過程，都是由對象中的方法實現，但是處理它們的方式有所不同。動作與轉移關聯，能被極快處理且不會被中斷?；顒雍蜖顟B關聯，持續時間長且可以被一些事件中斷。
轉移中的事件表示輸入，當狀態中的活動完成后，并且當相應的輸入事件發生時，轉移才會發生。有的轉移上沒有標明引發轉移的條件的事件，則表示狀態中的活動一旦完成，轉移不需要等待任何輸入，便立即發生轉移。
“空閑”狀態，把狀態變量timer的值置為0，然后遞增timer的值，直到“上行”或“下行”事件發生或守衛條件“timer=超時值”為真，觸發狀態轉換。
狀態圖適合于描述跨越多個用例的單個對象的行為，而不適合于描述多個對象之間的狀態圖確實有用，但不要對系統中的每個類都畫出它的狀態圖。從理論上講，如果能刻畫每個類的狀態圖，就可以準確描述每個類的動態行為。但是這樣要花費大量精力，而且也沒有必要。事實上，我們關心的是某些關鍵類的行為，為此為這些類建立狀態圖可以
幫助我們理解所研究的問題，在這種情況下才有必要繪制狀態圖。
五、活動圖
UML動態建模機制中活動圖顯示動作及其結果，著重描述操作實現中所完成的工作以及用例實例或對象中的活動?；顒訄D是狀態圖的一個變種，與狀態圖的目的有一些小的差別?；顒訄D的主要目的是描述動作(執行的工作或活動)以及對象狀態改變的結果。當狀態中的動作被執行時(不象正常的狀態圖，它不需指定任何事件)，活動圖中的狀態(稱作動作狀態)直接轉移到下一階段。活動圖和狀態圖的另一個區別是活動途中的動作可以放到泳道中去。泳道聚合一組活動，并指定負責人和所屬組織?；顒訄D是另一種描述交互的方式，描述采取何種動作，做什么(對象狀態改變)，何時發生(動作序列)，以及在何處發生(泳道)。
活動圖可以用作下列目的：
(1)描述成操作執行過程中(操作實現的實例化)所完成的工作(動作)，這是活動圖最常用的用途。
(2)描述對象內部工作。
(3)顯示如何執行一組相關的動作，以及這些動作如何影響它們周圍的對象。
(4)顯示用例的實例是如何執行動作以及改變對象狀態的。
泳道將一個活動圖中的活動狀態分組，每一組表示負責那些活動的業務組織。尤其當你對業務過程的工作流建模時，泳道是很有用的。在UML中，每個組被稱為一個泳道，因為從視覺上，每組用一條垂直實線把它與鄰居分開，一個泳道說明一個活動軌跡。
每個泳道在圖中都有一個唯一的名稱。泳道除了可能代表現實世界的某些實體之外，實際上沒有很深的語義。每個泳道代表一個活動圖的全部活動中部分活動的高層職責，并且每個泳道最終可能由一個或多個類實施。在一個被劃分為泳道的活動圖中，每個活動都明確地屬于一個泳道，而轉移可以跨越泳道。
【編輯推薦】
- 深入剖析UML動態建模機制中的四種動態模型
- UML動態建模機制專家解析
- UML動態建模中合作圖和活動圖解析
- L建模過程中需要注意要點專家提醒
- 體驗免費UML建模工具
