高級(jí)軟件架構(gòu)設(shè)計(jì)課件

1高級(jí)軟件架構(gòu)設(shè)計(jì)1高級(jí)軟件架構(gòu)設(shè)計(jì)2目錄第一單元：軟件生命周期與軟件架構(gòu)介紹 第二單元：技術(shù)架構(gòu)視圖─面向?qū)ο蟪绦蛟O(shè)計(jì)原則與模式

用GRASP模式指導(dǎo)設(shè)計(jì) 領(lǐng)域模型

面向?qū)ο笤O(shè)計(jì)的基本原則 第三單元：用UML輔助系統(tǒng)分析與設(shè)計(jì) UML簡(jiǎn)介及常見(jiàn)疑難問(wèn)題辨析 借鑒RUP的UML建模與分析 第四單元：設(shè)計(jì)模式與軟件設(shè)計(jì)思想 設(shè)計(jì)模式

常用的軟件架構(gòu)風(fēng)格及適用情況分析

SOA及分層架構(gòu)設(shè)計(jì) 第五單元：架構(gòu)設(shè)計(jì)實(shí)踐 2目錄第一單元：軟件生命周期與軟件架構(gòu)介紹 3第一單元：軟件生命周期與軟件架構(gòu)介紹3第一單元：軟件生命周期與軟件架構(gòu)介紹4IT行業(yè)的人才結(jié)構(gòu)與軟件架構(gòu)師的定位軟件架構(gòu)師應(yīng)掌握的知識(shí)體系軟件架構(gòu)設(shè)計(jì)的特點(diǎn)、層次、分類軟件架構(gòu)的主要理論、方向和趨勢(shì)軟件工廠，實(shí)現(xiàn)軟件開(kāi)發(fā)的產(chǎn)業(yè)化4IT行業(yè)的人才結(jié)構(gòu)與軟件架構(gòu)師的定位5軟件架構(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)題的能力。三、寫(xiě)作、溝通表達(dá)、培訓(xùn)。5軟件架構(gòu)師的定位系統(tǒng)架構(gòu)師的職責(zé)：6角色軟件架構(gòu)師SoftwareArchitect定義主導(dǎo)系統(tǒng)全局分析設(shè)計(jì)和實(shí)施、負(fù)責(zé)軟件構(gòu)架和關(guān)鍵技術(shù)決策的角色6角色7職責(zé)領(lǐng)導(dǎo)與協(xié)調(diào)整個(gè)項(xiàng)目中的技術(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)7職責(zé)8專業(yè)技能技術(shù)全面、成熟練達(dá)、洞察力強(qiáng)、經(jīng)驗(yàn)豐富，具備在缺乏完整信息、眾多問(wèn)題交織一團(tuán)、模糊和矛盾的情況下，迅速抓住問(wèn)題要害，并做出合理的關(guān)鍵決定的能力。具備戰(zhàn)略性和前瞻性思維能力，善于把握全局，能夠在更高抽象級(jí)別上進(jìn)行思考。對(duì)項(xiàng)目開(kāi)發(fā)涉及的所有問(wèn)題領(lǐng)域都有經(jīng)驗(yàn)，包括徹底地理解項(xiàng)目需求，開(kāi)展分析設(shè)計(jì)之類軟件工程活動(dòng)等。具備領(lǐng)導(dǎo)素質(zhì)，以在各小組之間推進(jìn)技術(shù)工作，并在項(xiàng)目壓力下做出牢靠的關(guān)鍵決策。擁有優(yōu)秀的溝通能力，用以進(jìn)行說(shuō)服、鼓勵(lì)和指導(dǎo)等活動(dòng)，并贏得項(xiàng)目成員的信任。8專業(yè)技能9以目標(biāo)導(dǎo)向和主動(dòng)的方式來(lái)不帶任何感情色彩地關(guān)注項(xiàng)目結(jié)果，構(gòu)架師應(yīng)當(dāng)是項(xiàng)目背后的技術(shù)推動(dòng)力，而非構(gòu)想者或夢(mèng)想家（追求完美）精通構(gòu)架設(shè)計(jì)的理論、實(shí)踐和工具，并掌握多種參考構(gòu)架、主要的可重用構(gòu)架機(jī)制和模式。具備系統(tǒng)設(shè)計(jì)員的所有技能，但涉及面更廣、抽象級(jí)別更高。9以目標(biāo)導(dǎo)向和主動(dòng)的方式來(lái)不帶任何感情色彩地關(guān)注項(xiàng)目結(jié)果，構(gòu)10軟件架構(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ò)對(duì)比軟件架構(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)師在需求分析、項(xiàng)目管理、運(yùn)行維護(hù)等方面知識(shí)的要求也就相對(duì)低些。10軟件架構(gòu)師的知識(shí)體系軟件架構(gòu)師作為整個(gè)軟件系統(tǒng)結(jié)構(gòu)的總設(shè)11成為一名合格的軟件架構(gòu)師必須具備的知識(shí)信息系統(tǒng)綜合知識(shí)體系軟件架構(gòu)知識(shí)體系11成為一名合格的軟件架構(gòu)師必須具備的知識(shí)12？MFC，MSF，MOF，RUP，J2EE，Spring，SOA，JUnit，ORM，.NetMVC，UML，XML，Corba，MDA，MDD，Web-ServiceRSS，Web2.0，AJAX，Serverlet，HibernateIOC，AOPRubyOnRailsRupBPELWorkflowEngineLBSOracleCMMIMQ…12？MFC，MSF，MOF，RUP，J2EE，Spring13軟件架構(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ì)方案的正確性13軟件架構(gòu)師在干什么？思考、思考、再思考14軟件架構(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ā)、項(xiàng)目管理、測(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)域的主要理論、流派、框架。14軟件架構(gòu)師的知識(shí)結(jié)構(gòu)軟件知識(shí)15軟件架構(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軟件架構(gòu)師的知識(shí)結(jié)構(gòu)業(yè)務(wù)知識(shí)16軟件架構(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軟件架構(gòu)師的思維方式基于框架的思維17軟件架構(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)秀的方案17軟件架構(gòu)師的思維方式風(fēng)險(xiǎn)管理意識(shí)18信息系統(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)典型系統(tǒng)應(yīng)用：包括網(wǎng)絡(luò)應(yīng)用、數(shù)據(jù)庫(kù)應(yīng)用和多媒體系統(tǒng)等方面的知識(shí)。(4)系統(tǒng)開(kāi)發(fā)：包括程序設(shè)計(jì)語(yǔ)言、軟件開(kāi)發(fā)方法、需求分析和設(shè)計(jì)方法、測(cè)試評(píng)審方法、開(kāi)發(fā)管理、應(yīng)用系統(tǒng)構(gòu)建、系統(tǒng)審計(jì)、外部資源使用和基于中間件的開(kāi)發(fā)等方面的知識(shí)。(5)安全性和可靠性技術(shù)：包括數(shù)據(jù)安全與保密、防闖入和防病毒、容錯(cuò)技術(shù)、可靠性模型與分析技術(shù)、系統(tǒng)可靠性、安全規(guī)章和保護(hù)私有信息規(guī)則等方面的知識(shí)。18信息系統(tǒng)綜合知識(shí)體系(1)計(jì)算機(jī)系統(tǒng)綜合知識(shí)：包括計(jì)算機(jī)19(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)的法律和規(guī)定等方面的知識(shí)。(8)數(shù)學(xué)和英語(yǔ)：至少具有大學(xué)以上的數(shù)學(xué)和英語(yǔ)基礎(chǔ)知識(shí)。19(6)標(biāo)準(zhǔn)化：包括標(biāo)準(zhǔn)化的基礎(chǔ)知識(shí)、標(biāo)準(zhǔn)化分級(jí)、編碼標(biāo)準(zhǔn)20軟件架構(gòu)知識(shí)體系(1)系統(tǒng)計(jì)劃：包括項(xiàng)目的提出和可行性分析、系統(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)風(fēng)格、特定領(lǐng)域的架構(gòu)風(fēng)格、基于架構(gòu)的軟件開(kāi)發(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ì)、文件與存儲(chǔ)設(shè)計(jì)、數(shù)據(jù)庫(kù)設(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)軟件建模：包括定義問(wèn)題與歸結(jié)模型、結(jié)構(gòu)化系統(tǒng)建模與數(shù)據(jù)流圖、面向?qū)ο笙到y(tǒng)建模、數(shù)據(jù)庫(kù)建模和逆向工程等。

20軟件架構(gòu)知識(shí)體系(1)系統(tǒng)計(jì)劃：包括項(xiàng)目的提出和可行性分21(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)開(kāi)發(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)的訪問(wèn)控制技術(shù)、數(shù)據(jù)的完整性、數(shù)據(jù)與文件的加密、通信的安全和系統(tǒng)的安全設(shè)計(jì)等。(10)復(fù)雜架構(gòu)設(shè)計(jì)：包括操作系統(tǒng)的架構(gòu)、編譯器的架構(gòu)和大型基礎(chǔ)庫(kù)的架構(gòu)等。21(6)分布式系統(tǒng)設(shè)計(jì)：包括分布式通信協(xié)議的設(shè)計(jì)、基于對(duì)象22軟件架構(gòu)師的任職條件根據(jù)軟件架構(gòu)師的職責(zé)和角色定位，以及知識(shí)體系，從實(shí)踐的角度考慮，合格的軟件架構(gòu)師應(yīng)該具有以下能力和經(jīng)驗(yàn)：(1)具有8年以上的軟件項(xiàng)目開(kāi)發(fā)實(shí)際工作經(jīng)驗(yàn)，其中至少有3年以上的代碼編寫(xiě)工作經(jīng)驗(yàn)，4年以上的基于面向?qū)ο蠛蜆?gòu)件開(kāi)發(fā)方法的軟件產(chǎn)品設(shè)計(jì)經(jīng)驗(yàn)。(2)具有5個(gè)以上大中型開(kāi)發(fā)項(xiàng)目的總體規(guī)劃、方案設(shè)計(jì)經(jīng)驗(yàn)，有大中型應(yīng)用系統(tǒng)開(kāi)發(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軟件架構(gòu)師的任職條件根據(jù)軟件架構(gòu)師的職責(zé)和角色定位，以及23(5)對(duì)設(shè)計(jì)模式有深刻的理解，并能在此基礎(chǔ)上設(shè)計(jì)出適合產(chǎn)品特性和質(zhì)量屬性的框架。(6)具有面向?qū)ο蟮姆治?、設(shè)計(jì)和開(kāi)發(fā)能力，精通UML和XML，能熟練使用RationalRose、PowerDesigner等工具進(jìn)行設(shè)計(jì)。(7)具有良好的團(tuán)隊(duì)意識(shí)和協(xié)作精神，有較強(qiáng)的溝通能力和書(shū)面表達(dá)能力。(8)具有旺盛的精力和學(xué)習(xí)能力，能快速掌握新技術(shù)和新方法。

23(5)對(duì)設(shè)計(jì)模式有深刻的理解，并能在此基礎(chǔ)上設(shè)計(jì)出適合產(chǎn)24第二單元：技術(shù)架構(gòu)視圖─面向?qū)ο蟪绦蛟O(shè)計(jì)原則與模式24第二單元：技術(shù)架構(gòu)視圖─面向?qū)ο蟪绦蛟O(shè)計(jì)原則與模式2525262627用GRASP模式指導(dǎo)設(shè)計(jì)27用GRASP模式指導(dǎo)設(shè)計(jì)2828292930303131323233333434353536363737383839394040414142424343444445領(lǐng)域模型45領(lǐng)域模型46層次結(jié)構(gòu)領(lǐng)域模型從EJB到輕量級(jí)框架46層次結(jié)構(gòu)47層次結(jié)構(gòu)表現(xiàn)層（present）業(yè)務(wù)層業(yè)務(wù)層外觀業(yè)務(wù)層核心領(lǐng)域?qū)ο蠊芾?服務(wù)/倉(cāng)庫(kù)層領(lǐng)域?qū)ο髮映志脤訑?shù)據(jù)訪問(wèn)層數(shù)據(jù)庫(kù)47層次結(jié)構(gòu)表現(xiàn)層（present）48領(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)服務(wù)(Service)，實(shí)現(xiàn)整個(gè)應(yīng)用程序的工作流(workflow)。服務(wù)包含那些無(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ù)可以說(shuō)是業(yè)務(wù)的協(xié)調(diào)者，業(yè)務(wù)邏輯可以分散到實(shí)體對(duì)象中。48領(lǐng)域模型中的各種角色：49領(lǐng)域模型失血模型貧血模型充血模型脹血模型49領(lǐng)域模型失血模型50失血模型DO只有屬性及其getter/setter方法，沒(méi)有任何業(yè)務(wù)邏輯。缺點(diǎn)：行為與數(shù)據(jù)分離，很多情況導(dǎo)致維護(hù)與理解困難。50失血模型DO只有屬性及其getter/setter方法，51貧血模型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ò)重。51貧血模型DO包含不依賴于持久化的領(lǐng)域邏輯；依賴持久化的領(lǐng)52充血模型與貧血模型類似，不同處在于如何劃分業(yè)務(wù)邏輯：絕大多業(yè)務(wù)邏輯都應(yīng)該放在DO里(包括持久化邏輯)，而Service層很薄，僅僅封裝事務(wù)和少量邏輯，不和DAO層打交道。Service(事務(wù)封裝)DODAO優(yōu)點(diǎn)：符合OOService層很薄，只充當(dāng)Facade的角色，不和DAO打交道。52充血模型與貧血模型類似，不同處在于如何劃分業(yè)務(wù)邏輯：絕大53缺點(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ò)程。53缺點(diǎn)：54脹血模型取消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ò)多的信息，可能引起不必要的耦合。54脹血模型取消Service層，只剩下DO和DAO層，在D55原則：業(yè)務(wù)對(duì)象封裝了內(nèi)在的業(yè)務(wù)邏輯，而應(yīng)用服務(wù)封裝了外在于業(yè)務(wù)對(duì)象的業(yè)務(wù)邏輯。55原則：56EJB到輕量級(jí)框架EJBPOJO（業(yè)務(wù)邏輯）+輕量級(jí)框架（[Hibernate、JDO、iBATIS]（持久化）、Spring（事務(wù)管理、安全））56EJB到輕量級(jí)框架EJB57EJBEJB：編寫(xiě)分布式業(yè)務(wù)應(yīng)用程序的Java標(biāo)準(zhǔn)架構(gòu)。提供大量服務(wù)：聲明型事務(wù),EIB容器自動(dòng)啟動(dòng)、提交和回滾事務(wù)。業(yè)務(wù)邏輯能參與由遠(yuǎn)程客戶發(fā)起的分布式事務(wù)。提供聲明型安全，大部分情況下不再搖要編寫(xiě)安全代碼求（bean部署描述符里的條目指定準(zhǔn)可以防問(wèn)某個(gè)具體bean）。57EJBEJB：58例：在兩個(gè)賬號(hào)間進(jìn)行轉(zhuǎn)賬的服務(wù)。58例：在兩個(gè)賬號(hào)間進(jìn)行轉(zhuǎn)賬的服務(wù)。59POJO（業(yè)務(wù)邏輯）+Hiibernate、JDO、iBATIS（持久化）、Spring（事務(wù)管理、安全）。┏━━━━━━━━━┳━━━━━━━━━━━━━━━┳━━━━━━━┓┃┃典型的EJB方法┃POJO方法┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━╋━━━━━━━┫┃組織┃過(guò)程式業(yè)務(wù)邏輯┃面向?qū)ο笤O(shè)計(jì)┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━╋━━━━━━━┫┃實(shí)現(xiàn)┃基于EJB┃POJO┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━┻━━━━━━━┫┃數(shù)據(jù)庫(kù)訪問(wèn)┃JDBC/SQL或?qū)嶓wbean ┃持久層框架┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━┳━━━━━━━┫┃返回給表示層的數(shù)據(jù)┃DTO┃業(yè)務(wù)對(duì)象┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━╋━━━━━━━┫┃事務(wù)管理┃EJB容器管理的事務(wù)┃Spring框架┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━╋━━━━━━━┫┃應(yīng)用程序組裝┃顯式的JNDI查詢┃依賴注入┃┗━━━━━━━━━┻━━━━━━━━━━━━━━━┻━━━━━━━┛59POJO（業(yè)務(wù)邏輯）+Hiibernate、JDO、i60新設(shè)計(jì)是面向?qū)ο?、基于POJO,而非基于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ā)人員要友好。60新設(shè)計(jì)是面向?qū)ο?、基于POJO,而非基于EJB的過(guò)程式61基于輕量級(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的種種好處。61基于輕量級(jí)框架設(shè)計(jì)的好處是，它提供事務(wù)和持久化時(shí)并不要求62面向?qū)ο蟮膬?yōu)點(diǎn)：整個(gè)設(shè)計(jì)更易理解和維護(hù)。它并不是一個(gè)無(wú)所不能的大型類,而是由大量小類組成,每個(gè)類只共有若干職責(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ì)往往需耍修改核心代碼。62面向?qū)ο蟮膬?yōu)點(diǎn)：63不適合用面向?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)體現(xiàn)的是彼此的業(yè)務(wù)關(guān)系。復(fù)雜的SQL固然不好維護(hù)，但業(yè)務(wù)真是復(fù)雜到簡(jiǎn)單的SQL都難以描述的程度，采用面向?qū)ο竺枋鰟t更加困難，維護(hù)也更困難，同時(shí)還損失了效率。比較大的事務(wù)。性能要求高的地方。（直接用Sql或者存儲(chǔ)過(guò)程；犧牲可維護(hù)性和可復(fù)用性）上層流程。63不適合用面向?qū)ο蟮膱?chǎng)合：64面向?qū)ο笤O(shè)計(jì)的基本原則64面向?qū)ο笤O(shè)計(jì)的基本原則656566liskov替換原則（LSP）66liskov替換原則（LSP）67子類型必須能夠替換掉其基類型問(wèn)題的根源是關(guān)于行為的：基類中有的行為在子類中不存在或不適當(dāng)。ISA的本質(zhì)是指行為的一致，而不是生活中的語(yǔ)言。違反了LSP原則的本質(zhì)是派生類的行為與基類中的不一致。如果違反了LSP原則，常會(huì)導(dǎo)致在運(yùn)行時(shí)的類型判斷(RTTI)違反OCP原則。例如：函數(shù)A的參數(shù)是基類型，調(diào)用時(shí)傳遞的對(duì)象是子類型，正常情況下，增加子類型都不會(huì)影響到函數(shù)A的，如果違反了LSP，則函數(shù)A必須小心的判斷傳進(jìn)來(lái)的具體類型，否則就會(huì)出錯(cuò)，這就已經(jīng)違反了OCP原則。67子類型必須能夠替換掉其基類型問(wèn)題的根源是關(guān)于行為的：68接口隔離原則（ISP）68接口隔離原則（ISP）69使用多個(gè)專門的接口比使用單一的總接口要好。一個(gè)類對(duì)另外一個(gè)類的依賴性應(yīng)當(dāng)是建立在最小的接口上的。一個(gè)接口代表一個(gè)角色，不應(yīng)當(dāng)將不同的角色都交給一個(gè)接口。沒(méi)有關(guān)系的接口合并在一起，形成一個(gè)臃腫的大接口，這是對(duì)角色和接口的污染。“不應(yīng)該強(qiáng)迫客戶依賴于它們不用的方法。接口屬于客戶，不屬于它所在的類層次結(jié)構(gòu)?！边@個(gè)說(shuō)得很明白了，再通俗點(diǎn)說(shuō)，不要強(qiáng)迫客戶使用它們不用的方法，如果強(qiáng)迫用戶使用它們不使用的方法，那么這些客戶就會(huì)面臨由于這些不使用的方法的改變所帶來(lái)的改變。69使用多個(gè)專門的接口比使用單一的總接口要好。70例比如說(shuō)電子商務(wù)的系統(tǒng),有訂單這個(gè)類,有三個(gè)地方會(huì)使用到,一個(gè)是門戶,只能有查詢方法,一個(gè)是外部系統(tǒng),有添加訂單的方法,一個(gè)是管理后臺(tái),添加刪除修改查詢都要用到.根據(jù)接口隔離原則(ISP),一個(gè)類對(duì)另外一個(gè)類的依賴性應(yīng)當(dāng)是建立在最小的接口上.也就是說(shuō),對(duì)于門戶,它只能依賴有一個(gè)查詢方法的接口.70例比如說(shuō)電子商務(wù)的系統(tǒng),有訂單這個(gè)類,有三個(gè)地方會(huì)使用到71依賴倒置原則（DIP）71依賴倒置原則（DIP）72相關(guān)概念關(guān)于解耦依賴倒置（DIP）控制反轉(zhuǎn)（IoC）依賴注入（DI）服務(wù)定位器（SL）有些是手段，有些是原則，不過(guò)其間的差異并不太重要，更重要的是其共同點(diǎn)：其根本目標(biāo)都是解除依賴，將組件的配置與使用分離開(kāi)。其它名詞服務(wù)組件框架類庫(kù)應(yīng)用程序72相關(guān)概念關(guān)于解耦73接口和實(shí)現(xiàn)分離

面向過(guò)程的接口與實(shí)現(xiàn)分離73接口和實(shí)現(xiàn)分離

面向過(guò)程的接口與實(shí)現(xiàn)分離74747575767677電影清單的例子一個(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()]);}}77電影清單的例子一個(gè)組件，用于提供一份電影清單，清單上列出78其中真正想要考察的是如何將MovieLister對(duì)象與特定的finder對(duì)象連接起來(lái)。要求：我們希望moviesDirectedBy方法完全不依賴于影片的實(shí)際存儲(chǔ)方式。這個(gè)方法只能引用一個(gè)finder對(duì)象，而finder對(duì)象必須知道如何實(shí)現(xiàn)findAll的細(xì)節(jié)。給finder定義一個(gè)接口：

publicinterfaceMovieFinder {ListfindAll();}當(dāng)要實(shí)際尋找影片時(shí)，就必須涉及到MovieFinder的某個(gè)具體子類。在這里，我把“涉及具體子類”的代碼放在MovieLister類的構(gòu)造函數(shù)中。78其中真正想要考察的是如何將MovieLister對(duì)象與特79對(duì)抗變化從一個(gè)逗號(hào)分隔的文本文件中獲得影片列表。classMovieLister...privateMovieFinderfinder;publicMovieLister(){finder=newColonDelimitedMovieFinder("movies1.txt");}對(duì)抗變化：文件清單的名字更改：可以從一個(gè)配置文件獲得文件名。如果用SQL數(shù)據(jù)庫(kù)、XML文件、webservice，或者另一種格式的文本文件來(lái)存儲(chǔ)影片清單：用另一個(gè)具體的類來(lái)獲取數(shù)據(jù)。該類從MovieFinder接口派生即可。創(chuàng)建合適的MovieFinder派生類的實(shí)例：不能對(duì)抗此變化。79對(duì)抗變化從一個(gè)逗號(hào)分隔的文本文件中獲得影片列表。80配置文件設(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>80配置文件設(shè)定配置文件：XML文件是比較理想的配置方式。81第三單元：用UML輔助系統(tǒng)分析與設(shè)計(jì)81第三單元：用UML輔助系統(tǒng)分析與設(shè)計(jì)82UML用來(lái)描述模型的內(nèi)容有3種,分別是事物(Things)、關(guān)系Relationships)和圖(Diagrams)。82UML用來(lái)描述模型的內(nèi)容有3種,分別是事物(Thing83UML中的關(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)系83UML中的關(guān)系UML中的關(guān)系(Relationships84一些常見(jiàn)問(wèn)題辨析類的層次結(jié)構(gòu)表示屬性與聚合關(guān)聯(lián)角色關(guān)聯(lián)類84一些常見(jiàn)問(wèn)題辨析類的層次結(jié)構(gòu)表示85層次結(jié)構(gòu)85層次結(jié)構(gòu)86領(lǐng)域建模－重?cái)?shù)86領(lǐng)域建模－重?cái)?shù)87細(xì)化類模型87細(xì)化類模型88關(guān)聯(lián)角色關(guān)聯(lián)角色名出現(xiàn)在關(guān)聯(lián)終端的旁邊。當(dāng)僅僅使用關(guān)聯(lián)名不足夠表達(dá)清楚后，可以用關(guān)聯(lián)角色名來(lái)加強(qiáng)表達(dá)?？梢园衙總€(gè)名稱都當(dāng)成偽屬性，關(guān)聯(lián)角色名提供了一種可以遍歷關(guān)聯(lián)的方法。88關(guān)聯(lián)角色關(guān)聯(lián)角色名出現(xiàn)在關(guān)聯(lián)終端的旁邊。當(dāng)僅僅使用關(guān)聯(lián)名89

在創(chuàng)建類圖時(shí)，應(yīng)該為使用正確的角色名，而不是為每個(gè)引用引入一個(gè)獨(dú)立的類。因?yàn)榻巧梢詤^(qū)分對(duì)象，所以附在一個(gè)類上的關(guān)聯(lián)名必須唯一（可以把角色名想象成類的偽屬性）。同樣，角色名不應(yīng)該與類的屬性名重復(fù)。89在創(chuàng)建類圖時(shí)，應(yīng)該為使用正確的角色名，而不是為每個(gè)引用90關(guān)聯(lián)類正如可以用屬性描述類的對(duì)象一樣，也可以用屬性來(lái)描述關(guān)聯(lián)的鏈接，可以把這樣的一組屬性組成關(guān)聯(lián)類。90關(guān)聯(lián)類正如可以用屬性描述類的對(duì)象一樣，也可以用屬性來(lái)描述91Actor的一些注意事項(xiàng)包括人與系統(tǒng)，總是外部的。定義了邊界。Actor是“角色”，不是特定的人或特定的事。要有恰當(dāng)?shù)拿帧？梢苑夯皇强捎锌蔁o(wú)的東西。另一方面它可以劃分系統(tǒng)與外部實(shí)體的界限，是系統(tǒng)設(shè)計(jì)的起點(diǎn)。91Actor的一些注意事項(xiàng)包括人與系統(tǒng)，總是外部的。92用例的一些注意事項(xiàng)是需求分析的第一步。用戶首先關(guān)心功能。用例是對(duì)一個(gè)系統(tǒng)或一個(gè)應(yīng)用的一種單一的使用方式所作的描述,是關(guān)于單個(gè)活動(dòng)者在與系統(tǒng)對(duì)話中所執(zhí)行的處理行為的陳述序列。不是事件流。不是需求規(guī)格說(shuō)明，但反映了主要的功能性需求。識(shí)別用例最好是從分析流開(kāi)始。每個(gè)用例都是獨(dú)立的。用例名用動(dòng)賓結(jié)構(gòu)描述，不要寫(xiě)成一個(gè)名詞。用例是分層的，一般而言，高層/中層用例更有實(shí)際意義。不要將不同的用例混合在一起。用例與編碼：低層的用例可以輔助編碼，高層的不能。擴(kuò)展用例：基礎(chǔ)用例不必知道擴(kuò)展用例的細(xì)節(jié)，只提供擴(kuò)展點(diǎn)。92用例的一些注意事項(xiàng)是需求分析的第一步。用戶首先關(guān)心功能。93倉(cāng)庫(kù)信息系統(tǒng)的用例圖93倉(cāng)庫(kù)信息系統(tǒng)的用例圖94借鑒RUP的UML建模與分析

94借鑒RUP的UML建模與分析

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

留存

分布式處理

安全性

進(jìn)程間通信

消息路由

進(jìn)程控制與同步

交易事務(wù)管理

信息交換

信息的冗余

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

數(shù)據(jù)格式轉(zhuǎn)換96全局分析常見(jiàn)的分析機(jī)制

留存

分布式處理

安全性

進(jìn)程間97局部分析提取分析類轉(zhuǎn)述需求場(chǎng)景整理分析類97局部分析提取分析類98局部分析分析類的類型劃分

眾多實(shí)踐表明，如果立足于軟件功能需求，擬建系統(tǒng)往往在三個(gè)維度易于發(fā)生變化：一、擬建系統(tǒng)和外部要素之間交互的邊界；第二，擬建系統(tǒng)要記錄和維護(hù)的信息；第三，擬建系統(tǒng)在運(yùn)行中的控制邏輯。通常按照這三個(gè)變化因素的維度，將分析類劃分為三種類型：邊界類、控制類、實(shí)體類系統(tǒng)邊界UseCase行為協(xié)調(diào)基本信息98局部分析分析類的類型劃分

眾多實(shí)踐表明，如果立足于軟件功99局部分析99局部分析100局部分析100局部分析101局部分析101局部分析102局部分析整理分析類

分析類是這樣的類：它代表問(wèn)題域中的簡(jiǎn)潔抽象；分析類映射到真實(shí)世界的業(yè)務(wù)概念（并且據(jù)此仔細(xì)命名）。問(wèn)題域是首先產(chǎn)生軟件系統(tǒng)（以及從此而來(lái)的軟件開(kāi)發(fā)活動(dòng)）需求的域。通常，這是特定的業(yè)務(wù)領(lǐng)域，如在線銷售或者客戶關(guān)系管理。然而，務(wù)必注意，問(wèn)題域可能根本不是任何特定業(yè)務(wù)活動(dòng)，但是可能產(chǎn)生需要軟件在其上運(yùn)轉(zhuǎn)的一塊物理硬件─這是嵌入式系統(tǒng)?；旧希袠I(yè)務(wù)軟件開(kāi)發(fā)服務(wù)于某種業(yè)務(wù)需求，自動(dòng)化一個(gè)已有業(yè)務(wù)過(guò)程或者開(kāi)發(fā)具有有意義的軟件組件的新產(chǎn)品。102局部分析整理分析類

分析類是這樣的類：它代表問(wèn)題域中的103分析類的職責(zé)職責(zé)是類和它的客戶之間的契約或者是類對(duì)它的客戶的義務(wù)。本質(zhì)上，職責(zé)是類提供給其他類的服務(wù)。分析類具有直接同類（由它的名稱所表達(dá)）的目的相一致的以及直接同該類正在建模的真實(shí)世界“事物”相一致的非常內(nèi)聚的職責(zé)集合，這一點(diǎn)是至關(guān)重要的。例如ShoppingBasket示例，你將期望該類具有如下職責(zé)：向購(gòu)物籃添加商品；從購(gòu)物籃刪除商品；顯示購(gòu)物籃中的商品。這是內(nèi)聚的職責(zé)集合，一切都是為了維護(hù)客戶選擇的商品集合。它是內(nèi)聚的，因?yàn)樗械穆氊?zé)都朝著相同的目標(biāo)─維護(hù)客戶已經(jīng)選擇的商品集合。實(shí)際上，我們能夠把這些職責(zé)概括為非常高級(jí)層次的職責(zé)“維護(hù)購(gòu)物籃”。同樣，向ShoppingBasket中添加如下職責(zé)：103分析類的職責(zé)職責(zé)是類和它的客戶之間的契約或者是類對(duì)它的104分析類的職責(zé)驗(yàn)證信用卡；接收付款；打印收據(jù)。但這些職責(zé)似乎同購(gòu)物籃的目的或直覺(jué)語(yǔ)法不匹配。它們不是內(nèi)聚的，顯然應(yīng)該賦予其他什么類─可能是類CreditCardCompany、類Checkout以及類ReceiptPrinter。把職責(zé)適當(dāng)?shù)胤峙浣o分析類以最大化每個(gè)類中的內(nèi)聚性，是很重要的。最后，良好的類與其他類之間具有最低數(shù)目的耦合。我們以給定類與其他類具有關(guān)系的數(shù)目來(lái)度量類間的耦合度。類間職責(zé)的平均分布趨向于產(chǎn)生低耦合度。把控制或職責(zé)局限于單一的類趨向于增加到該類的耦合度。104分析類的職責(zé)驗(yàn)證信用卡；105分析類經(jīng)驗(yàn)法則以下是創(chuàng)建形式良好的分析類的一些經(jīng)驗(yàn)法則。每個(gè)類大約3~5個(gè)職責(zé)─典型地，類應(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í)很難取得正確的平衡。如果模型看起來(lái)具有大量的非常小的類，每個(gè)類都具有一個(gè)或者兩個(gè)職責(zé)，那么你應(yīng)該仔細(xì)查看以把一些小的類整合成更大的類。105分析類經(jīng)驗(yàn)法則以下是創(chuàng)建形式良好的分析類的一些經(jīng)驗(yàn)法則106當(dāng)心少數(shù)幾個(gè)非常龐大的類─上述的反面是，模型具有很少的類，但每個(gè)類都是具有職責(zé)數(shù)量（>5）的龐大的類。解決問(wèn)題的策略是依次查看這些類，看看是否每個(gè)類都能夠被分解成為兩個(gè)或者多個(gè)能夠承擔(dān)恰當(dāng)數(shù)目職責(zé)的、更小的類。當(dāng)心“偽類”─偽類其實(shí)是一般的過(guò)程函數(shù)，它偽裝成類。當(dāng)心萬(wàn)能類─存在似乎能夠承擔(dān)任何工作的類?？纯疵Q為“system”和“controller”的類！處理這個(gè)問(wèn)題的策略是看看萬(wàn)能類的職責(zé)是否能夠分解成內(nèi)聚的子集。如果是，每個(gè)這些內(nèi)聚職責(zé)集合可能獨(dú)立成類。這些更小的類協(xié)作以實(shí)現(xiàn)由原始萬(wàn)能類所提供的行為。106當(dāng)心少數(shù)幾個(gè)非常龐大的類─上述的反面是，模型具有很少的107分析類經(jīng)驗(yàn)法則避免深度繼承樹(shù)─設(shè)計(jì)良好的繼承層次的本質(zhì)是繼承層次中每個(gè)抽象層次應(yīng)該具有良好定義的目的。容易添加很多實(shí)際上不能服務(wù)于任何目的層次。實(shí)際上，通常的錯(cuò)誤是使用繼承來(lái)實(shí)現(xiàn)一種功能分解，其中每個(gè)抽象層次恰有一個(gè)職責(zé)！無(wú)論從哪個(gè)方面來(lái)講，這都是無(wú)意義的，是會(huì)導(dǎo)致復(fù)雜的、難以理解的模型。在分析中，類代表業(yè)務(wù)事物，而業(yè)務(wù)事物趨向于形成更寬（不超過(guò)三層）的繼承層次。我們把三層或者更多層次的繼承認(rèn)為是“深度”繼承。107分析類經(jīng)驗(yàn)法則避免深度繼承樹(shù)─設(shè)計(jì)良好的繼承層次的本質(zhì)108第四單元：設(shè)計(jì)模式與軟件設(shè)計(jì)思想108第四單元：設(shè)計(jì)模式與軟件設(shè)計(jì)思想109設(shè)計(jì)模式在實(shí)際開(kāi)發(fā)中的運(yùn)用復(fù)用現(xiàn)有的、高質(zhì)量的、針對(duì)常見(jiàn)的重復(fù)出現(xiàn)問(wèn)題的解決方案。建立通用的術(shù)語(yǔ)以改善團(tuán)隊(duì)內(nèi)部的溝通。將思考轉(zhuǎn)移到更高的視角。判斷是否擁有正確的設(shè)計(jì)，而不僅僅使一個(gè)可以運(yùn)行的設(shè)計(jì)。改善代碼的可修改性。發(fā)現(xiàn)“龐大的繼承體系”的替代方案。109設(shè)計(jì)模式在實(shí)際開(kāi)發(fā)中的運(yùn)用復(fù)用現(xiàn)有的、高質(zhì)量的、針對(duì)常110GoF中的模式分類110GoF中的模式分類111設(shè)計(jì)模式的特點(diǎn)設(shè)計(jì)模式最根本的意圖是適應(yīng)需求變化隔離變化的部分與不變的部分，將之封裝起來(lái)。針對(duì)接口編程，而不要針對(duì)實(shí)現(xiàn)編程達(dá)成高內(nèi)聚合低耦合，提高復(fù)用提倡優(yōu)先使用聚合，而不是繼承111設(shè)計(jì)模式的特點(diǎn)設(shè)計(jì)模式最根本的意圖是適應(yīng)需求變化112例一個(gè)日志記錄工具。目前需要提供一個(gè)日志API，提供客戶方便地調(diào)用。該日志要求被記錄到指定的文本文件中，記錄的內(nèi)容屬于字符串類型，其值由客戶提供?？梢匀菀椎囟x一個(gè)日志對(duì)象。publicclassLog{ publicvoidWrite(stringtarget,stringlog){ //實(shí)現(xiàn)內(nèi)容;}}當(dāng)客戶需要調(diào)用日志的功能時(shí)，可以創(chuàng)建日志對(duì)象，完成日志的記錄：Loglog=newLog();log.Write(“error.log”,“l(fā)og”);112例一個(gè)日志記錄工具。目前需要提供一個(gè)日志API，提供客113113114例我們需要設(shè)計(jì)一個(gè)數(shù)據(jù)庫(kù)組件，它能夠訪問(wèn)SqlServer數(shù)據(jù)庫(kù)。如果用ADO.Net，需要使用如下的對(duì)象：SqlConnection,SqlCommand,SqlDataAdapter等。不用模式的做法：可以直接創(chuàng)建這些對(duì)象：SqlConnectionconnection=new SqlConnection(strConnection);SqlCommandcommand=newSqlCommand(connection);SqlDataAdapteradapter=newSqlDataAdapter();114例我們需要設(shè)計(jì)一個(gè)數(shù)據(jù)庫(kù)組件，它能夠訪問(wèn)SqlSer115策略（Strategy）模式115策略（Strategy）模式116例：電子零售系統(tǒng)該電子零售系統(tǒng)必須處理來(lái)自不同國(guó)家的銷售定單。例如在美國(guó)與加拿大。需求如下：請(qǐng)況過(guò)程美國(guó)據(jù)UPS的價(jià)格計(jì)算運(yùn)費(fèi)使用美國(guó)郵政規(guī)則檢查地址根據(jù)銷售額或服務(wù),按照當(dāng)?shù)囟愂找?guī)則計(jì)算稅費(fèi)金額使用美元處理款項(xiàng)加拿大根據(jù)主要的加拿大托運(yùn)公司的價(jià)格計(jì)算運(yùn)費(fèi)使用加拿大郵政規(guī)則檢查地址根據(jù)銷售額或服務(wù),按照加拿大各省的稅收規(guī)則計(jì)算稅費(fèi)金額(GST和PST)使用加拿大元處理款項(xiàng)116例：電子零售系統(tǒng)該電子零售系統(tǒng)必須處理來(lái)自不同國(guó)家的銷117分析矩陣117分析矩陣118橋接（Bridge）模式118橋接（Bridge）模式119意圖“將抽象部分與它的實(shí)現(xiàn)部分分離，使它們都可以獨(dú)立地變化”。抽象部分是指“不同的事物在概念層次上的聯(lián)系”。分離是指“讓各部分的行為各自獨(dú)立，或至少顯式指出關(guān)聯(lián)”。119意圖120例通過(guò)引入一個(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方法。120例通過(guò)引入一個(gè)Rectangle121需求變化用戶要求支持另一種形狀——圓形。121需求變化用戶要求支持另一種形狀——圓形。122識(shí)別變化首先識(shí)別出“什么在發(fā)生變化”。在上述的例子中，變化點(diǎn)是“不同類型的形狀”和“不同類型的畫(huà)圖程序”。共同的“概念”則是“形狀”和“畫(huà)圖程序”。用Shape類來(lái)封裝擁有的形狀的概念。形狀有責(zé)任知道如何畫(huà)自己。Drawing對(duì)象負(fù)責(zé)畫(huà)線和圓。122識(shí)別變化首先識(shí)別出“什么在發(fā)生變化”。在上述的例子中，123描述變化下一步是描述出現(xiàn)的特定變化：Shape類擁有矩形和圓形。畫(huà)圖程序分別擁有一個(gè)基于DP1的對(duì)象（V1Drawing）和一個(gè)基于DP2的對(duì)象（V2Drawing）。123描述變化下一步是描述出現(xiàn)的特定變化：Shape類擁有矩124橋接模式124橋接模式125命令（command）模式125命令（command）模式126意圖將一個(gè)請(qǐng)求封裝為一個(gè)對(duì)象，從而使你可用不同的請(qǐng)求對(duì)客戶進(jìn)行參數(shù)化；對(duì)請(qǐng)求排隊(duì)或記錄請(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ì)者無(wú)法知道請(qǐng)求的接受者或執(zhí)行的操作。命令模式通過(guò)將請(qǐng)求本身變成一個(gè)對(duì)象來(lái)使工具箱對(duì)象可向未指定的應(yīng)用對(duì)象提出請(qǐng)求。這個(gè)對(duì)象可被存儲(chǔ)并像其他的對(duì)象一樣被傳遞。這一模式的關(guān)鍵是一個(gè)抽象的Command類。126意圖127常用的軟件架構(gòu)風(fēng)格及適用情況分析軟件架構(gòu)軟件框架常見(jiàn)的架構(gòu)風(fēng)格127常用的軟件架構(gòu)風(fēng)格及適用情況分析軟件架構(gòu)128軟件架構(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)需求。128軟件架構(gòu)概論系統(tǒng)架構(gòu)是一個(gè)軟件系統(tǒng)從整體到部分的最高層129建造一個(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ò)慎重的研究和考察。129建造一個(gè)系統(tǒng)所作出的最高層次的、以后難以更改的，商業(yè)的130架構(gòu)的目標(biāo)可靠性（Reliable）：軟件系統(tǒng)對(duì)于用戶的商業(yè)經(jīng)營(yíng)和管理來(lái)說(shuō)極為重要，因此軟件系統(tǒng)必須非常可靠。安全性（Secure）：軟件系統(tǒng)所承擔(dān)的交易的商業(yè)價(jià)值極高，系統(tǒng)的安全性非常重要?？缮炜s性（Scalable）：軟件必須能夠在用戶的使用率、用戶的數(shù)目增加很快的情況下，保持合理的性能。只有這樣，才能適應(yīng)用戶的市場(chǎng)擴(kuò)展得可能性。130架構(gòu)的目標(biāo)可靠性（Reliable）：131架構(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āng)允許導(dǎo)入新技術(shù)，從而對(duì)現(xiàn)有系統(tǒng)進(jìn)行功能和性能的擴(kuò)展可維護(hù)性（Maintainable）：軟件系統(tǒng)的維護(hù)包括兩方面，一是排除現(xiàn)有的錯(cuò)誤，二是將新的軟件需求反映到現(xiàn)有系統(tǒng)中去。一個(gè)易于維護(hù)的系統(tǒng)可以有效地降低技術(shù)支持的花費(fèi)。131架構(gòu)的目標(biāo)可定制化（Customizable）：132客戶體驗(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ī)非常重要。132133架構(gòu)的種類根據(jù)我們關(guān)注的角度不同，可以將架構(gòu)分成三種：邏輯架構(gòu)物理架構(gòu)系統(tǒng)架構(gòu)133架構(gòu)的種類根據(jù)我們關(guān)注的角度不同，可以將架構(gòu)分成三種：134邏輯架構(gòu)軟件系統(tǒng)中元件之間的關(guān)系，比如用戶界面，數(shù)據(jù)庫(kù)，外部系統(tǒng)接口，商業(yè)邏輯元件等等。134邏輯架構(gòu)軟件系統(tǒng)中元件之間的關(guān)系，比如用戶界面，數(shù)據(jù)庫(kù)135物理架構(gòu)軟件元件是怎樣放到硬件上的下圖描述了一個(gè)分布于北京和上海的分布式系統(tǒng)的物理架構(gòu)，圖中所有的元件都是物理設(shè)備，包括網(wǎng)絡(luò)分流器、代理服務(wù)器、WEB服務(wù)器、應(yīng)用服務(wù)器、報(bào)表服務(wù)器、整合服務(wù)器、存儲(chǔ)服務(wù)器、主機(jī)等等。135物理架構(gòu)軟件元件是怎樣放到硬件上的136系統(tǒng)架構(gòu)系統(tǒng)的非功能性特征，如可擴(kuò)展性、可靠性、強(qiáng)壯性、靈活性、性能等。系統(tǒng)架構(gòu)的設(shè)計(jì)要求架構(gòu)師具備軟件和硬件的功能和性能的過(guò)硬知識(shí)，這一工作是架構(gòu)設(shè)計(jì)工作中最困難的工作。136系統(tǒng)架構(gòu)系統(tǒng)的非功能性特征，如可擴(kuò)展性、可靠性、強(qiáng)壯性137架構(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ì)文檔。137架構(gòu)的兩要素元件劃分和設(shè)計(jì)決定。138軟件框架什么是框架框架與架構(gòu)的區(qū)別常見(jiàn)的框架138軟件框架什么是框架139框架什么是框架？框架，即framework。是某種應(yīng)用的半成品，就是一組組件，供選用完成自己的系統(tǒng)。簡(jiǎn)單說(shuō)就是使用別人搭好的舞臺(tái)，你來(lái)做表演。而且，框架一般是成熟的，不斷升級(jí)的軟件?？蚣芘c架構(gòu)的區(qū)別？并無(wú)明確的定義，但一般從層的觀點(diǎn)看，認(rèn)為框架是底層的，接近系統(tǒng)的。軟件開(kāi)發(fā)者在其上構(gòu)建自己的軟件架構(gòu)，開(kāi)發(fā)自己的運(yùn)用程序。139框架什么是框架？140為什么要用框架因?yàn)檐浖到y(tǒng)發(fā)展到今天已經(jīng)很復(fù)雜了，特別是服務(wù)器端軟件，設(shè)計(jì)到的知識(shí)，內(nèi)容，問(wèn)題太多。在某些方面使用成熟的框架，可以避免重復(fù)做已有的基礎(chǔ)工作，而只需要集中精力完成系統(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ù)邏輯之間的中間層。140為什么要用框架因?yàn)檐浖到y(tǒng)發(fā)展到今天已經(jīng)很復(fù)雜了，特別141常見(jiàn)的框架常見(jiàn)的JAVA框架常見(jiàn)的.Net框架其它基于C++的框架141常見(jiàn)的框架常見(jiàn)的JAVA框架142常見(jiàn)的JAVA框架EJBWAFStrutsTurbineCOCOONECHOJATOTCFSpringHibernateIBatisJSF142常見(jiàn)的JAVA框架EJB143.NET框架.NET框架是創(chuàng)建、部署和運(yùn)行Web服務(wù)及其他應(yīng)用程序的一個(gè)環(huán)境。它包括三個(gè)主要部分：公共語(yǔ)言運(yùn)行時(shí)、框架類和ASP.NET。.NET框架對(duì)Web站點(diǎn)的支持：ASP.NET在編寫(xiě)Windows軟件（使用ATL/COM、MFC、VB或標(biāo)準(zhǔn)Win32）方面，與當(dāng)前創(chuàng)建應(yīng)用程序的方式相比.NET都具有的優(yōu)勢(shì)。143.NET框架.NET框架是創(chuàng)建、部署和運(yùn)行Web144C++框架ACEBOOSTMFCATLQTwxWidgets…144C++框架ACE145不同層次的模式架構(gòu)模式(ArchitecturalPattern)設(shè)計(jì)模式(DesignPattern)代碼模式(CodingPattern)145不同層次的模式架構(gòu)模式(ArchitecturalP146區(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)的總體布局和大尺度框架。146區(qū)別：在于三種不同的模式存在于它們各自的抽象層次和具體147幾種典型的架構(gòu)模式系統(tǒng)軟件分層(Layer)管道和過(guò)濾器(PipesandFilters)黑板(Blackboard)開(kāi)發(fā)分布式軟件經(jīng)紀(jì)人(Broker)客戶/服務(wù)器（Client/Server）點(diǎn)對(duì)點(diǎn)（PeertoPeer）交互軟件模型-視圖-控制器（Model-View-Controller）顯示-抽象-控制（Presentation-Abstraction-COntrol）147幾種典型的架構(gòu)模式系統(tǒng)軟件148其它面向?qū)ο箫L(fēng)格(ADT)基于消息廣播且面向圖形用戶界面的Chiron2風(fēng)格基于事件的隱式調(diào)用風(fēng)格(Event-based,ImplicitInvocation)…148其它面向?qū)ο箫L(fēng)格(ADT)149分層(Layer)從不同的層次來(lái)觀察系統(tǒng)，處理不同層次問(wèn)題的對(duì)象被封裝到不同的層中。

軟件為什么要分層？

為了實(shí)現(xiàn)“高內(nèi)聚、低耦合”。把問(wèn)題劃分開(kāi)來(lái)各個(gè)解決，易于控制，易于延展，易于分配資源…面向?qū)ο蟮?、基于模塊化的組件設(shè)計(jì)需要能夠方便地修改應(yīng)用程序的各個(gè)部分。完成這一目標(biāo)的一種好方法就是在層上工作，將一個(gè)應(yīng)用程序的主要功能分離到不同的層或者級(jí)中。149分層(Layer)從不同的層次來(lái)觀察系統(tǒng)，處理不同層次150分層模型從本質(zhì)上講，層代表了一個(gè)應(yīng)用程序主要的功能。一般地，我們將應(yīng)用程序功能分為三個(gè)方面，對(duì)應(yīng)3層架構(gòu)模式。它們是數(shù)據(jù)層（datalayer）、商務(wù)層（businesslayer）和表示層（presentationlayer）。數(shù)據(jù)層：包含數(shù)據(jù)存儲(chǔ)和與它交互的組件或服務(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è)過(guò)程的一部分，中間層負(fù)責(zé)處理來(lái)自數(shù)據(jù)存儲(chǔ)或者發(fā)送給數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)。150分層模型從本質(zhì)上講，層代表了一個(gè)應(yīng)用程序主要的功能。一151表示層：從中間層獲得信息并顯示給用戶。該層同時(shí)也負(fù)責(zé)和用戶進(jìn)行交互，比較返回的信息并將信息回送給中間層進(jìn)行處理。數(shù)據(jù)層從數(shù)據(jù)庫(kù)中獲得較為原始的數(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ù)層邏輯。151表示層：從中間層獲得信息并顯示給用戶。該層同時(shí)也負(fù)責(zé)和152管道和過(guò)濾器（PipesandFilters）管道和過(guò)濾器架構(gòu)模式是為處理數(shù)據(jù)流的系統(tǒng)提供的一種模式。它是由過(guò)濾器和管道組成的.每個(gè)處理步驟都被封裝在一個(gè)過(guò)濾器組件中，數(shù)據(jù)通過(guò)相鄰過(guò)濾器之間的管道進(jìn)行傳輸。每個(gè)過(guò)濾器可以單獨(dú)修改，功能單一，并且它們之間的順序可以進(jìn)行配置。152管道和過(guò)濾器（PipesandFilters）管道153一個(gè)著名的例子是傳統(tǒng)的編譯器。傳統(tǒng)的編譯器一直被認(rèn)為是一種管道系統(tǒng)，在該系統(tǒng)中，一個(gè)階段（包括詞法分析、語(yǔ)法分析、語(yǔ)義分析和代碼生成）的輸出是另一個(gè)階段的輸入。153一個(gè)著名的例子是傳統(tǒng)的編譯器。傳統(tǒng)的編譯器一直被認(rèn)為是154問(wèn)題：一個(gè)必須處理或轉(zhuǎn)換輸入數(shù)據(jù)流的系統(tǒng)。把這樣的系統(tǒng)作為單個(gè)組件實(shí)現(xiàn)是不容易的：系統(tǒng)必須由幾個(gè)開(kāi)發(fā)人員同時(shí)進(jìn)行協(xié)作開(kāi)發(fā)，整個(gè)系統(tǒng)任務(wù)自然就被分解為幾個(gè)處理階段，而且需求很容易變動(dòng)。因此你就要通過(guò)替換或重新排序處理步驟來(lái)為將來(lái)的靈活性作規(guī)劃。通過(guò)加入這樣的靈活性，采用現(xiàn)有處理組件構(gòu)建是可以辦到的。系統(tǒng)的設(shè)計(jì)尤其是處理步驟的內(nèi)部連接，必須考慮以下因素：未來(lái)系統(tǒng)的升級(jí)通過(guò)替換某些處理步驟，或重組步驟。不同的語(yǔ)境中小的處理步驟要比大的組件更易于重用。不相連的處理步驟不可共享信息。存在不同的輸入數(shù)據(jù)源，可以用多種方式輸出或存放最終結(jié)果。154問(wèn)題：155解決方案與結(jié)構(gòu)管道和過(guò)濾器體系架構(gòu)模式把系統(tǒng)任務(wù)分成為幾個(gè)獨(dú)立的處理步驟。這些步驟采用通過(guò)系統(tǒng)的數(shù)據(jù)流連接。一個(gè)步驟的輸出是下一個(gè)步驟的輸入。每個(gè)處理步驟由一個(gè)過(guò)濾器組件實(shí)現(xiàn)，它處理或者轉(zhuǎn)化數(shù)據(jù)，并且系統(tǒng)的輸入可以是多種數(shù)據(jù)源。這種體系架構(gòu)模式具有許多特性：過(guò)濾器是獨(dú)立運(yùn)行的部件。也就是除了輸入和輸出外，每個(gè)過(guò)濾器不受任何其他過(guò)濾器運(yùn)行的影響。在設(shè)計(jì)上，過(guò)濾器之間不共享任何狀態(tài)信息。獨(dú)立性還表現(xiàn)在它對(duì)其處理的上游和下游連接的過(guò)濾器是"無(wú)知"的.它的設(shè)計(jì)和使用不對(duì)與其連接的任何過(guò)濾器施加限制，唯一關(guān)心的是其輸入數(shù)據(jù)的，然后進(jìn)行加工處理，最后產(chǎn)生數(shù)據(jù)輸出。155解決方案與結(jié)構(gòu)管道和過(guò)濾器體系架構(gòu)模式把系統(tǒng)任務(wù)分成為156優(yōu)點(diǎn)與缺點(diǎn)優(yōu)點(diǎn)：結(jié)構(gòu)簡(jiǎn)單：系統(tǒng)的行為是所有過(guò)濾器行為的簡(jiǎn)單復(fù)合。系統(tǒng)易于維護(hù)和增強(qiáng)：增加新過(guò)濾器，替換舊過(guò)濾器。支持復(fù)用：過(guò)濾器只同其輸入、輸出端口的數(shù)據(jù)相關(guān)。各過(guò)濾器可以并發(fā)運(yùn)行。缺點(diǎn)：容易導(dǎo)致批處理方式：每個(gè)過(guò)濾器從輸入數(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)，過(guò)濾器之間的數(shù)據(jù)傳輸率較低，而且每個(gè)過(guò)濾器都要作類似的數(shù)據(jù)打包和解包的工作。156優(yōu)點(diǎn)與缺點(diǎn)優(yōu)點(diǎn)：157黑板(Blackboard)又稱看板模式：在這種架構(gòu)中，有兩種不同的構(gòu)件：一種是表示當(dāng)前狀態(tài)中心數(shù)據(jù)結(jié)構(gòu)；另一種是一種相互獨(dú)立的構(gòu)件，這些構(gòu)件對(duì)中心數(shù)據(jù)進(jìn)行操作。這種架構(gòu)主要用于數(shù)據(jù)庫(kù)和人工智能系統(tǒng)的開(kāi)發(fā)。模式識(shí)別、數(shù)據(jù)挖掘。157黑板(Blackboard)又稱看板模式：在這種架構(gòu)中158經(jīng)紀(jì)人(Broker)客戶和服務(wù)器通過(guò)一個(gè)經(jīng)紀(jì)人部件進(jìn)行通信，經(jīng)紀(jì)人負(fù)責(zé)協(xié)調(diào)客戶和服務(wù)器之間的操作，并且為客戶和服務(wù)器發(fā)送請(qǐng)求和結(jié)果信息。158經(jīng)紀(jì)人(Broker)客戶和服務(wù)器通過(guò)一個(gè)經(jīng)紀(jì)人部件進(jìn)159代理程序駐留在一個(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ù)載平衡。159代理程序駐留在一個(gè)不應(yīng)該頻繁更改的、眾所周知的位置。已160客戶/服務(wù)器（Client/Server）系統(tǒng)分為客戶和服務(wù)器，服務(wù)器一直處于偵聽(tīng)的狀態(tài)，客戶主動(dòng)連接服務(wù)器，每個(gè)服務(wù)器可以為多個(gè)客戶服務(wù)。160客戶/服務(wù)器（Client/Server）系統(tǒng)分為客戶161優(yōu)缺點(diǎn)優(yōu)點(diǎn)：結(jié)構(gòu)簡(jiǎn)單，系統(tǒng)中不同類型的任務(wù)分別由客戶和服務(wù)器承擔(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風(fēng)格的系統(tǒng)中，構(gòu)件之間的連接通過(guò)（遠(yuǎn)程）過(guò)程調(diào)用，接近于代碼一級(jí)，表達(dá)能力較弱。161優(yōu)缺點(diǎn)優(yōu)點(diǎn)：162點(diǎn)對(duì)點(diǎn)（PeertoPeer）系統(tǒng)中的節(jié)點(diǎn)都處于平等的地位，每個(gè)節(jié)點(diǎn)都可以連接其他節(jié)點(diǎn)。在這種架構(gòu)中，一般需要由一個(gè)中心服務(wù)器完成發(fā)現(xiàn)和管理節(jié)點(diǎn)的操作。ICQ以及WebService技術(shù)的大多數(shù)應(yīng)用，都是典型的點(diǎn)對(duì)點(diǎn)結(jié)構(gòu)。162點(diǎn)對(duì)點(diǎn)（PeertoPeer）系統(tǒng)中的節(jié)點(diǎn)都處于平163模型-視圖-控制器（MVC）當(dāng)應(yīng)用程序的用戶界面非常復(fù)雜，且關(guān)于用戶界面的需求很容易變化時(shí)，我們可以把交互類型的軟件抽象成模型、視圖和控制器這三類組件單元，這種抽象可以很好地分離用戶界面和業(yè)務(wù)邏輯，適應(yīng)變化的需求。大多數(shù)現(xiàn)代交互軟件都在一定程度上符合這一架構(gòu)模型的特點(diǎn)。MVC模式最吸引人之處在于它迫使用戶必須抽象自己的代碼，把項(xiàng)目分為表示、邏輯和控制三部分,每部分間的關(guān)聯(lián)較小。以MVC模式構(gòu)造軟件,可以使得軟件結(jié)構(gòu)靈活、重用性好、擴(kuò)展性佳。163模型-視圖-控制器（MVC）當(dāng)應(yīng)用程序的用戶界面非常復(fù)164模型—視圖—控制器交互的示意圖164模型—視圖—控制器交互的示意圖165模型：視圖：控制器:模型：模型表示應(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)展示給用戶,具體的顯示方法由視圖負(fù)責(zé),因此一個(gè)模型可以適用多個(gè)不同的視圖。在模型狀態(tài)改變后,通過(guò)模型和視圖之間的協(xié)議,視圖得知這種改變并修改自己的顯示。對(duì)于用戶的輸入,視圖將它們交給控制器處理?？刂破?控制器負(fù)責(zé)交互和將用戶輸入的數(shù)據(jù)導(dǎo)入模型,它還利用用戶的輸入將應(yīng)用轉(zhuǎn)向其他視圖。一些非持久的臨時(shí)數(shù)據(jù)也應(yīng)該在視圖中存取。165模型：視圖：控制器:模型：166SOA的架構(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ù)。166SOA的架構(gòu)的特點(diǎn)服務(wù)（Service）167OOvs.SOA–OO的擴(kuò)展遇到了挑戰(zhàn)隨著時(shí)間的推移，接口繼承的復(fù)雜度在累積隨著系統(tǒng)間距離的延伸，調(diào)用成本在上升，類型系統(tǒng)的不同步擴(kuò)展組件的功能成本高，不可確定未來(lái)需求，不可堆疊的擴(kuò)展方式重用與標(biāo)準(zhǔn)化，重用是OO的第一原則，難以維持和維護(hù)復(fù)雜的重用標(biāo)準(zhǔn)和機(jī)制167OOvs.SOA168–OOvs.SOAOO仍然適用于服務(wù)的開(kāi)發(fā)明顯的性能優(yōu)勢(shì)成熟的設(shè)計(jì)與開(kāi)發(fā)方法SOA適用于系統(tǒng)的互聯(lián)互操作性的要求強(qiáng)于性能的要求168–OOvs.SOA169SOA既不是一種語(yǔ)言，也不是一種具體的技術(shù)，它是一種新的軟件系統(tǒng)架構(gòu)模型。SOA最主要的應(yīng)用場(chǎng)合在于解決在Internet環(huán)境下的不同商業(yè)應(yīng)用之間的業(yè)務(wù)集成問(wèn)題。SOA架構(gòu)的出現(xiàn)為企業(yè)系統(tǒng)架構(gòu)提供了更加靈活的構(gòu)建方式，如果企業(yè)架構(gòu)設(shè)計(jì)師基于SOA來(lái)構(gòu)建系統(tǒng)架構(gòu)，就可以從底層架構(gòu)的級(jí)別來(lái)保證整個(gè)系統(tǒng)的松耦合性以及靈活性，這都為未來(lái)企業(yè)業(yè)務(wù)邏輯的擴(kuò)展打好了基礎(chǔ)。169SOA既不是一種語(yǔ)言，也不是一種具體的技術(shù)，它是一種170特性：松耦合性松耦合性要求SOA架構(gòu)中的不同服務(wù)之間應(yīng)該保持一種松耦合的關(guān)系，也就是應(yīng)該保持一種相對(duì)獨(dú)立無(wú)依賴的關(guān)系；位置透明性位置透明性要求S