摘要：
本文從程序的運行時結(jié)構(gòu)和源代碼的組織結(jié)構(gòu)兩個方面探討了系統(tǒng)構(gòu)架設(shè)計應(yīng)考慮的各種因素，列舉了系統(tǒng)構(gòu)架設(shè)計文檔應(yīng)考慮的一些問題。?
關(guān)鍵字：
系統(tǒng)構(gòu)架、設(shè)計、考慮、因素
正文：
約公元前25年，古羅馬建筑師維特魯威說：“理想的建筑師應(yīng)該既是文學家又是數(shù)字家，他還應(yīng)通曉歷史，熱衷于哲學研究，精通音樂，懂得醫(yī)藥知識，具有法學造詣，深諳天文學及天文計算。”（好難哪，軟件構(gòu)架設(shè)計師的要求呢？大家好好想想吧。）
本文目錄
一、與構(gòu)架有關(guān)的幾個基本概念；
二、構(gòu)架設(shè)計應(yīng)考慮的因素概攬；
三、程序的運行時結(jié)構(gòu)方面的考慮；
四、源代碼的組織結(jié)構(gòu)方面的考慮；
五、寫系統(tǒng)構(gòu)架設(shè)計文檔應(yīng)考慮的問題
六、結(jié)語

一、與構(gòu)架有關(guān)的幾個基本概念：
1、模塊（module）：一組完成指定功能的語句，包括：輸入、輸出、邏輯處理功能、內(nèi)部信息、運行環(huán)境（與功能對應(yīng)但不是一對一關(guān)系）。
2、組件（component）：系統(tǒng)中相當重要的、幾乎是獨立的可替換部分，它在明確定義的構(gòu)架環(huán)境中實現(xiàn)確切的功能。
3、模式（pattern）：指經(jīng)過驗證，至少適用于一種實用環(huán)境（更多時候是好幾種環(huán)境）的解決方案模板（用于結(jié)構(gòu)和行為。在 UML 中：模式由參數(shù)化的協(xié)作來表示，但 UML 不直接對模式的其他方面（如使用結(jié)果列表、使用示例等，它們可由文本來表示）進行建模。存在各種范圍和抽象程度的模式，例如，構(gòu)架模式、分析模式、設(shè)計模式和代碼模式或?qū)嵤┠Ｊ健ＤＪ綄⒖梢詭椭覀冏プ≈攸c。構(gòu)架也是存在模式的。比如，對于系統(tǒng)結(jié)構(gòu)設(shè)計，我們使用層模式；對于分布式系統(tǒng)，我們使用代理模式（通過使用代理來替代實際的對象，使程序能夠控制對該對象的訪問）；對于交互系統(tǒng)，我們使用MVC（M模型(對象)／V視圖(輸出管理)／C控制器(輸入處理)）模式。模式是針對特定問題的解，因此，我們也可以針對需求的特點采用相應(yīng)的模式來設(shè)計構(gòu)架。
4、構(gòu)架模式（architectural pattern）：表示軟件系統(tǒng)的基本結(jié)構(gòu)組織方案。它提供了一組預(yù)定義的子系統(tǒng)、指定它們的職責，并且包括用于組織其間關(guān)系的規(guī)則和指導(dǎo)。
5、層（layer）：對模型中同一抽象層次上的包進行分組的一種特定方式。通過分層，從邏輯上將子系統(tǒng)劃分成許多集合，而層間關(guān)系的形成要遵循一定的規(guī)則。通過分層，可以限制子系統(tǒng)間的依賴關(guān)系，使系統(tǒng)以更松散的方式耦合，從而更易于維護。（層是對構(gòu)架的橫向劃分，分區(qū)是對構(gòu)架的縱向劃分）。
6、系統(tǒng)分層的幾種常用方法：
1） 常用三層服務(wù)：用戶層、業(yè)務(wù)邏輯層、數(shù)據(jù)層；
2） 多層結(jié)構(gòu)的技術(shù)組成模型：表現(xiàn)層、屑洳恪⑹薟悖?br> 3） 網(wǎng)絡(luò)系統(tǒng)常用三層結(jié)構(gòu)：核心層、匯聚層和接入層；
4） RUP典型分層方法：應(yīng)用層、專業(yè)業(yè)務(wù)層、中間件層、系統(tǒng)軟件層；
5） 基于Java的B/S模式系統(tǒng)結(jié)構(gòu)：瀏覽器端、服務(wù)器端、請求接收層、請求處理層；
6） 某六層結(jié)構(gòu)：功能層（用戶界面）、模塊層、組裝層（軟件總線）、服務(wù)層（數(shù)據(jù)處理）、數(shù)據(jù)層、核心層；
7、構(gòu)架（Architecture，愿意為建筑學設(shè)計和建筑物建造的藝術(shù)與科學）: 在RUP中的定義：軟件系統(tǒng)的構(gòu)架（在某一給定點）是指系統(tǒng)重要構(gòu)件的組織或結(jié)構(gòu)，這些重要構(gòu)件通過接口與不斷減小的構(gòu)件與接口所組成的構(gòu)件進行交互；《軟件構(gòu)架實踐》中的定義：某個軟件或者計算系統(tǒng)的軟件構(gòu)架即組成該系統(tǒng)的一個或者多個結(jié)構(gòu)，他們組成軟件的各個部分，形成這些組件的外部可見屬性及相互間的聯(lián)系；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，構(gòu)架是系統(tǒng)在其所處環(huán)境中的最高層次的概念。軟件系統(tǒng)的構(gòu)架是通過接口交互的重要構(gòu)件（在特定時間點）的組織或結(jié)構(gòu)，這些構(gòu)件又由一些更小的構(gòu)件和接口組成。（“構(gòu)架”可以作為名詞，也可作為動詞，作為動詞的“構(gòu)架”相當于“構(gòu)架設(shè)計”）
8、構(gòu)架的描述方式：“4＋1”視圖（用例視圖、設(shè)計視圖、實現(xiàn)視圖、過程視圖、配置視圖）是一個被廣為使用的構(gòu)架描述的模型；RUP過程的構(gòu)架描述模板在“4＋1”視圖的基礎(chǔ)上增加了可選的數(shù)據(jù)視圖（從永久性數(shù)據(jù)存儲方面來對系統(tǒng)進行說明）；HP公司的軟件描述模板也是基于“4＋1”視圖。
9、結(jié)構(gòu)：軟件構(gòu)架是多種結(jié)構(gòu)的體現(xiàn)，結(jié)構(gòu)是系統(tǒng)構(gòu)架從不同角度觀察所產(chǎn)生的視圖。就像建筑物的結(jié)構(gòu)會隨著觀察動機和出發(fā)點的不同而有多種含義一樣，軟件構(gòu)架也表現(xiàn)為多種結(jié)構(gòu)。常見的軟件結(jié)構(gòu)有：模塊結(jié)構(gòu)、邏輯或概念結(jié)構(gòu)、進程或協(xié)調(diào)結(jié)構(gòu)、物理結(jié)構(gòu)、使用結(jié)構(gòu)、調(diào)用結(jié)構(gòu)、數(shù)據(jù)流、控制流、類結(jié)構(gòu)等等。

二、構(gòu)架設(shè)計應(yīng)考慮的因素概攬：
模塊構(gòu)架設(shè)計可以從程序的運行時結(jié)構(gòu)和源代碼的組織結(jié)構(gòu)方面考慮。
1、程序的運行時結(jié)構(gòu)方面的考慮：
1） 需求的符合性：正確性、完整性；功能性需求、非功能性需求；
2） 總體性能（內(nèi)存管理、數(shù)據(jù)庫組織和內(nèi)容、非數(shù)據(jù)庫信息、任務(wù)并行性、網(wǎng)絡(luò)多人操作、關(guān)鍵算法、與網(wǎng)絡(luò)、硬件和其他系統(tǒng)接口對性能的影響）；
3） 運行可管理性：便于控制系統(tǒng)運行、監(jiān)視系統(tǒng)狀態(tài)、錯誤處理；模塊間通信的簡單性；與可維護性不同；
4） 與其他系統(tǒng)接口兼容性；
5） 與網(wǎng)絡(luò)、硬件接口兼容性及性能；
6） 系統(tǒng)安全性；
7） 系統(tǒng)可靠性；
8） 業(yè)務(wù)流程的可調(diào)整性；
9） 業(yè)務(wù)信息的可調(diào)整性
10） 使用方便性
11） 構(gòu)架樣式的一致性
注：運行時負載均衡可以從系統(tǒng)性能、系統(tǒng)可靠性方面考慮。
2、源代碼的組織結(jié)構(gòu)方面的考慮：
1） 開發(fā)可管理性：便于人員分工（模塊獨立性、開發(fā)工作的負載均衡、進度安排優(yōu)化、預(yù)防人員流動對開發(fā)的影響）、利于配置管理、大小的合理性與適度復(fù)雜性；
2） 可維護性：與運行可管理性不同；
3） 可擴充性：系統(tǒng)方案的升級、擴容、擴充性能；
4） 可移植性：不同客戶端、應(yīng)用服務(wù)器、數(shù)據(jù)庫管理系統(tǒng)；
5） 需求的符合性（源代碼的組織結(jié)構(gòu)方面的考慮）。?

三、程序的運行時結(jié)構(gòu)方面的考慮：
1、 需求的符合性：正確性、完整性；功能性需求、非功能性需求
軟件項目最主要的目標是滿足客戶需求。在進行構(gòu)架設(shè)計的時候，大家考慮更多的是使用哪個運行平臺、編成語言、開發(fā)環(huán)境、數(shù)據(jù)庫管理系統(tǒng)等問題，對于和客戶需求相關(guān)的問題考慮不足、不夠系統(tǒng)。如果無論怎么好的構(gòu)架都無法滿足客戶明確的某個功能性需求或非功能性需求，就應(yīng)該與客戶協(xié)調(diào)在項目范圍和需求規(guī)格說明書中刪除這一需求。否則，架構(gòu)設(shè)計應(yīng)以滿足客戶所有明確需求為最基本目標，盡量滿足其隱含的需求。（客戶的非功能性需求可能包括接口、系統(tǒng)安全性、可靠性、移植性、擴展性等等，在其他小節(jié)中細述）
一般來說，功能需求決定業(yè)務(wù)構(gòu)架、非功能需求決定技術(shù)構(gòu)架，變化案例決定構(gòu)架的范圍。需求方面的知識告訴我們，功能需求定義了軟件能夠做些什么。我們需要根據(jù)業(yè)務(wù)上的需求來設(shè)計業(yè)務(wù)構(gòu)架，以使得未來的軟件能夠滿足客戶的需要。非功能需求定義了一些性能、效率上的一些約束、規(guī)則。而我們的技術(shù)構(gòu)架要能夠滿足這些約束和規(guī)則。變化案例是對未來可能發(fā)生的變化的一個估計，結(jié)合功能需求和非功能需求，我們就可以確定一個需求的范圍，進而確定一個構(gòu)架的范圍。（此段From林星）
這里講一個前幾年因客戶某些需求錯誤造成構(gòu)架設(shè)計問題而引起系統(tǒng)性能和可靠性問題的小小的例子：此系統(tǒng)的需求本身是比較簡單的，就是將某城市的某業(yè)務(wù)的全部歷史檔案卡片掃描存儲起來，以便可以按照姓名進行查詢。需求階段客戶說卡片大約有20萬張，需求調(diào)研者出于對客戶的信任沒有對數(shù)據(jù)的總量進行查證。由于是中小型數(shù)據(jù)量，并且今后數(shù)據(jù)不會增加，經(jīng)過計算20萬張卡片總體容量之后，決定使用一種可以單機使用也可以聯(lián)網(wǎng)的中小型數(shù)據(jù)庫管理系統(tǒng)。等到系統(tǒng)完成開始錄入數(shù)據(jù)時，才發(fā)現(xiàn)數(shù)據(jù)至少有60萬，這樣使用那種中小型數(shù)據(jù)庫管理系統(tǒng)不但會造成系統(tǒng)性能的問題，而且其可靠性是非常脆弱的，不得不對系統(tǒng)進行重新設(shè)計。從這個小小的教訓可以看出，需求階段不僅對客戶的功能需求要調(diào)查清楚，對于一些隱含非功能需求的一些數(shù)據(jù)也應(yīng)當調(diào)查清楚，并作為構(gòu)架設(shè)計的依據(jù)。
對于功能需求的正確性，在構(gòu)架設(shè)計文檔中可能不好驗證（需要人工、費力）。對于功能需求完整性，就應(yīng)當使用需求功能與對應(yīng)模塊對照表來跟蹤追溯。對于非功能需求正確性和完整性，可以使用需求非功能與對應(yīng)設(shè)計策略對照表來跟蹤追溯評估。
“軟件設(shè)計工作只有基于用戶需求，立足于可行的技術(shù)才有可能成功。”
2、 總體性能
性能其實也是客戶需求的一部分，當然可能是明確的，也有很多是隱含的，這里把它單獨列出來在說明一次。性能是設(shè)計方案的重要標準，性能應(yīng)考慮的不是單臺客戶端的性能，而是應(yīng)該考慮系統(tǒng)總的綜合性能；
性能設(shè)計應(yīng)從以下幾個方面考慮：內(nèi)存管理、數(shù)據(jù)庫組織和內(nèi)容、非數(shù)據(jù)庫信息、任務(wù)并行性、網(wǎng)絡(luò)多人操作、關(guān)鍵算法、與網(wǎng)絡(luò)、硬件和其他系統(tǒng)接口對性能的影響；
幾點提示：算法優(yōu)化及負載均衡是性能優(yōu)化的方向。經(jīng)常要調(diào)用的模塊要特別注意優(yōu)化。占用內(nèi)存較多的變量在不用時要及時清理掉。需要下載的網(wǎng)頁主題文件過大時應(yīng)當分解為若干部分，讓用戶先把主要部分顯示出來。
3、 運行可管理性
系統(tǒng)的構(gòu)架設(shè)計應(yīng)當為了使系統(tǒng)可以預(yù)測系統(tǒng)故障，防患于未然。現(xiàn)在的系統(tǒng)正逐步向復(fù)雜化、大型化發(fā)展，單靠一個人或幾個人來管理已顯得力不從心，況且對于某些突發(fā)事件的響應(yīng)，人的反應(yīng)明顯不夠。因此通過合理的系統(tǒng)構(gòu)架規(guī)劃系統(tǒng)運行資源，便于控制系統(tǒng)運行、監(jiān)視系統(tǒng)狀態(tài)、進行有效的錯誤處理；為了實現(xiàn)上述目標，模塊間通信應(yīng)當盡可能簡單，同時建立合理詳盡的系統(tǒng)運行日志，系統(tǒng)通過自動審計運行日志，了解系統(tǒng)運行狀態(tài)、進行有效的錯誤處理；（運行可管理性與可維護性不同）
4、 與其他系統(tǒng)接口兼容性（解釋略）
5、 與網(wǎng)絡(luò)、硬件接口兼容性及性能（解釋略）
6、 系統(tǒng)安全性
隨著計算機應(yīng)用的不斷深入和擴大，涉及的部門和信息也越來越多，其中有大量保密信息在網(wǎng)絡(luò)上傳輸，所以對系統(tǒng)安全性的考慮已經(jīng)成為系統(tǒng)設(shè)計的關(guān)鍵，需要從各個方面和角度加以考慮，來保證數(shù)據(jù)資料的絕對安全。
7、 系統(tǒng)可靠性
系統(tǒng)的可靠性是現(xiàn)代信息系統(tǒng)應(yīng)具有的重要特征，由于人們?nèi)粘５墓ぷ鲗ο到y(tǒng)依賴程度越來越多，因此系統(tǒng)的必須可靠。系統(tǒng)構(gòu)架設(shè)計可考慮系統(tǒng)的冗余度，盡可能地避免單點故障。系統(tǒng)可靠性是系統(tǒng)在給定的時間間隔及給定的環(huán)境條件下，按設(shè)計要求，成功地運行程序的概率。成功地運行不僅要保證系統(tǒng)能正確地運行，滿足功能需求，還要求當系統(tǒng)出現(xiàn)意外故障時能夠盡快恢復(fù)正常運行，數(shù)據(jù)不受破壞。
8、 業(yè)務(wù)流程的可調(diào)整性
應(yīng)當考慮客戶業(yè)務(wù)流程可能出現(xiàn)的變化，所以在系統(tǒng)構(gòu)架設(shè)計時要盡量排除業(yè)務(wù)流程的制約，即把流程中的各項業(yè)務(wù)結(jié)點工作作為獨立的對象，設(shè)計成獨立的模塊或組件，充分考慮他們與其他各種業(yè)務(wù)對象模塊或組件的接口，在流程之間通過業(yè)務(wù)對象模塊的相互調(diào)用實現(xiàn)各種業(yè)務(wù)，這樣，在業(yè)務(wù)流程發(fā)生有限的變化時（每個業(yè)務(wù)模塊本身的業(yè)務(wù)邏輯沒有變的情況下），就能夠比較方便地修改系統(tǒng)程序模塊或組件間的調(diào)用關(guān)系而實現(xiàn)新的需求。如果這種調(diào)用關(guān)系被設(shè)計成存儲在配置庫的數(shù)據(jù)字典里，則連程序代碼都不用修改，只需修改數(shù)據(jù)字典里的模塊或組件調(diào)用規(guī)則即可。
9、 業(yè)務(wù)信息的可調(diào)整性
應(yīng)當考慮客戶業(yè)務(wù)信息可能出現(xiàn)的變化，所以在系統(tǒng)構(gòu)架設(shè)計時必須盡可能減少因為業(yè)務(wù)信息的調(diào)整對于代碼模塊的影響范圍。
10、 使用方便性
使用方便性是不須提及的必然的需求，而使用方便性與系統(tǒng)構(gòu)架是密切相關(guān)的。WinCE（1.0）的失敗和后來改進版本的成功就說明了這個問題。WinCE（1.0）有太多層次的視窗和菜單，而用戶則更喜歡簡單的界面和快捷的操作。失敗了應(yīng)當及時糾正，但最好不要等到失敗了再來糾正，這樣會浪費巨大的財力物力，所以在系統(tǒng)構(gòu)架階段最好能將需要考慮的因素都考慮到。當然使用方便性必須與系統(tǒng)安全性協(xié)調(diào)平衡統(tǒng)一，使用方便性也必須與業(yè)務(wù)流程的可調(diào)整性和業(yè)務(wù)信息的可調(diào)整性協(xié)調(diào)平衡統(tǒng)一。“滿足用戶的需求，便于用戶使用，同時又使得操作流程盡可能簡單。這就是設(shè)計之本。”
11、構(gòu)架樣式的一致性
軟件系統(tǒng)的構(gòu)架樣式有些類似于建筑樣式（如中國式、哥特式、希臘復(fù)古式）。軟件構(gòu)架樣式可分為數(shù)據(jù)流構(gòu)架樣式、調(diào)用返回構(gòu)架樣式、獨立組件構(gòu)架樣式、以數(shù)據(jù)為中心的構(gòu)架樣式和虛擬機構(gòu)架樣式，每一種樣式還可以分為若干子樣式。構(gòu)架樣式的一致性并不是要求一個軟件系統(tǒng)只能采用一種樣式，就像建筑樣式可以是中西結(jié)合的，軟件系統(tǒng)也可以有異質(zhì)構(gòu)架樣式（分為局部異質(zhì)、層次異質(zhì)、并行異質(zhì)），即多種樣式的綜合，但這樣的綜合應(yīng)該考慮其某些方面的一致性和協(xié)調(diào)性。每一種樣式都有其使用的時機，應(yīng)當根據(jù)系統(tǒng)最強調(diào)的質(zhì)量屬性來選擇。?

四、源代碼的組織結(jié)構(gòu)方面的考慮：
1、 開發(fā)可管理性
便于人員分工（模塊獨立性、開發(fā)工作的負載均衡、進度安排優(yōu)化、預(yù)防人員流動對開發(fā)的影響：一個好的構(gòu)架同時應(yīng)有助于減少項目組的壓力和緊張，提高軟件開發(fā)效率）、利于配置管理、大小的合理性、適度復(fù)雜性；
1）便于人員分工－模塊獨立性、層次性
模塊獨立性、層次性是為了保證項目開發(fā)成員工作之間的相對獨立性，模塊聯(lián)結(jié)方式應(yīng)該是縱向而不是橫向, 模塊之間應(yīng)該是樹狀結(jié)構(gòu)而不是網(wǎng)狀結(jié)構(gòu)或交叉結(jié)構(gòu)，這樣就可以把開發(fā)人員之間的通信、模塊開發(fā)制約關(guān)系減到最少。同時模塊獨立性也比較利于配置管理工作的進行。現(xiàn)在有越來越多的的軟件開發(fā)是在異地進行，一個開發(fā)組的成員可能在不同城市甚至在不同國家，因此便于異地開發(fā)的人員分工與配置管理的源代碼組織結(jié)構(gòu)是非常必要的。
2）便于人員分工－開發(fā)工作的負載均衡
不僅僅是開發(fā)出來的軟件系統(tǒng)需要負載均衡，在開發(fā)過程中開發(fā)小組各成員之間工作任務(wù)的負載均衡也是非重要的。所謂工作任務(wù)的負載均衡就是通過合理的任務(wù)劃分按照開發(fā)人員特點進行分配任務(wù)，盡量讓項目組中的每個人每段時間都有用武之地。這就需要在構(gòu)架設(shè)計時應(yīng)當充分考慮項目組手頭的人力資源，在實現(xiàn)客戶需求的基礎(chǔ)上實現(xiàn)開發(fā)工作的負載均衡，以提高整體開發(fā)效率。
3）便于人員分工－進度安排優(yōu)化；
進度安排優(yōu)化的前提是模塊獨立性并搞清楚模塊開發(fā)的先后制約關(guān)系。利用工作分解結(jié)構(gòu)對所有程序編碼工作進行分解，得到每一項工作的輸入、輸出、所需資源、持續(xù)時間、前期應(yīng)完成的工作、完成后可以進行的工作。然后預(yù)估各模塊需要時間，分析各模塊的并行與串行（順序制約），繪制出網(wǎng)絡(luò)圖，找出影響整體進度的關(guān)鍵模塊，算出關(guān)鍵路徑，最后對網(wǎng)絡(luò)圖進行調(diào)整，以使進度安排最優(yōu)化。
有個家喻戶曉的智力題叫烤肉片策略：約翰遜家戶外有一個可以同時烤兩塊肉片的烤肉架，烤每塊肉片的每一面需要10分鐘，現(xiàn)要烤三塊肉片給饑腸轆轆急不可耐的一家三口。問題是怎樣才能在最短的時間內(nèi)烤完三片肉。一般的做法花20分鐘先烤完前兩片，再花20分鐘烤完第三片。有一種更好的方法可以節(jié)省10分鐘，大家想想。
4）便于人員分工－預(yù)防員工人員流動對開發(fā)的影響
人員流動在軟件行業(yè)是司空見慣的事情，已經(jīng)是一個常見的風險。作為對這一風險的有效的防范對策之一，可以在構(gòu)架設(shè)計中考慮到并預(yù)防員工人員流動對開發(fā)的影響。主要的思路還是在模塊的獨立性上（追求高內(nèi)聚低耦合），組件化是目前流行的趨勢。
5）利于配置管理（獨立性、層次性）
利于配置管理與利于人員分工有一定的聯(lián)系。除了邏輯上的模塊組件要利于人員分工外，物理上的源代碼層次結(jié)構(gòu)、目錄結(jié)構(gòu)、各模塊所處源代碼文件的部署也應(yīng)當利于人員分工和配置管理。（盡管現(xiàn)在配置管理工具有較強大的功能，但一個清楚的源碼分割和模塊分割是非常有好處的）。
6）大小的合理性與適度復(fù)雜性
大小的合理性與適度復(fù)雜性可以使開發(fā)工作的負載均衡，便于進度的安排，也可以使系統(tǒng)在運行時減少不必要的內(nèi)存資源浪費。對于代碼的可閱讀性和系統(tǒng)的可維護性也有一定的好處。另外，過大的模塊常常是系統(tǒng)分解不充分，而過小的模塊有可能降低模塊的獨立性，造成系統(tǒng)接口的復(fù)雜。
2、 可維護性
便于在系統(tǒng)出現(xiàn)故障時及時方便地找到產(chǎn)生故障的原因和源代碼位置，并能方便地進行局部修改、切割；（可維護性與運行可管理性不同）
3、 可擴充性：系統(tǒng)方案的升級、擴容、擴充性能
系統(tǒng)在建成后會有一段很長的運行周期，在該周期內(nèi)，應(yīng)用在不斷增加，應(yīng)用的層次在不斷升級，因此采用的構(gòu)架設(shè)計等方案因充分考慮升級、擴容、擴充的可行性和便利
4、 可移植性
不同客戶端、應(yīng)用服務(wù)器、數(shù)據(jù)庫管理系統(tǒng)：如果潛在的客戶使用的客戶端可能使用不同的操作系統(tǒng)或瀏覽器，其可移植性必須考慮客戶端程序的可移植性，或盡量不使業(yè)務(wù)邏輯放在客戶端；數(shù)據(jù)處理的業(yè)務(wù)邏輯放在數(shù)據(jù)庫管理系統(tǒng)中會有較好的性能，但如果客戶群中不能確定使用的是同一種數(shù)據(jù)庫管理系統(tǒng)，則業(yè)務(wù)邏輯就不能數(shù)據(jù)庫管理系統(tǒng)中；
達到可移植性一定要注重標準化和開放性：只有廣泛采用遵循國際標準，開發(fā)出開放性強的產(chǎn)品，才可以保證各種類型的系統(tǒng)的充分互聯(lián)，從而使產(chǎn)品更具有市場競爭力，也為未來的系統(tǒng)移植和升級擴展提供了基礎(chǔ)。
5、 需求的符合性
從源代碼的組織結(jié)構(gòu)看需求的符合型主要考慮針對用戶需求可能的變化的軟件代碼及構(gòu)架的最小冗余（同時又要使得系統(tǒng)具有一定的可擴展性）。

五、寫系統(tǒng)構(gòu)架設(shè)計文檔應(yīng)考慮的問題
構(gòu)架工作應(yīng)該在需求開發(fā)完成約80％的時候開始進行，不必等到需求開發(fā)全部完成，需要項目經(jīng)理以具體的判斷來評估此時是否足以開始構(gòu)建軟件構(gòu)架。
給出一致的輪廓：系統(tǒng)概述。一個系統(tǒng)構(gòu)架需要現(xiàn)有概括的描述，開發(fā)人員才能從上千個細節(jié)甚至數(shù)十個模塊或?qū)ο箢愔薪⒁恢碌妮喞?br />構(gòu)架的目標應(yīng)該能夠清楚說明系統(tǒng)概念，構(gòu)架應(yīng)盡可能簡化，最好的構(gòu)架文件應(yīng)該簡單、簡短，清晰而不雜亂，解決方案自然。
構(gòu)架應(yīng)單先定義上層的主要子系統(tǒng)，應(yīng)該描述各子系統(tǒng)的任務(wù)，并提供每個子系統(tǒng)中各模塊或?qū)ο箢惖牡某醪搅斜怼?br />構(gòu)架應(yīng)該描述不同子系統(tǒng)間相互通信的方式，而一個良好的構(gòu)架應(yīng)該將子系統(tǒng)間的通信關(guān)系降到最低。
成功構(gòu)架的一個重要特色，在于標明最可能變更的領(lǐng)域，應(yīng)當列出程序中最可能變更的部分，說明構(gòu)架的其他部分如何應(yīng)變。
復(fù)用分析、外購：縮短軟件開發(fā)周期、降低成本的有效方案未必是自行開發(fā)軟件，可以對現(xiàn)有軟件進行復(fù)用或進行外購。應(yīng)考慮其對構(gòu)架的影響。
除了系統(tǒng)組織的問題，構(gòu)架應(yīng)重點考慮對于細節(jié)全面影響的設(shè)計決策，深入這些決策領(lǐng)域：外部軟件接口（兼容性、通信方式、傳遞數(shù)據(jù)結(jié)構(gòu)）、用戶接口（用戶接口和系統(tǒng)層次劃分）、數(shù)據(jù)庫組織和內(nèi)容、非數(shù)據(jù)庫信息、關(guān)鍵算法、內(nèi)存管理（配置策略）、并行性、安全性、可移植性、網(wǎng)絡(luò)多人操作、錯誤處理。
要保證需求的可追蹤性，即保證每個需求功能都有相應(yīng)模塊去實現(xiàn)。
構(gòu)架不能只依據(jù)靜態(tài)的系統(tǒng)目標來設(shè)計，也應(yīng)當考慮動態(tài)的開發(fā)過程，如人力資源的情況，進度要求的情況，開發(fā)環(huán)境的滿足情況。構(gòu)架必須支持階段性規(guī)劃，應(yīng)該能夠提供階段性規(guī)劃中如何開發(fā)與完成的方式。不應(yīng)該依賴無法獨立運行的子系統(tǒng)構(gòu)架。將系統(tǒng)各部分的、依賴關(guān)系找出來，形成一套開發(fā)計劃。

六、結(jié)語
系統(tǒng)構(gòu)架設(shè)計和千差萬別的具體的開發(fā)平臺密切相關(guān)，因此在此無法給出通用的解決方案，主要是為了說明哪些因素是需要考慮的。對于每個因素的設(shè)計策略和本文未提到的因素需要軟件構(gòu)架設(shè)計師在具體開發(fā)實踐中靈活把握。不同因素之間有時是矛盾的，構(gòu)架設(shè)計時需要根據(jù)具體情況進行平衡。

參考文獻
《軟件構(gòu)架實踐》SEI軟件工程譯叢，林·巴斯著
《微軟項目：求生法則》Steve McConnell著，余孟學譯
《實用軟件工程》第二版，鄭人杰、殷人昆、陶永雷等著
《軟件工程：實踐者的研究方法》（第5版）Roger S.Pressman著
《軟件開發(fā)的科學與藝術(shù)》陳宏剛等著
本文作者郵箱：luls@dragonsoft.com.cn或lulsnet@21cn.com