高級軟件架構設計課件

1高級軟件架構設計1高級軟件架構設計2目錄第一單元：軟件生命周期與軟件架構介紹 第二單元：技術架構視圖─面向對象程序設計原則與模式

用GRASP模式指導設計 領域模型

面向對象設計的基本原則 第三單元：用UML輔助系統(tǒng)分析與設計 UML簡介及常見疑難問題辨析 借鑒RUP的UML建模與分析 第四單元：設計模式與軟件設計思想 設計模式

常用的軟件架構風格及適用情況分析

SOA及分層架構設計 第五單元：架構設計實踐 2目錄第一單元：軟件生命周期與軟件架構介紹 3第一單元：軟件生命周期與軟件架構介紹3第一單元：軟件生命周期與軟件架構介紹4IT行業(yè)的人才結構與軟件架構師的定位軟件架構師應掌握的知識體系軟件架構設計的特點、層次、分類軟件架構的主要理論、方向和趨勢軟件工廠，實現(xiàn)軟件開發(fā)的產業(yè)化4IT行業(yè)的人才結構與軟件架構師的定位5軟件架構師的定位系統(tǒng)架構師的職責：一、理解系統(tǒng)的業(yè)務需求，制定系統(tǒng)的整體框架（包括：技術框架和業(yè)務框架）二、對系統(tǒng)框架相關技術和業(yè)務進行培訓，指導開發(fā)人員開發(fā)。并解決系統(tǒng)開發(fā)、運行中出現(xiàn)的各種問題。系統(tǒng)架構師的目的：對系統(tǒng)的重用、擴展、安全、性能、伸縮性、簡潔等做系統(tǒng)級的把握。系統(tǒng)架構師能力要求：一、系統(tǒng)架構相關的知識和經驗。二、很強的自學能力、分析能力、解決問題的能力。三、寫作、溝通表達、培訓。5軟件架構師的定位系統(tǒng)架構師的職責：6角色軟件架構師SoftwareArchitect定義主導系統(tǒng)全局分析設計和實施、負責軟件構架和關鍵技術決策的角色6角色7職責領導與協(xié)調整個項目中的技術活動（分析、設計和實施等）推動主要的技術決策，并最終表達為軟件構架確定和文檔化系統(tǒng)的相對構架而言意義重大的方面，包括系統(tǒng)的需求、設計、實施和部署等“視圖”確定設計元素的分組以及這些主要分組之間的接口為技術決策提供規(guī)則，平衡各類涉眾的不同關注點，化解技術風險，并保證相關決定被有效的傳達和貫徹理解、評價并接收系統(tǒng)需求評價和確認軟件架構的實現(xiàn)7職責8專業(yè)技能技術全面、成熟練達、洞察力強、經驗豐富，具備在缺乏完整信息、眾多問題交織一團、模糊和矛盾的情況下，迅速抓住問題要害，并做出合理的關鍵決定的能力。具備戰(zhàn)略性和前瞻性思維能力，善于把握全局，能夠在更高抽象級別上進行思考。對項目開發(fā)涉及的所有問題領域都有經驗，包括徹底地理解項目需求，開展分析設計之類軟件工程活動等。具備領導素質，以在各小組之間推進技術工作，并在項目壓力下做出牢靠的關鍵決策。擁有優(yōu)秀的溝通能力，用以進行說服、鼓勵和指導等活動，并贏得項目成員的信任。8專業(yè)技能9以目標導向和主動的方式來不帶任何感情色彩地關注項目結果，構架師應當是項目背后的技術推動力，而非構想者或夢想家（追求完美）精通構架設計的理論、實踐和工具，并掌握多種參考構架、主要的可重用構架機制和模式。具備系統(tǒng)設計員的所有技能，但涉及面更廣、抽象級別更高。9以目標導向和主動的方式來不帶任何感情色彩地關注項目結果，構10軟件架構師的知識體系軟件架構師作為整個軟件系統(tǒng)結構的總設計師，其知識體系、技能和經驗決定了軟件系統(tǒng)的可靠性、安全性、可維護性、可擴展性和可移植性等方面的性能。因此一個優(yōu)秀的軟件架構師必須具備相當豐富的知識、技能和經驗。通過對比軟件架構師和系統(tǒng)分析師在軟件開發(fā)中的職責和角色，不難發(fā)現(xiàn)軟件架構師與系統(tǒng)分析師所必需的知識體系也是不盡相同的，系統(tǒng)分析師的主要職責是在需求分析、開發(fā)管理、運行維護等方面，而軟件架構師的重點工作是在架構與設計這兩個關鍵環(huán)節(jié)上。因此在系統(tǒng)分析師必須具備的知識體系中對系統(tǒng)的構架與設計等方面知識體系的要求就相對低些；而軟件架構師在需求分析、項目管理、運行維護等方面知識的要求也就相對低些。10軟件架構師的知識體系軟件架構師作為整個軟件系統(tǒng)結構的總設11成為一名合格的軟件架構師必須具備的知識信息系統(tǒng)綜合知識體系軟件架構知識體系11成為一名合格的軟件架構師必須具備的知識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軟件架構師在干什么？思考、思考、再思考深入理解、準確把握建設的業(yè)務需求分析所有可見的問題、障礙、風險充分參考已有的成功方案，降低風險交流、討論、博弈、質疑對構思中的方案不斷提出質疑，避免漏洞廣泛聽取各層面的意見，開拓思路反復質疑、逐步完善已有的設計構思在動手實現(xiàn)之前驗證設計方案的正確性13軟件架構師在干什么？思考、思考、再思考14軟件架構師的知識結構軟件知識最好要有系統(tǒng)開發(fā)全過程經驗。對IT建設生命周期各個環(huán)節(jié)有深入了解，包括：系統(tǒng)/模塊邏輯設計、物理設計、代碼開發(fā)、項目管理、測試、發(fā)布、運行維護等。深入掌握1-2種主流技術平臺上開發(fā)系統(tǒng)的方法。了解多種應用系統(tǒng)的結構。了解架構設計領域的主要理論、流派、框架。14軟件架構師的知識結構軟件知識15軟件架構師的知識結構業(yè)務知識深入了解系統(tǒng)建設的業(yè)務需求。了解系統(tǒng)的非功能需求和運行維護需求。了解企業(yè)IT公共設施、網絡環(huán)境、外部系統(tǒng)。15軟件架構師的知識結構業(yè)務知識16軟件架構師的思維方式基于框架的思維架構設計的層次（Enterprise，Application，etc）IT的生命周期（What，Why，Where，How，When，etc）成功經驗以及方法論的指導合理把握技術細節(jié)把握各個層次應有的內容合理忽略不應有的技術細節(jié)16軟件架構師的思維方式基于框架的思維17軟件架構師的思維方式風險管理意識采用成功經驗、避免不應有的風險多方位的開放思維多維度、多方向、包容性、避免排他性分析、質疑、抽象、歸納沒有絕對好的架構設計，只有相對優(yōu)秀的方案17軟件架構師的思維方式風險管理意識18信息系統(tǒng)綜合知識體系(1)計算機系統(tǒng)綜合知識：包括計算機組成與體系結構、嵌入式系統(tǒng)和操作系統(tǒng)等方面的知識。(2)系統(tǒng)配置和方法：包括系統(tǒng)配置技術和系統(tǒng)性能等方面的知識。(3)典型系統(tǒng)應用：包括網絡應用、數(shù)據庫應用和多媒體系統(tǒng)等方面的知識。(4)系統(tǒng)開發(fā)：包括程序設計語言、軟件開發(fā)方法、需求分析和設計方法、測試評審方法、開發(fā)管理、應用系統(tǒng)構建、系統(tǒng)審計、外部資源使用和基于中間件的開發(fā)等方面的知識。(5)安全性和可靠性技術：包括數(shù)據安全與保密、防闖入和防病毒、容錯技術、可靠性模型與分析技術、系統(tǒng)可靠性、安全規(guī)章和保護私有信息規(guī)則等方面的知識。18信息系統(tǒng)綜合知識體系(1)計算機系統(tǒng)綜合知識：包括計算機19(6)標準化：包括標準化的基礎知識、標準化分級、編碼標準、數(shù)據交換標準、軟件工程標準、信息安全標準、基于構件的軟件標準和標準化組織機構等方面的知識。(7)信息化基礎：包括政府信息化與電子政務、企業(yè)信息化與電子商務、信息化的有關的法律和規(guī)定等方面的知識。(8)數(shù)學和英語：至少具有大學以上的數(shù)學和英語基礎知識。19(6)標準化：包括標準化的基礎知識、標準化分級、編碼標準20軟件架構知識體系(1)系統(tǒng)計劃：包括項目的提出和可行性分析、系統(tǒng)方案的制定、評價和改進、新舊系統(tǒng)的分析與比較、現(xiàn)有軟、硬件和數(shù)據資源的有效利用等。(2)軟件架構設計：包括軟件架構的概念、軟件架構與設計、架構風格、特定領域的架構風格、基于架構的軟件開發(fā)方法、架構評估、軟件產品線和系統(tǒng)演化等。(3)設計模式：包括設計模式的概念、組成、分類和實現(xiàn)、模式和軟件架構的關系等。(4)系統(tǒng)設計：包括處理流程設計、人機界面設計、文件與存儲設計、數(shù)據庫設計、網絡應用系統(tǒng)的設計、系統(tǒng)運行環(huán)境的集成與設計、中間件與應用服務器、性能設計與性能評估等。(5)軟件建模：包括定義問題與歸結模型、結構化系統(tǒng)建模與數(shù)據流圖、面向對象系統(tǒng)建模、數(shù)據庫建模和逆向工程等。

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

23(5)對設計模式有深刻的理解，并能在此基礎上設計出適合產24第二單元：技術架構視圖─面向對象程序設計原則與模式24第二單元：技術架構視圖─面向對象程序設計原則與模式2525262627用GRASP模式指導設計27用GRASP模式指導設計2828292930303131323233333434353536363737383839394040414142424343444445領域模型45領域模型46層次結構領域模型從EJB到輕量級框架46層次結構47層次結構表現(xiàn)層（present）業(yè)務層業(yè)務層外觀業(yè)務層核心領域對象管理/服務/倉庫層領域對象層持久層數(shù)據訪問層數(shù)據庫47層次結構表現(xiàn)層（present）48領域模型中的各種角色：實體--有唯一的標識,并且要有屬性和行為(非GET/SET)，添加了行為，使其具有生命力。往往在設計時，實體的形為最難決斷。為確定行為，我們必須識別它們的責任和協(xié)作。類的責任是指該類要做、知道、或決定的一切，由一個或多個方法完成。類中有屬性和關聯(lián)，協(xié)作就是為完成自己的責任所調用其它關聯(lián)類。值對象--沒有標識沒有行為。如Address類。工廠---定義創(chuàng)建實體的方法，封裝實例化對象并將一些關聯(lián)對象注入。倉庫(repository)管理實體的集合,主要有查找和刪除實體的方法.實現(xiàn)類可以調用執(zhí)久化層(如Hibernate，Ibatis)服務(Service)，實現(xiàn)整個應用程序的工作流(workflow)。服務包含那些無法指派的單個實體的行為，由作用于多個對象方法組成。如可以調用repository查找到實體對象，然后委派給這些對象。服務和facade很像，但不一樣，它不處理以下事情：1）執(zhí)行事務。2）收集返回給表現(xiàn)層的數(shù)據。3）脫鉤對象。4）其它事情。服務可以說是業(yè)務的協(xié)調者，業(yè)務邏輯可以分散到實體對象中。48領域模型中的各種角色：49領域模型失血模型貧血模型充血模型脹血模型49領域模型失血模型50失血模型DO只有屬性及其getter/setter方法，沒有任何業(yè)務邏輯。缺點：行為與數(shù)據分離，很多情況導致維護與理解困難。50失血模型DO只有屬性及其getter/setter方法，51貧血模型DO包含不依賴于持久化的領域邏輯；依賴持久化的領域邏輯歸入Service層。Service(業(yè)務邏輯，事務封裝)DAODO優(yōu)點：各層單向依賴，結構清楚，易于實現(xiàn)和維護。設計簡單易行，底層模型非常穩(wěn)定。缺點：DO部分的持久化邏輯被放入Service層，不夠OO。Service層過重。51貧血模型DO包含不依賴于持久化的領域邏輯；依賴持久化的領52充血模型與貧血模型類似，不同處在于如何劃分業(yè)務邏輯：絕大多業(yè)務邏輯都應該放在DO里(包括持久化邏輯)，而Service層很薄，僅僅封裝事務和少量邏輯，不和DAO層打交道。Service(事務封裝)DODAO優(yōu)點：符合OOService層很薄，只充當Facade的角色，不和DAO打交道。52充血模型與貧血模型類似，不同處在于如何劃分業(yè)務邏輯：絕大53缺點：DAO和DO雙向依賴。如何劃分Service層邏輯和Domain層邏輯沒有確定的規(guī)則，取決與設計人員自己的理解。Service層封裝事務，須對所有的DO邏輯提供相應的事務封裝方法，造成重定義所有的Domainlogic。Service的事務化封裝的意義等于把OO的Domainlogic轉換為過程的Service事務腳本。充血模型在domain層實現(xiàn)的OO在Service層又變成了面向過程。53缺點：54脹血模型取消Service層，只剩下DO和DAO層，在DO的domainlogic上面封裝事務。DO(事務封裝，業(yè)務邏輯)DAO(RoR甚至合并為一層）

優(yōu)點：分層簡化符合OO缺點：service邏輯也強行放入DO，引起了DO不穩(wěn)定。DO暴露給web層過多的信息，可能引起不必要的耦合。54脹血模型取消Service層，只剩下DO和DAO層，在D55原則：業(yè)務對象封裝了內在的業(yè)務邏輯，而應用服務封裝了外在于業(yè)務對象的業(yè)務邏輯。55原則：56EJB到輕量級框架EJBPOJO（業(yè)務邏輯）+輕量級框架（[Hibernate、JDO、iBATIS]（持久化）、Spring（事務管理、安全））56EJB到輕量級框架EJB57EJBEJB：編寫分布式業(yè)務應用程序的Java標準架構。提供大量服務：聲明型事務,EIB容器自動啟動、提交和回滾事務。業(yè)務邏輯能參與由遠程客戶發(fā)起的分布式事務。提供聲明型安全，大部分情況下不再搖要編寫安全代碼求（bean部署描述符里的條目指定準可以防問某個具體bean）。57EJBEJB：58例：在兩個賬號間進行轉賬的服務。58例：在兩個賬號間進行轉賬的服務。59POJO（業(yè)務邏輯）+Hiibernate、JDO、iBATIS（持久化）、Spring（事務管理、安全）。┏━━━━━━━━━┳━━━━━━━━━━━━━━━┳━━━━━━━┓┃┃典型的EJB方法┃POJO方法┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━╋━━━━━━━┫┃組織┃過程式業(yè)務邏輯┃面向對象設計┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━╋━━━━━━━┫┃實現(xiàn)┃基于EJB┃POJO┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━┻━━━━━━━┫┃數(shù)據庫訪問┃JDBC/SQL或實體bean ┃持久層框架┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━┳━━━━━━━┫┃返回給表示層的數(shù)據┃DTO┃業(yè)務對象┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━╋━━━━━━━┫┃事務管理┃EJB容器管理的事務┃Spring框架┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━╋━━━━━━━┫┃應用程序組裝┃顯式的JNDI查詢┃依賴注入┃┗━━━━━━━━━┻━━━━━━━━━━━━━━━┻━━━━━━━┛59POJO（業(yè)務邏輯）+Hiibernate、JDO、i60新設計是面向對象、基于POJO,而非基于EJB的過程式。它使用構建在JDBC上的持久層框架來訪問數(shù)據庫,并不直接使用JDBC。業(yè)務邏輯由POJOfacade而非會話bean進行封裝。事務由Spring框架而非EJB容器進行管理。業(yè)務邏輯向表現(xiàn)層返回實際的業(yè)務對象,而不是DTO。應用程序通過將組件的依賴作為setter或構造子參數(shù)傳入來進行組裝,而不是之前采用Java命名和目錄接口(JNDI)查詢的組件。由于該設計面向對象,并采用上述輕量級技術,因此較之前看到的EJB版本對開發(fā)人員要友好。60新設計是面向對象、基于POJO,而非基于EJB的過程式61基于輕量級框架設計的好處是，它提供事務和持久化時并不要求應用程序類實現(xiàn)任何特殊接口。甚至當應用程序的類需要運行在事務里或是持久的時候，它們仍是POJO，設計者可以繼續(xù)享受POJO的種種好處。61基于輕量級框架設計的好處是，它提供事務和持久化時并不要求62面向對象的優(yōu)點：整個設計更易理解和維護。它并不是一個無所不能的大型類,而是由大量小類組成,每個類只共有若干職責。此外,諸如Account、BankingTransaction和OverdraftPolicy類都與現(xiàn)實世界的概念對應,因此易于理解。其次,面向對象設汁也更易測試:所有類都能并且應當進行獨立的測試。EJB只能通過調用它的public方法如Transter進行測試,難度大。(只能測試p-blic方法暴露的復雜功能,無法測試其中簡單的部分）。面向對象象設計更易擴展,它可使用設計模式，如Stategy和Template等。EJB風格的過程式設計往往需耍修改核心代碼。62面向對象的優(yōu)點：63不適合用面向對象的場合：大量數(shù)據集合的關系操作。以數(shù)據庫為中心的管理程序：這個領域所對應的現(xiàn)實世界是一個面向關系的世界，表與表的關聯(lián)體現(xiàn)的是彼此的業(yè)務關系。復雜的SQL固然不好維護，但業(yè)務真是復雜到簡單的SQL都難以描述的程度，采用面向對象描述則更加困難，維護也更困難，同時還損失了效率。比較大的事務。性能要求高的地方。（直接用Sql或者存儲過程；犧牲可維護性和可復用性）上層流程。63不適合用面向對象的場合：64面向對象設計的基本原則64面向對象設計的基本原則656566liskov替換原則（LSP）66liskov替換原則（LSP）67子類型必須能夠替換掉其基類型問題的根源是關于行為的：基類中有的行為在子類中不存在或不適當。ISA的本質是指行為的一致，而不是生活中的語言。違反了LSP原則的本質是派生類的行為與基類中的不一致。如果違反了LSP原則，常會導致在運行時的類型判斷(RTTI)違反OCP原則。例如：函數(shù)A的參數(shù)是基類型，調用時傳遞的對象是子類型，正常情況下，增加子類型都不會影響到函數(shù)A的，如果違反了LSP，則函數(shù)A必須小心的判斷傳進來的具體類型，否則就會出錯，這就已經違反了OCP原則。67子類型必須能夠替換掉其基類型問題的根源是關于行為的：68接口隔離原則（ISP）68接口隔離原則（ISP）69使用多個專門的接口比使用單一的總接口要好。一個類對另外一個類的依賴性應當是建立在最小的接口上的。一個接口代表一個角色，不應當將不同的角色都交給一個接口。沒有關系的接口合并在一起，形成一個臃腫的大接口，這是對角色和接口的污染?！安粦搹娖瓤蛻粢蕾囉谒鼈儾挥玫姆椒?。接口屬于客戶，不屬于它所在的類層次結構?！边@個說得很明白了，再通俗點說，不要強迫客戶使用它們不用的方法，如果強迫用戶使用它們不使用的方法，那么這些客戶就會面臨由于這些不使用的方法的改變所帶來的改變。69使用多個專門的接口比使用單一的總接口要好。70例比如說電子商務的系統(tǒng),有訂單這個類,有三個地方會使用到,一個是門戶,只能有查詢方法,一個是外部系統(tǒng),有添加訂單的方法,一個是管理后臺,添加刪除修改查詢都要用到.根據接口隔離原則(ISP),一個類對另外一個類的依賴性應當是建立在最小的接口上.也就是說,對于門戶,它只能依賴有一個查詢方法的接口.70例比如說電子商務的系統(tǒng),有訂單這個類,有三個地方會使用到71依賴倒置原則（DIP）71依賴倒置原則（DIP）72相關概念關于解耦依賴倒置（DIP）控制反轉（IoC）依賴注入（DI）服務定位器（SL）有些是手段，有些是原則，不過其間的差異并不太重要，更重要的是其共同點：其根本目標都是解除依賴，將組件的配置與使用分離開。其它名詞服務組件框架類庫應用程序72相關概念關于解耦73接口和實現(xiàn)分離

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

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

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

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

94借鑒RUP的UML建模與分析

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

留存

分布式處理

安全性

進程間通信

消息路由

進程控制與同步

交易事務管理

信息交換

信息的冗余

錯誤檢測、處理和報告

數(shù)據格式轉換96全局分析常見的分析機制

留存

分布式處理

安全性

進程間97局部分析提取分析類轉述需求場景整理分析類97局部分析提取分析類98局部分析分析類的類型劃分

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

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

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

分析類是這樣的類：它代表問題域中的103分析類的職責職責是類和它的客戶之間的契約或者是類對它的客戶的義務。本質上，職責是類提供給其他類的服務。分析類具有直接同類（由它的名稱所表達）的目的相一致的以及直接同該類正在建模的真實世界“事物”相一致的非常內聚的職責集合，這一點是至關重要的。例如ShoppingBasket示例，你將期望該類具有如下職責：向購物籃添加商品；從購物籃刪除商品；顯示購物籃中的商品。這是內聚的職責集合，一切都是為了維護客戶選擇的商品集合。它是內聚的，因為所有的職責都朝著相同的目標─維護客戶已經選擇的商品集合。實際上，我們能夠把這些職責概括為非常高級層次的職責“維護購物籃”。同樣，向ShoppingBasket中添加如下職責：103分析類的職責職責是類和它的客戶之間的契約或者是類對它的104分析類的職責驗證信用卡；接收付款；打印收據。但這些職責似乎同購物籃的目的或直覺語法不匹配。它們不是內聚的，顯然應該賦予其他什么類─可能是類CreditCardCompany、類Checkout以及類ReceiptPrinter。把職責適當?shù)胤峙浣o分析類以最大化每個類中的內聚性，是很重要的。最后，良好的類與其他類之間具有最低數(shù)目的耦合。我們以給定類與其他類具有關系的數(shù)目來度量類間的耦合度。類間職責的平均分布趨向于產生低耦合度。把控制或職責局限于單一的類趨向于增加到該類的耦合度。104分析類的職責驗證信用卡；105分析類經驗法則以下是創(chuàng)建形式良好的分析類的一些經驗法則。每個類大約3~5個職責─典型地，類應該保持盡可能簡單，這通常限制類能夠支持的3~5個職責的數(shù)目。先前ShoppingBasket的示例是帶有小的和可管理數(shù)目職責的專注的類的好的示例。不存在獨立的類─好的OO分析和設計的精華是，類相互協(xié)作讓用戶受益。同樣，每個類應該同小部分類協(xié)作以提供所期望的功能。類可以把它們的一些職責托付給專注于特定功能的其他“輔助”類。當心很多非常小的類─有時很難取得正確的平衡。如果模型看起來具有大量的非常小的類，每個類都具有一個或者兩個職責，那么你應該仔細查看以把一些小的類整合成更大的類。105分析類經驗法則以下是創(chuàng)建形式良好的分析類的一些經驗法則106當心少數(shù)幾個非常龐大的類─上述的反面是，模型具有很少的類，但每個類都是具有職責數(shù)量（>5）的龐大的類。解決問題的策略是依次查看這些類，看看是否每個類都能夠被分解成為兩個或者多個能夠承擔恰當數(shù)目職責的、更小的類。當心“偽類”─偽類其實是一般的過程函數(shù)，它偽裝成類。當心萬能類─存在似乎能夠承擔任何工作的類?？纯疵Q為“system”和“controller”的類！處理這個問題的策略是看看萬能類的職責是否能夠分解成內聚的子集。如果是，每個這些內聚職責集合可能獨立成類。這些更小的類協(xié)作以實現(xiàn)由原始萬能類所提供的行為。106當心少數(shù)幾個非常龐大的類─上述的反面是，模型具有很少的107分析類經驗法則避免深度繼承樹─設計良好的繼承層次的本質是繼承層次中每個抽象層次應該具有良好定義的目的。容易添加很多實際上不能服務于任何目的層次。實際上，通常的錯誤是使用繼承來實現(xiàn)一種功能分解，其中每個抽象層次恰有一個職責！無論從哪個方面來講，這都是無意義的，是會導致復雜的、難以理解的模型。在分析中，類代表業(yè)務事物，而業(yè)務事物趨向于形成更寬（不超過三層）的繼承層次。我們把三層或者更多層次的繼承認為是“深度”繼承。107分析類經驗法則避免深度繼承樹─設計良好的繼承層次的本質108第四單元：設計模式與軟件設計思想108第四單元：設計模式與軟件設計思想109設計模式在實際開發(fā)中的運用復用現(xiàn)有的、高質量的、針對常見的重復出現(xiàn)問題的解決方案。建立通用的術語以改善團隊內部的溝通。將思考轉移到更高的視角。判斷是否擁有正確的設計，而不僅僅使一個可以運行的設計。改善代碼的可修改性。發(fā)現(xiàn)“龐大的繼承體系”的替代方案。109設計模式在實際開發(fā)中的運用復用現(xiàn)有的、高質量的、針對常110GoF中的模式分類110GoF中的模式分類111設計模式的特點設計模式最根本的意圖是適應需求變化隔離變化的部分與不變的部分，將之封裝起來。針對接口編程，而不要針對實現(xiàn)編程達成高內聚合低耦合，提高復用提倡優(yōu)先使用聚合，而不是繼承111設計模式的特點設計模式最根本的意圖是適應需求變化112例一個日志記錄工具。目前需要提供一個日志API，提供客戶方便地調用。該日志要求被記錄到指定的文本文件中，記錄的內容屬于字符串類型，其值由客戶提供。可以容易地定義一個日志對象。publicclassLog{ publicvoidWrite(stringtarget,stringlog){ //實現(xiàn)內容;}}當客戶需要調用日志的功能時，可以創(chuàng)建日志對象，完成日志的記錄：Loglog=newLog();log.Write(“error.log”,“l(fā)og”);112例一個日志記錄工具。目前需要提供一個日志API，提供客113113114例我們需要設計一個數(shù)據庫組件，它能夠訪問SqlServer數(shù)據庫。如果用ADO.Net，需要使用如下的對象：SqlConnection,SqlCommand,SqlDataAdapter等。不用模式的做法：可以直接創(chuàng)建這些對象：SqlConnectionconnection=new SqlConnection(strConnection);SqlCommandcommand=newSqlCommand(connection);SqlDataAdapteradapter=newSqlDataAdapter();114例我們需要設計一個數(shù)據庫組件，它能夠訪問SqlSer115策略（Strategy）模式115策略（Strategy）模式116例：電子零售系統(tǒng)該電子零售系統(tǒng)必須處理來自不同國家的銷售定單。例如在美國與加拿大。需求如下：請況過程美國據UPS的價格計算運費使用美國郵政規(guī)則檢查地址根據銷售額或服務,按照當?shù)囟愂找?guī)則計算稅費金額使用美元處理款項加拿大根據主要的加拿大托運公司的價格計算運費使用加拿大郵政規(guī)則檢查地址根據銷售額或服務,按照加拿大各省的稅收規(guī)則計算稅費金額(GST和PST)使用加拿大元處理款項116例：電子零售系統(tǒng)該電子零售系統(tǒng)必須處理來自不同國家的銷117分析矩陣117分析矩陣118橋接（Bridge）模式118橋接（Bridge）模式119意圖“將抽象部分與它的實現(xiàn)部分分離，使它們都可以獨立地變化”。抽象部分是指“不同的事物在概念層次上的聯(lián)系”。分離是指“讓各部分的行為各自獨立，或至少顯式指出關聯(lián)”。119意圖120例通過引入一個Rectangle抽象類，利用了這一事實：不同的Rectangle派生類之間唯一的差異是如何實現(xiàn)drawLine方法。V1Rectangle類的實現(xiàn)方式是：保存一個DP1對象的引用，使用DP1對象的draw_a_line方法。V2Rectangle類的實現(xiàn)方法是：保存一個DP2對象的引用，使用這個對象的drawline方法。120例通過引入一個Rectangle121需求變化用戶要求支持另一種形狀——圓形。121需求變化用戶要求支持另一種形狀——圓形。122識別變化首先識別出“什么在發(fā)生變化”。在上述的例子中，變化點是“不同類型的形狀”和“不同類型的畫圖程序”。共同的“概念”則是“形狀”和“畫圖程序”。用Shape類來封裝擁有的形狀的概念。形狀有責任知道如何畫自己。Drawing對象負責畫線和圓。122識別變化首先識別出“什么在發(fā)生變化”。在上述的例子中，123描述變化下一步是描述出現(xiàn)的特定變化：Shape類擁有矩形和圓形。畫圖程序分別擁有一個基于DP1的對象（V1Drawing）和一個基于DP2的對象（V2Drawing）。123描述變化下一步是描述出現(xiàn)的特定變化：Shape類擁有矩124橋接模式124橋接模式125命令（command）模式125命令（command）模式126意圖將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進行參數(shù)化；對請求排隊或記錄請求日志，以及支持可撤消的操作。別名動作(Action)，事務(Transaction)動機有時必須向某對象提交請求，但并不知道關于被請求的操作或請求的接受者的任何信息。例如，用戶界面工具箱包括按鈕和菜單這樣的對象，它們執(zhí)行請求響應用戶輸入。但工具箱不能顯式的在按鈕或菜單中實現(xiàn)該請求，因為只有使用工具箱的應用知道該由哪個對象做哪個操作。而工具箱的設計者無法知道請求的接受者或執(zhí)行的操作。命令模式通過將請求本身變成一個對象來使工具箱對象可向未指定的應用對象提出請求。這個對象可被存儲并像其他的對象一樣被傳遞。這一模式的關鍵是一個抽象的Command類。126意圖127常用的軟件架構風格及適用情況分析軟件架構軟件框架常見的架構風格127常用的軟件架構風格及適用情況分析軟件架構128軟件架構概論系統(tǒng)架構是一個軟件系統(tǒng)從整體到部分的最高層次的劃分。一個系統(tǒng)通常是由元件組成的，而這些元件如何形成、相互之間如何發(fā)生作用，則是關于這個系統(tǒng)本身結構的重要信息。詳細地說，就是要包括架構元件（ArchitectureComponent）、聯(lián)結器（Connector）、任務流（Task-flow）。所謂架構元素，也就是組成系統(tǒng)的核心"磚瓦"，而聯(lián)結器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結果，任務流則描述系統(tǒng)如何使用這些元件和聯(lián)結器完成某一項需求。128軟件架構概論系統(tǒng)架構是一個軟件系統(tǒng)從整體到部分的最高層129建造一個系統(tǒng)所作出的最高層次的、以后難以更改的，商業(yè)的和技術的決定。在建造一個系統(tǒng)之前會有很多的重要決定需要事先作出，而一旦系統(tǒng)開始進行詳細設計甚至建造，這些決定就很難更改甚至無法更改。顯然，這樣的決定必定是有關系統(tǒng)設計成敗的最重要決定，必須經過慎重的研究和考察。129建造一個系統(tǒng)所作出的最高層次的、以后難以更改的，商業(yè)的130架構的目標可靠性（Reliable）：軟件系統(tǒng)對于用戶的商業(yè)經營和管理來說極為重要，因此軟件系統(tǒng)必須非?？煽?。安全性（Secure）：軟件系統(tǒng)所承擔的交易的商業(yè)價值極高，系統(tǒng)的安全性非常重要。可伸縮性（Scalable）：軟件必須能夠在用戶的使用率、用戶的數(shù)目增加很快的情況下，保持合理的性能。只有這樣，才能適應用戶的市場擴展得可能性。130架構的目標可靠性（Reliable）：131架構的目標可定制化（Customizable）：同樣的一套軟件，可以根據客戶群的不同和市場需求的變化進行調整?？蓴U展性（Extensible）：在新技術出現(xiàn)的時候，一個軟件系統(tǒng)應當允許導入新技術，從而對現(xiàn)有系統(tǒng)進行功能和性能的擴展可維護性（Maintainable）：軟件系統(tǒng)的維護包括兩方面，一是排除現(xiàn)有的錯誤，二是將新的軟件需求反映到現(xiàn)有系統(tǒng)中去。一個易于維護的系統(tǒng)可以有效地降低技術支持的花費。131架構的目標可定制化（Customizable）：132客戶體驗（CustomerExperience）：軟件系統(tǒng)必須易于使用。

市場時機（TimetoMarket）：軟件用戶要面臨同業(yè)競爭，軟件提供商也要面臨同業(yè)競爭。以最快的速度爭奪市場先機非常重要。132133架構的種類根據我們關注的角度不同，可以將架構分成三種：邏輯架構物理架構系統(tǒng)架構133架構的種類根據我們關注的角度不同，可以將架構分成三種：134邏輯架構軟件系統(tǒng)中元件之間的關系，比如用戶界面，數(shù)據庫，外部系統(tǒng)接口，商業(yè)邏輯元件等等。134邏輯架構軟件系統(tǒng)中元件之間的關系，比如用戶界面，數(shù)據庫135物理架構軟件元件是怎樣放到硬件上的下圖描述了一個分布于北京和上海的分布式系統(tǒng)的物理架構，圖中所有的元件都是物理設備，包括網絡分流器、代理服務器、WEB服務器、應用服務器、報表服務器、整合服務器、存儲服務器、主機等等。135物理架構軟件元件是怎樣放到硬件上的136系統(tǒng)架構系統(tǒng)的非功能性特征，如可擴展性、可靠性、強壯性、靈活性、性能等。系統(tǒng)架構的設計要求架構師具備軟件和硬件的功能和性能的過硬知識，這一工作是架構設計工作中最困難的工作。136系統(tǒng)架構系統(tǒng)的非功能性特征，如可擴展性、可靠性、強壯性137架構的兩要素元件劃分和設計決定。邏輯元件：一個軟件系統(tǒng)中的元件首先是邏輯元件。這些邏輯元件如何放到硬件上，以及這些元件如何為整個系統(tǒng)的可擴展性、可靠性、強壯性、靈活性、性能等做出貢獻，是非常重要的信息。設計決定：進行軟件設計需要做出的決定中，必然會包括邏輯結構、物理結構，以及它們如何影響到系統(tǒng)的所有非功能性特征。這些決定中會有很多是一旦作出，就很難更改的?；跀?shù)據庫的系統(tǒng)架構：一般有多少個數(shù)據表，就會有多少頁的架構設計文檔。比如一個中等的數(shù)據庫應用系統(tǒng)通常含有一百個左右的數(shù)據表，這樣的一個系統(tǒng)設計通常需要有一百頁左右的架構設計文檔。137架構的兩要素元件劃分和設計決定。138軟件框架什么是框架框架與架構的區(qū)別常見的框架138軟件框架什么是框架139框架什么是框架？框架，即framework。是某種應用的半成品，就是一組組件，供選用完成自己的系統(tǒng)。簡單說就是使用別人搭好的舞臺，你來做表演。而且，框架一般是成熟的，不斷升級的軟件。框架與架構的區(qū)別？并無明確的定義，但一般從層的觀點看，認為框架是底層的，接近系統(tǒng)的。軟件開發(fā)者在其上構建自己的軟件架構，開發(fā)自己的運用程序。139框架什么是框架？140為什么要用框架因為軟件系統(tǒng)發(fā)展到今天已經很復雜了，特別是服務器端軟件，設計到的知識，內容，問題太多。在某些方面使用成熟的框架，可以避免重復做已有的基礎工作，而只需要集中精力完成系統(tǒng)的業(yè)務邏輯設計?？蚣芤话闶浅墒?，穩(wěn)健的，可以處理系統(tǒng)很多細節(jié)問題，比如，事物理，安全性，數(shù)據流控制等問題?？蚣芤话愣冀涍^很多人使用，所以結構很好，所以擴展性也很好，而且它是不斷升級的，使用框架的開發(fā)者可以直接享受別人升級代碼帶來的好處。框架一般處在低層應用平臺（如J2EE）和高層業(yè)務邏輯之間的中間層。140為什么要用框架因為軟件系統(tǒng)發(fā)展到今天已經很復雜了，特別141常見的框架常見的JAVA框架常見的.Net框架其它基于C++的框架141常見的框架常見的JAVA框架142常見的JAVA框架EJBWAFStrutsTurbineCOCOONECHOJATOTCFSpringHibernateIBatisJSF142常見的JAVA框架EJB143.NET框架.NET框架是創(chuàng)建、部署和運行Web服務及其他應用程序的一個環(huán)境。它包括三個主要部分：公共語言運行時、框架類和ASP.NET。.NET框架對Web站點的支持：ASP.NET在編寫Windows軟件（使用ATL/COM、MFC、VB或標準Win32）方面，與當前創(chuàng)建應用程序的方式相比.NET都具有的優(yōu)勢。143.NET框架.NET框架是創(chuàng)建、部署和運行Web144C++框架ACEBOOSTMFCATLQTwxWidgets…144C++框架ACE145不同層次的模式架構模式(ArchitecturalPattern)設計模式(DesignPattern)代碼模式(CodingPattern)145不同層次的模式架構模式(ArchitecturalP146區(qū)別：在于三種不同的模式存在于它們各自的抽象層次和具體層次。架構模式是一個系統(tǒng)的高層次策略，涉及到大尺度的組件以及整體性質。架構模式的好壞可以影響到總體布局和框架性結構。設計模式是中等尺度的結構策略。這些中等尺度的結構實現(xiàn)了一些大尺度組件的行為和它們之間的關系。模式的好壞不會影響到系統(tǒng)的總體布局和總體框架。設計模式定義出子系統(tǒng)或組件的微觀結構。代碼模式是特定的范例和與特定語言有關的編程技巧。代碼模式的好壞會影響到一個中等尺度組件的內部、外部的結構或行為的底層細節(jié)，但不會影響到一個部件或子系統(tǒng)的中等尺度的結構，更不會影響到系統(tǒng)的總體布局和大尺度框架。146區(qū)別：在于三種不同的模式存在于它們各自的抽象層次和具體147幾種典型的架構模式系統(tǒng)軟件分層(Layer)管道和過濾器(PipesandFilters)黑板(Blackboard)開發(fā)分布式軟件經紀人(Broker)客戶/服務器（Client/Server）點對點（PeertoPeer）交互軟件模型-視圖-控制器（Model-View-Controller）顯示-抽象-控制（Presentation-Abstraction-COntrol）147幾種典型的架構模式系統(tǒng)軟件148其它面向對象風格(ADT)基于消息廣播且面向圖形用戶界面的Chiron2風格基于事件的隱式調用風格(Event-based,ImplicitInvocation)…148其它面向對象風格(ADT)149分層(Layer)從不同的層次來觀察系統(tǒng)，處理不同層次問題的對象被封裝到不同的層中。

軟件為什么要分層？

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