二、構(gòu)架設(shè)計應考慮的因素概攬：
模塊構(gòu)架設(shè)計可以從程序的運行時結(jié)構(gòu)和源代碼的組織結(jié)構(gòu)方面考慮。
1、程序的運行時結(jié)構(gòu)方面的考慮：
1） 需求的符合性：正確性、完整性；功能性需求、非功能性需求；
2） 總體性能（內(nèi)存管理、數(shù)據(jù)庫組織和內(nèi)容、非數(shù)據(jù)庫信息、任務并行性、網(wǎng)絡多人操作、關(guān)鍵算法、與網(wǎng)絡、硬件和其他系統(tǒng)接口對性能的影響）；
3） 運行可管理性：便于控制系統(tǒng)運行、監(jiān)視系統(tǒng)狀態(tài)、錯誤處理；模塊間通信的簡單性；與可維護性不同；
4） 與其他系統(tǒng)接口兼容性；
5） 與網(wǎng)絡、硬件接口兼容性及性能；
6） 系統(tǒng)安全性；
7） 系統(tǒng)可靠性；
8） 業(yè)務流程的可調(diào)整性；
9） 業(yè)務信息的可調(diào)整性
10） 使用方便性
11） 構(gòu)架樣式的一致性
注：運行時負載均衡可以從系統(tǒng)性能、系統(tǒng)可靠性方面考慮。
2、源代碼的組織結(jié)構(gòu)方面的考慮：
1） 開發(fā)可管理性：便于人員分工（模塊獨立性、開發(fā)工作的負載均衡、進度安排優(yōu)化、預防人員流動對開發(fā)的影響）、利于配置管理、大小的合理性與適度復雜性；
2） 可維護性：與運行可管理性不同；
3） 可擴充性：系統(tǒng)方案的升級、擴容、擴充性能；
4） 可移植性：不同客戶端、應用服務器、數(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)架都無法滿足客戶明確的某個功能性需求或非功能性需求，就應該與客戶協(xié)調(diào)在項目范圍和需求規(guī)格說明書中刪除這一需求。否則，架構(gòu)設(shè)計應以滿足客戶所有明確需求為最基本目標，盡量滿足其隱含的需求。（客戶的非功能性需求可能包括接口、系統(tǒng)安全性、可靠性、移植性、擴展性等等，在其他小節(jié)中細述）
一般來說，功能需求決定業(yè)務構(gòu)架、非功能需求決定技術(shù)構(gòu)架，變化案例決定構(gòu)架的范圍。需求方面的知識告訴我們，功能需求定義了軟件能夠做些什么。我們需要根據(jù)業(yè)務上的需求來設(shè)計業(yè)務構(gòu)架，以使得未來的軟件能夠滿足客戶的需要。非功能需求定義了一些性能、效率上的一些約束、規(guī)則。而我們的技術(shù)構(gòu)架要能夠滿足這些約束和規(guī)則。變化案例是對未來可能發(fā)生的變化的一個估計，結(jié)合功能需求和非功能需求，我們就可以確定一個需求的范圍，進而確定一個構(gòu)架的范圍。（此段From林星）
這里講一個前幾年因客戶某些需求錯誤造成構(gòu)架設(shè)計問題而引起系統(tǒng)性能和可靠性問題的小小的例子：此系統(tǒng)的需求本身是比較簡單的，就是將某城市的某業(yè)務的全部歷史檔案卡片掃描存儲起來，以便可以按照姓名進行查詢。需求階段客戶說卡片大約有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ù)也應當調(diào)查清楚，并作為構(gòu)架設(shè)計的依據(jù)。
對于功能需求的正確性，在構(gòu)架設(shè)計文檔中可能不好驗證（需要人工、費力）。對于功能需求完整性，就應當使用需求功能與對應模塊對照表來跟蹤追溯。對于非功能需求正確性和完整性，可以使用需求非功能與對應設(shè)計策略對照表來跟蹤追溯評估。
“軟件設(shè)計工作只有基于用戶需求，立足于可行的技術(shù)才有可能成功?！?
模塊構(gòu)架設(shè)計可以從程序的運行時結(jié)構(gòu)和源代碼的組織結(jié)構(gòu)方面考慮。
1、程序的運行時結(jié)構(gòu)方面的考慮：
1） 需求的符合性：正確性、完整性；功能性需求、非功能性需求；
2） 總體性能（內(nèi)存管理、數(shù)據(jù)庫組織和內(nèi)容、非數(shù)據(jù)庫信息、任務并行性、網(wǎng)絡多人操作、關(guān)鍵算法、與網(wǎng)絡、硬件和其他系統(tǒng)接口對性能的影響）；
3） 運行可管理性：便于控制系統(tǒng)運行、監(jiān)視系統(tǒng)狀態(tài)、錯誤處理；模塊間通信的簡單性；與可維護性不同；
4） 與其他系統(tǒng)接口兼容性；
5） 與網(wǎng)絡、硬件接口兼容性及性能；
6） 系統(tǒng)安全性；
7） 系統(tǒng)可靠性；
8） 業(yè)務流程的可調(diào)整性；
9） 業(yè)務信息的可調(diào)整性
10） 使用方便性
11） 構(gòu)架樣式的一致性
注：運行時負載均衡可以從系統(tǒng)性能、系統(tǒng)可靠性方面考慮。
2、源代碼的組織結(jié)構(gòu)方面的考慮：
1） 開發(fā)可管理性：便于人員分工（模塊獨立性、開發(fā)工作的負載均衡、進度安排優(yōu)化、預防人員流動對開發(fā)的影響）、利于配置管理、大小的合理性與適度復雜性；
2） 可維護性：與運行可管理性不同；
3） 可擴充性：系統(tǒng)方案的升級、擴容、擴充性能；
4） 可移植性：不同客戶端、應用服務器、數(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)架都無法滿足客戶明確的某個功能性需求或非功能性需求，就應該與客戶協(xié)調(diào)在項目范圍和需求規(guī)格說明書中刪除這一需求。否則，架構(gòu)設(shè)計應以滿足客戶所有明確需求為最基本目標，盡量滿足其隱含的需求。（客戶的非功能性需求可能包括接口、系統(tǒng)安全性、可靠性、移植性、擴展性等等，在其他小節(jié)中細述）
一般來說，功能需求決定業(yè)務構(gòu)架、非功能需求決定技術(shù)構(gòu)架，變化案例決定構(gòu)架的范圍。需求方面的知識告訴我們，功能需求定義了軟件能夠做些什么。我們需要根據(jù)業(yè)務上的需求來設(shè)計業(yè)務構(gòu)架，以使得未來的軟件能夠滿足客戶的需要。非功能需求定義了一些性能、效率上的一些約束、規(guī)則。而我們的技術(shù)構(gòu)架要能夠滿足這些約束和規(guī)則。變化案例是對未來可能發(fā)生的變化的一個估計，結(jié)合功能需求和非功能需求，我們就可以確定一個需求的范圍，進而確定一個構(gòu)架的范圍。（此段From林星）
這里講一個前幾年因客戶某些需求錯誤造成構(gòu)架設(shè)計問題而引起系統(tǒng)性能和可靠性問題的小小的例子：此系統(tǒng)的需求本身是比較簡單的，就是將某城市的某業(yè)務的全部歷史檔案卡片掃描存儲起來，以便可以按照姓名進行查詢。需求階段客戶說卡片大約有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ù)也應當調(diào)查清楚，并作為構(gòu)架設(shè)計的依據(jù)。
對于功能需求的正確性，在構(gòu)架設(shè)計文檔中可能不好驗證（需要人工、費力）。對于功能需求完整性，就應當使用需求功能與對應模塊對照表來跟蹤追溯。對于非功能需求正確性和完整性，可以使用需求非功能與對應設(shè)計策略對照表來跟蹤追溯評估。
“軟件設(shè)計工作只有基于用戶需求，立足于可行的技術(shù)才有可能成功?！?