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