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