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

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

2、架構(gòu)設(shè)計(jì)212 第五單元：架構(gòu)設(shè)計(jì)實(shí)踐第五單元：架構(gòu)設(shè)計(jì)實(shí)踐225 3 第一單元：軟件生命周期與軟件架構(gòu)介紹 4 IT行業(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è)化 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)師能力要求： 一、

3、系統(tǒng)架構(gòu)相關(guān)的知識(shí)和經(jīng)驗(yàn)。 二、很強(qiáng)的自學(xué)能力、分析能力、解決問(wèn)題的能力。 三、寫(xiě)作、溝通表達(dá)、培訓(xùn)。 6 角色 軟件架構(gòu)師Software Architect 定義 主導(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à)

4、和確認(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)鍵決定的能力。 具備戰(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) 目成員的信任。 9 以目標(biāo)導(dǎo)向和主動(dòng)的方式來(lái)不帶任何感情色彩地關(guān)注項(xiàng)目結(jié)果，構(gòu)架 師應(yīng)當(dāng)是項(xiàng)目背后

5、的技術(shù)推動(dòng)力，而非構(gòu)想者或夢(mèng)想家（追求完美） 精通構(gòu)架設(shè)計(jì)的理論、實(shí)踐和工具，并掌握多種參考構(gòu)架、主要的可 重用構(gòu)架機(jī)制和模式。 具備系統(tǒng)設(shè)計(jì)員的所有技能，但涉及面更廣、抽象級(jí)別更高。 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ù)等方面

6、，而 軟件架構(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ì)低些。 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

7、Rails Rup BPEL Workflow Engine LBS Oracle CMMI MQ 13 軟件架構(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ì)方案的正確性 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)行維

8、護(hù)等。 深入掌握1-2種主流技術(shù)平臺(tái)上開(kā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)的非功能需求和運(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)師的思維

9、方式 風(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)秀的方案 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)

10、安全性和可靠性技術(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)、軟件工程標(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)有軟、

11、硬件和數(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ù)建模和逆向工程等。 21 (6)分布式系統(tǒng)設(shè)計(jì)：包括分布式通信協(xié)議的設(shè)計(jì)、

12、基于對(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)等。 22 軟件架構(gòu)師的任職條件 根據(jù)軟件架構(gòu)師的職責(zé)和角

13、色定位，以及知識(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)。 23 (5)對(duì)設(shè)計(jì)模式有深刻的理解，并能在此基礎(chǔ)上設(shè)計(jì)出適合產(chǎn)品特性和 質(zhì)

14、量屬性的框架。 (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ù)和新方法。 24 第二單元：技術(shù)架構(gòu)視圖面向?qū)ο蟪绦?設(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)層（p

15、resent） 業(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í)體的形為最難決斷。 為確定行為，我們必須識(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í)體的集合

16、,主要有查找和刪除實(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ì)象中。 51 領(lǐng)域模型 失血模型 貧血模型 充血模型 脹血模型 52 失血模型 DO只有屬性及其getter/setter

17、方法，沒(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)定。 缺點(diǎn)： DO部分的持久化邏輯被放入Service層，不夠OO。 Service層過(guò)重。 54 充血模型 與貧血模型類似，不同處在于如何劃分業(yè)務(wù)邏輯：絕大多 業(yè)務(wù)邏輯都應(yīng)該放在DO里(包括持久化邏輯)，而Service 層很薄，僅僅封裝事務(wù)和少量邏輯，不和DAO層打交道。 Service(事

18、務(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ù)封裝方法，造成重定義所有的Domain logic。 Service的事務(wù)化封裝的意義等于把OO的Domain logic 轉(zhuǎn)換為過(guò)程的Service 事務(wù)腳本。充血模型在domain層 實(shí)現(xiàn)的OO在Service層又變成了面向過(guò)程。 56 脹血模型 取消Service層，只剩下DO和DAO層，

19、在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ù)封裝了 外在于業(yè)務(wù)對(duì)象的業(yè)務(wù)邏輯。 58 EJB到輕量級(jí)框架 EJB POJO （業(yè)務(wù)邏輯） + 輕量級(jí)框架（Hibernate、JDO、 iBATIS（持久化）、Spring（事務(wù)管理、安全） 59 EJB EJB： 編寫(xiě)分布式業(yè)務(wù)應(yīng)用程序的Java標(biāo)準(zhǔn)架構(gòu)。 提供大量服務(wù)： 聲明型事

20、務(wù), EIB容器自動(dòng)啟動(dòng)、提交和回滾事務(wù)。 業(yè)務(wù)邏輯能參與由遠(yuǎn)程客戶發(fā)起的分布式事務(wù)。 提供聲明型安全，大部分情況下不再搖要編寫(xiě)安全代 碼求（bean部署描述符里的條目指定準(zhǔn)可以防問(wèn)某個(gè) 具體bean）。 60 例：在兩個(gè)賬號(hào)間進(jìn)行轉(zhuǎn)賬的服務(wù)。 61 POJO（業(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框

21、架 應(yīng)用程序組裝 顯式的JNDI查詢 依賴注入 62 新設(shè)計(jì)是面向?qū)ο蟆⒒赑OJO, 而非基于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ì)象,而不是DTO。 應(yīng)用程序通過(guò)將組件的依賴作為setter或構(gòu)造子參數(shù)傳入 來(lái)進(jìn)行組裝,而不是之前采用Java命名和目錄接口(JNDI ) 查詢的組件。 由于該設(shè)計(jì)面向?qū)ο?并采用上述輕量級(jí)技術(shù),因此較之前 看到的EJB版本對(duì)開(kāi)發(fā)人員要友好。 63 基于輕量級(jí)框架設(shè)計(jì)

22、的好處是，它提供事務(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、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è)試,難度大

23、。(只能測(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) 的是彼此的業(yè)務(wù)關(guān)系。 復(fù)雜的SQL固然不好維護(hù)， 但業(yè)務(wù)真是復(fù)雜到簡(jiǎn)單的SQL都難以描述的程度， 采用面向?qū)ο竺枋鰟t更加困難，維護(hù)也更困難，同 時(shí)還損失了效率。 比較大的事務(wù)。 性能要求高的地方。（直接用Sql或者存儲(chǔ)過(guò)程；犧牲 可維護(hù)性和可

24、復(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ì)是派生類的行為與基類中的不一致。 如果違反了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)的具體類型，

25、否則就會(huì)出錯(cuò)，這就已 經(jīng)違反了OCP原則。 75 違反LSP導(dǎo)致違反OCP的簡(jiǎn)單例子 76 改善 77 例：會(huì)議管理系統(tǒng) 78 例：GUI對(duì)象 假定一個(gè)假定一個(gè)Component代表一個(gè)代表一個(gè)GUI對(duì)象，如按鈕或者文本框等。對(duì)象，如按鈕或者文本框等。 79 80 81 改善2 82 例 83 接口隔離原則（ISP） 康凱 84 例 85 使用委托分離接口 86 使用多重繼承分離接口 87 內(nèi)接口與外接口 Package IOuter InnerPackage IInner 88 普通接口與智能接口 Package INormal ISmart 89 軟件系統(tǒng)壞死的癥狀 90 “Copy”程序

26、程序 一個(gè)從鍵盤讀入字符并輸出到打印機(jī)的程序。一個(gè)從鍵盤讀入字符并輸出到打印機(jī)的程序。 void Copy() int c; while (c = RdKbd() != EOF) WrtPtr(c); 91 需求在變化 用戶希望用戶希望Copy程序能從紙帶讀入機(jī)中讀入信息。程序能從紙帶讀入機(jī)中讀入信息。 現(xiàn)實(shí)中的約束不能改變接口現(xiàn)實(shí)中的約束不能改變接口 Copy程序的第一次修改結(jié)果程序的第一次修改結(jié)果 bool ptFlag = false; /remember to reset this flag void Copy() int c; while (c = (ptFlag ? Rdpt()

27、: Rdkbd() != EOF) WrtPtr(c); 92 需求在變化2 客戶希望客戶希望Copy程序有時(shí)可以輸出到紙帶穿孔機(jī)上。程序有時(shí)可以輸出到紙帶穿孔機(jī)上。 /Copy程序的第二次修改結(jié)果程序的第二次修改結(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

28、） 康凱 94 相關(guān)概念 關(guān)于解耦 依賴倒置（DIP） 控制反轉(zhuǎn)（IoC） 依賴注入（DI） 服務(wù)定位器（SL） 有些是手段，有些是原則，不過(guò)其間的差異并不太重要，更重要的是其 共同點(diǎn)：其根本目標(biāo)都是解除依賴，將組件的配置與使用分離開(kāi)。 其它名詞 服務(wù) 組件 框架 類庫(kù) 應(yīng)用程序 95 接口和實(shí)現(xiàn)分離接口和實(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 a

29、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(); 100 其中真正想要考察的是如何將MovieLister對(duì)象與特定的finder對(duì)象連接起來(lái)。 要求：我們希望moviesDirectedBy方

30、法完全不依賴于影片的實(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è)具體子類。在這里， 我把“涉及具體子類”的代碼放在MovieLister 類的構(gòu)造函數(shù)中。 101 對(duì)抗變化 從一個(gè)逗號(hào)分隔的文本文件中獲得影片列表。 class MovieLister. private MovieFinder finder; public MovieLister(

31、) finder = new ColonDelimitedMovieFinder(movies1.txt); 對(duì)抗變化： 文件清單的名字更改： 可以從一個(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)介及常見(jiàn)疑難問(wèn)題辨析 105

32、 UML用來(lái)描述模型的內(nèi)容有3種,分別是事物( Things )、關(guān)系 Relationships )和圖( Diagrams )。 106 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 一些常見(jiàn)問(wèn)題辨析 類的層次結(jié)構(gòu)表示 屬性與聚合 關(guān)聯(lián)角色 關(guān)聯(lián)類 108 層次結(jié)構(gòu) PartAssembly IComponent * * 109 領(lǐng)域建模重?cái)?shù) 110 細(xì)化類模型 111 關(guān)聯(lián)角色 關(guān)聯(lián)角色名出現(xiàn)在關(guān)聯(lián)終端

33、的旁邊。當(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) 的方法。 PersonCompany 0.1* *0.1 +employee+employer employee Joe Doe Mary Brown Jean Smith employer Simplex Simplex United Widgets 112 在創(chuàng)建類圖時(shí)，應(yīng)該為使用正確的角色名，而不是為每個(gè)引用引入一 個(gè)獨(dú)立的類。 因?yàn)榻巧梢詤^(qū)分對(duì)象，所以附在一個(gè)類上的關(guān)聯(lián)名必須唯一（可 以把角色名想象成類的偽屬性）。同樣，角色名不應(yīng)該與類的屬性名 重

34、復(fù)。 ParentChild 0.n20.n2 Person * 0.2 +Child +Parent * 0.2 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)用的一種單一的使用方式所作的描述,是關(guān) 于單

35、個(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)。 116 倉(cāng)庫(kù)信息系統(tǒng)的用例圖 117 借鑒RUP的UML建模與分析 118 全局分析 全局分析側(cè)重于定義擬建系統(tǒng)所采用的構(gòu)架以及影響構(gòu)架 的要素。全局分析充分利用相似或問(wèn)題中的經(jīng)驗(yàn)，避免在 確定構(gòu)架上浪

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

37、求，擬建系統(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)的軟件開(kāi)發(fā)活 動(dòng)）需求的域。通常，這是特定的業(yè)務(wù)領(lǐng)域，如在線銷售 或者客戶關(guān)系管理。然而，務(wù)必注意

38、，問(wèn)題域可能根本不 是任何特定業(yè)務(wù)活動(dòng)，但 是可能產(chǎn)生需要軟件在其上運(yùn) 轉(zhuǎn)的一塊物理硬件這是嵌入式系統(tǒng)。基本上，所有業(yè)務(wù) 軟件開(kāi)發(fā)服 務(wù)于某種業(yè)務(wù)需求，自動(dòng)化一個(gè)已有業(yè)務(wù)過(guò) 程或者開(kāi)發(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)物籃中

39、的商品。 這是內(nèi)聚的職責(zé)集合，一切都是為了維護(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)聚性，是很重要的。 最后，良好的類

40、與其他類之間具有最低數(shù)目的耦合。我們以給定類與 其他類具有關(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é)托付給專注于特定功

41、能的其他“輔助” 類。 當(dāng)心很多非常小的類 有時(shí)很難取得正確的平衡。如果模型看起 來(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)任何工作的類。看看名稱為 “system”和“controller”的 類！處理這個(gè)問(wèn)題的策略是看看萬(wàn)能

42、 類的職責(zé)是否能夠分解成內(nèi)聚的子集。如果是，每個(gè)這些 內(nèi)聚職 責(zé)集合可能獨(dú)立成類。這些更小的類協(xié)作以實(shí)現(xiàn)由原始萬(wàn)能類所 提供的行為。 130 分析類經(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)為是“深度”繼承。 131 第四單元：

43、設(shè)計(jì)模式與軟件設(shè)計(jì)思想 132 設(shè)計(jì)模式 133 設(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)“龐大的繼承體系”的替代方案。 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，提

44、供客戶方便地調(diào) 用。 該日志要求被記錄到指定的文本文件中，記錄的內(nèi)容屬于字符串類型， 其值由客戶提供。 可以容易地定義一個(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 Log + Write() ILog + Execute() Log2TxtFile + Execute() Log2XmlFile + Execute

45、() Log2DB + Execute() 138 139 例 我們需要設(shè)計(jì)一個(gè)數(shù)據(jù)庫(kù)組件，它能夠訪問(wèn)Sql Server數(shù)據(jù)庫(kù)。 如果用ADO.Net，需要使用如下的對(duì)象： SqlConnection, SqlCommand, SqlDataAdapter等。 不用模式的做法：可以直接創(chuàng)建這些對(duì)象： SqlConnection connection = new SqlConnection(strConnection); SqlCommand command = new SqlCommand(connection); SqlDataAdapter adapter = new SqlDataAd

46、apter(); 140 Connection對(duì)象： SqlConn ection OracleCon nection SybaseCon nection IConnection 141 142 策略（Strategy）模式 143 練習(xí) 下面是一堆雜亂的類與接口： 動(dòng)作冒險(xiǎn)游戲。包括代表游戲角色的類，以及武器行為的類。 每個(gè)角色一次只能使用一個(gè)武器，但是可以在游戲的過(guò)程中換 武器。 任務(wù)： 1.安排類。 2.找出一個(gè)抽象類、一個(gè)接口、以及八個(gè)類。 3.在類之間畫(huà)箭頭。 A.繼承。B.實(shí)現(xiàn)接口。C.有一個(gè)關(guān)系。 4. 把setWeapon() 方法放到正確的類中。 144 原始的類與接口 14

47、5 例：電子零售系統(tǒng) 該電子零售系統(tǒng)必須處理來(lái)自不同國(guó)家的銷售定單。例如在 美國(guó)與加拿大。需求如下： 請(qǐng)況請(qǐng)況過(guò)程過(guò)程 美國(guó)l 據(jù)UPS的價(jià)格計(jì)算運(yùn)費(fèi) l 使用美國(guó)郵政規(guī)則檢查地址 l 根據(jù)銷售額或服務(wù),按照當(dāng)?shù)囟愂找?guī)則計(jì)算稅費(fèi)金額 l 使用美元處理款項(xiàng) 加拿大 l 根據(jù)主要的加拿大托運(yùn)公司的價(jià)格計(jì)算運(yùn)費(fèi) l 使用加拿大郵政規(guī)則檢查地址 l 根據(jù)銷售額或服務(wù),按照加拿大各省的稅收規(guī)則計(jì)算稅費(fèi) 金額(GST和PST) l 使用加拿大元處理款項(xiàng) 146 分析矩陣 147 橋接（Bridge）模式 148 意圖 “將抽象部分與它的實(shí)現(xiàn)部分分離，使它們都可以獨(dú)立 地變化”。 抽象部分是指“不同的事物在

48、概念層次上的聯(lián)系”。分 離是指“讓各部分的行為各自獨(dú)立，或至少顯式指出關(guān) 聯(lián)”。 149 例 通過(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方法。 150 需求變化 用戶要求支持另一種形狀圓形。 151 識(shí)別變化 首先識(shí)別出“什么在發(fā)生變化”。在上述的例子中，變 化點(diǎn)是“不同類型的形狀”和

49、“不同類型的畫(huà)圖程序”。 共同的“概念”則是“形狀”和“畫(huà)圖程序”。 用Shape類來(lái)封裝擁有的形狀的概念。形狀有責(zé)任知道 如何畫(huà)自己。Drawing對(duì)象負(fù)責(zé)畫(huà)線和圓。 152 描述變化 下一步是描述出現(xiàn)的特定變化：Shape類擁有矩形和圓 形 。 畫(huà) 圖 程 序 分 別 擁 有 一 個(gè) 基 于 D P 1 的 對(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ì)或

50、記錄請(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 類。 158 例子 ex

51、ecute() command + execute() Icommand + execute() Interfac. command + execute() 1 2 3 command + execute() 4 Icommand + execute() Interfac. Invoker 1.*1.* 159 結(jié)構(gòu) 160 其它設(shè)計(jì)模式 161 VISITOR模式 該系列中的模式如下: VISlTOR模式 ACYCLIC VISITOR模式 DECORATOR模式 EXTENSION OBJECT模式 162 例 是一個(gè)常見(jiàn)的問(wèn)題：例如,有一個(gè)Modem對(duì)象的層次結(jié)構(gòu)?；愔杏兴姓{(diào)制 解調(diào)

52、器的公共方法。派生類代表不同調(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)一種新操作系統(tǒng)時(shí), 就必須更改該接口并重

53、新部署所有的調(diào)制解 調(diào)器軟件。 164 VISITOR模式的結(jié)構(gòu) 165 VISITOR組合模式 VISTTOR模式的一個(gè)非常常見(jiàn)的應(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)表。 167 VlSITOR模

54、式的解決方法 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ī)。有些用戶希望聽(tīng)到撥號(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)中可能存在兩個(gè)或者更多

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

56、t）、聯(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) 開(kāi)始進(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)和

57、管理來(lái)說(shuō)極為重要，因此軟件系 統(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ù)包括

58、兩方面，一是排除現(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è)分

59、布于北京和上海的分布式系統(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ì)包括邏輯結(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ū)別 常見(jiàn)的框架 185 框架 什么是框架？ 框架，即framework。是某種應(yīng)用的半成品，就是一組組件，供選 用完成自己的系統(tǒng)。簡(jiǎn)單說(shuō)就是使用別人搭好的舞臺(tái)，你來(lái)做表 演。而且，框架一般是成熟的，不斷升級(jí)的軟件。 框