狀態(tài)圖及狀態(tài)表在軟件建模中的適用場景分析

姚紅巖，李佳琦，馬云吉

（遼寧科技大學(xué) 遼寧 鞍山 114051）

1 引言

2 刻畫狀態(tài)遷移的兩種手段

通過狀態(tài)的變化來考量對象的屬性數(shù)據(jù)集合、評估對象的行為是最為細微全面的[1，2]。在軟件建模范疇，針對某級別的對象為其進行狀態(tài)建模，是全面把握對象行為的關(guān)鍵。目前在工程領(lǐng)域，為對象進行狀態(tài)建模時，狀態(tài)圖和狀態(tài)表是兩種常見手段[3-7]。如何選用這兩種手段將關(guān)乎到設(shè)計思想的清晰表達以及模型的代碼轉(zhuǎn)化，目前在這方面鮮有分析。本文通過一個電梯模擬系統(tǒng)的驗證，對這兩種手段進行分析，探討在不同場景下，狀態(tài)圖和狀態(tài)表哪個更利于設(shè)計。

形式化的有限狀態(tài)機在模型上可定義為四元組：M ={S，S0，X，Transition}。S是一個對象的有限狀態(tài)集合；S0∈S，是初始狀態(tài)；X是對象的有限事件的集合；Transition：S*X→S是狀態(tài)轉(zhuǎn)移函數(shù)。

2.1 狀態(tài)圖

狀態(tài)圖是狀態(tài)機的一種直觀的圖形化表達，狀態(tài)圖應(yīng)至少表達出與狀態(tài)機對應(yīng)的信息，如各狀態(tài)的名稱、響應(yīng)的事件、遷移函數(shù)等。圖1的左半部分是對應(yīng)四元組的描述狀態(tài)的基本圖形，右半部分是設(shè)計模型時實際用到的簡化版本，其中“活動”即是表達狀態(tài)變化的遷移函數(shù)?！笆录?活動”表達的語義是針對某個事件，引發(fā)哪些對應(yīng)的活動。

圖3 為電梯設(shè)計的狀態(tài)轉(zhuǎn)換圖

圖1中的狀態(tài)圖在遇到復(fù)雜的狀態(tài)表達時，有兩類數(shù)據(jù)表達缺失：一是不能表達守衛(wèi)條件；二是缺少表達狀態(tài)特征的屬性數(shù)據(jù)。這兩類信息的缺失不利于設(shè)計思路的圖形化表達，往往會使整個狀態(tài)圖細化的狀態(tài)頗多，語義晦澀。改進后的基本狀態(tài)圖形如圖2所示。

圖1 圖形化的基本狀態(tài)元素

圖2 改進后的基本狀態(tài)元素

利用圖2進行狀態(tài)建模時，不必針對特征數(shù)據(jù)或者守衛(wèi)條件對狀態(tài)做過細的劃分。這能極大地減少狀態(tài)圖中基本狀態(tài)的數(shù)目，使?fàn)顟B(tài)圖更清晰、語義更流暢。

2.2 狀態(tài)表

狀態(tài)表是狀態(tài)建模的另一種形式。結(jié)合圖2的說明，定義狀態(tài)表的字段如表1所示。對應(yīng)該表的一個示例參見表2。

?

?

3 基于狀態(tài)的電梯模擬實驗

電梯是典型的需建模狀態(tài)的對象。下面將先后使用改進后的狀態(tài)圖、表對電梯系統(tǒng)進行狀態(tài)建模，然后對比兩種建模方法的適用性。

3.1 應(yīng)用狀態(tài)圖為電梯建模

建模電梯狀態(tài)的狀態(tài)圖見圖3。對圖3的說明如下：

（1）基礎(chǔ)狀態(tài)有6個，分別是movedown_straight_for_pickup（下行接人），move_up_for_dump_and_pickup（上行接/送人），idle（靜止），stop_and_open（暫停并開/關(guān)門），moveup_straight_for_pickup（上行接人），move_down_for_dump_and_pickup（下行接/送人）。

（2）以moveup_straight_for_pickup（上行接人）為例，該狀態(tài)的語義描述是：狀態(tài)名，moveup_straight_for_pickup；特征數(shù)據(jù)，“電梯方向：向上”。該狀態(tài)有兩個事件/活動，一個是：守衛(wèi)條件G1，無；活動，“向上移動一層”；守衛(wèi)條件G2，“未到達目標(biāo)樓層”；箭頭指向遷移后的狀態(tài)moveup_straight_for_pickup。另一個是：守衛(wèi)條件G1，“到達目標(biāo)樓層”；活動，“開門/關(guān)門、設(shè)定相反方向”；守衛(wèi)條件G2，無；箭頭指向目標(biāo)狀態(tài)為move_down_for_dump_and_pickup。圖3中的其它基本狀態(tài)在語義上與此類似，不贅述。

（3）初始時，電梯處于idle狀態(tài)，根據(jù)目的表是否為空，從idle狀態(tài)存在8條遷移路線：首先是目的表非空（意味著有人在轎廂內(nèi)點擊了按鈕）的情況，如首個目的樓層大于當(dāng)前樓層，則遷移至move_up_for_dump_and_pickup狀態(tài)，如小于當(dāng)前樓層則遷移至move_down_for_dump_and_pickup，如等于當(dāng)前樓層則進入狀態(tài)stop_and_open；其次是目的表為空的情況（轎廂內(nèi)沒人點擊按鈕），如有人在更高的樓層傳喚電梯且要上樓，則電梯轉(zhuǎn)入move_up_for_dump_and_pickup狀態(tài)，如有人在更低的樓層傳喚電梯且要下樓，則電梯轉(zhuǎn)入move_down_for_dump_and_pickup狀態(tài)，如有人在更高的樓層傳喚電梯并要下樓，則轉(zhuǎn)入moveup_straight_for_pickup，如有人在更低的樓層傳喚電梯并要上樓，則轉(zhuǎn)入movedown_straight_for_pickup狀態(tài)。如有人在當(dāng)前樓層傳喚電梯，則轉(zhuǎn)入stop_and_open狀態(tài)并開/關(guān)門。

（4）當(dāng)電梯處于move_up_for_dump_and_pickup和move_down_for_dump_and_pickup狀態(tài)時，在當(dāng)前移動方向上，既可以在傳喚樓層接人，也可以在目的樓層送人；但當(dāng)電梯處于moveup_straight_for_pickup和movedown_straight_for_pickup時，在到達指定傳喚樓層接人期間，如A層，中途不能再接人（因為無法預(yù)測中途進入轎廂的人它的目的樓層是高于還是低于A層），但可以在到達目的樓層時送人。

（6）如電梯處于move_up_for_dump_and_pickup狀態(tài)，在有人呼叫上行或者仍有上行目的樓層時（守衛(wèi)條件G1），要上行一層，如當(dāng)前樓層有上行傳喚要求或者目的樓層正是當(dāng)前層（守衛(wèi)條件G2），則轉(zhuǎn)入stop_and_open狀態(tài)。在stop_and_open狀態(tài)時，電梯開/關(guān)門時間是8秒，之后根據(jù)電梯當(dāng)前運行方向，如向上，則重新轉(zhuǎn)入move_up_for_dump_and_pickup狀態(tài)。如在move_up_for_dump_and_pickup狀態(tài)時，在滿足守衛(wèi)條件G1：“沒有待接送的貨物”時，自行轉(zhuǎn)入狀態(tài)idle，特征數(shù)據(jù)重置為無方向。

電梯在move_down_for_dump_and_pickup狀態(tài)與move_up_for_dump_and_pickup狀態(tài)下的行為類似，不再贅述。

3.2 應(yīng)用狀態(tài)表為電梯建模

下表2是遵照表1給出的電梯狀態(tài)的轉(zhuǎn)換表。該表清楚記錄狀態(tài)遷移時需考慮的守衛(wèi)條件和進行的活動。該表明顯沒有狀態(tài)圖直觀，不易形成電梯運行的直觀印象。對于大家都熟悉的電梯尚且如此，如果直接給出一個陌生系統(tǒng)的狀態(tài)表，要深入理解各狀態(tài)遷移的合理性將更為費力。

3.3 對狀態(tài)圖模型和狀態(tài)表模型的分析

（1）增加了守衛(wèi)條件的狀態(tài)圖，能大幅減少基本狀態(tài)的數(shù)目。（參見圖3）試想如果不在遷移箭線上注明各種守衛(wèi)條件，那么勢必要對應(yīng)這些條件細化出若干子狀態(tài)或衍生出新的狀態(tài)。整個狀態(tài)圖將涵蓋更多狀態(tài)，使得主體狀態(tài)之間的遷移路線不清晰且狀態(tài)圖很“臟”。

（2）雖然狀態(tài)圖在表達設(shè)計路線上有優(yōu)勢，但也應(yīng)注意到，箭線上的守衛(wèi)條件的性質(zhì)表達的不夠明顯，不能直觀有效地區(qū)分GC1和GC2。當(dāng)守衛(wèi)條件更復(fù)雜時，狀態(tài)遷移在語義上較為含混，不利于指導(dǎo)編碼人員有效地進行模型的代碼轉(zhuǎn)化。

（3）狀態(tài)表能清晰地指出源狀態(tài)和目標(biāo)狀態(tài)，遷移時需考量的守衛(wèi)條件GC1、GC2以及對應(yīng)的活動也是一目了然。但是，如果直接用狀態(tài)表建模，建模的思路相比于狀態(tài)圖而言，表達的不直觀、不利于設(shè)計路線的展示。同時從表2中難于體會圖3中體現(xiàn)出的設(shè)計上的對稱性，這會增加理解狀態(tài)遷移的難度。

（4）狀態(tài)表能有效指導(dǎo)模型的代碼轉(zhuǎn)化。參照表2能直接針對特定的源狀態(tài)進行編碼且在編碼時不必額外考慮狀態(tài)遷移的合理性。

綜上，在設(shè)計狀態(tài)模型時，狀態(tài)圖在表達主體狀態(tài)遷移上更有優(yōu)勢，編排良好的狀態(tài)繪圖能最大程度提升設(shè)計思路的表現(xiàn)力。而在代碼化狀態(tài)模型時，狀態(tài)表則能更有秩序地指導(dǎo)編碼意圖。

4 結(jié)語

應(yīng)用改進的基本狀態(tài)元素的圖形表達方式，可將復(fù)雜的遷移條件和活動表示在遷移路線上，這能極大地減少細粒度狀態(tài)的數(shù)目，同時能清晰表現(xiàn)主干狀態(tài)的遷移，防止出現(xiàn)子狀態(tài)。設(shè)計給出的電梯系統(tǒng)的狀態(tài)圖同時也證明了沒有子狀態(tài)的狀態(tài)圖是清晰可辨的，有設(shè)計美感。此外，根據(jù)電梯系統(tǒng)的狀態(tài)表也能得出另外一個結(jié)論：直接給出狀態(tài)表不便于設(shè)計思想的表達。狀態(tài)和遷移路線較多的狀態(tài)表，除了有利于指導(dǎo)編碼之外，在表現(xiàn)設(shè)計思路上并不適合。因此在面對狀態(tài)較多的復(fù)雜系統(tǒng)，建模狀態(tài)時應(yīng)首先使用狀態(tài)圖表現(xiàn)設(shè)計思路，在指導(dǎo)模型編碼時才應(yīng)轉(zhuǎn)化為狀態(tài)表。

[1]徐寶文，周毓明，盧紅敏.UML與軟件建模[M].清華大學(xué)出版社，2013.

[2] R o b e r t C.M a r t i n,M i c a h M a r t i n.A g i l e Principles,Patterns，and Practices in C#[M].Prentice Hall,July 2006,ISBN:0131857258.

[3] Hongyan Yao,Xuebo Sun，Han Bao.A New Notation TN for Expressing Concurrency in Program Design[J].ICIC Express Letters,2017(11)2:285-290.

[4] 劉忠，鄧蘇，沙基昌，張維明.基于狀態(tài)圖的對象行為建模[J].計算機工程與設(shè)計，2001，22(2)：9-12.

[5] Jilong CHEN，Quanli YANG，F(xiàn)ang ZHANG，Xiong WU.Research and Design of Simulative System of Elevators Based on Java[J]，Agricultural Science &Technology,2014,15(2):307-309.

[6]陳紀龍，孟洪兵，吳剛，六層電梯模擬系統(tǒng)的研究與實現(xiàn)[J].伊犁師范學(xué)院學(xué)報，2014，8(1)：57-62.

[7]陳紀龍，孟洪兵，利用OO方法實現(xiàn)電梯控制系統(tǒng)的模擬[J]，塔里木大學(xué)學(xué)報，2014，(26)1：128-132.