| 系統構架設計應考慮的因素
來(lái)自：51CMM.COM
作者：廈門(mén)巨龍軟件工程有限公司 盧琳生
[2003/12/29]
摘要：
本文從程序的運行時(shí)結構和源代碼的組織結構兩個(gè)方面探討了系統構架設計應考慮的各種因素，列舉了系統構架設計文檔應考慮的一些問(wèn)題。
關(guān)鍵字：
系統構架、設計、考慮、因素
正文：
約公元前25年，古羅馬建筑師維特魯威說(shuō)：“理想的建筑師應該既是文學(xué)家又是數字家，他還應通曉歷史，熱衷于哲學(xué)研究，精通音樂(lè )，懂得醫藥知識，具有法學(xué)造詣，深諳天文學(xué)及天文計算。”（好難哪，軟件構架設計師的要求呢？大家好好想想吧。）
本文目錄
一、與構架有關(guān)的幾個(gè)基本概念；
二、構架設計應考慮的因素概攬；
三、程序的運行時(shí)結構方面的考慮；
四、源代碼的組織結構方面的考慮；
五、寫(xiě)系統構架設計文檔應考慮的問(wèn)題
六、結語(yǔ) 一、與構架有關(guān)的幾個(gè)基本概念：
1、模塊（module）：一組完成指定功能的語(yǔ)句，包括：輸入、輸出、邏輯處理功能、內部信息、運行環(huán)境（與功能對應但不是一對一關(guān)系）。
2、組件（component）：系統中相當重要的、幾乎是獨立的可替換部分，它在明確定義的構架環(huán)境中實(shí)現確切的功能。
3、模式（pattern）：指經(jīng)過(guò)驗證，至少適用于一種實(shí)用環(huán)境（更多時(shí)候是好幾種環(huán)境）的解決方案模板（用于結構和行為。在 UML 中：模式由參數化的協(xié)作來(lái)表示，但 UML 不直接對模式的其他方面（如使用結果列表、使用示例等，它們可由文本來(lái)表示）進(jìn)行建模。存在各種范圍和抽象程度的模式，例如，構架模式、分析模式、設計模式和代碼模式或實(shí)施模式。模式將可以幫助我們抓住重點(diǎn)。構架也是存在模式的。比如，對于系統結構設計，我們使用層模式；對于分布式系統，我們使用代理模式（通過(guò)使用代理來(lái)替代實(shí)際的對象，使程序能夠控制對該對象的訪(fǎng)問(wèn)）；對于交互系統，我們使用MVC（M模型(對象)／V視圖(輸出管理)／C控制器(輸入處理)）模式。模式是針對特定問(wèn)題的解，因此，我們也可以針對需求的特點(diǎn)采用相應的模式來(lái)設計構架。
4、構架模式（architectural pattern）：表示軟件系統的基本結構組織方案。它提供了一組預定義的子系統、指定它們的職責，并且包括用于組織其間關(guān)系的規則和指導。
5、層（layer）：對模型中同一抽象層次上的包進(jìn)行分組的一種特定方式。通過(guò)分層，從邏輯上將子系統劃分成許多集合，而層間關(guān)系的形成要遵循一定的規則。通過(guò)分層，可以限制子系統間的依賴(lài)關(guān)系，使系統以更松散的方式耦合，從而更易于維護。（層是對構架的橫向劃分，分區是對構架的縱向劃分）。
6、系統分層的幾種常用方法：
1） 常用三層服務(wù)：用戶(hù)層、業(yè)務(wù)邏輯層、數據層；
2） 多層結構的技術(shù)組成模型：表現層、中間層、數據層；
3） 網(wǎng)絡(luò )系統常用三層結構：核心層、匯聚層和接入層；
4） RUP典型分層方法：應用層、專(zhuān)業(yè)業(yè)務(wù)層、中間件層、系統軟件層；
5） 基于Java的B/S模式系統結構：瀏覽器端、服務(wù)器端、請求接收層、請求處理層；
6） 某六層結構：功能層（用戶(hù)界面）、模塊層、組裝層（軟件總線(xiàn)）、服務(wù)層（數據處理）、數據層、核心層；
7、構架（Architecture，愿意為建筑學(xué)設計和建筑物建造的藝術(shù)與科學(xué)）: 在RUP中的定義：軟件系統的構架（在某一給定點(diǎn)）是指系統重要構件的組織或結構，這些重要構件通過(guò)接口與不斷減小的構件與接口所組成的構件進(jìn)行交互；《軟件構架實(shí)踐》中的定義：某個(gè)軟件或者計算系統的軟件構架即組成該系統的一個(gè)或者多個(gè)結構，他們組成軟件的各個(gè)部分，形成這些組件的外部可見(jiàn)屬性及相互間的聯(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，構架是系統在其所處環(huán)境中的最高層次的概念。軟件系統的構架是通過(guò)接口交互的重要構件（在特定時(shí)間點(diǎn)）的組織或結構，這些構件又由一些更小的構件和接口組成。（“構架”可以作為名詞，也可作為動(dòng)詞，作為動(dòng)詞的“構架”相當于“構架設計”）
8、構架的描述方式：“4＋1”視圖（用例視圖、設計視圖、實(shí)現視圖、過(guò)程視圖、配置視圖）是一個(gè)被廣為使用的構架描述的模型；RUP過(guò)程的構架描述模板在“4＋1”視圖的基礎上增加了可選的數據視圖（從永久性數據存儲方面來(lái)對系統進(jìn)行說(shuō)明）；HP公司的軟件描述模板也是基于“4＋1”視圖。
9、結構：軟件構架是多種結構的體現，結構是系統構架從不同角度觀(guān)察所產(chǎn)生的視圖。就像建筑物的結構會(huì )隨著(zhù)觀(guān)察動(dòng)機和出發(fā)點(diǎn)的不同而有多種含義一樣，軟件構架也表現為多種結構。常見(jiàn)的軟件結構有：模塊結構、邏輯或概念結構、進(jìn)程或協(xié)調結構、物理結構、使用結構、調用結構、數據流、控制流、類(lèi)結構等等。 二、構架設計應考慮的因素概攬：
模塊構架設計可以從程序的運行時(shí)結構和源代碼的組織結構方面考慮。
1、程序的運行時(shí)結構方面的考慮：
1） 需求的符合性：正確性、完整性；功能性需求、非功能性需求；
2） 總體性能（內存管理、數據庫組織和內容、非數據庫信息、任務(wù)并行性、網(wǎng)絡(luò )多人操作、關(guān)鍵算法、與網(wǎng)絡(luò )、硬件和其他系統接口對性能的影響）；
3） 運行可管理性：便于控制系統運行、監視系統狀態(tài)、錯誤處理；模塊間通信的簡(jiǎn)單性；與可維護性不同；
4） 與其他系統接口兼容性；
5） 與網(wǎng)絡(luò )、硬件接口兼容性及性能；
6） 系統安全性；
7） 系統可靠性；
8） 業(yè)務(wù)流程的可調整性；
9） 業(yè)務(wù)信息的可調整性
10） 使用方便性
11） 構架樣式的一致性
注：運行時(shí)負載均衡可以從系統性能、系統可靠性方面考慮。
2、源代碼的組織結構方面的考慮：
1） 開(kāi)發(fā)可管理性：便于人員分工（模塊獨立性、開(kāi)發(fā)工作的負載均衡、進(jìn)度安排優(yōu)化、預防人員流動(dòng)對開(kāi)發(fā)的影響）、利于配置管理、大小的合理性與適度復雜性；
2） 可維護性：與運行可管理性不同；
3） 可擴充性：系統方案的升級、擴容、擴充性能；
4） 可移植性：不同客戶(hù)端、應用服務(wù)器、數據庫管理系統；
5） 需求的符合性（源代碼的組織結構方面的考慮）。
三、程序的運行時(shí)結構方面的考慮：
1、 需求的符合性：正確性、完整性；功能性需求、非功能性需求
軟件項目最主要的目標是滿(mǎn)足客戶(hù)需求。在進(jìn)行構架設計的時(shí)候，大家考慮更多的是使用哪個(gè)運行平臺、編成語(yǔ)言、開(kāi)發(fā)環(huán)境、數據庫管理系統等問(wèn)題，對于和客戶(hù)需求相關(guān)的問(wèn)題考慮不足、不夠系統。如果無(wú)論怎么好的構架都無(wú)法滿(mǎn)足客戶(hù)明確的某個(gè)功能性需求或非功能性需求，就應該與客戶(hù)協(xié)調在項目范圍和需求規格說(shuō)明書(shū)中刪除這一需求。否則，架構設計應以滿(mǎn)足客戶(hù)所有明確需求為最基本目標，盡量滿(mǎn)足其隱含的需求。（客戶(hù)的非功能性需求可能包括接口、系統安全性、可靠性、移植性、擴展性等等，在其他小節中細述）
一般來(lái)說(shuō)，功能需求決定業(yè)務(wù)構架、非功能需求決定技術(shù)構架，變化案例決定構架的范圍。需求方面的知識告訴我們，功能需求定義了軟件能夠做些什么。我們需要根據業(yè)務(wù)上的需求來(lái)設計業(yè)務(wù)構架，以使得未來(lái)的軟件能夠滿(mǎn)足客戶(hù)的需要。非功能需求定義了一些性能、效率上的一些約束、規則。而我們的技術(shù)構架要能夠滿(mǎn)足這些約束和規則。變化案例是對未來(lái)可能發(fā)生的變化的一個(gè)估計，結合功能需求和非功能需求，我們就可以確定一個(gè)需求的范圍，進(jìn)而確定一個(gè)構架的范圍。（此段From林星）
這里講一個(gè)前幾年因客戶(hù)某些需求錯誤造成構架設計問(wèn)題而引起系統性能和可靠性問(wèn)題的小小的例子：此系統的需求本身是比較簡(jiǎn)單的，就是將某城市的某業(yè)務(wù)的全部歷史檔案卡片掃描存儲起來(lái)，以便可以按照姓名進(jìn)行查詢(xún)。需求階段客戶(hù)說(shuō)卡片大約有20萬(wàn)張，需求調研者出于對客戶(hù)的信任沒(méi)有對數據的總量進(jìn)行查證。由于是中小型數據量，并且今后數據不會(huì )增加，經(jīng)過(guò)計算20萬(wàn)張卡片總體容量之后，決定使用一種可以單機使用也可以聯(lián)網(wǎng)的中小型數據庫管理系統。等到系統完成開(kāi)始錄入數據時(shí)，才發(fā)現數據至少有60萬(wàn)，這樣使用那種中小型數據庫管理系統不但會(huì )造成系統性能的問(wèn)題，而且其可靠性是非常脆弱的，不得不對系統進(jìn)行重新設計。從這個(gè)小小的教訓可以看出，需求階段不僅對客戶(hù)的功能需求要調查清楚，對于一些隱含非功能需求的一些數據也應當調查清楚，并作為構架設計的依據。
對于功能需求的正確性，在構架設計文檔中可能不好驗證（需要人工、費力）。對于功能需求完整性，就應當使用需求功能與對應模塊對照表來(lái)跟蹤追溯。對于非功能需求正確性和完整性，可以使用需求非功能與對應設計策略對照表來(lái)跟蹤追溯評估。
“軟件設計工作只有基于用戶(hù)需求，立足于可行的技術(shù)才有可能成功。”
2、 總體性能
性能其實(shí)也是客戶(hù)需求的一部分，當然可能是明確的，也有很多是隱含的，這里把它單獨列出來(lái)在說(shuō)明一次。性能是設計方案的重要標準，性能應考慮的不是單臺客戶(hù)端的性能，而是應該考慮系統總的綜合性能；
性能設計應從以下幾個(gè)方面考慮：內存管理、數據庫組織和內容、非數據庫信息、任務(wù)并行性、網(wǎng)絡(luò )多人操作、關(guān)鍵算法、與網(wǎng)絡(luò )、硬件和其他系統接口對性能的影響；
幾點(diǎn)提示：算法優(yōu)化及負載均衡是性能優(yōu)化的方向。經(jīng)常要調用的模塊要特別注意優(yōu)化。占用內存較多的變量在不用時(shí)要及時(shí)清理掉。需要下載的網(wǎng)頁(yè)主題文件過(guò)大時(shí)應當分解為若干部分，讓用戶(hù)先把主要部分顯示出來(lái)。
3、 運行可管理性
系統的構架設計應當為了使系統可以預測系統故障，防患于未然?，F在的系統正逐步向復雜化、大型化發(fā)展，單靠一個(gè)人或幾個(gè)人來(lái)管理已顯得力不從心，況且對于某些突發(fā)事件的響應，人的反應明顯不夠。因此通過(guò)合理的系統構架規劃系統運行資源，便于控制系統運行、監視系統狀態(tài)、進(jìn)行有效的錯誤處理；為了實(shí)現上述目標，模塊間通信應當盡可能簡(jiǎn)單，同時(shí)建立合理詳盡的系統運行日志，系統通過(guò)自動(dòng)審計運行日志，了解系統運行狀態(tài)、進(jìn)行有效的錯誤處理；（運行可管理性與可維護性不同）
4、 與其他系統接口兼容性（解釋略）
5、 與網(wǎng)絡(luò )、硬件接口兼容性及性能（解釋略）
6、 系統安全性
隨著(zhù)計算機應用的不斷深入和擴大，涉及的部門(mén)和信息也越來(lái)越多，其中有大量保密信息在網(wǎng)絡(luò )上傳輸，所以對系統安全性的考慮已經(jīng)成為系統設計的關(guān)鍵，需要從各個(gè)方面和角度加以考慮，來(lái)保證數據資料的絕對安全。
7、 系統可靠性
系統的可靠性是現代信息系統應具有的重要特征，由于人們日常的工作對系統依賴(lài)程度越來(lái)越多，因此系統的必須可靠。系統構架設計可考慮系統的冗余度，盡可能地避免單點(diǎn)故障。系統可靠性是系統在給定的時(shí)間間隔及給定的環(huán)境條件下，按設計要求，成功地運行程序的概率。成功地運行不僅要保證系統能正確地運行，滿(mǎn)足功能需求，還要求當系統出現意外故障時(shí)能夠盡快恢復正常運行，數據不受破壞。
8、 業(yè)務(wù)流程的可調整性
應當考慮客戶(hù)業(yè)務(wù)流程可能出現的變化，所以在系統構架設計時(shí)要盡量排除業(yè)務(wù)流程的制約，即把流程中的各項業(yè)務(wù)結點(diǎn)工作作為獨立的對象，設計成獨立的模塊或組件，充分考慮他們與其他各種業(yè)務(wù)對象模塊或組件的接口，在流程之間通過(guò)業(yè)務(wù)對象模塊的相互調用實(shí)現各種業(yè)務(wù)，這樣，在業(yè)務(wù)流程發(fā)生有限的變化時(shí)（每個(gè)業(yè)務(wù)模塊本身的業(yè)務(wù)邏輯沒(méi)有變的情況下），就能夠比較方便地修改系統程序模塊或組件間的調用關(guān)系而實(shí)現新的需求。如果這種調用關(guān)系被設計成存儲在配置庫的數據字典里，則連程序代碼都不用修改，只需修改數據字典里的模塊或組件調用規則即可。
9、 業(yè)務(wù)信息的可調整性
應當考慮客戶(hù)業(yè)務(wù)信息可能出現的變化，所以在系統構架設計時(shí)必須盡可能減少因為業(yè)務(wù)信息的調整對于代碼模塊的影響范圍。
10、 使用方便性
使用方便性是不須提及的必然的需求，而使用方便性與系統構架是密切相關(guān)的。WinCE（1.0）的失敗和后來(lái)改進(jìn)版本的成功就說(shuō)明了這個(gè)問(wèn)題。WinCE（1.0）有太多層次的視窗和菜單，而用戶(hù)則更喜歡簡(jiǎn)單的界面和快捷的操作。失敗了應當及時(shí)糾正，但最好不要等到失敗了再來(lái)糾正，這樣會(huì )浪費巨大的財力物力，所以在系統構架階段最好能將需要考慮的因素都考慮到。當然使用方便性必須與系統安全性協(xié)調平衡統一，使用方便性也必須與業(yè)務(wù)流程的可調整性和業(yè)務(wù)信息的可調整性協(xié)調平衡統一。“滿(mǎn)足用戶(hù)的需求，便于用戶(hù)使用，同時(shí)又使得操作流程盡可能簡(jiǎn)單。這就是設計之本。”
11、構架樣式的一致性
軟件系統的構架樣式有些類(lèi)似于建筑樣式（如中國式、哥特式、希臘復古式）。軟件構架樣式可分為數據流構架樣式、調用返回構架樣式、獨立組件構架樣式、以數據為中心的構架樣式和虛擬機構架樣式，每一種樣式還可以分為若干子樣式。構架樣式的一致性并不是要求一個(gè)軟件系統只能采用一種樣式，就像建筑樣式可以是中西結合的，軟件系統也可以有異質(zhì)構架樣式（分為局部異質(zhì)、層次異質(zhì)、并行異質(zhì)），即多種樣式的綜合，但這樣的綜合應該考慮其某些方面的一致性和協(xié)調性。每一種樣式都有其使用的時(shí)機，應當根據系統最強調的質(zhì)量屬性來(lái)選擇。
四、源代碼的組織結構方面的考慮：
1、 開(kāi)發(fā)可管理性
便于人員分工（模塊獨立性、開(kāi)發(fā)工作的負載均衡、進(jìn)度安排優(yōu)化、預防人員流動(dòng)對開(kāi)發(fā)的影響：一個(gè)好的構架同時(shí)應有助于減少項目組的壓力和緊張，提高軟件開(kāi)發(fā)效率）、利于配置管理、大小的合理性、適度復雜性；
1）便于人員分工－模塊獨立性、層次性
模塊獨立性、層次性是為了保證項目開(kāi)發(fā)成員工作之間的相對獨立性，模塊聯(lián)結方式應該是縱向而不是橫向, 模塊之間應該是樹(shù)狀結構而不是網(wǎng)狀結構或交叉結構，這樣就可以把開(kāi)發(fā)人員之間的通信、模塊開(kāi)發(fā)制約關(guān)系減到最少。同時(shí)模塊獨立性也比較利于配置管理工作的進(jìn)行?，F在有越來(lái)越多的的軟件開(kāi)發(fā)是在異地進(jìn)行，一個(gè)開(kāi)發(fā)組的成員可能在不同城市甚至在不同國家，因此便于異地開(kāi)發(fā)的人員分工與配置管理的源代碼組織結構是非常必要的。
2）便于人員分工－開(kāi)發(fā)工作的負載均衡
不僅僅是開(kāi)發(fā)出來(lái)的軟件系統需要負載均衡，在開(kāi)發(fā)過(guò)程中開(kāi)發(fā)小組各成員之間工作任務(wù)的負載均衡也是非重要的。所謂工作任務(wù)的負載均衡就是通過(guò)合理的任務(wù)劃分按照開(kāi)發(fā)人員特點(diǎn)進(jìn)行分配任務(wù)，盡量讓項目組中的每個(gè)人每段時(shí)間都有用武之地。這就需要在構架設計時(shí)應當充分考慮項目組手頭的人力資源，在實(shí)現客戶(hù)需求的基礎上實(shí)現開(kāi)發(fā)工作的負載均衡，以提高整體開(kāi)發(fā)效率。
3）便于人員分工－進(jìn)度安排優(yōu)化；
進(jìn)度安排優(yōu)化的前提是模塊獨立性并搞清楚模塊開(kāi)發(fā)的先后制約關(guān)系。利用工作分解結構對所有程序編碼工作進(jìn)行分解，得到每一項工作的輸入、輸出、所需資源、持續時(shí)間、前期應完成的工作、完成后可以進(jìn)行的工作。然后預估各模塊需要時(shí)間，分析各模塊的并行與串行（順序制約），繪制出網(wǎng)絡(luò )圖，找出影響整體進(jìn)度的關(guān)鍵模塊，算出關(guān)鍵路徑，最后對網(wǎng)絡(luò )圖進(jìn)行調整，以使進(jìn)度安排最優(yōu)化。
有個(gè)家喻戶(hù)曉的智力題叫烤肉片策略：約翰遜家戶(hù)外有一個(gè)可以同時(shí)烤兩塊肉片的烤肉架，烤每塊肉片的每一面需要10分鐘，現要烤三塊肉片給饑腸轆轆急不可耐的一家三口。問(wèn)題是怎樣才能在最短的時(shí)間內烤完三片肉。一般的做法花20分鐘先烤完前兩片，再花20分鐘烤完第三片。有一種更好的方法可以節省10分鐘，大家想想。
4）便于人員分工－預防員工人員流動(dòng)對開(kāi)發(fā)的影響
人員流動(dòng)在軟件行業(yè)是司空見(jiàn)慣的事情，已經(jīng)是一個(gè)常見(jiàn)的風(fēng)險。作為對這一風(fēng)險的有效的防范對策之一，可以在構架設計中考慮到并預防員工人員流動(dòng)對開(kāi)發(fā)的影響。主要的思路還是在模塊的獨立性上（追求高內聚低耦合），組件化是目前流行的趨勢。
5）利于配置管理（獨立性、層次性）
利于配置管理與利于人員分工有一定的聯(lián)系。除了邏輯上的模塊組件要利于人員分工外，物理上的源代碼層次結構、目錄結構、各模塊所處源代碼文件的部署也應當利于人員分工和配置管理。（盡管現在配置管理工具有較強大的功能，但一個(gè)清楚的源碼分割和模塊分割是非常有好處的）。
6）大小的合理性與適度復雜性
大小的合理性與適度復雜性可以使開(kāi)發(fā)工作的負載均衡，便于進(jìn)度的安排，也可以使系統在運行時(shí)減少不必要的內存資源浪費。對于代碼的可閱讀性和系統的可維護性也有一定的好處。另外，過(guò)大的模塊常常是系統分解不充分，而過(guò)小的模塊有可能降低模塊的獨立性，造成系統接口的復雜。
2、 可維護性
便于在系統出現故障時(shí)及時(shí)方便地找到產(chǎn)生故障的原因和源代碼位置，并能方便地進(jìn)行局部修改、切割；（可維護性與運行可管理性不同）
3、 可擴充性：系統方案的升級、擴容、擴充性能
系統在建成后會(huì )有一段很長(cháng)的運行周期，在該周期內，應用在不斷增加，應用的層次在不斷升級，因此采用的構架設計等方案因充分考慮升級、擴容、擴充的可行性和便利
4、 可移植性
不同客戶(hù)端、應用服務(wù)器、數據庫管理系統：如果潛在的客戶(hù)使用的客戶(hù)端可能使用不同的操作系統或瀏覽器，其可移植性必須考慮客戶(hù)端程序的可移植性，或盡量不使業(yè)務(wù)邏輯放在客戶(hù)端；數據處理的業(yè)務(wù)邏輯放在數據庫管理系統中會(huì )有較好的性能，但如果客戶(hù)群中不能確定使用的是同一種數據庫管理系統，則業(yè)務(wù)邏輯就不能數據庫管理系統中；
達到可移植性一定要注重標準化和開(kāi)放性：只有廣泛采用遵循國際標準，開(kāi)發(fā)出開(kāi)放性強的產(chǎn)品，才可以保證各種類(lèi)型的系統的充分互聯(lián)，從而使產(chǎn)品更具有市場(chǎng)競爭力，也為未來(lái)的系統移植和升級擴展提供了基礎。
5、 需求的符合性
從源代碼的組織結構看需求的符合型主要考慮針對用戶(hù)需求可能的變化的軟件代碼及構架的最小冗余（同時(shí)又要使得系統具有一定的可擴展性）。
五、寫(xiě)系統構架設計文檔應考慮的問(wèn)題
構架工作應該在需求開(kāi)發(fā)完成約80％的時(shí)候開(kāi)始進(jìn)行，不必等到需求開(kāi)發(fā)全部完成，需要項目經(jīng)理以具體的判斷來(lái)評估此時(shí)是否足以開(kāi)始構建軟件構架。
給出一致的輪廓：系統概述。一個(gè)系統構架需要現有概括的描述，開(kāi)發(fā)人員才能從上千個(gè)細節甚至數十個(gè)模塊或對象類(lèi)中建立一致的輪廓。
構架的目標應該能夠清楚說(shuō)明系統概念，構架應盡可能簡(jiǎn)化，最好的構架文件應該簡(jiǎn)單、簡(jiǎn)短，清晰而不雜亂，解決方案自然。
構架應單先定義上層的主要子系統，應該描述各子系統的任務(wù)，并提供每個(gè)子系統中各模塊或對象類(lèi)的的初步列表。
構架應該描述不同子系統間相互通信的方式，而一個(gè)良好的構架應該將子系統間的通信關(guān)系降到最低。
成功構架的一個(gè)重要特色，在于標明最可能變更的領(lǐng)域，應當列出程序中最可能變更的部分，說(shuō)明構架的其他部分如何應變。
復用分析、外購：縮短軟件開(kāi)發(fā)周期、降低成本的有效方案未必是自行開(kāi)發(fā)軟件，可以對現有軟件進(jìn)行復用或進(jìn)行外購。應考慮其對構架的影響。
除了系統組織的問(wèn)題，構架應重點(diǎn)考慮對于細節全面影響的設計決策，深入這些決策領(lǐng)域：外部軟件接口（兼容性、通信方式、傳遞數據結構）、用戶(hù)接口（用戶(hù)接口和系統層次劃分）、數據庫組織和內容、非數據庫信息、關(guān)鍵算法、內存管理（配置策略）、并行性、安全性、可移植性、網(wǎng)絡(luò )多人操作、錯誤處理。
要保證需求的可追蹤性，即保證每個(gè)需求功能都有相應模塊去實(shí)現。
構架不能只依據靜態(tài)的系統目標來(lái)設計，也應當考慮動(dòng)態(tài)的開(kāi)發(fā)過(guò)程，如人力資源的情況，進(jìn)度要求的情況，開(kāi)發(fā)環(huán)境的滿(mǎn)足情況。構架必須支持階段性規劃，應該能夠提供階段性規劃中如何開(kāi)發(fā)與完成的方式。不應該依賴(lài)無(wú)法獨立運行的子系統構架。將系統各部分的、依賴(lài)關(guān)系找出來(lái)，形成一套開(kāi)發(fā)計劃。
六、結語(yǔ)
系統構架設計和千差萬(wàn)別的具體的開(kāi)發(fā)平臺密切相關(guān)，因此在此無(wú)法給出通用的解決方案，主要是為了說(shuō)明哪些因素是需要考慮的。對于每個(gè)因素的設計策略和本文未提到的因素需要軟件構架設計師在具體開(kāi)發(fā)實(shí)踐中靈活把握。不同因素之間有時(shí)是矛盾的，構架設計時(shí)需要根據具體情況進(jìn)行平衡。
參考文獻
《軟件構架實(shí)踐》SEI軟件工程譯叢，林·巴斯著(zhù)
《微軟項目：求生法則》Steve McConnell著(zhù)，余孟學(xué)譯
《實(shí)用軟件工程》第二版，鄭人杰、殷人昆、陶永雷等著(zhù)
《軟件工程：實(shí)踐者的研究方法》（第5版）Roger S.Pressman著(zhù)
《軟件開(kāi)發(fā)的科學(xué)與藝術(shù)》陳宏剛等著(zhù)
本文作者郵箱：luls@dragonsoft.com.cn或lulsnet@21cn.com
| 
