面向?qū)ο筌浖軜?gòu)設(shè)計(jì)

1、面向?qū)ο筌浖軜?gòu)設(shè)計(jì)Mail: Msn: 1第一單元：軟件生命周期與軟件架構(gòu)介紹2第二單元：技術(shù)架構(gòu)視圖面向?qū)ο蟪绦蛟O(shè)計(jì)原則與模式 59用GRASP模式指導(dǎo)設(shè)計(jì)62領(lǐng)域模型96面向?qū)ο笤O(shè)計(jì)的基本原則132第三單元：用UML輔助系統(tǒng)分析與設(shè)計(jì)177UML簡(jiǎn)介及常見(jiàn)疑難問(wèn)題辨析178借鑒RUP的UML建模與分析213第四單元：設(shè)計(jì)模式與軟件設(shè)計(jì)思想267設(shè)計(jì)模式268常用的軟件架構(gòu)風(fēng)格及適用情況分析391SOA 及分層架構(gòu)設(shè)計(jì)443第五單元：架構(gòu)設(shè)計(jì)實(shí)踐456目錄2第一單元：軟件生命周期與軟件架構(gòu)介紹3IT行業(yè)的人才結(jié)構(gòu)與軟件架構(gòu)師的定位軟件架構(gòu)師應(yīng)掌握的知識(shí)體系軟件架構(gòu)設(shè)計(jì)的特點(diǎn)、層次、分類(lèi)軟件

2、架構(gòu)的主要理論、方向和趨勢(shì)軟件工廠(chǎng)，實(shí)現(xiàn)軟件開(kāi)發(fā)的產(chǎn)業(yè)化4系統(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)。軟件架構(gòu)師的定位5角色軟件架構(gòu)師Software Architect定義主導(dǎo)系統(tǒng)全局分析設(shè)計(jì)和實(shí)施、負(fù)責(zé)軟件構(gòu)架和關(guān)鍵技術(shù)決策的角色6職責(zé)領(lǐng)導(dǎo)與協(xié)調(diào)整個(gè)項(xiàng)目中

3、的技術(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ī)則，平衡各類(lèi)涉眾的不同關(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專(zhuān)業(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)域都

4、有經(jīng)驗(yàn)，包括徹底地理解項(xiàng)目需求，開(kāi)展分析設(shè)計(jì)之類(lèi)軟件工程活動(dòng)等。具備領(lǐng)導(dǎo)素質(zhì)，以在各小組之間推進(jìn)技術(shù)工作，并在項(xiàng)目壓力下做出牢靠的關(guān)鍵決策。擁有優(yōu)秀的溝通能力，用以進(jìn)行說(shuō)服、鼓勵(lì)和指導(dǎo)等活動(dòng)，并贏(yíng)得項(xiàng)目成員的信任。8以目標(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軟件架構(gòu)師作為整個(gè)軟件系統(tǒng)結(jié)構(gòu)的總設(shè)計(jì)師，其知識(shí)體系、技能和經(jīng)驗(yàn)決定了軟件系統(tǒng)的可靠性、安全性、可維護(hù)性、可擴(kuò)展性和可移植性等方

5、面的性能。因此一個(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ì)低些。軟件架構(gòu)師的知識(shí)體系10成為一名合格的軟件架構(gòu)師必須具備的知識(shí)信息系統(tǒng)綜合知識(shí)體系軟件架構(gòu)知識(shí)體系11MFC，MSF，MOF，RUP，J2E

6、E，Spring，SOA，JUnit，ORM，.NetMVC，UML，XML，Corba，MDA，MDD，Web-ServiceRSS，Web2.0，AJAX，Serverlet，HibernateIOC， AOPRuby On RailsRupBPELWorkflow EngineLBSOracleCMMIMQ？12思考、思考、再思考深入理解、準(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ì)方案的正確性軟件架構(gòu)師在干

7、什么？13軟件知識(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)域的主要理論、流派、框架。軟件架構(gòu)師的知識(shí)結(jié)構(gòu)14業(yè)務(wù)知識(shí)深入了解系統(tǒng)建設(shè)的業(yè)務(wù)需求。了解系統(tǒng)的非功能需求和運(yùn)行維護(hù)需求。了解企業(yè) IT 公共設(shè)施、網(wǎng)絡(luò)環(huán)境、外部系統(tǒng)。軟件架構(gòu)師的知識(shí)結(jié)構(gòu)15基于框架的思維架構(gòu)設(shè)計(jì)的層次（Enterprise， Application， etc）IT 的生命周期（What， Why， Where， How， Wh

8、en， etc）成功經(jīng)驗(yàn)以及方法論的指導(dǎo)合理把握技術(shù)細(xì)節(jié)把握各個(gè)層次應(yīng)有的內(nèi)容合理忽略不應(yīng)有的技術(shù)細(xì)節(jié)軟件架構(gòu)師的思維方式16風(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)秀的方案軟件架構(gòu)師的思維方式17(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)審方

9、法、開(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í)。信息系統(tǒng)綜合知識(shí)體系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)的法律和規(guī)定等方面的知識(shí)。(8)數(shù)學(xué)和英語(yǔ)：至少具有大學(xué)以上的數(shù)學(xué)和英語(yǔ)基礎(chǔ)知識(shí)。19(1)系統(tǒng)計(jì)劃：包括項(xiàng)目的提出和可行

10、性分析、系統(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)品線(xiàn)和系統(tǒng)演化等。(3)設(shè)計(jì)模式：包括設(shè)計(jì)模式的概念、組成、分類(lèi)和實(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ù)建模和逆向工程等。軟件架構(gòu)知識(shí)

11、體系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)開(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)的訪(fǎ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根據(jù)軟件架構(gòu)師的

12、職責(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)用，精通Web Service，熟練掌握流行的架構(gòu)。 軟件架構(gòu)師的任職條件22(5)對(duì)設(shè)計(jì)模式有深刻的理解，并能在此基礎(chǔ)上設(shè)計(jì)出適合產(chǎn)品

13、特性和質(zhì)量屬性的框架。(6)具有面向?qū)ο蟮姆治?、設(shè)計(jì)和開(kāi)發(fā)能力，精通UML和XML，能熟練使用Rational Rose、PowerDesigner等工具進(jìn)行設(shè)計(jì)。 (7)具有良好的團(tuán)隊(duì)意識(shí)和協(xié)作精神，有較強(qiáng)的溝通能力和書(shū)面表達(dá)能力。(8)具有旺盛的精力和學(xué)習(xí)能力，能快速掌握新技術(shù)和新方法。 23業(yè)務(wù)應(yīng)用層 (Business Application)由應(yīng)用開(kāi)發(fā)者開(kāi)發(fā)應(yīng)用框架層 (Application Framework)特定領(lǐng)域框架層跨領(lǐng)域框架層基礎(chǔ)框架層 (Foundation Framework)操作系統(tǒng)層架構(gòu)的分層2425軟件體系結(jié)構(gòu)至少有十幾種思想流派。Zachman框架開(kāi)放分布式

14、處理領(lǐng)域分析Rational41視圖模型軟件體系結(jié)構(gòu)風(fēng)格供應(yīng)商驅(qū)動(dòng)的方案Sun Enterprise JavaBeansMS .Net 體系軟件體系結(jié)構(gòu)2627構(gòu)件可以最大程度的進(jìn)行互操作和重用。對(duì)系統(tǒng)和處理方式加以標(biāo)準(zhǔn)化，只是增強(qiáng)軟件可操作性和重用性的一種權(quán)宜之計(jì)，并不能徹底解決問(wèn)題。分布式處理：借助計(jì)算機(jī)網(wǎng)絡(luò)將分布在不同地點(diǎn)的構(gòu)件(對(duì)象)組織在一起，進(jìn)行信息處理。分布式處理中的構(gòu)件可能由不同的廠(chǎng)商開(kāi)發(fā)、生產(chǎn)，因而構(gòu)件之間可能存在不一致的接口；另外，構(gòu)件之間的通信也可能使用不同的協(xié)議。這種兼容異質(zhì)成分的分布式處理，稱(chēng)為開(kāi)放分布式處理。開(kāi)放分布式處理（ODP）28ISO/ITUT RMODP定

15、義的抽象層次(視角)：企業(yè)視點(diǎn)(Enterprise Viewpoint)purpose， scope and policies信息視點(diǎn)(Information Viewpoint)semantics of information and information processing計(jì)算視點(diǎn)(Computational Viewpoint)functional decomaosition工程視點(diǎn)(Engineering Viewpoint)infrastructure required to support distribution技技術(shù)視點(diǎn)(Technology Viewpoint )cho

16、ices of technology for implementationRMODP的元模型體系29是一種支持軟件復(fù)用的系統(tǒng)的管理過(guò)程。將項(xiàng)目專(zhuān)有需求轉(zhuǎn)化為一般的領(lǐng)域需求。通用功能被用來(lái)做水平框架和可復(fù)用軟件體系結(jié)構(gòu)的基礎(chǔ)。領(lǐng)域分析30MVC風(fēng)格管道過(guò)濾器風(fēng)格客戶(hù)服務(wù)器風(fēng)格層次系統(tǒng)倉(cāng)儲(chǔ)（數(shù)據(jù)庫(kù)和黑板）風(fēng)格面向?qū)ο箫L(fēng)格基于消息廣播且面向圖形用戶(hù)界面的Chiron2風(fēng)格基于事件的隱式調(diào)用風(fēng)格軟件體系結(jié)構(gòu)風(fēng)格31調(diào)研已有的成功參考架構(gòu)和相關(guān)模式提出系統(tǒng)邏輯架構(gòu)，包括分層的整體邏輯架構(gòu)、子系統(tǒng)/模塊組成以及邊界劃分根據(jù)。討論邏輯架構(gòu)的依據(jù)、優(yōu)缺點(diǎn)、以及已經(jīng)考慮和參考的其它方案。設(shè)計(jì)相關(guān)子架構(gòu)，包括：數(shù)

17、據(jù)架構(gòu)、子系統(tǒng)架構(gòu)、安全架構(gòu)、網(wǎng)絡(luò)架構(gòu)等。驗(yàn)證架構(gòu)設(shè)計(jì)、確認(rèn)能夠滿(mǎn)足業(yè)務(wù)需求和其他關(guān)鍵指標(biāo)，如性能要求、費(fèi)用限制等。軟件架構(gòu)設(shè)計(jì)過(guò)程舉例32處于軟件系統(tǒng)建設(shè)的上游需要全面考慮多方面的因素對(duì)于同一個(gè)問(wèn)題，可以有多種設(shè)計(jì)結(jié)果是在各種制約條件下取得的較好折衷方案科學(xué) + 經(jīng)驗(yàn) + 藝術(shù)“系統(tǒng)架構(gòu)”往往被濫用軟件架構(gòu)設(shè)計(jì)的一些特點(diǎn)需求分析架構(gòu)設(shè)計(jì)系統(tǒng)設(shè)計(jì)系統(tǒng)開(kāi)發(fā)測(cè)試上線(xiàn)33軟件架構(gòu)的層次34軟件架構(gòu)的分類(lèi)35軟件架構(gòu) 巨大的知識(shí)海洋門(mén)檻相對(duì)較高、職業(yè)生涯非常長(zhǎng)相對(duì)獨(dú)立于技術(shù)的新陳代謝適合于喜歡學(xué)習(xí)的人不斷學(xué)習(xí)、增加積累、注重經(jīng)驗(yàn)注意學(xué)習(xí)方法論、框架不斷增加各種系統(tǒng)架構(gòu)的知識(shí)經(jīng)驗(yàn)積累非常重要成為軟件架構(gòu)

18、師的途徑36在與高手和同行合作中提高水平與高手的合作是最佳途徑同行之間的交流也非常有效在每一個(gè)項(xiàng)目中進(jìn)行創(chuàng)新 成為軟件架構(gòu)師的途徑37RUP與XPAgile與CMMMSF軟件生命周期進(jìn)程模型38能夠較好地解決：軟件項(xiàng)目復(fù)雜性和一致一方面的問(wèn)題傳統(tǒng)的瀑布式開(kāi)發(fā)39無(wú)法解決：軟件項(xiàng)目可變性和不可視性方面的問(wèn)題瀑布式開(kāi)發(fā)推遲了風(fēng)險(xiǎn)的規(guī)避40最早的迭代觸及最重大的風(fēng)險(xiǎn)(例如需求或項(xiàng)目可行性風(fēng)險(xiǎn))。每次迭代產(chǎn)出一個(gè)可執(zhí)行(可以通過(guò)測(cè)試等較客觀(guān)的途徑加以驗(yàn)證)的交付，是系統(tǒng)的一個(gè)增量。每次迭代都包含集成與測(cè)試。將瀑布開(kāi)發(fā)迭代地應(yīng)用于系統(tǒng)增量41迭代式開(kāi)發(fā)促進(jìn)風(fēng)險(xiǎn)規(guī)避42嚴(yán)重的風(fēng)險(xiǎn)在(項(xiàng)目)大規(guī)模投入之前被

19、解決初期的迭代能獲取更早的用戶(hù)反饋測(cè)試與集成是連續(xù)的(增量式)客觀(guān)(可驗(yàn)證)的里程碑提供了短期的焦點(diǎn)進(jìn)度的度量直接依靠對(duì)實(shí)施成果的評(píng)估(而非主觀(guān)的估計(jì))部分的實(shí)現(xiàn)可以被先行部署迭代式開(kāi)發(fā)的特點(diǎn)43在RUP先啟階段的迭代中，項(xiàng)目組必須解決開(kāi)發(fā)目標(biāo)與范圍、以及技術(shù)和商業(yè)可行性的根本風(fēng)險(xiǎn)值不值得做，能不能做。而到了精化階段的迭代，項(xiàng)目組關(guān)注的焦點(diǎn)則轉(zhuǎn)到構(gòu)架風(fēng)險(xiǎn)上可否大量投入去做。進(jìn)入項(xiàng)目中成本最高的構(gòu)建階段后，控制成本、進(jìn)度和開(kāi)發(fā)質(zhì)量的風(fēng)險(xiǎn)將成為所有成員的責(zé)任準(zhǔn)備好交付給用戶(hù)了?最后到了遷移階段，項(xiàng)目組將面臨從客戶(hù)和用戶(hù)方面引入的各種風(fēng)險(xiǎn)(日程安排、需求變更等)客戶(hù)是否滿(mǎn)意。迭代：風(fēng)險(xiǎn)驅(qū)動(dòng)的開(kāi)發(fā)模型

20、44RUP、XP、Agile 都強(qiáng)調(diào)迭代開(kāi)發(fā)的方式 45rational統(tǒng)一開(kāi)發(fā)過(guò)程 rational公司提供的軟件開(kāi)發(fā)過(guò)程方法，RUP告訴你軟件開(kāi)發(fā)應(yīng)該做那些事情，分為哪些階段，每件事情應(yīng)該做到什么程度。RUP基本是一種根據(jù)風(fēng)險(xiǎn)大小安排次序的迭代過(guò)程，強(qiáng)調(diào)在開(kāi)發(fā)早期找到相對(duì)穩(wěn)定的構(gòu)架，以免后期因?yàn)樾薷臉?gòu)架而增加太多工作量，另外RUP使用use case捕獲需求作為每一次迭代開(kāi)發(fā)的開(kāi)始。RUP46極限編程 是一種指導(dǎo)你如何去開(kāi)發(fā)的思想。XP的核心是盡可能把所有的事情簡(jiǎn)化。XP反對(duì)在開(kāi)發(fā)過(guò)程中生成太多文檔，不鼓勵(lì)過(guò)多考慮未來(lái)的需求，鼓勵(lì)盡可能早期進(jìn)行盡可能全面的測(cè)試，鼓勵(lì)周期盡可能小的迭代開(kāi)發(fā)以

21、便是系統(tǒng)盡可能早的投入使用。另外還注重雙人編程、CRC和重構(gòu)技術(shù)。 XP47XP在很多方面都和我們傳統(tǒng)意義上得軟件工程不同，同時(shí)，它也和傳統(tǒng)得管理和項(xiàng)目計(jì)劃得方法不同。不采用瀑布式得軟件工程方法，而采用原型法。在軟件設(shè)計(jì)中，強(qiáng)調(diào)簡(jiǎn)單性48角色輪換項(xiàng)目的集體負(fù)責(zé) 保證8小時(shí)工作制，避免加班。有充分的培訓(xùn)、有每個(gè)人的提升空間推行淘汰制有效的招聘制度。強(qiáng)有力的后勤保障制度和輕松的企業(yè)文化結(jié)對(duì)編程49CMM 告訴組織為了系統(tǒng)化地建立、實(shí)施和改進(jìn)軟件開(kāi)發(fā)過(guò)程應(yīng)該做些什么，但沒(méi)有說(shuō)明如何去做以及采用哪些具體的技術(shù)、策略和方法。CMM 是一套通用的過(guò)程實(shí)踐標(biāo)準(zhǔn)，適用面很廣。實(shí)施CMM 要求組織在過(guò)程的制度化

22、建設(shè)上付出大量努力，通常被認(rèn)為是重載（heavy-weight）的模型。XP 與CMM 、RUP 的比較 50XP 是一個(gè)針對(duì)某種特定環(huán)境（需求變化快的小型團(tuán)隊(duì)）的具體過(guò)程實(shí)施模型和方法論。它其實(shí)是一種演進(jìn)式的原型化方法（evolutionary prototyping），具有溝通高效、設(shè)計(jì)簡(jiǎn)單、反饋迅速等特點(diǎn)，因而是一種輕載（light-weight）、敏捷（agile）的過(guò)程方法。 把XP 的實(shí)踐方法與CMM 的KPA（關(guān)鍵過(guò)程域）進(jìn)行對(duì)照。可以看出XP部分滿(mǎn)足或大部分滿(mǎn)足了CMM 2-3 級(jí)KPA 的要求，而基本上沒(méi)有涉及CMM 4-5 級(jí)的KPA。這說(shuō)明XP 的做法基本符合了CMM 的

23、目標(biāo)和KPA，但還不完備。51總體上看，XP 側(cè)重于具體的過(guò)程和開(kāi)發(fā)技術(shù)，而CMM 更關(guān)注組織和管理上的問(wèn)題。XP 缺少的一個(gè)重要內(nèi)容是“制度化”，它不含有被CMM 認(rèn)為是使良好的工程和管理實(shí)踐制度化的關(guān)鍵基礎(chǔ)設(shè)施和管理要件。52RUP（Rational Unified Process）是一個(gè)風(fēng)險(xiǎn)驅(qū)動(dòng)的基于UML 和構(gòu)件式架構(gòu)的迭代遞增型開(kāi)發(fā)過(guò)程（框架）。RUP 定義了4 個(gè)階段（起始、細(xì)化、構(gòu)造、移交）和9 個(gè)科目（業(yè)務(wù)建模、需求、分析和設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試、部署、配置和變更管理、項(xiàng)目管理、環(huán)境）。這些階段對(duì)應(yīng)著關(guān)鍵里程碑的劃分，而不同科目的工作流和活動(dòng)在生命周期的迭代中可以并發(fā)進(jìn)行，具體執(zhí)行的

24、程度則可以調(diào)節(jié)。53RUP 對(duì)于角色、流程、工件和活動(dòng)的要求是靈活的、可配置的，所以它廣泛地適用于各種類(lèi)型和規(guī)模的項(xiàng)目。RUP 集中體現(xiàn)了6 個(gè)軟件開(kāi)發(fā)的最佳實(shí)踐方法：迭代式開(kāi)發(fā)、需求管理、構(gòu)件式架構(gòu)、基于UML 的可視化建模、持續(xù)校驗(yàn)質(zhì)量、變更管理。54RUP 是一種以架構(gòu)為中心的開(kāi)發(fā)過(guò)程，而這正是大、中型項(xiàng)目成功的關(guān)鍵。XP 的編碼和設(shè)計(jì)活動(dòng)融為一體，弱化了架構(gòu)的概念，這是它與強(qiáng)調(diào)架構(gòu)設(shè)計(jì)的RUP 的最大不同。架構(gòu)的內(nèi)涵要遠(yuǎn)大于一些簡(jiǎn)單的隱喻，它要考慮結(jié)構(gòu)、行為、環(huán)境、使用、功能、性能、可靠性、彈性、重用、可理解性、約束和權(quán)衡乃至美學(xué)等諸多方面的因素。設(shè)計(jì)架構(gòu)的目的不是為了完美地表示系統(tǒng)的

25、全部細(xì)節(jié)，而是為了消除最主要和最關(guān)鍵的架構(gòu)風(fēng)險(xiǎn)。55RUP 細(xì)化階段的主要目的就是構(gòu)造出一個(gè)可運(yùn)行的架構(gòu)原型，作為將來(lái)添加需求功能的穩(wěn)固基礎(chǔ)。XP 沒(méi)有包含業(yè)務(wù)建模、部署等概念，反映了它以編程為中心、節(jié)省一切的哲學(xué)。 當(dāng)然兩者也有不少共同點(diǎn)。例如，它們的基礎(chǔ)都是面向?qū)ο蠓椒ǎㄈ〈鷤鹘y(tǒng)的結(jié)構(gòu)化方法），都重視代碼、文檔的最小化和設(shè)計(jì)的簡(jiǎn)化，采用動(dòng)態(tài)適應(yīng)變化的演進(jìn)式迭代周期（取代傳統(tǒng)的瀑布型生命周期）、需求和測(cè)試驅(qū)動(dòng)并鼓勵(lì)用戶(hù)積極參與等。 56RUP 提供了非常豐富的內(nèi)容，總體來(lái)說(shuō)是一個(gè)重載的過(guò)程。通過(guò)定制RUP 這個(gè)通用的過(guò)程框架，去掉項(xiàng)目不必要的工件和中間環(huán)節(jié)，把XP 的做法（比如短小的迭代周期

26、、結(jié)對(duì)編程、測(cè)試優(yōu)先的設(shè)計(jì)和重構(gòu)）吸收進(jìn)來(lái)，也可以實(shí)現(xiàn)RUP 過(guò)程的敏捷和輕量化。Robert Martin甚至從RUP中裁剪出了一個(gè)酷似XP 的最小化RUP 過(guò)程dxMART01。57XP、RUP 乃至其他工程和管理方法可以統(tǒng)一起來(lái)使用，姑且成之為統(tǒng)一軟件過(guò)程（Unified Software Process，USP）。例如，一個(gè)大項(xiàng)目團(tuán)隊(duì)在起始和細(xì)化階段采用RUP 方法完成需求分析和架構(gòu)設(shè)計(jì)，在構(gòu)造和移交階段采用XP 的做法來(lái)實(shí)現(xiàn)部分子系統(tǒng)或模塊。 “輕載”、“敏捷”是美麗的詞匯，無(wú)人會(huì)拒之于門(mén)外。XP、RUP 的目標(biāo)是一致的提高團(tuán)隊(duì)效率、開(kāi)發(fā)出高質(zhì)量的軟件，而區(qū)別就在于各自的側(cè)重點(diǎn)不同，

27、從而導(dǎo)致兩者的適用情況和應(yīng)用范圍有差異。然而，它們是可以互補(bǔ)的，無(wú)論是以架構(gòu)為中心，還是以代碼為中心，靈活運(yùn)用的關(guān)鍵就在于掌握其中的最佳實(shí)踐方法，實(shí)施RUP、XP 或者融合了兩者的過(guò)程（比如USP）都將有助于組織更好地實(shí)現(xiàn)CMM 目標(biāo)。 總結(jié)58 MSF是一套大型系統(tǒng)開(kāi)發(fā)指南，它描述了如何用組隊(duì)模型、過(guò)程模型和應(yīng)用模型來(lái)開(kāi)發(fā)Client/Server結(jié)構(gòu)的應(yīng)用程序，是在微軟的工具和技術(shù)的基礎(chǔ)上建立并開(kāi)發(fā)分布式企業(yè)系統(tǒng)應(yīng)用的參考。 MSF59第二單元：技術(shù)架構(gòu)視圖面向?qū)ο蟪绦蛟O(shè)計(jì)原則與模式606162用GRASP模式指導(dǎo)設(shè)計(jì)636465666768697071727374757677787980

28、81828384858687888990919293949596領(lǐng)域模型97層次結(jié)構(gòu)領(lǐng)域模型從EJB到輕量級(jí)框架98表現(xiàn)層（present）業(yè)務(wù)層業(yè)務(wù)層外觀(guān)業(yè)務(wù)層核心領(lǐng)域?qū)ο蠊芾?服務(wù)/倉(cāng)庫(kù)層領(lǐng)域?qū)ο髮映志脤訑?shù)據(jù)訪(fǎng)問(wèn)層數(shù)據(jù)庫(kù)層次結(jié)構(gòu)99100領(lǐng)域模型中的各種角色：實(shí)體-有唯一的標(biāo)識(shí),并且要有屬性和行為(非GET/SET)，添加了行為，使其具有生命力。往往在設(shè)計(jì)時(shí)，實(shí)體的形為最難決斷。為確定行為，我們必須識(shí)別它們的責(zé)任和協(xié)作。類(lèi)的責(zé)任是指該類(lèi)要做、知道、或決定的一切，由一個(gè)或多個(gè)方法完成。類(lèi)中有屬性和關(guān)聯(lián)，協(xié)作就是為完成自己的責(zé)任所調(diào)用其它關(guān)聯(lián)類(lèi)。值對(duì)象-沒(méi)有標(biāo)識(shí)沒(méi)有行為。如Address類(lèi)。工

29、廠(chǎng)-定義創(chuàng)建實(shí)體的方法，封裝實(shí)例化對(duì)象并將一些關(guān)聯(lián)對(duì)象注入。倉(cāng)庫(kù)(repository)管理實(shí)體的集合,主要有查找和刪除實(shí)體的方法.實(shí)現(xiàn)類(lèi)可以調(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ì)象中。101失血模型貧血模型充血模

30、型脹血模型領(lǐng)域模型102DO只有屬性及其getter/setter方法，沒(méi)有任何業(yè)務(wù)邏輯。缺點(diǎn)：行為與數(shù)據(jù)分離，很多情況導(dǎo)致維護(hù)與理解困難。失血模型103DO包含不依賴(lài)于持久化的領(lǐng)域邏輯；依賴(lài)持久化的領(lǐng)域邏輯歸入Service層。Service(業(yè)務(wù)邏輯，事務(wù)封裝) DAODO優(yōu)點(diǎn)：各層單向依賴(lài)，結(jié)構(gòu)清楚，易于實(shí)現(xiàn)和維護(hù)。設(shè)計(jì)簡(jiǎn)單易行，底層模型非常穩(wěn)定。缺點(diǎn)：DO部分的持久化邏輯被放入Service層，不夠OO。Service層過(guò)重。貧血模型104與貧血模型類(lèi)似，不同處在于如何劃分業(yè)務(wù)邏輯：絕大多業(yè)務(wù)邏輯都應(yīng)該放在DO里(包括持久化邏輯)，而Service層很薄，僅僅封裝事務(wù)和少量邏輯，不和D

31、AO層打交道。Service(事務(wù)封裝)DO DAO優(yōu)點(diǎn)：符合OOService層很薄，只充當(dāng)Facade的角色，不和DAO打交道。充血模型105缺點(diǎn)：DAO和DO雙向依賴(lài)。如何劃分Service層邏輯和Domain層邏輯沒(méi)有確定的規(guī)則，取決與設(shè)計(jì)人員自己的理解。Service層封裝事務(wù)，須對(duì)所有的DO邏輯提供相應(yīng)的事務(wù)封裝方法，造成重定義所有的Domain logic。Service的事務(wù)化封裝的意義等于把OO的Domain logic轉(zhuǎn)換為過(guò)程的Service 事務(wù)腳本。充血模型在domain層實(shí)現(xiàn)的OO在Service層又變成了面向過(guò)程。 106取消Service層，只剩下DO和DAO層

32、，在DO的domain logic上面封裝事務(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ò)多的信息，可能引起不必要的耦合。脹血模型107原則：業(yè)務(wù)對(duì)象封裝了內(nèi)在的業(yè)務(wù)邏輯，而應(yīng)用服務(wù)封裝了外在于業(yè)務(wù)對(duì)象的業(yè)務(wù)邏輯。 108EJBPOJO （業(yè)務(wù)邏輯） + 輕量級(jí)框架（Hibernate、JDO、iBATIS（持久化）、Spring（事務(wù)管理、安全）EJB到輕量級(jí)框架109EJB：編寫(xiě)分布式業(yè)務(wù)應(yīng)用程序的Java標(biāo)準(zhǔn)架構(gòu)。提供大量服務(wù)：聲明型事務(wù), EIB容器自動(dòng)啟動(dòng)、提交和回滾

33、事務(wù)。業(yè)務(wù)邏輯能參與由遠(yuǎn)程客戶(hù)發(fā)起的分布式事務(wù)。提供聲明型安全，大部分情況下不再搖要編寫(xiě)安全代碼求（bean部署描述符里的條目指定準(zhǔn)可以防問(wèn)某個(gè)具體bean）。EJB110例：在兩個(gè)賬號(hào)間進(jìn)行轉(zhuǎn)賬的服務(wù)。111TransferServiceEJB調(diào)用AccoutDAO獲取兩個(gè)賬號(hào),并執(zhí)行必耍的檢查及其他業(yè)務(wù)邏輯。例如,它要核實(shí)fromAccount仍有足夠余額,不至于透支。然后,TransferServicEJB再次調(diào)用AccountDAO將更新后的賬號(hào)信息保存到數(shù)據(jù)庫(kù)中。EJB調(diào)用TransactionDAO記錄轉(zhuǎn)賬操作，TransferServiceEJB返回一個(gè)TransferResul

34、t,這是個(gè)包含AccOuntDTO及其最近執(zhí)行事的DTO。表示層使用它向顧客顯示W(wǎng)eb頁(yè)面。112優(yōu)點(diǎn)：類(lèi)的設(shè)計(jì)和類(lèi)之間的關(guān)系簡(jiǎn)單。TransctionService可直接被遠(yuǎn)程調(diào)用,并能參與到分布式事務(wù)中。缺點(diǎn)（過(guò)程式設(shè)計(jì)的缺點(diǎn)）：業(yè)務(wù)邏輯的組織右兩種主要方式:過(guò)程式或面向?qū)ο?。過(guò)程式方式以函數(shù)為單元組織代碼,操作DTO/VO。DTO/VO遍布各處（函數(shù)參數(shù)、返回值等）數(shù)據(jù)與操作的關(guān)系非常松散。業(yè)務(wù)邏輯變得復(fù)雜后， TransfeService EJB必須實(shí)現(xiàn)新的特性, 其代碼量也會(huì)不斷增加。（例如,增加一神的透支政策）就得向TransfeService 添加更多代碼。導(dǎo)致業(yè)務(wù)邏輯類(lèi)易變得龐

35、大不堪。113EJB規(guī)范實(shí)際上鼓勵(lì)編寫(xiě)無(wú)狀態(tài)、過(guò)程式代碼,實(shí)現(xiàn)新的行為時(shí), 編寫(xiě)一個(gè)新的會(huì)話(huà)bean，加入方法，或在現(xiàn)有方法里添加代碼。Session和Message 都很龐大，SessionFacade和Message Facade模式并不能從根本上解決問(wèn)題。復(fù)雜的EJB難以測(cè)i式。開(kāi)發(fā)和測(cè)試乏味冗長(zhǎng)。關(guān)注點(diǎn)缺少分離的現(xiàn)實(shí)。迫便開(kāi)發(fā)人員同時(shí)處琛多個(gè)問(wèn)題（業(yè)務(wù)邏輯設(shè)計(jì)、數(shù)據(jù)庫(kù)模型設(shè)計(jì)、持久化映射等）114可能需要須編寫(xiě)大量永遠(yuǎn)不會(huì)被調(diào)用的代碼。需要設(shè)計(jì)DTO/VO對(duì)象。一般來(lái)源于實(shí)體bean，需維護(hù)同步；創(chuàng)建DTO是乏味的工作。用EJB2進(jìn)行J2EE開(kāi)發(fā)本質(zhì)上會(huì)排斥許多在其它類(lèi)型的Java開(kāi)發(fā)

36、中常見(jiàn)的實(shí)踐經(jīng)驗(yàn)。115EJB3EJB是POJO,需編寫(xiě)的樣板代(boilerplate code）大幅減少；代碼和應(yīng)用服務(wù)器環(huán)間的耦合度也下降。實(shí)體bean意在成為標(biāo)準(zhǔn)Java持久化機(jī)制，在J2EE和J2SE環(huán)境都能運(yùn)行。支持Java 5 annotation,以替代難寫(xiě)的部署描述符（用于指定事務(wù)屬性、安全屬性和對(duì)象/關(guān)系映射等細(xì)節(jié)）。實(shí)體bean 支持繼承。為大部分部署信息提供了默認(rèn)值。實(shí)體bean能向表示層反返回?cái)?shù)據(jù),無(wú)需在編寫(xiě)DTO。116POJO（業(yè)務(wù)邏輯） +Hiibernate、JDO、iBATIS（持久化）、Spring（事務(wù)管理、安全）。 典型的EJB方法 POJO方法 組織

37、 過(guò)程式業(yè)務(wù)邏輯 面向?qū)ο笤O(shè)計(jì) 實(shí)現(xiàn) 基于EJB POJO 數(shù)據(jù)庫(kù)訪(fǎng)問(wèn) JDBC/SQL或?qū)嶓wbean 持久層框架 返回給表示層的數(shù)據(jù)DTO 業(yè)務(wù)對(duì)象 事務(wù)管理 EJB容器管理的事務(wù) Spring框架 應(yīng)用程序組裝 顯式的JNDI查詢(xún) 依賴(lài)注入 117新設(shè)計(jì)是面向?qū)ο?、基于POJO, 而非基于EJB的過(guò)程式。它使用構(gòu)建在JDBC上的持久層框架來(lái)訪(fǎng)問(wèn)數(shù)據(jù)庫(kù), 并不直接使用JDBC。業(yè)務(wù)邏輯由POJO facade而非會(huì)話(huà)bean進(jìn)行封裝。事務(wù)由Spring框架而非EJB容器進(jìn)行管理。業(yè)務(wù)邏輯向表現(xiàn)層返回實(shí)際的業(yè)務(wù)對(duì)象,而不是DTO。應(yīng)用程序通過(guò)將組件的依賴(lài)作為setter或構(gòu)造子參數(shù)傳入來(lái)進(jìn)行組

38、裝,而不是之前采用Java命名和目錄接口(JNDI )查詢(xún)的組件。由于該設(shè)計(jì)面向?qū)ο?并采用上述輕量級(jí)技術(shù),因此較之前看到的EJB版本對(duì)開(kāi)發(fā)人員要友好。118基于輕量級(jí)框架設(shè)計(jì)的好處是，它提供事務(wù)和持久化時(shí)并不要求應(yīng)用程序類(lèi)實(shí)現(xiàn)任何特殊接口。甚至當(dāng)應(yīng)用程序的類(lèi)需要運(yùn)行在事務(wù)里或是持久的時(shí)候，它們?nèi)允荘OJO，設(shè)計(jì)者可以繼續(xù)享受POJO的種種好處。119120面向?qū)ο蟮膬?yōu)點(diǎn)：整個(gè)設(shè)計(jì)更易理解和維護(hù)。它并不是一個(gè)無(wú)所不能的大型類(lèi), 而是由大量小類(lèi)組成, 每個(gè)類(lèi)只共有若干職責(zé)。此外,諸如Account、BankingTransaction和Overdra類(lèi)都與現(xiàn)實(shí)世界的概念對(duì)應(yīng), 因此易于理解。其次

39、,面向?qū)ο笤O(shè)汁也更易測(cè)試: 所有類(lèi)都能并且應(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ì)往往需耍修改核心代碼。121不適合用面向?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更加困難，維

40、護(hù)也更困難，同時(shí)還損失了效率。比較大的事務(wù)。性能要求高的地方。（直接用Sql或者存儲(chǔ)過(guò)程；犧牲可維護(hù)性和可復(fù)用性）上層流程。122123封裝對(duì)持久層框架的調(diào)用：盡管Hibernare和JDO提供了透明持久化,但應(yīng)用程序的某些部分仍必須調(diào)用JDO和Hibernate的APl來(lái)保存、查詢(xún)和刪除持久對(duì)象。例如,必須調(diào)用持久層框架獲取賬戶(hù),然后創(chuàng)建BankingTransaction。一種做法是讓TransferService直接i周由持久層框架API。但這樣會(huì)將TransferService與持久層框架、數(shù)據(jù)庫(kù)耦合在一起。更好的做法：用接口裝Hibernate或JDO相關(guān)代碼。用倉(cāng)庫(kù)封裝持久層框架,

41、 對(duì)應(yīng)用程序其余部分隱藏持久化細(xì)節(jié)。124消除DTO125使POJO具有事務(wù)性（使用Spring）126部署POJO程序127128129130131實(shí)體：有唯一標(biāo)識(shí)的對(duì)象值對(duì)象：沒(méi)有唯一標(biāo)識(shí)的對(duì)象工廠(chǎng)：定義創(chuàng)建實(shí)體的方法倉(cāng)庫(kù)：管理實(shí)體的集合；封裝持久層框架；查找實(shí)體；（兼當(dāng)工廠(chǎng)）服務(wù)：實(shí)現(xiàn)無(wú)法指派給單個(gè)類(lèi)的責(zé)任；封裝裝領(lǐng)域模型132133134一般認(rèn)為：總是先有應(yīng)用程序?qū)ο竽Ｐ?，再有配套的持久化方案。上班以后發(fā)現(xiàn)，現(xiàn)實(shí)完全不需要這樣。業(yè)務(wù)被化解為神圣的表，實(shí)體表，引用表，鏈接表。整個(gè)系統(tǒng)非常靈活，所有的程序配置也全部在表里，還有專(zhuān)門(mén)的表來(lái)記錄表和表之間的join關(guān)系和一些預(yù)先寫(xiě)好的sql子句

42、。真是表中有程序，程序在表中。JAVA需要做什么呢？對(duì)，拼接SQL。代碼再惡心也沒(méi)關(guān)系，而且只要面向過(guò)程，完全不必?fù)?dān)心有性能問(wèn)題，要知道應(yīng)用程序的響應(yīng)時(shí)間是納秒級(jí)的，而數(shù)據(jù)庫(kù)的相應(yīng)時(shí)間是毫秒級(jí)的。萬(wàn)一很慢，那肯定只是你SQL沒(méi)寫(xiě)好。什么靈活性更是沒(méi)意義，客戶(hù)都是外行。反過(guò)來(lái)講，就算你OO厲害，別人程序一改一周，你的程序半天搞定，也只是給項(xiàng)目經(jīng)理認(rèn)為是你的改動(dòng)本身簡(jiǎn)單，別人的復(fù)雜。再退一萬(wàn)步講，就算客戶(hù)丟了，那也是客服的事情，銷(xiāo)售或者財(cái)務(wù)出身的老板完全不會(huì)把這些怪罪到你頭上。爭(zhēng)議1135JAVA說(shuō)完了，回頭看看SQL。數(shù)據(jù)越來(lái)越多，系統(tǒng)越來(lái)越慢。起初毫秒級(jí)響應(yīng)的操作，慢慢變成秒級(jí)，到了分鐘級(jí)客戶(hù)

43、就會(huì)來(lái)抱怨了。這個(gè)時(shí)候如果你SQL不錯(cuò)就可以自告奮勇去調(diào)優(yōu)，很容易就能發(fā)現(xiàn)很多初級(jí)錯(cuò)誤。簡(jiǎn)單改改，再優(yōu)化下索引，效果立竿見(jiàn)影。人們對(duì)你贊賞有加，認(rèn)為這就是技術(shù)的力量。136做一個(gè)J2EE系統(tǒng)時(shí)，一開(kāi)始必須從中間層Domain Model開(kāi)始，這就是域模型驅(qū)動(dòng)，而不是被具體技術(shù)牽著鼻子走，各個(gè)層技術(shù)鬧騰得厲害，整合起來(lái)時(shí)卻很難。所以必須以Domain Model設(shè)計(jì)為中心，再加入其他輔助對(duì)象，與Domain Model建立對(duì)象關(guān)聯(lián)(通過(guò)類(lèi)圖實(shí)現(xiàn)的四種類(lèi)關(guān)系)，而各個(gè)技術(shù)都是圍繞類(lèi)圖的類(lèi)各自完成自己功能。理清這個(gè)思路，從中間組件層入手，就能順藤摸瓜，問(wèn)題迎刃而解，這也是組件層（有些人說(shuō)是構(gòu)件）重要

44、的原因，面向組件（面向構(gòu)件）編程的重要性。實(shí)際上，這也是域建模 和框架重要的原因，使用UML依靠usecase設(shè)計(jì)出類(lèi)圖、用模式實(shí)現(xiàn)類(lèi)圖、使用框架（表現(xiàn)層 組件層 持久層框架）來(lái)進(jìn)行代碼級(jí)別實(shí)現(xiàn)，最終完成一個(gè)高質(zhì)量的J2EE系統(tǒng)。137面向?qū)ο笤O(shè)計(jì)的基本原則138139liskov替換原則（LSP）140問(wèn)題的根源是關(guān)于行為的：基類(lèi)中有的行為在子類(lèi)中不存在或不適當(dāng)。IS A的本質(zhì)是指行為的一致，而不是生活中的語(yǔ)言。違反了LSP原則的本質(zhì)是派生類(lèi)的行為與基類(lèi)中的不一致。如果違反了LSP原則，常會(huì)導(dǎo)致在運(yùn)行時(shí)的類(lèi)型判斷(RTTI)違反OCP原則。例如：函數(shù)A的參數(shù)是基類(lèi)型，調(diào)用時(shí)傳遞的對(duì)象是子類(lèi)型

45、，正常情況下，增加子類(lèi)型都不會(huì)影響到函數(shù)A的，如果違反了LSP，則函數(shù)A必須小心的判斷傳進(jìn)來(lái)的具體類(lèi)型，否則就會(huì)出錯(cuò)，這就已經(jīng)違反了OCP原則。子類(lèi)型必須能夠替換掉其基類(lèi)型141違反LSP導(dǎo)致違反OCP的簡(jiǎn)單例子142改善143問(wèn)題描述用來(lái)管理各種各樣的會(huì)議參與者信息。數(shù)據(jù)庫(kù)里面有個(gè)表Participants，里面的每條記錄表示一個(gè)參會(huì)者。因?yàn)榻?jīng)常會(huì)發(fā)生用戶(hù)誤刪掉某個(gè)參會(huì)者的信息。所以用戶(hù)刪除時(shí)，并不會(huì)真的刪除那參會(huì)者的信息，而只是將該記錄的刪除標(biāo)記設(shè)為true。24小時(shí)以后，系統(tǒng)會(huì)自動(dòng)將這條記錄刪除。但是在這24小時(shí)以?xún)?nèi)，如果用戶(hù)改變主意了，系統(tǒng)還可以將這條記錄還原，將刪除標(biāo)記設(shè)置為fals

46、e。 例：會(huì)議管理系統(tǒng)144145改善146假定一個(gè)Component代表一個(gè)GUI對(duì)象，如按鈕或者文本框等。例：GUI對(duì)象147148149改善2150例151改善：提取公共部分替代繼承152接口隔離原則（ISP）康凱153安全系統(tǒng)，有一些Door對(duì)象可以被加鎖和解鎖，并且Door對(duì)象知道自己是開(kāi)著還是關(guān)著的。需求變化：實(shí)現(xiàn)一個(gè)TimedDoor，如果門(mén)開(kāi)著的時(shí)間過(guò)長(zhǎng)，它就會(huì)發(fā)出警報(bào)聲。為了做到這一點(diǎn)，TimeDoor對(duì)象需要和一個(gè)Timer的對(duì)象交互。如何將TimerClient與TimedDoor類(lèi)聯(lián)系起來(lái)？例154一種方案155Door依賴(lài)于TimerClient 并不是所有種類(lèi)的Do

47、or都需要定時(shí)器。違反LSP：不需時(shí)鐘的派生類(lèi)中需要提供TimeOut的退化方法。不必要的復(fù)雜和重復(fù)性：使用這些派生類(lèi)的客戶(hù)程序被迫包含TimerClient的定義。Door接口被TimeOut方法污染了：持續(xù)的加入方法會(huì)使Door接口不斷變胖。每次Door中加入一個(gè)方法，其它派生類(lèi)中都需要對(duì)自己不需要的方法提供退化處理?？蛻?hù)對(duì)TimerClient接口的改變會(huì)影響接口使用者。例如需要在Timer中注冊(cè)多個(gè)超時(shí)通知（在TimeOut方法中加入超時(shí)ID），則即使不需要定時(shí)器的類(lèi)也會(huì)受影響。問(wèn)題156使用委托分離接口157使用多重繼承分離接口158內(nèi)接口與外接口159普通接口與智能接口160軟件系

48、統(tǒng)壞死的癥狀161一個(gè)從鍵盤(pán)讀入字符并輸出到打印機(jī)的程序。void Copy()int c;while (c = RdKbd() != EOF)WrtPtr(c);“Copy”程序162用戶(hù)希望Copy程序能從紙帶讀入機(jī)中讀入信息。現(xiàn)實(shí)中的約束不能改變接口Copy程序的第一次修改結(jié)果bool ptFlag = false;/remember to reset this flagvoid Copy()int c;while (c = (ptFlag ? Rdpt() : Rdkbd() != EOF)WrtPtr(c);需求在變化163客戶(hù)希望Copy程序有時(shí)可以輸出到紙帶穿孔機(jī)上。/Copy程

49、序的第二次修改結(jié)果bool ptFlag = false;bool punchFlag = false;/remember to reset these flagvoid Copy()int c;while (c = (ptFlag ? Rdpt() : Rdkbd() != EOF)punchFlag ? WrtPunch(c) : WrtPtr(c);需求在變化2164初始的設(shè)計(jì)的問(wèn)題依賴(lài)關(guān)系的不靈活性：高層模塊直接依賴(lài)于底層細(xì)節(jié)。Copy模塊直接依賴(lài)于KeyBoardReader和PrinterWriter依賴(lài)倒置：可以用Strategy模式實(shí)現(xiàn)依賴(lài)的倒置。針對(duì)實(shí)現(xiàn)編程，而沒(méi)有針對(duì)接口編

50、程。165依賴(lài)倒置原則（DIP）康凱166關(guān)于解耦依賴(lài)倒置（DIP）控制反轉(zhuǎn)（IoC）依賴(lài)注入（DI）服務(wù)定位器（SL）有些是手段，有些是原則，不過(guò)其間的差異并不太重要，更重要的是其共同點(diǎn)：其根本目標(biāo)都是解除依賴(lài)，將組件的配置與使用分離開(kāi)。其它名詞服務(wù)組件框架類(lèi)庫(kù)應(yīng)用程序相關(guān)概念167面向過(guò)程的接口與實(shí)現(xiàn)分離接口和實(shí)現(xiàn)分離168169170依賴(lài)于特定函數(shù)的框架171問(wèn)題：雙向依賴(lài)：應(yīng)用程序依賴(lài)GUI框架：應(yīng)用程序調(diào)用GUI框架中的CreateWindow()函數(shù)來(lái)創(chuàng)建窗口GUI框架依賴(lài)應(yīng)用程序：GUI框架不了解該窗口接收到窗口消息后應(yīng)該如何處理，這一點(diǎn)只有應(yīng)用程序最為清楚。因此，當(dāng)GUI框架需

51、要發(fā)送窗口消息時(shí)，又必須調(diào)用應(yīng)用程序定義的某個(gè)特定的窗口函數(shù)。雙向依賴(lài)關(guān)系的缺陷：由于GUI框架調(diào)用了應(yīng)用程序中的某個(gè)特定函數(shù)， GUI框架無(wú)法獨(dú)立存在，換一個(gè)新的應(yīng)用程序，GUI框架就要做相應(yīng)的修改。如何消解框架系統(tǒng)對(duì)應(yīng)用程序的依賴(lài)關(guān)系是實(shí)現(xiàn)框架系統(tǒng)的關(guān)鍵?？刂品崔D(zhuǎn)（IoC）172通過(guò)回調(diào)函數(shù)消解框架到運(yùn)用程序的依賴(lài)：173通過(guò)模板方式消解GUI框架到應(yīng)用程序的依賴(lài)174175176一個(gè)組件，用于提供一份電影清單，清單上列出的影片都是由一位特定的導(dǎo)演執(zhí)導(dǎo)的。class MovieLister . public Movie moviesDirectedBy(String arg) List a

52、llMovies = finder.findAll(); for (Iterator it = allMovies.iterator(); it.hasNext();) Movie movie = (Movie) it.next(); if (!movie.getDirector().equals(arg) it.remove(); return (Movie) allMovies.toArray(new MovieallMovies.size(); 電影清單的例子177其中真正想要考察的是如何將MovieLister對(duì)象與特定的finder對(duì)象連接起來(lái)。要求：我們希望moviesDirect

53、edBy方法完全不依賴(lài)于影片的實(shí)際存儲(chǔ)方式。這個(gè)方法只能引用一個(gè)finder對(duì)象，而finder對(duì)象必須知道如何實(shí)現(xiàn)findAll的細(xì)節(jié)。給finder定義一個(gè)接口： public interface MovieFinder List findAll(); 當(dāng)要實(shí)際尋找影片時(shí)，就必須涉及到MovieFinder 的某個(gè)具體子類(lèi)。在這里，我把“涉及具體子類(lèi)”的代碼放在MovieLister 類(lèi)的構(gòu)造函數(shù)中。178從一個(gè)逗號(hào)分隔的文本文件中獲得影片列表。class MovieLister. private MovieFinder finder; public MovieLister() finde

54、r = new ColonDelimitedMovieFinder(movies1.txt); 對(duì)抗變化：文件清單的名字更改：可以從一個(gè)配置文件獲得文件名。如果用SQL 數(shù)據(jù)庫(kù)、XML 文件、web service，或者另一種格式的文本文件來(lái)存儲(chǔ)影片清單：用另一個(gè)具體的類(lèi)來(lái)獲取數(shù)據(jù)。該類(lèi)從MovieFinder接口派生即可。創(chuàng)建合適的MovieFinder派生類(lèi)的實(shí)例：不能對(duì)抗此變化。對(duì)抗變化179public void testWithPico() MutablePicoContainer pico = configureContainer(); MovieLister lister = (

55、MovieLister) pico.getComponentInstance(MovieLister.class); Movie movies = lister.moviesDirectedBy(Sergio Leone); assertEquals(Once Upon a Time in the West, movies0.getTitle(); 客戶(hù)代碼180為了讓MovieLister 類(lèi)接受注入，需要為它定義一個(gè)設(shè)值方法，它接受類(lèi)型為MovieFinder的參數(shù)： class MovieLister. private MovieFinder finder; public void se

56、tFinder(MovieFinder finder) this.finder = finder; 類(lèi)似地在MovieFinder的實(shí)現(xiàn)類(lèi)中，定義一個(gè)設(shè)值方法，接受類(lèi)型為String 的參數(shù)： class ColonMovieFinder. public void set(String ) this. = ; Spring 注入181設(shè)定配置文件：XML 文件是比較理想的配置方式。movies1.txt配置文件182第三單元：用UML輔助系統(tǒng)分析與設(shè)計(jì)183UML簡(jiǎn)介及常見(jiàn)疑難問(wèn)題辨析184UML用來(lái)描述模型的內(nèi)容有3種,分別是事物( Things )、關(guān)系Relationships )和圖(

57、 Diagrams )。185UML中的事物包括結(jié)構(gòu)事物、行為事物、組織事物和輔助事物(也稱(chēng)注釋事物)。結(jié)構(gòu)事物( Structure Things )結(jié)構(gòu)事物主要包括7種,分別是類(lèi)、接口、協(xié)作、用例、活動(dòng)類(lèi)、組件和節(jié)點(diǎn):UML中的事物186行為事物（Behavior Things）行為事物也稱(chēng)動(dòng)作事物,是UML模型中的動(dòng)態(tài)部分,代表時(shí)間和空間上的動(dòng)作。行為事物主要有兩種:交互和狀態(tài)機(jī)。它們是UML模型中最基本的兩個(gè)動(dòng)態(tài)事物元素,通常和其他的結(jié)構(gòu)元素、主要的類(lèi)、對(duì)象連接在一起。(1)交互(Interaction)在UML圖中,交互的消息通常畫(huà)成帶箭頭的直線(xiàn)。(2)狀態(tài)機(jī)( State Mach

58、ine )狀態(tài)機(jī)是對(duì)象的一個(gè)或多個(gè)狀態(tài)的集合。1873、組織事物(Grouping Things)組織事物也稱(chēng)分組事物,是UML模型中組織的部分,可以把它看作一個(gè)個(gè)的盒子,每個(gè)盒子里面的對(duì)象關(guān)系相對(duì)復(fù)雜,而盒子與盒子之間的關(guān)系相對(duì)簡(jiǎn)單。組織事物只有一種,稱(chēng)為包（Package）包是一種有組織地將一系列元素分組的機(jī)制。包與組件的最大區(qū)別在于,包純粹是一種概念上的東西,僅僅存在于開(kāi)發(fā)階段結(jié)束之前,而組件是一種物理元素,存在于運(yùn)行時(shí)。在UML圖中,包通常表示為一個(gè)類(lèi)似文件夾的符號(hào)。1884、輔助事物(Annotation Things)輔助事物也稱(chēng)注釋事物,屬于這一類(lèi)的只有注釋( Annotatio

59、n )。注釋就是UML模型的解釋部分。在UML圖中,一般表示為折起一角的矩形。189UML中的關(guān)系(Relationships )主要包括4種:關(guān)聯(lián)關(guān)系、依賴(lài)關(guān)系、泛化關(guān)系和實(shí)現(xiàn)關(guān)系。1、關(guān)聯(lián)關(guān)系是一種結(jié)構(gòu)化的關(guān)系,指一種對(duì)象和另一種對(duì)象有聯(lián)系。給定關(guān)聯(lián)的兩個(gè)類(lèi),可以從其中的一個(gè)類(lèi)的對(duì)象訪(fǎng)問(wèn)到另一個(gè)類(lèi)的相關(guān)對(duì)象。在UML圖中,關(guān)聯(lián)關(guān)系用一條實(shí)線(xiàn)表示。另外,關(guān)聯(lián)可以有方向,表示該關(guān)聯(lián)在某方向被使用。只在一個(gè)方向上存在的關(guān)聯(lián),稱(chēng)作單向關(guān)聯(lián)(Unidirectional Association ),在兩個(gè)方向上都存在的關(guān)聯(lián),稱(chēng)作雙向關(guān)聯(lián)( Bidirectional Association)。UML

60、中的關(guān)系1902、依賴(lài)( Dependency)關(guān)系對(duì)于兩個(gè)對(duì)象X、Y,如果對(duì)象X發(fā)生變化,可能會(huì)引起對(duì)另一個(gè)對(duì)象Y的變化,則稱(chēng)Y依賴(lài)于X。在UML圖中,依賴(lài)關(guān)系用一條帶有箭頭的虛線(xiàn)來(lái)表示。3、泛化( Generalization )關(guān)系UML中的泛化關(guān)系定義了一般元素和特殊元素之間的分類(lèi)關(guān)系,與和C+及Java中的繼承關(guān)系有些類(lèi)似。在UML圖中,泛化關(guān)系用一條帶有空心箭頭的實(shí)線(xiàn)來(lái)表示。1914、實(shí)現(xiàn)( Realization )關(guān)系實(shí)現(xiàn)關(guān)系將一種模型元素(如類(lèi))與另一種模型元素(如接口)連接起來(lái),其中接口只是行為的說(shuō)明而不是結(jié)構(gòu)或者實(shí)現(xiàn)。真正的實(shí)現(xiàn)由前一個(gè)模型元素來(lái)完成。在UML圖中,實(shí)現(xiàn)關(guān)