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

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

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

優(yōu)點：分層簡化符合OO缺點：service邏輯也強行放入DO，引發(fā)了DO不穩(wěn)定。DO暴露給web層過多信息，可能引發(fā)無須要耦合。第56頁56標準：業(yè)務對象封裝了內(nèi)在業(yè)務邏輯，而應用服務封裝了外在于業(yè)務對象業(yè)務邏輯。第57頁57EJB到輕量級框架EJBPOJO（業(yè)務邏輯）+輕量級框架（[Hibernate、JDO、iBATIS]（持久化）、Spring（事務管理、安全））第58頁58EJBEJB：編寫分布式業(yè)務應用程序Java標準架構。提供大量服務：申明型事務,EIB容器自動開啟、提交和回滾事務。業(yè)務邏輯能參加由遠程客戶發(fā)起分布式事務。提供申明型安全，大部分情況下不再搖要編寫安全代碼求（bean布署描述符里條目指定準能夠防問某個詳細bean）。第59頁59例：在兩個賬號間進行轉(zhuǎn)賬服務。第60頁60POJO（業(yè)務邏輯）+Hiibernate、JDO、iBATIS（持久化）、Spring（事務管理、安全）。┏━━━━━━━━━┳━━━━━━━━━━━━━━━┳━━━━━━━┓┃┃經(jīng)典EJB方法┃POJO方法┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━╋━━━━━━━┫┃組織┃過程式業(yè)務邏輯┃面向?qū)ο笤O計┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━╋━━━━━━━┫┃實現(xiàn)┃基于EJB┃POJO┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━┻━━━━━━━┫┃數(shù)據(jù)庫訪問┃JDBC/SQL或?qū)嶓wbean ┃持久層框架┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━┳━━━━━━━┫┃返回給表示層數(shù)據(jù)┃DTO┃業(yè)務對象┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━╋━━━━━━━┫┃事務管理┃EJB容器管理事務┃Spring框架┃┣━━━━━━━━━╋━━━━━━━━━━━━━━━╋━━━━━━━┫┃應用程序組裝┃顯式JNDI查詢┃依賴注入┃┗━━━━━━━━━┻━━━━━━━━━━━━━━━┻━━━━━━━┛第61頁61新設計是面向?qū)ο?、基于POJO,而非基于EJB過程式。它使用構建在JDBC上持久層框架來訪問數(shù)據(jù)庫,并不直接使用JDBC。業(yè)務邏輯由POJOfacade而非會話bean進行封裝。事務由Spring框架而非EJB容器進行管理。業(yè)務邏輯向表現(xiàn)層返回實際業(yè)務對象,而不是DTO。應用程序經(jīng)過將組件依賴作為setter或結構子參數(shù)傳入來進行組裝,而不是之前采取Java命名和目錄接口(JNDI)查詢組件。因為該設計面向?qū)ο?并采取上述輕量級技術,所以較之前看到EJB版本對開發(fā)人員要友好。第62頁62基于輕量級框架設計好處是，它提供事務和持久化時并不要求應用程序類實現(xiàn)任何特殊接口。甚至當應用程序類需要運行在事務里或是持久時候，它們?nèi)允荘OJO，設計者能夠繼續(xù)享受POJO種種好處。第63頁63第64頁64面向?qū)ο髢?yōu)點：整個設計更易了解和維護。它并不是一個無所不能大型類,而是由大量小類組成,每個類只共有若干職責。另外,諸如Account、BankingTransaction和OverdraftPolicy類都與現(xiàn)實世界概念對應,所以易于了解。其次,面向?qū)ο笤O汁也更易測試:全部類都能而且應該進行獨立測試。EJB只能經(jīng)過調(diào)用它public方法如Transter進行測試,難度大。(只能測試p-blic方法暴露復雜功效,無法測試其中簡單部分）。面向?qū)ο笙笤O計更易擴展,它可使用設計模式，如Stategy和Template等。EJB格調(diào)過程式設計往往需耍修改關鍵代碼。第65頁65不適適用面向?qū)ο髨鏊捍罅繑?shù)據(jù)集合關系操作。以數(shù)據(jù)庫為中心管理程序：這個領域所對應現(xiàn)實世界是一個面向關系世界，表與表關聯(lián)表達是彼此業(yè)務關系。復雜SQL當然不好維護，但業(yè)務真是復雜到簡單SQL都難以描述程度，采取面向?qū)ο竺枋鰟t愈加困難，維護也更困難，同時還損失了效率。比較大事務。性能要求高地方。（直接用Sql或者存放過程；犧牲可維護性和可復用性）上層流程。第66頁66消除DTO第67頁67布署POJO程序第68頁68第69頁69第70頁70面向?qū)ο笤O計基本標準第71頁71第72頁72liskov替換標準（LSP）第73頁73子類型必須能夠替換掉其基類型問題根源是關于行為：基類中有行為在子類中不存在或不適當。ISA本質(zhì)是指行為一致，而不是生活中語言。違反了LSP標準本質(zhì)是派生類行為與基類中不一致。假如違反了LSP標準，常會造成在運行時類型判斷(RTTI)違反OCP標準。比如：函數(shù)A參數(shù)是基類型，調(diào)用時傳遞對象是子類型，正常情況下，增加子類型都不會影響到函數(shù)A，假如違反了LSP，則函數(shù)A必須小心判斷傳進來詳細類型，不然就會犯錯，這就已經(jīng)違反了OCP標準。第74頁74違反LSP造成違反OCP簡單例子第75頁75改進第76頁76例：會議管理系統(tǒng)第77頁77例：GUI對象假定一個Component代表一個GUI對象，如按鈕或者文本框等。第78頁78第79頁79第80頁80改進2第81頁81例第82頁82接口隔離標準（ISP）康凱第83頁83例第84頁84使用委托分離接口第85頁85使用多重繼承分離接口第86頁86內(nèi)接口與外接口第87頁87普通接口與智能接口第88頁88軟件系統(tǒng)壞死癥狀第89頁89“Copy”程序一個從鍵盤讀入字符并輸出到打印機程序。voidCopy(){ intc; while((c=RdKbd())!=EOF) WrtPtr(c);}第90頁90需求在改變用戶希望Copy程序能從紙帶讀入機中讀入信息。現(xiàn)實中約束－－不能改變接口Copy程序第一次修改結果boolptFlag=false;//remembertoresetthisflagvoidCopy(){ intc; while((c=(ptFlag?Rdpt():Rdkbd()))!=EOF) WrtPtr(c);}第91頁91需求在改變2客戶希望Copy程序有時能夠輸出到紙帶穿孔機上。//Copy程序第二次修改結果boolptFlag=false;boolpunchFlag=false;//remembertoresettheseflagvoidCopy(){ intc; while((c=(ptFlag?Rdpt():Rdkbd()))!=EOF) punchFlag?WrtPunch(c):WrtPtr(c);}第92頁92依賴倒置標準（DIP）康凱第93頁93相關概念關于解耦依賴倒置（DIP）控制反轉(zhuǎn)（IoC）依賴注入（DI）服務定位器（SL）有些是伎倆，有些是標準，不過其間差異并不太主要，更主要是其共同點：其根本目標都是解除依賴，將組件配置與使用分離開。其它名詞服務組件框架類庫應用程序第94頁94接口和實現(xiàn)分離

面向過程接口與實現(xiàn)分離第95頁95第96頁96第97頁97第98頁98電影清單例子一個組件，用于提供一份電影清單，清單上列出影片都是由一位特定導演執(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()]);}}第99頁99其中真正想要考查是怎樣將MovieLister對象與特定finder對象連接起來。要求：我們希望moviesDirectedBy方法完全不依賴于影片實際存放方式。這個方法只能引用一個finder對象，而finder對象必須知道怎樣實現(xiàn)findAll細節(jié)。給finder定義一個接口：publicinterfaceMovieFinder {ListfindAll();}當要實際尋找影片時，就必須包括到MovieFinder某個詳細子類。在這里，我把“包括詳細子類”代碼放在MovieLister類結構函數(shù)中。第100頁100反抗改變從一個逗號分隔文本文件中取得影片列表。classMovieLister...privateMovieFinderfinder;publicMovieLister(){finder=newColonDelimitedMovieFinder("movies1.txt");}反抗改變：文件清單名字更改：能夠從一個配置文件取得文件名。假如用SQL數(shù)據(jù)庫、XML文件、webservice，或者另一個格式文本文件來存放影片清單：用另一個詳細類來獲取數(shù)據(jù)。該類從MovieFinder接口派生即可。創(chuàng)建適當MovieFinder派生類實例：不能反抗此改變。第101頁101配置文件設定配置文件：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>第102頁102第三單元：用UML輔助系統(tǒng)分析與設計第103頁103UML介紹及常見疑難問題辨析

第104頁104UML用來描述模型內(nèi)容有3種,分別是事物(Things)、關系Relationships)和圖(Diagrams)。第105頁105UML中關系UML中關系(Relationships)主要包含4種:1、關聯(lián)關系2、依賴(Dependency)關系3、泛化(Generalization)關系4、實現(xiàn)(Realization)關系第106頁106一些常見問題辨析類層次結構表示屬性與聚合關聯(lián)角色關聯(lián)類第107頁107層次結構第108頁108領域建模－重數(shù)第109頁109細化類模型第110頁110關聯(lián)角色關聯(lián)角色名出現(xiàn)在關聯(lián)終端旁邊。當僅僅使用關聯(lián)名不足夠表示清楚后，能夠用關聯(lián)角色名來加強表示。能夠把每個名稱都當成偽屬性，關聯(lián)角色名提供了一個能夠遍歷關聯(lián)方法。第111頁111

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

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

留存

分布式處理

安全性

進程間通信

消息路由

進程控制與同時

交易事務管理

信息交換

信息冗余

錯誤檢測、處理和匯報

數(shù)據(jù)格式轉(zhuǎn)換第119頁119局部分析提取分析類轉(zhuǎn)述需求場景整理分析類第120頁120局部分析分析類類型劃分

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

分析類是這么類：它代表問題域中簡練抽象；分析類映射到真實世界業(yè)務概念（而且據(jù)此仔細命名）。問題域是首先產(chǎn)生軟件系統(tǒng)（以及從此而來軟件開發(fā)活動）需求域。通常，這是特定業(yè)務領域，如在線銷售或者客戶關系管理。然而，務必注意，問題域可能根本不是任何特定業(yè)務活動，但是可能產(chǎn)生需要軟件在其上運轉(zhuǎn)一塊物理硬件─這是嵌入式系統(tǒng)。基本上，全部業(yè)務軟件開發(fā)服務于某種業(yè)務需求，自動化一個已經(jīng)有業(yè)務過程或者開發(fā)含有有意義軟件組件新產(chǎn)品。第125頁125分析類職責職責是類和它客戶之間契約或者是類對它客戶義務。本質(zhì)上，職責是類提供給其它類服務。分析類含有直接同類（由它名稱所表示）目標相一致以及直接同該類正在建模真實世界“事物”相一致非常內(nèi)聚職責集合，這一點是至關主要。比如ShoppingBasket示例，你將期望該類含有以下職責：向購物籃添加商品；從購物籃刪除商品；顯示購物籃中商品。這是內(nèi)聚職責集合，一切都是為了維護客戶選擇商品集合。它是內(nèi)聚，因為全部職責都朝著相同目標─維護客戶已經(jīng)選擇商品集合。實際上，我們能夠把這些職責概括為非常高級層次職責“維護購物籃”。一樣，向ShoppingBasket中添加以下職責：第126頁126分析類職責驗證信用卡；接收付款；打印收據(jù)。但這些職責似乎同購物籃目標或直覺語法不匹配。它們不是內(nèi)聚，顯然應該賦予其它什么類─可能是類CreditCardCompany、類Checkout以及類ReceiptPrinter。把職責適當?shù)胤峙浣o分析類以最大化每個類中內(nèi)聚性，是很主要。最終，良好類與其它類之間含有最低數(shù)目標耦合。我們以給定類與其它類具相關系數(shù)目來度量類間耦合度。類間職責平均分布趨向于產(chǎn)生低耦合度。把控制或職責局限于單一類趨向于增加到該類耦合度。第127頁127分析類經(jīng)驗法則以下是創(chuàng)建形式良好分析類一些經(jīng)驗法則。每個類大約3~5個職責─經(jīng)典地，類應該保持盡可能簡單，這通常限制類能夠支持3~5個職責數(shù)目。先前ShoppingBasket示例是帶有小和可管理數(shù)目職責專注類好示例。不存在獨立類─好OO分析和設計精華是，類相互協(xié)作讓用戶受益。一樣，每個類應該同小部分類協(xié)作以提供所期望功效。類能夠把它們一些職責托付給專注于特定功效其它“輔助”類。當心很多非常小類─有時極難取得正確平衡。假如模型看起來含有大量非常小類，每個類都含有一個或者兩個職責，那么你應該仔細查看以把一些小類整合成更大類。第128頁128當心少數(shù)幾個非常龐大類─上述反面是，模型含有極少類，但每個類都是含有職責數(shù)量（>5）龐大類。處理問題策略是依次查看這些類，看看是否每個類都能夠被分解成為兩個或者多個能夠負擔恰當數(shù)目職責、更小類。當心“偽類”─偽類其實是普通過程函數(shù)，它偽裝成類。當心萬能類─存在似乎能夠負擔任何工作類。看看名稱為“system”和“controller”類！處理這個問題策略是看看萬能類職責是否能夠分解成內(nèi)聚子集。假如是，每個這些內(nèi)聚職責集合可能獨立成類。這些更小類協(xié)作以實現(xiàn)由原始萬能類所提供行為。第129頁129分析類經(jīng)驗法則防止深度繼承樹─設計良好繼承層次本質(zhì)是繼承層次中每個抽象層次應該含有良好定義目標。輕易添加很多實際上不能服務于任何目標層次。實際上，通常錯誤是使用繼承來實現(xiàn)一個功效分解，其中每個抽象層次恰有一個職責！不論從哪個方面來講，這都是無意義，是會造成復雜、難以了解模型。在分析中，類代表業(yè)務事物，而業(yè)務事物趨向于形成更寬（不超出三層）繼承層次。我們把三層或者更多層次繼認可為是“深度”繼承。第130頁130第四單元：設計模式與軟件設計思想第131頁131設計模式第132頁132設計模式在實際開發(fā)中利用復用現(xiàn)有、高質(zhì)量、針對常見重復出現(xiàn)問題處理方案。建立通用術語以改進團體內(nèi)部溝通。將思索轉(zhuǎn)移到更高視角。判斷是否擁有正確設計，而不但僅使一個能夠運行設計。改進代碼可修改性。發(fā)覺“龐大繼承體系”替換方案。第133頁133GoF中模式分類第134頁134設計模式特點設計模式最根本意圖是適應需求改變隔離改變部分與不變部分，將之封裝起來。針對接口編程，而不要針對實現(xiàn)編程達成高內(nèi)聚合低耦合，提升復用提倡優(yōu)先使用聚合，而不是繼承第135頁135例一個日志統(tǒng)計工具。當前需要提供一個日志API，提供客戶方便地調(diào)用。該日志要求被統(tǒng)計到指定文本文件中，統(tǒng)計內(nèi)容屬于字符串類型，其值由客戶提供。能夠輕易地定義一個日志對象。publicclassLog{ publicvoidWrite(stringtarget,stringlog){ //實現(xiàn)內(nèi)容;}}當客戶需要調(diào)用日志功效時，能夠創(chuàng)建日志對象，完成日志統(tǒng)計：Loglog=newLog();log.Write(“error.log”,“l(fā)og”);第136頁136第137頁137第138頁138例我們需要設計一個數(shù)據(jù)庫組件，它能夠訪問SqlServer數(shù)據(jù)庫。假如用ADO.Net，需要使用以下對象：SqlConnection,SqlCommand,SqlDataAdapter等。不用模式做法：能夠直接創(chuàng)建這些對象：SqlConnectionconnection=new SqlConnection(strConnection);SqlCommandcommand=newSqlCommand(connection);SqlDataAdapteradapter=newSqlDataAdapter();第139頁139Connection對象：第140頁140第141頁141策略（Strategy）模式第142頁142練習下面是一堆雜亂類與接口：

動作冒險游戲。包含代表游戲角色類，以及武器行為類。每個角色一次只能使用一個武器，不過能夠在游戲過程中換武器。任務：1.安排類。2.找出一個抽象類、一個接口、以及八個類。3.在類之間畫箭頭。A.繼承。B.實現(xiàn)接口。C.「有一個」關系。4.把setWeapon()方法放到正確類中。第143頁143原始類與接口第144頁144例：電子零售系統(tǒng)該電子零售系統(tǒng)必須處理來自不一樣國家銷售定單。比如在美國與加拿大。需求以下：請況過程美國據(jù)UPS價格計算運費使用美國郵政規(guī)則檢驗地址依據(jù)銷售額或服務,按照當?shù)囟愂找?guī)則計算稅費金額使用美元處理款項加拿大依據(jù)主要加拿大托運企業(yè)價格計算運費使用加拿大郵政規(guī)則檢驗地址依據(jù)銷售額或服務,按照加拿大各省稅收規(guī)則計算稅費金額(GST和PST)使用加拿大元處理款項第145頁145分析矩陣第146頁146橋接（Bridge）模式第147頁147意圖“將抽象部分與它實現(xiàn)部分分離，使它們都能夠獨立地改變”。抽象部分是指“不一樣事物在概念層次上聯(lián)絡”。分離是指“讓各部分行為各自獨立，或最少顯式指出關聯(lián)”。第148頁148例經(jīng)過引入一個Rectangle抽象類，利用了這一事實：不一樣Rectangle派生類之間唯一差異是如何實現(xiàn)drawLine方法。V1Rectangle類實現(xiàn)方式是：保留一個DP1對象引用，使用DP1對象draw_a_line方法。V2Rectangle類實現(xiàn)方法是：保留一個DP2對象引用，使用這個對象drawline方法。第149頁149需求改變用戶要求支持另一個形狀——圓形。第150頁150識別改變首先識別出“什么在發(fā)生改變”。在上述例子中，改變點是“不一樣類型形狀”和“不一樣類型畫圖程序”。共同“概念”則是“形狀”和“畫圖程序”。用Shape類來封裝擁有形狀概念。形狀有責任知道怎樣畫自己。Drawing對象負責畫線和圓。第151頁151描述改變下一步是描述出現(xiàn)特定改變：Shape類擁有矩形和圓形。畫圖程序分別擁有一個基于DP1對象（V1Drawing）和一個基于DP2對象（V2Drawing）。第152頁152橋接模式第153頁153觀察者（observer）模式康凱第154頁154第155頁155命令（command）模式康凱第156頁156意圖將一個請求封裝為一個對象，從而使你可用不一樣請求對客戶進行參數(shù)化；對請求排隊或統(tǒng)計請求日志，以及支持可撤消操作。別名動作(Action)，事務(Transaction)動機有時必須向某對象提交請求，但并不知道關于被請求操作或請求接收者任何信息。比如，用戶界面工具箱包含按鈕和菜單這么對象，它們執(zhí)行請求響應用戶輸入。但工具箱不能顯式在按鈕或菜單中實現(xiàn)該請求，因為只有使用工具箱應用知道該由哪個對象做哪個操作。而工具箱設計者無法知道請求接收者或執(zhí)行操作。命令模式經(jīng)過將請求本身變成一個對象來使工具箱對象可向未指定應用對象提出請求。這個對象可被存放并像其它對象一樣被傳遞。這一模式關鍵是一個抽象Command類。第157頁157例子第158頁158結構第159頁159其它設計模式第160頁160VISITOR模式該系列中模式以下:VISlTOR模式ACYCLICVISITOR模式DECORATOR模式EXTENSIONOBJECT模式第161頁161例是一個常見問題：比如,有一個Modem對象層次結構?；愔杏腥空{(diào)制解調(diào)器公共方法。派生類代表不一樣調(diào)制解調(diào)器類型驅(qū)動程序。第162頁162問題假設需要向該層次結構中增加一個新方法confrgureForUnix。使之可在UNIX下工作。在每個調(diào)制解調(diào)器派生類中該函數(shù)實現(xiàn)都不相同。（假設每個不一樣調(diào)制解調(diào)器在UNIX中都有自己獨特配置方法和行為特征）。問題：直接增加configureForUnix方法其實回避了一個問題：對于Windows怎樣處理?MacOS?Linux?必須針對所使用每一個新操作系統(tǒng)都要向Modem層次結構中增加一個新方法?這種做法是丑陋：我們永遠無法封閉Modem接口。每當出現(xiàn)一個新操作系統(tǒng)時,就必須更改該接口并重新布署全部調(diào)制解調(diào)器軟件。第163頁163VISITOR模式結構第164頁164VISITOR＋組合模式VISTTOR模式一個非經(jīng)常見應用是,遍歷大量數(shù)據(jù)結構并產(chǎn)生報表。這使得數(shù)據(jù)結構對象中不含有任何產(chǎn)生報表代碼。假如想增加新報表,只需增加新訪問者,而不需要更改數(shù)據(jù)結構中代碼。這意味著報表能夠被放置在不一樣組件中,而且僅被那些需要它們客戶單獨使用。第165頁165例：報表生成器一個表示材料單簡單數(shù)據(jù)結構。從該數(shù)據(jù)結構能夠生成無數(shù)報表。兩個能夠統(tǒng)計量：成本；數(shù)量比如能夠生成一張一個組合件總成本報表,或者生成一張列出了一個組合件中全部零件報表。第166頁166VlSITOR模式處理方法第167頁167其它模式問題：考慮前面Modem層次結構。假設有一個含有很多使用者應用程序。每個使用者都能夠坐在他計算機前,要求系統(tǒng)使用該計算機調(diào)制解調(diào)器呼叫另一臺計算機。有些用戶希望聽到撥號聲,有些用戶則希望他們調(diào)制解調(diào)器保持平靜。第168頁168DECORATOR模式DECORATOR模式經(jīng)過創(chuàng)建一個名為LoudDialModem全新類來處理這個問題。LoudDialModem派生自Modem,而且委托給一個它包含Modem實例。它捕捉對dial函數(shù)調(diào)用并在委托前把音量設高。第169頁169多個Decorator有時,在同一個類層次結構中可能存在兩個或者更多裝飾器（decorator）。比如,可能希望用LogoutExitModem來裝飾Modem層次結構,當Hangup被調(diào)用時,它會發(fā)送字符串"exit"。這個裝飾器必須要重復已經(jīng)在LoudDialModem中編寫過全部委托代碼。第170頁170第171頁171慣用軟件架構格調(diào)及適用情況分析康凱第172頁172軟件架構軟件框架常見架構格調(diào)第173頁173軟件架構概論系統(tǒng)架構是一個軟件系統(tǒng)從整體到部分最高層次劃分。一個系統(tǒng)通常是由元件組成，而這些元件怎樣形成、相互之間怎樣發(fā)生作用，則是關于這個系統(tǒng)本身結構主要信息。詳細地說，就是要包含架構元件（ArchitectureComponent）、聯(lián)結器（Connector）、任務流（Task-flow）。所謂架構元素，也就是組成系統(tǒng)關鍵"磚瓦"，而聯(lián)結器則描述這些元件之間通訊路徑、通訊機制、通訊預期結果，任務流則描述系統(tǒng)怎樣使用這些元件和聯(lián)結器完成某一項需求。第174頁174建造一個系統(tǒng)所作出最高層次、以后難以更改，商業(yè)和技術決定。在建造一個系統(tǒng)之前會有很多主要決定需要事先作出，而一旦系統(tǒng)開始進行詳細設計甚至建造，這些決定就極難更改甚至無法更改。顯然，這么決定必定是相關系統(tǒng)設計成敗最主要決定，必須經(jīng)過慎重研究和考查。第175頁175架構目標可靠性（Reliable）：軟件系統(tǒng)對于用戶商業(yè)經(jīng)營和管理來說極為主要，所以軟件系統(tǒng)必須非?？煽?。安全性（Secure）：軟件系統(tǒng)所負擔交易商業(yè)價值極高，系統(tǒng)安全性非常主要?？缮炜s性（Scalable）：軟件必須能夠在用戶使用率、用戶數(shù)目增加很快情況下，保持合理性能。只有這么，才能適應用戶市場擴展得可能性。第176頁176架構目標可定制化（Customizable）：一樣一套軟件，能夠依據(jù)客戶群不一樣和市場需求改變進行調(diào)整?？蓴U展性（Extensible）：在新技術出現(xiàn)時候，一個軟件系統(tǒng)應該允許導入新技術，從而對現(xiàn)有系統(tǒng)進行功效和性能擴展可維護性（Maintainable）：軟件系統(tǒng)維護包含兩方面，一是排除現(xiàn)有錯誤，二是將新軟件需求反應到現(xiàn)有系統(tǒng)中去。一個易于維護系統(tǒng)能夠有效地降低技術支持花費。第177頁177客戶體驗（CustomerExperience）：軟件系統(tǒng)必須易于使用。

市場時機（TimetoMarket）：軟件用戶要面臨同業(yè)競爭，軟件提供商也要面臨同業(yè)競爭。以最快速度爭奪市場先機非常主要。第178頁178架構種類依據(jù)我們關注角度不一樣，能夠?qū)⒓軜嫹殖扇N：邏輯架構物理架構系統(tǒng)架構第179頁179邏輯架構軟件系統(tǒng)中元件之間關系，比如用戶界面，數(shù)據(jù)庫，外部系統(tǒng)接口，商業(yè)邏輯元件等等。第180頁180物理架構軟件元件是怎樣放到硬件上下列圖描述了一個分布于北京和上海分布式系統(tǒng)物理架構，圖中全部元件都是物理設備，包含網(wǎng)絡分流器、代理服務器、WEB服務器、應用服務器、報表服務器、整合服務器、存放服務器、主機等等。第181頁181系統(tǒng)架構系統(tǒng)非功效性特征，如可擴展性、可靠性、強壯性、靈活性、性能等。系統(tǒng)架構設計要求架構師具備軟件和硬件功效和性能過硬知識，這一工作是架構設計工作中最困難工作。第182頁182架構兩要素元件劃分和設計決定。邏輯元件：一個軟件系統(tǒng)中元件首先是邏輯元件。這些邏輯元件怎樣放到硬件上，以及這些元件怎樣為整個系統(tǒng)可擴展性、可靠性、強壯性、靈活性、性能等做出貢獻，是非常主要信息。設計決定：進行軟件設計需要做出決定中，必定會包含邏輯結構、物理結構，以及它們怎樣影響到系統(tǒng)全部非功效性特征。這些決定中會有很多是一旦作出，就極難更改?；跀?shù)據(jù)庫系統(tǒng)架構：普通有多少個數(shù)據(jù)表，就會有多少頁架構設計文檔。比如一個中等數(shù)據(jù)庫應用系統(tǒng)通常含有一百個左右數(shù)據(jù)表，這么一個系統(tǒng)設計通常需要有一百頁左右架構設計文檔。第183頁183軟件框架什么是框架框架與架構區(qū)分常見框架第184頁184框架什么是框架？框架，即framework。是某種應用半成品，就是一組組件，供選取完成自己系統(tǒng)。簡單說就是使用他人搭好舞臺，你來做演出。而且，框架普通是成熟，不停升級軟件?？蚣芘c架構區(qū)分？并無明確定義，但普通從層觀點看，認為框架是底層，靠近系統(tǒng)。軟件開發(fā)者在其上構建自己軟件架構，開發(fā)自己利用程序。第185頁185為何要用框架因為軟件系統(tǒng)發(fā)展到今天已經(jīng)很復雜了，尤其是服務器端軟件，設計到知識，內(nèi)容，問題太多。在一些方面使用成熟框架，能夠防止重復做已經(jīng)有基礎工作，而只需要集中精力完成系統(tǒng)業(yè)務邏輯設計?？蚣芷胀ㄊ浅墒?，穩(wěn)健，能夠處理系統(tǒng)很多細節(jié)問題，比如，事物理，安全性，數(shù)據(jù)流控制等問題。框架普通都經(jīng)過很多人使用，所以結構很好，所以擴展性也很好，而且它是不停升級，使用框架開發(fā)者能夠直接享受他人升級代碼帶來好處?？蚣芷胀ㄌ幱诘蛯討闷脚_（如J2EE）和高層業(yè)務邏輯之間中間層。第186頁186常見框架常見JAVA框架常見.Net框架其它基于C++框架第187頁187常見JAVA框架EJBWAFStrutsTurbineCOCOONECHOJATOTCFSpringHibernateIBatisJSF第188頁188.NET框架.NET框架是創(chuàng)建、布署和運行Web服務及其它應用程序一個環(huán)境。它包含三個主要部分：公共語言運行時、框架類和ASP.NET。.NET框架對Web站點支持：ASP.NET在編寫Windows軟件（使用ATL/COM、MFC、VB或標準Win32）方面，與當前創(chuàng)建應用程序方式相比.NET都含有優(yōu)勢。第189頁189C++框架ACEBOOSTMFCATLQTwxWidgets…第190頁190不一樣層次模式架構模式(ArchitecturalPattern)設計模式(DesignPattern)代碼模式(CodingPattern)第191頁191區(qū)分：在于三種不一樣模式存在于它們各自抽象層次和詳細層次。架構模式是一個系統(tǒng)高層次策略，包括到大尺度組件以及整體性質(zhì)。架構模式好壞能夠影響到總體布局和框架性結構。設計模式是中等尺度結構策略。這些中等尺度結構實現(xiàn)了一些大尺度組件行為和它們之間關系。模式好壞不會影響到系統(tǒng)總體布局和總體框架。設計模式定義出子系統(tǒng)或組件微觀結構。代碼模式是特定范例和與特定語言相關編程技巧。代碼模式好壞會影響到一個中等尺度組件內(nèi)部、外部結構或行為底層細節(jié)，但不會影響到一個部件或子系統(tǒng)中等尺度結構，更不會影響到系統(tǒng)總體布局和大尺度框架。第192頁192幾個經(jīng)典架構模式系統(tǒng)軟件分層(Layer)管道和過濾器(PipesandFilters)黑板(Blackboard)開發(fā)分布式軟件經(jīng)紀人(Broker)客戶/服務器（Client/Server）點對點（PeertoPeer）交互軟件模型-視圖-控制器（Model-View-Controller）顯示-抽象-控制（Presentation-Abstraction-COntrol）第193頁193其它面向?qū)ο蟾裾{(diào)(ADT)基于消息廣播且面向圖形用戶界面Chiron2格調(diào)基于事件隱式調(diào)用格調(diào)(Event-based,ImplicitInvocation)…第194頁194分層(Layer)從不一樣層次來觀察系統(tǒng)，處理不一樣層次問題對象被封裝到不一樣層中。

軟件為何要分層？

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