|
引言 隨著(zhù)嵌入式應用的不斷增長(cháng)，嵌入式系統需求的復雜性、不確定性不斷提高，系統規模也逐步擴大；而產(chǎn)品的研發(fā)周期又在很快地縮短，給嵌入式應用軟件的開(kāi)發(fā)帶來(lái)了新的挑戰。同時(shí)，嵌入式軟件的開(kāi)發(fā)者必須面對由于芯片性能的增長(cháng)、嵌入式操作系統平臺等技術(shù)方面不斷變化所帶來(lái)的各種壓力。嵌入式軟件開(kāi)發(fā)環(huán)境的發(fā)展，使一直“深埋”于系統的嵌入式應用軟件變得開(kāi)放而易于開(kāi)發(fā)，從而促進(jìn)了嵌入式技術(shù)的廣泛應用。 1 基于UML的嵌入式軟件開(kāi)發(fā)環(huán)境結構 圖1所示為一種支持基于UML（Unified Modeling Language，統一建模語(yǔ)言）的迭代式開(kāi)發(fā)方法的開(kāi)發(fā)環(huán)境的結構，虛框部分為基于UML的軟件開(kāi)發(fā)環(huán)境。 
圖1 基于UML嵌入式軟件開(kāi)發(fā)環(huán)境的結構 系統分析和設計用UML來(lái)描述，對系統建模；實(shí)現過(guò)程利用代碼自動(dòng)生成技術(shù)來(lái)實(shí)現；測試過(guò)程將依賴(lài)于生成的代碼，通過(guò)在代碼中拆裝一些用于支持模型調試的調試信息來(lái)實(shí)現；而代碼的編譯、鏈接則采用目標系統的操作系統開(kāi)發(fā)環(huán)境來(lái)完成，代碼的運行與源程序級的調試仍然采用一般的嵌入式軟件調試環(huán)境。 Rhapsody是一個(gè)基于UML的面向嵌入式實(shí)時(shí)應用開(kāi)發(fā)的集成、可視化環(huán)境。軟件開(kāi)發(fā)者可以在這個(gè)環(huán)境里進(jìn)行分析、設計、實(shí)現及驗證。 Rhapsody支持基于模型的調試；提供專(zhuān)門(mén)為實(shí)時(shí)嵌入式應用設計的可執行的框架，可以產(chǎn)生基于VxWorks、POS、OSE等多種操作系統的C語(yǔ)言、C++語(yǔ)言、Java語(yǔ)言的源程序。本文所給出的自動(dòng)取款機系統的模型正是基于Rhapsody設計的。 2 自動(dòng)取款機系統模型的設計 2.1 需求分析 我們設計的自動(dòng)取款機系統要滿(mǎn)足如下要求： 在自動(dòng)取款機系統中，當顧客在自動(dòng)取款機操作面板上插入信用卡并輸入密碼和現金支取數額(每次最多只能取一千元)后，由自動(dòng)取款機讀取卡上的內容，并把相應信息傳送到銀行。銀行把自動(dòng)取款機送來(lái)的信息與銀行帳號上的信息進(jìn)行比較，如果兩者一致，則銀行傳送確認信息到自動(dòng)取款機，由自動(dòng)取款機輸出現金，然后顧客取出卡和現金；如果兩者不一致，則要求顧客再次輸入密碼和現金支取數額，然后重復上述操作；若密碼輸入三次不正確，自動(dòng)取款機就會(huì )吞掉信用卡，顧客就不能取出信用卡和現金。 該自動(dòng)取款機系統包括1個(gè)鍵盤(pán)(10個(gè)數字鍵、ENTER鍵和CANCEL鍵)、1個(gè)LCD液晶顯示屏、1個(gè)插卡孔和1個(gè)現金出口；通過(guò)雙絞線(xiàn)與銀行中的電腦進(jìn)行串行通信。該自動(dòng)取款機系統不包括銀行中的電腦，只是通過(guò)軟件與銀行中的上位機進(jìn)行串行通信。 2.2 可視化建模 建模是面向對象分析和設計的核心，也是分析和設計過(guò)程中最基本和最關(guān)鍵的活動(dòng)之一。UML不僅適用于以面向對象技術(shù)描述的任何類(lèi)型的系統，而且適用于系統開(kāi)發(fā)的不同階段。根據開(kāi)發(fā)過(guò)程中不同階段的具體要求，利用UML不同類(lèi)型的圖來(lái)描述系統的各種靜態(tài)結構模型和動(dòng)態(tài)行為模型。下面介紹如何利用基于UML的面向嵌入式實(shí)時(shí)應用開(kāi)發(fā)的集成可視化環(huán)境Rhapsody創(chuàng )建自動(dòng)取款機系統的模型。 第一步：根據要求建立用例圖。 圖2所示為用例圖。圖中給出了自動(dòng)取款機系統的主要用途，并表明由誰(shuí)使用自動(dòng)取款機系統。有一個(gè)主要成員——顧客。一個(gè)用例圖應該具有這樣的系統功能：對操作者而言，它返回可觀(guān)察的結果但并不顯示系統的內在結構。
圖2 自動(dòng)取款機系統的用例圖 自動(dòng)取款機系統的主要用途是“取出現金” 用例。顧客參與其中的兩個(gè)實(shí)例是“輸入密碼”和“取出現金”。這兩個(gè)實(shí)例都包含了另一個(gè)用例“讀取卡上內容并驗證”。對每一個(gè)用例而言，我們都可以增加文本描述。假如需要的話(huà)，這些用例能夠被細化成另一張更多用例的圖。這些用例并沒(méi)有顯示任何內在的結構，僅是一個(gè)功能性的視圖。 第二步：設計黑匣子場(chǎng)景。 建立了一個(gè)用例圖后，下一步便是細化用例，即設計一些黑匣子場(chǎng)景。這些黑匣子場(chǎng)景的主要作用是表明模型和對象之間的相互關(guān)系。把整個(gè)系統看作一個(gè)整體，對 “取出現金” 用例，我們細化為圖3所示的場(chǎng)景。(由于每次最多只能取一千元，所以最多只需要按鍵4次。)
圖3 取出現金的黑匣子場(chǎng)景 圖3所示的場(chǎng)景能被MSD（消息序列表）捕獲，用來(lái)描述在顧客和自動(dòng)取款機系統之間的通信行為。當創(chuàng )建這樣的圖表時(shí)，關(guān)于系統的更多細節被隱藏了；同時(shí)，這些場(chǎng)景幫助我們更好地理解使用者如何使用報警系統以及需要做哪些事情�？偠灾�，每一用例都有很多的場(chǎng)景需要捕獲，每一個(gè)場(chǎng)景都是用例的一個(gè)有效的實(shí)例。 第三步：設計子系統圖。 下一步是如何把模型分割成子系統。在UML中，一個(gè)子系統作為一個(gè)封裝顯示，即主要是一個(gè)類(lèi)的集合。圖4的子系統圖表明自動(dòng)取款機系統已經(jīng)被分解成兩個(gè)基本的部分：自動(dòng)柜員機封裝(AtmerPkg)和硬件封裝(HardharePkg)。同時(shí)也表明：自動(dòng)柜員機封裝是完全獨立于實(shí)際的硬件和硬件封裝的，并且實(shí)現了Ihardware接口能夠用于連接自動(dòng)柜員機封裝。接口類(lèi)Ihardware描述了對自動(dòng)柜員機封裝的所有必需的操作，實(shí)現了應用與硬件環(huán)境的隔離。
圖4 自動(dòng)取款機系統的子系統 一旦在自動(dòng)柜員機封裝和硬件封裝之間定義了接口類(lèi)，每一個(gè)子系統就能同步和獨立地細化為更多的子系統。每一個(gè)子系統都知道它和其它子系統之間的接口。例如，我們可以開(kāi)始分析自動(dòng)柜員機子系統圖，而不需要知道關(guān)于硬件的更多情況。 第四步：設計對象模型圖。 對自動(dòng)柜員機封裝而言，我們設想有一個(gè)AtmerController類(lèi)，其中包含Keypad類(lèi)、Card類(lèi)、LCD類(lèi)和Cash類(lèi)，這些類(lèi)表示如圖5所示。
圖5 AtmerController類(lèi)的對象模型 圖5表明：AtmerController類(lèi)作為一個(gè)聚合類(lèi)，包含了其它類(lèi)的實(shí)例。我們也能看出，我們能選擇顯示“Keypad”類(lèi)的不同的操作和屬性。在上面的例子中，假如一個(gè)實(shí)例被AtmerControlle類(lèi)創(chuàng )建，那么它將創(chuàng )建Keypad類(lèi)的一個(gè)實(shí)例theKeypad、LCD類(lèi)的一個(gè)實(shí)例theLCD、Cash類(lèi)的一個(gè)實(shí)例theCash以及Card類(lèi)的一個(gè)實(shí)例theCard。假如AtmerController類(lèi)的實(shí)例被刪除，這些包含的實(shí)例也同時(shí)被刪除。 Ihardware類(lèi)也有一些純虛函數，所以為了測試AtmerController類(lèi)，必須忽略這些操作。圖6表示：ATM包含了 AtmerController類(lèi)的一個(gè)實(shí)例和從Ihardware類(lèi)繼承并忽略了其操作的Hw類(lèi)的一個(gè)實(shí)例。
圖6 ATM對象模型圖 第五步：生成白匣子場(chǎng)景。 生成了一個(gè)新類(lèi)AtmerController后，就可以開(kāi)始為每一個(gè)黑匣子場(chǎng)景生成白匣子場(chǎng)景。消息序列表將用于獲取以上不同場(chǎng)景的類(lèi)的實(shí)例之間的通信行為。例如，圖7消息序列描述了顧客輸入支取現金數額并取出現金的場(chǎng)景。
圖7 顧客輸入支取現金數額并取出現金的場(chǎng)景 消息通常對應于對象模型中操作和操作的返回值。消息值對應于類(lèi)的屬性或是類(lèi)操作的返回值。消息可以是同步的，也可以是異步的。從圖中可以看出，這些類(lèi)都有動(dòng)態(tài)行為：它們正在處理定時(shí)事件；調用其它類(lèi)的操作；接受事件。對UML來(lái)說(shuō)，這些動(dòng)態(tài)行為都可以用一個(gè)狀態(tài)圖來(lái)表示。 第六步：創(chuàng )建狀態(tài)圖。 以顧客輸入密碼過(guò)程為例，創(chuàng )建狀態(tài)圖，如圖8所示。通常，當一個(gè)問(wèn)題很復雜時(shí)，它往往被分解成一些簡(jiǎn)單的問(wèn)題，這也正是對顧客輸入密碼過(guò)程要做的事情。圖8所示的狀態(tài)圖描述了顧客輸入密碼過(guò)程中的行為。
圖8 顧客輸入密碼過(guò)程的狀態(tài)圖 2.3 屬性、操作和事件 屬性來(lái)源于需求文檔中定義的數據，應該簡(jiǎn)單，不考慮設計和實(shí)現的細節。每個(gè)類(lèi)都可能有定義在其上的事件和操作。事件對應于明確的瞬時(shí)發(fā)生的影響類(lèi)的動(dòng)態(tài)行為。操作對應于類(lèi)的服務(wù)和功能。Rhapsody中有3種事件。 ① 信號事件：對應于實(shí)例間的異步通信。 ② 時(shí)間事件：這種事件在進(jìn)入一個(gè)狀態(tài)并且經(jīng)過(guò)一個(gè)指定的時(shí)間后觸發(fā)。 ③ 觸發(fā)操作：觸發(fā)操作是同步的操作，通過(guò)能夠迅速得到響應的事件得到執行。觸發(fā)操作沒(méi)有實(shí)現代碼，卻可以作為類(lèi)的狀態(tài)圖轉移的觸發(fā)器。當調用觸發(fā)操作時(shí)，同時(shí)產(chǎn)生響應的事件。 2.4 生成代碼 一般嵌入式應用中有60%~90%的代碼用于內務(wù)處理（如狀態(tài)圖的實(shí)現、任務(wù)間的通信等），這些代碼在設計新的系統時(shí)一般都可以重用。這種重用一般是通過(guò)實(shí)時(shí)框架來(lái)實(shí)現的。Rhapsody就提供了這樣一個(gè)實(shí)時(shí)框架，它提供了一套嵌入式和實(shí)時(shí)應用專(zhuān)門(mén)選擇和優(yōu)化的設計模板。嵌入式應用程序一般都運行在嵌入式操作系統的平臺上，而實(shí)時(shí)框架就是一個(gè)在操作系統之上應用程序之下的中間件。應用程序的編寫(xiě)或自動(dòng)產(chǎn)生都基于有統一接口的實(shí)時(shí)框架，這樣就使應用軟件的開(kāi)發(fā)與具體的平臺無(wú)關(guān)，解決了嵌入式應用軟件的移植問(wèn)題。 一旦畫(huà)出其余的圖表并創(chuàng )建好不同類(lèi)的實(shí)例后，就能進(jìn)行代碼的生成和模型的測試工作。在Rhapsody中，需要進(jìn)行一些配置，以告訴 Rhapsody從哪些類(lèi)生成代碼及使用什么樣的環(huán)境。首先，使用Microsoft環(huán)境（Windows操作環(huán)境和Visual C++編譯器）。然后，代碼在Rhapsody中生成和編譯，以產(chǎn)生可執行程序。 2.5 使UML模型有效 Rhapsody能使用自動(dòng)生成的代碼，所以，當實(shí)際的代碼運行時(shí)，它能返回一些信息給調試工具，以便Rhapsody進(jìn)行模型的測試。通過(guò)模型級調試、驗證，可以盡早發(fā)現系統的設計錯誤或缺陷，從而較早地確定或降低項目的風(fēng)險。 2.6 測試模型 一旦自動(dòng)柜員機封裝被手工產(chǎn)生的事件測試通過(guò)并觀(guān)察發(fā)生的情況后，就可以利用如微軟的Visual C++產(chǎn)生一個(gè)GUI。用于創(chuàng )建GUI的類(lèi)從Ihardware類(lèi)繼承而來(lái)，選中set選項，當按鈕被按下時(shí)，調用ON操作。GUI也能促使模型在模型級再次被調試。 3 在VxWorks上運行 模型是系統整體的抽象。軟件開(kāi)發(fā)的最終形式必須生成程序代碼，模型畢竟是一些漂亮的藍圖。雖然它對軟件的設計有很大的作用，但用戶(hù)的最終目的是希望得到可執行的程序。對于嵌入式實(shí)時(shí)系統，代碼與系統要求（時(shí)間約束、資源的限制等）是緊密聯(lián)系的，用最終形式的源程序驗證系統的模型更準確。 Rhapsody可利用軟件自動(dòng)生成技術(shù)的成果，根據模型可以自動(dòng)生成具有產(chǎn)品質(zhì)量的代碼。這種代碼既可以作為系統模型驗證的代碼，也是系統最后提交的代碼。所以產(chǎn)生的代碼是基于某個(gè)具體平臺的代碼，通過(guò)編譯即可運行在該平臺上。本文采用的是美國 Wind River System 公司推出的一個(gè)實(shí)時(shí)操作系統VxWorks。它是一個(gè)運行在目標機上的高性能、可裁剪的嵌入式實(shí)時(shí)操作系統。 一旦自動(dòng)取款機系統被設計、實(shí)現和測試后，它就能在實(shí)時(shí)多任務(wù)操作系統VxWorks上實(shí)現。1個(gè)鍵盤(pán)、1個(gè)LCD液晶顯示屏、1個(gè)插卡孔、1 根與銀行的上位機相連的雙絞線(xiàn)和1個(gè)輸出現金口經(jīng)由I/O板連接到1個(gè)目標板上。 從Ihardware類(lèi)繼承而來(lái)并選中set選項而創(chuàng )建新類(lèi)HwIrq。這些操作的實(shí)例可以被寫(xiě)進(jìn)Rhapsody中。為了寫(xiě)到I/O板中，使用VxWorks系統的操作sysOutByte。 HwIrq類(lèi)已經(jīng)被設置成一個(gè)活動(dòng)類(lèi)，所以它能在自己的線(xiàn)程運行，線(xiàn)程的參數被配置如下：線(xiàn)程名為tRhpHw，堆棧長(cháng)度為4096字節，優(yōu)先級為180。 HwIrq.cpp的部分程序見(jiàn)本文附件。 4 結論 本文運用基于UML的嵌入式實(shí)時(shí)應用軟件開(kāi)發(fā)環(huán)境Rhapsody來(lái)設計和實(shí)現自動(dòng)取款機系統的模型。與傳統的嵌入式軟件開(kāi)發(fā)方法相比，具有明顯的優(yōu)勢。它大大縮短了產(chǎn)品的開(kāi)發(fā)周期，解決了嵌入式應用軟件的移植問(wèn)題，使軟件的開(kāi)發(fā)工作主要集中在高層的建模和模型的測試及驗證上，從而使軟件開(kāi)發(fā)工作的焦點(diǎn)從編碼轉到了設計上。 參考文獻 1. 尚利宏.熊運鴻 一種基于UML 的嵌入式應用軟件開(kāi)發(fā)環(huán)境 [期刊論文] -電子質(zhì)量2001(9) 2. 左光 一種基于UML的實(shí)時(shí)框架的分析與應用 2002(3) 作 者：中國礦業(yè)大學(xué) 倪紅軍 趙紹剛 朱美強 來(lái) 源：單片機與嵌入式系統應用2004（1） |
