UML狀態圖描述一個實體基于事件反應的動態行為，顯示了該實體如何根據當前所處的狀態對不同的時間做出反應的，
UML建模風格之狀態圖UML
。通常我們創建一個UML狀態圖是為了以下的研究目的：研究類、角色、子系統、或組件的復雜行為。建模實時系統。 通用準則 當行為的改變和狀態有關時UML狀態圖描述一個實體基于事件反應的動態行為，顯示了該實體如何根據當前所處的狀態對不同的時間做出反應的。通常我們創建一個UML狀態圖是為了以下的研究目的：研究類、角色、子系統、或組件的復雜行為。建模實時系統。
通用準則
當行為的改變和狀態有關時才創建狀態圖。
敏捷建模( AM) ( Ambler 2002)的原則－－最大化項目干系人的投資－－建議你只有當模型能夠提供正面價值的時候才創建模型。 如果一個實體，比如一個類或組件，表示的行為的順序和當前的狀態無關，那么畫一個UML狀態圖可能是沒有什么用處的。例如一個SurfaceAddress類就很簡單，表示了那些你將會在系統中顯示和操作的數據，因此一個UML狀態圖就沒有任何相關之處。而一個Seminar對象就非常的復雜，學生注冊這樣一個事件將會根據它的當前狀態有不同的反應，就像你在圖１中看到的。
圖⒈班級注冊的一個UML狀態圖。
javascript.:if(this.width>498)this.style.width=498;' nmousewheel = 'javascript.:return big(this)' src="http://www.ltesting.net/uploads/2007/06/8_2007061117015411.gif" width=600>
把初始狀態放置在左上角。
如你在圖１所見的，初始狀態被建模成一個實心圈，把初始狀態放在左上角反映西方人的閱讀文化的習慣。
把最終狀態放置在右下角。
如你在圖１所見，最終狀態被建模為一個帶邊界的實心圓。把最終狀態放右下角反映了西方的文化的從左到右，從上到下的閱讀習慣。
狀態指南
狀態是一個實體的行為模式的某個階段。 狀態的表示是通過實體的屬性值。 例如，在圖１中，當seminar被標記為open，并且存在空位的時候，seminar就處于Open For Enrollment的狀態。
狀態名稱要簡單但應具有描述性。
象Open For Enrollment和Proposed這種的狀態名稱很容易理解，從而提高了圖⒈的溝通價值。理論上狀態名稱應該是現在時，但是用過去式寫成的諸如Proposed的名稱要比用現在時寫成的諸如Is Proposed的名稱好的多。
避免"黑洞"狀態。
黑洞狀態是那種只有變換進來但沒有任何變換發出的狀態，這種情況要么由于該狀態是一個最終狀態，要么就是你已經錯過了一個或多個變換變換。
避免"奇跡"狀態。
奇跡狀態是那種只有變換發出但沒有任何變換進來的狀態，這種情況要么由于該狀態是一個起點，要么就是你已經錯過了一個或多個變換變換。
子狀態建模指南
為復雜的目標建模子狀態。
圖１中展示的UML狀態圖是不完整的，因為它沒有建模Seminar的post - enrollment（注冊后）狀態。 圖２建模了一個Seminar的完整的生命周期，把圖１描述為一個新的包括子狀態集合的Enrollment的復合狀態，也稱作超狀態。 注意按理說你會像圖１的模型那樣處理標記，但為了簡化起見在原先變換上的標記都沒有包括在內。當一個現有狀態表現出復雜的行為時，建模子狀態就是有意義的，從而促使你來研究它的子狀態。 當幾個現有狀態共用一個通用的入口條件或出口條件( Douglass 1999)時，引入超狀態是有意義的，在圖１中你可以看到所有的狀態共用一個通用的closed變換，以到達最終狀態。
圖⒉Seminar的完整生命周期
498)this.style.width=498;' nmousewheel = 'javascript.:return big(this)' height=270 src="http://www.ltesting.net/uploads/2007/06/8_2007061117015412.gif" width=600>
把通用的子狀態變換放在一起
和圖１中每一個子狀態都擁有一個cancelled變換不同，在圖２中你可以看到cancelled變換僅用于描述Enrollment超狀態，這使圖形得到簡化。 如果子狀態都共享一個入口變換或出口變換，都可以使用一個同樣的方法。 變換上的警戒點和動作（如果有）也應該使相等的。
為復雜的實體創建一個分層的狀態圖
雖然這種表現子狀態的方法是很好使的，但是最終的圖可能變得相當復雜－－我們只要設想一下如果Being Taught狀態也有子狀態的話，圖２會變成什么樣就知道了。 一個替代的方法是創建一個分層的UML狀態圖。 例如，圖３表示高階視圖，而圖１描述了一個細節視圖。這種方法的好處是如果需要的話，馬上就可以建立一張詳圖來研究Being Taught狀態。
圖⒊Seminar的高階狀態圖。
498)this.style.width=498;' nmousewheel = 'javascript.:return big(this)' height=309 src="http://www.ltesting.net/uploads/2007/06/8_2007061117015413.gif" width=600>
最高階的狀態圖總有初始態和最終態
一個高階的UML狀態圖，例如圖2描述的這樣，應該表示實體的完整的生命周期，包括"出生"和最后的"死亡"。 低階的圖未必包含初始狀態和最終狀態，特別是那些建模一個實體的生命周期的"中間狀態"的圖。
變換和動作
變換是從一種狀態到另一種狀態的序列，它可能是通過一個事件觸發的，
電腦資料
《UML建模風格之狀態圖UML》(http://salifelink.com)。簡而言之就是被建模的實體的內部或外部的行為。 對一個類來說，變換一般是將會導致狀態的重要改變的操作調用的結果，因此我們需要了解一點，并不是所有的方法調用都會導致變換產生的，這一點非常重要。 一個動作就是某個東西，對類來說就是一個操作，被建模的實體所調用的操作。用實現語言的命名規則命名軟件動作
圖１中的動作遵循Java操作的命名規則( Vermeulen et. 2000)，因為系統使用 用敘述性文字命名角色動作 UML狀態圖可用于建模非軟件實體的生命周期，特別是UML圖上的角色。 例如學生角色就可能有諸如Aclearcase/" target="_blank" >ccepted、Full Time、Part Time、Graduated、Masters、Doctoral、和Post - Doctoral等狀態，以顯示各人的不同行為。 當你在建�，F實世界的角色時，與軟件中Student類不同的是，狀態間的變換最好是使用敘述性文字來描述，例如drop seminar和pay fees，而不是dropSeminar ()和payFees ()，因為現實生活中的人是做事情，而不是執行操作。 只有對所有的入口變換都合適時才注明入口動作 在圖１中你可以看到Closed To Enrollment狀態的入口中操作notifyInstructor ()都是經由entry/動作標記來調用的。 這暗示著每次進入狀態時都需要調用該操作，如果你不希望每次都發生，那么就把動作關聯到特定的入口變換。 例如，addStudent ()動作是在student enrolled變換到Open For Enrollment變換發生，而在到opened變換則不會發生，這是因為每次你在進入該狀態并不需要增加一個學生。 只有對所有的出口變換適合時才注明出口動作 出口動作，用exit/標記來表示，工作方式類似于入口動作。 只有當你想終止并再進入該狀態時才建模遞歸變換 一個遞歸的變換是那些兩個端點都擁有相同狀態的變換。 一個重要的暗示是實體從狀態出來，又回到原有的狀態，因此，那些由于entry/或exit/動作標記而被調用的任何一種操作都可能被自動調用。 圖１的Open For Enrollment狀態就是這種遞歸變換的例子，因此當前班級大小就在入口處被記錄下來。 用過去式命名轉換事件 圖１中的轉換事件，例如seminar split和cancelled，是使用過去式命名的，反映了這樣一個事實：變換是事件的結果－－因為事件發生在變換之前，因此應該用過去式命名。 把轉換標記放在接近源狀態的地方 雖然圖１比較復雜，變換標記盡可能放在靠近來源的地方，例如seminar split和student enrolled。 Furthermore, the labels were justified (left and right respectively) to help visually place them close to the source state. 以轉換方向為基礎放置變換標記 為了更易于判斷哪個標記和變換是一起的，按照如下的規則來放置變換標記： 在變換線條上的從左到右。 在變換線條下的從右到左。 變換線條右邊的往下。 變換線條左邊的往上。 警戒點 一個警戒點是為了穿過一個轉換而必須為真的一個條件。 警戒點不應該重疊 離開狀態的相似變換上的警戒點必須彼此一致。 舉例來說，x <0, x = 0,以及x > 0的警戒點是一致的，而x < = 0和x > = 0的警戒點就不是一致的，因為他們重疊了，它并沒有明確的指出當x為0時將發生什么。在圖1中，你可以看到警界點的一致性，從填寫注冊表活動出發的該學生劃線變換上的警戒點沒有重疊，決策點上的警戒點也一樣。 為可視化的定位警戒點而引入接合點。 在圖２中你可以看到從Being Taught觸發student dropped事件存在兩個變換，而圖３中僅有一個，變換被合并了，因此我們需要一個接合點（填滿的圓）。 這種方法的好處是現在圖上的兩個警戒點更彼此接近了，更容易看出警戒點是否重疊。 警戒點不必配套 一個狀態的變換警戒點有可能是不完整的。例如，一個bank account對象可能從Open狀態變換到Needs Authorization狀態，這時需要一個大額存款"large deposit"的警戒點�？墒�，一個帶有"small deposit"的警戒點的deposit變換可能并不需要建模，它是被隱含的，我們遵循了AM的實踐－－簡單的描述模型和僅僅包括相關的信息。 一致的命名警戒點 圖１包含了諸如seat available和no seat available的警戒點，兩個警戒點的描述是一致的。 然而，諸如seats left、no seat left、no seats left、no seats available、seat unavailable之類的描述就是不一致，而且難于理解的。
原文轉自：http://www.ltesting.net