一種基于UML 的嵌入式系統(tǒng)可視化開發(fā)方法
關鍵詞 UML,嵌入式系統(tǒng),形式化開發(fā)方法
中圖分類號: TP31 文獻標示碼: A
1 引言
隨著信息產(chǎn)業(yè)和微電子技術的發(fā)展,嵌入式系統(tǒng)的功能日漸強大,結構也愈加復雜,傳統(tǒng)的嵌入式開發(fā)方法已不能滿足開發(fā)要求,人們開始嘗試用一些形式化的開發(fā)方法進行開發(fā)。一種適合于嵌入式系統(tǒng)的形式化開發(fā)方法,不僅能縮短嵌入式系統(tǒng)開發(fā)的周期,還能減少開發(fā)成本,提高系統(tǒng)質量。本文結合統(tǒng)一建模語言UML,提出一種嵌入式系統(tǒng)可視化開發(fā)方法,并將其實際運用到了嵌入式遠程溫度監(jiān)控系統(tǒng)的開發(fā)過程中,驗證了該方法的可行性和有效性。
2 基于UML 的嵌入式系統(tǒng)可視化開發(fā)方法
2.1 統(tǒng)一建模語言UML
UML(Unified Modeling Language) 是一種定義良好、易于表達、功能強大且普遍適用的面向對象和基于構件的系統(tǒng)建模語言。它擴展了現(xiàn)有方法的應用范圍,不僅可建立軟件系統(tǒng)的模型,還可建立非軟件系統(tǒng)的模型,可廣泛用于描述系統(tǒng)軟件、嵌入式系統(tǒng)、企業(yè)機構或業(yè)務過程等。 UML由圖、視圖、模型元素、通用機制和擴展機制等幾個部分組成 [2] 。其中圖是UML建模的關鍵,根據(jù)圖在系統(tǒng)開發(fā)過程中不同階段的應用,可以分為用例圖、靜態(tài)圖、行為圖、交互圖、實現(xiàn)圖等五類,這些圖為系統(tǒng)的開發(fā)提供了多種圖形表達形式,應用于建模的不同階段。
2.2 將UML 語言應用于嵌入式系統(tǒng)開發(fā)的優(yōu)勢
隨著嵌入式系統(tǒng)的日趨復雜化,較多的系統(tǒng)都需要由一個團隊共同完成,因此,團隊成員之間的相互合作,軟硬件之間的協(xié)同開發(fā),乃至開發(fā)人員和客戶之間的交流都需要有一個統(tǒng)一的標準作為基礎。UML正是這樣一種標準的系統(tǒng)建模語言。它詳細描述系統(tǒng)的內(nèi)容和工作方法,先進行系統(tǒng)建模后再編寫代碼,在開始階段就保證了系統(tǒng)結構的合理性。UML系統(tǒng)模型包含許多不同框圖,使項目小組可以從不同角度了解整個系統(tǒng)。另外,UML可以用統(tǒng)一的形式表現(xiàn)軟件和硬件,支持循環(huán)迭代并可多次修改軟硬件方案直到滿足要求,可實現(xiàn)軟硬件協(xié)同設計。 特別的,UML是一種語言,不是方法,它獨立于開發(fā)過程 [3] ,所以我們可以結合UML語言提出一套針對嵌入式系統(tǒng)的開發(fā)過程,從而為嵌入式系統(tǒng)的開發(fā)提供一條新的途徑。
2.3 基于UML 的嵌入式系統(tǒng)可視化開發(fā)方法
文中提出的基于UML的嵌入式系統(tǒng)開發(fā)方法支持需求、分析、設計、實現(xiàn)、測試的循環(huán)迭代,使用面向對象思想,通過細化分析和設計階段的步驟,使得整個過程更有條理、充實,更適合于多任務的嵌入式系統(tǒng)開發(fā)。方法的需求、分析、設計過程被細化后分別包括了以下幾個步驟:
· 需求階段明確了系統(tǒng)所要實現(xiàn)的功能以及所要達到的性能,是整個系統(tǒng)開發(fā)的目標。
功能性需求:明確系統(tǒng)應該提供什么功能。
非功能性需求:明確系統(tǒng)的特定特性或者約束。
· 分析階段主要是精化和結構化需求,清楚地描述系統(tǒng)內(nèi)部,是設計階段的基礎。分為兩個步驟:
系統(tǒng)架構分析:運用面向對象技術描述系統(tǒng)的靜態(tài)結構。
系統(tǒng)行為分析:從動態(tài)的角度描述系統(tǒng)的對象間相互作用的特性。
· 設計階段是在對系統(tǒng)各方面有了解的基礎上來確定特定的解決方案。分為兩個步驟:
分層結構設計:確定了具體實現(xiàn)時軟件和硬件的最佳分界。
詳細設計:在軟件方面是深入到了系統(tǒng)低層信息,如操作的屬性、類的流程等;硬件方面則是到了設計具體電路板的階段。
本方法利用面向對象的概念將系統(tǒng)分成了相互關聯(lián)卻又較獨立的模塊,一方面方便了系統(tǒng)開發(fā)時的迭代過程以及系統(tǒng)的后期維護,設計人員可以根據(jù)不同的新的需要對各個步驟中相應部分進行調(diào)整來實現(xiàn)改進,這樣就可以大量減少重復分析或設計的過程;另一方面,對象概念可以和嵌入式系統(tǒng)中的任務概念很好的映射起來。任務可看成是由一個或多個對象協(xié)作而成的,在分析、設計過程中確立對象的同時也就確定了系統(tǒng)的多個任務,為嵌入式系統(tǒng)的多任務特性提供了很好的支持。
本文后續(xù)部分將以嵌入式遠程溫度監(jiān)控系統(tǒng)為例,簡單闡述和驗證此方法。
3 系統(tǒng)需求
3.1 功能性需求
功能性需求是系統(tǒng)功能的陳述。在UML中是應用用例圖來描述系統(tǒng)功能的。如圖1所示,系統(tǒng)大致由下述幾個角色和用例組成:本文引用地址:http://www.ex-cimer.com/article/201706/349390.htm 三個角色:數(shù)字式測溫儀,Internet遠端用戶,本地用戶。
五個用例:當前溫度信息顯示、更改最高警戒溫度、更改最低警戒溫度、修改測溫儀工作狀態(tài)以及登陸服務器(身份驗證)。
以上的各個用例只是對系統(tǒng)功能的大致劃分,主要目的是為后面的系統(tǒng)分析作基礎。
3.2 非功能性需求
非功能性需求是系統(tǒng)的特定特性。本系統(tǒng)的非功能性需求是:
溫度測量范圍要求0-400℃,顯示精度 為0.2℃。
在工業(yè)現(xiàn)場,遠程監(jiān)控系統(tǒng)對數(shù)字式測溫儀實現(xiàn)無線監(jiān)控。
遠程監(jiān)控系統(tǒng)為Internet遠端用戶提供統(tǒng)一開放的平臺,
遠程監(jiān)控系統(tǒng)每秒自動更新提供給用戶的溫度信息。
遠程監(jiān)控系統(tǒng)也為本地用戶提供友好的人機交互界面。
可以看出,這些非功能性需求為確定系統(tǒng)的結構和系統(tǒng)選用的技術等進行了約束。
4 系統(tǒng)分析
在系統(tǒng)分析階段,通過細化和結構化系統(tǒng)需求,可將系統(tǒng)需求轉換成系統(tǒng)中的結構、類、對象和關系等實體元素,并從靜態(tài)和動態(tài)兩個角度來清楚描述這些實體元素。
4.1 系統(tǒng)結構分析
系統(tǒng)結構分析是對系統(tǒng)元素靜態(tài)的描述,它在系統(tǒng)需求的基礎上確定系統(tǒng)的總體架構及內(nèi)部對象。
首先用部署圖來描述系統(tǒng)的物理架構,如圖2所示,其中帶有陰影的為處理器,未帶有陰影的是外部設備;系統(tǒng)采用了目前遠程監(jiān)控系統(tǒng)中比較流行的瀏覽器/服務器模式(B/S)。這樣系統(tǒng)的4個功能用例都將主要由嵌入式Web服務器實現(xiàn)。此外,根據(jù)非功能性需求中的無線監(jiān)控約束,在工控現(xiàn)場,運用了藍牙技術。
然后用類圖來描述系統(tǒng)靜態(tài)的對象結構及其相互關系。從用例圖(圖1)中我們可分解出一些類,并將這些類之間的結構描述出來。比如從遠端用戶的“登錄服務器”用例就可分解出嵌入式Web服務器中的網(wǎng)卡、TCP/IP、HTTP類,本地用戶的“登錄服務器”用例則可分解出嵌入式Web服務器中的鍵盤、顯示器和本地監(jiān)控等類。依次略推在嵌入式Web 服務器中共定義了網(wǎng)卡、TCP/IP、HTTP、藍牙模塊、鍵盤、顯示屏、本地監(jiān)控、數(shù)據(jù)處理等類。
每個類可以設置屬性和操作,但我們在這個步驟中并沒有定義,而僅僅是對嵌入式Web服務器的 對象結構作靜態(tài)描述,類的屬性和操作的定義將隨著完整的類圖在后文中出現(xiàn)。
4.2 系統(tǒng)行為分析
系統(tǒng)行為分析就是從多個角度來描述所研究系統(tǒng)的動態(tài)部分。我們可用狀態(tài)圖描述系統(tǒng)的狀態(tài)行為,然后根據(jù)系統(tǒng)內(nèi)部所具有的行為來定義和精化類的操作,另外也可用順序圖和協(xié)作圖從不同的角度來顯示動態(tài)的信息流。
這里采用嵌入式Web服務器的狀態(tài)圖來簡單說明(如圖3所示)。根據(jù)嵌入式系統(tǒng)的特點,在此處,狀態(tài)圖不但包括嵌套層次結構狀態(tài)的概念,還可用并發(fā)的概念來表示那些可以和其他狀態(tài)同時處于活動狀態(tài)的獨立狀態(tài),圖中用虛線表示。
圖 3 嵌入式Web服務器狀態(tài)圖
5 系統(tǒng)設計
設計階段是在對系統(tǒng)各方面都有充分了解的基礎上確定特定的解決方案。
5.1 層次結構設計
我們在系統(tǒng)的分析階段,一直使用統(tǒng)一的標識來描述系統(tǒng),但系統(tǒng)具體實現(xiàn)時還是需要將軟、硬件分開實現(xiàn),所以我們要在系統(tǒng)設計階段對軟硬件層次進行劃分。若這次的劃分最終不能滿足要求,也可以通過迭代在以后的循環(huán)中嘗試多種方案,直到滿足要求。
在系統(tǒng)結構分析中用類圖所作的統(tǒng)一描述涵蓋了軟件層和硬件層共同組成的系統(tǒng)結構,所有軟件層和硬件層都是由類圖中提取而來的,但類圖中既可由軟件實現(xiàn)又可由硬件提供的一部分內(nèi)容則要根據(jù)性能、價格、規(guī)格大小等因素來加以選擇。如本系統(tǒng)中TCP/IP協(xié)議棧的實現(xiàn),就即可通過軟件編程,也可選擇購買提供 TCP/IP協(xié)議棧的網(wǎng)卡芯片,相比較而言,自帶TCP/IP協(xié)議棧的網(wǎng)卡芯片提供的性能更高、更穩(wěn)定,但成本也較高,但本系統(tǒng)對網(wǎng)絡實現(xiàn)并沒有特別高的要求,所以從成本上考慮,還是選擇了軟件實現(xiàn)TCP/IP協(xié)議棧。這樣,TCP/IP協(xié)議棧也就將在軟件層中描述而不在硬件層中出現(xiàn)。
這里用部署圖描述的系統(tǒng)硬件層(如圖4),它將類圖中的數(shù)據(jù)處理對象,即軟件層中的操作系統(tǒng)所具有的任務映射到了處理器的各個線程,并且還設置了每個線程的優(yōu)先級。而藍牙模塊所帶的操作:藍牙底層協(xié)議,表示藍牙底層協(xié)議是由藍牙模塊硬件實現(xiàn)的。系統(tǒng)的軟件層也可以通過組件圖來描述。
5.2 詳細設計
詳細設計是一次循環(huán)中需求、分析、設計的最后一步,指定了細節(jié)問題,明確了單個對象的范圍、內(nèi)數(shù)據(jù)結構和算法的實現(xiàn)等。
先前已對類的屬性和操作作了定義,而在詳細設計中,為了編寫代碼,必須對每個類中定義的操作的各個屬性(包括它的類型和初始值等)填補完整。因為此時的類圖是為軟件編程準備的,所以應根據(jù)體系結構設計過程中組件圖的內(nèi)容重新進行整理,保留并細化由軟件實現(xiàn)的所有類。完整的類圖如圖5所示。
依照這些類的行為流程圖,在編程階段就可以容易的實現(xiàn)代碼,并且由于有了統(tǒng)一的設計決策, 即使是由不同的編程人員編寫,最后的代碼體現(xiàn)出的思路都是大同小異的,也方便非開發(fā)人員了解 和維護系統(tǒng)。
6 結束語
通過對UML語言的分析,文中提出了一種基于UML的嵌入式系統(tǒng)可視化開發(fā)方法,并實際應用到嵌入式遠程溫度監(jiān)控系統(tǒng)的開發(fā)過程中。此方法面向對象,步驟清晰流暢,并全部由UML的統(tǒng)一標準符號加以描述,有效的提高了系統(tǒng)的開發(fā)效率,也有利于系統(tǒng)以后的維護和升級。
參考文獻
[1] Bruce Powel Douglass 著 . 《實時UML——開發(fā)嵌入式系統(tǒng)高效對象(第2版)》.中國電力出版社,2003年12月
[2] Wendy Boggs, Michael Boggs著,邱仲潘 等譯 . UML與Rational Rose 2002從入門到精通. 2002年7月,電子工業(yè)出版社,北京
[3] 唐英,李志蜀 . 使用UML分析設計嵌入式系統(tǒng) . 計算機應用研究,2002年,5,p117-p120
評論