從實例開始談狀態圖的使用
2005119@gmail.com
v1.0 2006-03-15
摘要：在對“靚號租用”項目的重構中，我通過狀態圖很好的理解了業務邏輯。由此進一步歸納了狀態圖在開發過程中的使用提示和技巧。
關鍵詞：UML，狀態圖，重構
讀者水平：初級
引言
“靚號租用”是原無線技術部門開發GLSMRPIDService中的一個部分，由于這部分存在已的功能缺陷，需要對之進行適當的修改，通過這種方式來使功能得到完善并使版本得到演進。我先給出當前需求，對對象“靚號”的狀態圖。
按圖說圖圖（1）描述了對象“靚號”在其生命期中的幾個狀態，“靚號”能被鎖定，被鎖定的“靚號”不能被其它用戶再鎖定。被鎖定的靚號如果在15分鐘內沒被用戶租用，則還回到初始狀態，可以再被（其他）用戶鎖定。被鎖定的“靚號”可以被租用，租用到期后能被系統預留（即為先前的用戶保護起來），預留一個月后如用戶未續租，則此“靚號”可以被其他人鎖定或租用。在租用狀態下的“靚號”，如果被同一用戶累積租用超過半年，則可以買斷。被買斷后，此“靚號”變成普通號。
概念
很遺憾，原設計由于所面對的問題領域規模小，所以并沒有采用OOD/OOP的方式，所以看不到類 CCoolIdentity這樣的實體類，但由于問題領域所處理的對象即為“靚號”，因此，這里先引入這個類。這里，插入狀態圖使用的第一個準則：
|
準則1: 狀態圖只對單一對象的復雜行為進行模建。這里的對象指類、角色、子系統、或組件。 |
因此，狀態圖并不為多個對象之間的行為建模。多個對象之間的行為建模參考“活動圖”，“時序圖”，對象之間的關系參考“類圖”，“對象圖”以及參考設計模式(設計模式通常用UML或Booch圖表示類之間的關系, Booch是UML的前身)。現在我們給出狀態圖的定義。
狀態圖，全稱為狀態機視圖(state machine view)，通過對每個類的生個對象形字的生命期建模，描述了對象在時間上的動態行為。狀態圖用于對模型元素的動態行為進行建模，更具體地說，就是對系統行為中受事件驅動的方面進行建模。
狀態圖由狀態組成，各狀態由轉移鏈接在一起。狀態是對象執行某項活動或等待某個事件時的條件。轉移是兩個狀態之間的關系，它由某個事件觸發，然后執行特定的操作或評估并導致特定的結束狀態。圖 (2) 描繪了狀態圖的各種元素。
|
圖2 |
態是對象執行某項活動或等待某個事件時的條件。對象可能會在有限的時間長度內保持某一狀態。狀態具有以下幾項特征：
|
名稱 |
將一個狀態與其他狀態區分開來的文本字符串；狀態也可能是匿名的，這表示它沒有名稱。 |
|
進入/退出操作 |
在進入和退出狀態時所執行的操作。 |
|
內部轉移 |
在不使狀態發生變更的情況下進行的轉移。 |
|
子狀態 |
狀態的嵌套結構，包括不相連的（依次處于活動狀態的）或并行的（同時處于活動狀態的）子狀態。 |
|
延遲的事件 |
未在該狀態中處理但被延遲處理（即列隊等待由另一個狀態中的對象來處理）的一系列事件。 |
如圖 (2) 所示，可以為對象的狀態圖定義兩種特殊的狀態。初始狀態指示狀態圖或子狀態的默認起始位置。
何時需要狀態圖
在實際的項目開發中，并不是對每一個類都畫狀態圖。何時需要狀態圖，我們可以采用下面的原則來確定：
敏捷建模( AM) ( Ambler 2002)的原則－－最大化項目干系人的投資－－建議你只有當模型能夠提供正面價值的時候才創建模型。 如果一個實體，比如一個類或組件，表示的行為的順序和當前的狀態無關，那么畫一個UML狀態圖可能是沒有什么用處的。例如一個CLogFile類就很簡單，表示了那些你將會在系統中記錄一操作的數據，因此一個UML狀態圖就沒有任何相關之處。而“靚號”這類對象就經比較的復雜。
l 當給定一項選擇時，要使用狀態圖的可視語義，而不要寫出詳細的轉移代碼。例如，不要用幾個信號觸發一個轉移，然后使用詳細代碼來管理以不同的方式依賴于信號的控制流。應使用由單獨的信號來觸發的單獨轉移。在隱藏了附加行為的轉移代碼中，要避免使用條件邏輯。
l 根據在狀態期間等待的事件或正在發生的事件來命名狀態。記住，狀態不是“時間點”；它是狀態圖等待某個事件發生的時間段。例如，“waitingForEnd”這一名稱比“end”更好；“timingSomeActivity”比“timeout”更好。不要讓狀態的名稱看起來象是操作名。
l 在一個狀態圖內唯一地命名所有狀態和轉移；這將便于進行源級別的調試。
l 謹慎使用狀態變量；不要在創建新狀態時使用它們。如果狀態不多，很少帶有或不帶有依賴于狀態的行為，并且很少有或根本沒有可能與包含狀態圖的封裝體并行或獨立的行為，就可以使用狀態變量。如果有復雜的、依賴于狀態的潛在并行行為，或者如果必須處理的事件可能來自于包含狀態圖的封裝體之外，則應考慮使用構件封裝體。
l 如果單個圖中的狀態超過 5 * 2 個，就應考慮使用子狀態。在這里可以應用我們的常識：在一個非常規則的模式中可以有十個狀態，但如果兩個狀態之間具有四十個轉移，顯然就需要重新考慮了。務必要使狀態圖易于理解。
l 使用觸發事件的事件和/或在轉移期間發生的事件為轉移命名。選擇更加易于理解的名稱。
l 當您看見一個選擇點時，應考慮是否可以將作出該選擇的職責委托給另一個構件，以便將其作為一組將不同的信號提供給封裝體遵照執行（例如，代替對消息->數據 > x 的選擇），并考慮是否可以讓發送方或另一中間主角來作出決定，然后通過在信號名稱中明確顯示該決定的方式發送信號（例如，使用名為 isFull 和 isEmpty 的信號，而不是以值命名信號并檢查消息數據）。
l 為在選擇點中回答的問題指定描述性的名稱，例如“isThereStillLife”或“isItTimeToComplain”。
l 在任何給定的封裝體中，盡量使選擇點名稱保持唯一（其原因與轉移名稱需保持唯一相同）。
l 轉移的代碼段是否太長？是否應使用函數來代替它們，是否將常用代碼段記錄為函數？轉移應該類似于高層的偽代碼，并且應當遵循與 C++ 函數相同或更嚴格的長度規則。例如，代碼超過 25 行的轉移可被認為是過長。
l 應根據函數執行的操作來命名函數。
l 要特別注意進入和退出操作：在進行更改后忘記更改相應進入和退出操作的情況尤其容易發生。
l 退出操作可用于提供安全性功能，例如，從“heaterOn”狀態中的退出操作將關閉加熱器，在這里，操作被用來強制執行一個斷言語句。
l 通常，除非狀態圖是抽象的并且將由包含元素的子類來進行改進，否則子狀態應包含兩個或更多個狀態。
l 應該用選擇點來代替操作或轉移中的條件邏輯。選擇點容易被看到，而代碼中的條件邏輯則是不可見的，很容易被忽略。
l 避免使用警戒條件。
n 如果事件觸發了幾個轉移，將無法控制首先對哪個警戒條件求值。這會產生無法預料的結果。
n 可能有多個警戒條件為“True”，但隨后只能有一個轉移。所選擇的路徑是無法預料的。
n 警戒條件是不可見的；要“看見”它們的出現更是困難。
n 避免使用類似流程圖的狀態圖。
u 這可能表示您試圖對并不實際存在的抽象概念進行建模，例如：
u 使用一個封裝體來對最適合于數據類的行為進行建模，或
n 通過使用緊密耦合的數據類和封裝體類來對數據類建模（例如，數據類用于向四周傳遞類型信息，但封裝體類包含了應與數據類相關聯的大部分數據）。
u 狀態圖的這種錯誤用法可以通過以下故障現象來識別：
u 被發送給“自己”的消息，主要是為了重復使用代碼
u 幾乎沒有狀態，但有很多選擇點
u 在某些情況下沒有循環的狀態圖。在流程控制應用程序中，或者在試圖控制一個事件序列時，這樣的狀態圖是有效的；如果它們在分析過程中出現，則表示狀態圖已退化為流程圖。
n 當發現問題時，應采取以下措施：
u 考慮將封裝體分解為職責更明確的小單元，
u 將更多的行為轉移到與有問題的封裝體相關聯的數據類中。
u 將更多的行為轉移到封裝體類函數中。
u 制作更有意義的信號，以避免對數據的依賴。
l 避免"黑洞"狀態。
n 黑洞狀態是那種只有變換進來但沒有任何變換發出的狀態，這種情況要么由于該狀態是一個最終狀態，要么就是你已經錯過了一個或多個變換變換。
l 避免"奇跡"狀態。
n 奇跡狀態是那種只有變換發出但沒有任何變換進來的狀態，這種情況要么由于該狀態是一個起點，要么就是你已經錯過了一個或多個變換變換。
參考文獻
《UML用戶手冊》
“Rational Unified Process”
其它網絡資源