一切皆可抽象

架構設計說明書

參考文件《需求說明書》

需要考慮的要素

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％的時候開始進行，不必等到需求開發全部完成，需要項目經理以具體的判斷來評估此時是否足以開始構建軟件構架。

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

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

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

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

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

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

除了系統組織的問題，構架應重點考慮對于細節全面影響的設計決策，深入這些決策領域：外部軟件接口（兼容性、通信方式、傳遞數據結構）、用戶接口（用戶接口和系統層次劃分）、數據庫組織和內容、非數據庫信息、關鍵算法、內存管理（配置策略）、并行性、安全性、可移植性、網絡多人操作、錯誤處理。

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

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

系統概述

名詞解釋

業務構架

    模塊定義   模塊獨立性、層次性  

穩定的需求

不穩定需求

不穩定需求造成的后果

應對方案

使用方便性

技術構架

     運行平臺、接口、系統安全性、可靠性、移植性、擴展性

人力組織計劃

      人力資源分析

      進度安排優化

     開發工作的負載均衡

      預防員工人員流動對開發的影響應對