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

1、1軟件架構(gòu)設(shè)計(jì)模式與實(shí)踐目錄軟件架構(gòu)視圖軟件生命周期與軟件架構(gòu)介紹架構(gòu)設(shè)計(jì)的GRASP模式質(zhì)量屬性驅(qū)動(dòng)架構(gòu)設(shè)計(jì)策略軟件架構(gòu)模式分析及其實(shí)際運(yùn)用架構(gòu)設(shè)計(jì)原則面向?qū)ο蟮脑O(shè)計(jì)原則架構(gòu)設(shè)計(jì)驗(yàn)證數(shù)據(jù)訪問(wèn)層設(shè)計(jì)（持久層設(shè)計(jì)）借鑒RUP中的設(shè)計(jì)流程領(lǐng)域模型及業(yè)務(wù)邏輯層在架構(gòu)設(shè)計(jì)中的實(shí)現(xiàn)設(shè)計(jì)模式本質(zhì)SOA的設(shè)計(jì)思想軟件架構(gòu)實(shí)踐軟件系統(tǒng)架構(gòu)實(shí)踐與剖析軟件系統(tǒng)開(kāi)始?jí)乃赖陌Y狀一個(gè)軟件系統(tǒng)開(kāi)始?jí)乃罆r(shí)表現(xiàn)的癥狀有:硬化Rigidity系統(tǒng)變得越來(lái)越難以變更,修復(fù)或增添新功能的代價(jià)高昂;脆弱Fragility對(duì)系統(tǒng)的任何哪怕是微小的變更都可能造成四處(甚至是與變更處沒(méi)有邏輯上的關(guān)聯(lián)之處J崩潰;綁死Immobility抽取

2、系統(tǒng)的任何部分用來(lái)復(fù)用都非常困難;膠著Viscosity以與原有設(shè)計(jì)保持一致的方式來(lái)對(duì)實(shí)施變更已經(jīng)非常困難,誘使開(kāi)發(fā)人員繞過(guò)它選擇容易但有害的途徑,其結(jié)果卻使系統(tǒng)死的更快。前言 什么是軟件架構(gòu)軟件架構(gòu)的概念很混亂。如果你問(wèn)五個(gè)不同的人，可能會(huì)得到五種不同的答案。 軟件架構(gòu)概念主要分為兩大流派：組成派：軟件架構(gòu) = 組件 + 交互。決策派：軟件架構(gòu) = 重要決策集。 組成派和決策派的概念相輔相成。 軟件架構(gòu)要層次化并隔離關(guān)注點(diǎn)復(fù)雜性是層次化的。 -人月神話 好的架構(gòu)設(shè)計(jì)必須把變化點(diǎn)錯(cuò)落有致地封裝到軟件系統(tǒng)的不同部分(即關(guān)注點(diǎn)分離)。 通過(guò)關(guān)注點(diǎn)分離，達(dá)到“系統(tǒng)中的一部分發(fā)生了變化，不會(huì)影響其他部

3、分”的目標(biāo)。 軟件單元的粒度：粒度最小的單元通常是“類”。 幾個(gè)類緊密協(xié)作形成“模塊”。 完成相對(duì)獨(dú)立的功能的多個(gè)模塊構(gòu)成了“子系統(tǒng)”。 多個(gè)子系統(tǒng)相互配合才能滿足一個(gè)完整應(yīng)用的需求，從而構(gòu)成了軟件“系統(tǒng)”。 一個(gè)大型企業(yè)往往使用多套系統(tǒng)，多套系統(tǒng)通過(guò)互操作形成“集成系統(tǒng)”。 軟件單元的粒度是相對(duì)的。同一個(gè)軟件單元，在不同場(chǎng)景下我們會(huì)以不同的粒度看待它。 架構(gòu)(Architecture)與框架(Framework)。框架只是一種特殊的軟件，框架也有架構(gòu)。 可以通過(guò)架構(gòu)框架化達(dá)到“架構(gòu)重用”的目的，如很多人都在用 Spring 框架提供的控制反轉(zhuǎn)和依賴注入來(lái)構(gòu)建自己的架構(gòu)。 軟件架構(gòu)的作用如果一

4、個(gè)項(xiàng)目的系統(tǒng)架構(gòu)(包括理論基礎(chǔ))尚未確定，就不應(yīng)該進(jìn)行此系統(tǒng)的全面開(kāi)發(fā)。- Barry Boehm,Engineering Context 一個(gè)缺陷充斥的系統(tǒng)，將始終是一個(gè)缺陷充斥的系統(tǒng)。- Timothy C. Lethbridge,面向?qū)ο筌浖こ?軟件架構(gòu)設(shè)計(jì)為什么這么難？因?yàn)樗强缭浆F(xiàn)實(shí)世界與計(jì)算機(jī)世界之間鴻溝的一座橋。軟件架構(gòu)設(shè)計(jì)要完成從面向業(yè)務(wù)到面向技術(shù)的轉(zhuǎn)換，在鴻溝上架起一座橋梁。 需求 - 架構(gòu)設(shè)計(jì) - 軟件架構(gòu) - 系統(tǒng)開(kāi)發(fā) - 軟件系統(tǒng)軟件架構(gòu)對(duì)新產(chǎn)品開(kāi)發(fā)的作用：上承業(yè)務(wù)目標(biāo)。下接技術(shù)決策。控制復(fù)雜性。先進(jìn)行架構(gòu)設(shè)計(jì)，后進(jìn)行詳細(xì)設(shè)計(jì)和編碼實(shí)現(xiàn)，符合“基于問(wèn)題深度分而治之”的

5、理念。組織開(kāi)發(fā)。軟件架構(gòu)方案在小組中間扮演了“橋梁”和“合作契約”的作用。利于迭代開(kāi)發(fā)和增量交付。以架構(gòu)為中心進(jìn)行開(kāi)發(fā)，為增量交付提供了良好的基礎(chǔ)。在架構(gòu)經(jīng)過(guò)驗(yàn)證之后，可以專注于功能的增量提交。提高質(zhì)量。 軟件產(chǎn)品線：指具有一組可管理的、公共特性的、軟件密集性系統(tǒng)的集合，這些系統(tǒng)滿足特定的市場(chǎng)需求或任務(wù)需求，并且按照預(yù)定義方式從一個(gè)公共的核心資產(chǎn)集開(kāi)發(fā)得到。 軟件產(chǎn)品線架構(gòu)：針對(duì)一個(gè)公司或組織內(nèi)的一系列產(chǎn)品而設(shè)計(jì)的通用架構(gòu)。 軟件架構(gòu)對(duì)軟件產(chǎn)品線開(kāi)發(fā)的作用：固化核心知識(shí)；提供可重用資產(chǎn)；縮短推出產(chǎn)品的周期；降低開(kāi)發(fā)和維護(hù)成本；提高產(chǎn)品質(zhì)量；支持批量定制； 架構(gòu)師應(yīng)當(dāng)為項(xiàng)目相關(guān)的不同角色而設(shè)計(jì)：

6、架構(gòu)師要為客戶負(fù)責(zé)，滿足他們的業(yè)務(wù)目標(biāo)和約束條件。架構(gòu)師要為用戶負(fù)責(zé)，滿足他們關(guān)心的功能需求和運(yùn)行期質(zhì)量屬性。架構(gòu)師必須顧及處于協(xié)作分工“下游”的開(kāi)發(fā)人員。架構(gòu)師必須考慮“周邊”的管理人員，為他們進(jìn)行分工管理、協(xié)調(diào)控制和評(píng)估監(jiān)控等工作提供清晰的基礎(chǔ)。 軟件架構(gòu)視圖讓設(shè)計(jì)建模更明白、更有效張?jiān)瀑F2010-05-21“系統(tǒng)架構(gòu)圖”？架構(gòu)設(shè)計(jì)的多重視圖從根本上來(lái)說(shuō)是因?yàn)樾枨蠓N類的復(fù)雜性所致。比如一個(gè)媒體發(fā)布系統(tǒng)：功能需求：用戶可以通過(guò)瀏覽器瀏覽媒體的發(fā)布。據(jù)此初步設(shè)計(jì)出采用瀏覽器插件的方案；約束條件：不能影響用戶瀏覽器的安全性；細(xì)化設(shè)計(jì)方案，需要對(duì)插件進(jìn)行認(rèn)證，自動(dòng)判別客戶端是否存在，及版本比較；自

7、動(dòng)下載注冊(cè)等。使用期質(zhì)量屬性：為保證瀏覽的流暢，應(yīng)減少中間等待的時(shí)間，因此應(yīng)對(duì)下一步需使用的媒體做預(yù)測(cè)等。制作發(fā)布期的質(zhì)量保證：保證在遇到較大的媒體時(shí)能保持瀏覽的流暢，應(yīng)在發(fā)布時(shí)將視頻等流式化。軟件系統(tǒng)的需求種類復(fù)雜什么是軟件架構(gòu)視圖 個(gè)架構(gòu)視圖是對(duì)于從某一視角或某一點(diǎn)上看到的系統(tǒng)所做的簡(jiǎn)化描述，描述中涵蓋了系統(tǒng)的某一特定方面，而省略了于此方面無(wú)關(guān)的實(shí)體。架構(gòu)要涵蓋的內(nèi)容和決策太多了，超過(guò)了人腦“一蹴而就”的能力范圍，因此采用“分而治之”的辦法從不同視角分別設(shè)計(jì)；同時(shí)，也為軟件架構(gòu)的理解、交流和歸檔提供了方便。多視圖方法是軟件架構(gòu)歸檔的方法，更是指導(dǎo)我們進(jìn)行架構(gòu)設(shè)計(jì)的思維方法。邏輯架構(gòu)邏輯架構(gòu)

8、關(guān)注功能。其設(shè)計(jì)著重考慮功能需求。開(kāi)發(fā)架構(gòu)開(kāi)發(fā)架構(gòu)關(guān)注程序包。其設(shè)計(jì)著重考慮開(kāi)發(fā)期質(zhì)量屬性，如可擴(kuò)展性、可重用性、可移植性、易理解性和易測(cè)試性等。運(yùn)行架構(gòu)運(yùn)行架構(gòu)關(guān)注進(jìn)程、線程、對(duì)象等運(yùn)行時(shí)概念，以及相關(guān)的并發(fā)、同步、通信等問(wèn)題。其設(shè)計(jì)著重考慮運(yùn)行期質(zhì)量屬性，例如性能、可伸縮性、持續(xù)可用性和安全性等。物理架構(gòu)物理架構(gòu)關(guān)注軟件系統(tǒng)最終如何安裝或部署到物理機(jī)器。其設(shè)計(jì)著重考慮“安裝和部署需求”。以及如何部署機(jī)器和網(wǎng)絡(luò)來(lái)配合軟件系統(tǒng)的可靠性、可伸縮性等要求。數(shù)據(jù)架構(gòu)數(shù)據(jù)架構(gòu)關(guān)注持久化數(shù)據(jù)的存儲(chǔ)方案。設(shè)計(jì)著重考慮“數(shù)據(jù)需求”。 關(guān)系邏輯視圖。邏輯視圖不僅關(guān)注用戶可見(jiàn)的功能，還包括為實(shí)現(xiàn)用戶功能而必須提

9、供的“輔助功能模塊”；它們可能是邏輯層、功能模塊等。開(kāi)發(fā)視圖。開(kāi)發(fā)視圖關(guān)注程序包，不僅包括要編寫(xiě)的源程序，還包括可以直接使用的第三方SDK和現(xiàn)成框架、類庫(kù)，以及開(kāi)發(fā)的系統(tǒng)將運(yùn)行于其上的系統(tǒng)軟件或中間件。開(kāi)發(fā)視圖和邏輯視圖之間可能存在一定的映射關(guān)系：比如邏輯層一般會(huì)映射到多個(gè)程序包等。運(yùn)行視圖。和開(kāi)發(fā)視圖的關(guān)系：開(kāi)發(fā)視圖一般偏重程序包在編譯時(shí)期的靜態(tài)依賴關(guān)系，而這些程序運(yùn)行起來(lái)之后會(huì)表現(xiàn)為對(duì)象、線程、進(jìn)程，運(yùn)行視圖比較關(guān)注的正是這些運(yùn)行時(shí)單元的交互問(wèn)題。物理視圖。和運(yùn)行視圖的關(guān)系：運(yùn)行視圖特別關(guān)注目標(biāo)程序的動(dòng)態(tài)執(zhí)行情況，而物理視圖重視目標(biāo)程序的靜態(tài)位置問(wèn)題；物理視圖是綜合考慮軟件系統(tǒng)和整個(gè)IT系

10、統(tǒng)相互影響的架構(gòu)視圖。 軟件生命周期與軟件架構(gòu)介紹23軟件架構(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)師能力要求：一、系統(tǒng)架構(gòu)相關(guān)的知識(shí)和經(jīng)驗(yàn)。二、很強(qiáng)的自學(xué)能力、分析能力、解決問(wèn)題的能力。三、寫(xiě)作、溝通表達(dá)、培訓(xùn)。24角色軟件架構(gòu)師Software Architect定義主導(dǎo)系統(tǒng)全局分析設(shè)計(jì)和實(shí)施、負(fù)責(zé)軟件構(gòu)架和關(guān)鍵技術(shù)決策的角色25職責(zé)領(lǐng)導(dǎo)與協(xié)調(diào)整個(gè)項(xiàng)目中

11、的技術(shù)活動(dòng)（分析、設(shè)計(jì)和實(shí)施等）推動(dòng)主要的技術(shù)決策，并最終表達(dá)為軟件構(gòu)架確定和文檔化系統(tǒng)的相對(duì)構(gòu)架而言意義重大的方面，包括系統(tǒng)的需求、設(shè)計(jì)、實(shí)施和部署等“視圖”確定設(shè)計(jì)元素的分組以及這些主要分組之間的接口為技術(shù)決策提供規(guī)則，平衡各類涉眾的不同關(guān)注點(diǎn)，化解技術(shù)風(fēng)險(xiǎn)，并保證相關(guān)決定被有效的傳達(dá)和貫徹理解、評(píng)價(jià)并接收系統(tǒng)需求評(píng)價(jià)和確認(rèn)軟件架構(gòu)的實(shí)現(xiàn)26專業(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)域

12、都有經(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)目成員的信任。27以目標(biāo)導(dǎo)向和主動(dòng)的方式來(lái)不帶任何感情色彩地關(guān)注項(xiàng)目結(jié)果，構(gòu)架師應(yīng)當(dāng)是項(xiàng)目背后的技術(shù)推動(dòng)力，而非構(gòu)想者或夢(mèng)想家（追求完美）精通構(gòu)架設(shè)計(jì)的理論、實(shí)踐和工具，并掌握多種參考構(gòu)架、主要的可重用構(gòu)架機(jī)制和模式。具備系統(tǒng)設(shè)計(jì)員的所有技能，但涉及面更廣、抽象級(jí)別更高。28軟件架構(gòu)師的知識(shí)體系軟件架構(gòu)師作為整個(gè)軟件系統(tǒng)結(jié)構(gòu)的總設(shè)計(jì)師，其知識(shí)體系、技能和經(jīng)驗(yàn)決定了軟件系統(tǒng)的可靠性、安全性、可維護(hù)

13、性、可擴(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ù)等方面，而軟件架構(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ì)低些。29成為一名合格的軟件架構(gòu)師必須具備的知識(shí)信息系統(tǒng)綜合知識(shí)體系軟件架構(gòu)知識(shí)體系30？MFC，MSF，MOF，RUP

14、，J2EE，Spring，SOA，JUnit，ORM，.NetMVC，UML，XML，Corba，MDA，MDD，Web-ServiceRSS，Web2.0，AJAX，Serverlet，HibernateIOC， AOPRuby On RailsRupBPELWorkflow EngineLBSOracleCMMIMQ31軟件架構(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ì)

15、方案的正確性32軟件架構(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)行維護(hù)等。深入掌握1-2種主流技術(shù)平臺(tái)上開(kāi)發(fā)系統(tǒng)的方法。了解多種應(yīng)用系統(tǒng)的結(jié)構(gòu)。了解架構(gòu)設(shè)計(jì)領(lǐng)域的主要理論、流派、框架。33軟件架構(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)。34軟件架構(gòu)師的思維方式基于框架的思維架構(gòu)設(shè)計(jì)的層次（Enterprise， Application， etc）IT 的生命周期（What， Why， W

16、here， How， When， etc）成功經(jīng)驗(yàn)以及方法論的指導(dǎo)合理把握技術(shù)細(xì)節(jié)把握各個(gè)層次應(yīng)有的內(nèi)容合理忽略不應(yīng)有的技術(shù)細(xì)節(jié)35軟件架構(gòu)師的思維方式風(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)秀的方案注意：并不存在通用的設(shè)計(jì)方法。我們認(rèn)為，給定的某種固定的方法總是會(huì)顧此失彼，而且這種不平衡性不太容易覺(jué)察。如果給定的某種方法所注重的方面與系統(tǒng)需求不吻合，則這種方法就會(huì)將設(shè)計(jì)引入歧途。所以我們給出的是一些技巧，任何一次設(shè)計(jì)過(guò)程，都需要設(shè)計(jì)師仔細(xì)分析系統(tǒng)的需求和相關(guān)的約束條件，靈活運(yùn)用眾多的設(shè)計(jì)

17、技巧，針對(duì)不同的設(shè)計(jì)方案進(jìn)行取舍，做出合理的決策。36為了有效地控制設(shè)計(jì)工作的復(fù)雜性，一般把設(shè)計(jì)活動(dòng)分為總體設(shè)計(jì)和詳細(xì)設(shè)計(jì)兩個(gè)層次。總體設(shè)計(jì)主要關(guān)注于體系結(jié)構(gòu)和接口這些全局性的內(nèi)容，而詳細(xì)設(shè)計(jì)主要關(guān)注于每個(gè)模塊內(nèi)部的數(shù)據(jù)結(jié)構(gòu)和算法。至于數(shù)據(jù)，則在設(shè)計(jì)的各個(gè)層次都會(huì)涉及。軟件設(shè)計(jì)是一個(gè)迭代的過(guò)程，是一個(gè)逐步細(xì)化和求精的過(guò)程。因此，總體設(shè)計(jì)和詳細(xì)設(shè)計(jì)之間的劃分并不是絕對(duì)的。哪些是總體設(shè)計(jì)任務(wù)，哪些是詳細(xì)設(shè)計(jì)任務(wù)，取決于設(shè)計(jì)師對(duì)于整個(gè)項(xiàng)目的把握，并沒(méi)有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)。設(shè)計(jì)師在設(shè)計(jì)時(shí)實(shí)際是在做一系列的設(shè)計(jì)決策，來(lái)滿足系統(tǒng)的行為目標(biāo)，質(zhì)量目標(biāo)和開(kāi)發(fā)目標(biāo)。如果一個(gè)結(jié)構(gòu)對(duì)于完成這些目標(biāo)非常重要，則它是構(gòu)架的

18、一部分。相反，如果它可以留到以后再完善，則它不是構(gòu)架的組成部分。因此，總的說(shuō)來(lái)，一個(gè)設(shè)計(jì)是不是屬于構(gòu)架設(shè)計(jì)，要看你當(dāng)前的設(shè)計(jì)目標(biāo)。37管理陷阱隨著管理性責(zé)任的增加，你所從事技術(shù)性工作的時(shí)間就會(huì)顯著減少。這樣，因?yàn)樵谕瓿杉夹g(shù)性任務(wù)和保持職業(yè)技能上花費(fèi)時(shí)間的減少，你可能會(huì)失去技術(shù)優(yōu)勢(shì)。軟件架構(gòu)師和管理者有很大的差異：軟件架構(gòu)師是直接的技術(shù)貢獻(xiàn)者；而管理者則是通過(guò)協(xié)調(diào)其他人員的活動(dòng)來(lái)間接做出貢獻(xiàn)。他們往往一起協(xié)作，構(gòu)成高效的管理團(tuán)隊(duì)。以經(jīng)驗(yàn)看，把兩者結(jié)合起來(lái)卻不能長(zhǎng)久地工作。作為一名軟件架構(gòu)師，如果你已經(jīng)建立起個(gè)人的職業(yè)原則的話，就有可能避免成為管理者。架構(gòu)和設(shè)計(jì)應(yīng)該做到何種程度軟件架構(gòu)必須設(shè)計(jì)到“

19、能為開(kāi)發(fā)人員提供足夠的指導(dǎo)和限制”的程度。分而治之的兩種方式分而治之的緣由：?jiǎn)栴}太復(fù)雜了，超出了人們能夠“一蹴而就”的范圍。（接口和實(shí)現(xiàn)分離）一、先不把問(wèn)題研究得那么深，那么細(xì)，淺嘗輒止，見(jiàn)好就收。這種分而治之的方式稱為“按問(wèn)題深度分而治之”。二、先不研究整個(gè)問(wèn)題，而是研究問(wèn)題的一部分，分割問(wèn)題。這種分而治之的方式稱為“按問(wèn)題廣度分而治之”。（比如展現(xiàn)層、業(yè)務(wù)層和數(shù)據(jù)層的開(kāi)發(fā)）39隨著軟件設(shè)計(jì)工作越來(lái)越復(fù)雜，將架構(gòu)設(shè)計(jì)和詳細(xì)設(shè)計(jì)分離已成為普遍的做法。將設(shè)計(jì)分為架構(gòu)設(shè)計(jì)和詳細(xì)設(shè)計(jì)，是對(duì)“按問(wèn)題深度分而治之”思想的運(yùn)用。 所謂架構(gòu)設(shè)計(jì)，就是關(guān)于如何構(gòu)建軟件的一些最重要的設(shè)計(jì)決策;詳細(xì)設(shè)計(jì)針對(duì)每個(gè)部

20、分的內(nèi)部進(jìn)行設(shè)計(jì)?？梢赃@么說(shuō)，軟件架構(gòu)設(shè)計(jì)應(yīng)當(dāng)解決的是全局性的、涉及不同“局部”之間交互的設(shè)計(jì)問(wèn)題，而不同“局部”的設(shè)計(jì)由后續(xù)的詳細(xì)設(shè)計(jì)負(fù)責(zé)。40面對(duì)“技術(shù)復(fù)雜性”和“管理復(fù)雜性”這樣的雙重困難，以架構(gòu)為中心的開(kāi)發(fā)方法是有效的途徑：一方面：“軟件系統(tǒng)的架構(gòu)涵蓋了整個(gè)系統(tǒng)，盡管架構(gòu)的有些部分可能只有一寸深”。構(gòu)造一個(gè)具有一定抽象層次的解決方案，而不是將所有細(xì)節(jié)統(tǒng)統(tǒng)展開(kāi)，從而有效地控制了“技術(shù)復(fù)雜性”。沒(méi)有“把問(wèn)題研究那么深、那么細(xì)”，屬于“按問(wèn)題深度分而治之”41另一方面，因?yàn)椤凹軜?gòu)中包含了關(guān)于各元素應(yīng)如何彼此相關(guān)的信息”，從而可以把不同模塊分配給不同小組分頭開(kāi)發(fā)，而軟件架構(gòu)設(shè)計(jì)方案在這些小組中

21、間扮演“橋梁”和“合作契約”的作用。每個(gè)小組的工作覆蓋了“整個(gè)問(wèn)題的一部分”，各小組之間可以互相獨(dú)立地進(jìn)行并行工作，這種“分割問(wèn)題，各個(gè)擊破”的策略，屬于“按問(wèn)題廣度分而治之”。這樣一來(lái)，模塊的技術(shù)細(xì)節(jié)被局部化到了小組內(nèi)部，內(nèi)部的細(xì)節(jié)不會(huì)成為小組間協(xié)作溝通的主要內(nèi)容，理順了溝通的層次。另外，對(duì)“人盡其才”也有好處，不同小組的成員需要精通的技術(shù)各不相同。例如，用戶界面層、數(shù)據(jù)管理層、系統(tǒng)交互層。42架構(gòu)要進(jìn)行到什么程度軟件架構(gòu)是團(tuán)隊(duì)開(kāi)發(fā)的基礎(chǔ)，應(yīng)明確規(guī)定后期分頭開(kāi)發(fā)所必須的公共設(shè)計(jì)約定，為分頭開(kāi)發(fā)提供足夠的指導(dǎo)和限制。另一方面，具體的架構(gòu)設(shè)計(jì)程度還會(huì)因軟件項(xiàng)目的不同而不同。架構(gòu)設(shè)計(jì)對(duì)軟件的不同部

22、分的設(shè)計(jì)程度并不是整齊劃一的。(通信機(jī)制、持久化機(jī)制、消息機(jī)制等對(duì)應(yīng)的公共模塊；具體的業(yè)務(wù)功能模塊在架構(gòu)設(shè)計(jì)中往往設(shè)計(jì)程度不深。）歸納：由于項(xiàng)目的不同、開(kāi)發(fā)團(tuán)隊(duì)情況的不同，軟件架構(gòu)的設(shè)計(jì)程度會(huì)有不同;軟件架構(gòu)應(yīng)當(dāng)為開(kāi)發(fā)人員提供足夠的指導(dǎo)和限制。43 高來(lái)高去式架構(gòu)設(shè)計(jì)的癥狀 不能為開(kāi)發(fā)人員提供足夠的指導(dǎo)和限制的那種架構(gòu)設(shè)計(jì)方案。高來(lái)高去式架構(gòu)設(shè)計(jì)現(xiàn)象極為普遍，危害：缺少來(lái)自架構(gòu)的足夠的指導(dǎo)和限制，開(kāi)發(fā)人員在進(jìn)入分頭開(kāi)發(fā)階段之后會(huì)碰到很多問(wèn)題，并且容易造成管理混亂，溝通和協(xié)作效率低；對(duì)軟件質(zhì)量非常關(guān)鍵的全局性設(shè)計(jì)決定被拖延到分頭開(kāi)發(fā)期間草率決定；沒(méi)有完成化解重大技術(shù)風(fēng)險(xiǎn)的職責(zé)；團(tuán)隊(duì)成員對(duì)架構(gòu)師意

23、見(jiàn)大，團(tuán)隊(duì)士氣受到打擊。44癥狀一：缺失重要架構(gòu)視圖。給團(tuán)隊(duì)的不同角色提供指導(dǎo)。癥狀二：架構(gòu)設(shè)計(jì)方案停留在概念性架構(gòu)的層面，全局性的設(shè)計(jì)決策最后由具體開(kāi)發(fā)人員從局部視角考慮并確定下來(lái)，造成技術(shù)和管理上的種種問(wèn)題。癥狀三：名不副實(shí)的分層架構(gòu)。對(duì)各層之間交互接口和交互機(jī)制的設(shè)計(jì)嚴(yán)重不足。4546架構(gòu)設(shè)計(jì)的GRASP模式47484950515253545556575859606162636465質(zhì)量屬性驅(qū)動(dòng)架構(gòu)設(shè)計(jì)策略 軟件質(zhì)量及質(zhì)量模型軟件質(zhì)量是一個(gè)復(fù)雜的概念，不同的人從不同的角度來(lái)看軟件質(zhì)量問(wèn)題，會(huì)有不同的理解。從用戶的角度看，質(zhì)量就是滿足客戶的需求；從開(kāi)發(fā)者的角度看，質(zhì)量就是與需求說(shuō)明保持一致

24、；從產(chǎn)品的角度看，質(zhì)量就是產(chǎn)品的內(nèi)在特點(diǎn)；從價(jià)值的角度看，質(zhì)量就是客戶是否愿意購(gòu)買(mǎi)。在軟件項(xiàng)目開(kāi)發(fā)過(guò)程中，項(xiàng)目經(jīng)理眼中的質(zhì)量就是能“令人滿意”地工作以完成預(yù)期功能的軟件產(chǎn)品。所謂“令人滿意”，包括功能、性能、接口需求及其他指標(biāo)，如可靠性、可維護(hù)性、可復(fù)用性和正確性。然而在實(shí)際工作中，一旦出現(xiàn)問(wèn)題時(shí)，項(xiàng)目管理人員必須權(quán)衡利弊，作出取舍，在滿足某一個(gè)指標(biāo)的同時(shí)，犧牲另外一個(gè)或幾個(gè)指標(biāo)。比如為了按期交貨，需對(duì)軟件功能進(jìn)行分類，在第一個(gè)版本中實(shí)現(xiàn)優(yōu)先級(jí)較高的功能，在第二個(gè)版本中實(shí)現(xiàn)優(yōu)先級(jí)較低的功能。因此，項(xiàng)目經(jīng)理需要一個(gè)對(duì)其工作有指導(dǎo)意義的質(zhì)量模型和度量方法。該模型一方面可以幫助項(xiàng)目經(jīng)理生產(chǎn)出符合標(biāo)準(zhǔn)

25、的軟件產(chǎn)品，另一方面幫助項(xiàng)目經(jīng)理識(shí)別可能影響產(chǎn)品質(zhì)量的風(fēng)險(xiǎn)。為什么那么多軟件產(chǎn)品需要重新設(shè)計(jì)？ 難以維護(hù)？ 運(yùn)行速度太慢？ 穩(wěn)定性差？ 無(wú)法進(jìn)行功能擴(kuò)展？ 易遭受安全攻擊？ 忽視包括質(zhì)量屬性需求在內(nèi)的非功能需求是致命的。 質(zhì)量屬性分為： 運(yùn)行期質(zhì)量屬性 開(kāi)發(fā)期質(zhì)量屬性 各類需求架構(gòu)設(shè)計(jì)的不同影響 高可移植性對(duì)硬件和平臺(tái)相關(guān)特性進(jìn)行封裝、 隔離 高性能精心規(guī)劃職責(zé)模型在質(zhì)量屬性方面需求折衷質(zhì)量屬性分析的位置 質(zhì)量屬性分析是概念性架構(gòu)設(shè)計(jì)的重要步驟。 通過(guò)質(zhì)量屬性分析，制定出滿足非功能需求的高層設(shè)計(jì)決策。 質(zhì)量屬性分析所處的位置 如圖所示 ”屬性-場(chǎng)景-決策”表法 運(yùn)用“關(guān)鍵需求決定架構(gòu)”的策略，

26、使質(zhì)量屬性分析的“輸入”集中到關(guān)鍵質(zhì)量屬性需求。 “屬性-場(chǎng)景-決策”表方法提倡通過(guò)一組具體場(chǎng)景將要達(dá)到的質(zhì)量屬性需求目標(biāo)細(xì)化，再根據(jù)場(chǎng)景制定架構(gòu)決策。 “屬性-場(chǎng)景-決策“表法“屬性-場(chǎng)景-決策”表法的好處: 可操作性強(qiáng)。質(zhì)量熟悉需求是籠統(tǒng)的目標(biāo)，而一組質(zhì)量場(chǎng)景使之明確化。 避免過(guò)度設(shè)計(jì)。借助“屬性-場(chǎng)景-決策”表對(duì)質(zhì)量場(chǎng)景進(jìn)行評(píng)估，通過(guò)權(quán)衡場(chǎng)景發(fā)生的概率和遺漏它的代價(jià)，決定是否應(yīng)滿足該場(chǎng)景的要求。 便于系統(tǒng)升級(jí)時(shí)參考。 例：可擴(kuò)展性質(zhì)量屬性運(yùn)用“屬性-場(chǎng)景-決策”表方法，細(xì)化PM Tool的可擴(kuò)展性需求，制定架構(gòu)決策，如下表所示： 非功能需求對(duì)軟件架構(gòu)的影響比功能需求更大。 “屬性-場(chǎng)景-

27、決策”表可以幫助軟件架構(gòu)師以一種更透明、更可操作的方式完成從質(zhì)量屬性需求到質(zhì)量場(chǎng)景的細(xì)化，最終根據(jù)具體的場(chǎng)景有針對(duì)性地設(shè)計(jì)架構(gòu)決策。 架構(gòu)的目標(biāo)正確性correctness可靠性（Reliable）：軟件系統(tǒng)對(duì)于用戶的商業(yè)經(jīng)營(yíng)和管理來(lái)說(shuō)極為重要，因此軟件系統(tǒng)必須非?？煽?。健壯性robustness安全性（Secure） ：軟件系統(tǒng)所承擔(dān)的交易的商業(yè)價(jià)值極高，系統(tǒng)的安全性非常重要?？缮炜s性（Scalable） ：軟件必須能夠在用戶的使用率、用戶的數(shù)目增加很快的情況下，保持合理的性能。只有這樣，才能適應(yīng)用戶的市場(chǎng)擴(kuò)展得可能性?？啥ㄖ苹–ustomizable） ：同樣的一套軟件，可以根據(jù)客戶群的

28、不同和市場(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ò)展可復(fù)用性reusability可維護(hù)性（Maintainable）：軟件系統(tǒng)的維護(hù)包括兩方面，一是排除現(xiàn)有的錯(cuò)誤，二是將新的軟件需求反映到現(xiàn)有系統(tǒng)中去。一個(gè)易于維護(hù)的系統(tǒng)可以有效地降低技術(shù)支持的花費(fèi)。兼容性compatibility可移植性portability易用性ease of use高效性efficiencytimeliness,economy and functionality客戶體驗(yàn)（Customer Experience）：軟件系統(tǒng)必

29、須易于使用。市場(chǎng)時(shí)機(jī)（Time to Market）：軟件用戶要面臨同業(yè)競(jìng)爭(zhēng)，軟件提供商也要面臨同業(yè)競(jìng)爭(zhēng)。以最快的速度爭(zhēng)奪市場(chǎng)先機(jī)非常重要。86軟件可維護(hù)性重型和輕型方法重型方法：偏重于計(jì)劃、過(guò)程和中間產(chǎn)物敏捷方法：更加看重人和溝通。人和溝通永遠(yuǎn)是第一位的，而計(jì)劃、過(guò)程和中間產(chǎn)物，只是保證溝通、實(shí)現(xiàn)目標(biāo)的手段。并非計(jì)劃、過(guò)程、中間產(chǎn)物不重要，但不能本末倒置。評(píng)判軟件成功的標(biāo)準(zhǔn)：很多。對(duì)敏捷方法：首先在于交付可用的軟件。為了保證軟件的可用性，需求是根本。對(duì)于架構(gòu)設(shè)計(jì)工作，從需求出發(fā)來(lái)設(shè)計(jì)架構(gòu)，是保證軟件可用性的基本的保證。 如何開(kāi)始架構(gòu)設(shè)計(jì)工作考慮的平臺(tái)、語(yǔ)言、開(kāi)發(fā)環(huán)境、數(shù)據(jù)庫(kù)等誤區(qū)：架構(gòu)設(shè)計(jì)就

30、是寫(xiě)一些空話，套話。誤區(qū)：對(duì)與客戶具體情況密切相關(guān)的問(wèn)題卻未系統(tǒng)考慮。IT界的技術(shù)層出不窮，面對(duì)著如此之多的技術(shù)、平臺(tái)、框架、函數(shù)庫(kù)，我們?nèi)绾芜x擇一組適合軟件的技術(shù)？要針對(duì)需求設(shè)計(jì)架構(gòu)。每個(gè)客戶都有自身特點(diǎn)，如何才能夠設(shè)計(jì)出符合客戶利益的架構(gòu)？軟件中往往都充斥著眾多的問(wèn)題，在一開(kāi)始就把所有的問(wèn)題都想清楚往往很難做到，但是如果不解決問(wèn)題，風(fēng)險(xiǎn)又居高不下。架構(gòu)設(shè)計(jì)就是鋪設(shè)軟件的主管道。根據(jù)什么來(lái)制定主管道的粗細(xì)、路徑等因素？是根據(jù)城市的人口、地理位置、水源等因素。對(duì)應(yīng)到軟件設(shè)計(jì)，城市的各因素就是軟件中的各種需求：功能需求、非功能需求、變化案例等。例：城市中自來(lái)水管的架設(shè)是一項(xiàng)非常的復(fù)雜的工程。為了

31、需要滿足每家每戶的需要，自來(lái)水管組成了一個(gè)龐大的網(wǎng)絡(luò)。在這樣一個(gè)復(fù)雜的網(wǎng)絡(luò)中，如何完成鋪設(shè)的任務(wù)呢。一般的做法是，先找出問(wèn)題的根源，也就是水的源頭。從水源鋪設(shè)一條管道通至城市，然后根據(jù)城市的區(qū)域劃分，設(shè)計(jì)出主管道，剩下的就是使用的問(wèn)題了，每家每戶的管道最終都是連到主管道上的。因此，雖然自來(lái)水網(wǎng)絡(luò)龐大復(fù)雜。但是真正的主管道是比較簡(jiǎn)單的。一般來(lái)說(shuō)，功能需求決定業(yè)務(wù)架構(gòu)、非功能需求決定技術(shù)架構(gòu)，變化案例決定架構(gòu)的范圍。功能需求決定軟件能夠做些什么。我們需要根據(jù)業(yè)務(wù)上的需求來(lái)設(shè)計(jì)業(yè)務(wù)架構(gòu)，以使得未來(lái)的軟件能夠滿足客戶的需要。非功能需求定義了性能、效率上的一些約束、規(guī)則。而我們的技術(shù)架構(gòu)要能夠滿足這些約

32、束和規(guī)則。變化案例是對(duì)未來(lái)可能發(fā)生的變化的一個(gè)估計(jì)，結(jié)合功能需求和非功能需求，我們就可以確定一個(gè)需求的范圍，進(jìn)而確定一個(gè)架構(gòu)的范圍。例：一個(gè)字處理軟件，功能需求可以簡(jiǎn)單概括為格式化用戶輸入的文字，非功能需求可能是格式化大小為1000K的一段文字的處理速度不能低于10S，變化案例可能是推出多種語(yǔ)言版本。則在設(shè)計(jì)業(yè)務(wù)架構(gòu)時(shí)，我們會(huì)集中于如何表示文字、圖象、媒體等要素，此外需要有另外的技術(shù)架構(gòu)來(lái)處理速度問(wèn)題，比如緩沖技術(shù)，對(duì)于變化案例，我們也要考慮相應(yīng)的架構(gòu)，比如把字體獨(dú)立于程序包的設(shè)計(jì)。架構(gòu)設(shè)計(jì)的兩項(xiàng)工作分析：分析是分析需求設(shè)計(jì)：設(shè)計(jì)軟件的大致結(jié)構(gòu)。很多方法論分離二者，其實(shí)無(wú)一定的界限，做分析的時(shí)

33、候會(huì)想到如何設(shè)計(jì)，而思考如何設(shè)計(jì)反過(guò)來(lái)又會(huì)影響分析的效果?？梢哉f(shuō)，兩者間是相互聯(lián)系和不斷迭代的。需求與架構(gòu)都應(yīng)迭代進(jìn)行一點(diǎn)一點(diǎn)的作需求。這種做法在那些需求變化快的項(xiàng)目中尤其適用。由于我們采用的流程是一種迭代式的流程，這里我們將會(huì)面臨著如何對(duì)待上一次迭代的中間產(chǎn)物的問(wèn)題。如果我們每一次迭代都需要修改已存在的中間產(chǎn)物，那么這種維護(hù)的成本未免過(guò)大。因此，敏捷方法論的基本做法是，扔掉那些已經(jīng)沒(méi)有用處的中間產(chǎn)物。軟件要比文檔重要。生成中間產(chǎn)物的目的都是為了生成最終的程序，對(duì)于這些已經(jīng)完成作用的模型，沒(méi)有必要付出額外的維護(hù)成本。 架構(gòu)設(shè)計(jì)中的一些提示（也是拋棄模型的必要條件）：簡(jiǎn)單化：簡(jiǎn)單的模型和簡(jiǎn)單的程

34、序。模型和程序越復(fù)雜，就需要更多的精力來(lái)處理它們。因此盡可能簡(jiǎn)化它們，為的是更容易的處理它們。高效溝通渠道：通過(guò)增強(qiáng)溝通的效果來(lái)減少對(duì)中間產(chǎn)物的需要。試想若隨時(shí)能從客戶處得到需求的細(xì)節(jié)資料，則前期需求調(diào)研就沒(méi)有必要做得太細(xì)。角色交叉輪換：開(kāi)發(fā)人員間建立起交換角色的機(jī)制，能夠盡量的避免各子系統(tǒng)諸侯割據(jù)的局面。清晰的流程：或明確的過(guò)程。過(guò)程在方法論中是重點(diǎn)，敏捷方法論也不例外。開(kāi)發(fā)人員能夠清楚的知道，今天做什么，明天做什么。過(guò)程不是給別人看的，而是給自己用的。工具：好用的工具能夠節(jié)省大量的時(shí)間，工具并不僅指CASE工具，還包括版本控制工具、自動(dòng)測(cè)試工具、畫(huà)圖工具、文檔制作和管理工具。使用工具要注意

35、成本和效益的問(wèn)題。標(biāo)準(zhǔn)和風(fēng)格：語(yǔ)言標(biāo)準(zhǔn)不同是溝通的很大障礙。語(yǔ)言從某個(gè)角度來(lái)看屬于一種標(biāo)準(zhǔn)、一種風(fēng)格。因此，一個(gè)團(tuán)隊(duì)如果采用同樣的編碼標(biāo)準(zhǔn)、文檔標(biāo)準(zhǔn)、注釋風(fēng)格、制圖風(fēng)格，那么這個(gè)團(tuán)隊(duì)的溝通效率一定非常高。如果上述的環(huán)境都不具備，或是欠缺好幾項(xiàng)，那你的文檔的模型還是留著的好。僅針對(duì)需求設(shè)計(jì)架構(gòu)不要做未來(lái)才有用的事情。有時(shí)我們會(huì)把架構(gòu)考慮得非常復(fù)雜，主要原因是把很多未來(lái)的因素放入到現(xiàn)在來(lái)考慮。或在開(kāi)發(fā)第一個(gè)產(chǎn)品的時(shí)候就試圖做成完美的框架。以上的這兩種思路有沒(méi)有錯(cuò)呢？沒(méi)有錯(cuò)，這只是如何看待投入的問(wèn)題，有人希望開(kāi)始的時(shí)候多投入一些，這樣后續(xù)的投入就會(huì)節(jié)省下來(lái)。但在現(xiàn)實(shí)中，由于需求的不確定性，希望通過(guò)增

36、加開(kāi)始階段的投入來(lái)將降低未來(lái)的投入往往是難以做到的，框架的設(shè)計(jì)也絕非一蹴而就的，因此這種做法并不好。同其它很多事物一樣，架構(gòu)設(shè)計(jì)應(yīng)保持簡(jiǎn)單性和迭代過(guò)程！引入模式模式幫助我們抓住重點(diǎn)。為了解決設(shè)計(jì)文檔編輯器引出的七個(gè)問(wèn)題，一共使用了8種不同的模式。這8種模式的組合其實(shí)就是架構(gòu)，因?yàn)樗鼈兘鉀Q的，都是系統(tǒng)中最高層的問(wèn)題。架構(gòu)也是存在模式的。比如，對(duì)于系統(tǒng)結(jié)構(gòu)設(shè)計(jì)，我們使用層模式；對(duì)于分布式系統(tǒng)，我們使用代理模式；對(duì)于交互系統(tǒng)，我們使用MVC（模型-視圖-控制器）模式。模式本來(lái)就是針對(duì)特定問(wèn)題的解，因此，針對(duì)需求的特點(diǎn)，我們也可以采用相應(yīng)的模式來(lái)設(shè)計(jì)架構(gòu)。PetShot案例在MVC圖背后隱藏著的需求：

37、系統(tǒng)需要支持多種用戶界面，包括為普通用戶提供的HTML界面，為無(wú)線用戶提供的WML界面，為管理員提供的Swing界面，以及為B2B業(yè)務(wù)設(shè)計(jì)的WebService界面。這是系統(tǒng)最重要的需求，因此，系統(tǒng)的設(shè)計(jì)者就需要確定一個(gè)穩(wěn)定的架構(gòu)，以解決多界面的問(wèn)題。相對(duì)于多界面的問(wèn)題，后端的業(yè)務(wù)處理邏輯都是一致的。比如HTML界面和WML界面的功能并沒(méi)有太大的差別。把處理邏輯和界面分離開(kāi)來(lái)還有額外的好處，可以在添加功能的同時(shí)，不涉及界面的改動(dòng)，反之亦然。（耦合度的問(wèn)題）。MVC模式正可以適用于解決該問(wèn)題。系統(tǒng)使用控制器來(lái)為業(yè)務(wù)邏輯選擇不同的界面，這就完成了MVC架構(gòu)的設(shè)計(jì)思路。在架構(gòu)設(shè)計(jì)的工作中，我們手頭上

38、有模式這樣一張好牌，有什么理由不去使用它呢？抓住重點(diǎn)架構(gòu)是一種抽象，即架構(gòu)設(shè)計(jì)摒棄了具體的細(xì)節(jié)，僅僅抓住軟件最高層的概念，也就是最上層、優(yōu)先級(jí)最高、風(fēng)險(xiǎn)最大的那部分需求?？紤]、分析、解決一個(gè)問(wèn)題，一定有一個(gè)漸進(jìn)的過(guò)程。架構(gòu)設(shè)計(jì)就是解決問(wèn)題其中比較早期的一個(gè)階段，我們不會(huì)在架構(gòu)設(shè)計(jì)這個(gè)階段投入過(guò)多的時(shí)間，因此關(guān)鍵點(diǎn)在于我們要能夠在架構(gòu)設(shè)計(jì)中把握住需求的重點(diǎn)。比如，分布式系統(tǒng)和交互系統(tǒng)，分布和交互就是這兩個(gè)系統(tǒng)的重點(diǎn)。那么，如果說(shuō)我們面對(duì)的是一個(gè)分布式的交互系統(tǒng)，那么，我們就需要把這兩種特性做為重點(diǎn)來(lái)考慮，并以此為基礎(chǔ)，設(shè)計(jì)架構(gòu)。而寵物商店的范例也是類似的，除了MVC的架構(gòu)，還有很多的設(shè)計(jì)問(wèn)題需要

39、解決，例如用于數(shù)據(jù)庫(kù)訪問(wèn)的數(shù)據(jù)對(duì)象，用于視圖管理的前端控制器等。但是這些相對(duì)于MVC模式來(lái)說(shuō)，屬于局部的，優(yōu)先級(jí)較低的部分，可以在架構(gòu)確定后再來(lái)設(shè)計(jì)。架構(gòu)設(shè)計(jì)和領(lǐng)域?qū)＜乙粋€(gè)架構(gòu)要設(shè)計(jì)的好，和對(duì)需求的理解是分不開(kāi)的。因此在現(xiàn)實(shí)中，業(yè)務(wù)領(lǐng)域?qū)＜覒{借著他對(duì)業(yè)務(wù)領(lǐng)域的了解，能夠幫助開(kāi)發(fā)人員設(shè)計(jì)出優(yōu)秀的架構(gòu)來(lái)。架構(gòu)是需要抽象的，它是現(xiàn)實(shí)社會(huì)活動(dòng)的一個(gè)基本模型，而業(yè)務(wù)領(lǐng)域的模型僅僅憑開(kāi)發(fā)人員是很難設(shè)計(jì)出來(lái)的。在ERP的發(fā)展史上，MRP發(fā)展為MRPII，再發(fā)展到閉環(huán)MRP，直到發(fā)展成為現(xiàn)在的ERP，主要的因素是管理思想的演化，也就是說(shuō)，對(duì)業(yè)務(wù)領(lǐng)域的理解進(jìn)步了，架構(gòu)才有可能進(jìn)步。因此，敏捷型架構(gòu)設(shè)計(jì)的過(guò)程中，

40、我們也非常強(qiáng)調(diào)領(lǐng)域?qū)＜业淖饔谩?軟件約束條件與架構(gòu)的影響資金時(shí)間業(yè)務(wù)運(yùn)行環(huán)境開(kāi)發(fā)團(tuán)隊(duì)實(shí)現(xiàn)技術(shù)等103領(lǐng)域模型設(shè)計(jì)領(lǐng)域模型（Domain Model）商業(yè)建模范疇的概念： 同行業(yè)企業(yè)的業(yè)務(wù)模型必定有很大的共性和內(nèi)在的規(guī)律性，由這個(gè)行業(yè)內(nèi)的各個(gè)企業(yè)的業(yè)務(wù)模型再向上抽象出來(lái)整個(gè)行業(yè)的業(yè)務(wù)模型，即領(lǐng)域模型。技術(shù)建模范疇的概念：用編程語(yǔ)言來(lái)實(shí)現(xiàn)商業(yè)領(lǐng)域模型。關(guān)系：對(duì)行業(yè)經(jīng)驗(yàn)積累不足的軟件公司，開(kāi)發(fā)軟件由需求驅(qū)動(dòng)，而非商業(yè)的領(lǐng)域模型驅(qū)動(dòng)。商業(yè)領(lǐng)域模型與編程語(yǔ)言的不是一對(duì)一的對(duì)應(yīng)關(guān)系。例如用EJB2模型，需要最少兩個(gè)以上的EJB，即一個(gè) Session Bean，處理面向流程的控制邏輯，一個(gè)Entity B

41、ean，處理面向持久化的實(shí)體邏輯（持久化操作附著在Entity Bean的Home接口上）。如果是更加復(fù)雜的領(lǐng)域模型，則需要更多的EJB，一般一個(gè)領(lǐng)域模型需要多個(gè)Entity Bean和多個(gè)Session Bean。使用基于POJO模型的實(shí)現(xiàn)，則粗顆粒度的EJB要繼續(xù)細(xì)分：一個(gè)Entity Bean對(duì)應(yīng)三個(gè)以上POJO：一個(gè)或者多個(gè)實(shí)體類，DAO接口、DAO接口實(shí)現(xiàn)類；一個(gè)Session Bean要切分為多個(gè)業(yè)務(wù)Bean。104105層次結(jié)構(gòu)領(lǐng)域模型從EJB到輕量級(jí)框架106層次結(jié)構(gòu)表現(xiàn)層（present）業(yè)務(wù)層業(yè)務(wù)層外觀業(yè)務(wù)服務(wù)層領(lǐng)域?qū)ο蠊芾?服務(wù)/倉(cāng)庫(kù)層領(lǐng)域?qū)ο髮映志脤訑?shù)據(jù)訪問(wèn)層數(shù)據(jù)庫(kù)10

42、7領(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í)體的集合,主要有查找和刪除實(shí)體的方法.實(shí)現(xiàn)類可以調(diào)用執(zhí)久化層(如Hibernate，Ibatis)服務(wù)(Service) ，實(shí)現(xiàn)整個(gè)應(yīng)用程序的工作

43、流(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ì)象中。1082、層次之間的交互 A、頁(yè)面提交表單數(shù)據(jù)到Action，Action創(chuàng)建DTO對(duì)象并設(shè)置相應(yīng)屬性值為表單數(shù)據(jù) B、Action傳遞DTO對(duì)象給Facade C、Facade中套用ServiceTemplate事務(wù)模板以加入事務(wù)管理，在ServiceTemplat

44、e中根據(jù)具體業(yè)務(wù)調(diào)用Factory或Reposistory，分別create或者load出DomainModel對(duì)象 D、Facade傳遞DomainModel對(duì)象給Service E、Service執(zhí)行具體業(yè)務(wù)邏輯（調(diào)用DomainModel對(duì)象相應(yīng)的業(yè)務(wù)方法） F、Service調(diào)用Reposistory對(duì)狀態(tài)已改變的DomainModel對(duì)象進(jìn)行持久化操作（調(diào)用相應(yīng)DAO） 109注： 在Facade或Service中如果需要查詢DomainModel對(duì)象中的屬性值，調(diào)用DomainModel對(duì)象的getDataInfo()方法得到DataInfo對(duì)象，通過(guò)DataInfo對(duì)象查詢所需數(shù)

45、據(jù)，包括Service返回給Faade業(yè)務(wù)處理結(jié)果中所包含的業(yè)務(wù)數(shù)據(jù)。 110111領(lǐng)域模型失血模型貧血模型充血模型脹血模型112失血模型DO只有屬性及其getter/setter方法，沒(méi)有任何業(yè)務(wù)邏輯。缺點(diǎn)：行為與數(shù)據(jù)分離，很多情況導(dǎo)致維護(hù)與理解困難。113貧血模型DO包含不依賴于持久化的領(lǐng)域邏輯；依賴持久化的領(lǐng)域邏輯歸入Service層。Service(業(yè)務(wù)邏輯，事務(wù)封裝) DAODO優(yōu)點(diǎn)：各層單向依賴，結(jié)構(gòu)清楚，易于實(shí)現(xiàn)和維護(hù)。設(shè)計(jì)簡(jiǎn)單易行，底層模型非常穩(wěn)定。缺點(diǎn)：DO部分的持久化邏輯被放入Service層，不夠OO。Service層過(guò)重。114充血模型與貧血模型類似，不同處在于如何劃分

46、業(yè)務(wù)邏輯：絕大多業(yè)務(wù)邏輯都應(yīng)該放在DO里(包括持久化邏輯)，而Service層很薄，僅僅封裝事務(wù)和少量邏輯，不和DAO層打交道。Service(事務(wù)封裝)DO DAO優(yōu)點(diǎn)：符合OOService層很薄，只充當(dāng)Facade的角色，不和DAO打交道。115缺點(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ù)腳本。充血模型在do

47、main層實(shí)現(xiàn)的OO在Service層又變成了面向過(guò)程。 116脹血模型取消Service層，只剩下DO和DAO層，在DO的domain logic上面封裝事務(wù)。DO(事務(wù)封裝，業(yè)務(wù)邏輯)DAO(RoR甚至合并為一層） 優(yōu)點(diǎn)：分層簡(jiǎn)化符合OO缺點(diǎn)：service邏輯也強(qiáng)行放入DO ，引起了DO不穩(wěn)定。DO暴露給web層過(guò)多的信息，可能引起不必要的耦合。117原則：業(yè)務(wù)對(duì)象封裝了內(nèi)在的業(yè)務(wù)邏輯，而應(yīng)用服務(wù)封裝了外在于業(yè)務(wù)對(duì)象的業(yè)務(wù)邏輯。 118EJB到輕量級(jí)框架EJBPOJO （業(yè)務(wù)邏輯） + 輕量級(jí)框架（Hibernate、JDO、iBATIS（持久化）、Spring（事務(wù)管理、安全）119E

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

49、TO。應(yīng)用程序通過(guò)將組件的依賴作為setter或構(gòu)造子參數(shù)傳入來(lái)進(jìn)行組裝,而不是之前采用Java命名和目錄接口(JNDI )查詢的組件。由于該設(shè)計(jì)面向?qū)ο?并采用上述輕量級(jí)技術(shù),因此較之前看到的EJB版本對(duì)開(kāi)發(fā)人員要友好。123基于輕量級(jí)框架設(shè)計(jì)的好處是，它提供事務(wù)和持久化時(shí)并不要求應(yīng)用程序類實(shí)現(xiàn)任何特殊接口。甚至當(dāng)應(yīng)用程序的類需要運(yùn)行在事務(wù)里或是持久的時(shí)候，它們?nèi)允荘OJO，設(shè)計(jì)者可以繼續(xù)享受POJO的種種好處。124125面向?qū)ο蟮膬?yōu)點(diǎn)：整個(gè)設(shè)計(jì)更易理解和維護(hù)。它并不是一個(gè)無(wú)所不能的大型類, 而是由大量小類組成, 每個(gè)類只共有若干職責(zé)。此外,諸如Account、BankingTransac

50、tion和OverdraftPolicy類都與現(xiàn)實(shí)世界的概念對(duì)應(yīng), 因此易于理解。其次,面向?qū)ο笤O(shè)汁也更易測(cè)試: 所有類都能并且應(yīng)當(dāng)進(jìn)行獨(dú)立的測(cè)試。EJB只能通過(guò)調(diào)用它的public 方法如Transter進(jìn)行測(cè)試,難度大。(只能測(cè)試p-blic方法暴露的復(fù)雜功能,無(wú)法測(cè)試其中簡(jiǎn)單的部分）。面向?qū)ο笙笤O(shè)計(jì)更易擴(kuò)展, 它可使用設(shè)計(jì)模式，如Stategy和Template等。EJB風(fēng)格的過(guò)程式設(shè)計(jì)往往需耍修改核心代碼。126不適合用面向?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固然

51、不好維護(hù)，但業(yè)務(wù)真是復(fù)雜到簡(jiǎn)單的SQL都難以描述的程度，采用面向?qū)ο竺枋鰟t更加困難，維護(hù)也更困難，同時(shí)還損失了效率。比較大的事務(wù)。性能要求高的地方。（直接用Sql或者存儲(chǔ)過(guò)程；犧牲可維護(hù)性和可復(fù)用性）上層流程。127消除DTO128部署POJO程序129130軟件架構(gòu)模式分析及其實(shí)際運(yùn)用 軟件架構(gòu)軟件架構(gòu)概論架構(gòu)的目標(biāo)架構(gòu)的種類軟件框架常見(jiàn)的架構(gòu)模式軟件架構(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 Component）、

52、聯(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)需求。建造一個(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ò)慎重的研究和考察。架構(gòu)的種類根據(jù)我們關(guān)注的角度不同，可以將架構(gòu)分成三種：邏輯架構(gòu)物理架構(gòu)系統(tǒng)架構(gòu)邏輯架構(gòu)軟件系統(tǒng)中元件之間的關(guān)系，比

53、如用戶界面，數(shù)據(jù)庫(kù)，外部系統(tǒng)接口，商業(yè)邏輯元件等等。物理架構(gòu)軟件元件是怎樣放到硬件上的下圖描述了一個(gè)分布于北京和上海的分布式系統(tǒng)的物理架構(gòu)，圖中所有的元件都是物理設(shè)備，包括網(wǎng)絡(luò)分流器、代理服務(wù)器、WEB服務(wù)器、應(yīng)用服務(wù)器、報(bào)表服務(wù)器、整合服務(wù)器、存儲(chǔ)服務(wù)器、主機(jī)等等。系統(tǒng)架構(gòu)系統(tǒng)的非功能性特征，如可擴(kuò)展性、可靠性、強(qiáng)壯性、靈活性、性能等。系統(tǒng)架構(gòu)的設(shè)計(jì)要求架構(gòu)師具備軟件和硬件的功能和性能的過(guò)硬知識(shí)，這一工作是架構(gòu)設(shè)計(jì)工作中最困難的工作。架構(gòu)的兩要素元件劃分和設(shè)計(jì)決定。邏輯元件：一個(gè)軟件系統(tǒng)中的元件首先是邏輯元件。這些邏輯元件如何放到硬件上，以及這些元件如何為整個(gè)系統(tǒng)的可擴(kuò)展性、可靠性、強(qiáng)壯性、

54、靈活性、性能等做出貢獻(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ì)文檔。從概念性架構(gòu)到實(shí)際架構(gòu) 就是多 (Less is more.)。 - 密斯凡德羅 概念性架構(gòu)是對(duì)系統(tǒng)設(shè)計(jì)的最初構(gòu)想。 一般來(lái)說(shuō)，實(shí)際的軟件架構(gòu)設(shè)計(jì)過(guò)程是，先進(jìn)行概念性架構(gòu)的設(shè)計(jì)，把最關(guān)鍵的設(shè)計(jì)要素和交互機(jī)制確定下來(lái)，然后再

55、考慮具體技術(shù)的運(yùn)用，設(shè)計(jì)出實(shí)際架構(gòu)。 架構(gòu)設(shè)計(jì)中的關(guān)鍵要素及解決策略策略是制勝的關(guān)鍵。- 張明正，擋不住的趨勢(shì) 最好的軟件開(kāi)發(fā)人員都知道一個(gè)秘密：美的東西比丑的東西創(chuàng)建起來(lái)更廉價(jià)，也更快捷。- Robert C. Martin, 軟件之美 時(shí)間就是系統(tǒng)架構(gòu)的生命。- Philippe Kruchten 方法產(chǎn)生于恐懼。 面對(duì)時(shí)間緊迫的壓力，我們有理由質(zhì)疑那種不顧時(shí)間花銷、一味追求軟件架構(gòu)高質(zhì)量的做法。軟件架構(gòu)是軟件系統(tǒng)質(zhì)量的核心，必須足夠重視，但在不適當(dāng)?shù)臅r(shí)候“用時(shí)間換完美”會(huì)毀掉整個(gè)項(xiàng)目。 架構(gòu)設(shè)計(jì)并非“好的就是成功的”，而是“適合的才是成功的”。 方法論 Alistair Cockburn

56、 的七條定理，總結(jié)為：溝通和反饋。 RUP、XP重量之爭(zhēng)軟件架構(gòu)設(shè)計(jì)中的關(guān)鍵要素及解決策略： 關(guān)鍵要素 策略 - -1. 是否遺漏了至關(guān)重要的非功能需求？ 全面認(rèn)識(shí)需求。2. 能否馴服數(shù)量巨大且頻繁變化的需求？ 關(guān)鍵需求決定架構(gòu)。3. 能否從容地設(shè)計(jì)軟件架構(gòu)的不同方面？ 多視圖探尋架構(gòu)。4. 是否及早驗(yàn)證架構(gòu)方案并作出了調(diào)整？ 及早驗(yàn)證架構(gòu)。 軟件架構(gòu)設(shè)計(jì)過(guò)程總覽一般的軟件過(guò)程： 需求分析的幾個(gè)概念 需求捕獲 vs 需求分析 vs 系統(tǒng)分析需求捕獲是獲取知識(shí)的過(guò)程，知識(shí)從無(wú)到有。需求分析是挖掘和整理知識(shí)的過(guò)程，它在已掌握知識(shí)的基礎(chǔ)上進(jìn)行。系統(tǒng)分析？如果說(shuō)需求分析致力于“做什么”，那么系統(tǒng)分析則

57、涉及“怎么做”。 軟件架構(gòu)師不必是需求捕獲專家，也不必是編寫(xiě)軟件需求規(guī)格說(shuō)明書(shū)的專家。但他一定應(yīng)在需求分類、需求折衷和需求變更的研究方面是專家，否則他和其他軟件架構(gòu)師相比，就輸在了“起跑線”上。 概念性架構(gòu)設(shè)計(jì)概念性架構(gòu)設(shè)計(jì)的迭代方式：1. 魯棒性分析；2. 引入架構(gòu)模式；3. 質(zhì)量屬性分析。 魯棒性分析 所謂魯棒性分析是這樣一種方法：通過(guò)分析用例規(guī)約中的事件流，識(shí)別出實(shí)現(xiàn)用例規(guī)定的功能所需的主要對(duì)象及其職責(zé)，形成以職責(zé)模型為主的初步設(shè)計(jì)。 魯棒性分析是從功能需求向設(shè)計(jì)方案過(guò)度的第一步，所獲得的初步設(shè)計(jì)是一種理想化的職責(zé)模型，它的重點(diǎn)是識(shí)別組成軟件系統(tǒng)的高級(jí)職責(zé)塊、規(guī)劃它們之間的關(guān)系。 魯棒性

58、分析填補(bǔ)了分析和設(shè)計(jì)之間的鴻溝。 魯棒圖包含三種元素：邊界對(duì)象、控制對(duì)象和實(shí)體對(duì)象。引入架構(gòu)模式 較為經(jīng)典的幾種架構(gòu)模式：分層、MVC、微內(nèi)核、基于元模型的架構(gòu)、管道-過(guò)濾器等。質(zhì)量屬性分析 “屬性-場(chǎng)景-決策”表方法： 細(xì)化架構(gòu)設(shè)計(jì) 架構(gòu)細(xì)化工作主要體現(xiàn)在基于五視圖方法進(jìn)行架構(gòu)細(xì)化： 約束 領(lǐng)域模型 - 基于五視圖方法 關(guān)鍵需求 - - 架構(gòu)方案 概念架構(gòu) - 進(jìn)行架構(gòu)細(xì)化 經(jīng)驗(yàn) 邏輯架構(gòu)設(shè)計(jì)中，“發(fā)現(xiàn)通用機(jī)制”是應(yīng)被特別強(qiáng)調(diào)的。 機(jī)制(Mechanism)是模式的實(shí)例。機(jī)制是特定上下文中重復(fù)出現(xiàn)的問(wèn)題的特定解決方案。 具有良好架構(gòu)的系統(tǒng)具備概念完整性。它通過(guò)對(duì)系統(tǒng)架構(gòu)建立一種清晰的認(rèn)識(shí)來(lái)發(fā)

59、現(xiàn)通用的抽象和機(jī)制。利用這種共性使最終產(chǎn)生的系統(tǒng)結(jié)構(gòu)更為簡(jiǎn)單。實(shí)現(xiàn)并驗(yàn)證軟件架構(gòu)好的策略必須是一再求證、測(cè)試、發(fā)現(xiàn)瑕疵漏洞，另想途徑或方法來(lái)彌補(bǔ)策略不足，有時(shí)甚至得全盤(pán)放棄，重新策劃。- 張明正，擋不住的趨勢(shì) 架構(gòu)原型對(duì)功能性需求的實(shí)現(xiàn)非常有限，那么“架構(gòu)驗(yàn)證”要驗(yàn)證什么？答案是要驗(yàn)證架構(gòu)對(duì)質(zhì)量屬性需求的支持程度，包括運(yùn)行期質(zhì)量屬性和開(kāi)發(fā)期質(zhì)量屬性。 驗(yàn)證架構(gòu)的兩種方法：原型法。對(duì)于項(xiàng)目型開(kāi)發(fā)，常采用“原型法”。即對(duì)一組架構(gòu)設(shè)計(jì)決策在非功能需求方面的滿足程度進(jìn)行驗(yàn)證。該原型往往是演進(jìn)型，而非拋棄型?？蚣芊?。對(duì)于產(chǎn)品型開(kāi)發(fā)，采用“框架法”有更多優(yōu)點(diǎn)。該方法將架構(gòu)設(shè)計(jì)方案用框架的形式實(shí)現(xiàn)，并在此基

60、礎(chǔ)上進(jìn)行評(píng)估驗(yàn)證。在框架實(shí)現(xiàn)后，在框架基礎(chǔ)上實(shí)現(xiàn)部分應(yīng)用的功能，即實(shí)現(xiàn)一個(gè)小的垂直原型，從而進(jìn)行實(shí)際非功能測(cè)試和開(kāi)發(fā)期質(zhì)量屬性評(píng)價(jià)。 軟件框架什么是框架框架與架構(gòu)的區(qū)別常見(jiàn)的框架為什么要用框架因?yàn)檐浖到y(tǒng)發(fā)展到今天已經(jīng)很復(fù)雜了，特別是服務(wù)器端軟件，設(shè)計(jì)到的知識(shí)，內(nèi)容，問(wèn)題太多。在某些方面使用成熟的框架，可以避免重復(fù)做已有的基礎(chǔ)工作，而只需要集中精力完成系統(tǒng)的業(yè)務(wù)邏輯設(shè)計(jì)?？蚣芤话闶浅墒?，穩(wěn)健的，可以處理系統(tǒng)很多細(xì)節(jié)問(wèn)題，比如，事物理，安全性，數(shù)據(jù)流控制等問(wèn)題?？蚣芤话愣冀?jīng)過(guò)很多人使用，所以結(jié)構(gòu)很好，所以擴(kuò)展性也很好，而且它是不斷升級(jí)的，使用框架的開(kāi)發(fā)者可以直接享受別人升級(jí)代碼帶來(lái)的好處。框架一