軟體架構應該做些什麼

 

軟體架構是在軟體需求出來之後，軟體構建開始之前的工作

 

架構師應該確定的事情有：

1 程式組織

架構應該定義程式中的主要構造塊。
根據程式規模不同，各個構造塊可能是單個類，也可能是由多個類組成的系統。每個構造塊實現一個高層功能。並且每個需求都至少有一個構造塊覆蓋它。

定義各個構造塊之間的通訊規則和依賴規則

 

2 主要的類

架構應該詳細定義或寫出所用的主要的類。並指出該類如何與其他類互動。

架構不需要對所有類進行說明，使用82法則：對構成系統80%功能的20%類進行說明

 

3 資料設計

架構應該說明清楚用到的資料表的設計，並且描述為何做出這樣的選擇

 

4 商務規則

對特定的商務規則（比如:客戶資訊的更新時間不能超過30秒）要有架構方面的描述（比如30秒內對用戶端進行資訊同步）

 

5 使用者介面設計

架構應該有詳細的使用者介面，好的使用者介面直接關係到功能的實現和軟體的最終效果

 

6 資源管理

架構應該對稀缺資源有管理計劃。比如資料庫連接，線程，控制代碼等的使用。有可能需要設計一個“資源管理員”的模組

 

7 安全性

架構應該描述使用者據輸入資料，cookie，設定檔等的安全性說明

 

8效能

應該根據需求文檔中對效能的描述來提供估計的效能資料，並且說明為什麼架構師相信能達到效能目的。或者為什麼有的效能指標無法達到

 

9 延展性

架構應該說明系統如何應對以後使用者數量，伺服器數量，網路節點數量，資料庫記錄數，資料庫記錄長度，交易量等增長的需求。

 

10 互用性

如果系統與其他軟體或硬體有共用資源，架構應該說明如何完成這項功能

 

11 國際化/本地化

系統式是否支援國際化，如何在與使用者互動的模組中實現國際化

 

12 輸入輸出

架構應該詳細定義讀取策略

 

13 錯誤處理

有人估計程式中高達90%的代碼是用來處理異常和錯誤的，意味只有10%的代碼是用來處理常規情況的。

需要考慮的問題包括：

錯誤處理是進行糾正還是只進行檢測

錯誤偵測是主動還是被動

程式如何傳播錯誤，是立刻丟棄還是通知一個地方

錯誤處理有什麼約定

如何處理異常，什麼時候能拋出異常，什麼地方log，什麼地方捕獲

在什麼地方處理錯誤，是傳遞到專門處理錯誤的地方還是沿著函數鏈往上傳遞錯誤

每個類的輸入資料額有效性方面如何負責

是希望用運行環境內建的錯誤處理機制還是自訂一套機制

 

14 容錯性

容錯是增強系統可靠性的技術，如果出現了錯誤是轉入“部分運轉”還是“功能退化”?

 

15 架構的可行性

架構師應該論證自己這個系統設計的可行性

 

16過度工程

即健壯性。架構應該指出哪些類哪些模組需要進行過度工程（健壯性測試），哪些類或模組只需要做出最簡單的工作效能

 

17 關於買還是造

一些軟體，開原始碼，處理常式，是使用現貨採購還是自己定製開發

 

18 關於複用

如果使用業界已經存在的軟體，開原始碼等資源，應該說明清楚如何對這些東西進行加工。

 

19 變更策略

架構應該清楚描述處理變更的策略。架構應該列出已經考慮過的可能會有變更的需求或者可能增強功能。

並提供處理情況，比如使用版本號碼進行控制，或者將代碼設計成可動態添加新資料

 

20 架構的總體品質

架構應該清楚描述其做的所有主要決策的動機

明確指出有風險的地方