作者：倪紅軍 ， 趙紹剛 ， 朱美強

引言

隨著嵌入式應用的不斷增長，嵌入式系統(tǒng)需求的復雜性、不確定性不斷提高，系統(tǒng)規(guī)模也逐步擴大；而產品的研發(fā)周期又在很快地縮短，給嵌入式應用軟件的開發(fā)帶來了新的挑戰(zhàn)。同時，嵌入式軟件的開發(fā)者必須面對由于芯片性能的增長、嵌入式操作系統(tǒng)平臺等技術方面不斷變化所帶來的各種壓力。嵌入式軟件開發(fā)環(huán)境的發(fā)展，使一直“深埋”于系統(tǒng)的嵌入式應用軟件變得開放而易于開發(fā)，從而促進了嵌入式技術的廣泛應用。

1 基于UML的嵌入式軟件開發(fā)環(huán)境結構

圖1所示為一種支持基于UML（Unified Modeling Language，統(tǒng)一建模語言）的迭代式開發(fā)方法的開發(fā)環(huán)境的結構，虛框部分為基于UML的軟件開發(fā)環(huán)境。

圖1 基于UML嵌入式軟件開發(fā)環(huán)境的結構

系統(tǒng)分析和設計用UML來描述，對系統(tǒng)建模；實現過程利用代碼自動生成技術來實現；測試過程將依賴于生成的代碼，通過在代碼中拆裝一些用于支持模型調試的調試信息來實現；而代碼的編譯、鏈接則采用目標系統(tǒng)的操作系統(tǒng)開發(fā)環(huán)境來完成，代碼的運行與源程序級的調試仍然采用一般的嵌入式軟件調試環(huán)境。

Rhapsody是一個基于UML的面向嵌入式實時應用開發(fā)的集成、可視化環(huán)境。軟件開發(fā)者可以在這個環(huán)境里進行分析、設計、實現及驗證。 Rhapsody支持基于模型的調試；提供專門為實時嵌入式應用設計的可執(zhí)行的框架，可以產生基于VxWorks、POS、OSE等多種操作系統(tǒng)的C語言、C++語言、Java語言的源程序。本文所給出的自動取款機系統(tǒng)的模型正是基于Rhapsody設計的。

2 自動取款機系統(tǒng)模型的設計

2.1 需求分析

我們設計的自動取款機系統(tǒng)要滿足如下要求：

在自動取款機系統(tǒng)中，當顧客在自動取款機操作面板上插入信用卡并輸入密碼和現金支取數額（每次最多只能取一千元）后，由自動取款機讀取卡上的內容，并把相應信息傳送到銀行。銀行把自動取款機送來的信息與銀行帳號上的信息進行比較，如果兩者一致，則銀行傳送確認信息到自動取款機，由自動取款機輸出現金，然后顧客取出卡和現金；如果兩者不一致，則要求顧客再次輸入密碼和現金支取數額，然后重復上述操作；若密碼輸入三次不正確，自動取款機就會吞掉信用卡，顧客就不能取出信用卡和現金。

該自動取款機系統(tǒng)包括1個鍵盤（10個數字鍵、ENTER鍵和CANCEL鍵）、1個LCD液晶顯示屏、1個插卡孔和1個現金出口；通過雙絞線與銀行中的電腦進行串行通信。該自動取款機系統(tǒng)不包括銀行中的電腦，只是通過軟件與銀行中的上位機進行串行通信。

2.2 可視化建模

建模是面向對象分析和設計的核心，也是分析和設計過程中最基本和最關鍵的活動之一。UML不僅適用于以面向對象技術描述的任何類型的系統(tǒng)，而且適用于系統(tǒng)開發(fā)的不同階段。根據開發(fā)過程中不同階段的具體要求，利用UML不同類型的圖來描述系統(tǒng)的各種靜態(tài)結構模型和動態(tài)行為模型。下面介紹如何利用基于UML的面向嵌入式實時應用開發(fā)的集成可視化環(huán)境Rhapsody創(chuàng)建自動取款機系統(tǒng)的模型。

第一步：根據要求建立用例圖。

圖2所示為用例圖。圖中給出了自動取款機系統(tǒng)的主要用途，并表明由誰使用自動取款機系統(tǒng)。有一個主要成員——顧客。一個用例圖應該具有這樣的系統(tǒng)功能：對操作者而言，它返回可觀察的結果但并不顯示系統(tǒng)的內在結構。

圖2 自動取款機系統(tǒng)的用例圖

自動取款機系統(tǒng)的主要用途是“取出現金” 用例。顧客參與其中的兩個實例是“輸入密碼”和“取出現金”。這兩個實例都包含了另一個用例“讀取卡上內容并驗證”。對每一個用例而言，我們都可以增加文本描述。假如需要的話，這些用例能夠被細化成另一張更多用例的圖。這些用例并沒有顯示任何內在的結構，僅是一個功能性的視圖。

第二步：設計黑匣子場景。

建立了一個用例圖后，下一步便是細化用例，即設計一些黑匣子場景。這些黑匣子場景的主要作用是表明模型和對象之間的相互關系。把整個系統(tǒng)看作一個整體，對 “取出現金” 用例，我們細化為圖3所示的場景。（由于每次最多只能取一千元，所以最多只需要按鍵4次。）

圖3 取出現金的黑匣子場景

圖3所示的場景能被MSD（消息序列表）捕獲，用來描述在顧客和自動取款機系統(tǒng)之間的通信行為。當創(chuàng)建這樣的圖表時，關于系統(tǒng)的更多細節(jié)被隱藏了；同時，這些場景幫助我們更好地理解使用者如何使用報警系統(tǒng)以及需要做哪些事情?？偠灾?，每一用例都有很多的場景需要捕獲，每一個場景都是用例的一個有效的實例。

第三步：設計子系統(tǒng)圖。

下一步是如何把模型分割成子系統(tǒng)。在UML中，一個子系統(tǒng)作為一個封裝顯示，即主要是一個類的集合。圖4的子系統(tǒng)圖表明自動取款機系統(tǒng)已經被分解成兩個基本的部分：自動柜員機封裝（AtmerPkg）和硬件封裝（HardharePkg）。同時也表明：自動柜員機封裝是完全獨立于實際的硬件和硬件封裝的，并且實現了Ihardware接口能夠用于連接自動柜員機封裝。接口類Ihardware描述了對自動柜員機封裝的所有必需的操作，實現了應用與硬件環(huán)境的隔離。

圖4 自動取款機系統(tǒng)的子系統(tǒng)

一旦在自動柜員機封裝和硬件封裝之間定義了接口類，每一個子系統(tǒng)就能同步和獨立地細化為更多的子系統(tǒng)。每一個子系統(tǒng)都知道它和其它子系統(tǒng)之間的接口。例如，我們可以開始分析自動柜員機子系統(tǒng)圖，而不需要知道關于硬件的更多情況。

第四步：設計對象模型圖。

對自動柜員機封裝而言，我們設想有一個AtmerController類，其中包含Keypad類、Card類、LCD類和Cash類，這些類表示如圖5所示。

圖5 AtmerController類的對象模型

圖5表明：AtmerController類作為一個聚合類，包含了其它類的實例。我們也能看出，我們能選擇顯示“Keypad”類的不同的操作和屬性。在上面的例子中，假如一個實例被AtmerControlle類創(chuàng)建，那么它將創(chuàng)建Keypad類的一個實例theKeypad、LCD類的一個實例theLCD、Cash類的一個實例theCash以及Card類的一個實例theCard。假如AtmerController類的實例被刪除，這些包含的實例也同時被刪除。

Ihardware類也有一些純虛函數，所以為了測試AtmerController類，必須忽略這些操作。圖6表示：ATM包含了 AtmerController類的一個實例和從Ihardware類繼承并忽略了其操作的Hw類的一個實例。

圖6 ATM對象模型圖

第五步：生成白匣子場景。

生成了一個新類AtmerController后，就可以開始為每一個黑匣子場景生成白匣子場景。消息序列表將用于獲取以上不同場景的類的實例之間的通信行為。例如，圖7消息序列描述了顧客輸入支取現金數額并取出現金的場景。

圖7 顧客輸入支取現金數額并取出現金的場景

消息通常對應于對象模型中操作和操作的返回值。消息值對應于類的屬性或是類操作的返回值。消息可以是同步的，也可以是異步的。從圖中可以看出，這些類都有動態(tài)行為：它們正在處理定時事件；調用其它類的操作；接受事件。對UML來說，這些動態(tài)行為都可以用一個狀態(tài)圖來表示。

第六步：創(chuàng)建狀態(tài)圖。

以顧客輸入密碼過程為例，創(chuàng)建狀態(tài)圖，如圖8所示。通常，當一個問題很復雜時，它往往被分解成一些簡單的問題，這也正是對顧客輸入密碼過程要做的事情。圖8所示的狀態(tài)圖描述了顧客輸入密碼過程中的行為。

圖8 顧客輸入密碼過程的狀態(tài)圖

2.3 屬性、操作和事件

屬性來源于需求文檔中定義的數據，應該簡單，不考慮設計和實現的細節(jié)。每個類都可能有定義在其上的事件和操作。事件對應于明確的瞬時發(fā)生的影響類的動態(tài)行為。操作對應于類的服務和功能。Rhapsody中有3種事件。

① 信號事件：對應于實例間的異步通信。

② 時間事件：這種事件在進入一個狀態(tài)并且經過一個指定的時間后觸發(fā)。

③ 觸發(fā)操作：觸發(fā)操作是同步的操作，通過能夠迅速得到響應的事件得到執(zhí)行。觸發(fā)操作沒有實現代碼，卻可以作為類的狀態(tài)圖轉移的觸發(fā)器。當調用觸發(fā)操作時，同時產生響應的事件。

2.4 生成代碼

一般嵌入式應用中有60%~90%的代碼用于內務處理（如狀態(tài)圖的實現、任務間的通信等），這些代碼在設計新的系統(tǒng)時一般都可以重用。這種重用一般是通過實時框架來實現的。Rhapsody就提供了這樣一個實時框架，它提供了一套嵌入式和實時應用專門選擇和優(yōu)化的設計模板。嵌入式應用程序一般都運行在嵌入式操作系統(tǒng)的平臺上，而實時框架就是一個在操作系統(tǒng)之上應用程序之下的中間件。應用程序的編寫或自動產生都基于有統(tǒng)一接口的實時框架，這樣就使應用軟件的開發(fā)與具體的平臺無關，解決了嵌入式應用軟件的移植問題。

一旦畫出其余的圖表并創(chuàng)建好不同類的實例后，就能進行代碼的生成和模型的測試工作。在Rhapsody中，需要進行一些配置，以告訴 Rhapsody從哪些類生成代碼及使用什么樣的環(huán)境。首先，使用Microsoft環(huán)境（Windows操作環(huán)境和Visual C++編譯器）。然后，代碼在Rhapsody中生成和編譯，以產生可執(zhí)行程序。

2.5 使UML模型有效

Rhapsody能使用自動生成的代碼，所以，當實際的代碼運行時，它能返回一些信息給調試工具，以便Rhapsody進行模型的測試。通過模型級調試、驗證，可以盡早發(fā)現系統(tǒng)的設計錯誤或缺陷，從而較早地確定或降低項目的風險。

2.6 測試模型

一旦自動柜員機封裝被手工產生的事件測試通過并觀察發(fā)生的情況后，就可以利用如微軟的Visual C++產生一個GUI。用于創(chuàng)建GUI的類從Ihardware類繼承而來，選中set選項，當按鈕被按下時，調用ON操作。GUI也能促使模型在模型級再次被調試。

3 在VxWorks上運行

模型是系統(tǒng)整體的抽象。軟件開發(fā)的最終形式必須生成程序代碼，模型畢竟是一些漂亮的藍圖。雖然它對軟件的設計有很大的作用，但用戶的最終目的是希望得到可執(zhí)行的程序。對于嵌入式實時系統(tǒng)，代碼與系統(tǒng)要求（時間約束、資源的限制等）是緊密聯系的，用最終形式的源程序驗證系統(tǒng)的模型更準確。

Rhapsody可利用軟件自動生成技術的成果，根據模型可以自動生成具有產品質量的代碼。這種代碼既可以作為系統(tǒng)模型驗證的代碼，也是系統(tǒng)最后提交的代碼。所以產生的代碼是基于某個具體平臺的代碼，通過編譯即可運行在該平臺上。本文采用的是美國 Wind River System 公司推出的一個實時操作系統(tǒng)VxWorks。它是一個運行在目標機上的高性能、可裁剪的嵌入式實時操作系統(tǒng)。

一旦自動取款機系統(tǒng)被設計、實現和測試后，它就能在實時多任務操作系統(tǒng)VxWorks上實現。1個鍵盤、1個LCD液晶顯示屏、1個插卡孔、1 根與銀行的上位機相連的雙絞線和1個輸出現金口經由I/O板連接到1個目標板上。

從Ihardware類繼承而來并選中set選項而創(chuàng)建新類HwIrq。這些操作的實例可以被寫進Rhapsody中。為了寫到I/O板中，使用VxWorks系統(tǒng)的操作sysOutByte。

HwIrq類已經被設置成一個活動類，所以它能在自己的線程運行，線程的參數被配置如下：線程名為tRhpHw，堆棧長度為4096字節(jié)，優(yōu)先級為180。

HwIrq.cpp的部分程序見本文附件。

4 結論

本文運用基于UML的嵌入式實時應用軟件開發(fā)環(huán)境Rhapsody來設計和實現自動取款機系統(tǒng)的模型。與傳統(tǒng)的嵌入式軟件開發(fā)方法相比，具有明顯的優(yōu)勢。它大大縮短了產品的開發(fā)周期，解決了嵌入式應用軟件的移植問題，使軟件的開發(fā)工作主要集中在高層的建模和模型的測試及驗證上，從而使軟件開發(fā)工作的焦點從編碼轉到了設計上。

責任編輯：gt