姚紅巖,李佳琦,馬云吉
(遼寧科技大學(xué) 遼寧 鞍山 114051)
通過狀態(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ù)。
狀態(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)圖更清晰、語義更流暢。
狀態(tài)表是狀態(tài)建模的另一種形式。結(jié)合圖2的說明,定義狀態(tài)表的字段如表1所示。對應(yīng)該表的一個示例參見表2。
?
?
電梯是典型的需建模狀態(tài)的對象。下面將先后使用改進后的狀態(tài)圖、表對電梯系統(tǒ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)下的行為類似,不再贅述。
下表2是遵照表1給出的電梯狀態(tài)的轉(zhuǎn)換表。該表清楚記錄狀態(tài)遷移時需考慮的守衛(wèi)條件和進行的活動。該表明顯沒有狀態(tài)圖直觀,不易形成電梯運行的直觀印象。對于大家都熟悉的電梯尚且如此,如果直接給出一個陌生系統(tǒng)的狀態(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)編碼意圖。
應(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.