1、1,高級(jí)軟件架構(gòu)設(shè)計(jì),康凱 Msn: Mail: ,2,目錄,第一單元：軟件生命周期與軟件架構(gòu)介紹2 第二單元：技術(shù)架構(gòu)視圖面向?qū)ο蟪绦蛟O(shè)計(jì)原則與模式 24 用GRASP模式指導(dǎo)設(shè)計(jì)27 領(lǐng)域模型47 面向?qū)ο笤O(shè)計(jì)的基本原則71 第三單元：用UML輔助系統(tǒng)分析與設(shè)計(jì)103 UML簡(jiǎn)介及常見疑難問(wèn)題辨析104 借鑒RUP的UML建模與分析117 第四單元：設(shè)計(jì)模式與軟件設(shè)計(jì)思想131 設(shè)計(jì)模式132 常用的軟件架構(gòu)風(fēng)格及適用情況分析172 SOA 及分層架構(gòu)設(shè)計(jì)212 第五單元：架構(gòu)設(shè)計(jì)實(shí)踐225,3,第一單元：軟件生命周期與軟件架構(gòu)介紹,4,IT行業(yè)的人才結(jié)構(gòu)與軟件架構(gòu)師的定位 軟件架構(gòu)師應(yīng)掌

2、握的知識(shí)體系 軟件架構(gòu)設(shè)計(jì)的特點(diǎn)、層次、分類 軟件架構(gòu)的主要理論、方向和趨勢(shì) 軟件工廠，實(shí)現(xiàn)軟件開發(fā)的產(chǎn)業(yè)化,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)開發(fā)人員開發(fā)。并解決系統(tǒng)開發(fā)、運(yùn)行中出現(xiàn)的各種問(wèn)題。 系統(tǒng)架構(gòu)師的目的： 對(duì)系統(tǒng)的重用、擴(kuò)展、安全、性能、伸縮性、簡(jiǎn)潔等做系統(tǒng)級(jí)的把握。 系統(tǒng)架構(gòu)師能力要求： 一、系統(tǒng)架構(gòu)相關(guān)的知識(shí)和經(jīng)驗(yàn)。 二、很強(qiáng)的自學(xué)能力、分析能力、解決問(wèn)題的能力。 三、寫作、溝通表達(dá)、培訓(xùn)。,6,角色 軟件架構(gòu)師Software Architect 定義 主

3、導(dǎo)系統(tǒng)全局分析設(shè)計(jì)和實(shí)施、負(fù)責(zé)軟件構(gòu)架和關(guān)鍵技術(shù)決策的角色,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),8,專業(yè)技能 技術(shù)全面、成熟練達(dá)、洞察力強(qiáng)、經(jīng)驗(yàn)豐富，具備在缺乏完整信息、眾多問(wèn)題交織一團(tuán)、模糊和矛盾的情況下，迅速抓住問(wèn)題要害，并做出合理的關(guān)鍵決定的

4、能力。 具備戰(zhàn)略性和前瞻性思維能力，善于把握全局，能夠在更高抽象級(jí)別上進(jìn)行思考。 對(duì)項(xiàng)目開發(fā)涉及的所有問(wèn)題領(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)行說(shuō)服、鼓勵(lì)和指導(dǎo)等活動(dòng)，并贏得項(xiàng)目成員的信任。,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í)別更高。,10

5、,軟件架構(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)分析師在軟件開發(fā)中的職責(zé)和角色，不難發(fā)現(xiàn)軟件架構(gòu)師與系統(tǒng)分析師所必需的知識(shí)體系也是不盡相同的，系統(tǒng)分析師的主要職責(zé)是在需求分析、開發(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í)的要求

6、也就相對(duì)低些。,11,成為一名合格的軟件架構(gòu)師必須具備的知識(shí) 信息系統(tǒng)綜合知識(shí)體系 軟件架構(gòu)知識(shí)體系,12,？,MFC，MSF，MOF，RUP，J2EE，Spring，SOA，JUnit，ORM，.Net MVC，UML，XML，Corba，MDA，MDD，Web-Service RSS，Web2.0，AJAX，Serverlet，Hibernate IOC， AOP Ruby On Rails Rup BPEL Workflow Engine LBS Oracle CMMI MQ ,13,軟件架構(gòu)師在干什么？,思考、思考、再思考 深入理解、準(zhǔn)確把握建設(shè)的業(yè)務(wù)需求 分析所有可見的問(wèn)題、障礙、風(fēng)

7、險(xiǎn) 充分參考已有的成功方案，降低風(fēng)險(xiǎn) 交流、討論、博弈、質(zhì)疑 對(duì)構(gòu)思中的方案不斷提出質(zhì)疑，避免漏洞 廣泛聽取各層面的意見，開拓思路 反復(fù)質(zhì)疑、逐步完善已有的設(shè)計(jì)構(gòu)思 在動(dòng)手實(shí)現(xiàn)之前驗(yàn)證設(shè)計(jì)方案的正確性,14,軟件架構(gòu)師的知識(shí)結(jié)構(gòu),軟件知識(shí) 最好要有系統(tǒng)開發(fā)全過(guò)程經(jīng)驗(yàn)。 對(duì) IT 建設(shè)生命周期各個(gè)環(huán)節(jié)有深入了解，包括：系統(tǒng)/模塊邏輯設(shè)計(jì)、物理設(shè)計(jì)、代碼開發(fā)、項(xiàng)目管理、測(cè)試、發(fā)布、運(yùn)行維護(hù)等。 深入掌握1-2種主流技術(shù)平臺(tái)上開發(fā)系統(tǒng)的方法。 了解多種應(yīng)用系統(tǒng)的結(jié)構(gòu)。 了解架構(gòu)設(shè)計(jì)領(lǐng)域的主要理論、流派、框架。,15,軟件架構(gòu)師的知識(shí)結(jié)構(gòu),業(yè)務(wù)知識(shí) 深入了解系統(tǒng)建設(shè)的業(yè)務(wù)需求。 了解系統(tǒng)的非功能需求和

8、運(yùn)行維護(hù)需求。 了解企業(yè) IT 公共設(shè)施、網(wǎng)絡(luò)環(huán)境、外部系統(tǒng)。,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é),17,軟件架構(gòu)師的思維方式,風(fēng)險(xiǎn)管理意識(shí) 采用成功經(jīng)驗(yàn)、避免不應(yīng)有的風(fēng)險(xiǎn) 多方位的開放思維 多維度、多方向、包容性、避免排他性 分析、質(zhì)疑、抽象、歸納 沒(méi)有絕對(duì)好的架構(gòu)設(shè)計(jì)，只有相對(duì)優(yōu)秀的方案,18,信息系統(tǒng)綜合知識(shí)體系,(1)計(jì)算機(jī)系

9、統(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)開發(fā)：包括程序設(shè)計(jì)語(yǔ)言、軟件開發(fā)方法、需求分析和設(shè)計(jì)方法、測(cè)試評(píng)審方法、開發(fā)管理、應(yīng)用系統(tǒng)構(gòu)建、系統(tǒng)審計(jì)、外部資源使用和基于中間件的開發(fā)等方面的知識(shí)。 (5)安全性和可靠性技術(shù)：包括數(shù)據(jù)安全與保密、防闖入和防病毒、容錯(cuò)技術(shù)、可靠性模型與分析技術(shù)、系統(tǒng)可靠性、安全規(guī)章和保護(hù)私有信息規(guī)則等方面的知識(shí)。,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)、軟

10、件工程標(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í)。,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)的軟件開發(fā)方法、架構(gòu)評(píng)估、軟件產(chǎn)品線和系統(tǒng)演化等。 (3)設(shè)計(jì)模式：包括設(shè)計(jì)模式的概念、組成、分類和實(shí)現(xiàn)、模式

11、和軟件架構(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ù)建模和逆向工程等。,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)開發(fā)設(shè)計(jì)等。 (8)系統(tǒng)可靠性分析與設(shè)計(jì)：包括系統(tǒng)故障模型和可靠性模型、系

12、統(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)等。,22,軟件架構(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)目的總體

13、規(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)用，精通Web Service，熟練掌握流行的架構(gòu)。,23,(5)對(duì)設(shè)計(jì)模式有深刻的理解，并能在此基礎(chǔ)上設(shè)計(jì)出適合產(chǎn)品特性和質(zhì)量屬性的框架。 (6)具有面向?qū)ο蟮姆治?、設(shè)計(jì)和開發(fā)能力，精通UML和XML，能熟練使用Rational Rose、PowerDesigner等工具進(jìn)行設(shè)計(jì)。 (7)具有良好的團(tuán)隊(duì)意識(shí)和協(xié)作精神，有較強(qiáng)的溝通能力和書面表達(dá)能力。 (8)具有旺盛的精力和學(xué)習(xí)能力，能快速掌握新技

14、術(shù)和新方法。,24,第二單元：技術(shù)架構(gòu)視圖面向?qū)ο蟪绦蛟O(shè)計(jì)原則與模式,25,26,27,用GRASP模式指導(dǎo)設(shè)計(jì),28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,領(lǐng)域模型,48,層次結(jié)構(gòu) 領(lǐng)域模型 從EJB到輕量級(jí)框架,49,層次結(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ù),50,領(lǐng)域模型中的各種角色： 實(shí)體-有唯一的標(biāo)識(shí),并且要有屬性和行為(非GET/SET)，添加了行為，使其具有生命力。往往在設(shè)計(jì)時(shí)，實(shí)體的形為最難決斷。為確定行為，我

15、們必須識(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ì)象

16、。服務(wù)和facade很像，但不一樣，它不處理以下事情：1）執(zhí)行事務(wù)。2）收集返回給表現(xiàn)層的數(shù)據(jù)。3）脫鉤對(duì)象。4）其它事情。服務(wù)可以說(shuō)是業(yè)務(wù)的協(xié)調(diào)者，業(yè)務(wù)邏輯可以分散到實(shí)體對(duì)象中。,51,領(lǐng)域模型,失血模型 貧血模型 充血模型 脹血模型,52,失血模型,DO只有屬性及其getter/setter方法，沒(méi)有任何業(yè)務(wù)邏輯。 缺點(diǎn)：行為與數(shù)據(jù)分離，很多情況導(dǎo)致維護(hù)與理解困難。,53,貧血模型,DO包含不依賴于持久化的領(lǐng)域邏輯；依賴持久化的領(lǐng)域邏輯歸入Service層。 Service(業(yè)務(wù)邏輯，事務(wù)封裝) DAO DO 優(yōu)點(diǎn)： 各層單向依賴，結(jié)構(gòu)清楚，易于實(shí)現(xiàn)和維護(hù)。 設(shè)計(jì)簡(jiǎn)單易行，底層模型非常穩(wěn)定

17、。 缺點(diǎn)： DO部分的持久化邏輯被放入Service層，不夠OO。 Service層過(guò)重。,54,充血模型,與貧血模型類似，不同處在于如何劃分業(yè)務(wù)邏輯：絕大多業(yè)務(wù)邏輯都應(yīng)該放在DO里(包括持久化邏輯)，而Service層很薄，僅僅封裝事務(wù)和少量邏輯，不和DAO層打交道。 Service(事務(wù)封裝) DO DAO 優(yōu)點(diǎn)： 符合OO Service層很薄，只充當(dāng)Facade的角色，不和DAO打交道。,55,缺點(diǎn)： DAO和DO雙向依賴。 如何劃分Service層邏輯和Domain層邏輯沒(méi)有確定的規(guī)則，取決與設(shè)計(jì)人員自己的理解。 Service層封裝事務(wù)，須對(duì)所有的DO邏輯提供相應(yīng)的事務(wù)封裝方法，造

18、成重定義所有的Domain logic。 Service的事務(wù)化封裝的意義等于把OO的Domain logic轉(zhuǎn)換為過(guò)程的Service 事務(wù)腳本。充血模型在domain層實(shí)現(xiàn)的OO在Service層又變成了面向過(guò)程。,56,脹血模型,取消Service層，只剩下DO和DAO層，在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ò)多的信息，可能引起不必要的耦合。,57,原則： 業(yè)務(wù)對(duì)象封裝了內(nèi)在的業(yè)務(wù)邏輯，而應(yīng)用服務(wù)封裝了外在

19、于業(yè)務(wù)對(duì)象的業(yè)務(wù)邏輯。,58,EJB到輕量級(jí)框架,EJB POJO （業(yè)務(wù)邏輯） + 輕量級(jí)框架（Hibernate、JDO、iBATIS（持久化）、Spring（事務(wù)管理、安全）,59,EJB,EJB： 編寫分布式業(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ù)。 提供聲明型安全，大部分情況下不再搖要編寫安全代碼求（bean部署描述符里的條目指定準(zhǔn)可以防問(wèn)某個(gè)具體bean）。,60,例：在兩個(gè)賬號(hào)間進(jìn)行轉(zhuǎn)賬的服務(wù)。,61,POJO（業(yè)務(wù)邏輯） +Hiibernate、JDO、iBATIS（持久化）、

20、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查詢 依賴注入 ,62,新設(shè)計(jì)是面向?qū)ο?、基于POJO, 而非基于EJB的過(guò)程式。 它使用構(gòu)建在JDBC上的持久層框架來(lái)訪問(wèn)數(shù)據(jù)庫(kù), 并不直接使用JDBC。 業(yè)務(wù)邏輯由POJO facade而非會(huì)話bean進(jìn)行封裝。 事務(wù)由Spring框架而非EJB容器進(jìn)行管理。 業(yè)務(wù)邏輯向表現(xiàn)層返回實(shí)際的業(yè)務(wù)對(duì)象

21、,而不是DTO。 應(yīng)用程序通過(guò)將組件的依賴作為setter或構(gòu)造子參數(shù)傳入來(lái)進(jìn)行組裝,而不是之前采用Java命名和目錄接口(JNDI )查詢的組件。 由于該設(shè)計(jì)面向?qū)ο?并采用上述輕量級(jí)技術(shù),因此較之前看到的EJB版本對(duì)開發(fā)人員要友好。,63,基于輕量級(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的種種好處。,64,65,面向?qū)ο蟮膬?yōu)點(diǎn)： 整個(gè)設(shè)計(jì)更易理解和維護(hù)。它并不是一個(gè)無(wú)所不能的大型類, 而是由大量小類組成, 每個(gè)類只共有若干職責(zé)。此外,諸如Account、Bank

22、ingTransaction和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ì)往往需耍修改核心代碼。,66,不適合用面向?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)的是彼此

23、的業(yè)務(wù)關(guān)系。 復(fù)雜的SQL固然不好維護(hù)，但業(yè)務(wù)真是復(fù)雜到簡(jiǎn)單的SQL都難以描述的程度，采用面向?qū)ο竺枋鰟t更加困難，維護(hù)也更困難，同時(shí)還損失了效率。 比較大的事務(wù)。 性能要求高的地方。（直接用Sql或者存儲(chǔ)過(guò)程；犧牲可維護(hù)性和可復(fù)用性） 上層流程。,67,消除DTO,68,部署POJO程序,69,70,71,面向?qū)ο笤O(shè)計(jì)的基本原則,72,73,liskov替換原則（LSP）,74,子類型必須能夠替換掉其基類型,問(wèn)題的根源是關(guān)于行為的： 基類中有的行為在子類中不存在或不適當(dāng)。 IS A的本質(zhì)是指行為的一致，而不是生活中的語(yǔ)言。 違反了LSP原則的本質(zhì)是派生類的行為與基類中的不一致。 如果違反了LS

24、P原則，常會(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原則。,75,違反LSP導(dǎo)致違反OCP的簡(jiǎn)單例子,76,改善,77,例：會(huì)議管理系統(tǒng),78,例：GUI對(duì)象,假定一個(gè)Component代表一個(gè)GUI對(duì)象，如按鈕或者文本框等。,79,80,81,改善2,82,例,83,接口隔離原則（ISP）,康凱,84,例,85,使用委托分離接口,86,使用多重繼承分離接口,87,內(nèi)接口與外接口,88,普通接口

25、與智能接口,89,軟件系統(tǒng)壞死的癥狀,90,“Copy”程序,一個(gè)從鍵盤讀入字符并輸出到打印機(jī)的程序。 void Copy() int c; while (c = RdKbd() != EOF) WrtPtr(c); ,91,需求在變化,用戶希望Copy程序能從紙帶讀入機(jī)中讀入信息。 現(xiàn)實(shí)中的約束不能改變接口 Copy程序的第一次修改結(jié)果 bool ptFlag = false; /remember to reset this flag void Copy() int c; while (c = (ptFlag ? Rdpt() : Rdkbd() != EOF) WrtPtr(c); ,92

26、,需求在變化2,客戶希望Copy程序有時(shí)可以輸出到紙帶穿孔機(jī)上。 /Copy程序的第二次修改結(jié)果 bool ptFlag = false; bool punchFlag = false; /remember to reset these flag void Copy() int c; while (c = (ptFlag ? Rdpt() : Rdkbd() != EOF) punchFlag ? WrtPunch(c) : WrtPtr(c); ,93,依賴倒置原則（DIP）,康凱,94,相關(guān)概念,關(guān)于解耦 依賴倒置（DIP） 控制反轉(zhuǎn)（IoC） 依賴注入（DI） 服務(wù)定位器（SL） 有些是

27、手段，有些是原則，不過(guò)其間的差異并不太重要，更重要的是其共同點(diǎn)：其根本目標(biāo)都是解除依賴，將組件的配置與使用分離開。 其它名詞 服務(wù) 組件 框架 類庫(kù) 應(yīng)用程序,95,接口和實(shí)現(xiàn)分離,面向過(guò)程的接口與實(shí)現(xiàn)分離,96,97,98,99,電影清單的例子,一個(gè)組件，用于提供一份電影清單，清單上列出的影片都是由一位特定的導(dǎo)演執(zhí)導(dǎo)的。 class MovieLister . public Movie moviesDirectedBy(String arg) List allMovies = finder.findAll(); for (Iterator it = allMovies.iterator();

28、 it.hasNext();) Movie movie = (Movie) it.next(); if (!movie.getDirector().equals(arg) it.remove(); return (Movie) allMovies.toArray(new MovieallMovies.size(); ,100,其中真正想要考察的是如何將MovieLister對(duì)象與特定的finder對(duì)象連接起來(lái)。 要求：我們希望moviesDirectedBy方法完全不依賴于影片的實(shí)際存儲(chǔ)方式。 這個(gè)方法只能引用一個(gè)finder對(duì)象， 而finder對(duì)象必須知道如何實(shí)現(xiàn)findAll的細(xì)節(jié)。 給

29、finder定義一個(gè)接口： public interface MovieFinder List findAll(); 當(dāng)要實(shí)際尋找影片時(shí)，就必須涉及到MovieFinder 的某個(gè)具體子類。在這里，我把“涉及具體子類”的代碼放在MovieLister 類的構(gòu)造函數(shù)中。,101,對(duì)抗變化,從一個(gè)逗號(hào)分隔的文本文件中獲得影片列表。 class MovieLister. private MovieFinder finder; public MovieLister() finder = new ColonDelimitedMovieFinder(movies1.txt); 對(duì)抗變化： 文件清單的名字更

30、改： 可以從一個(gè)配置文件獲得文件名。 如果用SQL 數(shù)據(jù)庫(kù)、XML 文件、web service，或者另一種格式的文本文件來(lái)存儲(chǔ)影片清單： 用另一個(gè)具體的類來(lái)獲取數(shù)據(jù)。該類從MovieFinder接口派生即可。 創(chuàng)建合適的MovieFinder派生類的實(shí)例： 不能對(duì)抗此變化。,102,配置文件,設(shè)定配置文件：XML 文件是比較理想的配置方式。 movies1.txt ,103,第三單元：用UML輔助系統(tǒng)分析與設(shè)計(jì),104,UML簡(jiǎn)介及常見疑難問(wèn)題辨析,105,UML用來(lái)描述模型的內(nèi)容有3種,分別是事物( Things )、關(guān)系Relationships )和圖( Diagrams )。,106

31、,UML中的關(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)系,107,一些常見問(wèn)題辨析,類的層次結(jié)構(gòu)表示 屬性與聚合 關(guān)聯(lián)角色 關(guān)聯(lián)類,108,層次結(jié)構(gòu),109,領(lǐng)域建模重?cái)?shù),110,細(xì)化類模型,111,關(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)的方法。,112,在創(chuàng)建類圖時(shí)，應(yīng)該為使用正確的角色名，而不是為

32、每個(gè)引用引入一個(gè)獨(dú)立的類。 因?yàn)榻巧梢詤^(qū)分對(duì)象，所以附在一個(gè)類上的關(guān)聯(lián)名必須唯一（可以把角色名想象成類的偽屬性）。同樣，角色名不應(yīng)該與類的屬性名重復(fù)。,113,關(guān)聯(lián)類,正如可以用屬性描述類的對(duì)象一樣，也可以用屬性來(lái)描述關(guān)聯(lián)的鏈接，可以把這樣的一組屬性組成關(guān)聯(lián)類。,114,Actor的一些注意事項(xiàng),包括人與系統(tǒng)，總是外部的。 定義了邊界。 Actor是“角色”，不是特定的人或特定的事。 要有恰當(dāng)?shù)拿帧?可以泛化 不是可有可無(wú)的東西。另一方面它可以劃分系統(tǒng)與外部實(shí)體的界限，是系統(tǒng)設(shè)計(jì)的起點(diǎn)。,115,用例的一些注意事項(xiàng),是需求分析的第一步。用戶首先關(guān)心功能。 用例是對(duì)一個(gè)系統(tǒng)或一個(gè)應(yīng)用的一種

33、單一的使用方式所作的描述,是關(guān)于單個(gè)活動(dòng)者在與系統(tǒng)對(duì)話中所執(zhí)行的處理行為的陳述序列。 不是事件流。 不是需求規(guī)格說(shuō)明，但反映了主要的功能性需求。 識(shí)別用例最好是從分析流開始。 每個(gè)用例都是獨(dú)立的。 用例名用動(dòng)賓結(jié)構(gòu)描述，不要寫成一個(gè)名詞。 用例是分層的，一般而言，高層/中層用例更有實(shí)際意義。 不要將不同的用例混合在一起。 用例與編碼：低層的用例可以輔助編碼，高層的不能。 擴(kuò)展用例：基礎(chǔ)用例不必知道擴(kuò)展用例的細(xì)節(jié)，只提供擴(kuò)展點(diǎn)。,116,倉(cāng)庫(kù)信息系統(tǒng)的用例圖,117,借鑒RUP的UML建模與分析,118,全局分析,全局分析側(cè)重于定義擬建系統(tǒng)所采用的構(gòu)架以及影響構(gòu)架的要素。全局分析充分利用相似或問(wèn)

34、題中的經(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)容。,119,全局分析,常見的分析機(jī)制留存分布式處理安全性進(jìn)程間通信消息路由進(jìn)程控制與同步交易事務(wù)管理信息交換信息的冗余錯(cuò)誤檢測(cè)、處理和報(bào)告數(shù)據(jù)格式轉(zhuǎn)換,120,局部分析,提取分析類 轉(zhuǎn)述需求場(chǎng)景 整理分析類,121,局部分析,分析類的類型劃分眾多實(shí)踐表明，如果立足于軟件功能需求

35、，擬建系統(tǒng)往往在三個(gè)維度易于發(fā)生變化：一、擬建系統(tǒng)和外部要素之間交互的邊界；第二，擬建系統(tǒng)要記錄和維護(hù)的信息；第三，擬建系統(tǒng)在運(yùn)行中的控制邏輯。通常按照這三個(gè)變化因素的維度，將分析類劃分為三種類型：邊界類、控制類、實(shí)體類,系統(tǒng)邊界,Use Case 行為協(xié)調(diào),基本信息,122,局部分析,123,局部分析,124,局部分析,125,局部分析,整理分析類分析類是這樣的類：它代表問(wèn)題域中的簡(jiǎn)潔抽象； 分析類映射到真實(shí)世界的業(yè)務(wù)概念（并且據(jù)此仔細(xì)命名）。 問(wèn)題域是首先產(chǎn)生軟件系統(tǒng)（以及從此而來(lái)的軟件開發(fā)活動(dòng)）需求的域。通常，這是特定的業(yè)務(wù)領(lǐng)域，如在線銷售或者客戶關(guān)系管理。然而，務(wù)必注意，問(wèn)題域可能根本

36、不是任何特定業(yè)務(wù)活動(dòng)，但 是可能產(chǎn)生需要軟件在其上運(yùn)轉(zhuǎn)的一塊物理硬件這是嵌入式系統(tǒng)?；旧希袠I(yè)務(wù)軟件開發(fā)服 務(wù)于某種業(yè)務(wù)需求，自動(dòng)化一個(gè)已有業(yè)務(wù)過(guò)程或者開發(fā)具有有意義的軟件組件的新產(chǎn)品。,126,分析類的職責(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é)集合，一

37、切都是為了維護(hù)客戶選擇的商品集合。它是內(nèi)聚的，因?yàn)樗械穆氊?zé)都朝著相同的目標(biāo)維護(hù)客戶已經(jīng)選擇的商品集合。實(shí)際上，我們能夠把這些職責(zé)概括為非常高級(jí)層 次的職責(zé)“維護(hù)購(gòu)物籃”。 同樣，向 ShoppingBasket 中添加如下職責(zé)：,127,分析類的職責(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ù)目的耦合。我們以給定類

38、與其他類具有關(guān)系的數(shù)目來(lái)度量類間的耦合度。類間職責(zé)的平均分布趨向于產(chǎn)生低耦合度。把控制或職責(zé)局限于單一的類趨向于增 加到該類的耦合度。,128,分析類經(jīng)驗(yàn)法則,以下是創(chuàng)建形式良好的分析類的一些經(jīng)驗(yàn)法則。 每個(gè)類大約35個(gè)職責(zé)典型地，類應(yīng)該保持盡可能簡(jiǎn)單，這通常限制類能夠支持的35個(gè)職 責(zé)的數(shù)目。先前ShoppingBasket 的示例是帶有小的和可管理數(shù)目職責(zé)的專注的類的好的示例。 不存在獨(dú)立的類好的OO分析和設(shè)計(jì)的精華是，類相互協(xié)作讓用戶受益。同樣，每個(gè)類應(yīng)該 同小部分類協(xié)作以提供所期望的功能。類可以把它們的一些職責(zé)托付給專注于特定功能的其他“輔助”類。 當(dāng)心很多非常小的類 有時(shí)很難取得正確

39、的平衡。如果模型看起來(lái)具有大量的非常小的類， 每個(gè)類都具有一個(gè)或者兩個(gè)職責(zé)，那么你應(yīng)該仔細(xì)查看以把一些小的類整合成更大的類。,129,當(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ú)立

40、成類。這些更小的類協(xié)作以實(shí)現(xiàn)由原始萬(wàn)能類所提供的行為。,130,分析類經(jīng)驗(yàn)法則,避免深度繼承樹設(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)為是“深度”繼承。,131,第四單元：設(shè)計(jì)模式與軟件設(shè)計(jì)思想,132,設(shè)計(jì)模式,133,設(shè)計(jì)模式在實(shí)際開發(fā)中的運(yùn)用,復(fù)用現(xiàn)有的、

41、高質(zhì)量的、針對(duì)常見的重復(fù)出現(xiàn)問(wèn)題的解決方案。 建立通用的術(shù)語(yǔ)以改善團(tuán)隊(duì)內(nèi)部的溝通。 將思考轉(zhuǎn)移到更高的視角。 判斷是否擁有正確的設(shè)計(jì)，而不僅僅使一個(gè)可以運(yùn)行的設(shè)計(jì)。 改善代碼的可修改性。 發(fā)現(xiàn)“龐大的繼承體系”的替代方案。,134,GoF中的模式分類,135,設(shè)計(jì)模式的特點(diǎn),設(shè)計(jì)模式最根本的意圖是適應(yīng)需求變化 隔離變化的部分與不變的部分，將之封裝起來(lái)。 針對(duì)接口編程，而不要針對(duì)實(shí)現(xiàn)編程 達(dá)成高內(nèi)聚合低耦合，提高復(fù)用 提倡優(yōu)先使用聚合，而不是繼承,136,例,一個(gè)日志記錄工具。目前需要提供一個(gè)日志API，提供客戶方便地調(diào)用。 該日志要求被記錄到指定的文本文件中，記錄的內(nèi)容屬于字符串類型，其值由客

42、戶提供。 可以容易地定義一個(gè)日志對(duì)象。 public class Log public void Write(string target, string log) /實(shí)現(xiàn)內(nèi)容; 當(dāng)客戶需要調(diào)用日志的功能時(shí)，可以創(chuàng)建日志對(duì)象，完成日志的記錄： Log log = new Log(); log.Write(“error.log”, “l(fā)og”);,137,138,139,例,我們需要設(shè)計(jì)一個(gè)數(shù)據(jù)庫(kù)組件，它能夠訪問(wèn)Sql Server數(shù)據(jù)庫(kù)。如果用ADO.Net，需要使用如下的對(duì)象： SqlConnection, SqlCommand, SqlDataAdapter等。 不用模式的做法：可以直接創(chuàng)建

43、這些對(duì)象： SqlConnection connection = new SqlConnection(strConnection); SqlCommand command = new SqlCommand(connection); SqlDataAdapter adapter = new SqlDataAdapter();,140,Connection對(duì)象：,141,142,策略（Strategy）模式,143,練習(xí),下面是一堆雜亂的類與接口：動(dòng)作冒險(xiǎn)游戲。包括代表游戲角色的類，以及武器行為的類。每個(gè)角色一次只能使用一個(gè)武器，但是可以在游戲的過(guò)程中換武器。 任務(wù)： 1.安排類。 2.找出一個(gè)抽

44、象類、一個(gè)接口、以及八個(gè)類。 3.在類之間畫箭頭。 A.繼承。B.實(shí)現(xiàn)接口。C.有一個(gè)關(guān)系。 4. 把setWeapon() 方法放到正確的類中。,144,原始的類與接口,145,例：電子零售系統(tǒng),該電子零售系統(tǒng)必須處理來(lái)自不同國(guó)家的銷售定單。例如在美國(guó)與加拿大。需求如下：,146,分析矩陣,147,橋接（Bridge）模式,148,意圖 “將抽象部分與它的實(shí)現(xiàn)部分分離，使它們都可以獨(dú)立地變化”。 抽象部分是指“不同的事物在概念層次上的聯(lián)系”。分離是指“讓各部分的行為各自獨(dú)立，或至少顯式指出關(guān)聯(lián)”。,149,例,通過(guò)引入一個(gè)Rectangle 抽象類，利用了這一事 實(shí)：不同的Rectangle

45、派 生類之間唯一的差異是如 何實(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方法。,150,需求變化,用戶要求支持另一種形狀圓形。,151,識(shí)別變化,首先識(shí)別出“什么在發(fā)生變化”。在上述的例子中，變化點(diǎn)是“不同類型的形狀”和“不同類型的畫圖程序”。共同的“概念”則是“形狀”和“畫圖程序”。 用Shape類來(lái)封裝擁有的形狀的概念。形狀有責(zé)任知道如何畫自己。Drawing對(duì)象負(fù)責(zé)畫線和圓。,152,描述

46、變化,下一步是描述出現(xiàn)的特定變化：Shape類擁有矩形和圓形。畫圖程序分別擁有一個(gè)基于DP1的對(duì)象（V1Drawing）和一個(gè)基于DP2的對(duì)象（V2Drawing）。,153,橋接模式,154,觀察者（observer）模式,康凱,155,156,命令（command）模式,康凱,157,意圖 將一個(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ì)

47、象，它們執(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類。,158,例子,159,結(jié)構(gòu),160,其它設(shè)計(jì)模式,161,VISITOR模式 該系列中的模式如下: VISlTOR模式 ACYCLIC VISITOR模式 DECORATOR模式 EXTENSION OBJECT模式,162,例,是一個(gè)常見的問(wèn)題：例如,有一

48、個(gè)Modem對(duì)象的層次結(jié)構(gòu)。基類中有所有調(diào)制解調(diào)器的公共方法。派生類代表不同調(diào)制解調(diào)器類型的驅(qū)動(dòng)程序。,163,問(wèn)題,假設(shè)需要向該層次結(jié)構(gòu)中增加一個(gè)新方法confrgureForUnix。使之可在UNIX下工作。在每個(gè)調(diào)制解調(diào)器派生類中該函數(shù)的實(shí)現(xiàn)都不相同。（假設(shè)每個(gè)不同的調(diào)制解調(diào)器在UNIX中都有自己獨(dú)特的配置方法和行為特征）。 問(wèn)題：直接增加configureForUnix方法其實(shí)回避了一個(gè)問(wèn)題：對(duì)于Windows如何處理? MacOS? Linux? 必須針對(duì)所使用的每一種新操作系統(tǒng)都要向Modem層次結(jié)構(gòu)中增加一個(gè)新方法? 這種做法是丑陋的：我們永遠(yuǎn)無(wú)法封閉Modem接口。每當(dāng)出現(xiàn)一種

49、新操作系統(tǒng)時(shí), 就必須更改該接口并重新部署所有的調(diào)制解調(diào)器軟件。,164,VISITOR模式的結(jié)構(gòu),165,VISITOR組合模式,VISTTOR模式的一個(gè)非常常見的應(yīng)用是,遍歷大量的數(shù)據(jù)結(jié)構(gòu)并產(chǎn)生報(bào)表。這使得數(shù)據(jù)結(jié)構(gòu)對(duì)象中不含有任何產(chǎn)生報(bào)表的代碼。如果想增加新報(bào)表,只需增加新的訪問(wèn)者,而不需要更改數(shù)據(jù)結(jié)構(gòu)中的代碼。這意味著報(bào)表可以被放置在不同的組件中,并且僅被那些需要它們的客戶單獨(dú)使用。,166,例：報(bào)表生成器,一個(gè)表示材料單的簡(jiǎn)單數(shù)據(jù)結(jié)構(gòu)。從該數(shù)據(jù)結(jié)構(gòu)可以生成無(wú)數(shù)的報(bào)表。 兩個(gè)可以統(tǒng)計(jì)的量：成本；數(shù)量 例如可以生成一張一個(gè)組合件總成本的報(bào)表,或者生成一張列出了一個(gè)組合件中所有零件的報(bào)表。,

50、167,VlSITOR模式的解決方法,168,其它模式,問(wèn)題： 考慮前面的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)器保持安靜。,169,DECORATOR模式,DECORATOR模式通過(guò)創(chuàng)建一個(gè)名為L(zhǎng)oudDialModem的全新類來(lái)解決這個(gè)問(wèn)題。 LoudDialModem派生自Modem ,并且委托給一個(gè)它包含的Modem實(shí)例。它捕獲對(duì)dial函數(shù)的調(diào)用并在委托前把音量設(shè)高。,170,多個(gè)Decorator,有時(shí),在同一個(gè)類層次結(jié)構(gòu)中可能存

51、在兩個(gè)或者更多的裝飾器（decorator）。 例如, 可能希望用LogoutExitModem來(lái)裝飾Modem層次結(jié)構(gòu), 當(dāng)Hangup被調(diào)用時(shí),它會(huì)發(fā)送字符串 exit。這個(gè)裝飾器必須要重復(fù)已經(jīng)在LoudDialModem中編寫過(guò)的所有委托代碼。,171,172,常用的軟件架構(gòu)風(fēng)格及適用情況分析,康凱,173,軟件架構(gòu) 軟件框架 常見的架構(gòu)風(fēng)格,174,軟件架構(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)元件（Architecture Comp

52、onent）、聯(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)需求。,175,建造一個(gè)系統(tǒng)所作出的最高層次的、以后難以更改的，商業(yè)的和技術(shù)的決定。 在建造一個(gè)系統(tǒng)之前會(huì)有很多的重要決定需要事先作出，而一旦系統(tǒng)開始進(jìn)行詳細(xì)設(shè)計(jì)甚至建造，這些決定就很難更改甚至無(wú)法更改。顯然，這樣的決定必定是有關(guān)系統(tǒng)設(shè)計(jì)成敗的最重要決定，必須經(jīng)過(guò)慎重的研究和考察。,176,架構(gòu)的目標(biāo),可靠性（Reliable）： 軟件系統(tǒng)對(duì)于用戶的商業(yè)經(jīng)營(yíng)和管理來(lái)說(shuō)

53、極為重要，因此軟件系統(tǒng)必須非?？煽?。 安全性（Secure） ： 軟件系統(tǒng)所承擔(dān)的交易的商業(yè)價(jià)值極高，系統(tǒng)的安全性非常重要。 可伸縮性（Scalable） ： 軟件必須能夠在用戶的使用率、用戶的數(shù)目增加很快的情況下，保持合理的性能。只有這樣，才能適應(yīng)用戶的市場(chǎng)擴(kuò)展得可能性。,177,架構(gòu)的目標(biāo),可定制化（Customizable） ： 同樣的一套軟件，可以根據(jù)客戶群的不同和市場(chǎng)需求的變化進(jìn)行調(diào)整。 可擴(kuò)展性（Extensible）： 在新技術(shù)出現(xiàn)的時(shí)候，一個(gè)軟件系統(tǒng)應(yīng)當(dāng)允許導(dǎo)入新技術(shù)，從而對(duì)現(xiàn)有系統(tǒng)進(jìn)行功能和性能的擴(kuò)展 可維護(hù)性（Maintainable）： 軟件系統(tǒng)的維護(hù)包括兩方面，一是排除

54、現(xiàn)有的錯(cuò)誤，二是將新的軟件需求反映到現(xiàn)有系統(tǒng)中去。一個(gè)易于維護(hù)的系統(tǒng)可以有效地降低技術(shù)支持的花費(fèi)。,178,客戶體驗(yàn)（Customer Experience）： 軟件系統(tǒng)必須易于使用。 市場(chǎng)時(shí)機(jī)（Time to Market）： 軟件用戶要面臨同業(yè)競(jìng)爭(zhēng)，軟件提供商也要面臨同業(yè)競(jìng)爭(zhēng)。以最快的速度爭(zhēng)奪市場(chǎng)先機(jī)非常重要。,179,架構(gòu)的種類,根據(jù)我們關(guān)注的角度不同，可以將架構(gòu)分成三種： 邏輯架構(gòu) 物理架構(gòu) 系統(tǒng)架構(gòu),180,邏輯架構(gòu),軟件系統(tǒng)中元件之間的關(guān)系，比如用戶界面，數(shù)據(jù)庫(kù)，外部系統(tǒng)接口，商業(yè)邏輯元件等等。,181,物理架構(gòu),軟件元件是怎樣放到硬件上的 下圖描述了一個(gè)分布于北京和上海的分布式系

55、統(tǒng)的物理架構(gòu)，圖中所有的元件都是物理設(shè)備，包括網(wǎng)絡(luò)分流器、代理服務(wù)器、WEB服務(wù)器、應(yīng)用服務(wù)器、報(bào)表服務(wù)器、整合服務(wù)器、存儲(chǔ)服務(wù)器、主機(jī)等等。,182,系統(tǒng)架構(gòu),系統(tǒng)的非功能性特征，如可擴(kuò)展性、可靠性、強(qiáng)壯性、靈活性、性能等。 系統(tǒng)架構(gòu)的設(shè)計(jì)要求架構(gòu)師具備軟件和硬件的功能和性能的過(guò)硬知識(shí)，這一工作是架構(gòu)設(shè)計(jì)工作中最困難的工作。,183,架構(gòu)的兩要素,元件劃分和設(shè)計(jì)決定。 邏輯元件： 一個(gè)軟件系統(tǒng)中的元件首先是邏輯元件。這些邏輯元件如何放到硬件上，以及這些元件如何為整個(gè)系統(tǒng)的可擴(kuò)展性、可靠性、強(qiáng)壯性、靈活性、性能等做出貢獻(xiàn)，是非常重要的信息。 設(shè)計(jì)決定： 進(jìn)行軟件設(shè)計(jì)需要做出的決定中，必然會(huì)包括

56、邏輯結(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ì)文檔。,184,軟件框架,什么是框架 框架與架構(gòu)的區(qū)別 常見的框架,185,框架,什么是框架？ 框架，即framework。是某種應(yīng)用的半成品，就是一組組件，供選用完成自己的系統(tǒng)。簡(jiǎn)單說(shuō)就是使用別人搭好的舞臺(tái)，你來(lái)做表演。而且，框架一般是成熟的，不斷升級(jí)的軟件。 框架與架構(gòu)的區(qū)別？ 并無(wú)明確的定義，但一般從層的觀點(diǎn)

57、看，認(rèn)為框架是底層的，接近系統(tǒng)的。軟件開發(fā)者在其上構(gòu)建自己的軟件架構(gòu)，開發(fā)自己的運(yùn)用程序。,186,為什么要用框架,因?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í)的，使用框架的開發(fā)者可以直接享受別人升級(jí)代碼帶來(lái)的好處。 框架一般處在低層應(yīng)用平臺(tái)（如J2EE）和高層業(yè)務(wù)邏輯之間的中間層。,187,

58、常見的框架,常見的JAVA框架 常見的.Net框架 其它基于C+的框架,188,常見的JAVA框架,EJB WAF Struts Turbine COCOON ECHO JATO TCF Spring Hibernate IBatis JSF,189,.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 在編寫 Windows 軟件（使用 ATL/COM、MFC、VB或標(biāo)準(zhǔn) Win32）方面，與當(dāng)前創(chuàng)建應(yīng)用程序的方式相比.NET都具有的優(yōu)勢(shì)。

59、,190,C+框架,ACE BOOST MFC ATL QT wxWidgets ,191,不同層次的模式,架構(gòu)模式(Architectural Pattern) 設(shè)計(jì)模式(Design Pattern) 代碼模式(Coding Pattern),192,區(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)或行為的