改進(jìn)型UML在嵌入式系統中的應用

在后PC時(shí)代，越來(lái)越多的領(lǐng)域需要嵌入式系統的支持，傳統嵌入式系統的開(kāi)發(fā)手段已不能滿(mǎn)足日益增長(cháng)的復雜性和質(zhì)量要求；而UML技術(shù)在軟件領(lǐng)域所取得的巨大成就為嵌入式系統開(kāi)發(fā)帶來(lái)了希望。因此，如何把基于軟件領(lǐng)域的UML作為通用和完善的方法引入到嵌入式系統領(lǐng)域，將成為一個(gè)迫切需要考慮和解決的問(wèn)題。

隨著(zhù)計算機技術(shù)、網(wǎng)絡(luò )技術(shù)和通信技術(shù)的迅速發(fā)展，當前的信息社會(huì )已從當初傳統的個(gè)人計算機時(shí)代進(jìn)入了后PC時(shí)代；而后PC時(shí)代的主要特征就是以嵌入式系統的廣泛應用與發(fā)展為標志的。

關(guān)于嵌入式系統的定義雖然有很多種，不過(guò)國內普遍認可的定義是[1]： 以應用為中心，以計算機技術(shù)為基礎，軟硬件可裁剪，適合應用系統對功能、可靠性、成本、體積和功耗要求的專(zhuān)用計算機系統。

嵌入式系統主要是使用微型的芯片及其固化的軟件，嵌入在其他系統中，以達到對其他系統進(jìn)行智能化或信息化實(shí)時(shí)控制等目的。

當前，嵌入式系統已在工業(yè)控制、航空航天、國防以及信息家電等領(lǐng)域得到廣泛的應用，并發(fā)揮了重要作用，而且越來(lái)越多的領(lǐng)域都迫切需要嵌入式系統的支持。然而，由于嵌入式系統的硬件、軟件、應用環(huán)境的千差萬(wàn)別，因此當前有限的嵌入式技術(shù)人員的時(shí)間和精力主要花在熟悉不同的硬件、軟件及其代碼的開(kāi)發(fā)上。這樣不但造成嵌入式系統開(kāi)發(fā)的效率和質(zhì)量得不到保證，而且也嚴重束縛了嵌入式技術(shù)人員進(jìn)行更高層次的研究與開(kāi)發(fā)。這些都成為日益復雜的嵌入式系統迅速發(fā)展的瓶頸。

1 UML引入到嵌入式系統中的可行性

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

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

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

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

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

③ 大部分嵌入式系統對實(shí)時(shí)性要求嚴格。

④ 嵌入式平臺的軟件一般不是采用面向對象語(yǔ)言開(kāi)發(fā)的，主要采用C語(yǔ)言甚至是匯編語(yǔ)言編寫(xiě)。

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

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

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

② 對于實(shí)時(shí)性要求，提供的解決方法主要包括： 使用標準的UML及其構造型概念設計實(shí)時(shí)系統[4]，以及擴充UML或改造UML以使其滿(mǎn)足實(shí)時(shí)系統的要求[5]。

③ 對于語(yǔ)言的問(wèn)題，主要有以下兩種解決方法： 一種是使用面向對象的C++語(yǔ)言開(kāi)發(fā)，如SystemC[6]；另一種是使用可以與C語(yǔ)言結合的UML開(kāi)發(fā)環(huán)境，如美國ILogix公司推出的Rhapsody。

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

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

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

為了給嵌入式系統建模必須考慮以下方面：

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

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

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

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

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

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

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

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

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

⑤ 最后,使用組件圖和展開(kāi)圖來(lái)實(shí)現系統的集成與驗證。

以上過(guò)程可以在Rhapsody軟件環(huán)境下實(shí)現，因為該軟件可以產(chǎn)生嵌入式系統常用的C語(yǔ)言，更接近通常的嵌入式開(kāi)發(fā)環(huán)境。

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

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

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

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

圖1 報警系統序列圖

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

圖2 報警器系統組成的類(lèi)圖

結語(yǔ)

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