登錄 注冊
購物車0
TOP
Imgs 行業(yè)資訊

0

基于UML嵌入式軟件開發(fā)環(huán)境的自動(dòng)取款機(jī)系統(tǒng)的應(yīng)用方案

2021-03-22 11:27:48

引言
隨著嵌入式應(yīng)用的不斷增長,嵌入式系統(tǒng)需求的復(fù)雜性、不確定性不斷提高,系統(tǒng)規(guī)模也逐步擴(kuò)大;而產(chǎn)品的研發(fā)周期又在很快地縮短,給嵌入式應(yīng)用軟件的開發(fā)帶來了新的挑戰(zhàn)。同時(shí),嵌入式軟件的開發(fā)者必須面對由于芯片性能的增長、嵌入式操作系統(tǒng)平臺等技術(shù)方面不斷變化所帶來的各種壓力。嵌入式軟件開發(fā)環(huán)境的發(fā)展,使一直“深埋”于系統(tǒng)的嵌入式應(yīng)用軟件變得開放而易于開發(fā),從而促進(jìn)了嵌入式技術(shù)的廣泛應(yīng)用。
1基于UML的嵌入式軟件開發(fā)環(huán)境結(jié)構(gòu)
圖1所示為一種支持基于UML(UnifiedModelingLanguage,統(tǒng)一建模語言)的迭代式開發(fā)方法的開發(fā)環(huán)境的結(jié)構(gòu),虛框部分為基于UML的軟件開發(fā)環(huán)境。
基于UML嵌入式軟件開發(fā)環(huán)境的自動(dòng)取款機(jī)系統(tǒng)的應(yīng)用方案
基于UML嵌入式軟件開發(fā)環(huán)境的自動(dòng)取款機(jī)系統(tǒng)的應(yīng)用方案
圖1基于UML嵌入式軟件開發(fā)環(huán)境的結(jié)構(gòu)
系統(tǒng)分析和設(shè)計(jì)用UML來描述,對系統(tǒng)建模;實(shí)現(xiàn)過程利用代碼自動(dòng)生成技術(shù)來實(shí)現(xiàn);測試過程將依賴于生成的代碼,通過在代碼中拆裝一些用于支持模型調(diào)試的調(diào)試信息來實(shí)現(xiàn);而代碼的編譯、鏈接則采用目標(biāo)系統(tǒng)的操作系統(tǒng)開發(fā)環(huán)境來完成,代碼的運(yùn)行與源程序級的調(diào)試仍然采用一般的嵌入式軟件調(diào)試環(huán)境。
Rhapsody是一個(gè)基于UML的面向嵌入式實(shí)時(shí)應(yīng)用開發(fā)的集成、可視化環(huán)境。軟件開發(fā)者可以在這個(gè)環(huán)境里進(jìn)行分析、設(shè)計(jì)、實(shí)現(xiàn)及驗(yàn)證。Rhapsody支持基于模型的調(diào)試;提供專門為實(shí)時(shí)嵌入式應(yīng)用設(shè)計(jì)的可執(zhí)行的框架,可以產(chǎn)生基于VxWorks、POS、OSE等多種操作系統(tǒng)的C++語言、C++語言、Java語言的源程序。本文所給出的自動(dòng)取款機(jī)系統(tǒng)的模型正是基于Rhapsody設(shè)計(jì)的。
2自動(dòng)取款機(jī)系統(tǒng)模型的設(shè)計(jì)
2.1需求分析
我們設(shè)計(jì)的自動(dòng)取款機(jī)系統(tǒng)要滿足如下要求:
在自動(dòng)取款機(jī)系統(tǒng)中,當(dāng)顧客在自動(dòng)取款機(jī)操作面板上插入信用卡并輸入密碼和現(xiàn)金支取數(shù)額(每次最多只能取一千元)后,由自動(dòng)取款機(jī)讀取卡上的內(nèi)容,并把相應(yīng)信息傳送到銀行。銀行把自動(dòng)取款機(jī)送來的信息與銀行帳號上的信息進(jìn)行比較,如果兩者一致,則銀行傳送確認(rèn)信息到自動(dòng)取款機(jī),由自動(dòng)取款機(jī)輸出現(xiàn)金,然后顧客取出卡和現(xiàn)金;如果兩者不一致,則要求顧客再次輸入密碼和現(xiàn)金支取數(shù)額,然后重復(fù)上述操作;若密碼輸入三次不正確,自動(dòng)取款機(jī)就會吞掉信用卡,顧客就不能取出信用卡和現(xiàn)金。
該自動(dòng)取款機(jī)系統(tǒng)包括1個(gè)鍵盤(10個(gè)數(shù)字鍵、ENTER鍵和CANCEL鍵)、1個(gè)LCD液晶顯示屏、1個(gè)插卡孔和1個(gè)現(xiàn)金出口;通過雙絞線與銀行中的電腦進(jìn)行串行通信。該自動(dòng)取款機(jī)系統(tǒng)不包括銀行中的電腦,只是通過軟件與銀行中的上位機(jī)進(jìn)行串行通信。
2.2可視化建模
建模是面向?qū)ο蠓治龊驮O(shè)計(jì)的核心,也是分析和設(shè)計(jì)過程中最基本和最關(guān)鍵的活動(dòng)之一。UML不僅適用于以面向?qū)ο蠹夹g(shù)描述的任何類型的系統(tǒng),而且適用于系統(tǒng)開發(fā)的不同階段。根據(jù)開發(fā)過程中不同階段的具體要求,利用UML不同類型的圖來描述系統(tǒng)的各種靜態(tài)結(jié)構(gòu)模型和動(dòng)態(tài)行為模型。下面介紹如何利用基于UML的面向嵌入式實(shí)時(shí)應(yīng)用開發(fā)的集成可視化環(huán)境Rhapsody創(chuàng)建自動(dòng)取款機(jī)系統(tǒng)的模型。
第一步:根據(jù)要求建立用例圖。
圖2所示為用例圖。圖中給出了自動(dòng)取款機(jī)系統(tǒng)的主要用途,并表明由誰使用自動(dòng)取款機(jī)系統(tǒng)。有一個(gè)主要成員——顧客。一個(gè)用例圖應(yīng)該具有這樣的系統(tǒng)功能:對操作者而言,它返回可觀察的結(jié)果但并不顯示系統(tǒng)的內(nèi)在結(jié)構(gòu)。

圖2自動(dòng)取款機(jī)系統(tǒng)的用例圖
自動(dòng)取款機(jī)系統(tǒng)的主要用途是“取出現(xiàn)金”用例。顧客參與其中的兩個(gè)實(shí)例是“輸入密碼”和“取出現(xiàn)金”。這兩個(gè)實(shí)例都包含了另一個(gè)用例“讀取卡上內(nèi)容并驗(yàn)證”。對每一個(gè)用例而言,我們都可以增加文本描述。假如需要的話,這些用例能夠被細(xì)化成另一張更多用例的圖。這些用例并沒有顯示任何內(nèi)在的結(jié)構(gòu),僅是一個(gè)功能性的視圖。
第二步:設(shè)計(jì)黑匣子場景。
建立了一個(gè)用例圖后,下一步便是細(xì)化用例,即設(shè)計(jì)一些黑匣子場景。這些黑匣子場景的主要作用是表明模型和對象之間的相互關(guān)系。把整個(gè)系統(tǒng)看作一個(gè)整體,對“取出現(xiàn)金”用例,我們細(xì)化為圖3所示的場景。(由于每次最多只能取一千元,所以最多只需要按鍵4次。)

圖3取出現(xiàn)金的黑匣子場景
圖3所示的場景能被MSD(消息序列表)捕獲,用來描述在顧客和自動(dòng)取款機(jī)系統(tǒng)之間的通信行為。當(dāng)創(chuàng)建這樣的圖表時(shí),關(guān)于系統(tǒng)的更多細(xì)節(jié)被隱藏了;同時(shí),這些場景幫助我們更好地理解使用者如何使用報(bào)警系統(tǒng)以及需要做哪些事情??偠灾恳挥美加泻芏嗟膱鼍靶枰东@,每一個(gè)場景都是用例的一個(gè)有效的實(shí)例。
第三步:設(shè)計(jì)子系統(tǒng)圖。
下一步是如何把模型分割成子系統(tǒng)。在UML中,一個(gè)子系統(tǒng)作為一個(gè)封裝顯示,即主要是一個(gè)類的集合。圖4的子系統(tǒng)圖表明自動(dòng)取款機(jī)系統(tǒng)已經(jīng)被分解成兩個(gè)基本的部分:自動(dòng)柜員機(jī)封裝(AtmerPkg)和硬件封裝(HardharePkg)。同時(shí)也表明:自動(dòng)柜員機(jī)封裝是完全獨(dú)立于實(shí)際的硬件和硬件封裝的,并且實(shí)現(xiàn)了Ihardware接口能夠用于連接自動(dòng)柜員機(jī)封裝。接口類Ihardware描述了對自動(dòng)柜員機(jī)封裝的所有必需的操作,實(shí)現(xiàn)了應(yīng)用與硬件環(huán)境的隔離。

圖4自動(dòng)取款機(jī)系統(tǒng)的子系統(tǒng)
一旦在自動(dòng)柜員機(jī)封裝和硬件封裝之間定義了接口類,每一個(gè)子系統(tǒng)就能同步和獨(dú)立地細(xì)化為更多的子系統(tǒng)。每一個(gè)子系統(tǒng)都知道它和其它子系統(tǒng)之間的接口。例如,我們可以開始分析自動(dòng)柜員機(jī)子系統(tǒng)圖,而不需要知道關(guān)于硬件的更多情況。
第四步:設(shè)計(jì)對象模型圖。
對自動(dòng)柜員機(jī)封裝而言,我們設(shè)想有一個(gè)AtmerController類,其中包含Keypad類、Card類、LCD類和Cash類,這些類表示如圖5所示。

圖5AtmerController類的對象模型
圖5表明:AtmerController類作為一個(gè)聚合類,包含了其它類的實(shí)例。我們也能看出,我們能選擇顯示“Keypad”類的不同的操作和屬性。在上面的例子中,假如一個(gè)實(shí)例被AtmerControlle類創(chuàng)建,那么它將創(chuàng)建Keypad類的一個(gè)實(shí)例theKeypad、LCD類的一個(gè)實(shí)例theLCD、Cash類的一個(gè)實(shí)例theCash以及Card類的一個(gè)實(shí)例theCard。假如AtmerController類的實(shí)例被刪除,這些包含的實(shí)例也同時(shí)被刪除。
Ihardware類也有一些純虛函數(shù),所以為了測試AtmerController類,必須忽略這些操作。圖6表示:ATM包含了AtmerController類的一個(gè)實(shí)例和從Ihardware類繼承并忽略了其操作的Hw類的一個(gè)實(shí)例。

圖6ATM對象模型圖
第五步:生成白匣子場景。
生成了一個(gè)新類AtmerController后,就可以開始為每一個(gè)黑匣子場景生成白匣子場景。消息序列表將用于獲取以上不同場景的類的實(shí)例之間的通信行為。例如,圖7消息序列描述了顧客輸入支取現(xiàn)金數(shù)額并取出現(xiàn)金的場景。

圖7顧客輸入支取現(xiàn)金數(shù)額并取出現(xiàn)金的場景
消息通常對應(yīng)于對象模型中操作和操作的返回值。消息值對應(yīng)于類的屬性或是類操作的返回值。消息可以是同步的,也可以是異步的。從圖中可以看出,這些類都有動(dòng)態(tài)行為:它們正在處理定時(shí)事件;調(diào)用其它類的操作;接受事件。對UML來說,這些動(dòng)態(tài)行為都可以用一個(gè)狀態(tài)圖來表示。
第六步:創(chuàng)建狀態(tài)圖。
以顧客輸入密碼過程為例,創(chuàng)建狀態(tài)圖,如圖8所示。通常,當(dāng)一個(gè)問題很復(fù)雜時(shí),它往往被分解成一些簡單的問題,這也正是對顧客輸入密碼過程要做的事情。圖8所示的狀態(tài)圖描述了顧客輸入密碼過程中的行為。

圖8顧客輸入密碼過程的狀態(tài)圖
2.3屬性、操作和事件
屬性來源于需求文檔中定義的數(shù)據(jù),應(yīng)該簡單,不考慮設(shè)計(jì)和實(shí)現(xiàn)的細(xì)節(jié)。每個(gè)類都可能有定義在其上的事件和操作。事件對應(yīng)于明確的瞬時(shí)發(fā)生的影響類的動(dòng)態(tài)行為。操作對應(yīng)于類的服務(wù)和功能。Rhapsody中有3種事件。
①信號事件:對應(yīng)于實(shí)例間的異步通信。
②時(shí)間事件:這種事件在進(jìn)入一個(gè)狀態(tài)并且經(jīng)過一個(gè)指定的時(shí)間后觸發(fā)。
③觸發(fā)操作:觸發(fā)操作是同步的操作,通過能夠迅速得到響應(yīng)的事件得到執(zhí)行。觸發(fā)操作沒有實(shí)現(xiàn)代碼,卻可以作為類的狀態(tài)圖轉(zhuǎn)移的觸發(fā)器。當(dāng)調(diào)用觸發(fā)操作時(shí),同時(shí)產(chǎn)生響應(yīng)的事件。
2.4生成代碼
一般嵌入式應(yīng)用中有60%~90%的代碼用于內(nèi)務(wù)處理(如狀態(tài)圖的實(shí)現(xiàn)、任務(wù)間的通信等),這些代碼在設(shè)計(jì)新的系統(tǒng)時(shí)一般都可以重用。這種重用一般是通過實(shí)時(shí)框架來實(shí)現(xiàn)的。Rhapsody就提供了這樣一個(gè)實(shí)時(shí)框架,它提供了一套嵌入式和實(shí)時(shí)應(yīng)用專門選擇和優(yōu)化的設(shè)計(jì)模板。嵌入式應(yīng)用程序一般都運(yùn)行在嵌入式操作系統(tǒng)的平臺上,而實(shí)時(shí)框架就是一個(gè)在操作系統(tǒng)之上應(yīng)用程序之下的中間件。應(yīng)用程序的編寫或自動(dòng)產(chǎn)生都基于有統(tǒng)一接口的實(shí)時(shí)框架,這樣就使應(yīng)用軟件的開發(fā)與具體的平臺無關(guān),解決了嵌入式應(yīng)用軟件的移植問題。
一旦畫出其余的圖表并創(chuàng)建好不同類的實(shí)例后,就能進(jìn)行代碼的生成和模型的測試工作。在Rhapsody中,需要進(jìn)行一些配置,以告訴Rhapsody從哪些類生成代碼及使用什么樣的環(huán)境。首先,使用Microsoft環(huán)境(Windows操作環(huán)境和VisualC++編譯器)。然后,代碼在Rhapsody中生成和編譯,以產(chǎn)生可執(zhí)行程序。
2.5使UML模型有效
Rhapsody能使用自動(dòng)生成的代碼,所以,當(dāng)實(shí)際的代碼運(yùn)行時(shí),它能返回一些信息給調(diào)試工具,以便Rhapsody進(jìn)行模型的測試。通過模型級調(diào)試、驗(yàn)證,可以盡早發(fā)現(xiàn)系統(tǒng)的設(shè)計(jì)錯(cuò)誤或缺陷,從而較早地確定或降低項(xiàng)目的風(fēng)險(xiǎn)。
2.6測試模型
一旦自動(dòng)柜員機(jī)封裝被手工產(chǎn)生的事件測試通過并觀察發(fā)生的情況后,就可以利用如微軟的VisualC++產(chǎn)生一個(gè)GUI。用于創(chuàng)建GUI的類從Ihardware類繼承而來,選中set選項(xiàng),當(dāng)按鈕被按下時(shí),調(diào)用ON操作。GUI也能促使模型在模型級再次被調(diào)試。
3在VxWorks上運(yùn)行
模型是系統(tǒng)整體的抽象。軟件開發(fā)的最終形式必須生成程序代碼,模型畢竟是一些漂亮的藍(lán)圖。雖然它對軟件的設(shè)計(jì)有很大的作用,但用戶的最終目的是希望得到可執(zhí)行的程序。對于嵌入式實(shí)時(shí)系統(tǒng),代碼與系統(tǒng)要求(時(shí)間約束、資源的限制等)是緊密聯(lián)系的,用最終形式的源程序驗(yàn)證系統(tǒng)的模型更準(zhǔn)確。
Rhapsody可利用軟件自動(dòng)生成技術(shù)的成果,根據(jù)模型可以自動(dòng)生成具有產(chǎn)品質(zhì)量的代碼。這種代碼既可以作為系統(tǒng)模型驗(yàn)證的代碼,也是系統(tǒng)最后提交的代碼。所以產(chǎn)生的代碼是基于某個(gè)具體平臺的代碼,通過編譯即可運(yùn)行在該平臺上。本文采用的是美國WindRiverSystem公司推出的一個(gè)實(shí)時(shí)操作系統(tǒng)VxWorks。它是一個(gè)運(yùn)行在目標(biāo)機(jī)上的高性能、可裁剪的嵌入式實(shí)時(shí)操作系統(tǒng)。
從Ihardware類繼承而來并選中set選項(xiàng)而創(chuàng)建新類HwIrq。這些操作的實(shí)例可以被寫進(jìn)Rhapsody中。為了寫到I/O板中,使用VxWorks系統(tǒng)的操作sysOutByte。
HwIrq類已經(jīng)被設(shè)置成一個(gè)活動(dòng)類,所以它能在自己的線程運(yùn)行,線程的參數(shù)被配置如下:線程名為tRhpHw,堆棧長度為4096字節(jié),優(yōu)先級為180。
HwIrq.cpp的部分程序見本文附件。
4結(jié)論
本文運(yùn)用基于UML的嵌入式實(shí)時(shí)應(yīng)用軟件開發(fā)環(huán)境Rhapsody來設(shè)計(jì)和實(shí)現(xiàn)自動(dòng)取款機(jī)系統(tǒng)的模型。與傳統(tǒng)的嵌入式軟件開發(fā)方法相比,具有明顯的優(yōu)勢。它大大縮短了產(chǎn)品的開發(fā)周期,解決了嵌入式應(yīng)用軟件的移植問題,使軟件的開發(fā)工作主要集中在高層的建模和模型的測試及驗(yàn)證上,從而使軟件開發(fā)工作的焦點(diǎn)從編碼轉(zhuǎn)到了設(shè)計(jì)上。

高都電子,為客戶創(chuàng)造價(jià)值!

雙面板免費(fèi)加費(fèi),四層板加急打樣,厚銅電路板打樣

Xcm