軟件架構是體現在其組件中的系統的基本組織，它們之間的相互關系和環境，以及指導其設計和發展的原則[1]。軟件架構不意味著一次就可以創建并固定下來。相反，在嵌入式開發中，軟件架構應該在產品的整個生命周期中不斷發展和變化。
在實施過程中經過思考并不斷發展的軟件架構有很多好處，例如：
充當正在建設的項目的路線圖
提供可用于培訓工程師和向管理層和利益相關者解釋軟件的軟件圖
最大限度減少不必要的返工
降低開發成本
團隊可以使用五個步驟來開發和發展他們的軟件架構：
1.分離軟件架構
3.分解系統
4.界面和組件設計
5.模擬、迭代和縮放
今天讓我們來了解一下第1個步驟。
步驟 1–分離軟件架構
許多嵌入式開發團隊將他們的軟件架構視為一個單一的內聚架構，包括應用程序代碼和硬件交互。以這種方式看待架構并不奇怪，因為嵌入式軟件工程師通常從硬件的角度來看待他們的系統。嵌入式軟件是獨特的，因為它必須與硬件交互，這不同于所有其他軟件工程領域。雖然這是真的，但是現代軟件架構師將會并且應該把依賴于硬件和獨立于硬件的軟件分開，如圖1所示。
圖1——嵌入式軟件架構分為硬件相關和獨立架構，通過抽象層進行交互。(圖片來源:嵌入式軟件設計[2])。
傳統上，開發人員將設計和實現他們的架構，以便硬件的獨立層和依賴層緊密耦合。但是不幸的是，緊密耦合的架構有很多問題。
緊密耦合架構的問題
首先，它們不太便于攜帶。例如，如果微控制器突然變得不可用，會發生什么？如果代碼是緊密耦合的，那么試圖將應用程序代碼轉移到新的微控制器上運行就變得非常困難。應用程序代碼與微控制器上的底層硬件調用緊密耦合！如果嵌入式開發人員不更新他們的架構，他們就不得不重新檢查所有的代碼，并修改與硬件交互的每一行代碼。更新架構的公司通過抽象和依賴注入打破了架構耦合。
其次，在開發環境中而不是在目標硬件上對應用程序進行單元測試幾乎是不可能的。如果應用程序代碼直接調用硬件，大量的工作將進入測試工具以成功運行測試，或者測試將需要在硬件上完成。在硬件上進行測試是緩慢的，并且通常是手動的而不是自動化的過程。結果是軟件沒有得到很好的測試，整個系統的質量受到影響。此外，交付軟件可能需要更長時間。
最后，緊密耦合的架構會有可伸縮性問題。緊密耦合的系統通常共享數據。隨著軟件系統試圖增長和增加新的特性，每增加一個新的特性，增加新的代碼就變得更加困難。組件之間的交互、訪問共享數據的能力以及出現麻煩的缺陷的機會都急劇增加。因此，盡管嵌入式開發人員努力工作以完成工作，功能開發可能會停滯不前。
分離架構如何解決問題
將軟件架構分成依賴于硬件的和獨立的架構解決了緊密耦合架構的所有問題。例如，在硬件相關架構和獨立架構之間創建一個抽象層，可以將應用代碼從一個微控制器轉移到下一個微控制器。抽象層打破了硬件依賴；換句話說，應用程序不知道也不關心硬件。相反，應用程序依賴于接口。新的依賴于硬件的組件只需要滿足接口的要求，這意味著如果我們改變硬件，只有硬件模塊改變！而不是整個代碼庫。
在兩個架構之間添加一個抽象層也解決了單元測試的許多問題。有了抽象層，就更容易創建向應用程序代碼返回預期和意外數據的測試替身和模擬。我們甚至不需要硬件就可以編寫所有的應用程序代碼！
當我們保持我們的體系結構獨立，并專注于最小化耦合時，擴展軟件就變得容易多了。然而，僅僅因為我們分解了架構并不意味著我們不能在每個架構中產生耦合和內聚的問題。我們仍然需要確保我們遵循固體兩種架構中的原則。好消息是，它允許嵌入式開發人員獨立關注每個架構，這意味著實時和硬件約束問題不會進入核心應用程序邏輯。
最后一個好處是，通過分離依賴于硬件和獨立的架構，我們可以在硬件可用之前專注于開發和交付應用程序。這樣做的好處是，客戶和管理層可以提前訪問應用程序并提供反饋。然后迭代應用程序并關注于確保它滿足實際需求的能力變得更加易于管理。今天，太多的團隊專注于首先準備好硬件，而核心應用程序是事后才想到的。這不是設計和構建系統的方法。
軟件架構設計第1步結論
軟件架構可以幫助團隊控制他們的軟件。成功的軟件架構通常是通過迭代和演化創建的。設計軟件架構的第一步是認識到嵌入式系統不只有一種架構。取而代之的是兩種架構：硬件依賴型和獨立型架構。有目的地分離這些架構允許嵌入式開發人員利用現代軟件技術和方法來改進上市時間、質量和開發成本。