軟件架構(gòu)設(shè)計模式與實踐

軟件架構(gòu)設(shè)計模式與實踐第一頁，共四百八十九頁，2022年，8月28日目錄軟件架構(gòu)視圖軟件生命周期與軟件架構(gòu)介紹架構(gòu)設(shè)計的GRASP模式質(zhì)量屬性驅(qū)動架構(gòu)設(shè)計策略軟件架構(gòu)模式分析及其實際運用架構(gòu)設(shè)計原則面向?qū)ο蟮脑O(shè)計原則架構(gòu)設(shè)計驗證數(shù)據(jù)訪問層設(shè)計（持久層設(shè)計）借鑒RUP中的設(shè)計流程領(lǐng)域模型及業(yè)務(wù)邏輯層在架構(gòu)設(shè)計中的實現(xiàn)設(shè)計模式本質(zhì)SOA的設(shè)計思想軟件架構(gòu)實踐軟件系統(tǒng)架構(gòu)實踐與剖析第二頁，共四百八十九頁，2022年，8月28日前言第三頁，共四百八十九頁，2022年，8月28日軟件系統(tǒng)開始壞死的癥狀一個軟件系統(tǒng)開始壞死時表現(xiàn)的癥狀有:硬化Rigidity——系統(tǒng)變得越來越難以變更,修復(fù)或增添新功能的代價高昂;脆弱Fragility——對系統(tǒng)的任何哪怕是微小的變更都可能造成四處(甚至是與變更處沒有邏輯上的關(guān)聯(lián)之處J崩潰;綁死Immobility——抽取系統(tǒng)的任何部分用來復(fù)用都非常困難;膠著Viscosity——以與原有設(shè)計保持一致的方式來對實施變更已經(jīng)非常困難,誘使開發(fā)人員繞過它選擇容易但有害的途徑,其結(jié)果卻使系統(tǒng)死的更快。第四頁，共四百八十九頁，2022年，8月28日

什么是軟件架構(gòu)軟件架構(gòu)的概念很混亂。如果你問五個不同的人，可能會得到五種不同的答案。軟件架構(gòu)概念主要分為兩大流派：組成派：軟件架構(gòu)=組件+交互。決策派：軟件架構(gòu)=重要決策集。組成派和決策派的概念相輔相成。第五頁，共四百八十九頁，2022年，8月28日軟件架構(gòu)要層次化并隔離關(guān)注點復(fù)雜性是層次化的。--《人月神話》

好的架構(gòu)設(shè)計必須把變化點錯落有致地封裝到軟件系統(tǒng)的不同部分(即關(guān)注點分離)。通過關(guān)注點分離，達(dá)到“系統(tǒng)中的一部分發(fā)生了變化，不會影響其他部分”的目標(biāo)。第六頁，共四百八十九頁，2022年，8月28日軟件單元的粒度：粒度最小的單元通常是“類”。幾個類緊密協(xié)作形成“模塊”。完成相對獨立的功能的多個模塊構(gòu)成了“子系統(tǒng)”。多個子系統(tǒng)相互配合才能滿足一個完整應(yīng)用的需求，從而構(gòu)成了軟件“系統(tǒng)”。一個大型企業(yè)往往使用多套系統(tǒng)，多套系統(tǒng)通過互操作形成“集成系統(tǒng)”。軟件單元的粒度是相對的。同一個軟件單元，在不同場景下我們會以不同的粒度看待它。第七頁，共四百八十九頁，2022年，8月28日架構(gòu)(Architecture)與框架(Framework)?？蚣苤皇且环N特殊的軟件，框架也有架構(gòu)?？梢酝ㄟ^架構(gòu)框架化達(dá)到“架構(gòu)重用”的目的，如很多人都在用Spring框架提供的控制反轉(zhuǎn)和依賴注入來構(gòu)建自己的架構(gòu)。第八頁，共四百八十九頁，2022年，8月28日軟件架構(gòu)的作用如果一個項目的系統(tǒng)架構(gòu)(包括理論基礎(chǔ))尚未確定，就不應(yīng)該進行此系統(tǒng)的全面開發(fā)。--BarryBoehm,《EngineeringContext》一個缺陷充斥的系統(tǒng)，將始終是一個缺陷充斥的系統(tǒng)。--TimothyC.Lethbridge,《面向?qū)ο筌浖こ獭奋浖軜?gòu)設(shè)計為什么這么難？因為它是跨越現(xiàn)實世界與計算機世界之間鴻溝的一座橋。軟件架構(gòu)設(shè)計要完成從面向業(yè)務(wù)到面向技術(shù)的轉(zhuǎn)換，在鴻溝上架起一座橋梁。需求->架構(gòu)設(shè)計->軟件架構(gòu)->系統(tǒng)開發(fā)->軟件系統(tǒng)第九頁，共四百八十九頁，2022年，8月28日軟件架構(gòu)對新產(chǎn)品開發(fā)的作用：上承業(yè)務(wù)目標(biāo)。下接技術(shù)決策?？刂茝?fù)雜性。先進行架構(gòu)設(shè)計，后進行詳細(xì)設(shè)計和編碼實現(xiàn)，符合“基于問題深度分而治之”的理念。組織開發(fā)。軟件架構(gòu)方案在小組中間扮演了“橋梁”和“合作契約”的作用。利于迭代開發(fā)和增量交付。以架構(gòu)為中心進行開發(fā)，為增量交付提供了良好的基礎(chǔ)。在架構(gòu)經(jīng)過驗證之后，可以專注于功能的增量提交。提高質(zhì)量。

第十頁，共四百八十九頁，2022年，8月28日軟件產(chǎn)品線：指具有一組可管理的、公共特性的、軟件密集性系統(tǒng)的集合，這些系統(tǒng)滿足特定的市場需求或任務(wù)需求，并且按照預(yù)定義方式從一個公共的核心資產(chǎn)集開發(fā)得到。軟件產(chǎn)品線架構(gòu)：針對一個公司或組織內(nèi)的一系列產(chǎn)品而設(shè)計的通用架構(gòu)。軟件架構(gòu)對軟件產(chǎn)品線開發(fā)的作用：固化核心知識；提供可重用資產(chǎn)；縮短推出產(chǎn)品的周期；降低開發(fā)和維護成本；提高產(chǎn)品質(zhì)量；支持批量定制；第十一頁，共四百八十九頁，2022年，8月28日架構(gòu)師應(yīng)當(dāng)為項目相關(guān)的不同角色而設(shè)計：架構(gòu)師要為客戶負(fù)責(zé)，滿足他們的業(yè)務(wù)目標(biāo)和約束條件。架構(gòu)師要為用戶負(fù)責(zé)，滿足他們關(guān)心的功能需求和運行期質(zhì)量屬性。架構(gòu)師必須顧及處于協(xié)作分工“下游”的開發(fā)人員。架構(gòu)師必須考慮“周邊”的管理人員，為他們進行分工管理、協(xié)調(diào)控制和評估監(jiān)控等工作提供清晰的基礎(chǔ)。第十二頁，共四百八十九頁，2022年，8月28日軟件架構(gòu)視圖——讓設(shè)計建模更明白、更有效張云貴2010-05-21第十三頁，共四百八十九頁，2022年，8月28日“系統(tǒng)架構(gòu)圖”？第十四頁，共四百八十九頁，2022年，8月28日架構(gòu)設(shè)計的多重視圖從根本上來說是因為需求種類的復(fù)雜性所致。比如一個媒體發(fā)布系統(tǒng)：功能需求：用戶可以通過瀏覽器瀏覽媒體的發(fā)布。據(jù)此初步設(shè)計出采用瀏覽器插件的方案；約束條件：不能影響用戶瀏覽器的安全性；細(xì)化設(shè)計方案，需要對插件進行認(rèn)證，自動判別客戶端是否存在，及版本比較；自動下載注冊等。使用期質(zhì)量屬性：為保證瀏覽的流暢，應(yīng)減少中間等待的時間，因此應(yīng)對下一步需使用的媒體做預(yù)測等。制作發(fā)布期的質(zhì)量保證：保證在遇到較大的媒體時能保持瀏覽的流暢，應(yīng)在發(fā)布時將視頻等流式化。第十五頁，共四百八十九頁，2022年，8月28日軟件系統(tǒng)的需求種類復(fù)雜第十六頁，共四百八十九頁，2022年，8月28日什么是軟件架構(gòu)視圖個架構(gòu)視圖是對于從某一視角或某一點上看到的系統(tǒng)所做的簡化描述，描述中涵蓋了系統(tǒng)的某一特定方面，而省略了于此方面無關(guān)的實體。架構(gòu)要涵蓋的內(nèi)容和決策太多了，超過了人腦“一蹴而就”的能力范圍，因此采用“分而治之”的辦法從不同視角分別設(shè)計；同時，也為軟件架構(gòu)的理解、交流和歸檔提供了方便。多視圖方法是軟件架構(gòu)歸檔的方法，更是指導(dǎo)我們進行架構(gòu)設(shè)計的思維方法。第十七頁，共四百八十九頁，2022年，8月28日第十八頁，共四百八十九頁，2022年，8月28日邏輯架構(gòu)邏輯架構(gòu)關(guān)注功能。其設(shè)計著重考慮功能需求。開發(fā)架構(gòu)開發(fā)架構(gòu)關(guān)注程序包。其設(shè)計著重考慮開發(fā)期質(zhì)量屬性，如可擴展性、可重用性、可移植性、易理解性和易測試性等。運行架構(gòu)運行架構(gòu)關(guān)注進程、線程、對象等運行時概念，以及相關(guān)的并發(fā)、同步、通信等問題。其設(shè)計著重考慮運行期質(zhì)量屬性，例如性能、可伸縮性、持續(xù)可用性和安全性等。物理架構(gòu)物理架構(gòu)關(guān)注軟件系統(tǒng)最終如何安裝或部署到物理機器。其設(shè)計著重考慮“安裝和部署需求”。以及如何部署機器和網(wǎng)絡(luò)來配合軟件系統(tǒng)的可靠性、可伸縮性等要求。數(shù)據(jù)架構(gòu)數(shù)據(jù)架構(gòu)關(guān)注持久化數(shù)據(jù)的存儲方案。設(shè)計著重考慮“數(shù)據(jù)需求”。第十九頁，共四百八十九頁，2022年，8月28日關(guān)系邏輯視圖。邏輯視圖不僅關(guān)注用戶可見的功能，還包括為實現(xiàn)用戶功能而必須提供的“輔助功能模塊”；它們可能是邏輯層、功能模塊等。開發(fā)視圖。開發(fā)視圖關(guān)注程序包，不僅包括要編寫的源程序，還包括可以直接使用的第三方SDK和現(xiàn)成框架、類庫，以及開發(fā)的系統(tǒng)將運行于其上的系統(tǒng)軟件或中間件。開發(fā)視圖和邏輯視圖之間可能存在一定的映射關(guān)系：比如邏輯層一般會映射到多個程序包等。運行視圖。和開發(fā)視圖的關(guān)系：開發(fā)視圖一般偏重程序包在編譯時期的靜態(tài)依賴關(guān)系，而這些程序運行起來之后會表現(xiàn)為對象、線程、進程，運行視圖比較關(guān)注的正是這些運行時單元的交互問題。物理視圖。和運行視圖的關(guān)系：運行視圖特別關(guān)注目標(biāo)程序的動態(tài)執(zhí)行情況，而物理視圖重視目標(biāo)程序的靜態(tài)位置問題；物理視圖是綜合考慮軟件系統(tǒng)和整個IT系統(tǒng)相互影響的架構(gòu)視圖。第二十頁，共四百八十九頁，2022年，8月28日第二十一頁，共四百八十九頁，2022年，8月28日

第二十二頁，共四百八十九頁，2022年，8月28日軟件生命周期與軟件架構(gòu)介紹第二十三頁，共四百八十九頁，2022年，8月28日24軟件架構(gòu)師的定位系統(tǒng)架構(gòu)師的職責(zé)：一、理解系統(tǒng)的業(yè)務(wù)需求，制定系統(tǒng)的整體框架（包括：技術(shù)框架和業(yè)務(wù)框架）二、對系統(tǒng)框架相關(guān)技術(shù)和業(yè)務(wù)進行培訓(xùn)，指導(dǎo)開發(fā)人員開發(fā)。并解決系統(tǒng)開發(fā)、運行中出現(xiàn)的各種問題。系統(tǒng)架構(gòu)師的目的：對系統(tǒng)的重用、擴展、安全、性能、伸縮性、簡潔等做系統(tǒng)級的把握。系統(tǒng)架構(gòu)師能力要求：一、系統(tǒng)架構(gòu)相關(guān)的知識和經(jīng)驗。二、很強的自學(xué)能力、分析能力、解決問題的能力。三、寫作、溝通表達(dá)、培訓(xùn)。第二十四頁，共四百八十九頁，2022年，8月28日25角色軟件架構(gòu)師SoftwareArchitect定義主導(dǎo)系統(tǒng)全局分析設(shè)計和實施、負(fù)責(zé)軟件構(gòu)架和關(guān)鍵技術(shù)決策的角色第二十五頁，共四百八十九頁，2022年，8月28日26職責(zé)領(lǐng)導(dǎo)與協(xié)調(diào)整個項目中的技術(shù)活動（分析、設(shè)計和實施等）推動主要的技術(shù)決策，并最終表達(dá)為軟件構(gòu)架確定和文檔化系統(tǒng)的相對構(gòu)架而言意義重大的方面，包括系統(tǒng)的需求、設(shè)計、實施和部署等“視圖”確定設(shè)計元素的分組以及這些主要分組之間的接口為技術(shù)決策提供規(guī)則，平衡各類涉眾的不同關(guān)注點，化解技術(shù)風(fēng)險，并保證相關(guān)決定被有效的傳達(dá)和貫徹理解、評價并接收系統(tǒng)需求評價和確認(rèn)軟件架構(gòu)的實現(xiàn)第二十六頁，共四百八十九頁，2022年，8月28日27專業(yè)技能技術(shù)全面、成熟練達(dá)、洞察力強、經(jīng)驗豐富，具備在缺乏完整信息、眾多問題交織一團、模糊和矛盾的情況下，迅速抓住問題要害，并做出合理的關(guān)鍵決定的能力。具備戰(zhàn)略性和前瞻性思維能力，善于把握全局，能夠在更高抽象級別上進行思考。對項目開發(fā)涉及的所有問題領(lǐng)域都有經(jīng)驗，包括徹底地理解項目需求，開展分析設(shè)計之類軟件工程活動等。具備領(lǐng)導(dǎo)素質(zhì)，以在各小組之間推進技術(shù)工作，并在項目壓力下做出牢靠的關(guān)鍵決策。擁有優(yōu)秀的溝通能力，用以進行說服、鼓勵和指導(dǎo)等活動，并贏得項目成員的信任。第二十七頁，共四百八十九頁，2022年，8月28日28以目標(biāo)導(dǎo)向和主動的方式來不帶任何感情色彩地關(guān)注項目結(jié)果，構(gòu)架師應(yīng)當(dāng)是項目背后的技術(shù)推動力，而非構(gòu)想者或夢想家（追求完美）精通構(gòu)架設(shè)計的理論、實踐和工具，并掌握多種參考構(gòu)架、主要的可重用構(gòu)架機制和模式。具備系統(tǒng)設(shè)計員的所有技能，但涉及面更廣、抽象級別更高。第二十八頁，共四百八十九頁，2022年，8月28日軟件架構(gòu)師的知識體系軟件架構(gòu)師作為整個軟件系統(tǒng)結(jié)構(gòu)的總設(shè)計師，其知識體系、技能和經(jīng)驗決定了軟件系統(tǒng)的可靠性、安全性、可維護性、可擴展性和可移植性等方面的性能。因此一個優(yōu)秀的軟件架構(gòu)師必須具備相當(dāng)豐富的知識、技能和經(jīng)驗。通過對比軟件架構(gòu)師和系統(tǒng)分析師在軟件開發(fā)中的職責(zé)和角色，不難發(fā)現(xiàn)軟件架構(gòu)師與系統(tǒng)分析師所必需的知識體系也是不盡相同的，系統(tǒng)分析師的主要職責(zé)是在需求分析、開發(fā)管理、運行維護等方面，而軟件架構(gòu)師的重點工作是在架構(gòu)與設(shè)計這兩個關(guān)鍵環(huán)節(jié)上。因此在系統(tǒng)分析師必須具備的知識體系中對系統(tǒng)的構(gòu)架與設(shè)計等方面知識體系的要求就相對低些；而軟件架構(gòu)師在需求分析、項目管理、運行維護等方面知識的要求也就相對低些。29第二十九頁，共四百八十九頁，2022年，8月28日成為一名合格的軟件架構(gòu)師必須具備的知識信息系統(tǒng)綜合知識體系軟件架構(gòu)知識體系30第三十頁，共四百八十九頁，2022年，8月28日？MFC，MSF，MOF，RUP，J2EE，Spring，SOA，JUnit，ORM，.NetMVC，UML，XML，Corba，MDA，MDD，Web-ServiceRSS，Web2.0，AJAX，Serverlet，HibernateIOC，AOPRubyOnRailsRupBPELWorkflowEngineLBSOracleCMMIMQ…31第三十一頁，共四百八十九頁，2022年，8月28日軟件架構(gòu)師在干什么？思考、思考、再思考深入理解、準(zhǔn)確把握建設(shè)的業(yè)務(wù)需求分析所有可見的問題、障礙、風(fēng)險充分參考已有的成功方案，降低風(fēng)險交流、討論、博弈、質(zhì)疑對構(gòu)思中的方案不斷提出質(zhì)疑，避免漏洞廣泛聽取各層面的意見，開拓思路反復(fù)質(zhì)疑、逐步完善已有的設(shè)計構(gòu)思在動手實現(xiàn)之前驗證設(shè)計方案的正確性32第三十二頁，共四百八十九頁，2022年，8月28日軟件架構(gòu)師的知識結(jié)構(gòu)軟件知識最好要有系統(tǒng)開發(fā)全過程經(jīng)驗。對IT建設(shè)生命周期各個環(huán)節(jié)有深入了解，包括：系統(tǒng)/模塊邏輯設(shè)計、物理設(shè)計、代碼開發(fā)、項目管理、測試、發(fā)布、運行維護等。深入掌握1-2種主流技術(shù)平臺上開發(fā)系統(tǒng)的方法。了解多種應(yīng)用系統(tǒng)的結(jié)構(gòu)。了解架構(gòu)設(shè)計領(lǐng)域的主要理論、流派、框架。33第三十三頁，共四百八十九頁，2022年，8月28日軟件架構(gòu)師的知識結(jié)構(gòu)業(yè)務(wù)知識深入了解系統(tǒng)建設(shè)的業(yè)務(wù)需求。了解系統(tǒng)的非功能需求和運行維護需求。了解企業(yè)IT公共設(shè)施、網(wǎng)絡(luò)環(huán)境、外部系統(tǒng)。34第三十四頁，共四百八十九頁，2022年，8月28日軟件架構(gòu)師的思維方式基于框架的思維架構(gòu)設(shè)計的層次（Enterprise，Application，etc）IT的生命周期（What，Why，Where，How，When，etc）成功經(jīng)驗以及方法論的指導(dǎo)合理把握技術(shù)細(xì)節(jié)把握各個層次應(yīng)有的內(nèi)容合理忽略不應(yīng)有的技術(shù)細(xì)節(jié)35第三十五頁，共四百八十九頁，2022年，8月28日軟件架構(gòu)師的思維方式風(fēng)險管理意識采用成功經(jīng)驗、避免不應(yīng)有的風(fēng)險多方位的開放思維多維度、多方向、包容性、避免排他性分析、質(zhì)疑、抽象、歸納沒有絕對好的架構(gòu)設(shè)計，只有相對優(yōu)秀的方案36第三十六頁，共四百八十九頁，2022年，8月28日注意：并不存在通用的設(shè)計方法。我們認(rèn)為，給定的某種固定的方法總是會顧此失彼，而且這種不平衡性不太容易覺察。如果給定的某種方法所注重的方面與系統(tǒng)需求不吻合，則這種方法就會將設(shè)計引入歧途。所以我們給出的是一些技巧，任何一次設(shè)計過程，都需要設(shè)計師仔細(xì)分析系統(tǒng)的需求和相關(guān)的約束條件，靈活運用眾多的設(shè)計技巧，針對不同的設(shè)計方案進行取舍，做出合理的決策。37第三十七頁，共四百八十九頁，2022年，8月28日為了有效地控制設(shè)計工作的復(fù)雜性，一般把設(shè)計活動分為總體設(shè)計和詳細(xì)設(shè)計兩個層次?？傮w設(shè)計主要關(guān)注于體系結(jié)構(gòu)和接口這些全局性的內(nèi)容，而詳細(xì)設(shè)計主要關(guān)注于每個模塊內(nèi)部的數(shù)據(jù)結(jié)構(gòu)和算法。至于數(shù)據(jù)，則在設(shè)計的各個層次都會涉及。軟件設(shè)計是一個迭代的過程，是一個逐步細(xì)化和求精的過程。因此，總體設(shè)計和詳細(xì)設(shè)計之間的劃分并不是絕對的。哪些是總體設(shè)計任務(wù)，哪些是詳細(xì)設(shè)計任務(wù)，取決于設(shè)計師對于整個項目的把握，并沒有一個統(tǒng)一的標(biāo)準(zhǔn)。設(shè)計師在設(shè)計時實際是在做一系列的設(shè)計決策，來滿足系統(tǒng)的行為目標(biāo)，質(zhì)量目標(biāo)和開發(fā)目標(biāo)。如果一個結(jié)構(gòu)對于完成這些目標(biāo)非常重要，則它是構(gòu)架的一部分。相反，如果它可以留到以后再完善，則它不是構(gòu)架的組成部分。因此，總的說來，一個設(shè)計是不是屬于構(gòu)架設(shè)計，要看你當(dāng)前的設(shè)計目標(biāo)。38第三十八頁，共四百八十九頁，2022年，8月28日管理陷阱隨著管理性責(zé)任的增加，你所從事技術(shù)性工作的時間就會顯著減少。這樣，因為在完成技術(shù)性任務(wù)和保持職業(yè)技能上花費時間的減少，你可能會失去技術(shù)優(yōu)勢。軟件架構(gòu)師和管理者有很大的差異：軟件架構(gòu)師是直接的技術(shù)貢獻(xiàn)者；而管理者則是通過協(xié)調(diào)其他人員的活動來間接做出貢獻(xiàn)。他們往往一起協(xié)作，構(gòu)成高效的管理團隊。以經(jīng)驗看，把兩者結(jié)合起來卻不能長久地工作。作為一名軟件架構(gòu)師，如果你已經(jīng)建立起個人的職業(yè)原則的話，就有可能避免成為管理者。第三十九頁，共四百八十九頁，2022年，8月28日架構(gòu)和設(shè)計應(yīng)該做到何種程度軟件架構(gòu)必須設(shè)計到“能為開發(fā)人員提供足夠的指導(dǎo)和限制”的程度。分而治之的兩種方式分而治之的緣由：問題太復(fù)雜了，超出了人們能夠“一蹴而就”的范圍。（接口和實現(xiàn)分離）一、先不把問題研究得那么深，那么細(xì)，淺嘗輒止，見好就收。這種分而治之的方式稱為“按問題深度分而治之”。二、先不研究整個問題，而是研究問題的一部分，分割問題。這種分而治之的方式稱為“按問題廣度分而治之”。（比如展現(xiàn)層、業(yè)務(wù)層和數(shù)據(jù)層的開發(fā)）40第四十頁，共四百八十九頁，2022年，8月28日隨著軟件設(shè)計工作越來越復(fù)雜，將架構(gòu)設(shè)計和詳細(xì)設(shè)計分離已成為普遍的做法。將設(shè)計分為架構(gòu)設(shè)計和詳細(xì)設(shè)計，是對“按問題深度分而治之”思想的運用。所謂架構(gòu)設(shè)計，就是關(guān)于如何構(gòu)建軟件的一些最重要的設(shè)計決策;詳細(xì)設(shè)計針對每個部分的內(nèi)部進行設(shè)計?？梢赃@么說，軟件架構(gòu)設(shè)計應(yīng)當(dāng)解決的是全局性的、涉及不同“局部”之間交互的設(shè)計問題，而不同“局部”的設(shè)計由后續(xù)的詳細(xì)設(shè)計負(fù)責(zé)。41第四十一頁，共四百八十九頁，2022年，8月28日面對“技術(shù)復(fù)雜性”和“管理復(fù)雜性”這樣的雙重困難，以架構(gòu)為中心的開發(fā)方法是有效的途徑：一方面：“軟件系統(tǒng)的架構(gòu)涵蓋了整個系統(tǒng)，盡管架構(gòu)的有些部分可能只有‘一寸深’”。構(gòu)造一個具有一定抽象層次的解決方案，而不是將所有細(xì)節(jié)統(tǒng)統(tǒng)展開，從而有效地控制了“技術(shù)復(fù)雜性”。沒有“把問題研究那么深、那么細(xì)”，屬于“按問題深度分而治之”42第四十二頁，共四百八十九頁，2022年，8月28日另一方面，因為“架構(gòu)中包含了關(guān)于各元素應(yīng)如何彼此相關(guān)的信息”，從而可以把不同模塊分配給不同小組分頭開發(fā)，而軟件架構(gòu)設(shè)計方案在這些小組中間扮演“橋梁”和“合作契約”的作用。每個小組的工作覆蓋了“整個問題的一部分”，各小組之間可以互相獨立地進行并行工作，這種“分割問題，各個擊破”的策略，屬于“按問題廣度分而治之”。這樣一來，模塊的技術(shù)細(xì)節(jié)被局部化到了小組內(nèi)部，內(nèi)部的細(xì)節(jié)不會成為小組間協(xié)作溝通的主要內(nèi)容，理順了溝通的層次。另外，對“人盡其才”也有好處，不同小組的成員需要精通的技術(shù)各不相同。例如，用戶界面層、數(shù)據(jù)管理層、系統(tǒng)交互層

。43第四十三頁，共四百八十九頁，2022年，8月28日架構(gòu)要進行到什么程度軟件架構(gòu)是團隊開發(fā)的基礎(chǔ)，應(yīng)明確規(guī)定后期分頭開發(fā)所必須的公共設(shè)計約定，為分頭開發(fā)提供足夠的指導(dǎo)和限制。另一方面，具體的架構(gòu)設(shè)計程度還會因軟件項目的不同而不同。架構(gòu)設(shè)計對軟件的不同部分的設(shè)計程度并不是整齊劃一的。(通信機制、持久化機制、消息機制等對應(yīng)的公共模塊；具體的業(yè)務(wù)功能模塊在架構(gòu)設(shè)計中往往設(shè)計程度不深。）歸納：由于項目的不同、開發(fā)團隊情況的不同，軟件架構(gòu)的設(shè)計程度會有不同;軟件架構(gòu)應(yīng)當(dāng)為開發(fā)人員提供足夠的指導(dǎo)和限制。44第四十四頁，共四百八十九頁，2022年，8月28日

高來高去式架構(gòu)設(shè)計的癥狀不能為開發(fā)人員提供足夠的指導(dǎo)和限制的那種架構(gòu)設(shè)計方案。高來高去式架構(gòu)設(shè)計現(xiàn)象極為普遍，危害：缺少來自架構(gòu)的足夠的指導(dǎo)和限制，開發(fā)人員在進入分頭開發(fā)階段之后會碰到很多問題，并且容易造成管理混亂，溝通和協(xié)作效率低；對軟件質(zhì)量非常關(guān)鍵的全局性設(shè)計決定被拖延到分頭開發(fā)期間草率決定；沒有完成化解重大技術(shù)風(fēng)險的職責(zé)；團隊成員對架構(gòu)師意見大，團隊士氣受到打擊。45第四十五頁，共四百八十九頁，2022年，8月28日癥狀一：缺失重要架構(gòu)視圖。給團隊的不同角色提供指導(dǎo)。癥狀二：架構(gòu)設(shè)計方案停留在概念性架構(gòu)的層面，全局性的設(shè)計決策最后由具體開發(fā)人員從局部視角考慮并確定下來，造成技術(shù)和管理上的種種問題。癥狀三：名不副實的分層架構(gòu)。對各層之間交互接口和交互機制的設(shè)計嚴(yán)重不足。46第四十六頁，共四百八十九頁，2022年，8月28日47架構(gòu)設(shè)計的GRASP模式第四十七頁，共四百八十九頁，2022年，8月28日48第四十八頁，共四百八十九頁，2022年，8月28日49第四十九頁，共四百八十九頁，2022年，8月28日50第五十頁，共四百八十九頁，2022年，8月28日51第五十一頁，共四百八十九頁，2022年，8月28日52第五十二頁，共四百八十九頁，2022年，8月28日53第五十三頁，共四百八十九頁，2022年，8月28日54第五十四頁，共四百八十九頁，2022年，8月28日55第五十五頁，共四百八十九頁，2022年，8月28日56第五十六頁，共四百八十九頁，2022年，8月28日57第五十七頁，共四百八十九頁，2022年，8月28日58第五十八頁，共四百八十九頁，2022年，8月28日59第五十九頁，共四百八十九頁，2022年，8月28日60第六十頁，共四百八十九頁，2022年，8月28日61第六十一頁，共四百八十九頁，2022年，8月28日62第六十二頁，共四百八十九頁，2022年，8月28日63第六十三頁，共四百八十九頁，2022年，8月28日64第六十四頁，共四百八十九頁，2022年，8月28日65第六十五頁，共四百八十九頁，2022年，8月28日66第六十六頁，共四百八十九頁，2022年，8月28日第六十七頁，共四百八十九頁，2022年，8月28日第六十八頁，共四百八十九頁，2022年，8月28日質(zhì)量屬性驅(qū)動架構(gòu)設(shè)計策略

第六十九頁，共四百八十九頁，2022年，8月28日軟件質(zhì)量及質(zhì)量模型軟件質(zhì)量是一個復(fù)雜的概念，不同的人從不同的角度來看軟件質(zhì)量問題，會有不同的理解。從用戶的角度看，質(zhì)量就是滿足客戶的需求；從開發(fā)者的角度看，質(zhì)量

就是與需求說明保持一致；從產(chǎn)品的角度看，質(zhì)量就是

產(chǎn)品的內(nèi)在特點；從價值的角度看，質(zhì)量就是客戶是否

愿意購買。

第七十頁，共四百八十九頁，2022年，8月28日在軟件項目開發(fā)過程中，項目經(jīng)理眼中的質(zhì)量就是能“令人滿意”地工作以完成預(yù)期功能的軟件產(chǎn)品。所謂“令

人滿意”，包括功能、性能、接口需求及其他指標(biāo)，如可靠性、可維護性、可復(fù)用性和正確性。然而在實際工作中，一旦出現(xiàn)問題時，項目管理人員必須權(quán)衡利弊，作出取舍，在滿足某一個指標(biāo)的同時，犧牲另外一個或幾個指標(biāo)。比如為了按期交貨，需對軟件功能進行分類，在第

一個版本中實現(xiàn)優(yōu)先級較高的功能，在第二個版本中實

現(xiàn)優(yōu)先級較低的功能。因此，項目經(jīng)理需要一個對其工作有指導(dǎo)意義的質(zhì)量模型和度量方法。該模型一方面可以幫助項目經(jīng)理生產(chǎn)出符合標(biāo)準(zhǔn)的軟件產(chǎn)品，另一方面幫助項目經(jīng)理識別可能影響產(chǎn)品質(zhì)量的風(fēng)險。第七十一頁，共四百八十九頁，2022年，8月28日為什么那么多軟件產(chǎn)品需要重新設(shè)計？難以維護？運行速度太慢？穩(wěn)定性差？無法進行功能擴展？易遭受安全攻擊？忽視包括質(zhì)量屬性需求在內(nèi)的非功能需求是致命的。第七十二頁，共四百八十九頁，2022年，8月28日質(zhì)量屬性分為：運行期質(zhì)量屬性開發(fā)期質(zhì)量屬性各類需求架構(gòu)設(shè)計的不同影響高可移植性對硬件和平臺相關(guān)特性進行封裝、隔離高性能精心規(guī)劃職責(zé)模型在質(zhì)量屬性方面需求折衷第七十三頁，共四百八十九頁，2022年，8月28日質(zhì)量屬性分析的位置質(zhì)量屬性分析是概念性架構(gòu)設(shè)計的重要步驟。通過質(zhì)量屬性分析，制定出滿足非功能需求的高層設(shè)計決策。質(zhì)量屬性分析所處的位置如圖所示第七十四頁，共四百八十九頁，2022年，8月28日”屬性-場景-決策”表法運用“關(guān)鍵需求決定架構(gòu)”的策略，使質(zhì)量屬性分析的“輸入”集中到關(guān)鍵質(zhì)量屬性需求?！皩傩?場景-決策”表方法提倡通過一組具體場景將要達(dá)到的質(zhì)量屬性需求目標(biāo)細(xì)化，再根據(jù)場景制定架構(gòu)決策。第七十五頁，共四百八十九頁，2022年，8月28日“屬性-場景-決策“表法第七十六頁，共四百八十九頁，2022年，8月28日第七十七頁，共四百八十九頁，2022年，8月28日“屬性-場景-決策”表法的好處:可操作性強。質(zhì)量熟悉需求是籠統(tǒng)的目標(biāo)，而一組質(zhì)量場景使之明確化。避免過度設(shè)計。借助“屬性-場景-決策”表對質(zhì)量場景進行評估，通過權(quán)衡場景發(fā)生的概率和遺漏它的代價，決定是否應(yīng)滿足該場景的要求。便于系統(tǒng)升級時參考。第七十八頁，共四百八十九頁，2022年，8月28日例：可擴展性質(zhì)量屬性第七十九頁，共四百八十九頁，2022年，8月28日運用“屬性-場景-決策”表方法，細(xì)化PMTool的可擴展性需求，制定架構(gòu)決策，如下表所示：第八十頁，共四百八十九頁，2022年，8月28日非功能需求對軟件架構(gòu)的影響比功能需求更大?！皩傩?場景-決策”表可以幫助軟件架構(gòu)師以一種更透明、更可操作的方式完成從質(zhì)量屬性需求到質(zhì)量場景的細(xì)化，最終根據(jù)具體的場景有針對性地設(shè)計架構(gòu)決策。第八十一頁，共四百八十九頁，2022年，8月28日第八十二頁，共四百八十九頁，2022年，8月28日架構(gòu)的目標(biāo)正確性correctness可靠性（Reliable）：軟件系統(tǒng)對于用戶的商業(yè)經(jīng)營和管理來說極為重要，因此軟件系統(tǒng)必須非?？煽俊＝研詒obustness安全性（Secure）：軟件系統(tǒng)所承擔(dān)的交易的商業(yè)價值極高，系統(tǒng)的安全性非常重要?？缮炜s性（Scalable）：軟件必須能夠在用戶的使用率、用戶的數(shù)目增加很快的情況下，保持合理的性能。只有這樣，才能適應(yīng)用戶的市場擴展得可能性。第八十三頁，共四百八十九頁，2022年，8月28日可定制化（Customizable）：同樣的一套軟件，可以根據(jù)客戶群的不同和市場需求的變化進行調(diào)整?？蓴U展性（Extensible）：在新技術(shù)出現(xiàn)的時候，一個軟件系統(tǒng)應(yīng)當(dāng)允許導(dǎo)入新技術(shù)，從而對現(xiàn)有系統(tǒng)進行功能和性能的擴展可復(fù)用性reusability可維護性（Maintainable）：軟件系統(tǒng)的維護包括兩方面，一是排除現(xiàn)有的錯誤，二是將新的軟件需求反映到現(xiàn)有系統(tǒng)中去。一個易于維護的系統(tǒng)可以有效地降低技術(shù)支持的花費。第八十四頁，共四百八十九頁，2022年，8月28日兼容性compatibility可移植性portability易用性easeofuse高效性efficiencytimeliness,economyandfunctionality第八十五頁，共四百八十九頁，2022年，8月28日客戶體驗（CustomerExperience）：軟件系統(tǒng)必須易于使用。

市場時機（TimetoMarket）：軟件用戶要面臨同業(yè)競爭，軟件提供商也要面臨同業(yè)競爭。以最快的速度爭奪市場先機非常重要。第八十六頁，共四百八十九頁，2022年，8月28日87軟件可維護性第八十七頁，共四百八十九頁，2022年，8月28日重型和輕型方法重型方法：偏重于計劃、過程和中間產(chǎn)物敏捷方法：更加看重人和溝通。人和溝通永遠(yuǎn)是第一位的，而計劃、過程和中間產(chǎn)物，只是保證溝通、實現(xiàn)目標(biāo)的手段。并非計劃、過程、中間產(chǎn)物不重要，但不能本末倒置。評判軟件成功的標(biāo)準(zhǔn)：很多。對敏捷方法：首先在于交付可用的軟件。為了保證軟件的可用性，需求是根本。對于架構(gòu)設(shè)計工作，從需求出發(fā)來設(shè)計架構(gòu)，是保證軟件可用性的基本的保證。

第八十八頁，共四百八十九頁，2022年，8月28日如何開始架構(gòu)設(shè)計工作考慮的平臺、語言、開發(fā)環(huán)境、數(shù)據(jù)庫等誤區(qū)：架構(gòu)設(shè)計就是寫一些空話，套話。誤區(qū)：對與客戶具體情況密切相關(guān)的問題卻未系統(tǒng)考慮。IT界的技術(shù)層出不窮，面對著如此之多的技術(shù)、平臺、框架、函數(shù)庫，我們?nèi)绾芜x擇一組適合軟件的技術(shù)？要針對需求設(shè)計架構(gòu)。每個客戶都有自身特點，如何才能夠設(shè)計出符合客戶利益的架構(gòu)？軟件中往往都充斥著眾多的問題，在一開始就把所有的問題都想清楚往往很難做到，但是如果不解決問題，風(fēng)險又居高不下。第八十九頁，共四百八十九頁，2022年，8月28日架構(gòu)設(shè)計就是鋪設(shè)軟件的主管道。根據(jù)什么來制定主管道的粗細(xì)、路徑等因素？是根據(jù)城市的人口、地理位置、水源等因素。對應(yīng)到軟件設(shè)計，城市的各因素就是軟件中的各種需求：功能需求、非功能需求、變化案例等。例：城市中自來水管的架設(shè)是一項非常的復(fù)雜的工程。為了需要滿足每家每戶的需要，自來水管組成了一個龐大的網(wǎng)絡(luò)。在這樣一個復(fù)雜的網(wǎng)絡(luò)中，如何完成鋪設(shè)的任務(wù)呢。一般的做法是，先找出問題的根源，也就是水的源頭。從水源鋪設(shè)一條管道通至城市，然后根據(jù)城市的區(qū)域劃分，設(shè)計出主管道，剩下的就是使用的問題了，每家每戶的管道最終都是連到主管道上的。因此，雖然自來水網(wǎng)絡(luò)龐大復(fù)雜。但是真正的主管道是比較簡單的。第九十頁，共四百八十九頁，2022年，8月28日一般來說，功能需求決定業(yè)務(wù)架構(gòu)、非功能需求決定技術(shù)架構(gòu)，變化案例決定架構(gòu)的范圍。功能需求決定軟件能夠做些什么。我們需要根據(jù)業(yè)務(wù)上的需求來設(shè)計業(yè)務(wù)架構(gòu)，以使得未來的軟件能夠滿足客戶的需要。非功能需求定義了性能、效率上的一些約束、規(guī)則。而我們的技術(shù)架構(gòu)要能夠滿足這些約束和規(guī)則。變化案例是對未來可能發(fā)生的變化的一個估計，結(jié)合功能需求和非功能需求，我們就可以確定一個需求的范圍，進而確定一個架構(gòu)的范圍。例：一個字處理軟件，功能需求可以簡單概括為格式化用戶輸入的文字，非功能需求可能是格式化大小為1000K的一段文字的處理速度不能低于10S，變化案例可能是推出多種語言版本。則在設(shè)計業(yè)務(wù)架構(gòu)時，我們會集中于如何表示文字、圖象、媒體等要素，此外需要有另外的技術(shù)架構(gòu)來處理速度問題，比如緩沖技術(shù)，對于變化案例，我們也要考慮相應(yīng)的架構(gòu)，比如把字體獨立于程序包的設(shè)計。第九十一頁，共四百八十九頁，2022年，8月28日架構(gòu)設(shè)計的兩項工作分析：分析是分析需求設(shè)計：設(shè)計軟件的大致結(jié)構(gòu)。很多方法論分離二者，其實無一定的界限，做分析的時候會想到如何設(shè)計，而思考如何設(shè)計反過來又會影響分析的效果?？梢哉f，兩者間是相互聯(lián)系和不斷迭代的。第九十二頁，共四百八十九頁，2022年，8月28日需求與架構(gòu)都應(yīng)迭代進行一點一點的作需求。這種做法在那些需求變化快的項目中尤其適用。由于我們采用的流程是一種迭代式的流程，這里我們將會面臨著如何對待上一次迭代的中間產(chǎn)物的問題。如果我們每一次迭代都需要修改已存在的中間產(chǎn)物，那么這種維護的成本未免過大。因此，敏捷方法論的基本做法是，扔掉那些已經(jīng)沒有用處的中間產(chǎn)物。軟件要比文檔重要。生成中間產(chǎn)物的目的都是為了生成最終的程序，對于這些已經(jīng)完成作用的模型，沒有必要付出額外的維護成本。第九十三頁，共四百八十九頁，2022年，8月28日架構(gòu)設(shè)計中的一些提示（也是拋棄模型的必要條件）：簡單化：簡單的模型和簡單的程序。模型和程序越復(fù)雜，就需要更多的精力來處理它們。因此盡可能簡化它們，為的是更容易的處理它們。高效溝通渠道：通過增強溝通的效果來減少對中間產(chǎn)物的需要。試想若隨時能從客戶處得到需求的細(xì)節(jié)資料，則前期需求調(diào)研就沒有必要做得太細(xì)。角色交叉輪換：開發(fā)人員間建立起交換角色的機制，能夠盡量的避免各子系統(tǒng)諸侯割據(jù)的局面。清晰的流程：或明確的過程。過程在方法論中是重點，敏捷方法論也不例外。開發(fā)人員能夠清楚的知道，今天做什么，明天做什么。過程不是給別人看的，而是給自己用的。第九十四頁，共四百八十九頁，2022年，8月28日工具：好用的工具能夠節(jié)省大量的時間，工具并不僅指CASE工具，還包括版本控制工具、自動測試工具、畫圖工具、文檔制作和管理工具。使用工具要注意成本和效益的問題。標(biāo)準(zhǔn)和風(fēng)格：語言標(biāo)準(zhǔn)不同是溝通的很大障礙。語言從某個角度來看屬于一種標(biāo)準(zhǔn)、一種風(fēng)格。因此，一個團隊如果采用同樣的編碼標(biāo)準(zhǔn)、文檔標(biāo)準(zhǔn)、注釋風(fēng)格、制圖風(fēng)格，那么這個團隊的溝通效率一定非常高。

如果上述的環(huán)境都不具備，或是欠缺好幾項，那你的文檔的模型還是留著的好。

第九十五頁，共四百八十九頁，2022年，8月28日僅針對需求設(shè)計架構(gòu)不要做未來才有用的事情。有時我們會把架構(gòu)考慮得非常復(fù)雜，主要原因是把很多未來的因素放入到現(xiàn)在來考慮?；蛟陂_發(fā)第一個產(chǎn)品的時候就試圖做成完美的框架。以上的這兩種思路有沒有錯呢？沒有錯，這只是如何看待投入的問題，有人希望開始的時候多投入一些，這樣后續(xù)的投入就會節(jié)省下來。但在現(xiàn)實中，由于需求的不確定性，希望通過增加開始階段的投入來將降低未來的投入往往是難以做到的，框架的設(shè)計也絕非一蹴而就的，因此這種做法并不好。同其它很多事物一樣，架構(gòu)設(shè)計應(yīng)保持簡單性和迭代過程！第九十六頁，共四百八十九頁，2022年，8月28日引入模式模式幫助我們抓住重點。為了解決設(shè)計文檔編輯器引出的七個問題，一共使用了8種不同的模式。這8種模式的組合其實就是架構(gòu)，因為它們解決的，都是系統(tǒng)中最高層的問題。架構(gòu)也是存在模式的。比如，對于系統(tǒng)結(jié)構(gòu)設(shè)計，我們使用層模式；對于分布式系統(tǒng)，我們使用代理模式；對于交互系統(tǒng)，我們使用MVC（模型-視圖-控制器）模式。模式本來就是針對特定問題的解，因此，針對需求的特點，我們也可以采用相應(yīng)的模式來設(shè)計架構(gòu)。

第九十七頁，共四百八十九頁，2022年，8月28日第九十八頁，共四百八十九頁，2022年，8月28日PetShot案例在MVC圖背后隱藏著的需求：系統(tǒng)需要支持多種用戶界面，包括為普通用戶提供的HTML界面，為無線用戶提供的WML界面，為管理員提供的Swing界面，以及為B2B業(yè)務(wù)設(shè)計的WebService界面。這是系統(tǒng)最重要的需求，因此，系統(tǒng)的設(shè)計者就需要確定一個穩(wěn)定的架構(gòu)，以解決多界面的問題。相對于多界面的問題，后端的業(yè)務(wù)處理邏輯都是一致的。比如HTML界面和WML界面的功能并沒有太大的差別。把處理邏輯和界面分離開來還有額外的好處，可以在添加功能的同時，不涉及界面的改動，反之亦然。（耦合度的問題）。

MVC模式正可以適用于解決該問題。系統(tǒng)使用控制器來為業(yè)務(wù)邏輯選擇不同的界面，這就完成了MVC架構(gòu)的設(shè)計思路。在架構(gòu)設(shè)計的工作中，我們手頭上有模式這樣一張好牌，有什么理由不去使用它呢？第九十九頁，共四百八十九頁，2022年，8月28日第一百頁，共四百八十九頁，2022年，8月28日抓住重點架構(gòu)是一種抽象，即架構(gòu)設(shè)計摒棄了具體的細(xì)節(jié)，僅僅抓住軟件最高層的概念，也就是最上層、優(yōu)先級最高、風(fēng)險最大的那部分需求。考慮、分析、解決一個問題，一定有一個漸進的過程。架構(gòu)設(shè)計就是解決問題其中比較早期的一個階段，我們不會在架構(gòu)設(shè)計這個階段投入過多的時間，因此關(guān)鍵點在于我們要能夠在架構(gòu)設(shè)計中把握住需求的重點。比如，分布式系統(tǒng)和交互系統(tǒng)，分布和交互就是這兩個系統(tǒng)的重點。那么，如果說我們面對的是一個分布式的交互系統(tǒng)，那么，我們就需要把這兩種特性做為重點來考慮，并以此為基礎(chǔ)，設(shè)計架構(gòu)。而寵物商店的范例也是類似的，除了MVC的架構(gòu)，還有很多的設(shè)計問題需要解決，例如用于數(shù)據(jù)庫訪問的數(shù)據(jù)對象，用于視圖管理的前端控制器等。但是這些相對于MVC模式來說，屬于局部的，優(yōu)先級較低的部分，可以在架構(gòu)確定后再來設(shè)計。第一百零一頁，共四百八十九頁，2022年，8月28日架構(gòu)設(shè)計和領(lǐng)域?qū)＜乙粋€架構(gòu)要設(shè)計的好，和對需求的理解是分不開的。因此在現(xiàn)實中，業(yè)務(wù)領(lǐng)域?qū)＜覒{借著他對業(yè)務(wù)領(lǐng)域的了解，能夠幫助開發(fā)人員設(shè)計出優(yōu)秀的架構(gòu)來。架構(gòu)是需要抽象的，它是現(xiàn)實社會活動的一個基本模型，而業(yè)務(wù)領(lǐng)域的模型僅僅憑開發(fā)人員是很難設(shè)計出來的。在ERP的發(fā)展史上，MRP發(fā)展為MRPII，再發(fā)展到閉環(huán)MRP，直到發(fā)展成為現(xiàn)在的ERP，主要的因素是管理思想的演化，也就是說，對業(yè)務(wù)領(lǐng)域的理解進步了，架構(gòu)才有可能進步。因此，敏捷型架構(gòu)設(shè)計的過程中，我們也非常強調(diào)領(lǐng)域?qū)＜业淖饔谩５谝话倭愣?，共四百八十九頁?022年，8月28日軟件約束條件與架構(gòu)的影響資金時間業(yè)務(wù)運行環(huán)境開發(fā)團隊實現(xiàn)技術(shù)等第一百零三頁，共四百八十九頁，2022年，8月28日104領(lǐng)域模型設(shè)計領(lǐng)域模型（DomainModel）商業(yè)建模范疇的概念：同行業(yè)企業(yè)的業(yè)務(wù)模型必定有很大的共性和內(nèi)在的規(guī)律性，由這個行業(yè)內(nèi)的各個企業(yè)的業(yè)務(wù)模型再向上抽象出來整個行業(yè)的業(yè)務(wù)模型，即領(lǐng)域模型。技術(shù)建模范疇的概念：用編程語言來實現(xiàn)商業(yè)領(lǐng)域模型。第一百零四頁，共四百八十九頁，2022年，8月28日關(guān)系：對行業(yè)經(jīng)驗積累不足的軟件公司，開發(fā)軟件由需求驅(qū)動，而非商業(yè)的領(lǐng)域模型驅(qū)動。商業(yè)領(lǐng)域模型與編程語言的不是一對一的對應(yīng)關(guān)系。例如用EJB2模型，需要最少兩個以上的EJB，即一個SessionBean，處理面向流程的控制邏輯，一個EntityBean，處理面向持久化的實體邏輯（持久化操作附著在EntityBean的Home接口上）。如果是更加復(fù)雜的領(lǐng)域模型，則需要更多的EJB，一般一個領(lǐng)域模型需要多個EntityBean和多個SessionBean。使用基于POJO模型的實現(xiàn)，則粗顆粒度的EJB要繼續(xù)細(xì)分：一個EntityBean對應(yīng)三個以上POJO：一個或者多個實體類，DAO接口、DAO接口實現(xiàn)類；一個SessionBean要切分為多個業(yè)務(wù)Bean。105第一百零五頁，共四百八十九頁，2022年，8月28日106層次結(jié)構(gòu)領(lǐng)域模型從EJB到輕量級框架第一百零六頁，共四百八十九頁，2022年，8月28日107層次結(jié)構(gòu)表現(xiàn)層（present）業(yè)務(wù)層業(yè)務(wù)層外觀業(yè)務(wù)服務(wù)層領(lǐng)域?qū)ο蠊芾?服務(wù)/倉庫層領(lǐng)域?qū)ο髮映志脤訑?shù)據(jù)訪問層數(shù)據(jù)庫第一百零七頁，共四百八十九頁，2022年，8月28日108領(lǐng)域模型中的各種角色：實體--有唯一的標(biāo)識,并且要有屬性和行為(非GET/SET)，添加了行為，使其具有生命力。往往在設(shè)計時，實體的形為最難決斷。為確定行為，我們必須識別它們的責(zé)任和協(xié)作。類的責(zé)任是指該類要做、知道、或決定的一切，由一個或多個方法完成。類中有屬性和關(guān)聯(lián)，協(xié)作就是為完成自己的責(zé)任所調(diào)用其它關(guān)聯(lián)類。值對象--沒有標(biāo)識沒有行為。如Address類。工廠---定義創(chuàng)建實體的方法，封裝實例化對象并將一些關(guān)聯(lián)對象注入。倉庫(repository)管理實體的集合,主要有查找和刪除實體的方法.實現(xiàn)類可以調(diào)用執(zhí)久化層(如Hibernate，Ibatis)服務(wù)(Service)，實現(xiàn)整個應(yīng)用程序的工作流(workflow)。服務(wù)包含那些無法指派的單個實體的行為，由作用于多個對象方法組成。如可以調(diào)用repository查找到實體對象，然后委派給這些對象。服務(wù)和facade很像，但不一樣，它不處理以下事情：1）執(zhí)行事務(wù)。2）收集返回給表現(xiàn)層的數(shù)據(jù)。3）脫鉤對象。4）其它事情。服務(wù)可以說是業(yè)務(wù)的協(xié)調(diào)者，業(yè)務(wù)邏輯可以分散到實體對象中。第一百零八頁，共四百八十九頁，2022年，8月28日109第一百零九頁，共四百八十九頁，2022年，8月28日2、層次之間的交互A、頁面提交表單數(shù)據(jù)到Action，Action創(chuàng)建DTO對象并設(shè)置相應(yīng)屬性值為表單數(shù)據(jù)B、Action傳遞DTO對象給FacadeC、Facade中套用ServiceTemplate事務(wù)模板以加入事務(wù)管理，在ServiceTemplate中根據(jù)具體業(yè)務(wù)調(diào)用Factory或Reposistory，分別create或者load出DomainModel對象D、Facade傳遞DomainModel對象給ServiceE、Service執(zhí)行具體業(yè)務(wù)邏輯（調(diào)用DomainModel對象相應(yīng)的業(yè)務(wù)方法）F、Service調(diào)用Reposistory對狀態(tài)已改變的DomainModel對象進行持久化操作（調(diào)用相應(yīng)DAO）110第一百一十頁，共四百八十九頁，2022年，8月28日注：在Facade或Service中如果需要查詢DomainModel對象中的屬性值，調(diào)用DomainModel對象的getDataInfo()方法得到DataInfo對象，通過DataInfo對象查詢所需數(shù)據(jù)，包括Service返回給Fa?ade業(yè)務(wù)處理結(jié)果中所包含的業(yè)務(wù)數(shù)據(jù)。111第一百一十一頁，共四百八十九頁，2022年，8月28日112領(lǐng)域模型失血模型貧血模型充血模型脹血模型第一百一十二頁，共四百八十九頁，2022年，8月28日113失血模型DO只有屬性及其getter/setter方法，沒有任何業(yè)務(wù)邏輯。缺點：行為與數(shù)據(jù)分離，很多情況導(dǎo)致維護與理解困難。第一百一十三頁，共四百八十九頁，2022年，8月28日114貧血模型DO包含不依賴于持久化的領(lǐng)域邏輯；依賴持久化的領(lǐng)域邏輯歸入Service層。Service(業(yè)務(wù)邏輯，事務(wù)封裝)DAODO優(yōu)點：各層單向依賴，結(jié)構(gòu)清楚，易于實現(xiàn)和維護。設(shè)計簡單易行，底層模型非常穩(wěn)定。缺點：DO部分的持久化邏輯被放入Service層，不夠OO。Service層過重。第一百一十四頁，共四百八十九頁，2022年，8月28日115充血模型與貧血模型類似，不同處在于如何劃分業(yè)務(wù)邏輯：絕大多業(yè)務(wù)邏輯都應(yīng)該放在DO里(包括持久化邏輯)，而Service層很薄，僅僅封裝事務(wù)和少量邏輯，不和DAO層打交道。Service(事務(wù)封裝)DODAO優(yōu)點：符合OOService層很薄，只充當(dāng)Facade的角色，不和DAO打交道。第一百一十五頁，共四百八十九頁，2022年，8月28日116缺點：DAO和DO雙向依賴。如何劃分Service層邏輯和Domain層邏輯沒有確定的規(guī)則，取決與設(shè)計人員自己的理解。Service層封裝事務(wù)，須對所有的DO邏輯提供相應(yīng)的事務(wù)封裝方法，造成重定義所有的Domainlogic。Service的事務(wù)化封裝的意義等于把OO的Domainlogic轉(zhuǎn)換為過程的Service事務(wù)腳本。充血模型在domain層實現(xiàn)的OO在Service層又變成了面向過程。第一百一十六頁，共四百八十九頁，2022年，8月28日117脹血模型取消Service層，只剩下DO和DAO層，在DO的domainlogic上面封裝事務(wù)。DO(事務(wù)封裝，業(yè)務(wù)邏輯)DAO(RoR甚至合并為一層）

優(yōu)點：分層簡化符合OO缺點：service邏輯也強行放入DO，引起了DO不穩(wěn)定。DO暴露給web層過多的信息，可能引起不必要的耦合。第一百一十七頁，共四百八十九頁，2022年，8月28日118原則：業(yè)務(wù)對象封裝了內(nèi)在的業(yè)務(wù)邏輯，而應(yīng)用服務(wù)封裝了外在于業(yè)務(wù)對象的業(yè)務(wù)邏輯。第一百一十八頁，共四百八十九頁，2022年，8月28日119EJB到輕量級框架EJBPOJO（業(yè)務(wù)邏輯）+輕量級框架（[Hibernate、JDO、iBATIS]（持久化）、Spring（事務(wù)管理、安全））第一百一十九頁，共四百八十九頁，2022年，8月28日120EJBEJB：編寫分布式業(yè)務(wù)應(yīng)用程序的Java標(biāo)準(zhǔn)架構(gòu)。提供大量服務(wù)：聲明型事務(wù),EIB容器自動啟動、提交和回滾事務(wù)。業(yè)務(wù)邏輯能參與由遠(yuǎn)程客戶發(fā)起的分布式事務(wù)。提供聲明型安全，大部分情況下不再搖要編寫安全代碼求（bean部署描述符里的條目指定準(zhǔn)可以防問某個具體bean）。第一百二十頁，共四百八十九頁，2022年，8月28日121例：在兩個賬號間進行轉(zhuǎn)賬的服務(wù)。第一百二十一頁，共四百八十九頁，2022年，8月28日122第一百二十二頁，共四百八十九頁，2022年，8月28日123新設(shè)計是面向?qū)ο?、基于POJO,而非基于EJB的過程式。它使用構(gòu)建在JDBC上的持久層框架來訪問數(shù)據(jù)庫,并不直接使用JDBC。業(yè)務(wù)邏輯由POJOfacade而非會話bean進行封裝。事務(wù)由Spring框架而非EJB容器進行管理。業(yè)務(wù)邏輯向表現(xiàn)層返回實際的業(yè)務(wù)對象,而不是DTO。應(yīng)用程序通過將組件的依賴作為setter或構(gòu)造子參數(shù)傳入來進行組裝,而不是之前采用Java命名和目錄接口(JNDI)查詢的組件。由于該設(shè)計面向?qū)ο?并采用上述輕量級技術(shù),因此較之前看到的EJB版本對開發(fā)人員要友好。第一百二十三頁，共四百八十九頁，2022年，8月28日124基于輕量級框架設(shè)計的好處是，它提供事務(wù)和持久化時并不要求應(yīng)用程序類實現(xiàn)任何特殊接口。甚至當(dāng)應(yīng)用程序的類需要運行在事務(wù)里或是持久的時候，它們?nèi)允荘OJO，設(shè)計者可以繼續(xù)享受POJO的種種好處。第一百二十四頁，共四百八十九頁，2022年，8月28日125第一百二十五頁，共四百八十九頁，2022年，8月28日126面向?qū)ο蟮膬?yōu)點：整個設(shè)計更易理解和維護。它并不是一個無所不能的大型類,而是由大量小類組成,每個類只共有若干職責(zé)。此外,諸如Account、BankingTransaction和OverdraftPolicy類都與現(xiàn)實世界的概念對應(yīng),因此易于理解。其次,面向?qū)ο笤O(shè)汁也更易測試:所有類都能并且應(yīng)當(dāng)進行獨立的測試。EJB只能通過調(diào)用它的public方法如Transter進行測試,難度大。(只能測試p-blic方法暴露的復(fù)雜功能,無法測試其中簡單的部分）。面向?qū)ο笙笤O(shè)計更易擴展,它可使用設(shè)計模式，如Stategy和Template等。EJB風(fēng)格的過程式設(shè)計往往需耍修改核心代碼。第一百二十六頁，共四百八十九頁，2022年，8月28日127不適合用面向?qū)ο蟮膱龊希捍罅繑?shù)據(jù)集合的關(guān)系操作。以數(shù)據(jù)庫為中心的管理程序：這個領(lǐng)域所對應(yīng)的現(xiàn)實世界是一個面向關(guān)系的世界，表與表的關(guān)聯(lián)體現(xiàn)的是彼此的業(yè)務(wù)關(guān)系。復(fù)雜的SQL固然不好維護，但業(yè)務(wù)真是復(fù)雜到簡單的SQL都難以描述的程度，采用面向?qū)ο竺枋鰟t更加困難，維護也更困難，同時還損失了效率。比較大的事務(wù)。性能要求高的地方。（直接用Sql或者存儲過程；犧牲可維護性和可復(fù)用性）上層流程。第一百二十七頁，共四百八十九頁，2022年，8月28日128消除DTO第一百二十八頁，共四百八十九頁，2022年，8月28日129部署POJO程序第一百二十九頁，共四百八十九頁，2022年，8月28日130第一百三十頁，共四百八十九頁，2022年，8月28日131第一百三十一頁，共四百八十九頁，2022年，8月28日軟件架構(gòu)模式分析及其實際運用第一百三十二頁，共四百八十九頁，2022年，8月28日軟件架構(gòu)軟件架構(gòu)概論架構(gòu)的目標(biāo)架構(gòu)的種類軟件框架常見的架構(gòu)模式第一百三十三頁，共四百八十九頁，2022年，8月28日軟件架構(gòu)概論系統(tǒng)架構(gòu)是一個軟件系統(tǒng)從整體到部分的最高層次的劃分。一個系統(tǒng)通常是由元件組成的，而這些元件如何形成、相互之間如何發(fā)生作用，則是關(guān)于這個系統(tǒng)本身結(jié)構(gòu)的重要信息。詳細(xì)地說，就是要包括架構(gòu)元件（ArchitectureComponent）、聯(lián)結(jié)器（Connector）、任務(wù)流（Task-flow）。所謂架構(gòu)元素，也就是組成系統(tǒng)的核心"磚瓦"，而聯(lián)結(jié)器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預(yù)期結(jié)果，任務(wù)流則描述系統(tǒng)如何使用這些元件和聯(lián)結(jié)器完成某一項需求。第一百三十四頁，共四百八十九頁，2022年，8月28日建造一個系統(tǒng)所作出的最高層次的、以后難以更改的，商業(yè)的和技術(shù)的決定。在建造一個系統(tǒng)之前會有很多的重要決定需要事先作出，而一旦系統(tǒng)開始進行詳細(xì)設(shè)計甚至建造，這些決定就很難更改甚至無法更改。顯然，這樣的決定必定是有關(guān)系統(tǒng)設(shè)計成敗的最重要決定，必須經(jīng)過慎重的研究和考察。第一百三十五頁，共四百八十九頁，2022年，8月28日架構(gòu)的種類根據(jù)我們關(guān)注的角度不同，可以將架構(gòu)分成三種：邏輯架構(gòu)物理架構(gòu)系統(tǒng)架構(gòu)第一百三十六頁，共四百八十九頁，2022年，8月28日邏輯架構(gòu)軟件系統(tǒng)中元件之間的關(guān)系，比如用戶界面，數(shù)據(jù)庫，外部系統(tǒng)接口，商業(yè)邏輯元件等等。第一百三十七頁，共四百八十九頁，2022年，8月28日物理架構(gòu)軟件元件是怎樣放到硬件上的下圖描述了一個分布于北京和上海的分布式系統(tǒng)的物理架構(gòu)，圖中所有的元件都是物理設(shè)備，包括網(wǎng)絡(luò)分流器、代理服務(wù)器、WEB服務(wù)器、應(yīng)用服務(wù)器、報表服務(wù)器、整合服務(wù)器、存儲服務(wù)器、主機等等。第一百三十八頁，共四百八十九頁，2022年，8月28日系統(tǒng)架構(gòu)系統(tǒng)的非功能性特征，如可擴展性、可靠性、強壯性、靈活性、性能等。系統(tǒng)架構(gòu)的設(shè)計要求架構(gòu)師具備軟件和硬件的功能和性能的過硬知識，這一工作是架構(gòu)設(shè)計工作中最困難的工作。第一百三十九頁，共四百八十九頁，2022年，8月28日架構(gòu)的兩要素元件劃分和設(shè)計決定。邏輯元件：一個軟件系統(tǒng)中的元件首先是邏輯元件。這些邏輯元件如何放到硬件上，以及這些元件如何為整個系統(tǒng)的可擴展性、可靠性、強壯性、靈活性、性能等做出貢獻(xiàn)，是非常重要的信息。設(shè)計決定：進行軟件設(shè)計需要做出的決定中，必然會包括邏輯結(jié)構(gòu)、物理結(jié)構(gòu)，以及它們?nèi)绾斡绊懙较到y(tǒng)的所有非功能性特征。這些決定中會有很多是一旦作出，就很難更改的。基于數(shù)據(jù)庫的系統(tǒng)架構(gòu)：一般有多少個數(shù)據(jù)表，就會有多少頁的架構(gòu)設(shè)計文檔。比如一個中等的數(shù)據(jù)庫應(yīng)用系統(tǒng)通常含有一百個左右的數(shù)據(jù)表，這樣的一個系統(tǒng)設(shè)計通常需要有一百頁左右的架構(gòu)設(shè)計文檔。第一百四十頁，共四百八十九頁，2022年，8月28日從概念性架構(gòu)到實際架構(gòu)

就是多(Lessismore.)。--密斯·凡德羅概念性架構(gòu)是對系統(tǒng)設(shè)計的最初構(gòu)想。一般來說，實際的軟件架構(gòu)設(shè)計過程是，先進行概念性架構(gòu)的設(shè)計，把最關(guān)鍵的設(shè)計要素和交互機制確定下來，然后再考慮具體技術(shù)的運用，設(shè)計出實際架構(gòu)。第一百四十一頁，共四百八十九頁，2022年，8月28日架構(gòu)設(shè)計中的關(guān)鍵要素及解決策略策略是制勝的關(guān)鍵。--張明正，《擋不住的趨勢》最好的軟件開發(fā)人員都知道一個秘密：美的東西比丑的東西創(chuàng)建起來更廉價，也更快捷。--RobertC.Martin,《軟件之美》時間就是系統(tǒng)架構(gòu)的生命。--PhilippeKruchten方法產(chǎn)生于恐懼。面對時間緊迫的壓力，我們有理由質(zhì)疑那種不顧時間花銷、一味追求軟件架構(gòu)高質(zhì)量的做法。軟件架構(gòu)是軟件系統(tǒng)質(zhì)量的核心，必須足夠重視，但在不適當(dāng)?shù)臅r候“用時間換完美”會毀掉整個項目。架構(gòu)設(shè)計并非“好的就是成功的”，而是“適合的才是成功的”。第一百四十二頁，共四百八十九頁，2022年，8月28日方法論第一百四十三頁，共四百八十九頁，2022年，8月28日

AlistairCockburn的七條定理，總結(jié)為：溝通和反饋。RUP、XP重量之爭第一百四十四頁，共四百八十九頁，2022年，8月28日軟件架構(gòu)設(shè)計中的關(guān)鍵要素及解決策略：

關(guān)鍵要素

策略

----------------------------------------------- -----------------------1.是否遺漏了至關(guān)重要的非功能需求？

全面認(rèn)識需求。2.能否馴服數(shù)量巨大且頻繁變化的需求？

關(guān)鍵需求決定架構(gòu)。3.能否從容地設(shè)計軟件架構(gòu)的不同方面？

多視圖探尋架構(gòu)。4.是否及早驗證架構(gòu)方案并作出了調(diào)整？

及早驗證架構(gòu)。第一百四十五頁，共四百八十九頁，2022年，8月28日軟件架構(gòu)設(shè)計過程總覽一般的軟件過程：第一百四十六頁，共四百八十九頁，2022年，8月28日需求分析的幾個概念需求捕獲vs需求分析vs系統(tǒng)分析需求捕獲是獲取知識的過程，知識從無到有。需求分析是挖掘和整理知識的過程，它在已掌握知識的基礎(chǔ)上進行。系統(tǒng)分析？如果說需求分析致力于“做什么”，那么系統(tǒng)分析則涉及“怎么做”。軟件架構(gòu)師不必是需求捕獲專家，也不必是編寫《軟件需求規(guī)格說明書》的專家。但他一定應(yīng)在需求分類、需求折衷和需求變更的研究方面是專家，否則他和其他軟件架構(gòu)師相比，就輸在了“起跑線”上。第一百四十七頁，共四百八十九頁，2022年，8月28日概念性架構(gòu)設(shè)計概念性架構(gòu)設(shè)計的迭代方式：1.魯棒性分析；2.引入架構(gòu)模式；3.質(zhì)量屬性分析。第一百四十八頁，共四百八十九頁，2022年，8月28日魯棒性分析所謂魯棒性分析是這樣一種方法：通過分析用例規(guī)約中的事件流，識別出實現(xiàn)用例規(guī)定的功能所需的主要對象及其職責(zé)，形成以職責(zé)模型為主的初步設(shè)計。魯棒性分析是從功能需求向設(shè)計方案過度的第一步，所獲得的初步設(shè)計是一種理想化的職責(zé)模型，它的重點是識別組成軟件系統(tǒng)的高級職責(zé)塊、規(guī)劃它們之間的關(guān)系。魯棒性分析填補了分析和設(shè)計之間的鴻溝。魯棒圖包含三種元素：邊界對象、控制對象和實體對象。第一百四十九頁，共四百八十九頁，2022年，8月28日引入架構(gòu)模式較為經(jīng)典的幾種架構(gòu)模式：分層、MVC、微內(nèi)核、基于元模型的架構(gòu)、管道-過濾器等。第一百五十頁，共四百八十九頁，2022年，8月28日質(zhì)量屬性分析“屬性-場景-決策”表方法：第一百五十一頁，共四百八十九頁，2022年，8月28日細(xì)化架構(gòu)設(shè)計

架構(gòu)細(xì)化工作主要體現(xiàn)在基于五視圖方法進行架構(gòu)細(xì)化：

約束

↓

┌───────┐

領(lǐng)域模型->│基于五視圖方法│

關(guān)鍵需求->│

│->架構(gòu)方案

概念架構(gòu)->│進行架構(gòu)細(xì)化│

└───────┘

↑

經(jīng)驗第一百五十二頁，共四百八十九頁，2022年，8月28日第一百五十三頁，共四百八十九頁，2022年，8月28日邏輯架構(gòu)設(shè)計中，“發(fā)現(xiàn)通用機制”是應(yīng)被特別強調(diào)的。機制(Mechanism)是模式的實例。機制是特定上下文中重復(fù)出現(xiàn)的問題的特定解決方案。具有良好架構(gòu)的系統(tǒng)具備概念完整性。它通過對系統(tǒng)架構(gòu)建立一種清晰的認(rèn)識來發(fā)現(xiàn)通用的抽象和機制。利用這種共性使最終產(chǎn)生的系統(tǒng)結(jié)構(gòu)更為簡單。第一百五十四頁，共四百八十九頁，2022年，8月28日實現(xiàn)并驗證軟件架構(gòu)好的策略必須是一再求證、測試、發(fā)現(xiàn)瑕疵漏洞，另想途徑或方法來彌補策略不足，有時甚至得全盤放棄，重新策劃。--張明正，《擋不住的趨勢》架構(gòu)原型對功能性需求的實現(xiàn)非常有限，那么“架構(gòu)驗證”要驗證什么？答案是要驗證架構(gòu)對質(zhì)量屬性需求的支持程度，包括運行期質(zhì)量屬性和開發(fā)期質(zhì)量屬性。第一百五十五頁，共四百八十九頁，2022年，8月28日驗證架構(gòu)的兩種方法：原型法。對于項目型開發(fā)，常采用“原型法”。即對一組架構(gòu)設(shè)計決策在非功能需求方面的滿足程度進行驗證。該原型往往是演進型，而非拋棄型。框架法。對于產(chǎn)品型開發(fā)，采用“框架法”有更多優(yōu)點。該方法將架構(gòu)設(shè)計方案用框架的形式實現(xiàn)，并在此基礎(chǔ)上進行評估驗證。在框架實現(xiàn)后，在框架基礎(chǔ)上實現(xiàn)部分應(yīng)用的功能，即實現(xiàn)一個小的垂直原型，從而進行實際非功能測試和開發(fā)期質(zhì)量屬性評價。第一百五十六頁，共四百八十九頁，2022年，8月28日軟件框架什么是框架框架與架構(gòu)的區(qū)別常見的框架第一百五十七頁，共四百八十九頁，2022年，8月28日為什么要用框架因為軟件系統(tǒng)發(fā)展到今天已經(jīng)很復(fù)雜了，特別是服務(wù)器端軟件，設(shè)計到的知識，內(nèi)容，問題太多。在某些方面使用成熟的框架，可以避免重復(fù)做已有的基礎(chǔ)工作，而只需要集中精力完成系統(tǒng)的業(yè)務(wù)邏輯設(shè)計?？蚣芤话闶浅墒欤€(wěn)健的，可以處理系統(tǒng)很多細(xì)節(jié)問題，比如，事物理，安全性，數(shù)據(jù)流控制等問題?？蚣芤话愣冀?jīng)過很多人使用，所以結(jié)構(gòu)很好，所以擴展性也很好，而且它是不斷升級的，使用框架的開發(fā)者可以直接享受別人升級代碼帶來的好處?？蚣芤话闾幵诘蛯討?yīng)用平臺（如J2EE）和高層業(yè)務(wù)邏輯之間的中間層。第一百五十八頁，共四百八十九頁，2022年，8月28日159常見的JAVA框架EJBStrutsSpringHibernateIBatisJSFtapestryWAFTurbineCOCOONECHOJATOTCFExt…第一百五十九頁，共四百八十九頁，2022年，8月28日160.NET框架.NET框架是創(chuàng)建、部署和運行Web服務(wù)及其他應(yīng)用程序的一個環(huán)境。它包括三個主要部分：公共語言運行時、框架類和ASP.NET。.NET框架對Web站點的支持：ASP.NET在編寫Windows軟件（使用ATL/COM、MFC、VB或標(biāo)準(zhǔn)Win32）方面，與當(dāng)前創(chuàng)建應(yīng)用程序的方式相比.NET都具有的優(yōu)勢。第一百六十頁，共四百八十九頁，2022年，8月28日C++框架標(biāo)準(zhǔn)庫DinkumwareC++Library、RogueWaveStandardC++Library、SGISTL、STLportGUIMFC、QT、WxWindows、Fox、WTL、GTK、BCG、XtremeToolkit網(wǎng)絡(luò)通信ACE、StreamModule、SimpleSocket綜合P::Classes、ACDK-ArtefakturComponentDevelopmentKit、dlibC++library、ChilkatC++Libraries、C++PortableTypesLibrary(PTypes)、LFC其他庫Loki、ATL、FC++:TheFunctionalC++Library、FACT!、Crypto++第一百六十一頁，共四百八十九頁，2022年，8月28日BoostRegex正則表達(dá)式庫Spirit

LLparserframework，用C++代碼直接表達(dá)EBNFGraph圖組件和算法Lambda在調(diào)用的地方定義短小匿名的函數(shù)對象conceptcheck檢查泛型編程中的conceptMpl用模板實現(xiàn)的元編程框架Thread可移植的C++多線程庫、Python把C++類和函數(shù)映射到Python之中Pool內(nèi)存池管理smart_ptr智能指針第一百六十二頁，共四百八十九頁，2022年，8月28日XMLXerces、XMLBooster、PullParser、Xalan、CMarkup、libxml++

科學(xué)計算Blitz++、POOMA、MTL、CGAL游戲開發(fā)Audio/Video3DC++Programming Library、KlayGE龔敏敏、OGRE線程

C++Threads、ZThreads序列化

s11n、SimpleXMLPersistenceLibrary字符串

C++StrLibrary、CommonTextTransformationLibrary、GRETA第一百六十三頁，共四百八十九頁，2022年，8月28日164不同層次的模式架構(gòu)模式(ArchitecturalPattern)設(shè)計模式(DesignPattern)代碼模式(CodingPattern)第一百六十四頁，共四百八十九頁，2022年，8月28日區(qū)別：在于三種不同的模式存在于它們各自的抽象層次和具體層次。架構(gòu)模式是一個系統(tǒng)的高層次策略，涉及到大尺度的組件以及整體性質(zhì)。架構(gòu)模式的好壞可以影響到總體布局和框架性結(jié)構(gòu)。設(shè)計模式是中等尺度的結(jié)構(gòu)策略。這些中等尺度的結(jié)構(gòu)實現(xiàn)了一些大尺度組件的行為和它們之間的關(guān)系。模式的好壞不會影響到系統(tǒng)的總體布局和總體框架。設(shè)計模式定義出子系統(tǒng)或組件的微觀結(jié)構(gòu)。代碼模式是特定的范例和與特定語言有關(guān)的編程技巧。代碼模式的好壞會影響到一個中等尺度組件的內(nèi)部、外部的結(jié)構(gòu)或行為的底層細(xì)節(jié)，但不會影響到一個部件或子系統(tǒng)的中等尺度的結(jié)構(gòu)，更不會影響到系統(tǒng)的總體布局和大尺度框架。第一百六十五頁，共四百八十九頁，2022年，8月28日架構(gòu)模式(ArchitecturalPattern)軟件體系結(jié)構(gòu)通常被稱為架構(gòu)，指可以預(yù)制和可重構(gòu)的軟件框架結(jié)構(gòu)。架構(gòu)尚處在發(fā)展期，對于其定義，學(xué)術(shù)界尚未形成一個統(tǒng)一的意見，而不同角度的視點也會造成軟件體系結(jié)構(gòu)的不同理解。眾多軟件架構(gòu)概念都是圍繞“組成”和“決策”兩個視角展開的。第一百六十六頁，共四百八十九頁，2022年，8月28日Booch、Rumbaugh和Jacobson的定義架構(gòu)是一系列重要決策的集合，這些決策與以下內(nèi)容有關(guān)：軟件的組織，構(gòu)成系統(tǒng)的結(jié)構(gòu)元素及其接口的選擇，這些元素在相互協(xié)作中明確表現(xiàn)出的行為，這些結(jié)構(gòu)元素和行為元素進一步組合所構(gòu)成的更大規(guī)模的子系統(tǒng)，以及指導(dǎo)這一組織——包括這些元素及其接口、它們的協(xié)作和它們的組合——架構(gòu)風(fēng)格。IEEE610.12-1990軟件工程標(biāo)準(zhǔn)：架構(gòu)是以組件、組件之間的關(guān)系、組件與環(huán)境之間的關(guān)系為內(nèi)容的某一系統(tǒng)的基本組織結(jié)構(gòu)，以及指導(dǎo)上述內(nèi)容設(shè)計與演化的原理（Principle）。第一百六十七頁，共四百八十九頁，2022年，8月28日Garlan的定義架構(gòu)包括組件（Component）、連接件（Connector）和約束（Constrain）三大要素。組件可以是一組代碼（例如程序模塊），也可以是獨立的程序（例如數(shù)據(jù)庫服務(wù)器）。連接件可以是過程調(diào)用、管道和消息等，用于表示組件之間的相互關(guān)系?！凹s束”一般為對象連接時的規(guī)則，或指明構(gòu)件連接的形式和條件，例如，上層構(gòu)件可要求下層構(gòu)件的服務(wù)，反之不行；兩對象不得遞規(guī)地發(fā)送消息；代碼復(fù)制遷移的一致性約束；什么條件下此種連接無效等。Shaw的定義：“軟件系統(tǒng)的架構(gòu)將系統(tǒng)描述為計算組件及組件之間的交互”。架構(gòu)＝組件＋交互第一百六十八頁，共四百八十九頁，2022年，8月28日幾種典型的架構(gòu)模式系統(tǒng)軟件分層(Layer)管道和過濾器(PipesandFilters)黑板(Blackboard)開發(fā)分布式軟件經(jīng)紀(jì)人(Broker)客戶/服務(wù)器（Client/Server）點對點（PeertoPeer）交互軟件模型-視圖-控制器（Model-View-Controller）顯示-抽象-控制（Presentation-Abstraction-COntrol）第一百六十九頁，共四百八十九頁，2022年，8月28日其它面向?qū)ο箫L(fēng)格(ADT)基于消息廣播且面向圖形用戶界面的Chiron2風(fēng)格基于事件的隱式調(diào)用風(fēng)格(Event-based,ImplicitInv