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

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

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

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

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

　　② 嵌入式系統軟件平臺也千差萬別，各自對開發的要求差異較大。

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

　　④ 嵌入式平臺的軟件一般不是采用面向對象語言開發的，主要采用C語言甚至是匯編語言編寫。

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

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

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

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

　　③ 對于語言的問題，主要有以下兩種解決方法： 一種是使用面向對象的C++語言開發，如SystemC[6];另一種是使用可以與C語言結合的UML開發環境，如美國ILogix公司推出的Rhapsody。

　　由以上3種解決方案可知，UML應用在嵌入式系統所產生的可驗證性、實時性以及語言的問題，都是可以解決的，因而有可能廣泛使用UML來分析、設計與指導嵌入式系統開發，以解決嵌入式系統開發效率低下的問題。

　　2 一種改進的通用嵌入式系統UML方案

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

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

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

　　◆ 并發性。用活動類來描述并發。活動類的屬性(如優先級)可以定義成類的標簽值，可通過組件版類﹤﹤Process﹥﹥和﹤﹤Thread﹥﹥將它們映射到實現環境中。

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

　　◆ 同步通信。定義信號量、監視器或關鍵區的類/版類來描述同步。

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

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

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

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

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

　　⑤ 最后,使用組件圖和展開圖來實現系統的集成與驗證。

　　以上過程可以在Rhapsody軟件環境下實現，因為該軟件可以產生嵌入式系統常用的C語言，更接近通常的嵌入式開發環境。

　　3 實例分析與討論

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

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

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

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

　　圖1 報警系統序列圖

　　圖2 報警器系統組成的類圖

　　結語

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