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