《電子技術(shù)應(yīng)用》
您所在的位置:首頁 > 其他 > 設(shè)計應(yīng)用 > 一種改進型UML在嵌入式系統(tǒng)中的應(yīng)用
一種改進型UML在嵌入式系統(tǒng)中的應(yīng)用
摘要: 一種改進型UML在嵌入式系統(tǒng)中的應(yīng)用
Abstract:
Key words :

    引言

  隨著計算機技術(shù)、網(wǎng)絡(luò)技術(shù)和通信技術(shù)的迅速發(fā)展,當(dāng)前的信息社會已從當(dāng)初傳統(tǒng)的個人計算機時代進入了后PC時代;而后PC時代的主要特征就是以嵌入式系統(tǒng)的廣泛應(yīng)用與發(fā)展為標(biāo)志的。

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

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

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

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

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

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

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

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

 ?、?嵌入式系統(tǒng)軟件平臺也千差萬別,各自對開發(fā)的要求差異較大。

 ?、?大部分嵌入式系統(tǒng)對實時性要求嚴格。

  ④ 嵌入式平臺的軟件一般不是采用面向?qū)ο笳Z言開發(fā)的,主要采用C語言甚至是匯編語言編寫。

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

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

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

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

 ?、?對于語言的問題,主要有以下兩種解決方法: 一種是使用面向?qū)ο蟮腃++語言開發(fā),如SystemC[6];另一種是使用可以與C語言結(jié)合的UML開發(fā)環(huán)境,如美國ILogix公司推出的Rhapsody。

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

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

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

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

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

  ◆ 并發(fā)性。用活動類來描述并發(fā)?;顒宇惖膶傩裕ㄈ鐑?yōu)先級)可以定義成類的標(biāo)簽值,可通過組件版類﹤﹤Process﹥﹥和﹤﹤Thread﹥﹥將它們映射到實現(xiàn)環(huán)境中。

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

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

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

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

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

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

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

  ⑤ 最后,使用組件圖和展開圖來實現(xiàn)系統(tǒng)的集成與驗證。

  以上過程可以在Rhapsody軟件環(huán)境下實現(xiàn),因為該軟件可以產(chǎn)生嵌入式系統(tǒng)常用的C語言,更接近通常的嵌入式開發(fā)環(huán)境。

  3、實例分析與討論

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

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

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

  

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

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

  

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

  結(jié)語

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

此內(nèi)容為AET網(wǎng)站原創(chuàng),未經(jīng)授權(quán)禁止轉(zhuǎn)載。