高級(jí)軟件架構(gòu)設(shè)計(jì)名師優(yōu)質(zhì)課獲獎(jiǎng)市賽課一等獎(jiǎng)?wù)n件

高級(jí)軟件架構(gòu)設(shè)計(jì)康凱Msn:lptstr512@Mail:lptstr@第1頁1目錄第一單元：軟件生命周期與軟件架構(gòu)介紹 2第二單元：技術(shù)架構(gòu)視圖─面向?qū)ο蟪绦蛟O(shè)計(jì)標(biāo)準(zhǔn)與模式 24用GRASP模式指導(dǎo)設(shè)計(jì) 27領(lǐng)域模型 47面向?qū)ο笤O(shè)計(jì)基本標(biāo)準(zhǔn) 71第三單元：用UML輔助系統(tǒng)分析與設(shè)計(jì) 103UML介紹及常見疑難問題辨析 104借鑒RUPUML建模與分析 117第四單元：設(shè)計(jì)模式與軟件設(shè)計(jì)思想 131設(shè)計(jì)模式 132慣用軟件架構(gòu)格調(diào)及適用情況分析 172SOA及分層架構(gòu)設(shè)計(jì) 212第五單元：架構(gòu)設(shè)計(jì)實(shí)踐 225第2頁2第一單元：軟件生命周期與軟件架構(gòu)介紹第3頁3IT行業(yè)人才結(jié)構(gòu)與軟件架構(gòu)師定位軟件架構(gòu)師應(yīng)掌握知識(shí)體系軟件架構(gòu)設(shè)計(jì)特點(diǎn)、層次、分類軟件架構(gòu)主要理論、方向和趨勢(shì)軟件工廠，實(shí)現(xiàn)軟件開發(fā)產(chǎn)業(yè)化第4頁4軟件架構(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)開發(fā)人員開發(fā)。并處理系統(tǒng)開發(fā)、運(yùn)行中出現(xiàn)各種問題。系統(tǒng)架構(gòu)師目標(biāo)：對(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é)能力、分析能力、處理問題能力。三、寫作、溝通表示、培訓(xùn)。第5頁5角色軟件架構(gòu)師SoftwareArchitect定義主導(dǎo)系統(tǒng)全局分析設(shè)計(jì)和實(shí)施、負(fù)責(zé)軟件構(gòu)架和關(guān)鍵技術(shù)決議角色第6頁6職責(zé)領(lǐng)導(dǎo)與協(xié)調(diào)整個(gè)項(xiàng)目中技術(shù)活動(dòng)（分析、設(shè)計(jì)和實(shí)施等）推進(jìn)主要技術(shù)決議，并最終表示為軟件構(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á)和落實(shí)了解、評(píng)價(jià)并接收系統(tǒng)需求評(píng)價(jià)和確認(rèn)軟件架構(gòu)實(shí)現(xiàn)第7頁7專業(yè)技能技術(shù)全方面、成熟練達(dá)、洞察力強(qiáng)、經(jīng)驗(yàn)豐富，具備在缺乏完整信息、眾多問題交織一團(tuán)、含糊和矛盾情況下，快速抓住問題要害，并做出合理關(guān)鍵決定能力。具備戰(zhàn)略性和前瞻性思維能力，善于把握全局，能夠在更高抽象級(jí)別上進(jìn)行思索。對(duì)項(xiàng)目開發(fā)包括全部問題領(lǐng)域都有經(jīng)驗(yàn)，包含徹底地了解項(xiàng)目需求，開展分析設(shè)計(jì)之類軟件工程活動(dòng)等。具備領(lǐng)導(dǎo)素質(zhì)，以在各小組之間推進(jìn)技術(shù)工作，并在項(xiàng)目壓力下做出牢靠關(guān)鍵決議。擁有優(yōu)異溝通能力，用以進(jìn)行說服、勉勵(lì)和指導(dǎo)等活動(dòng)，并贏得項(xiàng)目組員信任。第8頁8以目標(biāo)導(dǎo)向和主動(dòng)方式來不帶任何感情色彩地關(guān)注項(xiàng)目結(jié)果，構(gòu)架師應(yīng)該是項(xiàng)目背后技術(shù)推進(jìn)力，而非構(gòu)想者或夢(mèng)想家（追求完美）精通構(gòu)架設(shè)計(jì)理論、實(shí)踐和工具，并掌握各種參考構(gòu)架、主要可重用構(gòu)架機(jī)制和模式。具備系統(tǒng)設(shè)計(jì)員全部技能，但包括面更廣、抽象級(jí)別更高。第9頁9軟件架構(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)。經(jīng)過對(duì)比軟件架構(gòu)師和系統(tǒng)分析師在軟件開發(fā)中職責(zé)和角色，不難發(fā)覺軟件架構(gòu)師與系統(tǒng)分析師所必需知識(shí)體系也是不盡相同，系統(tǒng)分析師主要職責(zé)是在需求分析、開發(fā)管理、運(yùn)行維護(hù)等方面，而軟件架構(gòu)師重點(diǎn)工作是在架構(gòu)與設(shè)計(jì)這兩個(gè)關(guān)鍵步驟上。所以在系統(tǒng)分析師必須具備知識(shí)體系中對(duì)系統(tǒng)構(gòu)架與設(shè)計(jì)等方面知識(shí)體系要求就相對(duì)低些；而軟件架構(gòu)師在需求分析、項(xiàng)目管理、運(yùn)行維護(hù)等方面知識(shí)要求也就相對(duì)低些。第10頁10成為一名合格軟件架構(gòu)師必須具備知識(shí)信息系統(tǒng)綜合知識(shí)體系軟件架構(gòu)知識(shí)體系第11頁11？MFC，MSF，MOF，RUP，J2EE，Spring，SOA，JUnit，ORM，.NetMVC，UML，XML，Corba，MDA，MDD，Web-ServiceRSS，Web2.0，AJAX，Serverlet，HibernateIOC，AOPRubyOnRailsRupBPELWorkflowEngineLBSOracleCMMIMQ…第12頁12軟件架構(gòu)師在干什么？思索、思索、再思索深入了解、準(zhǔn)確把握建設(shè)業(yè)務(wù)需求分析全部可見問題、障礙、風(fēng)險(xiǎn)充分參考已經(jīng)有成功方案，降低風(fēng)險(xiǎn)交流、討論、博弈、質(zhì)疑對(duì)構(gòu)思中方案不停提出質(zhì)疑，防止漏洞廣泛聽取各層面意見，開拓思緒重復(fù)質(zhì)疑、逐步完善已經(jīng)有設(shè)計(jì)構(gòu)思在動(dòng)手實(shí)現(xiàn)之前驗(yàn)證設(shè)計(jì)方案正確性第13頁13軟件架構(gòu)師知識(shí)結(jié)構(gòu)軟件知識(shí)最好要有系統(tǒng)開發(fā)全過程經(jīng)驗(yàn)。對(duì)IT建設(shè)生命周期各個(gè)步驟有深入了解，包含：系統(tǒng)/模塊邏輯設(shè)計(jì)、物理設(shè)計(jì)、代碼開發(fā)、項(xiàng)目管理、測(cè)試、公布、運(yùn)行維護(hù)等。深入掌握1-2種主流技術(shù)平臺(tái)上開發(fā)系統(tǒng)方法。了解各種應(yīng)用系統(tǒng)結(jié)構(gòu)。了解架構(gòu)設(shè)計(jì)領(lǐng)域主要理論、流派、框架。第14頁14軟件架構(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)。第15頁15軟件架構(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é)第16頁16軟件架構(gòu)師思維方式風(fēng)險(xiǎn)管理意識(shí)采取成功經(jīng)驗(yàn)、防止不應(yīng)有風(fēng)險(xiǎn)多方位開放思維多維度、多方向、包容性、防止排他性分析、質(zhì)疑、抽象、歸納沒有絕對(duì)好架構(gòu)設(shè)計(jì)，只有相對(duì)優(yōu)異方案第17頁17信息系統(tǒng)綜合知識(shí)體系(1)計(jì)算機(jī)系統(tǒng)綜合知識(shí)：包含計(jì)算機(jī)組成與體系結(jié)構(gòu)、嵌入式系統(tǒng)和操作系統(tǒng)等方面知識(shí)。(2)系統(tǒng)配置和方法：包含系統(tǒng)配置技術(shù)和系統(tǒng)性能等方面知識(shí)。(3)經(jīng)典系統(tǒng)應(yīng)用：包含網(wǎng)絡(luò)應(yīng)用、數(shù)據(jù)庫應(yīng)用和多媒體系統(tǒng)等方面知識(shí)。(4)系統(tǒng)開發(fā)：包含程序設(shè)計(jì)語言、軟件開發(fā)方法、需求分析和設(shè)計(jì)方法、測(cè)試評(píng)審方法、開發(fā)管理、應(yīng)用系統(tǒng)構(gòu)建、系統(tǒng)審計(jì)、外部資源使用和基于中間件開發(fā)等方面知識(shí)。(5)安全性和可靠性技術(shù)：包含數(shù)據(jù)安全與保密、防闖進(jìn)和防病毒、容錯(cuò)技術(shù)、可靠性模型與分析技術(shù)、系統(tǒng)可靠性、安全規(guī)章和保護(hù)私有信息規(guī)則等方面知識(shí)。第18頁18(6)標(biāo)準(zhǔn)化：包含標(biāo)準(zhǔn)化基礎(chǔ)知識(shí)、標(biāo)準(zhǔn)化分級(jí)、編碼標(biāo)準(zhǔn)、數(shù)據(jù)交換標(biāo)準(zhǔn)、軟件工程標(biāo)準(zhǔn)、信息安全標(biāo)準(zhǔn)、基于構(gòu)件軟件標(biāo)準(zhǔn)和標(biāo)準(zhǔn)化組織機(jī)構(gòu)等方面知識(shí)。(7)信息化基礎(chǔ)：包含政府信息化與電子政務(wù)、企業(yè)信息化與電子商務(wù)、信息化相關(guān)法律和要求等方面知識(shí)。(8)數(shù)學(xué)和英語：最少含有大學(xué)以上數(shù)學(xué)和英語基礎(chǔ)知識(shí)。第19頁19軟件架構(gòu)知識(shí)體系(1)系統(tǒng)計(jì)劃：包含項(xiàng)目標(biāo)提出和可行性分析、系統(tǒng)方案制訂、評(píng)價(jià)和改進(jìn)、新舊系統(tǒng)分析與比較、現(xiàn)有軟、硬件和數(shù)據(jù)資源有效利用等。(2)軟件架構(gòu)設(shè)計(jì)：包含軟件架構(gòu)概念、軟件架構(gòu)與設(shè)計(jì)、架構(gòu)格調(diào)、特定領(lǐng)域架構(gòu)格調(diào)、基于架構(gòu)軟件開發(fā)方法、架構(gòu)評(píng)定、軟件產(chǎn)品線和系統(tǒng)演化等。(3)設(shè)計(jì)模式：包含設(shè)計(jì)模式概念、組成、分類和實(shí)現(xiàn)、模式和軟件架構(gòu)關(guān)系等。(4)系統(tǒng)設(shè)計(jì)：包含處理流程設(shè)計(jì)、人機(jī)界面設(shè)計(jì)、文件與存放設(shè)計(jì)、數(shù)據(jù)庫設(shè)計(jì)、網(wǎng)絡(luò)應(yīng)用系統(tǒng)設(shè)計(jì)、系統(tǒng)運(yùn)行環(huán)境集成與設(shè)計(jì)、中間件與應(yīng)用服務(wù)器、性能設(shè)計(jì)與性能評(píng)定等。(5)軟件建模：包含定義問題與歸結(jié)模型、結(jié)構(gòu)化系統(tǒng)建模與數(shù)據(jù)流圖、面向?qū)ο笙到y(tǒng)建模、數(shù)據(jù)庫建模和逆向工程等。

第20頁20(6)分布式系統(tǒng)設(shè)計(jì)：包含分布式通信協(xié)議設(shè)計(jì)、基于對(duì)象與web分布式設(shè)計(jì)、基于消息和協(xié)同分布式設(shè)計(jì)和異構(gòu)分布式系統(tǒng)互操作性設(shè)計(jì)等。(7)嵌入式系統(tǒng)設(shè)計(jì)：包含實(shí)施任務(wù)調(diào)度和多任務(wù)設(shè)計(jì)、中止處理和異常處理、嵌入式系統(tǒng)開發(fā)設(shè)計(jì)等。(8)系統(tǒng)可靠性分析與設(shè)計(jì)：包含系統(tǒng)故障模型和可靠性模型、系統(tǒng)可靠性分析與可靠度計(jì)算、提升系統(tǒng)可靠性辦法、系統(tǒng)故障對(duì)策和系統(tǒng)備份與恢復(fù)等。(9)系統(tǒng)安全性和保密性設(shè)計(jì)：包含系統(tǒng)訪問控制技術(shù)、數(shù)據(jù)完整性、數(shù)據(jù)與文件加密、通信安全和系統(tǒng)安全設(shè)計(jì)等。(10)復(fù)雜架構(gòu)設(shè)計(jì)：包含操作系統(tǒng)架構(gòu)、編譯器架構(gòu)和大型基礎(chǔ)庫架構(gòu)等。第21頁21軟件架構(gòu)師任職條件依據(jù)軟件架構(gòu)師職責(zé)和角色定位，以及知識(shí)體系，從實(shí)踐角度考慮，合格軟件架構(gòu)師應(yīng)該含有以下能力和經(jīng)驗(yàn)：(1)含有8年以上軟件項(xiàng)目開發(fā)實(shí)際工作經(jīng)驗(yàn)，其中最少有3年以上代碼編寫工作經(jīng)驗(yàn)，4年以上基于面向?qū)ο蠛蜆?gòu)件開發(fā)方法軟件產(chǎn)品設(shè)計(jì)經(jīng)驗(yàn)。(2)含有5個(gè)以上大中型開發(fā)項(xiàng)目標(biāo)總體規(guī)劃、方案設(shè)計(jì)經(jīng)驗(yàn)，有大中型應(yīng)用系統(tǒng)開發(fā)和實(shí)施成功案例。(3)對(duì)相關(guān)技術(shù)標(biāo)準(zhǔn)有深刻認(rèn)識(shí)，對(duì)軟件工程標(biāo)準(zhǔn)和規(guī)范有良好把握。(4)對(duì).Net或Java技術(shù)及整個(gè)處理方案有深刻了解及熟練應(yīng)用，精通WebService，熟練掌握流行架構(gòu)。第22頁22(5)對(duì)設(shè)計(jì)模式有深刻了解，并能在此基礎(chǔ)上設(shè)計(jì)出適合產(chǎn)品特征和質(zhì)量屬性框架。(6)含有面向?qū)ο蠓治?、設(shè)計(jì)和開發(fā)能力，精通UML和XML，能熟練使用RationalRose、PowerDesigner等工具進(jìn)行設(shè)計(jì)。(7)含有良好團(tuán)體意識(shí)和協(xié)作精神，有較強(qiáng)溝通能力和書面表示能力。(8)含有旺盛精力和學(xué)習(xí)能力，能快速掌握新技術(shù)和新方法。

第23頁23第二單元：技術(shù)架構(gòu)視圖─面向?qū)ο蟪绦蛟O(shè)計(jì)標(biāo)準(zhǔn)與模式第24頁24第25頁25第26頁26用GRASP模式指導(dǎo)設(shè)計(jì)第27頁27第28頁28第29頁29第30頁30第31頁31第32頁32第33頁33第34頁34第35頁35第36頁36第37頁37第38頁38第39頁39第40頁40第41頁41第42頁42第43頁43第44頁44第45頁45第46頁46領(lǐng)域模型第47頁47層次結(jié)構(gòu)領(lǐng)域模型從EJB到輕量級(jí)框架第48頁48層次結(jié)構(gòu)表現(xiàn)層（present）業(yè)務(wù)層業(yè)務(wù)層外觀業(yè)務(wù)層關(guān)鍵領(lǐng)域?qū)ο蠊芾?服務(wù)/倉庫層領(lǐng)域?qū)ο髮映志脤訑?shù)據(jù)訪問層數(shù)據(jù)庫第49頁49領(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ì)象--沒有標(biāo)識(shí)沒有行為。如Address類。工廠---定義創(chuàng)建實(shí)體方法，封裝實(shí)例化對(duì)象并將一些關(guān)聯(lián)對(duì)象注入。倉庫(repository)管理實(shí)體集合,主要有查找和刪除實(shí)體方法.實(shí)現(xiàn)類能夠調(diào)用執(zhí)久化層(如Hibernate，Ibatis)服務(wù)(Service)，實(shí)現(xiàn)整個(gè)應(yīng)用程序工作流(workflow)。服務(wù)包含那些無法指派單個(gè)實(shí)體行為，由作用于多個(gè)對(duì)象方法組成。如能夠調(diào)用repository查找到實(shí)體對(duì)象，然后委派給這些對(duì)象。服務(wù)和facade很像，但不一樣，它不處理以下事情：1）執(zhí)行事務(wù)。2）搜集返回給表現(xiàn)層數(shù)據(jù)。3）脫鉤對(duì)象。4）其它事情。服務(wù)能夠說是業(yè)務(wù)協(xié)調(diào)者，業(yè)務(wù)邏輯能夠分散到實(shí)體對(duì)象中。第50頁50領(lǐng)域模型失血模型貧血模型充血模型脹血模型第51頁51失血模型DO只有屬性及其getter/setter方法，沒有任何業(yè)務(wù)邏輯。缺點(diǎn)：行為與數(shù)據(jù)分離，很多情況造成維護(hù)與了解困難。第52頁52貧血模型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層過重。第53頁53充血模型與貧血模型類似，不一樣處于于怎樣劃分業(yè)務(wù)邏輯：絕大多業(yè)務(wù)邏輯都應(yīng)該放在DO里(包含持久化邏輯)，而Service層很薄，僅僅封裝事務(wù)和少許邏輯，不和DAO層打交道。Service(事務(wù)封裝)DODAO優(yōu)點(diǎn)：符合OOService層很薄，只充當(dāng)Facade角色，不和DAO打交道。第54頁54缺點(diǎn)：DAO和DO雙向依賴。怎樣劃分Service層邏輯和Domain層邏輯沒有確定規(guī)則，取決與設(shè)計(jì)人員自己了解。Service層封裝事務(wù)，須對(duì)全部DO邏輯提供對(duì)應(yīng)事務(wù)封裝方法，造成重定義全部Domainlogic。Service事務(wù)化封裝意義等于把OODomainlogic轉(zhuǎn)換為過程Service事務(wù)腳本。充血模型在domain層實(shí)現(xiàn)OO在Service層又變成了面向過程。第55頁55脹血模型取消Service層，只剩下DO和DAO層，在DOdomainlogic上面封裝事務(wù)。DO(事務(wù)封裝，業(yè)務(wù)邏輯)DAO(RoR甚至合并為一層）

優(yōu)點(diǎn)：分層簡(jiǎn)化符合OO缺點(diǎn)：service邏輯也強(qiáng)行放入DO，引發(fā)了DO不穩(wěn)定。DO暴露給web層過多信息，可能引發(fā)無須要耦合。第56頁56標(biāo)準(zhǔn)：業(yè)務(wù)對(duì)象封裝了內(nèi)在業(yè)務(wù)邏輯，而應(yīng)用服務(wù)封裝了外在于業(yè)務(wù)對(duì)象業(yè)務(wù)邏輯。第57頁57EJB到輕量級(jí)框架EJBPOJO（業(yè)務(wù)邏輯）+輕量級(jí)框架（[Hibernate、JDO、iBATIS]（持久化）、Spring（事務(wù)管理、安全））第58頁58EJBEJB：編寫分布式業(yè)務(wù)應(yīng)用程序Java標(biāo)準(zhǔn)架構(gòu)。提供大量服務(wù)：申明型事務(wù),EIB容器自動(dòng)開啟、提交和回滾事務(wù)。業(yè)務(wù)邏輯能參加由遠(yuǎn)程客戶發(fā)起分布式事務(wù)。提供申明型安全，大部分情況下不再搖要編寫安全代碼求（bean布署描述符里條目指定準(zhǔn)能夠防問某個(gè)詳細(xì)bean）。第59頁59例：在兩個(gè)賬號(hào)間進(jìn)行轉(zhuǎn)賬服務(wù)。第60頁60POJO（業(yè)務(wù)邏輯）+Hiibernate、JDO、iBATIS（持久化）、Spring（事務(wù)管理、安全）。┏━━━━━━━━━┳━━━━━━━━━━━━━━━┳━━━━━━━┓┃┃經(jīng)典EJB方法┃POJO方法┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━╋━━━━━━━┫┃組織┃過程式業(yè)務(wù)邏輯┃面向?qū)ο笤O(shè)計(jì)┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━╋━━━━━━━┫┃實(shí)現(xiàn)┃基于EJB┃POJO┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━┻━━━━━━━┫┃數(shù)據(jù)庫訪問┃JDBC/SQL或?qū)嶓wbean ┃持久層框架┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━┳━━━━━━━┫┃返回給表示層數(shù)據(jù)┃DTO┃業(yè)務(wù)對(duì)象┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━╋━━━━━━━┫┃事務(wù)管理┃EJB容器管理事務(wù)┃Spring框架┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━╋━━━━━━━┫┃應(yīng)用程序組裝┃顯式JNDI查詢┃依賴注入┃┗━━━━━━━━━┻━━━━━━━━━━━━━━━┻━━━━━━━┛第61頁61新設(shè)計(jì)是面向?qū)ο?、基于POJO,而非基于EJB過程式。它使用構(gòu)建在JDBC上持久層框架來訪問數(shù)據(jù)庫,并不直接使用JDBC。業(yè)務(wù)邏輯由POJOfacade而非會(huì)話bean進(jìn)行封裝。事務(wù)由Spring框架而非EJB容器進(jìn)行管理。業(yè)務(wù)邏輯向表現(xiàn)層返回實(shí)際業(yè)務(wù)對(duì)象,而不是DTO。應(yīng)用程序經(jīng)過將組件依賴作為setter或結(jié)構(gòu)子參數(shù)傳入來進(jìn)行組裝,而不是之前采取Java命名和目錄接口(JNDI)查詢組件。因?yàn)樵撛O(shè)計(jì)面向?qū)ο?并采取上述輕量級(jí)技術(shù),所以較之前看到EJB版本對(duì)開發(fā)人員要友好。第62頁62基于輕量級(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種種好處。第63頁63第64頁64面向?qū)ο髢?yōu)點(diǎn)：整個(gè)設(shè)計(jì)更易了解和維護(hù)。它并不是一個(gè)無所不能大型類,而是由大量小類組成,每個(gè)類只共有若干職責(zé)。另外,諸如Account、BankingTransaction和OverdraftPolicy類都與現(xiàn)實(shí)世界概念對(duì)應(yīng),所以易于了解。其次,面向?qū)ο笤O(shè)汁也更易測(cè)試:全部類都能而且應(yīng)該進(jìn)行獨(dú)立測(cè)試。EJB只能經(jīng)過調(diào)用它public方法如Transter進(jìn)行測(cè)試,難度大。(只能測(cè)試p-blic方法暴露復(fù)雜功效,無法測(cè)試其中簡(jiǎn)單部分）。面向?qū)ο笙笤O(shè)計(jì)更易擴(kuò)展,它可使用設(shè)計(jì)模式，如Stategy和Template等。EJB格調(diào)過程式設(shè)計(jì)往往需耍修改關(guān)鍵代碼。第65頁65不適適用面向?qū)ο髨?chǎng)所：大量數(shù)據(jù)集合關(guān)系操作。以數(shù)據(jù)庫為中心管理程序：這個(gè)領(lǐng)域所對(duì)應(yīng)現(xiàn)實(shí)世界是一個(gè)面向關(guān)系世界，表與表關(guān)聯(lián)表達(dá)是彼此業(yè)務(wù)關(guān)系。復(fù)雜SQL當(dāng)然不好維護(hù)，但業(yè)務(wù)真是復(fù)雜到簡(jiǎn)單SQL都難以描述程度，采取面向?qū)ο竺枋鰟t愈加困難，維護(hù)也更困難，同時(shí)還損失了效率。比較大事務(wù)。性能要求高地方。（直接用Sql或者存放過程；犧牲可維護(hù)性和可復(fù)用性）上層流程。第66頁66消除DTO第67頁67布署POJO程序第68頁68第69頁69第70頁70面向?qū)ο笤O(shè)計(jì)基本標(biāo)準(zhǔn)第71頁71第72頁72liskov替換標(biāo)準(zhǔn)（LSP）第73頁73子類型必須能夠替換掉其基類型問題根源是關(guān)于行為：基類中有行為在子類中不存在或不適當(dāng)。ISA本質(zhì)是指行為一致，而不是生活中語言。違反了LSP標(biāo)準(zhǔn)本質(zhì)是派生類行為與基類中不一致。假如違反了LSP標(biāo)準(zhǔn)，常會(huì)造成在運(yùn)行時(shí)類型判斷(RTTI)違反OCP標(biāo)準(zhǔn)。比如：函數(shù)A參數(shù)是基類型，調(diào)用時(shí)傳遞對(duì)象是子類型，正常情況下，增加子類型都不會(huì)影響到函數(shù)A，假如違反了LSP，則函數(shù)A必須小心判斷傳進(jìn)來詳細(xì)類型，不然就會(huì)犯錯(cuò)，這就已經(jīng)違反了OCP標(biāo)準(zhǔn)。第74頁74違反LSP造成違反OCP簡(jiǎn)單例子第75頁75改進(jìn)第76頁76例：會(huì)議管理系統(tǒng)第77頁77例：GUI對(duì)象假定一個(gè)Component代表一個(gè)GUI對(duì)象，如按鈕或者文本框等。第78頁78第79頁79第80頁80改進(jìn)2第81頁81例第82頁82接口隔離標(biāo)準(zhǔn)（ISP）康凱第83頁83例第84頁84使用委托分離接口第85頁85使用多重繼承分離接口第86頁86內(nèi)接口與外接口第87頁87普通接口與智能接口第88頁88軟件系統(tǒng)壞死癥狀第89頁89“Copy”程序一個(gè)從鍵盤讀入字符并輸出到打印機(jī)程序。voidCopy(){ intc; while((c=RdKbd())!=EOF) WrtPtr(c);}第90頁90需求在改變用戶希望Copy程序能從紙帶讀入機(jī)中讀入信息?，F(xiàn)實(shí)中約束－－不能改變接口Copy程序第一次修改結(jié)果boolptFlag=false;//remembertoresetthisflagvoidCopy(){ intc; while((c=(ptFlag?Rdpt():Rdkbd()))!=EOF) WrtPtr(c);}第91頁91需求在改變2客戶希望Copy程序有時(shí)能夠輸出到紙帶穿孔機(jī)上。//Copy程序第二次修改結(jié)果boolptFlag=false;boolpunchFlag=false;//remembertoresettheseflagvoidCopy(){ intc; while((c=(ptFlag?Rdpt():Rdkbd()))!=EOF) punchFlag?WrtPunch(c):WrtPtr(c);}第92頁92依賴倒置標(biāo)準(zhǔn)（DIP）康凱第93頁93相關(guān)概念關(guān)于解耦依賴倒置（DIP）控制反轉(zhuǎn)（IoC）依賴注入（DI）服務(wù)定位器（SL）有些是伎倆，有些是標(biāo)準(zhǔn)，不過其間差異并不太主要，更主要是其共同點(diǎn)：其根本目標(biāo)都是解除依賴，將組件配置與使用分離開。其它名詞服務(wù)組件框架類庫應(yīng)用程序第94頁94接口和實(shí)現(xiàn)分離

面向過程接口與實(shí)現(xiàn)分離第95頁95第96頁96第97頁97第98頁98電影清單例子一個(gè)組件，用于提供一份電影清單，清單上列出影片都是由一位特定導(dǎo)演執(zhí)導(dǎo)。classMovieLister{...publicMovie[]moviesDirectedBy(Stringarg){ListallMovies=finder.findAll();for(Iteratorit=allMovies.iterator();it.hasNext();){Moviemovie=(Movie)it.next();if(!movie.getDirector().equals(arg))it.remove();}return(Movie[])allMovies.toArray(newMovie[allMovies.size()]);}}第99頁99其中真正想要考查是怎樣將MovieLister對(duì)象與特定finder對(duì)象連接起來。要求：我們希望moviesDirectedBy方法完全不依賴于影片實(shí)際存放方式。這個(gè)方法只能引用一個(gè)finder對(duì)象，而finder對(duì)象必須知道怎樣實(shí)現(xiàn)findAll細(xì)節(jié)。給finder定義一個(gè)接口：publicinterfaceMovieFinder {ListfindAll();}當(dāng)要實(shí)際尋找影片時(shí)，就必須包括到MovieFinder某個(gè)詳細(xì)子類。在這里，我把“包括詳細(xì)子類”代碼放在MovieLister類結(jié)構(gòu)函數(shù)中。第100頁100反抗改變從一個(gè)逗號(hào)分隔文本文件中取得影片列表。classMovieLister...privateMovieFinderfinder;publicMovieLister(){finder=newColonDelimitedMovieFinder("movies1.txt");}反抗改變：文件清單名字更改：能夠從一個(gè)配置文件取得文件名。假如用SQL數(shù)據(jù)庫、XML文件、webservice，或者另一個(gè)格式文本文件來存放影片清單：用另一個(gè)詳細(xì)類來獲取數(shù)據(jù)。該類從MovieFinder接口派生即可。創(chuàng)建適當(dāng)MovieFinder派生類實(shí)例：不能反抗此改變。第101頁101配置文件設(shè)定配置文件：XML文件是比較理想配置方式。<beans><beanid="MovieLister"class="spring.MovieLister"><propertyname="finder"><reflocal="MovieFinder"/></property></bean><beanid="MovieFinder"class="spring.ColonMovieFinder"><propertyname="filename"><value>movies1.txt</value></property></bean></beans>第102頁102第三單元：用UML輔助系統(tǒng)分析與設(shè)計(jì)第103頁103UML介紹及常見疑難問題辨析

第104頁104UML用來描述模型內(nèi)容有3種,分別是事物(Things)、關(guān)系Relationships)和圖(Diagrams)。第105頁105UML中關(guān)系UML中關(guān)系(Relationships)主要包含4種:1、關(guān)聯(lián)關(guān)系2、依賴(Dependency)關(guān)系3、泛化(Generalization)關(guān)系4、實(shí)現(xiàn)(Realization)關(guān)系第106頁106一些常見問題辨析類層次結(jié)構(gòu)表示屬性與聚合關(guān)聯(lián)角色關(guān)聯(lián)類第107頁107層次結(jié)構(gòu)第108頁108領(lǐng)域建模－重?cái)?shù)第109頁109細(xì)化類模型第110頁110關(guān)聯(lián)角色關(guān)聯(lián)角色名出現(xiàn)在關(guān)聯(lián)終端旁邊。當(dāng)僅僅使用關(guān)聯(lián)名不足夠表示清楚后，能夠用關(guān)聯(lián)角色名來加強(qiáng)表示。能夠把每個(gè)名稱都當(dāng)成偽屬性，關(guān)聯(lián)角色名提供了一個(gè)能夠遍歷關(guān)聯(lián)方法。第111頁111

在創(chuàng)建類圖時(shí)，應(yīng)該為使用正確角色名，而不是為每個(gè)引用引入一個(gè)獨(dú)立類。因?yàn)榻巧軌騾^(qū)分對(duì)象，所以附在一個(gè)類上關(guān)聯(lián)名必須唯一（能夠把角色名想象成類偽屬性）。一樣，角色名不應(yīng)該與類屬性名重復(fù)。第112頁112關(guān)聯(lián)類正如能夠用屬性描述類對(duì)象一樣，也能夠用屬性來描述關(guān)聯(lián)鏈接，能夠把這么一組屬性組成關(guān)聯(lián)類。第113頁113Actor一些注意事項(xiàng)包含人與系統(tǒng)，總是外部。定義了邊界。Actor是“角色”，不是特定人或特定事。要有恰當(dāng)名字。能夠泛化不是可有可無東西。另首先它能夠劃分系統(tǒng)與外部實(shí)體界限，是系統(tǒng)設(shè)計(jì)起點(diǎn)。第114頁114用例一些注意事項(xiàng)是需求分析第一步。用戶首先關(guān)心功效。用例是對(duì)一個(gè)系統(tǒng)或一個(gè)應(yīng)用一個(gè)單一使用方式所作描述,是關(guān)于單個(gè)活動(dòng)者在與系統(tǒng)對(duì)話中所執(zhí)行處理行為陳說序列。不是事件流。不是需求規(guī)格說明，但反應(yīng)了主要功效性需求。識(shí)別用例最好是從分析流開始。每個(gè)用例都是獨(dú)立。用例名用動(dòng)賓結(jié)構(gòu)描述，不要寫成一個(gè)名詞。用例是分層，普通而言，高層/中層用例更有實(shí)際意義。不要將不一樣用例混合在一起。用例與編碼：低層用例能夠輔助編碼，高層不能。擴(kuò)展用例：基礎(chǔ)用例無須知道擴(kuò)展用例細(xì)節(jié)，只提供擴(kuò)展點(diǎn)。第115頁115倉庫信息系統(tǒng)用例圖第116頁116借鑒RUPUML建模與分析

第117頁117全局分析全局分析側(cè)重于定義擬建系統(tǒng)所采取構(gòu)架以及影響構(gòu)架要素。全局分析充分利用相同或問題中經(jīng)驗(yàn)，防止在確定構(gòu)架上浪費(fèi)人力和物力。選取架構(gòu)模式識(shí)別關(guān)鍵抽象：尋找那些不論在問題域或方案領(lǐng)域都含有普遍意義概念點(diǎn)。標(biāo)識(shí)分析機(jī)制：將那些問題領(lǐng)域（應(yīng)用邏輯）沒有直接關(guān)聯(lián)計(jì)算機(jī)概念及對(duì)應(yīng)復(fù)雜行為表述為支撐分析工作“占位符”。選定分析局部：針對(duì)擬建系統(tǒng)整體架構(gòu)，找出那些蘊(yùn)含相對(duì)高風(fēng)險(xiǎn)局部作為工作內(nèi)容。第118頁118全局分析常見分析機(jī)制

留存

分布式處理

安全性

進(jìn)程間通信

消息路由

進(jìn)程控制與同時(shí)

交易事務(wù)管理

信息交換

信息冗余

錯(cuò)誤檢測(cè)、處理和匯報(bào)

數(shù)據(jù)格式轉(zhuǎn)換第119頁119局部分析提取分析類轉(zhuǎn)述需求場(chǎng)景整理分析類第120頁120局部分析分析類類型劃分

眾多實(shí)踐表明，假如立足于軟件功效需求，擬建系統(tǒng)往往在三個(gè)維度易于發(fā)生改變：一、擬建系統(tǒng)和外部要素之間交互邊界；第二，擬建系統(tǒng)要統(tǒng)計(jì)和維護(hù)信息；第三，擬建系統(tǒng)在運(yùn)行中控制邏輯。通常按照這三個(gè)改變?cè)蚓S度，將分析類劃分為三種類型：邊界類、控制類、實(shí)體類系統(tǒng)邊界UseCase行為協(xié)調(diào)基本信息第121頁121局部分析第122頁122局部分析第123頁123局部分析第124頁124局部分析整理分析類

分析類是這么類：它代表問題域中簡(jiǎn)練抽象；分析類映射到真實(shí)世界業(yè)務(wù)概念（而且據(jù)此仔細(xì)命名）。問題域是首先產(chǎn)生軟件系統(tǒng)（以及從此而來軟件開發(fā)活動(dòng)）需求域。通常，這是特定業(yè)務(wù)領(lǐng)域，如在線銷售或者客戶關(guān)系管理。然而，務(wù)必注意，問題域可能根本不是任何特定業(yè)務(wù)活動(dòng)，但是可能產(chǎn)生需要軟件在其上運(yùn)轉(zhuǎn)一塊物理硬件─這是嵌入式系統(tǒng)?；旧?，全部業(yè)務(wù)軟件開發(fā)服務(wù)于某種業(yè)務(wù)需求，自動(dòng)化一個(gè)已經(jīng)有業(yè)務(wù)過程或者開發(fā)含有有意義軟件組件新產(chǎn)品。第125頁125分析類職責(zé)職責(zé)是類和它客戶之間契約或者是類對(duì)它客戶義務(wù)。本質(zhì)上，職責(zé)是類提供給其它類服務(wù)。分析類含有直接同類（由它名稱所表示）目標(biāo)相一致以及直接同該類正在建模真實(shí)世界“事物”相一致非常內(nèi)聚職責(zé)集合，這一點(diǎn)是至關(guān)主要。比如ShoppingBasket示例，你將期望該類含有以下職責(zé)：向購物籃添加商品；從購物籃刪除商品；顯示購物籃中商品。這是內(nèi)聚職責(zé)集合，一切都是為了維護(hù)客戶選擇商品集合。它是內(nèi)聚，因?yàn)槿柯氊?zé)都朝著相同目標(biāo)─維護(hù)客戶已經(jīng)選擇商品集合。實(shí)際上，我們能夠把這些職責(zé)概括為非常高級(jí)層次職責(zé)“維護(hù)購物籃”。一樣，向ShoppingBasket中添加以下職責(zé)：第126頁126分析類職責(zé)驗(yàn)證信用卡；接收付款；打印收據(jù)。但這些職責(zé)似乎同購物籃目標(biāo)或直覺語法不匹配。它們不是內(nèi)聚，顯然應(yīng)該賦予其它什么類─可能是類CreditCardCompany、類Checkout以及類ReceiptPrinter。把職責(zé)適當(dāng)?shù)胤峙浣o分析類以最大化每個(gè)類中內(nèi)聚性，是很主要。最終，良好類與其它類之間含有最低數(shù)目標(biāo)耦合。我們以給定類與其它類具相關(guān)系數(shù)目來度量類間耦合度。類間職責(zé)平均分布趨向于產(chǎn)生低耦合度。把控制或職責(zé)局限于單一類趨向于增加到該類耦合度。第127頁127分析類經(jīng)驗(yàn)法則以下是創(chuàng)建形式良好分析類一些經(jīng)驗(yàn)法則。每個(gè)類大約3~5個(gè)職責(zé)─經(jīng)典地，類應(yīng)該保持盡可能簡(jiǎn)單，這通常限制類能夠支持3~5個(gè)職責(zé)數(shù)目。先前ShoppingBasket示例是帶有小和可管理數(shù)目職責(zé)專注類好示例。不存在獨(dú)立類─好OO分析和設(shè)計(jì)精華是，類相互協(xié)作讓用戶受益。一樣，每個(gè)類應(yīng)該同小部分類協(xié)作以提供所期望功效。類能夠把它們一些職責(zé)托付給專注于特定功效其它“輔助”類。當(dāng)心很多非常小類─有時(shí)極難取得正確平衡。假如模型看起來含有大量非常小類，每個(gè)類都含有一個(gè)或者兩個(gè)職責(zé)，那么你應(yīng)該仔細(xì)查看以把一些小類整合成更大類。第128頁128當(dāng)心少數(shù)幾個(gè)非常龐大類─上述反面是，模型含有極少類，但每個(gè)類都是含有職責(zé)數(shù)量（>5）龐大類。處理問題策略是依次查看這些類，看看是否每個(gè)類都能夠被分解成為兩個(gè)或者多個(gè)能夠負(fù)擔(dān)恰當(dāng)數(shù)目職責(zé)、更小類。當(dāng)心“偽類”─偽類其實(shí)是普通過程函數(shù)，它偽裝成類。當(dāng)心萬能類─存在似乎能夠負(fù)擔(dān)任何工作類?？纯疵Q為“system”和“controller”類！處理這個(gè)問題策略是看看萬能類職責(zé)是否能夠分解成內(nèi)聚子集。假如是，每個(gè)這些內(nèi)聚職責(zé)集合可能獨(dú)立成類。這些更小類協(xié)作以實(shí)現(xiàn)由原始萬能類所提供行為。第129頁129分析類經(jīng)驗(yàn)法則防止深度繼承樹─設(shè)計(jì)良好繼承層次本質(zhì)是繼承層次中每個(gè)抽象層次應(yīng)該含有良好定義目標(biāo)。輕易添加很多實(shí)際上不能服務(wù)于任何目標(biāo)層次。實(shí)際上，通常錯(cuò)誤是使用繼承來實(shí)現(xiàn)一個(gè)功效分解，其中每個(gè)抽象層次恰有一個(gè)職責(zé)！不論從哪個(gè)方面來講，這都是無意義，是會(huì)造成復(fù)雜、難以了解模型。在分析中，類代表業(yè)務(wù)事物，而業(yè)務(wù)事物趨向于形成更寬（不超出三層）繼承層次。我們把三層或者更多層次繼認(rèn)可為是“深度”繼承。第130頁130第四單元：設(shè)計(jì)模式與軟件設(shè)計(jì)思想第131頁131設(shè)計(jì)模式第132頁132設(shè)計(jì)模式在實(shí)際開發(fā)中利用復(fù)用現(xiàn)有、高質(zhì)量、針對(duì)常見重復(fù)出現(xiàn)問題處理方案。建立通用術(shù)語以改進(jìn)團(tuán)體內(nèi)部溝通。將思索轉(zhuǎn)移到更高視角。判斷是否擁有正確設(shè)計(jì)，而不但僅使一個(gè)能夠運(yùn)行設(shè)計(jì)。改進(jìn)代碼可修改性。發(fā)覺“龐大繼承體系”替換方案。第133頁133GoF中模式分類第134頁134設(shè)計(jì)模式特點(diǎn)設(shè)計(jì)模式最根本意圖是適應(yīng)需求改變隔離改變部分與不變部分，將之封裝起來。針對(duì)接口編程，而不要針對(duì)實(shí)現(xiàn)編程達(dá)成高內(nèi)聚合低耦合，提升復(fù)用提倡優(yōu)先使用聚合，而不是繼承第135頁135例一個(gè)日志統(tǒng)計(jì)工具。當(dāng)前需要提供一個(gè)日志API，提供客戶方便地調(diào)用。該日志要求被統(tǒng)計(jì)到指定文本文件中，統(tǒng)計(jì)內(nèi)容屬于字符串類型，其值由客戶提供。能夠輕易地定義一個(gè)日志對(duì)象。publicclassLog{ publicvoidWrite(stringtarget,stringlog){ //實(shí)現(xiàn)內(nèi)容;}}當(dāng)客戶需要調(diào)用日志功效時(shí)，能夠創(chuàng)建日志對(duì)象，完成日志統(tǒng)計(jì)：Loglog=newLog();log.Write(“error.log”,“l(fā)og”);第136頁136第137頁137第138頁138例我們需要設(shè)計(jì)一個(gè)數(shù)據(jù)庫組件，它能夠訪問SqlServer數(shù)據(jù)庫。假如用ADO.Net，需要使用以下對(duì)象：SqlConnection,SqlCommand,SqlDataAdapter等。不用模式做法：能夠直接創(chuàng)建這些對(duì)象：SqlConnectionconnection=new SqlConnection(strConnection);SqlCommandcommand=newSqlCommand(connection);SqlDataAdapteradapter=newSqlDataAdapter();第139頁139Connection對(duì)象：第140頁140第141頁141策略（Strategy）模式第142頁142練習(xí)下面是一堆雜亂類與接口：

動(dòng)作冒險(xiǎn)游戲。包含代表游戲角色類，以及武器行為類。每個(gè)角色一次只能使用一個(gè)武器，不過能夠在游戲過程中換武器。任務(wù)：1.安排類。2.找出一個(gè)抽象類、一個(gè)接口、以及八個(gè)類。3.在類之間畫箭頭。A.繼承。B.實(shí)現(xiàn)接口。C.「有一個(gè)」關(guān)系。4.把setWeapon()方法放到正確類中。第143頁143原始類與接口第144頁144例：電子零售系統(tǒng)該電子零售系統(tǒng)必須處理來自不一樣國(guó)家銷售定單。比如在美國(guó)與加拿大。需求以下：請(qǐng)況過程美國(guó)據(jù)UPS價(jià)格計(jì)算運(yùn)費(fèi)使用美國(guó)郵政規(guī)則檢驗(yàn)地址依據(jù)銷售額或服務(wù),按照當(dāng)?shù)囟愂找?guī)則計(jì)算稅費(fèi)金額使用美元處理款項(xiàng)加拿大依據(jù)主要加拿大托運(yùn)企業(yè)價(jià)格計(jì)算運(yùn)費(fèi)使用加拿大郵政規(guī)則檢驗(yàn)地址依據(jù)銷售額或服務(wù),按照加拿大各省稅收規(guī)則計(jì)算稅費(fèi)金額(GST和PST)使用加拿大元處理款項(xiàng)第145頁145分析矩陣第146頁146橋接（Bridge）模式第147頁147意圖“將抽象部分與它實(shí)現(xiàn)部分分離，使它們都能夠獨(dú)立地改變”。抽象部分是指“不一樣事物在概念層次上聯(lián)絡(luò)”。分離是指“讓各部分行為各自獨(dú)立，或最少顯式指出關(guān)聯(lián)”。第148頁148例經(jīng)過引入一個(gè)Rectangle抽象類，利用了這一事實(shí)：不一樣Rectangle派生類之間唯一差異是如何實(shí)現(xiàn)drawLine方法。V1Rectangle類實(shí)現(xiàn)方式是：保留一個(gè)DP1對(duì)象引用，使用DP1對(duì)象draw_a_line方法。V2Rectangle類實(shí)現(xiàn)方法是：保留一個(gè)DP2對(duì)象引用，使用這個(gè)對(duì)象drawline方法。第149頁149需求改變用戶要求支持另一個(gè)形狀——圓形。第150頁150識(shí)別改變首先識(shí)別出“什么在發(fā)生改變”。在上述例子中，改變點(diǎn)是“不一樣類型形狀”和“不一樣類型畫圖程序”。共同“概念”則是“形狀”和“畫圖程序”。用Shape類來封裝擁有形狀概念。形狀有責(zé)任知道怎樣畫自己。Drawing對(duì)象負(fù)責(zé)畫線和圓。第151頁151描述改變下一步是描述出現(xiàn)特定改變：Shape類擁有矩形和圓形。畫圖程序分別擁有一個(gè)基于DP1對(duì)象（V1Drawing）和一個(gè)基于DP2對(duì)象（V2Drawing）。第152頁152橋接模式第153頁153觀察者（observer）模式康凱第154頁154第155頁155命令（command）模式康凱第156頁156意圖將一個(gè)請(qǐng)求封裝為一個(gè)對(duì)象，從而使你可用不一樣請(qǐng)求對(duì)客戶進(jìn)行參數(shù)化；對(duì)請(qǐng)求排隊(duì)或統(tǒng)計(jì)請(qǐng)求日志，以及支持可撤消操作。別名動(dòng)作(Action)，事務(wù)(Transaction)動(dòng)機(jī)有時(shí)必須向某對(duì)象提交請(qǐng)求，但并不知道關(guān)于被請(qǐng)求操作或請(qǐng)求接收者任何信息。比如，用戶界面工具箱包含按鈕和菜單這么對(duì)象，它們執(zhí)行請(qǐng)求響應(yīng)用戶輸入。但工具箱不能顯式在按鈕或菜單中實(shí)現(xiàn)該請(qǐng)求，因?yàn)橹挥惺褂霉ぞ呦鋺?yīng)用知道該由哪個(gè)對(duì)象做哪個(gè)操作。而工具箱設(shè)計(jì)者無法知道請(qǐng)求接收者或執(zhí)行操作。命令模式經(jīng)過將請(qǐng)求本身變成一個(gè)對(duì)象來使工具箱對(duì)象可向未指定應(yīng)用對(duì)象提出請(qǐng)求。這個(gè)對(duì)象可被存放并像其它對(duì)象一樣被傳遞。這一模式關(guān)鍵是一個(gè)抽象Command類。第157頁157例子第158頁158結(jié)構(gòu)第159頁159其它設(shè)計(jì)模式第160頁160VISITOR模式該系列中模式以下:VISlTOR模式ACYCLICVISITOR模式DECORATOR模式EXTENSIONOBJECT模式第161頁161例是一個(gè)常見問題：比如,有一個(gè)Modem對(duì)象層次結(jié)構(gòu)?；愔杏腥空{(diào)制解調(diào)器公共方法。派生類代表不一樣調(diào)制解調(diào)器類型驅(qū)動(dòng)程序。第162頁162問題假設(shè)需要向該層次結(jié)構(gòu)中增加一個(gè)新方法confrgureForUnix。使之可在UNIX下工作。在每個(gè)調(diào)制解調(diào)器派生類中該函數(shù)實(shí)現(xiàn)都不相同。（假設(shè)每個(gè)不一樣調(diào)制解調(diào)器在UNIX中都有自己獨(dú)特配置方法和行為特征）。問題：直接增加configureForUnix方法其實(shí)回避了一個(gè)問題：對(duì)于Windows怎樣處理?MacOS?Linux?必須針對(duì)所使用每一個(gè)新操作系統(tǒng)都要向Modem層次結(jié)構(gòu)中增加一個(gè)新方法?這種做法是丑陋：我們永遠(yuǎn)無法封閉Modem接口。每當(dāng)出現(xiàn)一個(gè)新操作系統(tǒng)時(shí),就必須更改該接口并重新布署全部調(diào)制解調(diào)器軟件。第163頁163VISITOR模式結(jié)構(gòu)第164頁164VISITOR＋組合模式VISTTOR模式一個(gè)非經(jīng)常見應(yīng)用是,遍歷大量數(shù)據(jù)結(jié)構(gòu)并產(chǎn)生報(bào)表。這使得數(shù)據(jù)結(jié)構(gòu)對(duì)象中不含有任何產(chǎn)生報(bào)表代碼。假如想增加新報(bào)表,只需增加新訪問者,而不需要更改數(shù)據(jù)結(jié)構(gòu)中代碼。這意味著報(bào)表能夠被放置在不一樣組件中,而且僅被那些需要它們客戶單獨(dú)使用。第165頁165例：報(bào)表生成器一個(gè)表示材料單簡(jiǎn)單數(shù)據(jù)結(jié)構(gòu)。從該數(shù)據(jù)結(jié)構(gòu)能夠生成無數(shù)報(bào)表。兩個(gè)能夠統(tǒng)計(jì)量：成本；數(shù)量比如能夠生成一張一個(gè)組合件總成本報(bào)表,或者生成一張列出了一個(gè)組合件中全部零件報(bào)表。第166頁166VlSITOR模式處理方法第167頁167其它模式問題：考慮前面Modem層次結(jié)構(gòu)。假設(shè)有一個(gè)含有很多使用者應(yīng)用程序。每個(gè)使用者都能夠坐在他計(jì)算機(jī)前,要求系統(tǒng)使用該計(jì)算機(jī)調(diào)制解調(diào)器呼叫另一臺(tái)計(jì)算機(jī)。有些用戶希望聽到撥號(hào)聲,有些用戶則希望他們調(diào)制解調(diào)器保持平靜。第168頁168DECORATOR模式DECORATOR模式經(jīng)過創(chuàng)建一個(gè)名為L(zhǎng)oudDialModem全新類來處理這個(gè)問題。LoudDialModem派生自Modem,而且委托給一個(gè)它包含Modem實(shí)例。它捕捉對(duì)dial函數(shù)調(diào)用并在委托前把音量設(shè)高。第169頁169多個(gè)Decorator有時(shí),在同一個(gè)類層次結(jié)構(gòu)中可能存在兩個(gè)或者更多裝飾器（decorator）。比如,可能希望用LogoutExitModem來裝飾Modem層次結(jié)構(gòu),當(dāng)Hangup被調(diào)用時(shí),它會(huì)發(fā)送字符串"exit"。這個(gè)裝飾器必須要重復(fù)已經(jīng)在LoudDialModem中編寫過全部委托代碼。第170頁170第171頁171慣用軟件架構(gòu)格調(diào)及適用情況分析康凱第172頁172軟件架構(gòu)軟件框架常見架構(gòu)格調(diào)第173頁173軟件架構(gòu)概論系統(tǒng)架構(gòu)是一個(gè)軟件系統(tǒng)從整體到部分最高層次劃分。一個(gè)系統(tǒng)通常是由元件組成，而這些元件怎樣形成、相互之間怎樣發(fā)生作用，則是關(guān)于這個(gè)系統(tǒng)本身結(jié)構(gòu)主要信息。詳細(xì)地說，就是要包含架構(gòu)元件（ArchitectureComponent）、聯(lián)結(jié)器（Connector）、任務(wù)流（Task-flow）。所謂架構(gòu)元素，也就是組成系統(tǒng)關(guān)鍵"磚瓦"，而聯(lián)結(jié)器則描述這些元件之間通訊路徑、通訊機(jī)制、通訊預(yù)期結(jié)果，任務(wù)流則描述系統(tǒng)怎樣使用這些元件和聯(lián)結(jié)器完成某一項(xiàng)需求。第174頁174建造一個(gè)系統(tǒng)所作出最高層次、以后難以更改，商業(yè)和技術(shù)決定。在建造一個(gè)系統(tǒng)之前會(huì)有很多主要決定需要事先作出，而一旦系統(tǒng)開始進(jìn)行詳細(xì)設(shè)計(jì)甚至建造，這些決定就極難更改甚至無法更改。顯然，這么決定必定是相關(guān)系統(tǒng)設(shè)計(jì)成敗最主要決定，必須經(jīng)過慎重研究和考查。第175頁175架構(gòu)目標(biāo)可靠性（Reliable）：軟件系統(tǒng)對(duì)于用戶商業(yè)經(jīng)營(yíng)和管理來說極為主要，所以軟件系統(tǒng)必須非?？煽?。安全性（Secure）：軟件系統(tǒng)所負(fù)擔(dān)交易商業(yè)價(jià)值極高，系統(tǒng)安全性非常主要?？缮炜s性（Scalable）：軟件必須能夠在用戶使用率、用戶數(shù)目增加很快情況下，保持合理性能。只有這么，才能適應(yīng)用戶市場(chǎng)擴(kuò)展得可能性。第176頁176架構(gòu)目標(biāo)可定制化（Customizable）：一樣一套軟件，能夠依據(jù)客戶群不一樣和市場(chǎng)需求改變進(jìn)行調(diào)整?？蓴U(kuò)展性（Extensible）：在新技術(shù)出現(xiàn)時(shí)候，一個(gè)軟件系統(tǒng)應(yīng)該允許導(dǎo)入新技術(shù)，從而對(duì)現(xiàn)有系統(tǒng)進(jìn)行功效和性能擴(kuò)展可維護(hù)性（Maintainable）：軟件系統(tǒng)維護(hù)包含兩方面，一是排除現(xiàn)有錯(cuò)誤，二是將新軟件需求反應(yīng)到現(xiàn)有系統(tǒng)中去。一個(gè)易于維護(hù)系統(tǒng)能夠有效地降低技術(shù)支持花費(fèi)。第177頁177客戶體驗(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ī)非常主要。第178頁178架構(gòu)種類依據(jù)我們關(guān)注角度不一樣，能夠?qū)⒓軜?gòu)分成三種：邏輯架構(gòu)物理架構(gòu)系統(tǒng)架構(gòu)第179頁179邏輯架構(gòu)軟件系統(tǒng)中元件之間關(guān)系，比如用戶界面，數(shù)據(jù)庫，外部系統(tǒng)接口，商業(yè)邏輯元件等等。第180頁180物理架構(gòu)軟件元件是怎樣放到硬件上下列圖描述了一個(gè)分布于北京和上海分布式系統(tǒng)物理架構(gòu)，圖中全部元件都是物理設(shè)備，包含網(wǎng)絡(luò)分流器、代理服務(wù)器、WEB服務(wù)器、應(yīng)用服務(wù)器、報(bào)表服務(wù)器、整合服務(wù)器、存放服務(wù)器、主機(jī)等等。第181頁181系統(tǒng)架構(gòu)系統(tǒng)非功效性特征，如可擴(kuò)展性、可靠性、強(qiáng)壯性、靈活性、性能等。系統(tǒng)架構(gòu)設(shè)計(jì)要求架構(gòu)師具備軟件和硬件功效和性能過硬知識(shí)，這一工作是架構(gòu)設(shè)計(jì)工作中最困難工作。第182頁182架構(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)，以及它們?cè)鯓佑绊懙较到y(tǒng)全部非功效性特征。這些決定中會(huì)有很多是一旦作出，就極難更改?；跀?shù)據(jù)庫系統(tǒng)架構(gòu)：普通有多少個(gè)數(shù)據(jù)表，就會(huì)有多少頁架構(gòu)設(shè)計(jì)文檔。比如一個(gè)中等數(shù)據(jù)庫應(yīng)用系統(tǒng)通常含有一百個(gè)左右數(shù)據(jù)表，這么一個(gè)系統(tǒng)設(shè)計(jì)通常需要有一百頁左右架構(gòu)設(shè)計(jì)文檔。第183頁183軟件框架什么是框架框架與架構(gòu)區(qū)分常見框架第184頁184框架什么是框架？框架，即framework。是某種應(yīng)用半成品，就是一組組件，供選取完成自己系統(tǒng)。簡(jiǎn)單說就是使用他人搭好舞臺(tái)，你來做演出。而且，框架普通是成熟，不停升級(jí)軟件?？蚣芘c架構(gòu)區(qū)分？并無明確定義，但普通從層觀點(diǎn)看，認(rèn)為框架是底層，靠近系統(tǒng)。軟件開發(fā)者在其上構(gòu)建自己軟件架構(gòu)，開發(fā)自己利用程序。第185頁185為何要用框架因?yàn)檐浖到y(tǒng)發(fā)展到今天已經(jīng)很復(fù)雜了，尤其是服務(wù)器端軟件，設(shè)計(jì)到知識(shí)，內(nèi)容，問題太多。在一些方面使用成熟框架，能夠防止重復(fù)做已經(jīng)有基礎(chǔ)工作，而只需要集中精力完成系統(tǒng)業(yè)務(wù)邏輯設(shè)計(jì)?？蚣芷胀ㄊ浅墒?，穩(wěn)健，能夠處理系統(tǒng)很多細(xì)節(jié)問題，比如，事物理，安全性，數(shù)據(jù)流控制等問題?？蚣芷胀ǘ冀?jīng)過很多人使用，所以結(jié)構(gòu)很好，所以擴(kuò)展性也很好，而且它是不停升級(jí)，使用框架開發(fā)者能夠直接享受他人升級(jí)代碼帶來好處。框架普通處于低層應(yīng)用平臺(tái)（如J2EE）和高層業(yè)務(wù)邏輯之間中間層。第186頁186常見框架常見JAVA框架常見.Net框架其它基于C++框架第187頁187常見JAVA框架EJBWAFStrutsTurbineCOCOONECHOJATOTCFSpringHibernateIBatisJSF第188頁188.NET框架.NET框架是創(chuàng)建、布署和運(yùn)行Web服務(wù)及其它應(yīng)用程序一個(gè)環(huán)境。它包含三個(gè)主要部分：公共語言運(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ì)。第189頁189C++框架ACEBOOSTMFCATLQTwxWidgets…第190頁190不一樣層次模式架構(gòu)模式(ArchitecturalPattern)設(shè)計(jì)模式(DesignPattern)代碼模式(CodingPattern)第191頁191區(qū)分：在于三種不一樣模式存在于它們各自抽象層次和詳細(xì)層次。架構(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)。代碼模式是特定范例和與特定語言相關(guān)編程技巧。代碼模式好壞會(huì)影響到一個(gè)中等尺度組件內(nèi)部、外部結(jié)構(gòu)或行為底層細(xì)節(jié)，但不會(huì)影響到一個(gè)部件或子系統(tǒng)中等尺度結(jié)構(gòu)，更不會(huì)影響到系統(tǒng)總體布局和大尺度框架。第192頁192幾個(gè)經(jīng)典架構(gòu)模式系統(tǒng)軟件分層(Layer)管道和過濾器(PipesandFilters)黑板(Blackboard)開發(fā)分布式軟件經(jīng)紀(jì)人(Broker)客戶/服務(wù)器（Client/Server）點(diǎn)對(duì)點(diǎn)（PeertoPeer）交互軟件模型-視圖-控制器（Model-View-Controller）顯示-抽象-控制（Presentation-Abstraction-COntrol）第193頁193其它面向?qū)ο蟾裾{(diào)(ADT)基于消息廣播且面向圖形用戶界面Chiron2格調(diào)基于事件隱式調(diào)用格調(diào)(Event-based,ImplicitInvocation)…第194頁194分層(Layer)從不一樣層次來觀察系統(tǒng)，處理不一樣層次問題對(duì)象被封裝到不一樣層中。

軟件為何要分層？

為了實(shí)現(xiàn)“高內(nèi)聚、低耦合”。把問題劃分開來各個(gè)處理，易于控制，易于延展，易于分配資源…面向?qū)ο蟆⒒谀K化組件設(shè)計(jì)需要能夠方便地修改應(yīng)用程序各個(gè)部分。完成這一目標(biāo)一個(gè)好方法就是在層上工作，將一個(gè)應(yīng)用程序主要功效分離到不一樣層或者級(jí)中。第195頁195分層模型從本質(zhì)上講，層代表了一個(gè)應(yīng)用程序主要功效。普通地，我們將應(yīng)用程序功效分為三個(gè)方面，對(duì)應(yīng)3層架構(gòu)模式。它們是數(shù)據(jù)層（datalayer）、商務(wù)層（businesslayer）和表示層（presentationlayer）。數(shù)據(jù)層：包含數(shù)據(jù)存放和與它交互組件或服務(wù)。這些組件和服務(wù)在功效上和中間層相互獨(dú)立（盡管在物理上無須一定相互獨(dú)立--它們能夠在同一臺(tái)服務(wù)器上）。中間層：包含一個(gè)或者多個(gè)組件服務(wù)，它們應(yīng)用商務(wù)規(guī)則、實(shí)現(xiàn)應(yīng)用程序邏輯并完成應(yīng)用程序運(yùn)行所需要數(shù)據(jù)處理。作為這個(gè)過程一部分，中間層負(fù)責(zé)處理來自數(shù)據(jù)存放或者發(fā)送給數(shù)據(jù)存放數(shù)據(jù)。第196頁196表示層：從中間層取得信息并顯示給用戶。該層同時(shí)也負(fù)責(zé)和用戶進(jìn)行交互，比較返回信息并將信息回送給中間層進(jìn)行處理。數(shù)據(jù)層從數(shù)據(jù)庫中取得較為原始數(shù)據(jù)，商務(wù)層把數(shù)據(jù)轉(zhuǎn)換成符合商務(wù)規(guī)則有意義信息，表示層把信息轉(zhuǎn)換成對(duì)于用戶有意義內(nèi)容。這種分層設(shè)計(jì)方式很有用，因?yàn)槊恳粚佣寄軌颡?dú)立地修改。我們能夠修改商務(wù)層，不停地從數(shù)據(jù)層接收相同數(shù)據(jù)，并把這些數(shù)據(jù)傳遞到表示層，而不用擔(dān)心出現(xiàn)歧義。我們也能夠修改表示層，使得對(duì)于站點(diǎn)外觀修改無須改動(dòng)下面商務(wù)層邏輯。第197頁197管道和過濾器（PipesandFilters）管道和過濾器架構(gòu)模式是為處理數(shù)據(jù)流系統(tǒng)提供一個(gè)模式。它是由過濾器和管道組成.每個(gè)處理步驟都被封裝在一個(gè)過濾器組件中，數(shù)據(jù)經(jīng)過相鄰過濾器之間管道進(jìn)行傳輸。每個(gè)過濾器能夠單獨(dú)修改，功效單一，而且它們之間次序能夠進(jìn)行配置。第198頁198一個(gè)著名例子是傳統(tǒng)編譯器。傳統(tǒng)編譯器一直被認(rèn)為是一個(gè)管道系統(tǒng)，在該系統(tǒng)中，一個(gè)階段（包含詞法分析、語法分析、語義分析和代碼生成）輸出是另一個(gè)階段輸入。第199頁199問題：一個(gè)必須處理或轉(zhuǎn)換輸入數(shù)據(jù)流系統(tǒng)。把這么系統(tǒng)作為單個(gè)組件實(shí)現(xiàn)是不輕易：系統(tǒng)必須由幾個(gè)開發(fā)人員同時(shí)進(jìn)行協(xié)作開發(fā)，整個(gè)系統(tǒng)任務(wù)自然就被分解為幾個(gè)處理階段，而且需求很輕易變動(dòng)。所以你就要經(jīng)過替換或重新排序處理步驟來為未來靈活性作規(guī)劃。經(jīng)過加入這么靈活性，采取現(xiàn)有處理組件構(gòu)建是能夠辦到。系統(tǒng)設(shè)計(jì)尤其是處理步驟內(nèi)部連接，必須考慮以下原因：未來系統(tǒng)升級(jí)經(jīng)過替換一些處理步驟，或重組步驟。不一樣語境中小處理步驟要比大組件更易于重用。不相連處理步驟不可共享信息。存在不一樣輸入數(shù)據(jù)源，能夠用各種方式輸出或存放最終止果。第200頁200處理方案與結(jié)構(gòu)管道和過濾器體系架構(gòu)模式把系統(tǒng)任務(wù)分成為幾個(gè)獨(dú)立處理步驟。這些步驟采取經(jīng)過系統(tǒng)數(shù)據(jù)流連接。一個(gè)步驟輸出是下一個(gè)步驟輸入。每個(gè)處理步驟由一個(gè)過濾器組件實(shí)現(xiàn)，它處理或者轉(zhuǎn)化數(shù)據(jù)，而且系統(tǒng)輸入能夠是各種數(shù)據(jù)源。這種體系架構(gòu)模式含有許多特征：過濾器是獨(dú)立運(yùn)行部件。也就是除了輸入和輸出外，每個(gè)過濾器不受任何其它過濾器運(yùn)行影響。在設(shè)計(jì)上，過濾器之間不共享任何狀態(tài)信息。獨(dú)立性還表現(xiàn)在它對(duì)其處理上游和下游連接過濾器是"無知".它設(shè)計(jì)和使用不對(duì)與其連接任何過濾器施加限制，唯一關(guān)心是其輸入數(shù)據(jù)，然后進(jìn)行加工處理，最終產(chǎn)生數(shù)據(jù)輸出。第201頁201優(yōu)點(diǎn)與缺點(diǎn)優(yōu)點(diǎn)：結(jié)構(gòu)簡(jiǎn)單：系統(tǒng)行為是全部過濾器行為簡(jiǎn)單復(fù)合。系統(tǒng)易于維護(hù)和增強(qiáng)：增加新過濾器，替換舊過濾器。支持復(fù)用：過濾器只同其輸入、輸出端口數(shù)據(jù)相關(guān)。各過濾器能夠并發(fā)運(yùn)行。缺點(diǎn)：輕易造成批處理方式：每個(gè)過濾器從輸入數(shù)據(jù)到輸出數(shù)據(jù)轉(zhuǎn)換是一個(gè)整體。轉(zhuǎn)換通常不適合交互式應(yīng)用。有時(shí)必須維護(hù)兩個(gè)分離而又相關(guān)流之間對(duì)應(yīng)關(guān)系。同實(shí)現(xiàn)相關(guān)，過濾器之間數(shù)據(jù)傳輸率較低，而且每個(gè)過濾器都要作類似數(shù)據(jù)打包和解包工作。第202頁202黑板(Blackboard)又稱看板模式：在這種架構(gòu)中，有兩種不一樣構(gòu)件：一個(gè)是表示當(dāng)前狀態(tài)中心數(shù)據(jù)結(jié)構(gòu)；另一個(gè)是一個(gè)相互獨(dú)立構(gòu)件，這些構(gòu)件對(duì)中心數(shù)據(jù)進(jìn)行操作。這種架構(gòu)主要用于數(shù)據(jù)庫和人工智能系統(tǒng)開發(fā)。模式識(shí)別、數(shù)據(jù)挖掘。第203頁203經(jīng)紀(jì)人(Broker)客戶和服務(wù)器經(jīng)過一個(gè)經(jīng)紀(jì)人部件進(jìn)行通信，經(jīng)紀(jì)人負(fù)責(zé)協(xié)調(diào)客戶和服務(wù)器之間操作，而且為客戶和服務(wù)器發(fā)送請(qǐng)求和結(jié)果信息。第204頁204代理程序駐留在一個(gè)不應(yīng)該頻繁更改、眾所周知位置。已被激活而且準(zhǔn)備接收請(qǐng)求任何服務(wù)器都將向代理程序注冊(cè)自己，方便下一次客戶端向代理程序請(qǐng)求這種類型服務(wù)器時(shí)，代理程序能夠使用它。這還可能提升系統(tǒng)性能和可用性，因?yàn)樗鼓軌驌碛卸鄠€(gè)同時(shí)運(yùn)行并服務(wù)于多個(gè)客戶端、完全相同服務(wù)器組件。這種機(jī)制有時(shí)稱為負(fù)載平衡。第205頁205客戶/服務(wù)器（Client/Server）系統(tǒng)分為客戶和服務(wù)器，服務(wù)器一直處于偵聽狀態(tài)，客戶主動(dòng)連接服務(wù)器，每個(gè)服務(wù)器能夠?yàn)槎鄠€(gè)客戶服務(wù)。第206頁206優(yōu)缺點(diǎn)優(yōu)點(diǎn)：結(jié)構(gòu)簡(jiǎn)單，系統(tǒng)中不一樣類型任務(wù)分別由客戶和服務(wù)器負(fù)擔(dān)，有利于發(fā)揮不一樣機(jī)器平臺(tái)優(yōu)勢(shì)；支持分布式、并發(fā)環(huán)境，尤其是當(dāng)客戶和服務(wù)器之間關(guān)系是多對(duì)多時(shí)，能夠有效地提升資源利用率和共享程度；服務(wù)器集中管理資源，有利于權(quán)限控制和系統(tǒng)安全。缺點(diǎn)：在大多數(shù)client-server格調(diào)系統(tǒng)中，構(gòu)件之間連接經(jīng)過（遠(yuǎn)程）過程調(diào)用，靠近于代碼一級(jí)，表示能力較弱。第207頁207點(diǎn)對(duì)點(diǎn)（PeertoPeer）系統(tǒng)中節(jié)點(diǎn)都處于平等地位，每個(gè)節(jié)點(diǎn)都能夠連接其它節(jié)點(diǎn)。在這種架構(gòu)中，普通需要由一個(gè)中心服務(wù)器完成發(fā)覺和管理節(jié)點(diǎn)操作。ICQ以及WebService技術(shù)大多數(shù)應(yīng)用，都是經(jīng)典點(diǎn)對(duì)點(diǎn)結(jié)構(gòu)。第208頁208模型-視圖-控制器（MVC）當(dāng)應(yīng)用程序用戶界面非常復(fù)雜，且關(guān)于用戶界面需求很輕易改變時(shí)，我們能夠把交互類型軟件抽象成模型、視圖和控制器這三類組件單元，這種抽象能夠很好地分離用戶界面和業(yè)務(wù)邏輯，適應(yīng)改變需求。大多數(shù)當(dāng)代交互軟件都在一定程度上符合這一架構(gòu)模型特點(diǎn)。MVC模式最吸引人之處于于它迫使用戶必須抽象自己代碼，把項(xiàng)目分為表示、邏輯和控制三部分,每部分間關(guān)聯(lián)較小。以MVC模式結(jié)構(gòu)軟件,能夠使得軟件結(jié)構(gòu)靈活、重用性好、擴(kuò)展性佳。第209頁209模型—視圖—控制器交互示意圖第210頁210模型：視圖：控制器:模型：模型表示應(yīng)用數(shù)據(jù)及操作這些數(shù)據(jù)邏輯方法。任何和整個(gè)應(yīng)用相關(guān)持久性數(shù)據(jù)都應(yīng)該放在模型中。對(duì)于模型,它所提供API不能只針對(duì)某一個(gè)專門視圖或控制器,應(yīng)該更普通化以適應(yīng)不一樣客戶需求。視圖：視圖將模型當(dāng)前狀態(tài)展示給用戶,詳細(xì)顯示方法由視圖負(fù)責(zé),所以一個(gè)模型能夠適用多個(gè)不一樣視圖。在模型狀態(tài)改變后,經(jīng)過模型和視圖之間協(xié)議,視圖得知這種改變并修改自己顯示。對(duì)于用戶輸入,視圖將它們交給控制器處理。控制器:控制器負(fù)責(zé)交互和將用戶輸入數(shù)據(jù)導(dǎo)入模型,它還利用用戶輸入將應(yīng)用轉(zhuǎn)向其它視圖。一些非持久暫時(shí)數(shù)據(jù)也應(yīng)該在視圖中存取。第211頁211SOA及分層架構(gòu)設(shè)計(jì)第212頁212SOA架構(gòu)特點(diǎn)服務(wù)（Service）定義良好，自包含，不依賴于上下文和其它服務(wù)一組功效SOA（Service-OrientedArchitecture）本質(zhì)上是一組服務(wù)集合服務(wù)之間相互溝通能夠是簡(jiǎn)單數(shù)據(jù)傳輸，或者是由兩個(gè)或多個(gè)服務(wù)共同參加一些活動(dòng)，SOA也包含Service之間連通技術(shù)。第213頁213OOvs.SOA–OO擴(kuò)展碰到了挑戰(zhàn)伴隨時(shí)間推移，接口繼承復(fù)雜度在累積伴隨系統(tǒng)間距離延伸，調(diào)用成本在上升，類型系統(tǒng)不一樣時(shí)擴(kuò)展組件功效成本高，不可確定未來需求，不可堆疊擴(kuò)展方式重用與標(biāo)準(zhǔn)化，重用是OO第一標(biāo)準(zhǔn)，難以維持和維護(hù)復(fù)雜重用標(biāo)準(zhǔn)和機(jī)制第214頁214–OOvs.SOAOO依然適合用于服務(wù)開發(fā)顯著性能優(yōu)勢(shì)成熟設(shè)計(jì)與開發(fā)方法SOA適合用于系統(tǒng)互聯(lián)互操作性要求強(qiáng)于性能要求第215頁215SOA既不是一個(gè)語言，也不是一個(gè)詳細(xì)技術(shù)，它是一個(gè)新軟件系統(tǒng)架構(gòu)模型。