2.1 構建系統框圖
正如硬件設計師需要設計電路原理圖一樣，我們也應該設計一系列的軟件框圖來描述軟件系統各個不同部分之間的關系。這些框圖會讓我們對系統有全局的了解，有助于我們定義各個部分之間的相互依賴關系，并且為新功能的設計提供指導。
推薦三種不同的框圖：
架構框圖
控制層級圖
軟件層次視圖
2.1.1 架構框圖
在開始階段，設計是直觀的，因為這個時候面對的是系統的硬件組件，并且可以用面向對象的思維去對硬件組件進行建模，而不管是否使用面向對象的編程語言。連接到處理器的每個芯片都是個對象，連接芯片和處理器之間的線（通信方法）也可以作為另外一組對象。
你可以把這些對象劃成一個一個的方框，以此作為設計的起點。將芯片畫在中心，通信對象畫在處理器里，然后將其他外設一個一個地連接到這些對象上。
舉個例子，這里我要介紹一種稱為閃存的存儲器。撇開其細節不談，它是一個在很多設備中被廣泛使用的一種相對便宜的存儲器。大多數閃存芯片都通過SPI總線通信（SPI是一種串行通信，后面會詳細討論）。它通常用做片外部存儲器，因為大部分處理器都無法通過SPI接口在閃存上執行代碼。圖2-1上半部分的原理圖展示了如何將閃存通過SPI連接到處理器。
在我們的軟件框圖中，我們將閃存作為外設（處理器外面的一個方框），在處理器內部增加一個表示SPI的方框，這意味著我們需要寫一些驅動SPI的代碼。這個時候，我們的軟件框圖看起來和硬件原理圖很相似，但隨著我們逐漸加入更多的軟件組件，就會慢慢變得不同了。
下一步在處理器內部增加一個表示閃存的方框，提示我們需要寫一些驅動閃存的代碼。將通信方式和外設分離開來是有益的。如果有多個芯片通過同樣的通信方式連接到處理器，那么它們就應該連接到處理器內部同一個通信模塊上。這時候，框圖就會提醒我們對于共享資源需要格外小心，需要我們考慮共享帶來的性能和資源沖突問題。

圖2-1展示了在畫軟件框圖時的一部分電氣原理圖。注意這個原理圖是非常粗略的。這個時候，我們需要在更高的層面上去了解系統以便決定我們需要構造哪些對象以及這些對象如何相互配合。將細節部分銘記于心，特別是那些有系統級有影響的，但只要有可能，不要把這些細節畫在框圖上。

圖2-1：原理圖和初始軟件框圖的對比
下一個階段就是增加一些高層功能。每個外設芯片是做什么用的？如果每個芯片只有一個功能，那就簡單了。例如，如果將閃存用做存儲位圖圖片以便在屏幕上顯示，我們就可以在架構框圖上畫一個方框表示顯示數據。這時候沒有片外組件，因此這個方框置于處理器內部。我們還需要畫上一些方框來表示屏幕與屏幕的通信方式，和另一個方框表示將基于閃存的顯示數據轉換到屏幕。這個時候，多畫些功能框比少畫好，后面我們會合并它們。
可以將能夠想到的其他一些軟件構件加到框圖上，如數據庫、緩存系統、命令處理程序、算法、狀態機等。這個時候，可能不是很確切地知道自己是否需要這些（本書的后繼章節會對其中一些內容深入討論），但請試著將從硬件到產品功能的所有東西都表達在框圖上，如圖2-2所示。
當在一張紙或者白板上畫下這個框圖后（因為圖不夠大或者位置不對，可能會經過多次反復），不要以為已經做得足夠好了，還有另外一張圖會給我們更多的啟發。
從多個不同的角度看，你會發現一些隱藏的、不完善的問題點，如關鍵瓶頸、沒有充分理解的需求，或者在這個平臺上設計實現產品時會帶來一些不可避免的缺陷。通常，這些不足只能從某個角度才能發現，或者當它們出現在不同的框圖中時發生了很大的變化。當從恰當的角度去看這些問題時，不僅可以找到這些棘手的模塊，而且可以找到這些問題的解決之道。

圖2-2：軟件框圖
2.1.2 控制層級圖
另一種軟件架構圖看起來有點像組織結構圖，如圖2-3所示。圖2-3中展示了各個相互獨立的組件，以及組件之間的調用關系。整個系統就是一個分層的結構，Main是最高層的對象。如果已經知道算法將要如何使用每個組件，就可以在下一個層次畫上算法相關的對象。如果認為它們不會再變化，那么就可以從產品相關的特征開始，逐步分解到我們已經知道的對象，將最復雜的放在頂層。然后，畫上被高層對象使用的低層次對象。例如，我們的SPI對象會被閃存對象調用，閃存對象又會被顯示對象調用，依此類推。還可以加上之前沒有考慮到的對象或者組件。同時，還需要決定是否將這些組件增加到架構框圖上（很有可能）。

圖
2-3：軟件架構的結構框圖
雖然，我們總希望一個外設完成一個特定的功能（比如，閃存中的顯示資源），但系統的約束（成本、速度等）通常不會支持這樣做。因此，我們往往會給一個外設上賦予了多個但并不特別兼容的功能。
在圖2-3中可以看到文本組件和圖像組件共享閃存驅動程序組件及其下面的SPI驅動程序組件。通常，這種共享是必要的，但對設計來說，這是個紅燈，因為需要特別當心以避免資源的沖突，并確保資源在需要的時候可用。幸運的是，圖2-3中給出了渲染代碼組件，它控制這兩個組件，并能夠確保在任何一個時刻只有一個組件（文本或者圖像）可用，因此在它們之間就不大可能再有沖突發生。
比如，設計團隊決定系統需要每個單元有一個序列號。這個序列號會在生產的時候燒錄進去并在需要的時候提供。我們可以增加另外一個存儲器芯片作為外設，但這會增加成本、電路板的復雜度和軟件的復雜度。我們已有的閃存有足夠的空間存儲這個序列號，因此只需要增加軟件的復雜度。
在圖2-4中，我們通過閃存打印序列號，而這個閃存之前是用于顯示組件。如果日志子系統需要從顯示組件異步獲取序列號（比如，我們有兩個線程或者顯示組件使用中斷），軟件需要避免沖突和由此帶來的系統崩潰。

圖2-4：共享資源的結構框圖
每當此類的組件被加到框圖上時，就需要考慮一些正在使用A和B的組件可能會給C組件帶來的干擾，系統的健壯性就會變得稍微差點。需要額外注意的地方很難用文檔記錄。共享資源給設計、實現、維護階段帶來痛苦。這里的例子很容易地就解決了，雖然留著一個紅燈標記。但是需要考慮所有的共享資源所帶來的最終結果。
2.1.3 層次圖
最后一張架構圖著重在不同的層次劃分，如圖2-5所示，用對象預計的大小來表達。這張圖也一樣可以用鉛筆在紙上畫出來。從紙的下方開始畫出那些逐漸遠離處理器的對象（比如，我們的通信模塊）。如果估計某個對象實現起來相對比較復雜，那么就把它畫得大一點。如果不能確定對象的復雜度，那么就把它們畫得一樣大。然后，在圖中增加調用最底層對象的那些對象。如果同一個底層對象被多個上層對象調用，那么這些調用對象都應該和該底層對象關聯（意味著可以把這個被調用對象畫大一點）。同樣，如果同一個上層對象調用多個底層對象，那么這個上層對象也應該和這些底層對象關聯（把它畫大一點）。
我說根據對象的復雜度決定其大小，然后又說如果一個對象被多個上層對象調用，那么就把它畫大一點。這看起來有點難以理解。在2.1.2節中提到，共享資源會增加復雜性。所以，如果在多個對象之間共享一個資源，但是這些對象卻不能同時訪問，那么即使這個模塊的目的很簡單，也會增加其復雜度。在圖2-5中，開始的時候我把渲染模塊畫得很小，因為從閃存中將數據傳送到LCD是很簡單的事情。但是，后來這個渲染模塊還需要控制在它下一層的所有位，就把它畫大了。在我摘錄這張層次圖的項目中，最終結果證明了渲染模塊確實要比其他兩個模塊大。

圖2-5：軟件層次圖
最終，這張層次圖會表示出每段代碼處在哪個層次，讓我們有可能將通常一起使用的資源綁定在一起。比如，LCD和并行I/O對象只在兩者之間相互聯系，所以在最終的設計圖中，可以將這兩個模塊合并成一個模塊。對背光模塊和PWM輸出模塊也可以進行一樣的處理。
再看看水平方向模塊的分組情況。字體和圖像模塊共享同樣的高層和低層連接，也許應該將它們合并到一個模塊中，因為它們有相同的輸入和輸出。這張圖的目的就是找出這些點，并且找出合并模塊的不同方法。最后，就會得到一個更簡單的設計圖。
最后，可能會有同一組中的多個模塊訪問同一個低層對象，這時候也許應該花些時間把這個資源再分解。如果閃存驅動程序只處理序列號，這樣設計有必要嗎？可不可以在初始化的時候讀出序列號，之后就再也不用重復讀它，這樣讓顯示子系統能一直控制閃存？理解設計的復雜度，以及有哪些不同的設計方法去改變這個復雜度相當重要。一個好的設計應該是在實現和維護上既省錢又省時間。

總結

以上是生活随笔為你收集整理的《 嵌入式系统设计与实践》一一2.1 构建系统框图的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。