高級(jí)軟件架構(gòu)設(shè)計(jì)師實(shí)戰(zhàn)

1高級(jí)軟件架構(gòu)設(shè)計(jì)師實(shí)戰(zhàn)康凱軟件系統(tǒng)開(kāi)始?jí)乃赖牟“Y一個(gè)軟件系統(tǒng)開(kāi)始?jí)乃罆r(shí)表現(xiàn)的病癥有:硬化Rigidity——系統(tǒng)變得越來(lái)越難以變更,修復(fù)或增添新功能的代價(jià)高昂;脆弱Fragility——對(duì)系統(tǒng)的任何哪怕是微小的變更都可能造成四處(甚至是與變更處沒(méi)有邏輯上的關(guān)聯(lián)之處J崩潰;綁死Immobility——抽取系統(tǒng)的任何局部用來(lái)復(fù)用都非常困難;膠著Viscosity——以與原有設(shè)計(jì)保持一致的方式來(lái)對(duì)實(shí)施變更已經(jīng)非常困難,誘使開(kāi)發(fā)人員繞過(guò)它選擇容易但有害的途徑,其結(jié)果卻使系統(tǒng)死的更快。

什么是軟件架構(gòu)軟件架構(gòu)的概念很混亂。如果你問(wèn)五個(gè)不同的人，可能會(huì)得到五種不同的答案。軟件架構(gòu)概念主要分為兩大流派：組成派：軟件架構(gòu)=組件+交互。決策派：軟件架構(gòu)=重要決策集。組成派和決策派的概念相輔相成。軟件架構(gòu)要層次化并隔離關(guān)注點(diǎn)復(fù)雜性是層次化的。--《人月神話》好的架構(gòu)設(shè)計(jì)必須把變化點(diǎn)錯(cuò)落有致地封裝到軟件系統(tǒng)的不同局部(即關(guān)注點(diǎn)別離)。通過(guò)關(guān)注點(diǎn)別離，到達(dá)“系統(tǒng)中的一局部發(fā)生了變化，不會(huì)影響其他局部”的目標(biāo)。軟件單元的粒度：粒度最小的單元通常是“類”。幾個(gè)類緊密協(xié)作形成“模塊”。完成相對(duì)獨(dú)立的功能的多個(gè)模塊構(gòu)成了“子系統(tǒng)”。多個(gè)子系統(tǒng)相互配合才能滿足一個(gè)完整應(yīng)用的需求，從而構(gòu)成了軟件“系統(tǒng)”。一個(gè)大型企業(yè)往往使用多套系統(tǒng)，多套系統(tǒng)通過(guò)互操作形成“集成系統(tǒng)”。軟件單元的粒度是相對(duì)的。同一個(gè)軟件單元，在不同場(chǎng)景下我們會(huì)以不同的粒度看待它。架構(gòu)(Architecture)與框架(Framework)?？蚣苤皇且环N特殊的軟件，框架也有架構(gòu)?？梢酝ㄟ^(guò)架構(gòu)框架化到達(dá)“架構(gòu)重用”的目的，如很多人都在用Spring框架提供的控制反轉(zhuǎn)和依賴注入來(lái)構(gòu)建自己的架構(gòu)。軟件架構(gòu)的作用如果一個(gè)工程的系統(tǒng)架構(gòu)(包括理論根底)尚未確定，就不應(yīng)該進(jìn)行此系統(tǒng)的全面開(kāi)發(fā)。--BarryBoehm,《EngineeringContext》一個(gè)缺陷充滿的系統(tǒng)，將始終是一個(gè)缺陷充滿的系統(tǒng)。--TimothyC.Lethbridge,《面向?qū)ο筌浖こ獭奋浖軜?gòu)設(shè)計(jì)為什么這么難？因?yàn)樗强缭浆F(xiàn)實(shí)世界與計(jì)算機(jī)世界之間鴻溝的一座橋。軟件架構(gòu)設(shè)計(jì)要完成從面向業(yè)務(wù)到面向技術(shù)的轉(zhuǎn)換，在鴻溝上架起一座橋梁。需求->架構(gòu)設(shè)計(jì)->軟件架構(gòu)->系統(tǒng)開(kāi)發(fā)->軟件系統(tǒng)軟件架構(gòu)對(duì)新產(chǎn)品開(kāi)發(fā)的作用：上承業(yè)務(wù)目標(biāo)。下接技術(shù)決策。控制復(fù)雜性。先進(jìn)行架構(gòu)設(shè)計(jì)，后進(jìn)行詳細(xì)設(shè)計(jì)和編碼實(shí)現(xiàn)，符合“基于問(wèn)題深度分而治之”的理念。組織開(kāi)發(fā)。軟件架構(gòu)方案在小組中間扮演了“橋梁”和“合作契約”的作用。利于迭代開(kāi)發(fā)和增量交付。以架構(gòu)為中心進(jìn)行開(kāi)發(fā)，為增量交付提供了良好的根底。在架構(gòu)經(jīng)過(guò)驗(yàn)證之后，可以專注于功能的增量提交。提高質(zhì)量。軟件產(chǎn)品線：指具有一組可管理的、公共特性的、軟件密集性系統(tǒng)的集合，這些系統(tǒng)滿足特定的市場(chǎng)需求或任務(wù)需求，并且按照預(yù)定義方式從一個(gè)公共的核心資產(chǎn)集開(kāi)發(fā)得到。軟件產(chǎn)品線架構(gòu)：針對(duì)一個(gè)公司或組織內(nèi)的一系列產(chǎn)品而設(shè)計(jì)的通用架構(gòu)。軟件架構(gòu)對(duì)軟件產(chǎn)品線開(kāi)發(fā)的作用：固化核心知識(shí)；提供可重用資產(chǎn)；縮短推出產(chǎn)品的周期；降低開(kāi)發(fā)和維護(hù)本錢；提高產(chǎn)品質(zhì)量；支持批量定制；架構(gòu)師應(yīng)當(dāng)為工程相關(guān)的不同角色而設(shè)計(jì)：架構(gòu)師要為客戶負(fù)責(zé)，滿足他們的業(yè)務(wù)目標(biāo)和約束條件。架構(gòu)師要為用戶負(fù)責(zé)，滿足他們關(guān)心的功能需求和運(yùn)行期質(zhì)量屬性。架構(gòu)師必須顧及處于協(xié)作分工“下游”的開(kāi)發(fā)人員。架構(gòu)師必須考慮“周邊”的管理人員，為他們進(jìn)行分工管理、協(xié)調(diào)控制和評(píng)估監(jiān)控等工作提供清晰的根底。軟件架構(gòu)視圖——讓設(shè)計(jì)建模更明白、更有效張?jiān)瀑F2010-05-21“系統(tǒng)架構(gòu)圖”？架構(gòu)設(shè)計(jì)的多重視圖從根本上來(lái)說(shuō)是因?yàn)樾枨蠓N類的復(fù)雜性所致。比方一個(gè)媒體發(fā)布系統(tǒng)：功能需求：用戶可以通過(guò)瀏覽器瀏覽媒體的發(fā)布。據(jù)此初步設(shè)計(jì)出采用瀏覽器插件的方案；約束條件：不能影響用戶瀏覽器的平安性；細(xì)化設(shè)計(jì)方案，需要對(duì)插件進(jìn)行認(rèn)證，自動(dòng)判別客戶端是否存在，及版本比較；自動(dòng)下載注冊(cè)等。使用期質(zhì)量屬性：為保證瀏覽的流暢，應(yīng)減少中間等待的時(shí)間，因此應(yīng)對(duì)下一步需使用的媒體做預(yù)測(cè)等。制作發(fā)布期的質(zhì)量保證：保證在遇到較大的媒體時(shí)能保持瀏覽的流暢，應(yīng)在發(fā)布時(shí)將視頻等流式化。軟件系統(tǒng)的需求種類復(fù)雜什么是軟件架構(gòu)視圖個(gè)架構(gòu)視圖是對(duì)于從某一視角或某一點(diǎn)上看到的系統(tǒng)所做的簡(jiǎn)化描述，描述中涵蓋了系統(tǒng)的某一特定方面，而省略了于此方面無(wú)關(guān)的實(shí)體。架構(gòu)要涵蓋的內(nèi)容和決策太多了，超過(guò)了人腦“一蹴而就”的能力范圍，因此采用“分而治之”的方法從不同視角分別設(shè)計(jì)；同時(shí)，也為軟件架構(gòu)的理解、交流和歸檔提供了方便。多視圖方法是軟件架構(gòu)歸檔的方法，更是指導(dǎo)我們進(jìn)行架構(gòu)設(shè)計(jì)的思維方法。邏輯架構(gòu)邏輯架構(gòu)關(guān)注功能。其設(shè)計(jì)著重考慮功能需求。開(kāi)發(fā)架構(gòu)開(kāi)發(fā)架構(gòu)關(guān)注程序包。其設(shè)計(jì)著重考慮開(kāi)發(fā)期質(zhì)量屬性，如可擴(kuò)展性、可重用性、可移植性、易理解性和易測(cè)試性等。運(yùn)行架構(gòu)運(yùn)行架構(gòu)關(guān)注進(jìn)程、線程、對(duì)象等運(yùn)行時(shí)概念，以及相關(guān)的并發(fā)、同步、通信等問(wèn)題。其設(shè)計(jì)著重考慮運(yùn)行期質(zhì)量屬性，例如性能、可伸縮性、持續(xù)可用性和平安性等。物理架構(gòu)物理架構(gòu)關(guān)注軟件系統(tǒng)最終如何安裝或部署到物理機(jī)器。其設(shè)計(jì)著重考慮“安裝和部署需求”。以及如何部署機(jī)器和網(wǎng)絡(luò)來(lái)配合軟件系統(tǒng)的可靠性、可伸縮性等要求。數(shù)據(jù)架構(gòu)數(shù)據(jù)架構(gòu)關(guān)注持久化數(shù)據(jù)的存儲(chǔ)方案。設(shè)計(jì)著重考慮“數(shù)據(jù)需求”。關(guān)系邏輯視圖。邏輯視圖不僅關(guān)注用戶可見(jiàn)的功能，還包括為實(shí)現(xiàn)用戶功能而必須提供的“輔助功能模塊”；它們可能是邏輯層、功能模塊等。開(kāi)發(fā)視圖。開(kāi)發(fā)視圖關(guān)注程序包，不僅包括要編寫的源程序，還包括可以直接使用的第三方SDK和現(xiàn)成框架、類庫(kù)，以及開(kāi)發(fā)的系統(tǒng)將運(yùn)行于其上的系統(tǒng)軟件或中間件。開(kāi)發(fā)視圖和邏輯視圖之間可能存在一定的映射關(guān)系：比方邏輯層一般會(huì)映射到多個(gè)程序包等。運(yùn)行視圖。和開(kāi)發(fā)視圖的關(guān)系：開(kāi)發(fā)視圖一般偏重程序包在編譯時(shí)期的靜態(tài)依賴關(guān)系，而這些程序運(yùn)行起來(lái)之后會(huì)表現(xiàn)為對(duì)象、線程、進(jìn)程，運(yùn)行視圖比較關(guān)注的正是這些運(yùn)行時(shí)單元的交互問(wèn)題。物理視圖。和運(yùn)行視圖的關(guān)系：運(yùn)行視圖特別關(guān)注目標(biāo)程序的動(dòng)態(tài)執(zhí)行情況，而物理視圖重視目標(biāo)程序的靜態(tài)位置問(wèn)題；物理視圖是綜合考慮軟件系統(tǒng)和整個(gè)IT系統(tǒng)相互影響的架構(gòu)視圖。

軟件生命周期與軟件架構(gòu)介紹22軟件架構(gòu)師的定位系統(tǒng)架構(gòu)師的職責(zé)：一、理解系統(tǒng)的業(yè)務(wù)需求，制定系統(tǒng)的整體框架〔包括：技術(shù)框架和業(yè)務(wù)框架〕二、對(duì)系統(tǒng)框架相關(guān)技術(shù)和業(yè)務(wù)進(jìn)行培訓(xùn)，指導(dǎo)開(kāi)發(fā)人員開(kāi)發(fā)。并解決系統(tǒng)開(kāi)發(fā)、運(yùn)行中出現(xiàn)的各種問(wèn)題。系統(tǒng)架構(gòu)師的目的：對(duì)系統(tǒng)的重用、擴(kuò)展、平安、性能、伸縮性、簡(jiǎn)潔等做系統(tǒng)級(jí)的把握。系統(tǒng)架構(gòu)師能力要求：一、系統(tǒng)架構(gòu)相關(guān)的知識(shí)和經(jīng)驗(yàn)。二、很強(qiáng)的自學(xué)能力、分析能力、解決問(wèn)題的能力。三、寫作、溝通表達(dá)、培訓(xùn)。23角色軟件架構(gòu)師SoftwareArchitect定義主導(dǎo)系統(tǒng)全局分析設(shè)計(jì)和實(shí)施、負(fù)責(zé)軟件構(gòu)架和關(guān)鍵技術(shù)決策的角色24職責(zé)領(lǐng)導(dǎo)與協(xié)調(diào)整個(gè)工程中的技術(shù)活動(dòng)〔分析、設(shè)計(jì)和實(shí)施等〕推動(dòng)主要的技術(shù)決策，并最終表達(dá)為軟件構(gòu)架確定和文檔化系統(tǒng)的相對(duì)構(gòu)架而言意義重大的方面，包括系統(tǒng)的需求、設(shè)計(jì)、實(shí)施和部署等“視圖”確定設(shè)計(jì)元素的分組以及這些主要分組之間的接口為技術(shù)決策提供規(guī)那么，平衡各類涉眾的不同關(guān)注點(diǎn)，化解技術(shù)風(fēng)險(xiǎn)，并保證相關(guān)決定被有效的傳達(dá)和貫徹理解、評(píng)價(jià)并接收系統(tǒng)需求評(píng)價(jià)和確認(rèn)軟件架構(gòu)的實(shí)現(xiàn)25專業(yè)技能技術(shù)全面、成熟練達(dá)、洞察力強(qiáng)、經(jīng)驗(yàn)豐富，具備在缺乏完整信息、眾多問(wèn)題交織一團(tuán)、模糊和矛盾的情況下，迅速抓住問(wèn)題要害，并做出合理的關(guān)鍵決定的能力。具備戰(zhàn)略性和前瞻性思維能力，善于把握全局，能夠在更高抽象級(jí)別上進(jìn)行思考。對(duì)工程開(kāi)發(fā)涉及的所有問(wèn)題領(lǐng)域都有經(jīng)驗(yàn)，包括徹底地理解工程需求，開(kāi)展分析設(shè)計(jì)之類軟件工程活動(dòng)等。具備領(lǐng)導(dǎo)素質(zhì)，以在各小組之間推進(jìn)技術(shù)工作，并在工程壓力下做出牢靠的關(guān)鍵決策。擁有優(yōu)秀的溝通能力，用以進(jìn)行說(shuō)服、鼓勵(lì)和指導(dǎo)等活動(dòng)，并贏得工程成員的信任。26以目標(biāo)導(dǎo)向和主動(dòng)的方式來(lái)不帶任何感情色彩地關(guān)注工程結(jié)果，構(gòu)架師應(yīng)當(dāng)是工程背后的技術(shù)推動(dòng)力，而非設(shè)想者或夢(mèng)想家〔追求完美〕精通構(gòu)架設(shè)計(jì)的理論、實(shí)踐和工具，并掌握多種參考構(gòu)架、主要的可重用構(gòu)架機(jī)制和模式。具備系統(tǒng)設(shè)計(jì)員的所有技能，但涉及面更廣、抽象級(jí)別更高。27軟件架構(gòu)師的知識(shí)體系軟件架構(gòu)師作為整個(gè)軟件系統(tǒng)結(jié)構(gòu)的總設(shè)計(jì)師，其知識(shí)體系、技能和經(jīng)驗(yàn)決定了軟件系統(tǒng)的可靠性、平安性、可維護(hù)性、可擴(kuò)展性和可移植性等方面的性能。因此一個(gè)優(yōu)秀的軟件架構(gòu)師必須具備相當(dāng)豐富的知識(shí)、技能和經(jīng)驗(yàn)。通過(guò)比照軟件架構(gòu)師和系統(tǒng)分析師在軟件開(kāi)發(fā)中的職責(zé)和角色，不難發(fā)現(xiàn)軟件架構(gòu)師與系統(tǒng)分析師所必需的知識(shí)體系也是不盡相同的，系統(tǒng)分析師的主要職責(zé)是在需求分析、開(kāi)發(fā)管理、運(yùn)行維護(hù)等方面，而軟件架構(gòu)師的重點(diǎn)工作是在架構(gòu)與設(shè)計(jì)這兩個(gè)關(guān)鍵環(huán)節(jié)上。因此在系統(tǒng)分析師必須具備的知識(shí)體系中對(duì)系統(tǒng)的構(gòu)架與設(shè)計(jì)等方面知識(shí)體系的要求就相對(duì)低些；而軟件架構(gòu)師在需求分析、工程管理、運(yùn)行維護(hù)等方面知識(shí)的要求也就相對(duì)低些。28成為一名合格的軟件架構(gòu)師必須具備的知識(shí)信息系統(tǒng)綜合知識(shí)體系軟件架構(gòu)知識(shí)體系29？MFC，MSF，MOF，RUP，J2EE，Spring，SOA，JUnit，ORM，.NetMVC，UML，XML，Corba，MDA，MDD，Web-ServiceRSS，Web2.0，AJAX，Serverlet，HibernateIOC，AOPRubyOnRailsRupBPELWorkflowEngineLBSOracleCMMIMQ…30軟件架構(gòu)師在干什么？思考、思考、再思考深入理解、準(zhǔn)確把握建設(shè)的業(yè)務(wù)需求分析所有可見(jiàn)的問(wèn)題、障礙、風(fēng)險(xiǎn)充分參考已有的成功方案，降低風(fēng)險(xiǎn)交流、討論、博弈、質(zhì)疑對(duì)構(gòu)思中的方案不斷提出質(zhì)疑，防止漏洞廣泛聽(tīng)取各層面的意見(jiàn)，開(kāi)拓思路反復(fù)質(zhì)疑、逐步完善已有的設(shè)計(jì)構(gòu)思在動(dòng)手實(shí)現(xiàn)之前驗(yàn)證設(shè)計(jì)方案的正確性31軟件架構(gòu)師的知識(shí)結(jié)構(gòu)軟件知識(shí)最好要有系統(tǒng)開(kāi)發(fā)全過(guò)程經(jīng)驗(yàn)。對(duì)IT建設(shè)生命周期各個(gè)環(huán)節(jié)有深入了解，包括：系統(tǒng)/模塊邏輯設(shè)計(jì)、物理設(shè)計(jì)、代碼開(kāi)發(fā)、工程管理、測(cè)試、發(fā)布、運(yùn)行維護(hù)等。深入掌握1-2種主流技術(shù)平臺(tái)上開(kāi)發(fā)系統(tǒng)的方法。了解多種應(yīng)用系統(tǒng)的結(jié)構(gòu)。了解架構(gòu)設(shè)計(jì)領(lǐng)域的主要理論、流派、框架。32軟件架構(gòu)師的知識(shí)結(jié)構(gòu)業(yè)務(wù)知識(shí)深入了解系統(tǒng)建設(shè)的業(yè)務(wù)需求。了解系統(tǒng)的非功能需求和運(yùn)行維護(hù)需求。了解企業(yè)IT公共設(shè)施、網(wǎng)絡(luò)環(huán)境、外部系統(tǒng)。33軟件架構(gòu)師的思維方式基于框架的思維架構(gòu)設(shè)計(jì)的層次〔Enterprise，Application，etc〕IT的生命周期〔What，Why，Where，How，When，etc〕成功經(jīng)驗(yàn)以及方法論的指導(dǎo)合理把握技術(shù)細(xì)節(jié)把握各個(gè)層次應(yīng)有的內(nèi)容合理忽略不應(yīng)有的技術(shù)細(xì)節(jié)34軟件架構(gòu)師的思維方式風(fēng)險(xiǎn)管理意識(shí)采用成功經(jīng)驗(yàn)、防止不應(yīng)有的風(fēng)險(xiǎn)多方位的開(kāi)放思維多維度、多方向、包容性、防止排他性分析、質(zhì)疑、抽象、歸納沒(méi)有絕對(duì)好的架構(gòu)設(shè)計(jì)，只有相對(duì)優(yōu)秀的方案注意：并不存在通用的設(shè)計(jì)方法。我們認(rèn)為，給定的某種固定的方法總是會(huì)顧此失彼，而且這種不平衡性不太容易覺(jué)察。如果給定的某種方法所注重的方面與系統(tǒng)需求不吻合，那么這種方法就會(huì)將設(shè)計(jì)引入歧途。所以我們給出的是一些技巧，任何一次設(shè)計(jì)過(guò)程，都需要設(shè)計(jì)師仔細(xì)分析系統(tǒng)的需求和相關(guān)的約束條件，靈活運(yùn)用眾多的設(shè)計(jì)技巧，針對(duì)不同的設(shè)計(jì)方案進(jìn)行取舍，做出合理的決策。35為了有效地控制設(shè)計(jì)工作的復(fù)雜性，一般把設(shè)計(jì)活動(dòng)分為總體設(shè)計(jì)和詳細(xì)設(shè)計(jì)兩個(gè)層次。總體設(shè)計(jì)主要關(guān)注于體系結(jié)構(gòu)和接口這些全局性的內(nèi)容，而詳細(xì)設(shè)計(jì)主要關(guān)注于每個(gè)模塊內(nèi)部的數(shù)據(jù)結(jié)構(gòu)和算法。至于數(shù)據(jù)，那么在設(shè)計(jì)的各個(gè)層次都會(huì)涉及。軟件設(shè)計(jì)是一個(gè)迭代的過(guò)程，是一個(gè)逐步細(xì)化和求精的過(guò)程。因此，總體設(shè)計(jì)和詳細(xì)設(shè)計(jì)之間的劃分并不是絕對(duì)的。哪些是總體設(shè)計(jì)任務(wù)，哪些是詳細(xì)設(shè)計(jì)任務(wù)，取決于設(shè)計(jì)師對(duì)于整個(gè)工程的把握，并沒(méi)有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)。設(shè)計(jì)師在設(shè)計(jì)時(shí)實(shí)際是在做一系列的設(shè)計(jì)決策，來(lái)滿足系統(tǒng)的行為目標(biāo)，質(zhì)量目標(biāo)和開(kāi)發(fā)目標(biāo)。如果一個(gè)結(jié)構(gòu)對(duì)于完成這些目標(biāo)非常重要，那么它是構(gòu)架的一局部。相反，如果它可以留到以后再完善，那么它不是構(gòu)架的組成局部。因此，總的說(shuō)來(lái)，一個(gè)設(shè)計(jì)是不是屬于構(gòu)架設(shè)計(jì)，要看你當(dāng)前的設(shè)計(jì)目標(biāo)。36管理陷阱隨著管理性責(zé)任的增加，你所從事技術(shù)性工作的時(shí)間就會(huì)顯著減少。這樣，因?yàn)樵谕瓿杉夹g(shù)性任務(wù)和保持職業(yè)技能上花費(fèi)時(shí)間的減少，你可能會(huì)失去技術(shù)優(yōu)勢(shì)。軟件架構(gòu)師和管理者有很大的差異：軟件架構(gòu)師是直接的技術(shù)奉獻(xiàn)者；而管理者那么是通過(guò)協(xié)調(diào)其他人員的活動(dòng)來(lái)間接做出奉獻(xiàn)。他們往往一起協(xié)作，構(gòu)成高效的管理團(tuán)隊(duì)。以經(jīng)驗(yàn)看，把兩者結(jié)合起來(lái)卻不能長(zhǎng)久地工作。作為一名軟件架構(gòu)師，如果你已經(jīng)建立起個(gè)人的職業(yè)原那么的話，就有可能防止成為管理者。架構(gòu)和設(shè)計(jì)應(yīng)該做到何種程度38軟件架構(gòu)必須設(shè)計(jì)到“能為開(kāi)發(fā)人員提供足夠的指導(dǎo)和限制”的程度。分而治之的兩種方式分而治之的緣由：?jiǎn)栴}太復(fù)雜了，超出了人們能夠“一蹴而就”的范圍?！步涌诤蛯?shí)現(xiàn)別離〕一、先不把問(wèn)題研究得那么深，那么細(xì)，淺嘗輒止，見(jiàn)好就收。這種分而治之的方式稱為“按問(wèn)題深度分而治之”。二、先不研究整個(gè)問(wèn)題，而是研究問(wèn)題的一局部，分割問(wèn)題。這種分而治之的方式稱為“按問(wèn)題廣度分而治之”?！脖确秸宫F(xiàn)層、業(yè)務(wù)層和數(shù)據(jù)層的開(kāi)發(fā)〕39隨著軟件設(shè)計(jì)工作越來(lái)越復(fù)雜，將架構(gòu)設(shè)計(jì)和詳細(xì)設(shè)計(jì)別離已成為普遍的做法。將設(shè)計(jì)分為架構(gòu)設(shè)計(jì)和詳細(xì)設(shè)計(jì)，是對(duì)“按問(wèn)題深度分而治之”思想的運(yùn)用。所謂架構(gòu)設(shè)計(jì)，就是關(guān)于如何構(gòu)建軟件的一些最重要的設(shè)計(jì)決策;詳細(xì)設(shè)計(jì)針對(duì)每個(gè)局部的內(nèi)部進(jìn)行設(shè)計(jì)?？梢赃@么說(shuō)，軟件架構(gòu)設(shè)計(jì)應(yīng)當(dāng)解決的是全局性的、涉及不同“局部”之間交互的設(shè)計(jì)問(wèn)題，而不同“局部”的設(shè)計(jì)由后續(xù)的詳細(xì)設(shè)計(jì)負(fù)責(zé)。40面對(duì)“技術(shù)復(fù)雜性”和“管理復(fù)雜性”這樣的雙重困難，以架構(gòu)為中心的開(kāi)發(fā)方法是有效的途徑：一方面：“軟件系統(tǒng)的架構(gòu)涵蓋了整個(gè)系統(tǒng)，盡管架構(gòu)的有些局部可能只有‘一寸深’”。構(gòu)造一個(gè)具有一定抽象層次的解決方案，而不是將所有細(xì)節(jié)統(tǒng)統(tǒng)展開(kāi)，從而有效地控制了“技術(shù)復(fù)雜性”。沒(méi)有“把問(wèn)題研究那么深、那么細(xì)”，屬于“按問(wèn)題深度分而治之”41另一方面，因?yàn)椤凹軜?gòu)中包含了關(guān)于各元素應(yīng)如何彼此相關(guān)的信息”，從而可以把不同模塊分配給不同小組分頭開(kāi)發(fā)，而軟件架構(gòu)設(shè)計(jì)方案在這些小組中間扮演“橋梁”和“合作契約”的作用。每個(gè)小組的工作覆蓋了“整個(gè)問(wèn)題的一局部”，各小組之間可以互相獨(dú)立地進(jìn)行并行工作，這種“分割問(wèn)題，各個(gè)擊破”的策略，屬于“按問(wèn)題廣度分而治之”。這樣一來(lái)，模塊的技術(shù)細(xì)節(jié)被局部化到了小組內(nèi)部，內(nèi)部的細(xì)節(jié)不會(huì)成為小組間協(xié)作溝通的主要內(nèi)容，理順了溝通的層次。另外，對(duì)“人盡其才”也有好處，不同小組的成員需要精通的技術(shù)各不相同。例如，用戶界面層、數(shù)據(jù)管理層、系統(tǒng)交互層

。42架構(gòu)要進(jìn)行到什么程度軟件架構(gòu)是團(tuán)隊(duì)開(kāi)發(fā)的根底，應(yīng)明確規(guī)定后期分頭開(kāi)發(fā)所必須的公共設(shè)計(jì)約定，為分頭開(kāi)發(fā)提供足夠的指導(dǎo)和限制。另一方面，具體的架構(gòu)設(shè)計(jì)程度還會(huì)因軟件工程的不同而不同。架構(gòu)設(shè)計(jì)對(duì)軟件的不同局部的設(shè)計(jì)程度并不是整齊劃一的。(通信機(jī)制、持久化機(jī)制、消息機(jī)制等對(duì)應(yīng)的公共模塊；具體的業(yè)務(wù)功能模塊在架構(gòu)設(shè)計(jì)中往往設(shè)計(jì)程度不深?！硽w納：由于工程的不同、開(kāi)發(fā)團(tuán)隊(duì)情況的不同，軟件架構(gòu)的設(shè)計(jì)程度會(huì)有不同;軟件架構(gòu)應(yīng)當(dāng)為開(kāi)發(fā)人員提供足夠的指導(dǎo)和限制。43高來(lái)高去式架構(gòu)設(shè)計(jì)的病癥不能為開(kāi)發(fā)人員提供足夠的指導(dǎo)和限制的那種架構(gòu)設(shè)計(jì)方案。高來(lái)高去式架構(gòu)設(shè)計(jì)現(xiàn)象極為普遍，危害：缺少來(lái)自架構(gòu)的足夠的指導(dǎo)和限制，開(kāi)發(fā)人員在進(jìn)入分頭開(kāi)發(fā)階段之后會(huì)碰到很多問(wèn)題，并且容易造成管理混亂，溝通和協(xié)作效率低；對(duì)軟件質(zhì)量非常關(guān)鍵的全局性設(shè)計(jì)決定被拖延到分頭開(kāi)發(fā)期間草率決定；沒(méi)有完成化解重大技術(shù)風(fēng)險(xiǎn)的職責(zé)；團(tuán)隊(duì)成員對(duì)架構(gòu)師意見(jiàn)大，團(tuán)隊(duì)士氣受到打擊。44病癥一：缺失重要架構(gòu)視圖。給團(tuán)隊(duì)的不同角色提供指導(dǎo)。病癥二：架構(gòu)設(shè)計(jì)方案停留在概念性架構(gòu)的層面，全局性的設(shè)計(jì)決策最后由具體開(kāi)發(fā)人員從局部視角考慮并確定下來(lái)，造成技術(shù)和管理上的種種問(wèn)題。病癥三：名不副實(shí)的分層架構(gòu)。對(duì)各層之間交互接口和交互機(jī)制的設(shè)計(jì)嚴(yán)重缺乏。45架構(gòu)設(shè)計(jì)過(guò)程重型和輕型方法重型方法：偏重于方案、過(guò)程和中間產(chǎn)物敏捷方法：更加看重人和溝通。人和溝通永遠(yuǎn)是第一位的，而方案、過(guò)程和中間產(chǎn)物，只是保證溝通、實(shí)現(xiàn)目標(biāo)的手段。并非方案、過(guò)程、中間產(chǎn)物不重要，但不能本末倒置。評(píng)判軟件成功的標(biāo)準(zhǔn)：很多。對(duì)敏捷方法：首先在于交付可用的軟件。為了保證軟件的可用性，需求是根本。對(duì)于架構(gòu)設(shè)計(jì)工作，從需求出發(fā)來(lái)設(shè)計(jì)架構(gòu)，是保證軟件可用性的根本的保證。

如何開(kāi)始架構(gòu)設(shè)計(jì)工作考慮的平臺(tái)、語(yǔ)言、開(kāi)發(fā)環(huán)境、數(shù)據(jù)庫(kù)等誤區(qū)：架構(gòu)設(shè)計(jì)就是寫一些空話，套話。誤區(qū)：對(duì)與客戶具體情況密切相關(guān)的問(wèn)題卻未系統(tǒng)考慮。IT界的技術(shù)層出不窮，面對(duì)著如此之多的技術(shù)、平臺(tái)、框架、函數(shù)庫(kù)，我們?nèi)绾芜x擇一組適合軟件的技術(shù)？要針對(duì)需求設(shè)計(jì)架構(gòu)。每個(gè)客戶都有自身特點(diǎn)，如何才能夠設(shè)計(jì)出符合客戶利益的架構(gòu)？軟件中往往都充滿著眾多的問(wèn)題，在一開(kāi)始就把所有的問(wèn)題都想清楚往往很難做到，但是如果不解決問(wèn)題，風(fēng)險(xiǎn)又居高不下。架構(gòu)設(shè)計(jì)就是鋪設(shè)軟件的主管道。根據(jù)什么來(lái)制定主管道的粗細(xì)、路徑等因素？是根據(jù)城市的人口、地理位置、水源等因素。對(duì)應(yīng)到軟件設(shè)計(jì)，城市的各因素就是軟件中的各種需求：功能需求、非功能需求、變化案例等。例：城市中自來(lái)水管的架設(shè)是一項(xiàng)非常的復(fù)雜的工程。為了需要滿足每家每戶的需要，自來(lái)水管組成了一個(gè)龐大的網(wǎng)絡(luò)。在這樣一個(gè)復(fù)雜的網(wǎng)絡(luò)中，如何完成鋪設(shè)的任務(wù)呢。一般的做法是，先找出問(wèn)題的根源，也就是水的源頭。從水源鋪設(shè)一條管道通至城市，然后根據(jù)城市的區(qū)域劃分，設(shè)計(jì)出主管道，剩下的就是使用的問(wèn)題了，每家每戶的管道最終都是連到主管道上的。因此，雖然自來(lái)水網(wǎng)絡(luò)龐大復(fù)雜。但是真正的主管道是比較簡(jiǎn)單的。一般來(lái)說(shuō)，功能需求決定業(yè)務(wù)架構(gòu)、非功能需求決定技術(shù)架構(gòu)，變化案例決定架構(gòu)的范圍。功能需求決定軟件能夠做些什么。我們需要根據(jù)業(yè)務(wù)上的需求來(lái)設(shè)計(jì)業(yè)務(wù)架構(gòu)，以使得未來(lái)的軟件能夠滿足客戶的需要。非功能需求定義了性能、效率上的一些約束、規(guī)那么。而我們的技術(shù)架構(gòu)要能夠滿足這些約束和規(guī)那么。變化案例是對(duì)未來(lái)可能發(fā)生的變化的一個(gè)估計(jì)，結(jié)合功能需求和非功能需求，我們就可以確定一個(gè)需求的范圍，進(jìn)而確定一個(gè)架構(gòu)的范圍。例：一個(gè)字處理軟件，功能需求可以簡(jiǎn)單概括為格式化用戶輸入的文字，非功能需求可能是格式化大小為1000K的一段文字的處理速度不能低于10S，變化案例可能是推出多種語(yǔ)言版本。那么在設(shè)計(jì)業(yè)務(wù)架構(gòu)時(shí)，我們會(huì)集中于如何表示文字、圖象、媒體等要素，此外需要有另外的技術(shù)架構(gòu)來(lái)處理速度問(wèn)題，比方緩沖技術(shù)，對(duì)于變化案例，我們也要考慮相應(yīng)的架構(gòu)，比方把字體獨(dú)立于程序包的設(shè)計(jì)。架構(gòu)設(shè)計(jì)的兩項(xiàng)工作分析：分析是分析需求設(shè)計(jì)：設(shè)計(jì)軟件的大致結(jié)構(gòu)。很多方法論別離二者，其實(shí)無(wú)一定的界限，做分析的時(shí)候會(huì)想到如何設(shè)計(jì)，而思考如何設(shè)計(jì)反過(guò)來(lái)又會(huì)影響分析的效果?？梢哉f(shuō)，兩者間是相互聯(lián)系和不斷迭代的。需求與架構(gòu)都應(yīng)迭代進(jìn)行一點(diǎn)一點(diǎn)的作需求。這種做法在那些需求變化快的工程中尤其適用。由于我們采用的流程是一種迭代式的流程，這里我們將會(huì)面臨著如何對(duì)待上一次迭代的中間產(chǎn)物的問(wèn)題。如果我們每一次迭代都需要修改已存在的中間產(chǎn)物，那么這種維護(hù)的本錢未免過(guò)大。因此，敏捷方法論的根本做法是，扔掉那些已經(jīng)沒(méi)有用處的中間產(chǎn)物。軟件要比文檔重要。生成中間產(chǎn)物的目的都是為了生成最終的程序，對(duì)于這些已經(jīng)完成作用的模型，沒(méi)有必要付出額外的維護(hù)本錢。架構(gòu)設(shè)計(jì)中的一些提示〔也是拋棄模型的必要條件〕：簡(jiǎn)單化：簡(jiǎn)單的模型和簡(jiǎn)單的程序。模型和程序越復(fù)雜，就需要更多的精力來(lái)處理它們。因此盡可能簡(jiǎn)化它們，為的是更容易的處理它們。高效溝通渠道：通過(guò)增強(qiáng)溝通的效果來(lái)減少對(duì)中間產(chǎn)物的需要。試想假設(shè)隨時(shí)能從客戶處得到需求的細(xì)節(jié)資料，那么前期需求調(diào)研就沒(méi)有必要做得太細(xì)。角色交叉輪換：開(kāi)發(fā)人員間建立起交換角色的機(jī)制，能夠盡量的防止各子系統(tǒng)諸侯割據(jù)的局面。清晰的流程：或明確的過(guò)程。過(guò)程在方法論中是重點(diǎn)，敏捷方法論也不例外。開(kāi)發(fā)人員能夠清楚的知道，今天做什么，明天做什么。過(guò)程不是給別人看的，而是給自己用的。工具：好用的工具能夠節(jié)省大量的時(shí)間，工具并不僅指CASE工具，還包括版本控制工具、自動(dòng)測(cè)試工具、畫圖工具、文檔制作和管理工具。使用工具要注意本錢和效益的問(wèn)題。標(biāo)準(zhǔn)和風(fēng)格：語(yǔ)言標(biāo)準(zhǔn)不同是溝通的很大障礙。語(yǔ)言從某個(gè)角度來(lái)看屬于一種標(biāo)準(zhǔn)、一種風(fēng)格。因此，一個(gè)團(tuán)隊(duì)如果采用同樣的編碼標(biāo)準(zhǔn)、文檔標(biāo)準(zhǔn)、注釋風(fēng)格、制圖風(fēng)格，那么這個(gè)團(tuán)隊(duì)的溝通效率一定非常高。

如果上述的環(huán)境都不具備，或是欠缺好幾項(xiàng)，那你的文檔的模型還是留著的好。

僅針對(duì)需求設(shè)計(jì)架構(gòu)不要做未來(lái)才有用的事情。有時(shí)我們會(huì)把架構(gòu)考慮得非常復(fù)雜，主要原因是把很多未來(lái)的因素放入到現(xiàn)在來(lái)考慮?；蛟陂_(kāi)發(fā)第一個(gè)產(chǎn)品的時(shí)候就試圖做成完美的框架。以上的這兩種思路有沒(méi)有錯(cuò)呢？沒(méi)有錯(cuò)，這只是如何看待投入的問(wèn)題，有人希望開(kāi)始的時(shí)候多投入一些，這樣后續(xù)的投入就會(huì)節(jié)省下來(lái)。但在現(xiàn)實(shí)中，由于需求的不確定性，希望通過(guò)增加開(kāi)始階段的投入來(lái)將降低未來(lái)的投入往往是難以做到的，框架的設(shè)計(jì)也絕非一蹴而就的，因此這種做法并不好。同其它很多事物一樣，架構(gòu)設(shè)計(jì)應(yīng)保持簡(jiǎn)單性和迭代過(guò)程！引入模式模式幫助我們抓住重點(diǎn)。為了解決設(shè)計(jì)文檔編輯器引出的七個(gè)問(wèn)題，一共使用了8種不同的模式。這8種模式的組合其實(shí)就是架構(gòu)，因?yàn)樗鼈兘鉀Q的，都是系統(tǒng)中最高層的問(wèn)題。架構(gòu)也是存在模式的。比方，對(duì)于系統(tǒng)結(jié)構(gòu)設(shè)計(jì)，我們使用層模式；對(duì)于分布式系統(tǒng)，我們使用代理模式；對(duì)于交互系統(tǒng)，我們使用MVC〔模型-視圖-控制器〕模式。模式本來(lái)就是針對(duì)特定問(wèn)題的解，因此，針對(duì)需求的特點(diǎn)，我們也可以采用相應(yīng)的模式來(lái)設(shè)計(jì)架構(gòu)。

PetShot案例在MVC圖背后隱藏著的需求：系統(tǒng)需要支持多種用戶界面，包括為普通用戶提供的HTML界面，為無(wú)線用戶提供的WML界面，為管理員提供的Swing界面，以及為B2B業(yè)務(wù)設(shè)計(jì)的WebService界面。這是系統(tǒng)最重要的需求，因此，系統(tǒng)的設(shè)計(jì)者就需要確定一個(gè)穩(wěn)定的架構(gòu)，以解決多界面的問(wèn)題。相對(duì)于多界面的問(wèn)題，后端的業(yè)務(wù)處理邏輯都是一致的。比方HTML界面和WML界面的功能并沒(méi)有太大的差異。把處理邏輯和界面別離開(kāi)來(lái)還有額外的好處，可以在添加功能的同時(shí)，不涉及界面的改動(dòng)，反之亦然。〔耦合度的問(wèn)題〕。

MVC模式正可以適用于解決該問(wèn)題。系統(tǒng)使用控制器來(lái)為業(yè)務(wù)邏輯選擇不同的界面，這就完成了MVC架構(gòu)的設(shè)計(jì)思路。在架構(gòu)設(shè)計(jì)的工作中，我們手頭上有模式這樣一張好牌，有什么理由不去使用它呢？抓住重點(diǎn)架構(gòu)是一種抽象，即架構(gòu)設(shè)計(jì)摒棄了具體的細(xì)節(jié)，僅僅抓住軟件最高層的概念，也就是最上層、優(yōu)先級(jí)最高、風(fēng)險(xiǎn)最大的那局部需求。考慮、分析、解決一個(gè)問(wèn)題，一定有一個(gè)漸進(jìn)的過(guò)程。架構(gòu)設(shè)計(jì)就是解決問(wèn)題其中比較早期的一個(gè)階段，我們不會(huì)在架構(gòu)設(shè)計(jì)這個(gè)階段投入過(guò)多的時(shí)間，因此關(guān)鍵點(diǎn)在于我們要能夠在架構(gòu)設(shè)計(jì)中把握住需求的重點(diǎn)。比方，分布式系統(tǒng)和交互系統(tǒng)，分布和交互就是這兩個(gè)系統(tǒng)的重點(diǎn)。那么，如果說(shuō)我們面對(duì)的是一個(gè)分布式的交互系統(tǒng)，那么，我們就需要把這兩種特性做為重點(diǎn)來(lái)考慮，并以此為根底，設(shè)計(jì)架構(gòu)。而寵物商店的范例也是類似的，除了MVC的架構(gòu)，還有很多的設(shè)計(jì)問(wèn)題需要解決，例如用于數(shù)據(jù)庫(kù)訪問(wèn)的數(shù)據(jù)對(duì)象，用于視圖管理的前端控制器等。但是這些相對(duì)于MVC模式來(lái)說(shuō)，屬于局部的，優(yōu)先級(jí)較低的局部，可以在架構(gòu)確定后再來(lái)設(shè)計(jì)。架構(gòu)設(shè)計(jì)和領(lǐng)域?qū)＜乙粋€(gè)架構(gòu)要設(shè)計(jì)的好，和對(duì)需求的理解是分不開(kāi)的。因此在現(xiàn)實(shí)中，業(yè)務(wù)領(lǐng)域?qū)＜覒{借著他對(duì)業(yè)務(wù)領(lǐng)域的了解，能夠幫助開(kāi)發(fā)人員設(shè)計(jì)出優(yōu)秀的架構(gòu)來(lái)。架構(gòu)是需要抽象的，它是現(xiàn)實(shí)社會(huì)活動(dòng)的一個(gè)根本模型，而業(yè)務(wù)領(lǐng)域的模型僅僅憑開(kāi)發(fā)人員是很難設(shè)計(jì)出來(lái)的。在ERP的開(kāi)展史上，MRP開(kāi)展為MRPII，再開(kāi)展到閉環(huán)MRP，直到開(kāi)展成為現(xiàn)在的ERP，主要的因素是管理思想的演化，也就是說(shuō)，對(duì)業(yè)務(wù)領(lǐng)域的理解進(jìn)步了，架構(gòu)才有可能進(jìn)步。因此，敏捷型架構(gòu)設(shè)計(jì)的過(guò)程中，我們也非常強(qiáng)調(diào)領(lǐng)域?qū)＜业淖饔?。軟件約束條件與架構(gòu)的影響資金時(shí)間業(yè)務(wù)運(yùn)行環(huán)境開(kāi)發(fā)團(tuán)隊(duì)實(shí)現(xiàn)技術(shù)等63領(lǐng)域模型設(shè)計(jì)領(lǐng)域模型〔DomainModel〕商業(yè)建模范疇的概念：同行業(yè)企業(yè)的業(yè)務(wù)模型必定有很大的共性和內(nèi)在的規(guī)律性，由這個(gè)行業(yè)內(nèi)的各個(gè)企業(yè)的業(yè)務(wù)模型再向上抽象出來(lái)整個(gè)行業(yè)的業(yè)務(wù)模型，即領(lǐng)域模型。技術(shù)建模范疇的概念：用編程語(yǔ)言來(lái)實(shí)現(xiàn)商業(yè)領(lǐng)域模型。關(guān)系：對(duì)行業(yè)經(jīng)驗(yàn)積累缺乏的軟件公司，開(kāi)發(fā)軟件由需求驅(qū)動(dòng)，而非商業(yè)的領(lǐng)域模型驅(qū)動(dòng)。商業(yè)領(lǐng)域模型與編程語(yǔ)言的不是一對(duì)一的對(duì)應(yīng)關(guān)系。例如用EJB2模型，需要最少兩個(gè)以上的EJB，即一個(gè)SessionBean，處理面向流程的控制邏輯，一個(gè)EntityBean，處理面向持久化的實(shí)體邏輯〔持久化操作附著在EntityBean的Home接口上〕。如果是更加復(fù)雜的領(lǐng)域模型，那么需要更多的EJB，一般一個(gè)領(lǐng)域模型需要多個(gè)EntityBean和多個(gè)SessionBean。使用基于POJO模型的實(shí)現(xiàn)，那么粗顆粒度的EJB要繼續(xù)細(xì)分：一個(gè)EntityBean對(duì)應(yīng)三個(gè)以上POJO：一個(gè)或者多個(gè)實(shí)體類，DAO接口、DAO接口實(shí)現(xiàn)類；一個(gè)SessionBean要切分為多個(gè)業(yè)務(wù)Bean。6465層次結(jié)構(gòu)領(lǐng)域模型從EJB到輕量級(jí)框架66層次結(jié)構(gòu)表現(xiàn)層〔present〕業(yè)務(wù)層業(yè)務(wù)層外觀業(yè)務(wù)效勞層領(lǐng)域?qū)ο蠊芾?效勞/倉(cāng)庫(kù)層領(lǐng)域?qū)ο髮映志脤訑?shù)據(jù)訪問(wèn)層數(shù)據(jù)庫(kù)67領(lǐng)域模型中的各種角色：實(shí)體--有唯一的標(biāo)識(shí),并且要有屬性和行為(非GET/SET)，添加了行為，使其具有生命力。往往在設(shè)計(jì)時(shí)，實(shí)體的形為最難決斷。為確定行為，我們必須識(shí)別它們的責(zé)任和協(xié)作。類的責(zé)任是指該類要做、知道、或決定的一切，由一個(gè)或多個(gè)方法完成。類中有屬性和關(guān)聯(lián)，協(xié)作就是為完成自己的責(zé)任所調(diào)用其它關(guān)聯(lián)類。值對(duì)象--沒(méi)有標(biāo)識(shí)沒(méi)有行為。如Address類。工廠---定義創(chuàng)立實(shí)體的方法，封裝實(shí)例化對(duì)象并將一些關(guān)聯(lián)對(duì)象注入。倉(cāng)庫(kù)(repository)管理實(shí)體的集合,主要有查找和刪除實(shí)體的方法.實(shí)現(xiàn)類可以調(diào)用執(zhí)久化層(如Hibernate，Ibatis)效勞(Service)，實(shí)現(xiàn)整個(gè)應(yīng)用程序的工作流(workflow)。效勞包含那些無(wú)法指派的單個(gè)實(shí)體的行為，由作用于多個(gè)對(duì)象方法組成。如可以調(diào)用repository查找到實(shí)體對(duì)象，然后委派給這些對(duì)象。效勞和facade很像，但不一樣，它不處理以下事情：1〕執(zhí)行事務(wù)。2〕收集返回給表現(xiàn)層的數(shù)據(jù)。3〕脫鉤對(duì)象。4〕其它事情。效勞可以說(shuō)是業(yè)務(wù)的協(xié)調(diào)者，業(yè)務(wù)邏輯可以分散到實(shí)體對(duì)象中。682、層次之間的交互A、頁(yè)面提交表單數(shù)據(jù)到Action，Action創(chuàng)立DTO對(duì)象并設(shè)置相應(yīng)屬性值為表單數(shù)據(jù)B、Action傳遞DTO對(duì)象給FacadeC、Facade中套用ServiceTemplate事務(wù)模板以參加事務(wù)管理，在ServiceTemplate中根據(jù)具體業(yè)務(wù)調(diào)用Factory或Reposistory，分別create或者load出DomainModel對(duì)象D、Facade傳遞DomainModel對(duì)象給ServiceE、Service執(zhí)行具體業(yè)務(wù)邏輯〔調(diào)用DomainModel對(duì)象相應(yīng)的業(yè)務(wù)方法〕F、Service調(diào)用Reposistory對(duì)狀態(tài)已改變的DomainModel對(duì)象進(jìn)行持久化操作〔調(diào)用相應(yīng)DAO〕69注：在Facade或Service中如果需要查詢DomainModel對(duì)象中的屬性值，調(diào)用DomainModel對(duì)象的getDataInfo()方法得到DataInfo對(duì)象，通過(guò)DataInfo對(duì)象查詢所需數(shù)據(jù)，包括Service返回給Fa?ade業(yè)務(wù)處理結(jié)果中所包含的業(yè)務(wù)數(shù)據(jù)。7071領(lǐng)域模型失血模型貧血模型充血模型脹血模型72失血模型DO只有屬性及其getter/setter方法，沒(méi)有任何業(yè)務(wù)邏輯。缺點(diǎn)：行為與數(shù)據(jù)別離，很多情況導(dǎo)致維護(hù)與理解困難。73貧血模型DO包含不依賴于持久化的領(lǐng)域邏輯；依賴持久化的領(lǐng)域邏輯歸入Service層。Service(業(yè)務(wù)邏輯，事務(wù)封裝)DAODO優(yōu)點(diǎn)：各層單向依賴，結(jié)構(gòu)清楚，易于實(shí)現(xiàn)和維護(hù)。設(shè)計(jì)簡(jiǎn)單易行，底層模型非常穩(wěn)定。缺點(diǎn)：DO局部的持久化邏輯被放入Service層，不夠OO。Service層過(guò)重。74充血模型與貧血模型類似，不同處在于如何劃分業(yè)務(wù)邏輯：絕大多業(yè)務(wù)邏輯都應(yīng)該放在DO里(包括持久化邏輯)，而Service層很薄，僅僅封裝事務(wù)和少量邏輯，不和DAO層打交道。Service(事務(wù)封裝)DODAO優(yōu)點(diǎn)：符合OOService層很薄，只充當(dāng)Facade的角色，不和DAO打交道。75缺點(diǎn)：DAO和DO雙向依賴。如何劃分Service層邏輯和Domain層邏輯沒(méi)有確定的規(guī)那么，取決與設(shè)計(jì)人員自己的理解。Service層封裝事務(wù)，須對(duì)所有的DO邏輯提供相應(yīng)的事務(wù)封裝方法，造成重定義所有的Domainlogic。Service的事務(wù)化封裝的意義等于把OO的Domainlogic轉(zhuǎn)換為過(guò)程的Service事務(wù)腳本。充血模型在domain層實(shí)現(xiàn)的OO在Service層又變成了面向過(guò)程。76脹血模型取消Service層，只剩下DO和DAO層，在DO的domainlogic上面封裝事務(wù)。DO(事務(wù)封裝，業(yè)務(wù)邏輯)DAO(RoR甚至合并為一層〕

優(yōu)點(diǎn)：分層簡(jiǎn)化符合OO缺點(diǎn)：service邏輯也強(qiáng)行放入DO，引起了DO不穩(wěn)定。DO暴露給web層過(guò)多的信息，可能引起不必要的耦合。77原那么：業(yè)務(wù)對(duì)象封裝了內(nèi)在的業(yè)務(wù)邏輯，而應(yīng)用效勞封裝了外在于業(yè)務(wù)對(duì)象的業(yè)務(wù)邏輯。78EJB到輕量級(jí)框架EJBPOJO〔業(yè)務(wù)邏輯〕+輕量級(jí)框架〔[Hibernate、JDO、iBATIS]〔持久化〕、Spring〔事務(wù)管理、平安〕〕79EJBEJB：編寫分布式業(yè)務(wù)應(yīng)用程序的Java標(biāo)準(zhǔn)架構(gòu)。提供大量效勞：聲明型事務(wù),EIB容器自動(dòng)啟動(dòng)、提交和回滾事務(wù)。業(yè)務(wù)邏輯能參與由遠(yuǎn)程客戶發(fā)起的分布式事務(wù)。提供聲明型平安，大局部情況下不再搖要編寫平安代碼求〔bean部署描述符里的條目指定準(zhǔn)可以防問(wèn)某個(gè)具體bean〕。80例：在兩個(gè)賬號(hào)間進(jìn)行轉(zhuǎn)賬的效勞。8182新設(shè)計(jì)是面向?qū)ο蟆⒒赑OJO,而非基于EJB的過(guò)程式。它使用構(gòu)建在JDBC上的持久層框架來(lái)訪問(wèn)數(shù)據(jù)庫(kù),并不直接使用JDBC。業(yè)務(wù)邏輯由POJOfacade而非會(huì)話bean進(jìn)行封裝。事務(wù)由Spring框架而非EJB容器進(jìn)行管理。業(yè)務(wù)邏輯向表現(xiàn)層返回實(shí)際的業(yè)務(wù)對(duì)象,而不是DTO。應(yīng)用程序通過(guò)將組件的依賴作為setter或構(gòu)造子參數(shù)傳入來(lái)進(jìn)行組裝,而不是之前采用Java命名和目錄接口(JNDI)查詢的組件。由于該設(shè)計(jì)面向?qū)ο?并采用上述輕量級(jí)技術(shù),因此較之前看到的EJB版本對(duì)開(kāi)發(fā)人員要友好。83基于輕量級(jí)框架設(shè)計(jì)的好處是，它提供事務(wù)和持久化時(shí)并不要求應(yīng)用程序類實(shí)現(xiàn)任何特殊接口。甚至當(dāng)應(yīng)用程序的類需要運(yùn)行在事務(wù)里或是持久的時(shí)候，它們?nèi)允荘OJO，設(shè)計(jì)者可以繼續(xù)享受POJO的種種好處。8485面向?qū)ο蟮膬?yōu)點(diǎn)：整個(gè)設(shè)計(jì)更易理解和維護(hù)。它并不是一個(gè)無(wú)所不能的大型類,而是由大量小類組成,每個(gè)類只共有假設(shè)干職責(zé)。此外,諸如Account、BankingTransaction和OverdraftPolicy類都與現(xiàn)實(shí)世界的概念對(duì)應(yīng),因此易于理解。其次,面向?qū)ο笤O(shè)汁也更易測(cè)試:所有類都能并且應(yīng)當(dāng)進(jìn)行獨(dú)立的測(cè)試。EJB只能通過(guò)調(diào)用它的public方法如Transter進(jìn)行測(cè)試,難度大。(只能測(cè)試p-blic方法暴露的復(fù)雜功能,無(wú)法測(cè)試其中簡(jiǎn)單的局部〕。面向?qū)ο笙笤O(shè)計(jì)更易擴(kuò)展,它可使用設(shè)計(jì)模式，如Stategy和Template等。EJB風(fēng)格的過(guò)程式設(shè)計(jì)往往需耍修改核心代碼。86不適合用面向?qū)ο蟮膱?chǎng)合：大量數(shù)據(jù)集合的關(guān)系操作。以數(shù)據(jù)庫(kù)為中心的管理程序：這個(gè)領(lǐng)域所對(duì)應(yīng)的現(xiàn)實(shí)世界是一個(gè)面向關(guān)系的世界，表與表的關(guān)聯(lián)表達(dá)的是彼此的業(yè)務(wù)關(guān)系。復(fù)雜的SQL固然不好維護(hù)，但業(yè)務(wù)真是復(fù)雜到簡(jiǎn)單的SQL都難以描述的程度，采用面向?qū)ο竺枋瞿敲锤永щy，維護(hù)也更困難，同時(shí)還損失了效率。比較大的事務(wù)。性能要求高的地方?！仓苯佑肧ql或者存儲(chǔ)過(guò)程；犧牲可維護(hù)性和可復(fù)用性〕上層流程。87消除DTO88部署POJO程序899091用GRASP模式指導(dǎo)設(shè)計(jì)9293949596979899100101102103104105106107108109110質(zhì)量屬性驅(qū)動(dòng)架構(gòu)設(shè)計(jì)策略軟件質(zhì)量及質(zhì)量模型軟件質(zhì)量是一個(gè)復(fù)雜的概念，不同的人從不同的角度來(lái)看軟件質(zhì)量問(wèn)題，會(huì)有不同的理解。從用戶的角度看，質(zhì)量就是滿足客戶的需求；從開(kāi)發(fā)者的角度看，質(zhì)量

就是與需求說(shuō)明保持一致；從產(chǎn)品的角度看，質(zhì)量就是

產(chǎn)品的內(nèi)在特點(diǎn)；從價(jià)值的角度看，質(zhì)量就是客戶是否

愿意購(gòu)置。

在軟件工程開(kāi)發(fā)過(guò)程中，工程經(jīng)理眼中的質(zhì)量就是能“令人滿意”地工作以完成預(yù)期功能的軟件產(chǎn)品。所謂“令

人滿意”，包括功能、性能、接口需求及其他指標(biāo)，如可靠性、可維護(hù)性、可復(fù)用性和正確性。然而在實(shí)際工作中，一旦出現(xiàn)問(wèn)題時(shí)，工程管理人員必須權(quán)衡利弊，作出取舍，在滿足某一個(gè)指標(biāo)的同時(shí)，犧牲另外一個(gè)或幾個(gè)指標(biāo)。比方為了按期交貨，需對(duì)軟件功能進(jìn)行分類，在第

一個(gè)版本中實(shí)現(xiàn)優(yōu)先級(jí)較高的功能，在第二個(gè)版本中實(shí)

現(xiàn)優(yōu)先級(jí)較低的功能。因此，工程經(jīng)理需要一個(gè)對(duì)其工作有指導(dǎo)意義的質(zhì)量模型和度量方法。該模型一方面可以幫助工程經(jīng)理生產(chǎn)出符合標(biāo)準(zhǔn)的軟件產(chǎn)品，另一方面幫助工程經(jīng)理識(shí)別可能影響產(chǎn)品質(zhì)量的風(fēng)險(xiǎn)。為什么那么多軟件產(chǎn)品需要重新設(shè)計(jì)？難以維護(hù)？運(yùn)行速度太慢？穩(wěn)定性差？無(wú)法進(jìn)行功能擴(kuò)展？易遭受平安攻擊？無(wú)視包括質(zhì)量屬性需求在內(nèi)的非功能需求是致命的。質(zhì)量屬性分為：運(yùn)行期質(zhì)量屬性開(kāi)發(fā)期質(zhì)量屬性各類需求架構(gòu)設(shè)計(jì)的不同影響高可移植性對(duì)硬件和平臺(tái)相關(guān)特性進(jìn)行封裝、隔離高性能精心規(guī)劃職責(zé)模型在質(zhì)量屬性方面需求折衷質(zhì)量屬性分析的位置質(zhì)量屬性分析是概念性架構(gòu)設(shè)計(jì)的重要步驟。通過(guò)質(zhì)量屬性分析，制定出滿足非功能需求的高層設(shè)計(jì)決策。質(zhì)量屬性分析所處的位置如下圖”屬性-場(chǎng)景-決策”表法運(yùn)用“關(guān)鍵需求決定架構(gòu)”的策略，使質(zhì)量屬性分析的“輸入”集中到關(guān)鍵質(zhì)量屬性需求?！皩傩?場(chǎng)景-決策”表方法提倡通過(guò)一組具體場(chǎng)景將要到達(dá)的質(zhì)量屬性需求目標(biāo)細(xì)化，再根據(jù)場(chǎng)景制定架構(gòu)決策。“屬性-場(chǎng)景-決策“表法“屬性-場(chǎng)景-決策”表法的好處:可操作性強(qiáng)。質(zhì)量熟悉需求是籠統(tǒng)的目標(biāo)，而一組質(zhì)量場(chǎng)景使之明確化。防止過(guò)度設(shè)計(jì)。借助“屬性-場(chǎng)景-決策”表對(duì)質(zhì)量場(chǎng)景進(jìn)行評(píng)估，通過(guò)權(quán)衡場(chǎng)景發(fā)生的概率和遺漏它的代價(jià)，決定是否應(yīng)滿足該場(chǎng)景的要求。便于系統(tǒng)升級(jí)時(shí)參考。例：可擴(kuò)展性質(zhì)量屬性運(yùn)用“屬性-場(chǎng)景-決策”表方法，細(xì)化PMTool的可擴(kuò)展性需求，制定架構(gòu)決策，如下表所示：非功能需求對(duì)軟件架構(gòu)的影響比功能需求更大?！皩傩?場(chǎng)景-決策”表可以幫助軟件架構(gòu)師以一種更透明、更可操作的方式完成從質(zhì)量屬性需求到質(zhì)量場(chǎng)景的細(xì)化，最終根據(jù)具體的場(chǎng)景有針對(duì)性地設(shè)計(jì)架構(gòu)決策。架構(gòu)的目標(biāo)正確性correctness可靠性〔Reliable〕：軟件系統(tǒng)對(duì)于用戶的商業(yè)經(jīng)營(yíng)和管理來(lái)說(shuō)極為重要，因此軟件系統(tǒng)必須非?？煽?。健壯性robustness平安性〔Secure〕：軟件系統(tǒng)所承擔(dān)的交易的商業(yè)價(jià)值極高，系統(tǒng)的平安性非常重要?？缮炜s性〔Scalable〕：軟件必須能夠在用戶的使用率、用戶的數(shù)目增加很快的情況下，保持合理的性能。只有這樣，才能適應(yīng)用戶的市場(chǎng)擴(kuò)展得可能性?？啥ㄖ苹睠ustomizable〕：同樣的一套軟件，可以根據(jù)客戶群的不同和市場(chǎng)需求的變化進(jìn)行調(diào)整。可擴(kuò)展性〔Extensible〕：在新技術(shù)出現(xiàn)的時(shí)候，一個(gè)軟件系統(tǒng)應(yīng)當(dāng)允許導(dǎo)入新技術(shù)，從而對(duì)現(xiàn)有系統(tǒng)進(jìn)行功能和性能的擴(kuò)展可復(fù)用性reusability可維護(hù)性〔Maintainable〕：軟件系統(tǒng)的維護(hù)包括兩方面，一是排除現(xiàn)有的錯(cuò)誤，二是將新的軟件需求反映到現(xiàn)有系統(tǒng)中去。一個(gè)易于維護(hù)的系統(tǒng)可以有效地降低技術(shù)支持的花費(fèi)。兼容性compatibility可移植性portability易用性easeofuse高效性efficiencytimeliness,economyandfunctionality客戶體驗(yàn)〔CustomerExperience〕：軟件系統(tǒng)必須易于使用。

市場(chǎng)時(shí)機(jī)〔TimetoMarket〕：軟件用戶要面臨同業(yè)競(jìng)爭(zhēng)，軟件提供商也要面臨同業(yè)競(jìng)爭(zhēng)。以最快的速度爭(zhēng)奪市場(chǎng)先機(jī)非常重要。131軟件可維護(hù)性軟件的可維護(hù)性概述軟件可維護(hù)策略軟件可擴(kuò)展性〔Extensibility〕設(shè)計(jì)策略軟件靈活性〔Flexibility〕設(shè)計(jì)策略軟件可插入性〔Pluggability〕設(shè)計(jì)策略132軟件的可維護(hù)性概述軟件可維護(hù)性的定義：軟件能夠被理解、校正、適應(yīng)及增強(qiáng)功能的容易程度。軟件的可維護(hù)性、可使用性、可靠性是衡量軟件質(zhì)量的幾個(gè)主要特性，也是用戶十分關(guān)心的幾個(gè)問(wèn)題。軟件的可維護(hù)性是軟件開(kāi)發(fā)階段的關(guān)鍵目標(biāo)。影響軟件可維護(hù)性的因素較多，設(shè)計(jì)、編碼及測(cè)試中的疏忽和低劣的軟件配置，缺少文檔等都對(duì)軟件的可維護(hù)性產(chǎn)生不良影響。軟件可維護(hù)性可用下面七個(gè)質(zhì)量特性來(lái)衡量，即可理解性、可測(cè)試性、可修改性、可靠性、可移植性、可使用性和效率。對(duì)于不同類型的維護(hù),這七種特性的側(cè)重點(diǎn)也是不相同。133可維護(hù)性和可復(fù)用性一般來(lái)說(shuō)，一個(gè)易于維護(hù)的系統(tǒng)，就是復(fù)用率較高的系統(tǒng)；一個(gè)復(fù)用率較好的的系統(tǒng)，就是一個(gè)易于維護(hù)的系統(tǒng)。但是，實(shí)際上，可維護(hù)性和可復(fù)用性是兩個(gè)獨(dú)立的目標(biāo)。軟件維護(hù)就是軟件的再生。一個(gè)好的軟件設(shè)計(jì)，必須能夠允許新的設(shè)計(jì)要求以比較容易和平穩(wěn)的方式參加到已有的系統(tǒng)中去，從而使這個(gè)系統(tǒng)能夠不斷的的煥發(fā)出活力。一個(gè)可維護(hù)性較好的系統(tǒng)，應(yīng)當(dāng)允許維護(hù)工作能夠以容易、準(zhǔn)確、平安和經(jīng)濟(jì)的形式進(jìn)行。134導(dǎo)致可維護(hù)性較低的原因：1.過(guò)于僵硬：在系統(tǒng)中參加一個(gè)新的功能，不管大小都很難，不僅意味著建造一個(gè)獨(dú)立的新的模塊，而且因?yàn)檫@個(gè)新功能會(huì)涉及很多其他模塊，最后成跨越幾個(gè)模塊的改動(dòng)。2.過(guò)于脆弱：與軟件的過(guò)于僵硬同時(shí)存在，是軟件系統(tǒng)在修改已有代碼時(shí)過(guò)于脆弱。對(duì)一個(gè)地方的修改，往往會(huì)導(dǎo)致看上去沒(méi)有什么關(guān)系的另外一個(gè)地方發(fā)生故障。3.復(fù)用率低：所謂復(fù)用，就是指一個(gè)軟件的組成局部，可以在同一個(gè)工程的不同地方甚至另一個(gè)工程中重復(fù)使用。復(fù)用率低，指當(dāng)一段代碼，函數(shù)，模塊的功能可以在新的模塊或新的系統(tǒng)使用，但是已有代碼依賴于其他很多東西，很難分開(kāi)。1354.黏度過(guò)高：一個(gè)改動(dòng)可以保存原始設(shè)計(jì)意圖和原始設(shè)計(jì)框架的方式進(jìn)行，也可以以破壞原始意圖和框架進(jìn)行。第一種方法對(duì)系統(tǒng)的未來(lái)有利，第二種方法是權(quán)宜之計(jì)，可以解決短期的問(wèn)題，但是會(huì)犧牲中長(zhǎng)期的利益。如果一個(gè)系統(tǒng)中使用第二種方法比使用第一種方法容易，那么就是黏度過(guò)高。設(shè)計(jì)的目標(biāo)：1.可擴(kuò)張性2.靈活性3.

插入性136系統(tǒng)的可復(fù)用性：復(fù)用性的重要性：1.較高的生產(chǎn)效率2.較高的軟件質(zhì)量3.恰當(dāng)使用復(fù)用可以改善系統(tǒng)的可維護(hù)性統(tǒng)的復(fù)用和面向?qū)ο蟮南到y(tǒng)設(shè)計(jì)中復(fù)用的區(qū)別1.傳統(tǒng)的復(fù)用：代碼的剪貼復(fù)用；算法的復(fù)用；數(shù)據(jù)結(jié)構(gòu)的復(fù)用。2.面向?qū)ο蟮脑O(shè)計(jì)的復(fù)用：在OO中數(shù)據(jù)的抽象化、繼承、封裝和多態(tài)是幾個(gè)重要的語(yǔ)言特性，這些特性使得一個(gè)系統(tǒng)可以在更高的層次上提供可復(fù)用性。137數(shù)據(jù)的抽象化和繼承關(guān)系使得概念和定義可以復(fù)用；多態(tài)性使得實(shí)現(xiàn)和應(yīng)用可以復(fù)用；抽象化和封裝可以保持和促進(jìn)系統(tǒng)的可維護(hù)性。138可復(fù)用和可維護(hù)性的關(guān)系1.適當(dāng)?shù)氖褂脧?fù)用，可以提高可維護(hù)性，即支持可維護(hù)性的復(fù)用，就是在保持甚至提高系統(tǒng)的可維護(hù)性的同時(shí)，實(shí)現(xiàn)系統(tǒng)的復(fù)用。2.適當(dāng)提高系統(tǒng)的可復(fù)用性可以提高系統(tǒng)的可擴(kuò)展性：系統(tǒng)的可擴(kuò)展性由“開(kāi)-閉”原那么、里氏代換原那么、依賴倒轉(zhuǎn)原那么和組合/聚合復(fù)用原那么所保證。3.適當(dāng)提高系統(tǒng)的可復(fù)用性，可以提高系統(tǒng)的靈活性。系統(tǒng)的靈活性由“開(kāi)-閉”原那么、迪米特法那么、接口隔離原那么所保證的。4.適當(dāng)提高系統(tǒng)的可復(fù)用性，可以提高系統(tǒng)的可插入性。系統(tǒng)的可插入性由“開(kāi)-閉”原那么、里氏代換原那么、組合/聚合復(fù)用原那么和依賴倒轉(zhuǎn)原那么所保證。139復(fù)用原那么：1.“開(kāi)-閉”原那么:OCP2.里氏代換原那么:LSP3.依賴倒轉(zhuǎn)原那么:DIP4.接口隔離原那么:ISP5.組合/聚合復(fù)用原那么:CARP6.迪米特法那么:LoD140軟件可維護(hù)策略從下面五個(gè)方面來(lái)闡述如何提高軟件的可維護(hù)性：1.建立明確的軟件質(zhì)量目標(biāo)如果要程序滿足可維護(hù)性七個(gè)特性的全部要求，那么要付出很大的代價(jià)，甚至是不現(xiàn)實(shí)的，但有些可維護(hù)性是相互促進(jìn)的，因此要明確軟件所追求的質(zhì)量目標(biāo)。2.使用先進(jìn)的軟件開(kāi)發(fā)技術(shù)和工具利用先進(jìn)的軟件開(kāi)發(fā)技術(shù)能大大提高軟件質(zhì)量和減少軟件費(fèi)用。面向?qū)ο蟮能浖_(kāi)發(fā)方法就是一個(gè)非常實(shí)用而強(qiáng)有力的軟件開(kāi)發(fā)方法，用面向?qū)ο蠓椒ㄩ_(kāi)發(fā)出來(lái)的軟件系統(tǒng)，穩(wěn)定性好，比較容易修改，比較容易理解，易于測(cè)試和調(diào)試，因此，可維護(hù)性好。1413.建立明確的質(zhì)量保證質(zhì)量保證是指為提高軟件質(zhì)量所做的各種檢查工作。質(zhì)量保證檢查是非常有效的方法，不僅在軟件開(kāi)發(fā)的各階段中得到了廣泛應(yīng)用，而且在軟件維護(hù)中也是一個(gè)非常主要的工具。為了保證可維護(hù)性，以下四類檢查是非常有用的：(1)在檢查點(diǎn)進(jìn)行檢查。(2)驗(yàn)收檢查。(3)周期性的維護(hù)檢查。(4)對(duì)軟件包的檢查。4.選擇可維護(hù)的語(yǔ)言程序設(shè)計(jì)語(yǔ)言的選擇對(duì)維護(hù)影響很大。低級(jí)語(yǔ)言很難掌握，很難理解，因而很難維護(hù)。一般來(lái)說(shuō)，高級(jí)語(yǔ)言比低級(jí)語(yǔ)言更容易理解，第四代語(yǔ)言更容易理解，容易編程，程序容易修改，改進(jìn)了可維護(hù)性。1425.改進(jìn)程序的文檔程序文檔是對(duì)程序功能、程序各組成局部之間的關(guān)系、程序設(shè)計(jì)策略、程序?qū)崿F(xiàn)過(guò)程的歷史數(shù)據(jù)等的說(shuō)明和補(bǔ)充。程序文檔對(duì)提高程序的可閱讀性有重要作用。為了維護(hù)程序，人們必須閱讀和理解程序文檔。143一些經(jīng)驗(yàn)1。首先在軟件設(shè)計(jì)的時(shí)候就應(yīng)盡量考慮全面，防止在后期開(kāi)發(fā)到一定階段之后在進(jìn)行需求和功能上的改動(dòng)。軟件設(shè)計(jì)完成之后需要所有的工程負(fù)責(zé)人，工程經(jīng)理，主要程序員，主要的測(cè)試人員一起討論，討論通過(guò)之后才能進(jìn)行開(kāi)發(fā)。2。強(qiáng)調(diào)開(kāi)發(fā)人員的代碼標(biāo)準(zhǔn)。公司一定要形成自己的編程標(biāo)準(zhǔn)，所有的開(kāi)發(fā)人員須遵守。

3。軟件開(kāi)發(fā)的時(shí)候必須遵守一定的流程標(biāo)準(zhǔn)。例如代碼統(tǒng)一放在vss中進(jìn)行管理，每次checkin之前必須完成codereview，須有兩個(gè)同事一起檢查等，盡量在前期發(fā)現(xiàn)問(wèn)題。1444。重視測(cè)試。除了單元測(cè)試與集成測(cè)試，由非開(kāi)發(fā)人員和非設(shè)計(jì)人員來(lái)進(jìn)行的黑盒測(cè)試非常重要。測(cè)試組未確認(rèn)質(zhì)量過(guò)關(guān)的軟件不可release。

5。重視文檔。設(shè)計(jì)文檔，需求文檔，程序架構(gòu)文檔，測(cè)試文檔，用戶手冊(cè)，白皮書，等都應(yīng)完善。

6。在經(jīng)歷多個(gè)工程以后，要總結(jié)出一套對(duì)質(zhì)量和可維護(hù)性的度量方法和標(biāo)準(zhǔn)，才能持續(xù)不斷改進(jìn)。145軟件可擴(kuò)展性設(shè)計(jì)策略應(yīng)用框架(ApplicationFramework)軟件設(shè)計(jì)師用這個(gè)詞描述有助于軟件應(yīng)用開(kāi)發(fā)的一組可重用的設(shè)計(jì)和代碼?！敖Y(jié)構(gòu)”一詞著實(shí)反映了任何框架的本質(zhì)。在應(yīng)用開(kāi)發(fā)中，一個(gè)相當(dāng)復(fù)雜的應(yīng)用包含了如此之多的不斷變化的細(xì)枝局部，而結(jié)構(gòu)幫助我們將這些不斷變化的細(xì)枝局部，組織成易于理解的少數(shù)幾個(gè)局部?！皯?yīng)用框架”為開(kāi)發(fā)者提供了結(jié)構(gòu)和模板，開(kāi)發(fā)者以此為基線〔Baseline)來(lái)構(gòu)建他們的應(yīng)用系統(tǒng)。用戶界面1.模型-視圖控制器(Model-ViewController,MVC)2.MacApp3.MFC業(yè)務(wù)領(lǐng)域1.SanFrancisco通用應(yīng)用開(kāi)發(fā)1.CommonPoint2.Java語(yǔ)言和運(yùn)行時(shí)虛擬機(jī)的Java環(huán)境應(yīng)用框架作用模塊化(modularity)可重用性(reusability)可擴(kuò)展性(extensibility)簡(jiǎn)單性(simplicity)可維護(hù)性(maintainability)應(yīng)用框架解析----框架開(kāi)發(fā)過(guò)程在明確了需要應(yīng)用框架之后，首先要確定框架開(kāi)發(fā)過(guò)程包括的四個(gè)主要階段：分析、設(shè)計(jì)、實(shí)現(xiàn)和穩(wěn)定。分析設(shè)計(jì)構(gòu)造穩(wěn)定范圍目標(biāo)文檔測(cè)試培訓(xùn)架構(gòu)識(shí)別通用點(diǎn)和擴(kuò)展點(diǎn)實(shí)現(xiàn)應(yīng)用框架解析----框架開(kāi)發(fā)過(guò)程框架開(kāi)發(fā)的通用技術(shù)：通用點(diǎn)(Commonspots)擴(kuò)展點(diǎn)(Hotspots):占位符號(hào)/擴(kuò)展點(diǎn)黑盒框架(Black-boxframework)白盒框架(White-boxframework)灰盒框架(Gray-boxframework)設(shè)計(jì)模式(Designpattern)其中，通用點(diǎn)、擴(kuò)展點(diǎn)、設(shè)計(jì)模式是用于開(kāi)發(fā)框架的技術(shù)，黑盒、白盒、灰盒是開(kāi)發(fā)框架的方法。151軟件可復(fù)用性軟件的可復(fù)用性概述軟件復(fù)用是將已有的軟件及其有效成分用于構(gòu)造新的軟件或系統(tǒng)。它不僅是對(duì)軟件程序的復(fù)用，還包括對(duì)軟件生產(chǎn)過(guò)程中其它勞動(dòng)成果的復(fù)用，如工程方案書、可行性報(bào)告、需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼(源程序)、測(cè)試用例、文檔與使用手冊(cè)等等。因此，軟件復(fù)用包括軟件產(chǎn)品復(fù)用和軟件過(guò)程復(fù)用兩局部的內(nèi)容。152從對(duì)復(fù)用產(chǎn)品的了解程度和復(fù)用方式看，也可分為白盒復(fù)用與黑盒復(fù)用。黑盒復(fù)用指對(duì)已有產(chǎn)品或構(gòu)件不需作任何修改，直接進(jìn)行復(fù)用，這是理想的復(fù)用方式。它主要基于二進(jìn)制代碼的復(fù)用，包括可執(zhí)行程序的復(fù)用和基于庫(kù)〔包括動(dòng)態(tài)鏈接庫(kù)和靜態(tài)庫(kù)〕的復(fù)用。白盒復(fù)用指根據(jù)用戶需求對(duì)已有產(chǎn)品進(jìn)行適應(yīng)性修改后才可使用。白盒復(fù)用一般為源代碼一級(jí)的復(fù)用，以及相應(yīng)的測(cè)試用例、文檔等的復(fù)用。無(wú)論白盒復(fù)用還是黑盒復(fù)用，都需要花費(fèi)一定的代價(jià)熟悉和掌握被復(fù)用的軟件系統(tǒng)。作為經(jīng)濟(jì)上的考慮，要求復(fù)用的代價(jià)必須大大小于重新開(kāi)發(fā)的代價(jià)，否那么就不應(yīng)該考慮。153軟件復(fù)用的一個(gè)關(guān)鍵因素是抽象。軟件的復(fù)用性很大程度上取決于對(duì)可復(fù)用對(duì)象的認(rèn)識(shí)深度或者說(shuō)可復(fù)用對(duì)象的抽象層次。抽象層次越高、與具體環(huán)境和特定細(xì)節(jié)越無(wú)關(guān)，那么它被未來(lái)系統(tǒng)復(fù)用的可能性也越大。領(lǐng)域分析那么是進(jìn)行抽象的有力工具。軟件復(fù)用根本原那么必須有可以復(fù)用的對(duì)象，所復(fù)用的對(duì)象必須是有用的；復(fù)用者需要知道如何去使用被復(fù)用的對(duì)象。154在復(fù)用軟件設(shè)計(jì)中，根據(jù)面向?qū)ο笤?，可考慮幾個(gè)方面：1〕封裝性2〕重載3〕繼承4〕聚合5〕多態(tài)性中間件及相關(guān)軟件是商業(yè)化的軟件復(fù)用。僅看程序方面，軟件復(fù)用后的制品也不只包括中間件軟件，還包括軟件框架、應(yīng)用框架、通用業(yè)務(wù)構(gòu)件等多種可復(fù)用形式。155常見(jiàn)問(wèn)題：在編程相關(guān)的各種書籍中一直在強(qiáng)調(diào)代碼的可重用性，之前所寫的代碼也一直遵循著這一規(guī)那么，但是最近越來(lái)越感覺(jué)這種規(guī)那么很麻煩，當(dāng)費(fèi)力心機(jī)的想使一段代碼變得可重用，就不得不加上各種條件的判斷，代碼中充滿了各種if...else...使代碼變得很難看懂，有時(shí)自己都會(huì)被各種不同的屬性與條件判斷搞暈，這樣的代碼對(duì)于后期的維護(hù)來(lái)說(shuō)肯定是十分困難的。所以我現(xiàn)在都是把不同的業(yè)務(wù)邏輯用不同的方法實(shí)現(xiàn)，即使有些邏輯是相似的，我也使用了不同的方法，雖然這樣造成了許多重復(fù)代碼，但是這樣的代碼看起來(lái)邏輯更清晰，也更利于后期的維護(hù)，包括轉(zhuǎn)交給別人時(shí)也更容易讓人看懂，盡管這樣會(huì)造成代碼量的增加。所以現(xiàn)在對(duì)代碼的可重用性這個(gè)問(wèn)題很困惑。156建議：在面向?qū)ο蟮恼Z(yǔ)言里，如果ifelse大多，也許說(shuō)明抽象不夠。多態(tài)、功能邊界定義不夠、模塊細(xì)化不夠。抽象錯(cuò)誤的情況下考慮代碼級(jí)別的重用是比較傷神的。業(yè)務(wù)描述真正正確以后,維護(hù)方案也真正就浮現(xiàn)出來(lái)了。反之業(yè)務(wù)錯(cuò)了可維護(hù)性設(shè)計(jì)也會(huì)預(yù)測(cè)錯(cuò)誤,設(shè)計(jì)無(wú)用接口。誤區(qū)：面向?qū)ο笫勾a、邏輯更簡(jiǎn)單。157軟件架構(gòu)模式軟件架構(gòu)軟件架構(gòu)概論架構(gòu)的目標(biāo)架構(gòu)的種類軟件框架常見(jiàn)的架構(gòu)模式軟件架構(gòu)概論系統(tǒng)架構(gòu)是一個(gè)軟件系統(tǒng)從整體到局部的最高層次的劃分。一個(gè)系統(tǒng)通常是由元件組成的，而這些元件如何形成、相互之間如何發(fā)生作用，那么是關(guān)于這個(gè)系統(tǒng)本身結(jié)構(gòu)的重要信息。詳細(xì)地說(shuō)，就是要包括架構(gòu)元件〔ArchitectureComponent〕、聯(lián)結(jié)器〔Connector〕、任務(wù)流〔Task-flow〕。所謂架構(gòu)元素，也就是組成系統(tǒng)的核心"磚瓦"，而聯(lián)結(jié)器那么描述這些元件之間通訊的路徑、通訊的機(jī)制、通訊的預(yù)期結(jié)果，任務(wù)流那么描述系統(tǒng)如何使用這些元件和聯(lián)結(jié)器完成某一項(xiàng)需求。建造一個(gè)系統(tǒng)所作出的最高層次的、以后難以更改的，商業(yè)的和技術(shù)的決定。在建造一個(gè)系統(tǒng)之前會(huì)有很多的重要決定需要事先作出，而一旦系統(tǒng)開(kāi)始進(jìn)行詳細(xì)設(shè)計(jì)甚至建造，這些決定就很難更改甚至無(wú)法更改。顯然，這樣的決定必定是有關(guān)系統(tǒng)設(shè)計(jì)成敗的最重要決定，必須經(jīng)過(guò)慎重的研究和考察。架構(gòu)的種類根據(jù)我們關(guān)注的角度不同，可以將架構(gòu)分成三種：邏輯架構(gòu)物理架構(gòu)系統(tǒng)架構(gòu)邏輯架構(gòu)軟件系統(tǒng)中元件之間的關(guān)系，比方用戶界面，數(shù)據(jù)庫(kù)，外部系統(tǒng)接口，商業(yè)邏輯元件等等。物理架構(gòu)軟件元件是怎樣放到硬件上的以下圖描述了一個(gè)分布于北京和上海的分布式系統(tǒng)的物理架構(gòu)，圖中所有的元件都是物理設(shè)備，包括網(wǎng)絡(luò)分流器、代理效勞器、WEB效勞器、應(yīng)用效勞器、報(bào)表效勞器、整合效勞器、存儲(chǔ)效勞器、主機(jī)等等。系統(tǒng)架構(gòu)系統(tǒng)的非功能性特征，如可擴(kuò)展性、可靠性、強(qiáng)壯性、靈活性、性能等。系統(tǒng)架構(gòu)的設(shè)計(jì)要求架構(gòu)師具備軟件和硬件的功能和性能的過(guò)硬知識(shí)，這一工作是架構(gòu)設(shè)計(jì)工作中最困難的工作。架構(gòu)的兩要素元件劃分和設(shè)計(jì)決定。邏輯元件：一個(gè)軟件系統(tǒng)中的元件首先是邏輯元件。這些邏輯元件如何放到硬件上，以及這些元件如何為整個(gè)系統(tǒng)的可擴(kuò)展性、可靠性、強(qiáng)壯性、靈活性、性能等做出奉獻(xiàn)，是非常重要的信息。設(shè)計(jì)決定：進(jìn)行軟件設(shè)計(jì)需要做出的決定中，必然會(huì)包括邏輯結(jié)構(gòu)、物理結(jié)構(gòu)，以及它們?nèi)绾斡绊懙较到y(tǒng)的所有非功能性特征。這些決定中會(huì)有很多是一旦作出，就很難更改的?；跀?shù)據(jù)庫(kù)的系統(tǒng)架構(gòu)：一般有多少個(gè)數(shù)據(jù)表，就會(huì)有多少頁(yè)的架構(gòu)設(shè)計(jì)文檔。比方一個(gè)中等的數(shù)據(jù)庫(kù)應(yīng)用系統(tǒng)通常含有一百個(gè)左右的數(shù)據(jù)表，這樣的一個(gè)系統(tǒng)設(shè)計(jì)通常需要有一百頁(yè)左右的架構(gòu)設(shè)計(jì)文檔。從概念性架構(gòu)到實(shí)際架構(gòu)就是多(Lessismore.)。--密斯·凡德羅概念性架構(gòu)是對(duì)系統(tǒng)設(shè)計(jì)的最初設(shè)想。一般來(lái)說(shuō)，實(shí)際的軟件架構(gòu)設(shè)計(jì)過(guò)程是，先進(jìn)行概念性架構(gòu)的設(shè)計(jì)，把最關(guān)鍵的設(shè)計(jì)要素和交互機(jī)制確定下來(lái)，然后再考慮具體技術(shù)的運(yùn)用，設(shè)計(jì)出實(shí)際架構(gòu)。架構(gòu)設(shè)計(jì)中的關(guān)鍵要素及解決策略策略是制勝的關(guān)鍵。--張明正，《擋不住的趨勢(shì)》最好的軟件開(kāi)發(fā)人員都知道一個(gè)秘密：美的東西比丑的東西創(chuàng)立起來(lái)更廉價(jià)，也更快捷。--RobertC.Martin,《軟件之美》時(shí)間就是系統(tǒng)架構(gòu)的生命。--PhilippeKruchten方法產(chǎn)生于恐懼。面對(duì)時(shí)間緊迫的壓力，我們有理由質(zhì)疑那種不顧時(shí)間花銷、一味追求軟件架構(gòu)高質(zhì)量的做法。軟件架構(gòu)是軟件系統(tǒng)質(zhì)量的核心，必須足夠重視，但在不適當(dāng)?shù)臅r(shí)候“用時(shí)間換完美”會(huì)毀掉整個(gè)工程。架構(gòu)設(shè)計(jì)并非“好的就是成功的”，而是“適合的才是成功的”。方法論

AlistairCockburn的七條定理，總結(jié)為：溝通和反響。RUP、XP重量之爭(zhēng)軟件架構(gòu)設(shè)計(jì)中的關(guān)鍵要素及解決策略：

關(guān)鍵要素

策略

----------------------------------------------- -----------------------1.是否遺漏了至關(guān)重要的非功能需求？

全面認(rèn)識(shí)需求。2.能否馴服數(shù)量巨大且頻繁變化的需求？

關(guān)鍵需求決定架構(gòu)。3.能否沉著地設(shè)計(jì)軟件架構(gòu)的不同方面？

多視圖探尋架構(gòu)。4.是否及早驗(yàn)證架構(gòu)方案并作出了調(diào)整？

及早驗(yàn)證架構(gòu)。軟件架構(gòu)設(shè)計(jì)過(guò)程總覽一般的軟件過(guò)程：需求分析的幾個(gè)概念需求捕獲vs需求分析vs系統(tǒng)分析需求捕獲是獲取知識(shí)的過(guò)程，知識(shí)從無(wú)到有。需求分析是挖掘和整理知識(shí)的過(guò)程，它在已掌握知識(shí)的根底上進(jìn)行。系統(tǒng)分析？如果說(shuō)需求分析致力于“做什么”，那么系統(tǒng)分析那么涉及“怎么做”。軟件架構(gòu)師不必是需求捕獲專家，也不必是編寫《軟件需求規(guī)格說(shuō)明書》的專家。但他一定應(yīng)在需求分類、需求折衷和需求變更的研究方面是專家，否那么他和其他軟件架構(gòu)師相比，就輸在了“起跑線”上。概念性架構(gòu)設(shè)計(jì)概念性架構(gòu)設(shè)計(jì)的迭代方式：1.魯棒性分析；2.引入架構(gòu)模式；3.質(zhì)量屬性分析。魯棒性分析所謂魯棒性分析是這樣一種方法：通過(guò)分析用例規(guī)約中的事件流，識(shí)別出實(shí)現(xiàn)用例規(guī)定的功能所需的主要對(duì)象及其職責(zé)，形成以職責(zé)模型為主的初步設(shè)計(jì)。魯棒性分析是從功能需求向設(shè)計(jì)方案過(guò)度的第一步，所獲得的初步設(shè)計(jì)是一種理想化的職責(zé)模型，它的重點(diǎn)是識(shí)別組成軟件系統(tǒng)的高級(jí)職責(zé)塊、規(guī)劃它們之間的關(guān)系。魯棒性分析填補(bǔ)了分析和設(shè)計(jì)之間的鴻溝。魯棒圖包含三種元素：邊界對(duì)象、控制對(duì)象和實(shí)體對(duì)象。引入架構(gòu)模式較為經(jīng)典的幾種架構(gòu)模式：分層、MVC、微內(nèi)核、基于元模型的架構(gòu)、管道-過(guò)濾器等。質(zhì)量屬性分析“屬性-場(chǎng)景-決策”表方法：細(xì)化架構(gòu)設(shè)計(jì)架構(gòu)細(xì)化工作主要表達(dá)在基于五視圖方法進(jìn)行架構(gòu)細(xì)化：

約束

↓

┌───────┐

領(lǐng)域模型->│基于五視圖方法│

關(guān)鍵需求->│

│->架構(gòu)方案

概念架構(gòu)->│進(jìn)行架構(gòu)細(xì)化│

└───────┘

↑

經(jīng)驗(yàn)邏輯架構(gòu)設(shè)計(jì)中，“發(fā)現(xiàn)通用機(jī)制”是應(yīng)被特別強(qiáng)調(diào)的。機(jī)制(Mechanism)是模式的實(shí)例。機(jī)制是特定上下文中重復(fù)出現(xiàn)的問(wèn)題的特定解決方案。具有良好架構(gòu)的系統(tǒng)具備概念完整性。它通過(guò)對(duì)系統(tǒng)架構(gòu)建立一種清晰的認(rèn)識(shí)來(lái)發(fā)現(xiàn)通用的抽象和機(jī)制。利用這種共性使最終產(chǎn)生的系統(tǒng)結(jié)構(gòu)更為簡(jiǎn)單。實(shí)現(xiàn)并驗(yàn)證軟件架構(gòu)好的策略必須是一再求證、測(cè)試、發(fā)現(xiàn)瑕疵漏洞，另想途徑或方法來(lái)彌補(bǔ)策略缺乏，有時(shí)甚至得全盤放棄，重新籌劃。--張明正，《擋不住的趨勢(shì)》架構(gòu)原型對(duì)功能性需求的實(shí)現(xiàn)非常有限，那么“架構(gòu)驗(yàn)證”要驗(yàn)證什么？答案是要驗(yàn)證架構(gòu)對(duì)質(zhì)量屬性需求的支持程度，包括運(yùn)行期質(zhì)量屬性和開(kāi)發(fā)期質(zhì)量屬性。驗(yàn)證架構(gòu)的兩種方法：原型法。對(duì)于工程型開(kāi)發(fā)，常采用“原型法”。即對(duì)一組架構(gòu)設(shè)計(jì)決策在非功能需求方面的滿足程度進(jìn)行驗(yàn)證。該原型往往是演進(jìn)型，而非拋棄型?？蚣芊?。對(duì)于產(chǎn)品型開(kāi)發(fā)，采用“框架法”有更多優(yōu)點(diǎn)。該方法將架構(gòu)設(shè)計(jì)方案用框架的形式實(shí)現(xiàn)，并在此根底上進(jìn)行評(píng)估驗(yàn)證。在框架實(shí)現(xiàn)后，在框架根底上實(shí)現(xiàn)局部應(yīng)用的功能，即實(shí)現(xiàn)一個(gè)小的垂直原型，從而進(jìn)行實(shí)際非功能測(cè)試和開(kāi)發(fā)期質(zhì)量屬性評(píng)價(jià)。軟件框架什么是框架框架與架構(gòu)的區(qū)別常見(jiàn)的框架為什么要用框架因?yàn)檐浖到y(tǒng)開(kāi)展到今天已經(jīng)很復(fù)雜了，特別是效勞器端軟件，設(shè)計(jì)到的知識(shí)，內(nèi)容，問(wèn)題太多。在某些方面使用成熟的框架，可以防止重復(fù)做已有的根底工作，而只需要集中精力完成系統(tǒng)的業(yè)務(wù)邏輯設(shè)計(jì)?？蚣芤话闶浅墒?，穩(wěn)健的，可以處理系統(tǒng)很多細(xì)節(jié)問(wèn)題，比方，事物理，平安性，數(shù)據(jù)流控制等問(wèn)題?？蚣芤话愣冀?jīng)過(guò)很多人使用，所以結(jié)構(gòu)很好，所以擴(kuò)展性也很好，而且它是不斷升級(jí)的，使用框架的開(kāi)發(fā)者可以直接享受別人升級(jí)代碼帶來(lái)的好處。框架一般處在低層應(yīng)用平臺(tái)〔如J2EE〕和高層業(yè)務(wù)邏輯之間的中間層。185常見(jiàn)的JAVA框架EJBStrutsSpringHibernateIBatisJSFtapestryWAFTurbineCOCOONECHOJATOTCFExt…186.NET框架.NET框架是創(chuàng)立、部署和運(yùn)行Web效勞及其他應(yīng)用程序的一個(gè)環(huán)境。它包括三個(gè)主要局部：公共語(yǔ)言運(yùn)行時(shí)、框架類和ASP.NET。.NET框架對(duì)Web站點(diǎn)的支持：ASP.NET在編寫Windows軟件〔使用ATL/COM、MFC、VB或標(biāo)準(zhǔn)Win32〕方面，與當(dāng)前創(chuàng)立應(yīng)用程序的方式相比.NET都具有的優(yōu)勢(shì)。C++框架標(biāo)準(zhǔn)庫(kù)DinkumwareC++Library、RogueWaveStandardC++Library、SGISTL、STLportGUIMFC、QT、WxWindows、Fox、WTL、GTK、BCG、XtremeToolkit網(wǎng)絡(luò)通信ACE、StreamModule、SimpleSocket綜合P::Classes、ACDK-ArtefakturComponentDevelopmentKit、dlibC++library、ChilkatC++Libraries、C++PortableTypesLibrary(PTypes)、LFC其他庫(kù)Loki、ATL、FC++:TheFunctionalC++Library、FACT!、Crypto++BoostRegex正那么表達(dá)式庫(kù)SpiritLLparserframework，用C++代碼直接表達(dá)EBNFGraph圖組件和算法Lambda在調(diào)用的地方定義短小匿名的函數(shù)對(duì)象conceptcheck檢查泛型編程中的conceptMpl用模板實(shí)現(xiàn)的元編程框架Thread可移植的C++多線程庫(kù)、Python把C++類和函數(shù)映射到Python之中Pool內(nèi)存池管理smart_ptr智能指針XMLXerces、XMLBooster、PullParser、Xalan、CMarkup、libxml++

科學(xué)計(jì)算Blitz++、POOMA、MTL、CGAL游戲開(kāi)發(fā)Audio/Video3DC++Programming Library、KlayGE龔敏敏、OGRE線程

C++Threads、ZThreads序列化

s11n、SimpleXMLPersistenceLibrary字符串

C++StrLibrary、CommonTextTransformationLibrary、GRETA190不同層次的模式架構(gòu)模式(ArchitecturalPattern)設(shè)計(jì)模式(DesignPattern)代碼模式(CodingPattern)區(qū)別：在于三種不同的模式存在于它們各自的抽象層次和具體層次。架構(gòu)模式是一個(gè)系統(tǒng)的高層次策略，涉及到大尺度的組件以及整體性質(zhì)。架構(gòu)模式的好壞可以影響到總體布局和框架性結(jié)構(gòu)。設(shè)計(jì)模式是中等尺度的結(jié)構(gòu)策略。這些中等尺度的結(jié)構(gòu)實(shí)現(xiàn)了一些大尺度組件的行為和它們之間的關(guān)系。模式的好壞不會(huì)影響到系統(tǒng)的總體布局和總體框架。設(shè)計(jì)模式定義出子系統(tǒng)或組件的微觀結(jié)構(gòu)。代碼模式是特定的范例和與特定語(yǔ)言有關(guān)的編程技巧。代碼模式的好壞會(huì)影響到一個(gè)中等尺度組件的內(nèi)部、外部的結(jié)構(gòu)或行為的底層細(xì)節(jié)，但不會(huì)影響到一個(gè)部件或子系統(tǒng)的中等尺度的結(jié)構(gòu)，更不會(huì)影響到系統(tǒng)的總體布局和大尺度框架。架構(gòu)模式(ArchitecturalPattern)軟件體系結(jié)構(gòu)通常被稱為架構(gòu)，指可以預(yù)制和可重構(gòu)的軟件框架結(jié)構(gòu)。架構(gòu)尚處在開(kāi)展期，對(duì)于其定義，學(xué)術(shù)界尚未形成一個(gè)統(tǒng)一的意見(jiàn)，而不同角度的視點(diǎn)也會(huì)造成軟件體系結(jié)構(gòu)的不同理解。眾多軟件架構(gòu)概念都是圍繞“組成”和“決策”兩個(gè)視角展開(kāi)的。Booch、Rumbaugh和Jacobson的定義架構(gòu)是一系列重要決策的集合，這些決策與以下內(nèi)容有關(guān)：軟件的組織，構(gòu)成系統(tǒng)的結(jié)構(gòu)元素及其接口的選擇，這些元素在相互協(xié)作中明確表現(xiàn)出的行為，這些結(jié)構(gòu)元素和行為元素進(jìn)一步組合所構(gòu)成的更大規(guī)模的子系統(tǒng)，以及指導(dǎo)這一組織——包括這些元素及其接口、它們的協(xié)作和它們的組合——架構(gòu)風(fēng)格。IEEE610.12-1990軟件工程標(biāo)準(zhǔn)：架構(gòu)是以組件、組件之間的關(guān)系、組件與環(huán)境之間的關(guān)系為內(nèi)容的某一系統(tǒng)的根本組織結(jié)構(gòu)，以及指導(dǎo)上述內(nèi)容設(shè)計(jì)與演化的原理〔Principle〕。Garlan的定義架構(gòu)包括組件〔Component〕、連接件〔Connector〕和約束〔Constrain〕三大要素。組件可以是一組代碼〔例如程序模塊〕，也可以是獨(dú)立的程序〔例如數(shù)據(jù)庫(kù)效勞器〕。連接件可以是過(guò)程調(diào)用、管道和消息等，用于表示組件之間的相互關(guān)系?！凹s束”一般為對(duì)象連接時(shí)的規(guī)那么，或指明構(gòu)件連接的形式和條件，例如，上層構(gòu)件可要求下層構(gòu)件的效勞，反之不行；兩對(duì)象不得遞規(guī)地發(fā)送消息；代碼復(fù)制遷移的一致性約束；什么條件下此種連接無(wú)效等。Shaw的定義：“軟件系統(tǒng)的架構(gòu)將系統(tǒng)描述為計(jì)算組件及組件之間的交互”。架構(gòu)＝組件＋交互幾種典型的架構(gòu)模式系統(tǒng)軟件分層(Layer)管道和過(guò)濾器(PipesandFilters)黑板(Blackboard)開(kāi)發(fā)分布式軟件經(jīng)紀(jì)人(Broker)客戶/效勞器〔Client/Server〕點(diǎn)對(duì)點(diǎn)〔PeertoPeer〕交互軟件模型-視圖-控制器〔Model-View-Controller〕顯示-抽象-控制〔Presentation-Abstraction-COntrol〕其它面向?qū)ο箫L(fēng)格(ADT)基于消息播送且面向圖形用戶界面的Chiron2風(fēng)格基于事件的隱式調(diào)用風(fēng)格(Event-based,ImplicitInvocation)…分層(Layer)從不同的層次來(lái)觀察系統(tǒng)，處理不同層次問(wèn)題的對(duì)象被封裝到不同的層中。

軟件為什么要分層？

為了實(shí)現(xiàn)“高內(nèi)聚、低耦合”。把問(wèn)題劃分開(kāi)來(lái)各個(gè)解決，易于控制，易于延展，易于分配資源…面向?qū)ο蟮摹⒒谀K化的組件設(shè)計(jì)需要能夠方便地修改應(yīng)用程序的各個(gè)局部。完成這一目標(biāo)的一種好方法就是在層上工作，將一個(gè)應(yīng)用程序的主要功能別離到不同的層或者級(jí)中。分層模型從本質(zhì)上講，層代表了一個(gè)應(yīng)用程序主要的功能。一般地，我們將應(yīng)用程序功能分為三個(gè)方面，對(duì)應(yīng)3層架構(gòu)模式。它們是數(shù)據(jù)層〔datalayer〕、商務(wù)層〔businesslayer〕和表示層〔presentationlayer〕。數(shù)據(jù)層：包含數(shù)據(jù)存儲(chǔ)和與它交互的組件或效勞。這些組件和效勞在功能上和中間層相互獨(dú)立〔盡管在物理上不必一定相互獨(dú)立--它們可以在同一臺(tái)效勞器上〕。中間層：包括一個(gè)或者多個(gè)組件效勞，它們應(yīng)用商務(wù)規(guī)那么、實(shí)現(xiàn)應(yīng)用程序邏輯并完成應(yīng)用程序運(yùn)行所需要的數(shù)據(jù)處理。作為這個(gè)過(guò)程的一局部，中間層負(fù)責(zé)處理來(lái)自數(shù)據(jù)存儲(chǔ)或者發(fā)送給數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)。表示層：從中間層獲得信息并顯示給用戶。該層同時(shí)也負(fù)責(zé)和用