1 UML引入到嵌入式系統(tǒng)中的可行性

　　20世紀(jì)六七十年代，軟件產(chǎn)業(yè)遇到了危機(jī)。其原因就是軟件越來(lái)越龐大和復(fù)雜，而軟件的質(zhì)量和生產(chǎn)率卻越來(lái)越低。由此促進(jìn)了軟件工程的誕生，使得 軟件開(kāi)發(fā)的規(guī)范化和效率都得到了很大提高。在20世紀(jì)90年代，隨著面向?qū)ο蠹夹g(shù)的發(fā)展，軟件工程向自動(dòng)化、智能化方向發(fā)展，其突出的標(biāo)志就是UML標(biāo)準(zhǔn) 的出現(xiàn)與發(fā)展。隨后，很多軟硬件廠商相繼開(kāi)發(fā)出了許多基于UML標(biāo)準(zhǔn)的CASE工具。從此開(kāi)發(fā)軟件可以借助UML的CASE工具來(lái)完成從軟件的分析、設(shè) 計(jì)、實(shí)現(xiàn)到測(cè)試的一系列軟件工程過(guò)程，大大提高了軟件開(kāi)發(fā)的復(fù)用性和效率，降低了軟件開(kāi)發(fā)過(guò)程中的返工率。

　　UML突出的特點(diǎn)就是以面向?qū)ο蟮挠^點(diǎn)來(lái)分析和設(shè)計(jì)所開(kāi)發(fā)的系統(tǒng)，它把系統(tǒng)的每個(gè)功能都作為一個(gè)模塊(以“類”來(lái)表 示)。在UML中，使用用例視圖、邏輯視圖、組件視圖、并發(fā)視圖和展開(kāi)視圖來(lái)分別對(duì)軟件實(shí)現(xiàn)需求分析、設(shè)計(jì)、實(shí)現(xiàn)、集成和測(cè)試等過(guò)程;并且每個(gè)視圖都包括 一系列的圖來(lái)具體實(shí)現(xiàn)，上面的5類視圖包括了用例圖、類圖、對(duì)象圖、狀態(tài)圖、序列圖、協(xié)作圖、活動(dòng)圖、組件圖和展開(kāi)圖。其中，用例圖、類圖、對(duì)象圖、組件 圖和展開(kāi)圖屬于靜態(tài)圖，是從靜態(tài)方面對(duì)系統(tǒng)進(jìn)行分析和建模的;而狀態(tài)圖、序列圖、協(xié)作圖和活動(dòng)圖則是從動(dòng)態(tài)方面對(duì)系統(tǒng)進(jìn)行分析，模擬系統(tǒng)動(dòng)態(tài)交互情況的。

　　2001年，UML2.0的發(fā)布標(biāo)志著UML技術(shù)進(jìn)一步成熟，也得到了越來(lái)越多的硬件和軟件廠商的支持，這也使得UML的發(fā)展前景更加廣闊。面 對(duì)基于軟件工程的UML在軟件領(lǐng)域所取得的巨大成就，是否可以把UML引入到嵌入式系統(tǒng)開(kāi)發(fā)中來(lái)，用來(lái)改變當(dāng)前嵌入式系統(tǒng)開(kāi)發(fā)效率低下的局面呢?通過(guò)研究 分析發(fā)現(xiàn)，UML應(yīng)用到嵌入式系統(tǒng)主要存在以下幾個(gè)方面困難：

　?、?嵌入式系統(tǒng)包括硬件和軟件兩部分，不同廠商的硬件千差萬(wàn)別，在某個(gè)嵌入式芯片中能正確運(yùn)行的軟件在另外一個(gè)嵌入式硬件平臺(tái)上就不一定能正常運(yùn)行。

　　② 嵌入式系統(tǒng)軟件平臺(tái)也千差萬(wàn)別，各自對(duì)開(kāi)發(fā)的要求差異較大。

　?、?大部分嵌入式系統(tǒng)對(duì)實(shí)時(shí)性要求嚴(yán)格。

　?、?嵌入式平臺(tái)的軟件一般不是采用面向?qū)ο笳Z(yǔ)言開(kāi)發(fā)的，主要采用C語(yǔ)言甚至是匯編語(yǔ)言編寫。

　　所有以上這些特點(diǎn)，導(dǎo)致在實(shí)際的嵌入式系統(tǒng)中UML模型很難被構(gòu)建。即使構(gòu)建出模型，其正確性、實(shí)時(shí)性能也很難得到驗(yàn)證和保證。

　　雖然如此，各國(guó)的研究者和開(kāi)發(fā)商為把UML引入到嵌入式系統(tǒng)中都做出了不懈的努力，并取得了一些成果，主要包括：

　?、?為了使所建立模型的正確性能夠得到驗(yàn)證，有人提出采用形式化的方法。例如William和H. C. Cheng使用VHDL作為模型的形式化描述語(yǔ)言，通過(guò)分析UML模型中的類圖和狀態(tài)圖得到嵌入式系統(tǒng)的VHDL描述，確定系統(tǒng)的結(jié)構(gòu)和行為，并進(jìn)行模型 驗(yàn)證[2]。還有學(xué)者使用有限狀態(tài)自動(dòng)機(jī)與UML相結(jié)合來(lái)完成系統(tǒng)的分析、設(shè)計(jì)和驗(yàn)證[3]。

　　② 對(duì)于實(shí)時(shí)性要求，提供的解決方法主要包括： 使用標(biāo)準(zhǔn)的UML及其構(gòu)造型概念設(shè)計(jì)實(shí)時(shí)系統(tǒng)[4]，以及擴(kuò)充UML或改造UML以使其滿足實(shí)時(shí)系統(tǒng)的要求[5]。

　?、?對(duì)于語(yǔ)言的問(wèn)題，主要有以下兩種解決方法： 一種是使用面向?qū)ο蟮?a href="http://m.makelele.cn/tags/C++/" target="_blank">C++語(yǔ)言開(kāi)發(fā)，如SystemC[6];另一種是使用可以與C語(yǔ)言結(jié)合的UML開(kāi)發(fā)環(huán)境，如美國(guó)ILogix公司推出的Rhapsody。

　　由以上3種解決方案可知，UML應(yīng)用在嵌入式系統(tǒng)所產(chǎn)生的可驗(yàn)證性、實(shí)時(shí)性以及語(yǔ)言的問(wèn)題，都是可以解決的，因而有可能廣泛使用UML來(lái)分析、設(shè)計(jì)與指導(dǎo)嵌入式系統(tǒng)開(kāi)發(fā)，以解決嵌入式系統(tǒng)開(kāi)發(fā)效率低下的問(wèn)題。

　　2 一種改進(jìn)的通用嵌入式系統(tǒng)UML方案

　　由于目前對(duì)UML應(yīng)用在嵌入式系統(tǒng)中的研究往往都是側(cè)重于解決嵌入式系統(tǒng)的某一方面，因而不具有通用性，很難成為嵌入式系統(tǒng)建模的標(biāo)準(zhǔn)。為了解決UML在嵌入式系統(tǒng)中的建模問(wèn)題，本文提出了一種通用的UML嵌入式系統(tǒng)設(shè)計(jì)解決方案。

　　為了給嵌入式系統(tǒng)建模必須考慮以下方面：

　　◆ 時(shí)間。在序列圖中描述時(shí)間及其約束信息。

　　◆ 并發(fā)性。用活動(dòng)類來(lái)描述并發(fā)。活動(dòng)類的屬性(如優(yōu)先級(jí))可以定義成類的標(biāo)簽值，可通過(guò)組件版類﹤﹤Process﹥﹥和﹤﹤Thread﹥﹥將它們映射到實(shí)現(xiàn)環(huán)境中。

　　◆ 異步通信。UML支持線程間發(fā)送異步消息。

　　◆ 同步通信。定義信號(hào)量、監(jiān)視器或關(guān)鍵區(qū)的類/版類來(lái)描述同步。

　　由此，可以得出嵌入式系統(tǒng)建模的一般過(guò)程如下：

　?、?首先確定系統(tǒng)需求。在此階段既不考慮哪部分是軟件，也不考慮哪部分是硬件，只根據(jù)調(diào)研和與用戶的交流得出系統(tǒng)應(yīng)具有的功能，并通過(guò)角色與用例的關(guān)系表現(xiàn)出來(lái)，從而得出用例圖和系統(tǒng)最終需求。

　?、?進(jìn)入系統(tǒng)設(shè)計(jì)階段,也就是根據(jù)用例圖得出的需求來(lái)設(shè)計(jì)類圖。這個(gè)階段需要確定哪些功能由硬件完成，哪些功能由軟件完成。軟件類圖的設(shè)計(jì)與純軟件建模方法基 本一樣，在此不再贅述。對(duì)硬件的處理一般由硬件包裝類來(lái)實(shí)現(xiàn)，硬件包裝類提供訪問(wèn)硬件的接口。這些硬件包裝類處理到設(shè)備的通信和設(shè)備產(chǎn)生的中斷，通過(guò)這樣 的硬件類可以隱藏低級(jí)協(xié)議的細(xì)節(jié)，并且很方便、快速地將低級(jí)中斷轉(zhuǎn)換為系統(tǒng)中其余部分的高級(jí)事件。包裝類是屬于活動(dòng)的還是靜態(tài)的類，主要取決于硬件的屬 性。

　?、?如果類圖中所描述的軟件類或硬件類比較復(fù)雜，難以描述清楚，那么可以采用對(duì)象圖來(lái)細(xì)化，使之更加具體和明確。

　?、?對(duì)于實(shí)時(shí)性要求，需要在序列圖中進(jìn)行定義和描述;如果想知道不同對(duì)象之間的鏈接,以及鏈接對(duì)象間如何發(fā)送消息，可以建立協(xié)作圖;通過(guò)建立狀態(tài)圖,可以了解到某個(gè)對(duì)象所能到達(dá)的所有狀態(tài),以及對(duì)象收到的事件對(duì)該對(duì)象狀態(tài)的影響等。

　?、?最后,使用組件圖和展開(kāi)圖來(lái)實(shí)現(xiàn)系統(tǒng)的集成與驗(yàn)證。

　　以上過(guò)程可以在Rhapsody軟件環(huán)境下實(shí)現(xiàn)，因?yàn)樵撥浖梢援a(chǎn)生嵌入式系統(tǒng)常用的C語(yǔ)言，更接近通常的嵌入式開(kāi)發(fā)環(huán)境。

　　3 實(shí)例分析與討論

　　這里以一個(gè)報(bào)警系統(tǒng)為例，說(shuō)明如何使用UML來(lái)設(shè)計(jì)嵌入式系統(tǒng)。一個(gè)報(bào)警系統(tǒng)一般由傳感器(包括聲音傳感器、圖像傳感器和熱傳感器)，報(bào)警器 (包括聲音報(bào)警器、電話報(bào)警器和光報(bào)警器)，鍵盤，LCD顯示器，系統(tǒng)處理器，以及用于存儲(chǔ)系統(tǒng)配置信息和日志信息的存儲(chǔ)器等部件組成。

　　當(dāng)傳感器接收到某個(gè)信號(hào)，通過(guò)模/數(shù)轉(zhuǎn)換把信息送到系統(tǒng)處理器中后，系統(tǒng)處理器根據(jù)設(shè)定的配置信息條件，判斷是否需要報(bào)警。若需要，則會(huì)向報(bào)警器發(fā)出報(bào)警命令。鍵盤和LCD顯示器用于人機(jī)對(duì)話，可以根據(jù)實(shí)際需要設(shè)定報(bào)警條件和方式。

　　該系統(tǒng)的序列圖如圖1所示。從圖1中可以看出，該系統(tǒng)要求從傳感器返回信息到發(fā)出報(bào)警的時(shí)間間隔小于3 s。這就是序列圖中對(duì)嵌入式實(shí)時(shí)系統(tǒng)時(shí)間要求的一個(gè)例子。

　　在類圖中，把系統(tǒng)處理器設(shè)計(jì)成活動(dòng)類，負(fù)責(zé)處理通過(guò)帶有LCD 顯示的控制面板與用戶的交互。通過(guò)控制面板，可以配置、激活和關(guān)閉系統(tǒng)。所有的配置變化均保存在系統(tǒng)配置信息類中。系統(tǒng)處理器接收傳感器的信息，并把它與 系統(tǒng)配置信息比較，從而決定是否報(bào)警。為了查詢和了解報(bào)警系統(tǒng)歷史信息，系統(tǒng)處理器將所有事件保存在日志中。系統(tǒng)處理器、傳感器和報(bào)警器的類圖的簡(jiǎn)單關(guān)系 如圖2所示。

　　圖1 報(bào)警系統(tǒng)序列圖

　　圖2 報(bào)警器系統(tǒng)組成的類圖

　　結(jié)語(yǔ)

　　為嵌入式系統(tǒng)引入一個(gè)通用、完善的UML技術(shù)，必將對(duì)當(dāng)前高速發(fā)展的嵌入式系統(tǒng)的研究與開(kāi)發(fā)產(chǎn)生積極的影響。而本文所提出的思想和方法，對(duì)于擺脫UML技術(shù)在嵌入式領(lǐng)域的困境起到了有益的探索和建議作用。