|
1 引言 隨著信息產(chǎn)業(yè)和微電子技術(shù)的發(fā)展，嵌入式系統(tǒng)的功能日漸強大，結(jié)構(gòu)也愈加復(fù)雜，傳統(tǒng)的嵌入式開發(fā)方法已不能滿足開發(fā)要求,人們開始嘗試用一些形式化的開發(fā)方法進行開發(fā)。一種適合于嵌入式系統(tǒng)的形式化開發(fā)方法，不僅能縮短嵌入式系統(tǒng)開發(fā)的周期，還能減少開發(fā)成本，提高系統(tǒng)質(zhì)量。 本文結(jié)合統(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) 是一種定義良好、易于表達、功能強大且普遍適用的面向?qū)ο蠛突跇?gòu)件的系統(tǒng)建模語言。它擴展了現(xiàn)有方法的應(yīng)用范圍，不僅可建立軟件系統(tǒng)的模型，還可建立非軟件系統(tǒng)的模型，可廣泛用于描述系統(tǒng)軟件、嵌入式系統(tǒng)、企業(yè)機構(gòu)或業(yè)務(wù)過程等。 UML由圖、視圖、模型元素、通用機制和擴展機制等幾個部分組成 。其中圖是UML建模的關(guān)鍵，根據(jù)圖在系統(tǒng)開發(fā)過程中不同階段的應(yīng)用，可以分為用例圖、靜態(tài)圖、行為圖、交互圖、實現(xiàn)圖等五類，這些圖為系統(tǒng)的開發(fā)提供了多種圖形表達形式，應(yīng)用于建模的不同階段。 2.2 將UML 語言應(yīng)用于嵌入式系統(tǒng)開發(fā)的優(yōu)勢 隨著嵌入式系統(tǒng)的日趨復(fù)雜化，較多的系統(tǒng)都需要由一個團隊共同完成，因此，團隊成員之間的相互合作，軟硬件之間的協(xié)同開發(fā)，乃至開發(fā)人員和客戶之間的交流都需要有一個統(tǒng)一的標準作為基礎(chǔ)。UML正是這樣一種標準的系統(tǒng)建模語言。它詳細描述系統(tǒng)的內(nèi)容和工作方法，先進行系統(tǒng)建模后再編寫代碼，在開始階段就保證了系統(tǒng)結(jié)構(gòu)的合理性。UML系統(tǒng)模型包含許多不同框圖，使項目小組可以從不同角度了解整個系統(tǒng)。另外,UML可以用統(tǒng)一的形式表現(xiàn)軟件和硬件，支持循環(huán)迭代并可多次修改軟硬件方案直到滿足要求，可實現(xiàn)軟硬件協(xié)同設(shè)計。 特別的，UML是一種語言，不是方法，它獨立于開發(fā)過程 ，所以我們可以結(jié)合UML語言提出一套針對嵌入式系統(tǒng)的開發(fā)過程，從而為嵌入式系統(tǒng)的開發(fā)提供一條新的途徑。 2.3 基于UML 的嵌入式系統(tǒng)可視化開發(fā)方法 文中提出的基于UML的嵌入式系統(tǒng)開發(fā)方法支持需求、分析、設(shè)計、實現(xiàn)、測試的循環(huán)迭代，使用面向?qū)ο笏枷耄ㄟ^細化分析和設(shè)計階段的步驟，使得整個過程更有條理、充實，更適合于多任務(wù)的嵌入式系統(tǒng)開發(fā)。方法的需求、分析、設(shè)計過程被細化后分別包括了以下幾個步驟： · 需求階段明確了系統(tǒng)所要實現(xiàn)的功能以及所要達到的性能，是整個系統(tǒng)開發(fā)的目標。 功能性需求：明確系統(tǒng)應(yīng)該提供什么功能。 非功能性需求：明確系統(tǒng)的特定特性或者約束。 · 分析階段主要是精化和結(jié)構(gòu)化需求，清楚地描述系統(tǒng)內(nèi)部，是設(shè)計階段的基礎(chǔ)。分為兩個步驟： 系統(tǒng)架構(gòu)分析：運用面向?qū)ο蠹夹g(shù)描述系統(tǒng)的靜態(tài)結(jié)構(gòu)。 系統(tǒng)行為分析：從動態(tài)的角度描述系統(tǒng)的對象間相互作用的特性。 · 設(shè)計階段是在對系統(tǒng)各方面有了解的基礎(chǔ)上來確定特定的解決方案。分為兩個步驟： 分層結(jié)構(gòu)設(shè)計：確定了具體實現(xiàn)時軟件和硬件的最佳分界。 詳細設(shè)計：在軟件方面是深入到了系統(tǒng)低層信息，如操作的屬性、類的流程等；硬件方面則是到了設(shè)計具體電路板的階段。 本方法利用面向?qū)ο蟮母拍顚⑾到y(tǒng)分成了相互關(guān)聯(lián)卻又較獨立的模塊，一方面方便了系統(tǒng)開發(fā)時的迭代過程以及系統(tǒng)的后期維護，設(shè)計人員可以根據(jù)不同的新的需要對各個步驟中相應(yīng)部分進行調(diào)整來實現(xiàn)改進，這樣就可以大量減少重復(fù)分析或設(shè)計的過程；另一方面，對象概念可以和嵌入式系統(tǒng)中的任務(wù)概念很好的映射起來。任務(wù)可看成是由一個或多個對象協(xié)作而成的，在分析、設(shè)計過程中確立對象的同時也就確定了系統(tǒng)的多個任務(wù)，為嵌入式系統(tǒng)的多任務(wù)特性提供了很好的支持。 本文后續(xù)部分將以嵌入式遠程溫度監(jiān)控系統(tǒng)為例，簡單闡述和驗證此方法。 3 系統(tǒng)需求 3.1 功能性需求 功能性需求是系統(tǒng)功能的陳述。在UML中是應(yīng)用用例圖來描述系統(tǒng)功能的。如圖1所示，系統(tǒng)大致由下述幾個角色和用例組成: 三個角色：數(shù)字式測溫儀，Internet遠端用戶，本地用戶。 五個用例：當(dāng)前溫度信息顯示、更改最高警戒溫度、更改最低警戒溫度、修改測溫儀工作狀態(tài)以及登陸服務(wù)器（身份驗證）。 以上的各個用例只是對系統(tǒng)功能的大致劃分，主要目的是為后面的系統(tǒng)分析作基礎(chǔ)。 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)也為本地用戶提供友好的人機交互界面。 |
