軟件模型可以幫助開發人員理解、闡明和交流關于他們的代碼和它必須支持的用戶需求的想法。但不幸的是，嵌入式開發人員在開發軟件模型方面是出了名的糟糕。以下是一些經驗，每個開發人員在設計下一代嵌入式系統時都應該考慮。

　　1.指定模型的用途

　　如果目標明確，模型可以讓嵌入式軟件開發人員在編寫一行代碼之前更好地理解系統。它們作為一種抽象，用于回答關于系統的特定問題。在開發人員開始隨機填充模型之前，他們應該停下來定義模型的目的和要回答的具體問題。

　　為了幫助指定目的，建議開發人員向模型添加一個任務聲明來陳述其目的。一個簡短的使命陳述不僅可以作為一個提醒來指導模型的開發者，還可以告知未來的維護者模型的目的。

　　2.80%的建模被三個UML圖覆蓋

　　一個嵌入式系統的大部分可以用三種圖表類型來建模。最常用的圖是類圖、狀態圖和序列圖。

　　類圖為嵌入式開發人員提供了一種定義軟件塊或類以及它們在軟件系統中的交互的方法。然后，這些圖表幫助開發人員理解更大的圖景，并看到不同的代碼塊將如何相互作用。

　　狀態圖，幫助開發人員描繪系統的不同軟件狀態，以及系統如何從一個狀態轉移到下一個狀態。

　　序列圖可以用來描述輸入、輸出和系統組件之間的一系列事件和行為。

　　偶爾可能需要的額外圖表是流程圖，這可能是幾乎每個開發人員都熟悉的圖表。

　　3.需求可以建模

　　通常開發人員獲得或開發一個軟件需求文檔，然后用于開發軟件的設計，那份文件很重要。開發人員可以利用UML用例圖，以可視化和精確的方式建模和定義軟件的需求。

　　4.重用成熟解決方案的設計模式

　　如果一個問題有一個已知的解決方案，為什么要重新發明輪子呢?計算機科學為嵌入式開發人員提供了許多在幾乎每個嵌入式系統中遇到的常見問題的成熟解決方案。設計模式為開發人員提供了一種利用他人經驗的方式，比他們從零開始更快、更健壯地開發系統。

　　5.持續驗證和測試

　　嵌入式軟件開發人員通常會在編寫代碼時抽查他們的工作，但大部分測試真正是在最后進行的。通常，大量的代碼被寫出來，然后交給QA團隊去證明沒有缺陷。

　　缺陷發現得越早，成本越低，因此，嵌入式系統的測試和驗證應該在系統的每個階段和迭代中進行。將系統分解成小塊進行建模和測試，然后實現和測試，這是開始證明系統工作的一個很好的方法。隨著每一次迭代，可以添加更多的部分，在將更多的部分添加到系統之前，可以再次對這些部分進行測試和驗證。

　　結論

　　嵌入式開發人員在編寫一行代碼之前，需要更好地對他們的軟件和系統進行建模。以上五條經驗教訓是開發人員開始構建更好的模型以產生更可靠、更具成本效益的系統的良好開端。