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