系統構架設計時應考慮的一些必要性因素

      一、與構架有關的幾個基本概念：

　　1、模組（module）：一組完成指定功能的語句，包括：輸入、輸出、邏輯處理功能、內部資訊、執行環境（與功能對應但不是一對一關係）。

　　2、元件（component）：系統中相當重要的、幾乎是獨立的可替換部分，它在明確定義的構架環境中實現確切的功能。

　　3、模式（pattern）：指經過驗證，至少適用於一種實用環境（更多時候是好幾種環境）的解決方案模板（用於結構和行為。在 UML 中：模式由引數化的協作來表示，但 UML 不直接對模式的其他方面（如使用結果列表、使用示例等，它們可由文字來表示）進行建模。存在各種範圍和抽象程度的模式，例如，構架模式、分析模式、設計模式和程式碼模式或實施模式。模式將可以幫助我們抓住重點。構架也是存在模式的。比如，對於系統結構設計，我們使用層模式；對於分散式系統，我們使用代理模式（通過使用代理來替代實際的物件，使程式能夠控制對該物件的訪問）；對於互動系統，我們使用MVC（M模型(物件)／V檢視(輸出管理)／C控制器(輸入處理)）模式。模式是針對特定問題的解，因此，我們也可以針對需求的特點採用相應的模式來設計構架。

　　4、構架模式（architectural pattern）：表示軟體系統的基本結構組織方案。它提供了一組預定義的子系統、指定它們的職責，並且包括用於組織其間關係的規則和指導。

　　5、層（layer）：對模型中同一抽象層次上的包進行分組的一種特定方式。通過分層，從邏輯上將子系統劃分成許多集合，而層間關係的形成要遵循一定的規則。通過分層，可以限制子系統間的依賴關係，使系統以更鬆散的方式耦合，從而更易於維護。（層是對構架的橫向劃分，分割槽是對構架的縱向劃分）。

　　6、系統分層的幾種常用方法：
　　1） 常用三層服務：使用者層、業務邏輯層、資料層；
　　2） 多層結構的技術組成模型：表現層、中間層、資料層；
　　3） 網路系統常用三層結構：核心層、匯聚層和接入層；
　　4） RUP典型分層方法：應用層、專業業務層、中介軟體層、系統軟體層；
　　5） 基於Java的B/S模式系統結構：瀏覽器端、伺服器端、請求接收層、請求處理層；
　　6） 某六層結構：功能層（使用者介面）、模組層、組裝層（軟體匯流排）、服務層（資料處理）、資料層、核心層；

　　7、構架（Architecture，願意為建築學設計和建築物建造的藝術與科學）: 在RUP中的定義：軟體系統的構架（在某一給定點）是指系統重要構件的組織或結構，這些重要構件通過介面與不斷減小的構件與介面所組成的構件進行互動；《軟體構架實踐》中的定義：某個軟體或者計算系統的軟體構架即組成該系統的一個或者多個結構，他們組成軟體的各個部分，形成這些元件的外部可見屬性及相互間的聯絡；IEEE 1471-2000中的定義：the fundamental organization of a system emboided in its components,their relationships to each other,and to the enviroment and the principles guiding its design and evolution，構架是系統在其所處環境中的最高層次的概念。軟體系統的構架是通過介面互動的重要構件（在特定時間點）的組織或結構，這些構件又由一些更小的構件和介面組成。（“構架”可以作為名詞，也可作為動詞，作為動詞的“構架”相當於“構架設計”）

　　8、構架的描述方式：“4＋1”檢視（用例檢視、設計檢視、實現檢視、過程檢視、配置檢視）是一個被廣為使用的構架描述的模型；RUP過程的構架描述模板在“4＋1”檢視的基礎上增加了可選的資料檢視（從永久性資料儲存方面來對系統進行說明）；HP公司的軟體描述模板也是基於“4＋1”檢視。

　　9、結構：軟體構架是多種結構的體現，結構是系統構架從不同角度觀察所產生的檢視。就像建築物的結構會隨著觀察動機和出發點的不同而有多種含義一樣，軟體構架也表現為多種結構。常見的軟體結構有：模組結構、邏輯或概念結構、程式或協調結構、物理結構、使用結構、呼叫結構、資料流、控制流、類結構等等。
　　二、構架設計應考慮的因素概攬：

　　模組構架設計可以從程式的執行時結構和原始碼的組織結構方面考慮。

　　1、程式的執行時結構方面的考慮：
　　1） 需求的符合性：正確性、完整性；功能性需求、非功能性需求；
　　2） 總體效能（記憶體管理、資料庫組織和內容、非資料庫資訊、任務並行性、網路多人操作、關鍵演算法、與網路、硬體和其他系統介面對效能的影響）；
　　3） 執行可管理性：便於控制系統執行、監視系統狀態、錯誤處理；模組間通訊的簡單性；與可維護性不同；
　　4） 與其他系統介面相容性；
　　5） 與網路、硬體介面相容性及效能；
　　6） 系統安全性；
　　7） 系統可靠性；
　　8） 業務流程的可調整性；
　　9） 業務資訊的可調整性
　　10） 使用方便性
　　11） 構架樣式的一致性
　　注：執行時負載均衡可以從系統效能、系統可靠性方面考慮。

　　2、原始碼的組織結構方面的考慮：
　　1） 開發可管理性：便於人員分工（模組獨立性、開發工作的負載均衡、進度安排優化、預防人員流動對開發的影響）、利於配置管理、大小的合理性與適度複雜性；
　　2） 可維護性：與執行可管理性不同；
　　3） 可擴充性：系統方案的升級、擴容、擴充效能；
　　4） 可移植性：不同客戶端、應用伺服器、資料庫管理系統；
　　5） 需求的符合性（原始碼的組織結構方面的考慮）。

　　三、程式的執行時結構方面的考慮：

　　1、 需求的符合性：正確性、完整性；功能性需求、非功能性需求軟體專案最主要的目標是滿足客戶需求。在進行構架設計的時候，大家考慮更多的是使用哪個執行平臺、編成語言、開發環境、資料庫管理系統等問題，對於和客戶需求相關的問題考慮不足、不夠系統。如果無論怎麼好的構架都無法滿足客戶明確的某個功能性需求或非功能性需求，就應該與客戶協調在專案範圍和需求規格說明書中刪除這一需求。否則，架構設計應以滿足客戶所有明確需求為最基本目標，儘量滿足其隱含的需求。（客戶的非功能性需求可能包括介面、系統安全性、可靠性、移植性、擴充套件性等等，在其他小節中細述）

　　一般來說，功能需求決定業務構架、非功能需求決定技術構架，變化案例決定構架的範圍。需求方面的知識告訴我們，功能需求定義了軟體能夠做些什麼。我們需要根據業務上的需求來設計業務構架，以使得未來的軟體能夠滿足客戶的需要。非功能需求定義了一些效能、效率上的一些約束、規則。而我們的技術構架要能夠滿足這些約束和規則。變化案例是對未來可能發生的變化的一個估計，結合功能需求和非功能需求，我們就可以確定一個需求的範圍，進而確定一個構架的範圍。（此段From林星）

　　這裡講一個前幾年因客戶某些需求錯誤造成構架設計問題而引起系統效能和可靠性問題的小小的例子：此係統的需求本身是比較簡單的，就是將某城市的某業務的全部歷史檔案卡片掃描儲存起來，以便可以按照姓名進行查詢。需求階段客戶說卡片大約有20萬張，需求調研者出於對客戶的信任沒有對資料的總量進行查證。由於是中小型資料量，並且今後資料不會增加，經過計算20萬張卡片總體容量之後，決定使用一種可以單機使用也可以聯網的中小型資料庫管理系統。等到系統完成開始錄入資料時，才發現資料至少有60萬，這樣使用那種中小型資料庫管理系統不但會造成系統效能的問題，而且其可靠性是非常脆弱的，不得不對系統進行重新設計。從這個小小的教訓可以看出，需求階段不僅對客戶的功能需求要調查清楚，對於一些隱含非功能需求的一些資料也應當調查清楚，並作為構架設計的依據。

　　對於功能需求的正確性，在構架設計文件中可能不好驗證（需要人工、費力）。對於功能需求完整性，就應當使用需求功能與對應模組對照表來跟蹤追溯。對於非功能需求正確性和完整性，可以使用需求非功能與對應設計策略對照表來跟蹤追溯評估。

　　“軟體設計工作只有基於使用者需求，立足於可行的技術才有可能成功。”

　　2、 總體效能
　　效能其實也是客戶需求的一部分，當然可能是明確的，也有很多是隱含的，這裡把它單獨列出來在說明一次。效能是設計方案的重要標準，效能應考慮的不是單臺客戶端的效能，而是應該考慮系統總的綜合效能；

　　效能設計應從以下幾個方面考慮：記憶體管理、資料庫組織和內容、非資料庫資訊、任務並行性、網路多人操作、關鍵演算法、與網路、硬體和其他系統介面對效能的影響；

　　幾點提示：演算法優化及負載均衡是效能優化的方向。經常要呼叫的模組要特別注意優化。佔用記憶體較多的變數在不用時要及時清理掉。需要下載的網頁主題檔案過大時應當分解為若干部分，讓使用者先把主要部分顯示出來。

　　3、 執行可管理性
　　系統的構架設計應當為了使系統可以預測系統故障，防患於未然。現在的系統正逐步向複雜化、大型化發展，單靠一個人或幾個人來管理已顯得力不從心，況且對於某些突發事件的響應，人的反應明顯不夠。因此通過合理的系統構架規劃系統執行資源，便於控制系統執行、監視系統狀態、進行有效的錯誤處理；為了實現上述目標，模組間通訊應當儘可能簡單，同時建立合理詳盡的系統執行日誌，系統通過自動審計執行日誌，瞭解系統執行狀態、進行有效的錯誤處理；（執行可管理性與可維護性不同）

　　4、 與其他系統介面相容性（解釋略）

　　5、 與網路、硬體介面相容性及效能（解釋略）

　　6、 系統安全性
　　隨著計算機應用的不斷深入和擴大，涉及的部門和資訊也越來越多，其中有大量保密資訊在網路上傳輸，所以對系統安全性的考慮已經成為系統設計的關鍵，需要從各個方面和角度加以考慮，來保證資料資料的絕對安全。 
　　7、 系統可靠性
　　系統的可靠性是現代資訊系統應具有的重要特徵，由於人們日常的工作對系統依賴程度越來越多，因此係統的必須可靠。系統構架設計可考慮系統的冗餘度，儘可能地避免單點故障。系統可靠性是系統在給定的時間間隔及給定的環境條件下，按設計要求，成功地執行程式的概率。成功地執行不僅要保證系統能正確地執行，滿足功能需求，還要求當系統出現意外故障時能夠儘快恢復正常執行，資料不受破壞。

　　8、 業務流程的可調整性
　　應當考慮客戶業務流程可能出現的變化，所以在系統構架設計時要儘量排除業務流程的制約，即把流程中的各項業務結點工作作為獨立的物件，設計成獨立的模組或元件，充分考慮他們與其他各種業務物件模組或元件的介面，在流程之間通過業務物件模組的相互呼叫實現各種業務，這樣，在業務流程發生有限的變化時（每個業務模組本身的業務邏輯沒有變的情況下），就能夠比較方便地修改系統程式模組或元件間的呼叫關係而實現新的需求。如果這種呼叫關係被設計成儲存在配置庫的資料字典裡，則連程式程式碼都不用修改，只需修改資料字典裡的模組或元件呼叫規則即可。

　　9、 業務資訊的可調整性
　　應當考慮客戶業務資訊可能出現的變化，所以在系統構架設計時必須儘可能減少因為業務資訊的調整對於程式碼模組的影響範圍。

　　10、 使用方便性
　　使用方便性是不須提及的必然的需求，而使用方便性與系統構架是密切相關的。WinCE（1.0）的失敗和後來改進版本的成功就說明了這個問題。 WinCE（1.0）有太多層次的視窗和選單，而使用者則更喜歡簡單的介面和快捷的操作。失敗了應當及時糾正，但最好不要等到失敗了再來糾正，這樣會浪費巨大的財力物力，所以在系統構架階段最好能將需要考慮的因素都考慮到。當然使用方便性必須與系統安全性協調平衡統一，使用方便性也必須與業務流程的可調整性和業務資訊的可調整性協調平衡統一。“滿足使用者的需求，便於使用者使用，同時又使得操作流程儘可能簡單。這就是設計之本。”

　　11、構架樣式的一致性
　　軟體系統的構架樣式有些類似於建築樣式（如中國式、哥特式、希臘復古式）。軟體構架樣式可分為資料流構架樣式、呼叫返回構架樣式、獨立元件構架樣式、以資料為中心的構架樣式和虛擬機器構架樣式，每一種樣式還可以分為若干子樣式。構架樣式的一致性並不是要求一個軟體系統只能採用一種樣式，就像建築樣式可以是中西結合的，軟體系統也可以有異質構架樣式（分為區域性異質、層次異質、並行異質），即多種樣式的綜合，但這樣的綜合應該考慮其某些方面的一致性和協調性。每一種樣式都有其使用的時機，應當根據系統最強調的質量屬性來選擇。

　　四、原始碼的組織結構方面的考慮：

　　1、 開發可管理性

　　便於人員分工（模組獨立性、開發工作的負載均衡、進度安排優化、預防人員流動對開發的影響：一個好的構架同時應有助於減少專案組的壓力和緊張，提高軟體開發效率）、利於配置管理、大小的合理性、適度複雜性；

　　1）便於人員分工－模組獨立性、層次性
　　模組獨立性、層次性是為了保證專案開發成員工作之間的相對獨立性，模組聯結方式應該是縱向而不是橫向, 模組之間應該是樹狀結構而不是網狀結構或交叉結構，這樣就可以把開發人員之間的通訊、模組開發制約關係減到最少。同時模組獨立性也比較利於配置管理工作的進行。現在有越來越多的的軟體開發是在異地進行，一個開發組的成員可能在不同城市甚至在不同國家，因此便於異地開發的人員分工與配置管理的原始碼組織結構是非常必要的。

　　2）便於人員分工－開發工作的負載均衡
　　不僅僅是開發出來的軟體系統需要負載均衡，在開發過程中開發小組各成員之間工作任務的負載均衡也是非重要的。所謂工作任務的負載均衡就是通過合理的任務劃分按照開發人員特點進行分配任務，儘量讓專案組中的每個人每段時間都有用武之地。這就需要在構架設計時應當充分考慮專案組手頭的人力資源，在實現客戶需求的基礎上實現開發工作的負載均衡，以提高整體開發效率。

　　3）便於人員分工－進度安排優化；
　　進度安排優化的前提是模組獨立性並搞清楚模組開發的先後制約關係。利用工作分解結構對所有程式編碼工作進行分解，得到每一項工作的輸入、輸出、所需資源、持續時間、前期應完成的工作、完成後可以進行的工作。然後預估各模組需要時間，分析各模組的並行與序列（順序制約），繪製出網路圖，找出影響整體進度的關鍵模組，算出關鍵路徑，最後對網路圖進行調整，以使進度安排最優化。

　　有個家喻戶曉的智力題叫烤肉片策略：約翰遜家戶外有一個可以同時烤兩塊肉片的烤肉架，烤每塊肉片的每一面需要10分鐘，現要烤三塊肉片給飢腸轆轆急不可耐的一家三口。問題是怎樣才能在最短的時間內烤完三片肉。一般的做法花20分鐘先烤完前兩片，再花20分鐘烤完第三片。有一種更好的方法可以節省10分鐘，大家想想。

　　4）便於人員分工－預防員工人員流動對開發的影響
　　人員流動在軟體行業是司空見慣的事情，已經是一個常見的風險。作為對這一風險的有效的防範對策之一，可以在構架設計中考慮到並預防員工人員流動對開發的影響。主要的思路還是在模組的獨立性上（追求高內聚低耦合），元件化是目前流行的趨勢。

　　5）利於配置管理（獨立性、層次性）
　　利於配置管理與利於人員分工有一定的聯絡。除了邏輯上的模組元件要利於人員分工外，物理上的原始碼層次結構、目錄結構、各模組所處原始碼檔案的部署也應當利於人員分工和配置管理。（儘管現在配置管理工具有較強大的功能，但一個清楚的原始碼分割和模組分割是非常有好處的）。

　　6）大小的合理性與適度複雜性
　　大小的合理性與適度複雜性可以使開發工作的負載均衡，便於進度的安排，也可以使系統在執行時減少不必要的記憶體資源浪費。對於程式碼的可閱讀性和系統的可維護性也有一定的好處。另外，過大的模組常常是系統分解不充分，而過小的模組有可能降低模組的獨立性，造成系統介面的複雜。
　　2、 可維護性
　　便於在系統出現故障時及時方便地找到產生故障的原因和原始碼位置，並能方便地進行區域性修改、切割；（可維護性與執行可管理性不同）

　　3、 可擴充性：系統方案的升級、擴容、擴充效能
　　系統在建成後會有一段很長的執行週期，在該週期內，應用在不斷增加，應用的層次在不斷升級，因此採用的構架設計等方案因充分考慮升級、擴容、擴充的可行性和便利。

　　4、 可移植性
　　不同客戶端、應用伺服器、資料庫管理系統：如果潛在的客戶使用的客戶端可能使用不同的作業系統或瀏覽器，其可移植性必須考慮客戶端程式的可移植性，或儘量不使業務邏輯放在客戶端；資料處理的業務邏輯放在資料庫管理系統中會有較好的效能，但如果客戶群中不能確定使用的是同一種資料庫管理系統，則業務邏輯就不能資料庫管理系統中；

　　達到可移植性一定要注重標準化和開放性：只有廣泛採用遵循國際標準，開發出開放性強的產品，才可以保證各種型別的系統的充分互聯，從而使產品更具有市場競爭力，也為未來的系統移植和升級擴充套件提供了基礎。

　　5、 需求的符合性
　　從原始碼的組織結構看需求的符合型主要考慮針對使用者需求可能的變化的軟體程式碼及構架的最小冗餘（同時又要使得系統具有一定的可擴充套件性）。

　　五、寫系統構架設計文件應考慮的問題

　　構架工作應該在需求開發完成約80％的時候開始進行，不必等到需求開發全部完成，需要專案經理以具體的判斷來評估此時是否足以開始構建軟體構架。

　　給出一致的輪廓：系統概述。一個系統構架需要現有概括的描述，開發人員才能從上千個細節甚至數十個模組或物件類中建立一致的輪廓。

　　構架的目標應該能夠清楚說明系統概念，構架應儘可能簡化，最好的構架檔案應該簡單、簡短，清晰而不雜亂，解決方案自然。

　　構架應單先定義上層的主要子系統，應該描述各子系統的任務，並提供每個子系統中各模組或物件類的的初步列表。

　　構架應該描述不同子系統間相互通訊的方式，而一個良好的構架應該將子系統間的通訊關係降到最低。

　　成功構架的一個重要特色，在於標明最可能變更的領域，應當列出程式中最可能變更的部分，說明構架的其他部分如何應變。

　　複用分析、外購：縮短軟體開發週期、降低成本的有效方案未必是自行開發軟體，可以對現有軟體進行復用或進行外購。應考慮其對構架的影響。

　　除了系統組織的問題，構架應重點考慮對於細節全面影響的設計決策，深入這些決策領域：外部軟體介面（相容性、通訊方式、傳遞資料結構）、使用者介面（使用者介面和系統層次劃分）、資料庫組織和內容、非資料庫資訊、關鍵演算法、記憶體管理（配置策略）、並行性、安全性、可移植性、網路多人操作、錯誤處理。

　　要保證需求的可追蹤性，即保證每個需求功能都有相應模組去實現。

　　構架不能只依據靜態的系統目標來設計，也應當考慮動態的開發過程，如人力資源的情況，進度要求的情況，開發環境的滿足情況。構架必須支援階段性規劃，應該能夠提供階段性規劃中如何開發與完成的方式。不應該依賴無法獨立執行的子系統構架。將系統各部分的、依賴關係找出來，形成一套開發計劃。

　　六、結語

　　系統構架設計和千差萬別的具體的開發平臺密切相關，因此在此無法給出通用的解決方案，主要是為了說明哪些因素是需要考慮的。對於每個因素的設計策略和本文未提到的因素需要軟體構架設計師在具體開發實踐中靈活把握。不同因素之間有時是矛盾的，構架設計時需要根據具體情況進行平衡。

　　參考文獻：

　 《軟體構架實踐》SEI軟體工程譯叢，林·巴斯著
　 《微軟專案：求生法則》Steve McConnell著，餘孟學譯
　 《實用軟體工程》第二版，鄭人傑、殷人昆、陶永雷等著
　 《軟體工程：實踐者的研究方法》（第5版）Roger S.Pressman著
　 《軟體開發的科學與藝術》陳巨集剛等著