從實(shí)例開始談狀態(tài)圖的使用

                                                               2005119@gmail.com

                                                              v1.0 2006-03-15

摘要：在對“靚號租用”項(xiàng)目的重構(gòu)中，我通過狀態(tài)圖很好的理解了業(yè)務(wù)邏輯。由此進(jìn)一步歸納了狀態(tài)圖在開發(fā)過程中的使用提示和技巧。

關(guān)鍵詞：UML，狀態(tài)圖，重構(gòu)

讀者水平：初級

引言

“靚號租用”是原無線技術(shù)部門開發(fā)GLSMRPIDService中的一個(gè)部分，由于這部分存在已的功能缺陷，需要對之進(jìn)行適當(dāng)?shù)男薷模ㄟ^這種方式來使功能得到完善并使版本得到演進(jìn)。我先給出當(dāng)前需求，對對象“靚號”的狀態(tài)圖。

按圖說圖圖（1）描述了對象“靚號”在其生命期中的幾個(gè)狀態(tài)，“靚號”能被鎖定，被鎖定的“靚號”不能被其它用戶再鎖定。被鎖定的靚號如果在15分鐘內(nèi)沒被用戶租用，則還回到初始狀態(tài)，可以再被（其他）用戶鎖定。被鎖定的“靚號”可以被租用，租用到期后能被系統(tǒng)預(yù)留（即為先前的用戶保護(hù)起來），預(yù)留一個(gè)月后如用戶未續(xù)租，則此“靚號”可以被其他人鎖定或租用。在租用狀態(tài)下的“靚號”，如果被同一用戶累積租用超過半年，則可以買斷。被買斷后，此“靚號”變成普通號。

概念

很遺憾，原設(shè)計(jì)由于所面對的問題領(lǐng)域規(guī)模小，所以并沒有采用OOD/OOP的方式，所以看不到類 CCoolIdentity這樣的實(shí)體類，但由于問題領(lǐng)域所處理的對象即為“靚號”，因此，這里先引入這個(gè)類。這里，插入狀態(tài)圖使用的第一個(gè)準(zhǔn)則：

因此，狀態(tài)圖并不為多個(gè)對象之間的行為建模。多個(gè)對象之間的行為建模參考“活動圖”，“時(shí)序圖”，對象之間的關(guān)系參考“類圖”，“對象圖”以及參考設(shè)計(jì)模式(設(shè)計(jì)模式通常用UML或Booch圖表示類之間的關(guān)系, Booch是UML的前身)。現(xiàn)在我們給出狀態(tài)圖的定義。

    狀態(tài)圖，全稱為狀態(tài)機(jī)視圖(state machine view)，通過對每個(gè)類的生個(gè)對象形字的生命期建模，描述了對象在時(shí)間上的動態(tài)行為。狀態(tài)圖用于對模型元素的動態(tài)行為進(jìn)行建模，更具體地說，就是對系統(tǒng)行為中受事件驅(qū)動的方面進(jìn)行建模。

  狀態(tài)圖由狀態(tài)組成，各狀態(tài)由轉(zhuǎn)移鏈接在一起。狀態(tài)是對象執(zhí)行某項(xiàng)活動或等待某個(gè)事件時(shí)的條件。轉(zhuǎn)移是兩個(gè)狀態(tài)之間的關(guān)系，它由某個(gè)事件觸發(fā)，然后執(zhí)行特定的操作或評估并導(dǎo)致特定的結(jié)束狀態(tài)。圖 (2) 描繪了狀態(tài)圖的各種元素。

態(tài)是對象執(zhí)行某項(xiàng)活動或等待某個(gè)事件時(shí)的條件。對象可能會在有限的時(shí)間長度內(nèi)保持某一狀態(tài)。狀態(tài)具有以下幾項(xiàng)特征：

如圖 (2) 所示，可以為對象的狀態(tài)圖定義兩種特殊的狀態(tài)。初始狀態(tài)指示狀態(tài)圖或子狀態(tài)的默認(rèn)起始位置。

何時(shí)需要狀態(tài)圖

在實(shí)際的項(xiàng)目開發(fā)中，并不是對每一個(gè)類都畫狀態(tài)圖。何時(shí)需要狀態(tài)圖，我們可以采用下面的原則來確定：

敏捷建模( AM) ( Ambler 2002)的原則－－最大化項(xiàng)目干系人的投資－－建議你只有當(dāng)模型能夠提供正面價(jià)值的時(shí)候才創(chuàng)建模型。 如果一個(gè)實(shí)體，比如一個(gè)類或組件，表示的行為的順序和當(dāng)前的狀態(tài)無關(guān)，那么畫一個(gè)UML狀態(tài)圖可能是沒有什么用處的。例如一個(gè)CLogFile類就很簡單，表示了那些你將會在系統(tǒng)中記錄一操作的數(shù)據(jù)，因此一個(gè)UML狀態(tài)圖就沒有任何相關(guān)之處。而“靚號”這類對象就經(jīng)比較的復(fù)雜。

提示與技巧

l         當(dāng)給定一項(xiàng)選擇時(shí)，要使用狀態(tài)圖的可視語義，而不要寫出詳細(xì)的轉(zhuǎn)移代碼。例如，不要用幾個(gè)信號觸發(fā)一個(gè)轉(zhuǎn)移，然后使用詳細(xì)代碼來管理以不同的方式依賴于信號的控制流。應(yīng)使用由單獨(dú)的信號來觸發(fā)的單獨(dú)轉(zhuǎn)移。在隱藏了附加行為的轉(zhuǎn)移代碼中，要避免使用條件邏輯。

l         根據(jù)在狀態(tài)期間等待的事件或正在發(fā)生的事件來命名狀態(tài)。記住，狀態(tài)不是“時(shí)間點(diǎn)”；它是狀態(tài)圖等待某個(gè)事件發(fā)生的時(shí)間段。例如，“waitingForEnd”這一名稱比“end”更好；“timingSomeActivity”比“timeout”更好。不要讓狀態(tài)的名稱看起來象是操作名。

l         在一個(gè)狀態(tài)圖內(nèi)唯一地命名所有狀態(tài)和轉(zhuǎn)移；這將便于進(jìn)行源級別的調(diào)試。

l         謹(jǐn)慎使用狀態(tài)變量；不要在創(chuàng)建新狀態(tài)時(shí)使用它們。如果狀態(tài)不多，很少帶有或不帶有依賴于狀態(tài)的行為，并且很少有或根本沒有可能與包含狀態(tài)圖的封裝體并行或獨(dú)立的行為，就可以使用狀態(tài)變量。如果有復(fù)雜的、依賴于狀態(tài)的潛在并行行為，或者如果必須處理的事件可能來自于包含狀態(tài)圖的封裝體之外，則應(yīng)考慮使用構(gòu)件封裝體。

l         如果單個(gè)圖中的狀態(tài)超過 5 * 2 個(gè)，就應(yīng)考慮使用子狀態(tài)。在這里可以應(yīng)用我們的常識：在一個(gè)非常規(guī)則的模式中可以有十個(gè)狀態(tài)，但如果兩個(gè)狀態(tài)之間具有四十個(gè)轉(zhuǎn)移，顯然就需要重新考慮了。務(wù)必要使?fàn)顟B(tài)圖易于理解。

l         使用觸發(fā)事件的事件和/或在轉(zhuǎn)移期間發(fā)生的事件為轉(zhuǎn)移命名。選擇更加易于理解的名稱。

l         當(dāng)您看見一個(gè)選擇點(diǎn)時(shí)，應(yīng)考慮是否可以將作出該選擇的職責(zé)委托給另一個(gè)構(gòu)件，以便將其作為一組將不同的信號提供給封裝體遵照執(zhí)行（例如，代替對消息->數(shù)據(jù) > x 的選擇），并考慮是否可以讓發(fā)送方或另一中間主角來作出決定，然后通過在信號名稱中明確顯示該決定的方式發(fā)送信號（例如，使用名為 isFull 和 isEmpty 的信號，而不是以值命名信號并檢查消息數(shù)據(jù)）。

l         為在選擇點(diǎn)中回答的問題指定描述性的名稱，例如“isThereStillLife”或“isItTimeToComplain”。

l         在任何給定的封裝體中，盡量使選擇點(diǎn)名稱保持唯一（其原因與轉(zhuǎn)移名稱需保持唯一相同）。

l         轉(zhuǎn)移的代碼段是否太長？是否應(yīng)使用函數(shù)來代替它們，是否將常用代碼段記錄為函數(shù)？轉(zhuǎn)移應(yīng)該類似于高層的偽代碼，并且應(yīng)當(dāng)遵循與 C++ 函數(shù)相同或更嚴(yán)格的長度規(guī)則。例如，代碼超過 25 行的轉(zhuǎn)移可被認(rèn)為是過長。

l         應(yīng)根據(jù)函數(shù)執(zhí)行的操作來命名函數(shù)。

l         要特別注意進(jìn)入和退出操作：在進(jìn)行更改后忘記更改相應(yīng)進(jìn)入和退出操作的情況尤其容易發(fā)生。

l         退出操作可用于提供安全性功能，例如，從“heaterOn”狀態(tài)中的退出操作將關(guān)閉加熱器，在這里，操作被用來強(qiáng)制執(zhí)行一個(gè)斷言語句。

l         通常，除非狀態(tài)圖是抽象的并且將由包含元素的子類來進(jìn)行改進(jìn)，否則子狀態(tài)應(yīng)包含兩個(gè)或更多個(gè)狀態(tài)。

l         應(yīng)該用選擇點(diǎn)來代替操作或轉(zhuǎn)移中的條件邏輯。選擇點(diǎn)容易被看到，而代碼中的條件邏輯則是不可見的，很容易被忽略。

l         避免使用警戒條件。

n         如果事件觸發(fā)了幾個(gè)轉(zhuǎn)移，將無法控制首先對哪個(gè)警戒條件求值。這會產(chǎn)生無法預(yù)料的結(jié)果。

n         可能有多個(gè)警戒條件為“True”，但隨后只能有一個(gè)轉(zhuǎn)移。所選擇的路徑是無法預(yù)料的。

n         警戒條件是不可見的；要“看見”它們的出現(xiàn)更是困難。

n         避免使用類似流程圖的狀態(tài)圖。

u       這可能表示您試圖對并不實(shí)際存在的抽象概念進(jìn)行建模，例如：

u       使用一個(gè)封裝體來對最適合于數(shù)據(jù)類的行為進(jìn)行建模，或

n         通過使用緊密耦合的數(shù)據(jù)類和封裝體類來對數(shù)據(jù)類建模（例如，數(shù)據(jù)類用于向四周傳遞類型信息，但封裝體類包含了應(yīng)與數(shù)據(jù)類相關(guān)聯(lián)的大部分?jǐn)?shù)據(jù)）。

u       狀態(tài)圖的這種錯誤用法可以通過以下故障現(xiàn)象來識別：

u       被發(fā)送給“自己”的消息，主要是為了重復(fù)使用代碼

u       幾乎沒有狀態(tài)，但有很多選擇點(diǎn)

u       在某些情況下沒有循環(huán)的狀態(tài)圖。在流程控制應(yīng)用程序中，或者在試圖控制一個(gè)事件序列時(shí)，這樣的狀態(tài)圖是有效的；如果它們在分析過程中出現(xiàn)，則表示狀態(tài)圖已退化為流程圖。

n         當(dāng)發(fā)現(xiàn)問題時(shí)，應(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)是那種只有變換進(jìn)來但沒有任何變換發(fā)出的狀態(tài)，這種情況要么由于該狀態(tài)是一個(gè)最終狀態(tài)，要么就是你已經(jīng)錯過了一個(gè)或多個(gè)變換變換。

l         避免"奇跡"狀態(tài)。

n         奇跡狀態(tài)是那種只有變換發(fā)出但沒有任何變換進(jìn)來的狀態(tài)，這種情況要么由于該狀態(tài)是一個(gè)起點(diǎn)，要么就是你已經(jīng)錯過了一個(gè)或多個(gè)變換變換。

參考文獻(xiàn)

       《UML用戶手冊》

     “Rational Unified Process”

     其它網(wǎng)絡(luò)資源