摘　要　 近年來(lái)，在嵌入式領(lǐng)域中缺乏一個(gè)成熟的始終一貫的形式化開(kāi)發(fā)方法，這已成為制約嵌入式系統(tǒng)發(fā)展的瓶頸之一。本文結(jié)合統(tǒng)一建模語(yǔ)言UML，對(duì)嵌入式系統(tǒng)開(kāi)發(fā)方法進(jìn)行了有益的探索研究，提出了一種基于UML的適合于嵌入式系統(tǒng)的形式化開(kāi)發(fā)方法，并以嵌入式遠(yuǎn)程溫度監(jiān)控系統(tǒng)為例，驗(yàn)證了該方法的可行性和有效性。

關(guān)鍵詞　 UML，嵌入式系統(tǒng)，形式化開(kāi)發(fā)方法

中圖分類號(hào)： TP31 文獻(xiàn)標(biāo)示碼： A

1 引言

隨著信息產(chǎn)業(yè)和微電子技術(shù)的發(fā)展，嵌入式系統(tǒng)的功能日漸強(qiáng)大，結(jié)構(gòu)也愈加復(fù)雜，傳統(tǒng)的嵌入式開(kāi)發(fā)方法已不能滿足開(kāi)發(fā)要求,人們開(kāi)始嘗試用一些形式化的開(kāi)發(fā)方法進(jìn)行開(kāi)發(fā)。一種適合于嵌入式系統(tǒng)的形式化開(kāi)發(fā)方法，不僅能縮短嵌入式系統(tǒng)開(kāi)發(fā)的周期，還能減少開(kāi)發(fā)成本，提高系統(tǒng)質(zhì)量。本文結(jié)合統(tǒng)一建模語(yǔ)言UML，提出一種嵌入式系統(tǒng)可視化開(kāi)發(fā)方法，并將其實(shí)際運(yùn)用到了嵌入式遠(yuǎn)程溫度監(jiān)控系統(tǒng)的開(kāi)發(fā)過(guò)程中，驗(yàn)證了該方法的可行性和有效性。

2 基于UML 的嵌入式系統(tǒng)可視化開(kāi)發(fā)方法

2.1 　統(tǒng)一建模語(yǔ)言UML

UML(Unified Modeling Language) 是一種定義良好、易于表達(dá)、功能強(qiáng)大且普遍適用的面向?qū)ο蠛突跇?gòu)件的系統(tǒng)建模語(yǔ)言。它擴(kuò)展了現(xiàn)有方法的應(yīng)用范圍，不僅可建立軟件系統(tǒng)的模型，還可建立非軟件系統(tǒng)的模型，可廣泛用于描述系統(tǒng)軟件、嵌入式系統(tǒng)、企業(yè)機(jī)構(gòu)或業(yè)務(wù)過(guò)程等。 UML由圖、視圖、模型元素、通用機(jī)制和擴(kuò)展機(jī)制等幾個(gè)部分組成 [2] 。其中圖是UML建模的關(guān)鍵，根據(jù)圖在系統(tǒng)開(kāi)發(fā)過(guò)程中不同階段的應(yīng)用，可以分為用例圖、靜態(tài)圖、行為圖、交互圖、實(shí)現(xiàn)圖等五類，這些圖為系統(tǒng)的開(kāi)發(fā)提供了多種圖形表達(dá)形式，應(yīng)用于建模的不同階段。

2.2 　將UML 語(yǔ)言應(yīng)用于嵌入式系統(tǒng)開(kāi)發(fā)的優(yōu)勢(shì)

隨著嵌入式系統(tǒng)的日趨復(fù)雜化，較多的系統(tǒng)都需要由一個(gè)團(tuán)隊(duì)共同完成，因此，團(tuán)隊(duì)成員之間的相互合作，軟硬件之間的協(xié)同開(kāi)發(fā)，乃至開(kāi)發(fā)人員和客戶之間的交流都需要有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)作為基礎(chǔ)。UML正是這樣一種標(biāo)準(zhǔn)的系統(tǒng)建模語(yǔ)言。它詳細(xì)描述系統(tǒng)的內(nèi)容和工作方法，先進(jìn)行系統(tǒng)建模后再編寫(xiě)代碼，在開(kāi)始階段就保證了系統(tǒng)結(jié)構(gòu)的合理性。UML系統(tǒng)模型包含許多不同框圖，使項(xiàng)目小組可以從不同角度了解整個(gè)系統(tǒng)。另外,UML可以用統(tǒng)一的形式表現(xiàn)軟件和硬件，支持循環(huán)迭代并可多次修改軟硬件方案直到滿足要求，可實(shí)現(xiàn)軟硬件協(xié)同設(shè)計(jì)。 特別的，UML是一種語(yǔ)言，不是方法，它獨(dú)立于開(kāi)發(fā)過(guò)程 [3] ，所以我們可以結(jié)合UML語(yǔ)言提出一套針對(duì)嵌入式系統(tǒng)的開(kāi)發(fā)過(guò)程，從而為嵌入式系統(tǒng)的開(kāi)發(fā)提供一條新的途徑。

2.3 　基于UML 的嵌入式系統(tǒng)可視化開(kāi)發(fā)方法

文中提出的基于UML的嵌入式系統(tǒng)開(kāi)發(fā)方法支持需求、分析、設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試的循環(huán)迭代，使用面向?qū)ο笏枷?，通過(guò)細(xì)化分析和設(shè)計(jì)階段的步驟，使得整個(gè)過(guò)程更有條理、充實(shí)，更適合于多任務(wù)的嵌入式系統(tǒng)開(kāi)發(fā)。方法的需求、分析、設(shè)計(jì)過(guò)程被細(xì)化后分別包括了以下幾個(gè)步驟：

· 需求階段明確了系統(tǒng)所要實(shí)現(xiàn)的功能以及所要達(dá)到的性能，是整個(gè)系統(tǒng)開(kāi)發(fā)的目標(biāo)。

功能性需求：明確系統(tǒng)應(yīng)該提供什么功能。

非功能性需求：明確系統(tǒng)的特定特性或者約束。

· 分析階段主要是精化和結(jié)構(gòu)化需求，清楚地描述系統(tǒng)內(nèi)部，是設(shè)計(jì)階段的基礎(chǔ)。分為兩個(gè)步驟：

系統(tǒng)架構(gòu)分析：運(yùn)用面向?qū)ο蠹夹g(shù)描述系統(tǒng)的靜態(tài)結(jié)構(gòu)。

系統(tǒng)行為分析：從動(dòng)態(tài)的角度描述系統(tǒng)的對(duì)象間相互作用的特性。

· 設(shè)計(jì)階段是在對(duì)系統(tǒng)各方面有了解的基礎(chǔ)上來(lái)確定特定的解決方案。分為兩個(gè)步驟：

分層結(jié)構(gòu)設(shè)計(jì)：確定了具體實(shí)現(xiàn)時(shí)軟件和硬件的最佳分界。

詳細(xì)設(shè)計(jì)：在軟件方面是深入到了系統(tǒng)低層信息，如操作的屬性、類的流程等；硬件方面則是到了設(shè)計(jì)具體電路板的階段。

本方法利用面向?qū)ο蟮母拍顚⑾到y(tǒng)分成了相互關(guān)聯(lián)卻又較獨(dú)立的模塊，一方面方便了系統(tǒng)開(kāi)發(fā)時(shí)的迭代過(guò)程以及系統(tǒng)的后期維護(hù)，設(shè)計(jì)人員可以根據(jù)不同的新的需要對(duì)各個(gè)步驟中相應(yīng)部分進(jìn)行調(diào)整來(lái)實(shí)現(xiàn)改進(jìn)，這樣就可以大量減少重復(fù)分析或設(shè)計(jì)的過(guò)程；另一方面，對(duì)象概念可以和嵌入式系統(tǒng)中的任務(wù)概念很好的映射起來(lái)。任務(wù)可看成是由一個(gè)或多個(gè)對(duì)象協(xié)作而成的，在分析、設(shè)計(jì)過(guò)程中確立對(duì)象的同時(shí)也就確定了系統(tǒng)的多個(gè)任務(wù)，為嵌入式系統(tǒng)的多任務(wù)特性提供了很好的支持。

本文后續(xù)部分將以嵌入式遠(yuǎn)程溫度監(jiān)控系統(tǒng)為例，簡(jiǎn)單闡述和驗(yàn)證此方法。

3 系統(tǒng)需求

3.1 功能性需求

功能性需求是系統(tǒng)功能的陳述。在UML中是應(yīng)用用例圖來(lái)描述系統(tǒng)功能的。如圖1所示，系統(tǒng)大致由下述幾個(gè)角色和用例組成:

本文引用地址：http://www.biyoush.com/article/201706/349390.htm 三個(gè)角色：數(shù)字式測(cè)溫儀，Internet遠(yuǎn)端用戶，本地用戶。

五個(gè)用例：當(dāng)前溫度信息顯示、更改最高警戒溫度、更改最低警戒溫度、修改測(cè)溫儀工作狀態(tài)以及登陸服務(wù)器（身份驗(yàn)證）。
以上的各個(gè)用例只是對(duì)系統(tǒng)功能的大致劃分，主要目的是為后面的系統(tǒng)分析作基礎(chǔ)。

3.2 非功能性需求

非功能性需求是系統(tǒng)的特定特性。本系統(tǒng)的非功能性需求是：

溫度測(cè)量范圍要求0-400℃，顯示精度 為0.2℃。

在工業(yè)現(xiàn)場(chǎng)，遠(yuǎn)程監(jiān)控系統(tǒng)對(duì)數(shù)字式測(cè)溫儀實(shí)現(xiàn)無(wú)線監(jiān)控。

遠(yuǎn)程監(jiān)控系統(tǒng)為Internet遠(yuǎn)端用戶提供統(tǒng)一開(kāi)放的平臺(tái)，

遠(yuǎn)程監(jiān)控系統(tǒng)每秒自動(dòng)更新提供給用戶的溫度信息。

遠(yuǎn)程監(jiān)控系統(tǒng)也為本地用戶提供友好的人機(jī)交互界面。

可以看出，這些非功能性需求為確定系統(tǒng)的結(jié)構(gòu)和系統(tǒng)選用的技術(shù)等進(jìn)行了約束。

4 系統(tǒng)分析

在系統(tǒng)分析階段，通過(guò)細(xì)化和結(jié)構(gòu)化系統(tǒng)需求，可將系統(tǒng)需求轉(zhuǎn)換成系統(tǒng)中的結(jié)構(gòu)、類、對(duì)象和關(guān)系等實(shí)體元素，并從靜態(tài)和動(dòng)態(tài)兩個(gè)角度來(lái)清楚描述這些實(shí)體元素。

4.1 　系統(tǒng)結(jié)構(gòu)分析

系統(tǒng)結(jié)構(gòu)分析是對(duì)系統(tǒng)元素靜態(tài)的描述，它在系統(tǒng)需求的基礎(chǔ)上確定系統(tǒng)的總體架構(gòu)及內(nèi)部對(duì)象。

首先用部署圖來(lái)描述系統(tǒng)的物理架構(gòu)，如圖2所示，其中帶有陰影的為處理器，未帶有陰影的是外部設(shè)備；系統(tǒng)采用了目前遠(yuǎn)程監(jiān)控系統(tǒng)中比較流行的瀏覽器/服務(wù)器模式（B/S）。這樣系統(tǒng)的4個(gè)功能用例都將主要由嵌入式Web服務(wù)器實(shí)現(xiàn)。此外，根據(jù)非功能性需求中的無(wú)線監(jiān)控約束，在工控現(xiàn)場(chǎng)，運(yùn)用了藍(lán)牙技術(shù)。

然后用類圖來(lái)描述系統(tǒng)靜態(tài)的對(duì)象結(jié)構(gòu)及其相互關(guān)系。從用例圖(圖1)中我們可分解出一些類，并將這些類之間的結(jié)構(gòu)描述出來(lái)。比如從遠(yuǎn)端用戶的“登錄服務(wù)器”用例就可分解出嵌入式Web服務(wù)器中的網(wǎng)卡、TCP/IP、HTTP類，本地用戶的“登錄服務(wù)器”用例則可分解出嵌入式Web服務(wù)器中的鍵盤(pán)、顯示器和本地監(jiān)控等類。依次略推在嵌入式Web 服務(wù)器中共定義了網(wǎng)卡、TCP/IP、HTTP、藍(lán)牙模塊、鍵盤(pán)、顯示屏、本地監(jiān)控、數(shù)據(jù)處理等類。

每個(gè)類可以設(shè)置屬性和操作，但我們?cè)谶@個(gè)步驟中并沒(méi)有定義，而僅僅是對(duì)嵌入式Web服務(wù)器的 對(duì)象結(jié)構(gòu)作靜態(tài)描述，類的屬性和操作的定義將隨著完整的類圖在后文中出現(xiàn)。

4.2 系統(tǒng)行為分析

系統(tǒng)行為分析就是從多個(gè)角度來(lái)描述所研究系統(tǒng)的動(dòng)態(tài)部分。我們可用狀態(tài)圖描述系統(tǒng)的狀態(tài)行為，然后根據(jù)系統(tǒng)內(nèi)部所具有的行為來(lái)定義和精化類的操作，另外也可用順序圖和協(xié)作圖從不同的角度來(lái)顯示動(dòng)態(tài)的信息流。

這里采用嵌入式Web服務(wù)器的狀態(tài)圖來(lái)簡(jiǎn)單說(shuō)明（如圖3所示）。根據(jù)嵌入式系統(tǒng)的特點(diǎn)，在此處，狀態(tài)圖不但包括嵌套層次結(jié)構(gòu)狀態(tài)的概念，還可用并發(fā)的概念來(lái)表示那些可以和其他狀態(tài)同時(shí)處于活動(dòng)狀態(tài)的獨(dú)立狀態(tài)，圖中用虛線表示。

圖 3 嵌入式Web服務(wù)器狀態(tài)圖

5 系統(tǒng)設(shè)計(jì)

設(shè)計(jì)階段是在對(duì)系統(tǒng)各方面都有充分了解的基礎(chǔ)上確定特定的解決方案。

5.1 層次結(jié)構(gòu)設(shè)計(jì)

我們?cè)谙到y(tǒng)的分析階段，一直使用統(tǒng)一的標(biāo)識(shí)來(lái)描述系統(tǒng)，但系統(tǒng)具體實(shí)現(xiàn)時(shí)還是需要將軟、硬件分開(kāi)實(shí)現(xiàn)，所以我們要在系統(tǒng)設(shè)計(jì)階段對(duì)軟硬件層次進(jìn)行劃分。若這次的劃分最終不能滿足要求，也可以通過(guò)迭代在以后的循環(huán)中嘗試多種方案，直到滿足要求。

在系統(tǒng)結(jié)構(gòu)分析中用類圖所作的統(tǒng)一描述涵蓋了軟件層和硬件層共同組成的系統(tǒng)結(jié)構(gòu)，所有軟件層和硬件層都是由類圖中提取而來(lái)的，但類圖中既可由軟件實(shí)現(xiàn)又可由硬件提供的一部分內(nèi)容則要根據(jù)性能、價(jià)格、規(guī)格大小等因素來(lái)加以選擇。如本系統(tǒng)中TCP/IP協(xié)議棧的實(shí)現(xiàn)，就即可通過(guò)軟件編程，也可選擇購(gòu)買(mǎi)提供 TCP/IP協(xié)議棧的網(wǎng)卡芯片，相比較而言，自帶TCP/IP協(xié)議棧的網(wǎng)卡芯片提供的性能更高、更穩(wěn)定，但成本也較高，但本系統(tǒng)對(duì)網(wǎng)絡(luò)實(shí)現(xiàn)并沒(méi)有特別高的要求，所以從成本上考慮，還是選擇了軟件實(shí)現(xiàn)TCP/IP協(xié)議棧。這樣，TCP/IP協(xié)議棧也就將在軟件層中描述而不在硬件層中出現(xiàn)。

這里用部署圖描述的系統(tǒng)硬件層（如圖4），它將類圖中的數(shù)據(jù)處理對(duì)象，即軟件層中的操作系統(tǒng)所具有的任務(wù)映射到了處理器的各個(gè)線程，并且還設(shè)置了每個(gè)線程的優(yōu)先級(jí)。而藍(lán)牙模塊所帶的操作：藍(lán)牙底層協(xié)議，表示藍(lán)牙底層協(xié)議是由藍(lán)牙模塊硬件實(shí)現(xiàn)的。系統(tǒng)的軟件層也可以通過(guò)組件圖來(lái)描述。

5.2 詳細(xì)設(shè)計(jì)

詳細(xì)設(shè)計(jì)是一次循環(huán)中需求、分析、設(shè)計(jì)的最后一步，指定了細(xì)節(jié)問(wèn)題，明確了單個(gè)對(duì)象的范圍、內(nèi)數(shù)據(jù)結(jié)構(gòu)和算法的實(shí)現(xiàn)等。

先前已對(duì)類的屬性和操作作了定義，而在詳細(xì)設(shè)計(jì)中，為了編寫(xiě)代碼，必須對(duì)每個(gè)類中定義的操作的各個(gè)屬性（包括它的類型和初始值等）填補(bǔ)完整。因?yàn)榇藭r(shí)的類圖是為軟件編程準(zhǔn)備的，所以應(yīng)根據(jù)體系結(jié)構(gòu)設(shè)計(jì)過(guò)程中組件圖的內(nèi)容重新進(jìn)行整理，保留并細(xì)化由軟件實(shí)現(xiàn)的所有類。完整的類圖如圖5所示。

依照這些類的行為流程圖，在編程階段就可以容易的實(shí)現(xiàn)代碼，并且由于有了統(tǒng)一的設(shè)計(jì)決策， 即使是由不同的編程人員編寫(xiě)，最后的代碼體現(xiàn)出的思路都是大同小異的，也方便非開(kāi)發(fā)人員了解 和維護(hù)系統(tǒng)。

6 結(jié)束語(yǔ)

通過(guò)對(duì)UML語(yǔ)言的分析，文中提出了一種基于UML的嵌入式系統(tǒng)可視化開(kāi)發(fā)方法，并實(shí)際應(yīng)用到嵌入式遠(yuǎn)程溫度監(jiān)控系統(tǒng)的開(kāi)發(fā)過(guò)程中。此方法面向?qū)ο?，步驟清晰流暢，并全部由UML的統(tǒng)一標(biāo)準(zhǔn)符號(hào)加以描述，有效的提高了系統(tǒng)的開(kāi)發(fā)效率，也有利于系統(tǒng)以后的維護(hù)和升級(jí)。

參考文獻(xiàn)

[1] Bruce Powel Douglass 著 . 《實(shí)時(shí)UML——開(kāi)發(fā)嵌入式系統(tǒng)高效對(duì)象（第2版）》.中國(guó)電力出版社，2003年12月

[2] Wendy Boggs, Michael Boggs著，邱仲潘 等譯 . UML與Rational Rose 2002從入門(mén)到精通. 2002年7月，電子工業(yè)出版社，北京

[3] 唐英，李志蜀 . 使用UML分析設(shè)計(jì)嵌入式系統(tǒng) . 計(jì)算機(jī)應(yīng)用研究，2002年，5，p117-p120