從實現(xiàn)角度看，軟件架構(gòu)可以分為邏輯架構(gòu)與物理架構(gòu)兩個緊密相關(guān)的視圖。軟件的邏輯架構(gòu)規(guī)定了軟件系統(tǒng)由哪些邏輯元素組成、以及這些邏輯元素之間的關(guān)系。軟件的物理架構(gòu)則關(guān)注“目標程序及其依賴的運行庫和系統(tǒng)軟件”最終如何安裝或部署到物理機器，以及如何部署機器和網(wǎng)絡來配合軟件系統(tǒng)的可靠性、可伸縮性等要求。以一個網(wǎng)絡管理系統(tǒng)(NMS)為例，在設計其架構(gòu)時，我們通常會首先想到將NMS在邏輯上分為5個功能模塊:故障管理、記賬管理、配置與命名管理、性能管理、安全管理。然后，可能會考慮采用Manager-Agent管理模型，以SNMP作為基本的通訊協(xié)議，以運行在局端的數(shù)據(jù)庫集中存儲MIB。Agent會用C語言實現(xiàn)，Manager采用C或者C++、Java實現(xiàn)，數(shù)據(jù)庫采用Oracle或者MySQL之類。應該說這樣的考慮在技術(shù)上未必有什么大的漏洞，但從架構(gòu)設計的角度來說，顯得過于簡單含混，沒有包含邏輯架構(gòu)與物理架構(gòu)的必要元素。如果將這樣的論述交給marketing對客戶做宣傳的話，也許是可以的，但還不足以在此基礎上進行深一步的開發(fā)，這也就是所謂的“高來高去”的系統(tǒng)架構(gòu)吧。
那么軟件的系統(tǒng)架構(gòu)設計應該達到怎樣的深度？
所謂架構(gòu)，終究是技術(shù)的概念。對于成熟的客戶而言，他們不會關(guān)心系統(tǒng)在技術(shù)上如何實現(xiàn)，而只注重系統(tǒng)能否滿足他們的需求。架構(gòu)本質(zhì)上只是實現(xiàn)需求的一個臺階。這個臺階能否跨越過去呢？老一輩計算機專家認為“程序=算法+數(shù)據(jù)結(jié)構(gòu)”，現(xiàn)代的專家們則認為只有算法和數(shù)據(jù)結(jié)構(gòu)還不夠，還需要設計方法、系統(tǒng)架構(gòu)、設計模式、環(huán)境和工具等等。思維與系統(tǒng)于是同時變得復雜起來，而復雜性通常導致更多問題的出現(xiàn)。就系統(tǒng)架構(gòu)而言，保持其簡單性是至關(guān)重要的。
系統(tǒng)架構(gòu)中包含了關(guān)于各元素應如何彼此相關(guān)的信息，架構(gòu)必須省略各元素中與交互無關(guān)的某些信息。因此，架構(gòu)首先是對系統(tǒng)的抽象，該抽象去除了不影響它們?nèi)绾问褂谩⑵渌厝绾问褂靡约叭绾闻c其他元素關(guān)聯(lián)或交互的細節(jié)。在幾乎所有的現(xiàn)代系統(tǒng)中，各元素都是通過接口實現(xiàn)交互的，而這些接口又將各元素的細節(jié)劃分為公有和私有兩大類。根據(jù)這種劃分，架構(gòu)屬于公有部分，而私有部分——即僅與內(nèi)部具體實現(xiàn)有關(guān)的細節(jié)——是不屬于架構(gòu)的。就此而言，架構(gòu)設計存在于各級系統(tǒng)、子系統(tǒng)的開發(fā)過程，無論系統(tǒng)的粒度多小。
邏輯架構(gòu)設計需要考慮職責劃分，體現(xiàn)為層、子系統(tǒng)、模塊等的劃分決定。從軟件開發(fā)生命周期看，軟件架構(gòu)設計屬于design范疇，邏輯架構(gòu)從靜態(tài)視角為詳細設計和編程實現(xiàn)提供切實的指導；有了分解就必然產(chǎn)生協(xié)作，邏輯架構(gòu)還需要定義不同邏輯單元之間的交互接口和交互機制，而編程工作必須實現(xiàn)這些接口和機制。物理架構(gòu)可以反映出軟件系統(tǒng)動態(tài)運行時的組織情況，并以進程、線程、以及作為類的運行時實例的對象等方式體現(xiàn)出來，而進程調(diào)度、線程同步、進程或線程通信等則進一步反映物理架構(gòu)的動態(tài)行為，數(shù)據(jù)的持久化、共享、傳輸則是反映了物理架構(gòu)的運作狀態(tài)。
由于用戶需求是復雜多樣的，軟件架構(gòu)也是一系列有層次性的決策是伴隨著對軟件系統(tǒng)的層層分解依次展開的。伴隨著對軟件系統(tǒng)的依次分解，軟件架構(gòu)師應當不斷做出決策，例如需要劃分成哪些模塊、每個模塊的職責為何、每個模塊的接口如何定義、模塊間采用何種交互機制、如何滿足約束和質(zhì)量屬性需求、如何適應可能發(fā)生的變化等等。 之后，軟件架構(gòu)師必須規(guī)劃整個系統(tǒng)的具體組成。通常，對于一個獨立的軟件系統(tǒng)而言，它常常被劃分為不同的子系統(tǒng)或分系統(tǒng)，每個部分承擔相對獨立的功能，各部分之間通過特定的交互機制進行協(xié)作。軟件架構(gòu)師決策制定的順序往往是先制定技術(shù)無關(guān)的決策、后制定技術(shù)相關(guān)的決策，后者在前者的指導下進行。
一項需求可能有多種方式實現(xiàn)，架構(gòu)設計師必須與系統(tǒng)分析員確定該需求將采用何種方式實現(xiàn)，將達到何種效果，以消除將需求映射為設計的歧義；討論過程中還可能會發(fā)現(xiàn)需求有不完備甚至錯誤的地方，在需求重新確定后設計者需修正設計。設計文檔必須寫清楚各個模塊/接口/公共對象的定義，列明程序的各種執(zhí)行條件與期望的運行效果，還要正確處理各種可能的異常。此外設計文檔應該遵循一定的寫作模式與版面風格，使用統(tǒng)一的術(shù)語或慣用語，使得開發(fā)團隊成員很容易理解其內(nèi)涵。當系統(tǒng)架構(gòu)設計不可能窮盡每一個細節(jié)，只要分析與即將開發(fā)的模塊相關(guān)的內(nèi)容即可。一項設計任務可能需要多個程序員完成。比如用戶界面一組程序員負責，而業(yè)務邏輯組件則由另一組負責，數(shù)據(jù)庫部分則又由其他開發(fā)人員負責。架構(gòu)設計師必須考慮他們的立場，以各方面都相對容易理解的方式寫清楚主要的模塊/接口/對象定義，明確相應的調(diào)用規(guī)則與主要邏輯處理。如果某項設計任務所涉及的內(nèi)容太專業(yè)化，架構(gòu)設計師并不熟悉相關(guān)的內(nèi)容，他也可以用描述性的文字說明該部分的設計要求，并與其他成員協(xié)作補充。
軟件架構(gòu)設計是一個動態(tài)的過程，但無論怎樣變化，需要時刻牢記架構(gòu)設計的目標:
1.最大化的重用
2.盡可能的簡單明了
3.最靈活的拓展性
本文來自: IT知道網(wǎng)(http://www.itwis.com) 詳細出處參考：http://www.itwis.com/html/software/ic/20080401/1178.html
