UML建模風格之狀態圖 |
| 作者：axing譯 來源：LinuxAid http://www.csai.cn 2006年1月18日 |
UML狀態圖描述一個實體基於事件反應的動態行爲，顯示了該實體如何根據當前所處的狀態對不同的時間做出反應的。通常我們創建一個UML狀態圖是爲了以下的研究目的：研究類、角色、子系統、或組件的複雜行爲。建模實時系統。
通用準則
當行爲的改變和狀態有關時才創建狀態圖。
敏 捷建模( AM) ( Ambler 2002)的原則－－最大化項目干係人的投資－－建議你只有當模型能夠提供正面價值的時候才創建模型。 如果一個實體，比如一個類或組件，表示的行爲的順序和當前的狀態無關，那麼畫一個UML狀態圖可能是沒有什麼用處的。例如一個 SurfaceAddress類就很簡單，表示了那些你將會在系統中顯示和操作的數據，因此一個UML狀態圖就沒有任何相關之處。而一個Seminar對 象就非常的複雜，學生註冊這樣一個事件將會根據它的當前狀態有不同的反應，就像你在圖１中看到的。
圖⒈班級註冊的一個UML狀態圖。
把初始狀態放置在左上角。
如你在圖１所見的，初始狀態被建模成一個實心圈，把初始狀態放在左上角反映西方人的閱讀文化的習慣。
把最終狀態放置在右下角。
如你在圖１所見，最終狀態被建模爲一個帶邊界的實心圓。把最終狀態放右下角反映了西方的文化的從左到右，從上到下的閱讀習慣。
狀態指南
狀態是一個實體的行爲模式的某個階段。 狀態的表示是通過實體的屬性值。 例如，在圖１中，當seminar被標記爲open，並且存在空位的時候，seminar就處於Open For Enrollment的狀態。
狀態名稱要簡單但應具有描述性。
象Open For Enrollment和Proposed這種的狀態名稱很容易理解，從而提高了圖⒈的溝通價值。理論上狀態名稱應該是現在時，但是用過去式寫成的諸如Proposed的名稱要比用現在時寫成的諸如Is Proposed的名稱好的多。
避免"黑洞"狀態。
黑洞狀態是那種只有變換進來但沒有任何變換髮出的狀態，這種情況要麼由於該狀態是一個最終狀態，要麼就是你已經錯過了一個或多個變換變換。
避免"奇蹟"狀態。
奇蹟狀態是那種只有變換髮出但沒有任何變換進來的狀態，這種情況要麼由於該狀態是一個起點，要麼就是你已經錯過了一個或多個變換變換。
子狀態建模指南
爲複雜的目標建模子狀態。
圖１中展示的UML狀態圖是不完整的，因爲它沒有建模Seminar的post - enrollment（註冊後）狀態。 圖２建模了一個Seminar的完整的生命週期，把圖１描述爲一個新的包括子狀態集合的Enrollment的複合狀態，也稱作超狀態。 注意按理說你會像圖１的模型那樣處理標記，但爲了簡化起見在原先變換上的標記都沒有包括在內。當一個現有狀態表現出複雜的行爲時，建模子狀態就是有意義的，從而促使你來研究它的子狀態。 當幾個現有狀態共用一個通用的入口條件或出口條件( Douglass 1999)時，引入超狀態是有意義的，在圖１中你可以看到所有的狀態共用一個通用的closed變換，以到達最終狀態。
圖⒉Seminar的完整生命週期
把通用的子狀態變換放在一起
和圖１中每一個子狀態都擁有一個cancelled變換不同，在圖２中你可以看到cancelled變換僅用於描述Enrollment超狀態，這使圖形得到簡化。 如果子狀態都共享一個入口變換或出口變換，都可以使用一個同樣的方法。 變換上的警戒點和動作（如果有）也應該使相等的。
爲複雜的實體創建一個分層的狀態圖
雖然這種表現子狀態的方法是很好使的，但是最終的圖可能變得相當複雜－－我們只要設想一下如果Being Taught狀態也有子狀態的話，圖２會變成什麼樣就知道了。 一個替代的方法是創建一個分層的UML狀態圖。 例如，圖３表示高階視圖，而圖１描述了一個細節視圖。這種方法的好處是如果需要的話，馬上就可以建立一張詳圖來研究Being Taught狀態。
圖⒊Seminar的高階狀態圖。
最高階的狀態圖總有初始態和最終態
一個高階的UML狀態圖，例如圖2描述的這樣，應該表示實體的完整的生命週期，包括"出生"和最後的"死亡"。 低階的圖未必包含初始狀態和最終狀態，特別是那些建模一個實體的生命週期的"中間狀態"的圖。
變換和動作
變換是從一種狀態到另一種狀態的序列，它可能是通過一個事件觸發的。簡而言之就是被建模的實體的內部或外部的行爲。 對一個類來說，變換一般是將會導致狀態的重要改變的操作調用的結果，因此我們需要了解一點，並不是所有的方法調用都會導致變換產生的，這一點非常重要。 一個動作就是某個東西，對類來說就是一個操作，被建模的實體所調用的操作。
用實現語言的命名規則命名軟件動作
圖１中的動作遵循Java操作的命名規則( Vermeulen et. 2000)，因爲系統使用
用敘述性文字命名角色動作
UML狀態圖可用於建模非軟件實體的生命週期，特別是UML圖上的角色。 例如學生角色就可能有諸如Accepted、Full Time、Part Time、Graduated、Masters、Doctoral、和Post - Doctoral等狀態，以顯示各人的不同行爲。 當你在建模現實世界的角色時，與軟件中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之類的描述就是不一致，而且難於理解的。
