軟體架構————架構核對錶

標籤：軟體   軟體架構師   系統架構   設計   

架構的典型組成部分

一、程式組織：

1.系統架構首先要以概括的形式對有關係統做一個綜述。如果沒有這種綜述，要想將成千的局部圖片拼成一幅完整的圖畫是相當傷腦筋的。

2.在架構中，應該發現對那些曾經考慮過的最終組織圖的替代方案的記敘，找到之所以選用最終的組織圖，而不用其他替代方案的理由。

3.架構應該定義程式的主要構造塊。根據程式規模不同，各個構造塊可能是單個類，也可能是有許多類組成的一個子系統。

4.應該明確定義各個構造塊的責任。每個構造塊應該負責某一個地區的事情，並且對其他構造塊負責的地區知道得越少越好。通過使各個構造塊對其他構造塊瞭解達到最小，你能將設計的資訊局限於各個構造塊之內。

5.應該明確定義每個構造塊的通訊規則。對於每個構造塊，架構應該描述他能直接使用那些構造塊，能間接使用那些構造塊，不能使用哪些構造塊。

二、主要的類

架構應該詳細定義所用的主要的類。它應該指出每個主要的類的責任，以及該類如何與其他類互動。它應該包含對類的繼承體系、狀態轉換、對象持久化等的描述。架構無須詳細說明系統中的每一個類，瞄準80/20原則。對那些構成系統80%的行為的20%類進行詳細說明。

三、資料設計

1.架構應該描述所用的主要檔案和資料表的設計。它應該描述曾經考慮過的其他方案，並說明做出選擇的理由。

2.資料通常只應該由一個子系統或一個類直接存取。

3.架構應該詳細定義所用資料庫的最高層組織圖和內容。架構應該解釋為什麼單個資料庫比多個資料庫要好（反之亦然），解釋為什麼不用平坦檔案而要用資料庫，指出與其他訪問同一資料的程式的可能互動方式，說明會建立哪些資料檢視等等。

四、商務規則

如果架構依賴於特定的商務規則，那麼它就應該詳細描述這些規則，並描述這些規則對系統設計的影響。

五、使用者介面設計

1.使用者介面常常在需求階段進行詳細說明。如果沒有，就應該在軟體架構中進行詳細說明。

2.架構應該模組化，以便在替換為新使用者介面時不影響商務規則和程式的輸出部分。

六、資源管理

架構應該描述一份管理稀缺資源的計劃。稀缺資源套件括：資料庫連接、線程、控制代碼等。

七、安全性

架構應該描述實現設計層面和代碼層面的安全性的方法。在定製編碼規範的時候應該把安全性牢記在心，包括處理緩衝區的方法、處理非受信資料的規則、加密、錯誤訊息的細緻程度、保護記憶體中的秘密資料，以及其他事項。

八、效能

1.如果需要關注效能，就應該在需求中詳細定義效能目標。

2.架構應該提供估計的資料，並解釋為什麼架構師相信能達到效能目標。如果某些部分存在達不到效能目標的風險，那麼架構也應該指出來。如果為了滿足效能目標，需要在某些部分使用特定的演算法或資料類型，架構也應該說清楚。架構中也可以抱括各個類或各個對象的空間和時間預算。

九、延展性

延展性是指系統增長以滿足未來需求的能力。架構應該描述系統如何應對使用者數量、伺服器數量、網路節點數量、資料庫記錄數、資料庫記錄的長度、交易量等的增長。

十、互用性

如果預計這個系統會與其他軟體或硬體共用資料或資源，架構應該描述如何完成這一任務。

十一、國際化/本地化

對互動系統，國際化問題值得在架構中關注。大多數互動式系統包含幾十上百條提示、狀態顯示、協助資訊、錯誤資訊、等等。應該估算這些字串所用的資源。如果這是一個在商業中使用的程式，架構應該表現出已經考慮過典型的字串問題和字元集問題，包括所用的字串類型，如果無須更改代碼就能維護這些字串，如何將這些字串翻譯為另一種語言而又盡量不影響代碼和使用者介面。

十二、輸入輸出

架構應該詳細定義讀取策略是先做、後作還是即時做。而且應該描述在那一層測I/O錯誤：在欄位、記錄、流，或者檔案的層次。

十三、錯誤處理

錯誤處理已被證實為現代電腦科學中最棘手的問題之一。錯誤處理牽連到整個系統，因此最好在架構層次上對待他。

1.錯誤處理是進行糾正還是僅僅進行檢測？如果是糾正，程式可以嘗試從錯誤中恢複過來。

2.錯誤偵測是主動的還是被動的？系統可以主動滴預測錯誤。

3.程式如何傳播錯誤？程式一旦檢測到錯誤，它可以立刻丟棄引發該錯誤的資料；也可以把這個錯誤當成一個錯誤，並進入錯誤處理狀態；或者可以等到所有處理完成，再通知使用者說在某個地方發現了錯誤。

4.錯誤訊息的處理有什麼約定？如果架構沒有詳細定義一個一致的處理策略，那使用者介面看起來非常糟。

5.如何處理異常？架構應該規定代碼何時能夠拋出異常，在什麼地方捕獲異常，如何記錄這些異常，以及如何在文檔中描述異常，等等。

6.在程式中，在什麼層次上處理錯誤？

7.每個類在驗證其輸入資料的有效性方面需要負何種責任？

8.是希望運行環境中內建的錯誤處理機制，還是想建立自己的一套機制？

十四、容錯性

架構還應該詳細定義所期望的容錯種類。容錯是增強系統可靠性的一組技術，包括檢測錯誤；如果可能的話從錯誤中恢複；如果不能從錯誤中恢複，則包容其不利影響。

十五、架構的可行性

設計師多半會關注系統的各種能力，例如是否達到效能目標，能夠在有限的資源下運轉，實現環境是否有足夠的支援。架構應該論證系統的技術可能性。如果在任何一個方面不可行都會導致項目無法實施，那麼架構應該說明“這些問題是如何經過研究的”——通過驗證概念的原型、研究、或其他手段。必須在全面開展構建之前解決掉這些風險。

十六、過度工程

健壯性是指“系統在檢測到錯誤後繼續運行”的能力。通常架構詳細描述的系統會比需求描述的系統更健壯。理由之一是，如果組成系統的各個部分都只在最低限度上滿足健壯性要求，那麼系統整體上是達不到所要求的健壯程度的。在軟體中，鏈條的強度不是取決於最薄弱的一環，而是等於所有薄弱環節的乘積。架構應該清楚地指出程式員應該“為了謹慎起見寧可進行過度工程”，還是應該做出最簡單的能工作的東西。

詳細定義一種過度工程的方法尤其重要，因為許多程式員會處於專業自豪感，對自己編寫的類做過度工程。通過在架構中明確地設立期望目標，就能避免出現“某些類異常健壯，而其他類勉強夠健壯”的現象。

十七、關於“買”還是“造”的決策

採購IP進行整合還是自己進行設計，都應該給出詳細的分析。

十八、關於複用的決策

關於開發計劃提倡使用已存在的軟體、測試案例、資料歌會或其他原料。架構應該說明：如何對複用的軟體進行加工，使之符合其他架構目標。

十九、變更策略

要面對開發過程中產品的變化，軟體架構師所遇到的挑戰是，讓架構靈活，能夠適應核能出現的變化。

架構應當清楚地描述處理變更的策略。架構應該列出已經考慮過的有可能會有所增強功能，並說明“最有肯能增強功能同樣也是最容易實現的”。如果變更很可能出現輸入輸出格式、使用者互動的風格、需求的處理等方面，那麼架構就應該說明：這些變更已經被預料到了，並且任何單一的變更都只會影響少數幾個類。

二十、架構的總體品質

1、架構的目標應該清楚地表述。

2、架構應該描述所有主要決策的動機。

3、優秀的軟體架構很大程度上是與機器和編程無關的。

4、架構應該踏在對系統”欠描述“和”過度描述“之間的那條分界線上。

5、架構應該明確地指出有風險的地區。他應該解釋為什麼這些地區是有風險的，並說明已經採取了哪些步驟以使風險最小化。

6、架構應該包含多個視角。

7、不應該擔憂架構的任何部分。它不應該任何對你而言很難理解的東西。

軟體架構————架構核對錶