軟件架構(gòu)設計

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

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

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

4、構(gòu)建自己的架構(gòu)。 軟件架構(gòu)的作用 如果一個項目的系統(tǒng)架構(gòu)(包括理論基礎)尚未確定，就不應該進行此系統(tǒng)的全面開發(fā)。- Barry Boehm,Engineering Context 一個缺陷充斥的系統(tǒng)，將始終是一個缺陷充斥的系統(tǒng)。- Timothy C. Lethbridge,面向?qū)ο筌浖こ?軟件架構(gòu)設計為什么這么難？ 因為它是跨越現(xiàn)實世界與計算機世界之間鴻溝的一座橋。 軟件架構(gòu)設計要完成從面向業(yè)務到面向技術(shù)的轉(zhuǎn)換，在鴻溝上架起一座橋梁。 需求 - 架構(gòu)設計 - 軟件架構(gòu) - 系統(tǒng)開發(fā) - 軟件系統(tǒng)軟件架構(gòu)對新產(chǎn)品開發(fā)的作用： 上承業(yè)務目標。上承業(yè)務目標。 下接技術(shù)決策。下接技術(shù)決策。 控制復

5、雜性。控制復雜性。 先進行架構(gòu)設計，后進行詳細設計和編碼實現(xiàn)，符合“基于問題深度分而治之”的理念。 組織開發(fā)。組織開發(fā)。 軟件架構(gòu)方案在小組中間扮演了“橋梁”和“合作契約”的作用。 利于迭代開發(fā)和增量交付。利于迭代開發(fā)和增量交付。 以架構(gòu)為中心進行開發(fā)，為增量交付提供了良好的基礎。在架構(gòu)經(jīng)過驗證之后，可以專注于功能的增量提交。 提高質(zhì)量。提高質(zhì)量。 軟件產(chǎn)品線軟件產(chǎn)品線：指具有一組可管理的、公共特性的、軟件密集性系統(tǒng)的集合，這些系統(tǒng)滿足特定的市場需求或任務需求，并且按照預定義方式從一個公共的核心資產(chǎn)集開發(fā)得到。 軟件產(chǎn)品線架構(gòu)軟件產(chǎn)品線架構(gòu)：針對一個公司或組織內(nèi)的一系列產(chǎn)品而設計的通用架構(gòu)。

6、軟件架構(gòu)對軟件產(chǎn)品線開發(fā)的作用： 固化核心知識； 提供可重用資產(chǎn)； 縮短推出產(chǎn)品的周期； 降低開發(fā)和維護成本； 提高產(chǎn)品質(zhì)量； 支持批量定制； 架構(gòu)師應當為項目相關的不同角色而設計： 架構(gòu)師要為客戶負責，滿足他們的業(yè)務目標和約束條件。 架構(gòu)師要為用戶負責，滿足他們關心的功能需求和運行期質(zhì)量屬性。 架構(gòu)師必須顧及處于協(xié)作分工“下游”的開發(fā)人員。 架構(gòu)師必須考慮“周邊”的管理人員，為他們進行分工管理、協(xié)調(diào)控制和評估監(jiān)控等工作提供清晰的基礎。 軟件架構(gòu)視圖讓設計建模更明白、更有效張云貴2010-05-21“系統(tǒng)架構(gòu)圖”？架構(gòu)設計的多重視圖 從根本上來說是因為需求種類的復雜性所致。 比如一個媒體發(fā)布系

7、統(tǒng)： 功能需求：用戶可以通過瀏覽器瀏覽媒體的發(fā)布。據(jù)此初步設計出采用瀏覽器插件的方案； 約束條件：不能影響用戶瀏覽器的安全性；細化設計方案，需要對插件進行認證，自動判別客戶端是否存在，及版本比較；自動下載注冊等。 使用期質(zhì)量屬性：為保證瀏覽的流暢，應減少中間等待的時間，因此應對下一步需使用的媒體做預測等。 制作發(fā)布期的質(zhì)量保證：保證在遇到較大的媒體時能保持瀏覽的流暢，應在發(fā)布時將視頻等流式化。軟件系統(tǒng)的需求種類復雜什么是軟件架構(gòu)視圖什么是軟件架構(gòu)視圖 個架構(gòu)視圖是對于從某一視角或某一點上看到的系統(tǒng)所做的簡化描述，描述中涵蓋了系統(tǒng)的某一特定方面，而省略了于此方面無關的實體。 架構(gòu)要涵蓋的內(nèi)容和決

8、策太多了，超過了人腦“一蹴而就”的能力范圍，因此采用“分而治之”的辦法從不同視角分別設計；同時，也為軟件架構(gòu)的理解、交流和歸檔提供了方便。 多視圖方法是軟件架構(gòu)歸檔的方法，更是指導我們進行架構(gòu)設計的思維方法。邏輯架構(gòu)邏輯架構(gòu) 邏輯架構(gòu)關注功能。其設計著重考慮功能需求。開發(fā)架構(gòu)開發(fā)架構(gòu) 開發(fā)架構(gòu)關注程序包。其設計著重考慮開發(fā)期質(zhì)量屬性，如可擴展性、可重用性、可移植性、易理解性和易測試性等。運行架構(gòu)運行架構(gòu) 運行架構(gòu)關注進程、線程、對象等運行時概念，以及相關的并發(fā)、同步、通信等問題。 其設計著重考慮運行期質(zhì)量屬性，例如性能、可伸縮性、持續(xù)可用性和安全性等。物理架構(gòu)物理架構(gòu) 物理架構(gòu)關注軟件系統(tǒng)最終

9、如何安裝或部署到物理機器。其設計著重考慮“安裝和部署需求”。以及如何部署機器和網(wǎng)絡來配合軟件系統(tǒng)的可靠性、可伸縮性等要求。數(shù)據(jù)架構(gòu)數(shù)據(jù)架構(gòu) 數(shù)據(jù)架構(gòu)關注持久化數(shù)據(jù)的存儲方案。設計著重考慮“數(shù)據(jù)需求”。 關系邏輯視圖邏輯視圖。邏輯視圖不僅關注用戶可見的功能，還包括為實現(xiàn)用戶功能而必須提供的“輔助功能模塊”；它們可能是邏輯層、功能模塊等。開發(fā)視圖開發(fā)視圖。開發(fā)視圖關注程序包，不僅包括要編寫的源程序，還包括可以直接使用的第三方SDK和現(xiàn)成框架、類庫，以及開發(fā)的系統(tǒng)將運行于其上的系統(tǒng)軟件或中間件。開發(fā)視圖和邏輯視圖之間可能存在一定的映射關系：比如邏輯層一般會映射到多個程序包等。運行視圖運行視圖。和開發(fā)

10、視圖的關系：開發(fā)視圖一般偏重程序包在編譯時期的靜態(tài)依賴關系，而這些程序運行起來之后會表現(xiàn)為對象、線程、進程，運行視圖比較關注的正是這些運行時單元的交互問題。物理視圖物理視圖。和運行視圖的關系：運行視圖特別關注目標程序的動態(tài)執(zhí)行情況，而物理視圖重視目標程序的靜態(tài)位置問題；物理視圖是綜合考慮軟件系統(tǒng)和整個IT系統(tǒng)相互影響的架構(gòu)視圖。 軟件生命周期與軟件架構(gòu)介紹軟件生命周期與軟件架構(gòu)介紹24軟件架構(gòu)師的定位系統(tǒng)架構(gòu)師的職責：一、理解系統(tǒng)的業(yè)務需求，制定系統(tǒng)的整體框架（包括：技術(shù)框架和業(yè)務框架）二、對系統(tǒng)框架相關技術(shù)和業(yè)務進行培訓，指導開發(fā)人員開發(fā)。并解決系統(tǒng)開發(fā)、運行中出現(xiàn)的各種問題。系統(tǒng)架構(gòu)師的目

11、的：對系統(tǒng)的重用、擴展、安全、性能、伸縮性、簡潔等做系統(tǒng)級的把握。系統(tǒng)架構(gòu)師能力要求：一、系統(tǒng)架構(gòu)相關的知識和經(jīng)驗。二、很強的自學能力、分析能力、解決問題的能力。三、寫作、溝通表達、培訓。25角色軟件架構(gòu)師Software Architect定義主導系統(tǒng)全局分析設計和實施、負責軟件構(gòu)架和關鍵技術(shù)決策的角色26職責 領導與協(xié)調(diào)整個項目中的技術(shù)活動（分析、設計和實施等） 推動主要的技術(shù)決策，并最終表達為軟件構(gòu)架 確定和文檔化系統(tǒng)的相對構(gòu)架而言意義重大的方面，包括系統(tǒng)的需求、設計、實施和部署等“視圖” 確定設計元素的分組以及這些主要分組之間的接口 為技術(shù)決策提供規(guī)則，平衡各類涉眾的不同關注點，化解技

12、術(shù)風險，并保證相關決定被有效的傳達和貫徹 理解、評價并接收系統(tǒng)需求 評價和確認軟件架構(gòu)的實現(xiàn)27專業(yè)技能技術(shù)全面、成熟練達、洞察力強、經(jīng)驗豐富，具備在缺乏完整信息、眾多問題交織一團、模糊和矛盾的情況下，迅速抓住問題要害，并做出合理的關鍵決定的能力。具備戰(zhàn)略性和前瞻性思維能力，善于把握全局，能夠在更高抽象級別上進行思考。對項目開發(fā)涉及的所有問題領域都有經(jīng)驗，包括徹底地理解項目需求，開展分析設計之類軟件工程活動等。具備領導素質(zhì)，以在各小組之間推進技術(shù)工作，并在項目壓力下做出牢靠的關鍵決策。擁有優(yōu)秀的溝通能力，用以進行說服、鼓勵和指導等活動，并贏得項目成員的信任。28以目標導向和主動的方式來不帶任何

13、感情色彩地關注項目結(jié)果，構(gòu)架師應當是項目背后的技術(shù)推動力，而非構(gòu)想者或夢想家（追求完美）精通構(gòu)架設計的理論、實踐和工具，并掌握多種參考構(gòu)架、主要的可重用構(gòu)架機制和模式。具備系統(tǒng)設計員的所有技能，但涉及面更廣、抽象級別更高。29軟件架構(gòu)師的知識體系軟件架構(gòu)師作為整個軟件系統(tǒng)結(jié)構(gòu)的總設計師，其知識體系、技能和經(jīng)驗決定了軟件系統(tǒng)的可靠性、安全性、可維護性、可擴展性和可移植性等方面的性能。因此一個優(yōu)秀的軟件架構(gòu)師必須具備相當豐富的知識、技能和經(jīng)驗。通過對比軟件架構(gòu)師和系統(tǒng)分析師在軟件開發(fā)中的職責和角色，不難發(fā)現(xiàn)軟件架構(gòu)師與系統(tǒng)分析師所必需的知識體系也是不盡相同的，系統(tǒng)分析師的主要職責是在需求分析、開發(fā)

14、管理、運行維護等方面，而軟件架構(gòu)師的重點工作是在架構(gòu)與設計這兩個關鍵環(huán)節(jié)上。因此在系統(tǒng)分析師必須具備的知識體系中對系統(tǒng)的構(gòu)架與設計等方面知識體系的要求就相對低些；而軟件架構(gòu)師在需求分析、項目管理、運行維護等方面知識的要求也就相對低些。30成為一名合格的軟件架構(gòu)師必須具備的知識 信息系統(tǒng)綜合知識體系 軟件架構(gòu)知識體系31？MFC，MSF，MOF，RUP，J2EE，Spring，SOA，JUnit，ORM，.NetMVC，UML，XML，Corba，MDA，MDD，Web-ServiceRSS，Web2.0，AJAX，Serverlet，HibernateIOC， AOPRuby On Rails

15、RupBPELWorkflow EngineLBSOracleCMMIMQ32軟件架構(gòu)師在干什么？思考、思考、再思考 深入理解、準確把握建設的業(yè)務需求 分析所有可見的問題、障礙、風險 充分參考已有的成功方案，降低風險交流、討論、博弈、質(zhì)疑 對構(gòu)思中的方案不斷提出質(zhì)疑，避免漏洞 廣泛聽取各層面的意見，開拓思路 反復質(zhì)疑、逐步完善已有的設計構(gòu)思在動手實現(xiàn)之前驗證設計方案的正確性33軟件架構(gòu)師的知識結(jié)構(gòu)軟件知識 最好要有系統(tǒng)開發(fā)全過程經(jīng)驗。 對 IT 建設生命周期各個環(huán)節(jié)有深入了解，包括：系統(tǒng)/模塊邏輯設計、物理設計、代碼開發(fā)、項目管理、測試、發(fā)布、運行維護等。 深入掌握1-2種主流技術(shù)平臺上開發(fā)系

16、統(tǒng)的方法。 了解多種應用系統(tǒng)的結(jié)構(gòu)。 了解架構(gòu)設計領域的主要理論、流派、框架。34軟件架構(gòu)師的知識結(jié)構(gòu)業(yè)務知識 深入了解系統(tǒng)建設的業(yè)務需求。 了解系統(tǒng)的非功能需求和運行維護需求。 了解企業(yè) IT 公共設施、網(wǎng)絡環(huán)境、外部系統(tǒng)。35軟件架構(gòu)師的思維方式基于框架的思維 架構(gòu)設計的層次（Enterprise， Application， etc） IT 的生命周期（What， Why， Where， How， When， etc） 成功經(jīng)驗以及方法論的指導合理把握技術(shù)細節(jié) 把握各個層次應有的內(nèi)容 合理忽略不應有的技術(shù)細節(jié)36軟件架構(gòu)師的思維方式風險管理意識 采用成功經(jīng)驗、避免不應有的風險多方位的開放思

17、維 多維度、多方向、包容性、避免排他性 分析、質(zhì)疑、抽象、歸納 沒有絕對好的架構(gòu)設計，只有相對優(yōu)秀的方案注意：并不存在通用的設計方法。我們認為，給定的某種固定的方法總是會顧此失彼，而且這種不平衡性不太容易覺察。如果給定的某種方法所注重的方面與系統(tǒng)需求不吻合，則這種方法就會將設計引入歧途。所以我們給出的是一些技巧，任何一次設計過程，都需要設計師仔細分析系統(tǒng)的需求和相關的約束條件，靈活運用眾多的設計技巧，針對不同的設計方案進行取舍，做出合理的決策。37為了有效地控制設計工作的復雜性，一般把設計活動分為總體設計和詳細設計兩個層次。總體設計主要關注于體系結(jié)構(gòu)和接口這些全局性的內(nèi)容，而詳細設計主要關注于

18、每個模塊內(nèi)部的數(shù)據(jù)結(jié)構(gòu)和算法。至于數(shù)據(jù)，則在設計的各個層次都會涉及。軟件設計是一個迭代的過程，是一個逐步細化和求精的過程。因此，總體設計和詳細設計之間的劃分并不是絕對的。哪些是總體設計任務，哪些是詳細設計任務，取決于設計師對于整個項目的把握，并沒有一個統(tǒng)一的標準。設計師在設計時實際是在做一系列的設計決策，來滿足系統(tǒng)的行為目標，質(zhì)量目標和開發(fā)目標。如果一個結(jié)構(gòu)對于完成這些目標非常重要，則它是構(gòu)架的一部分。相反，如果它可以留到以后再完善，則它不是構(gòu)架的組成部分。因此，總的說來，一個設計是不是屬于構(gòu)架設計，要看你當前的設計目標。38管理陷阱管理陷阱 隨著管理性責任的增加，你所從事技術(shù)性工作的時間就會

19、顯著減少。這樣，因為在完成技術(shù)性任務和保持職業(yè)技能上花費時間的減少，你可能會失去技術(shù)優(yōu)勢。 軟件架構(gòu)師和管理者有很大的差異：軟件架構(gòu)師是直接的技術(shù)貢獻者；而管理者則是通過協(xié)調(diào)其他人員的活動來間接做出貢獻。他們往往一起協(xié)作，構(gòu)成高效的管理團隊。以經(jīng)驗看，把兩者結(jié)合起來卻不能長久地工作。 作為一名軟件架構(gòu)師，如果你已經(jīng)建立起個人的職業(yè)原則的話，就有可能避免成為管理者。架構(gòu)和設計應該做到何種程度軟件架構(gòu)必須設計到“能為開發(fā)人員提供足夠的指導和限制”的程度。分而治之的兩種方式 分而治之的緣由：問題太復雜了，超出了人們能夠“一蹴而就”的范圍。（接口和實現(xiàn)分離） 一、先不把問題研究得那么深，那么細，淺嘗輒

20、止，見好就收。這種分而治之的方式稱為“按問題深度分而治之”。 二、先不研究整個問題，而是研究問題的一部分，分割問題。這種分而治之的方式稱為“按問題廣度分而治之”。（比如展現(xiàn)層、業(yè)務層和數(shù)據(jù)層的開發(fā)）40隨著軟件設計工作越來越復雜，將架構(gòu)設計和詳細設計分離已成為普遍的做法。將設計分為架構(gòu)設計和詳細設計，是對“按問題深度分而治之”思想的運用。 所謂架構(gòu)設計，就是關于如何構(gòu)建軟件的一些最重要的設計決策; 詳細設計針對每個部分的內(nèi)部進行設計?？梢赃@么說，軟件架構(gòu)設計應當解決的是全局性的、涉及不同“局部”之間交互的設計問題，而不同“局部”的設計由后續(xù)的詳細設計負責。41面對“技術(shù)復雜性”和“管理復雜性”

21、這樣的雙重困難，以架構(gòu)為中心的開發(fā)方法是有效的途徑：一方面：“軟件系統(tǒng)的架構(gòu)涵蓋了整個系統(tǒng)，盡管架構(gòu)的有些部分可能只有一寸深”。構(gòu)造一個具有一定抽象層次的解決方案，而不是將所有細節(jié)統(tǒng)統(tǒng)展開，從而有效地控制了“技術(shù)復雜性”。沒有“把問題研究那么深、那么細”，屬于“按問題深度分而治之”42另一方面，因為“架構(gòu)中包含了關于各元素應如何彼此相關的信息”，從而可以把不同模塊分配給不同小組分頭開發(fā)，而軟件架構(gòu)設計方案在這些小組中間扮演“橋梁”和“合作契約”的作用。每個小組的工作覆蓋了“整個問題的一部分”，各小組之間可以互相獨立地進行并行工作，這種“分割問題，各個擊破”的策略，屬于“按問題廣度分而治之”。這

22、樣一來，模塊的技術(shù)細節(jié)被局部化到了小組內(nèi)部，內(nèi)部的細節(jié)不會成為小組間協(xié)作溝通的主要內(nèi)容，理順了溝通的層次。另外，對“人盡其才”也有好處，不同小組的成員需要精通的技術(shù)各不相同。例如，用戶界面層、數(shù)據(jù)管理層、系統(tǒng)交互層 。43架構(gòu)要進行到什么程度 軟件架構(gòu)是團隊開發(fā)的基礎，應明確規(guī)定后期分頭開發(fā)所必須的公共設計約定，為分頭開發(fā)提供足夠的指導和限制。 另一方面，具體的架構(gòu)設計程度還會因軟件項目的不同而不同。 架構(gòu)設計對軟件的不同部分的設計程度并不是整齊劃一的。(通信機制、持久化機制、消息機制等對應的公共模塊；具體的業(yè)務功能模塊在架構(gòu)設計中往往設計程度不深。）歸納： 由于項目的不同、開發(fā)團隊情況的不同

23、，軟件架構(gòu)的設計程度會有不同; 軟件架構(gòu)應當為開發(fā)人員提供足夠的指導和限制。44 高來高去式架構(gòu)設計的癥狀 不能為開發(fā)人員提供足夠的指導和限制的那種架構(gòu)設計方案。高來高去式架構(gòu)設計現(xiàn)象極為普遍，危害： 缺少來自架構(gòu)的足夠的指導和限制，開發(fā)人員在進入分頭開發(fā)階段之后會碰到很多問題，并且容易造成管理混亂，溝通和協(xié)作效率低； 對軟件質(zhì)量非常關鍵的全局性設計決定被拖延到分頭開發(fā)期間草率決定； 沒有完成化解重大技術(shù)風險的職責； 團隊成員對架構(gòu)師意見大，團隊士氣受到打擊。45癥狀一：缺失重要架構(gòu)視圖。給團隊的不同角色提供指導。癥狀二：架構(gòu)設計方案停留在概念性架構(gòu)的層面，全局性的設計決策最后由具體開發(fā)人員從

24、局部視角考慮并確定下來，造成技術(shù)和管理上的種種問題。癥狀三：名不副實的分層架構(gòu)。對各層之間交互接口和交互機制的設計嚴重不足。4647架構(gòu)設計的GRASP模式48495051525354555657585960616263646566質(zhì)量屬性驅(qū)動架構(gòu)設計策略質(zhì)量屬性驅(qū)動架構(gòu)設計策略 軟件質(zhì)量及質(zhì)量模型軟件質(zhì)量及質(zhì)量模型 軟件質(zhì)量是一個復雜的概念，不同的人從不同的角度來看軟件質(zhì)量問題，會有不同的理解。 從用戶的角度看，質(zhì)量就是滿足客戶的需求； 從開發(fā)者的角度看，質(zhì)量 就是與需求說明保持一致； 從產(chǎn)品的角度看，質(zhì)量就是 產(chǎn)品的內(nèi)在特點； 從價值的角度看，質(zhì)量就是客戶是否 愿意購買。在軟件項目開發(fā)過程

25、中，項目經(jīng)理眼中的質(zhì)量就是能“令人滿意”地工作以完成預期功能的軟件產(chǎn)品。所謂“令 人滿意”，包括功能、性能、接口需求及其他指標，如可靠性、可維護性、可復用性和正確性。然而在實際工作中，一旦出現(xiàn)問題時，項目管理人員必須權(quán)衡利弊，作出取舍，在滿足某一個指標的同時，犧牲另外一個或幾個指標。比如為了按期交貨，需對軟件功能進行分類，在第 一個版本中實現(xiàn)優(yōu)先級較高的功能，在第二個版本中實 現(xiàn)優(yōu)先級較低的功能。因此，項目經(jīng)理需要一個對其工作有指導意義的質(zhì)量模型和度量方法。該模型一方面可以幫助項目經(jīng)理生產(chǎn)出符合標準的軟件產(chǎn)品，另一方面幫助項目經(jīng)理識別可能影響產(chǎn)品質(zhì)量的風險。為什么那么多軟件產(chǎn)品需要重新設計？

26、難以維護？ 運行速度太慢？ 穩(wěn)定性差？ 無法進行功能擴展？ 易遭受安全攻擊？ 忽視包括質(zhì)量屬性需求在內(nèi)的非功能需求是致命的。 質(zhì)量屬性分為： 運行期質(zhì)量屬性 開發(fā)期質(zhì)量屬性 各類需求架構(gòu)設計的不同影響 高可移植性 對硬件和平臺相關特性進行封裝、 隔離 高性能 精心規(guī)劃職責模型在質(zhì)量屬性方面需求折衷質(zhì)量屬性分析的位置 質(zhì)量屬性分析是概念性架構(gòu)設計的重要步驟。 通過質(zhì)量屬性分析，制定出滿足非功能需求的高層設計決策。 質(zhì)量屬性分析所處的位置 如圖所示 ”屬性-場景-決策”表法 運用“關鍵需求決定架構(gòu)”的策略，使質(zhì)量屬性分析的“輸入”集中到關鍵質(zhì)量屬性需求。 “屬性-場景-決策”表方法提倡通過一組具體

27、場景將要達到的質(zhì)量屬性需求目標細化，再根據(jù)場景制定架構(gòu)決策。 “屬性-場景-決策“表法“屬性-場景-決策”表法的好處: 可操作性強。質(zhì)量熟悉需求是籠統(tǒng)的目標，而一組質(zhì)量場景使之明確化。 避免過度設計。借助“屬性-場景-決策”表對質(zhì)量場景進行評估，通過權(quán)衡場景發(fā)生的概率和遺漏它的代價，決定是否應滿足該場景的要求。 便于系統(tǒng)升級時參考。 例：可擴展性質(zhì)量屬性運用“屬性-場景-決策”表方法，細化PM Tool的可擴展性需求，制定架構(gòu)決策，如下表所示： 非功能需求對軟件架構(gòu)的影響比功能需求更大。 “屬性-場景-決策”表可以幫助軟件架構(gòu)師以一種更透明、更可操作的方式完成從質(zhì)量屬性需求到質(zhì)量場景的細化，最

28、終根據(jù)具體的場景有針對性地設計架構(gòu)決策。 架構(gòu)的目標正確性correctness可靠性（Reliable）： 軟件系統(tǒng)對于用戶的商業(yè)經(jīng)營和管理來說極為重要，因此軟件系統(tǒng)必須非常可靠。 健壯性robustness安全性（Secure） ： 軟件系統(tǒng)所承擔的交易的商業(yè)價值極高，系統(tǒng)的安全性非常重要?？缮炜s性（Scalable） ： 軟件必須能夠在用戶的使用率、用戶的數(shù)目增加很快的情況下，保持合理的性能。只有這樣，才能適應用戶的市場擴展得可能性?？啥ㄖ苹–ustomizable） ： 同樣的一套軟件，可以根據(jù)客戶群的不同和市場需求的變化進行調(diào)整?？蓴U展性（Extensible）： 在新技術(shù)出現(xiàn)的時

29、候，一個軟件系統(tǒng)應當允許導入新技術(shù)，從而對現(xiàn)有系統(tǒng)進行功能和性能的擴展可復用性reusability可維護性（Maintainable）： 軟件系統(tǒng)的維護包括兩方面，一是排除現(xiàn)有的錯誤，二是將新的軟件需求反映到現(xiàn)有系統(tǒng)中去。一個易于維護的系統(tǒng)可以有效地降低技術(shù)支持的花費。兼容性compatibility可移植性portability易用性ease of use高效性efficiencytimeliness,economy and functionality客戶體驗（Customer Experience）： 軟件系統(tǒng)必須易于使用。市場時機（Time to Market）： 軟件用戶要面臨同業(yè)競

30、爭，軟件提供商也要面臨同業(yè)競爭。以最快的速度爭奪市場先機非常重要。87軟件可維護性重型和輕型方法 重型方法：偏重于計劃、過程和中間產(chǎn)物 敏捷方法：更加看重人和溝通。人和溝通永遠是第一位的，而計劃、過程和中間產(chǎn)物，只是保證溝通、實現(xiàn)目標的手段。并非計劃、過程、中間產(chǎn)物不重要，但不能本末倒置。評判軟件成功的標準： 很多。對敏捷方法：首先在于交付可用的軟件。 為了保證軟件的可用性，需求是根本。對于架構(gòu)設計工作，從需求出發(fā)來設計架構(gòu)，是保證軟件可用性的基本的保證。 如何開始架構(gòu)設計工作 考慮的平臺、語言、開發(fā)環(huán)境、數(shù)據(jù)庫等 誤區(qū)：架構(gòu)設計就是寫一些空話，套話。 誤區(qū)：對與客戶具體情況密切相關的問題卻未

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

32、需要滿足每家每戶的需要，自來水管組成了一個龐大的網(wǎng)絡。在要滿足每家每戶的需要，自來水管組成了一個龐大的網(wǎng)絡。在這樣一個復雜的網(wǎng)絡中，如何完成鋪設的任務呢。一般的做法這樣一個復雜的網(wǎng)絡中，如何完成鋪設的任務呢。一般的做法是，先找出問題的根源，也就是水的源頭。從水源鋪設一條管是，先找出問題的根源，也就是水的源頭。從水源鋪設一條管道通至城市，然后根據(jù)城市的區(qū)域劃分，設計出主管道，剩下道通至城市，然后根據(jù)城市的區(qū)域劃分，設計出主管道，剩下的就是使用的問題了，每家每戶的管道最終都是連到主管道上的就是使用的問題了，每家每戶的管道最終都是連到主管道上的。因此，雖然自來水網(wǎng)絡龐大復雜。但是真正的主管道是比的。

33、因此，雖然自來水網(wǎng)絡龐大復雜。但是真正的主管道是比較簡單的。較簡單的。一般來說，功能需求決定業(yè)務架構(gòu)、非功能需求決定技術(shù)架構(gòu)，變化案例決定架構(gòu)的范圍。功能需求決定軟件能夠做些什么。我們需要根據(jù)業(yè)務上的需求來設計業(yè)務架構(gòu)，以使得未來的軟件能夠滿足客戶的需要。非功能需求定義了性能、效率上的一些約束、規(guī)則。而我們的技術(shù)架構(gòu)要能夠滿足這些約束和規(guī)則。變化案例是對未來可能發(fā)生的變化的一個估計，結(jié)合功能需求和非功能需求，我們就可以確定一個需求的范圍，進而確定一個架構(gòu)的范圍。例：一個字處理軟件，功能需求可以簡單概括為格式化用戶輸入的文例：一個字處理軟件，功能需求可以簡單概括為格式化用戶輸入的文字，非功能需求

34、可能是格式化大小為字，非功能需求可能是格式化大小為1000K的一段文字的處理速度不的一段文字的處理速度不能低于能低于10S，變化案例可能是推出多種語言版本。則在設計業(yè)務架構(gòu)，變化案例可能是推出多種語言版本。則在設計業(yè)務架構(gòu)時，我們會集中于如何表示文字、圖象、媒體等要素，此外需要有另時，我們會集中于如何表示文字、圖象、媒體等要素，此外需要有另外的技術(shù)架構(gòu)來處理速度問題，比如緩沖技術(shù)，對于變化案例，我們外的技術(shù)架構(gòu)來處理速度問題，比如緩沖技術(shù)，對于變化案例，我們也要考慮相應的架構(gòu)，比如把字體獨立于程序包的設計。也要考慮相應的架構(gòu)，比如把字體獨立于程序包的設計。架構(gòu)設計的兩項工作 分析：分析是分析需

35、求 設計：設計軟件的大致結(jié)構(gòu)。 很多方法論分離二者，其實無一定的界限，做分析的時候會想到如何設計，而思考如何設計反過來又會影響分析的效果?？梢哉f，兩者間是相互聯(lián)系和不斷迭代的。需求與架構(gòu)都應迭代進行 一點一點的作需求。這種做法在那些需求變化快的項目中尤其適用。 由于我們采用的流程是一種迭代式的流程，這里我們將會面臨著如何對待上一次迭代的中間產(chǎn)物的問題。如果我們每一次迭代都需要修改已存在的中間產(chǎn)物，那么這種維護的成本未免過大。因此，敏捷方法論的基本做法是，扔掉那些已經(jīng)沒有用處的中間產(chǎn)物。 軟件要比文檔重要。生成中間產(chǎn)物的目的都是為了生成最終的程序，對于這些已經(jīng)完成作用的模型，沒有必要付出額外的維

36、護成本。 架構(gòu)設計中的一些提示（也是拋棄模型的必要條件）：簡單化：簡單化：簡單的模型和簡單的程序。模型和程序越復雜，就需要更多的精力來處理它們。因此盡可能簡化它們，為的是更容易的處理它們。高效溝通渠道：高效溝通渠道：通過增強溝通的效果來減少對中間產(chǎn)物的需要。試想若隨時能從客戶處得到需求的細節(jié)資料，則前期需求調(diào)研就沒有必要做得太細。角色交叉輪換：角色交叉輪換：開發(fā)人員間建立起交換角色的機制，能夠盡量的避免各子系統(tǒng)諸侯割據(jù)的局面。清晰的流程：清晰的流程：或明確的過程。過程在方法論中是重點，敏捷方法論也不例外。開發(fā)人員能夠清楚的知道，今天做什么，明天做什么。過程不是給別人看的，而是給自己用的。工具：

37、工具：好用的工具能夠節(jié)省大量的時間，工具并不僅指CASE工具，還包括版本控制工具、自動測試工具、畫圖工具、文檔制作和管理工具。使用工具要注意成本和效益的問題。標準和風格：標準和風格：語言標準不同是溝通的很大障礙。語言從某個角度來看屬于一種標準、一種風格。因此，一個團隊如果采用同樣的編碼標準、文檔標準、注釋風格、制圖風格，那么這個團隊的溝通效率一定非常高。如果上述的環(huán)境都不具備，或是欠缺好幾項，那你的文檔的模型還是留著的好。僅針對需求設計架構(gòu)僅針對需求設計架構(gòu) 不要做未來才有用的事情。 有時我們會把架構(gòu)考慮得非常復雜，主要原因是把很多未來的因素放入到現(xiàn)在來考慮。 或在開發(fā)第一個產(chǎn)品的時候就試圖做

38、成完美的框架。 以上的這兩種思路有沒有錯呢？沒有錯，這只是如何看待投入的問題，有人希望開始的時候多投入一些，這樣后續(xù)的投入就會節(jié)省下來。但在現(xiàn)實中，由于需求的不確定性，希望通過增加開始階段的投入來將降低未來的投入往往是難以做到的，框架的設計也絕非一蹴而就的，因此這種做法并不好。 同其它很多事物一樣，架構(gòu)設計應保持簡單性和迭代過程！引入模式引入模式 模式幫助我們抓住重點。 為了解決設計文檔編輯器引出的七個問題，一共使用了8種不同的模式。這8種模式的組合其實就是架構(gòu)，因為它們解決的，都是系統(tǒng)中最高層的問題。 架構(gòu)也是存在模式的。比如，對于系統(tǒng)結(jié)構(gòu)設計，我們使用層模式；對于分布式系統(tǒng)，我們使用代理模

39、式；對于交互系統(tǒng)，我們使用MVC（模型-視圖-控制器）模式。模式本來就是針對特定問題的解，因此，針對需求的特點，我們也可以采用相應的模式來設計架構(gòu)。PetShot案例 在MVC圖背后隱藏著的需求： 系統(tǒng)需要支持多種用戶界面，包括為普通用戶提供的HTML界面，為無線用戶提供的WML界面，為管理員提供的Swing界面，以及為B2B業(yè)務設計的WebService界面。這是系統(tǒng)最重要的需求，因此，系統(tǒng)的設計者就需要確定一個穩(wěn)定的架構(gòu)，以解決多界面的問題。 相對于多界面的問題，后端的業(yè)務處理邏輯都是一致的。比如HTML界面和WML界面的功能并沒有太大的差別。把處理邏輯和界面分離開來還有額外的好處，可以在

40、添加功能的同時，不涉及界面的改動，反之亦然。（耦合度的問題）。 MVC模式正可以適用于解決該問題。系統(tǒng)使用控制器來為業(yè)務邏輯選擇不同的界面，這就完成了MVC架構(gòu)的設計思路。在架構(gòu)設計的工作中，我們手頭上有模式這樣一張好牌，有什么理由不去使用它呢？抓住重點抓住重點 架構(gòu)是一種抽象，即架構(gòu)設計摒棄了具體的細節(jié)，僅僅抓住軟件最高層的概念，也就是最上層、優(yōu)先級最高、風險最大的那部分需求。 考慮、分析、解決一個問題，一定有一個漸進的過程。架構(gòu)設計就是解決問題其中比較早期的一個階段，我們不會在架構(gòu)設計這個階段投入過多的時間，因此關鍵點在于我們要能夠在架構(gòu)設計中把握住需求的重點。 比如，分布式系統(tǒng)和交互系統(tǒng)

41、，分布和交互就是這兩個系統(tǒng)的重點。那么，如果說我們面對的是一個分布式的交互系統(tǒng)，那么，我們就需要把這兩種特性做為重點來考慮，并以此為基礎，設計架構(gòu)。而寵物商店的范例也是類似的，除了MVC的架構(gòu)，還有很多的設計問題需要解決，例如用于數(shù)據(jù)庫訪問的數(shù)據(jù)對象，用于視圖管理的前端控制器等。但是這些相對于MVC模式來說，屬于局部的，優(yōu)先級較低的部分，可以在架構(gòu)確定后再來設計。架構(gòu)設計和領域?qū)＜壹軜?gòu)設計和領域?qū)＜?一個架構(gòu)要設計的好，和對需求的理解是分不開的。因此在現(xiàn)實中，業(yè)務領域?qū)＜覒{借著他對業(yè)務領域的了解，能夠幫助開發(fā)人員設計出優(yōu)秀的架構(gòu)來。 架構(gòu)是需要抽象的，它是現(xiàn)實社會活動的一個基本模型，而業(yè)務領域

42、的模型僅僅憑開發(fā)人員是很難設計出來的。在ERP的發(fā)展史上，MRP發(fā)展為MRPII，再發(fā)展到閉環(huán)MRP，直到發(fā)展成為現(xiàn)在的ERP，主要的因素是管理思想的演化，也就是說，對業(yè)務領域的理解進步了，架構(gòu)才有可能進步。 因此，敏捷型架構(gòu)設計的過程中，我們也非常強調(diào)領域?qū)＜业淖饔谩?軟件約束條件與架構(gòu)的影響 資金 時間 業(yè)務 運行環(huán)境 開發(fā)團隊 實現(xiàn)技術(shù)等104領域模型設計領域模型（Domain Model） 商業(yè)建模范疇的概念： 同行業(yè)企業(yè)的業(yè)務模型必定有很大的共性和內(nèi)在的規(guī)律性，由這個行業(yè)內(nèi)的各個企業(yè)的業(yè)務模型再向上抽象出來整個行業(yè)的業(yè)務模型，即領域模型。 技術(shù)建模范疇的概念：用編程語言來實現(xiàn)商業(yè)領域

43、模型。關系： 對行業(yè)經(jīng)驗積累不足的軟件公司，開發(fā)軟件由需求驅(qū)動，而非商業(yè)的領域模型驅(qū)動。 商業(yè)領域模型與編程語言的不是一對一的對應關系。例如用EJB2模型，需要最少兩個以上的EJB，即一個 Session Bean，處理面向流程的控制邏輯，一個Entity Bean，處理面向持久化的實體邏輯（持久化操作附著在Entity Bean的Home接口上）。如果是更加復雜的領域模型，則需要更多的EJB，一般一個領域模型需要多個Entity Bean和多個Session Bean。 使用基于POJO模型的實現(xiàn)，則粗顆粒度的EJB要繼續(xù)細分：一個Entity Bean對應三個以上POJO：一個或者多個實體

44、類，DAO接口、DAO接口實現(xiàn)類；一個Session Bean要切分為多個業(yè)務Bean。105106層次結(jié)構(gòu)領域模型從EJB到輕量級框架107層次結(jié)構(gòu)表現(xiàn)層（present）業(yè)務層 業(yè)務層外觀 業(yè)務服務層 領域?qū)ο蠊芾?服務/倉庫層 領域?qū)ο髮映志脤?數(shù)據(jù)訪問層數(shù)據(jù)庫108領域模型中的各種角色： 實體-有唯一的標識,并且要有屬性和行為(非GET/SET)，添加了行為，使其具有生命力。往往在設計時，實體的形為最難決斷。為確定行為，我們必須識別它們的責任和協(xié)作。類的責任是指該類要做、知道、或決定的一切，由一個或多個方法完成。類中有屬性和關聯(lián)，協(xié)作就是為完成自己的責任所調(diào)用其它關聯(lián)類。 值對象-沒有

45、標識沒有行為。如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è)務邏輯可以分散

46、到實體對象中。1092、層次之間的交互 A、頁面提交表單數(shù)據(jù)到Action，Action創(chuàng)建DTO對象并設置相應屬性值為表單數(shù)據(jù) B、Action傳遞DTO對象給Facade C、Facade中套用ServiceTemplate事務模板以加入事務管理，在ServiceTemplate中根據(jù)具體業(yè)務調(diào)用Factory或Reposistory，分別create或者load出DomainModel對象 D、Facade傳遞DomainModel對象給Service E、Service執(zhí)行具體業(yè)務邏輯（調(diào)用DomainModel對象相應的業(yè)務方法） F、Service調(diào)用Reposistory對狀態(tài)已

47、改變的DomainModel對象進行持久化操作（調(diào)用相應DAO） 110注： 在Facade或Service中如果需要查詢DomainModel對象中的屬性值，調(diào)用DomainModel對象的getDataInfo()方法得到DataInfo對象，通過DataInfo對象查詢所需數(shù)據(jù)，包括Service返回給Faade業(yè)務處理結(jié)果中所包含的業(yè)務數(shù)據(jù)。 111112領域模型失血模型貧血模型充血模型脹血模型113失血模型DO只有屬性及其getter/setter方法，沒有任何業(yè)務邏輯。缺點：行為與數(shù)據(jù)分離，很多情況導致維護與理解困難。114貧血模型DO包含不依賴于持久化的領域邏輯；依賴持久化的領域

48、邏輯歸入Service層。 Service(業(yè)務邏輯，事務封裝) DAO DO優(yōu)點： 各層單向依賴，結(jié)構(gòu)清楚，易于實現(xiàn)和維護。 設計簡單易行，底層模型非常穩(wěn)定。缺點： DO部分的持久化邏輯被放入Service層，不夠OO。 Service層過重。115充血模型與貧血模型類似，不同處在于如何劃分業(yè)務邏輯：絕大多業(yè)務邏輯都應該放在DO里(包括持久化邏輯)，而Service層很薄，僅僅封裝事務和少量邏輯，不和DAO層打交道。 Service(事務封裝) DO DAO優(yōu)點： 符合OO Service層很薄，只充當Facade的角色，不和DAO打交道。116缺點： DAO和DO雙向依賴。 如何劃分Ser

49、vice層邏輯和Domain層邏輯沒有確定的規(guī)則，取決與設計人員自己的理解。 Service層封裝事務，須對所有的DO邏輯提供相應的事務封裝方法，造成重定義所有的Domain logic。 Service的事務化封裝的意義等于把OO的Domain logic轉(zhuǎn)換為過程的Service 事務腳本。充血模型在domain層實現(xiàn)的OO在Service層又變成了面向過程。 117脹血模型取消Service層，只剩下DO和DAO層，在DO的domain logic上面封裝事務。 DO(事務封裝，業(yè)務邏輯) DAO (RoR甚至合并為一層） 優(yōu)點： 分層簡化 符合OO缺點： service邏輯也強行放入D

50、O ，引起了DO不穩(wěn)定。 DO暴露給web層過多的信息，可能引起不必要的耦合。118原則： 業(yè)務對象封裝了內(nèi)在的業(yè)務邏輯，而應用服務封裝了外在于業(yè)務對象的業(yè)務邏輯。 119EJB到輕量級框架EJBPOJO （業(yè)務邏輯） + 輕量級框架（Hibernate、JDO、iBATIS（持久化）、Spring（事務管理、安全）120EJBEJB：編寫分布式業(yè)務應用程序的Java標準架構(gòu)。提供大量服務： 聲明型事務, EIB容器自動啟動、提交和回滾事務。 業(yè)務邏輯能參與由遠程客戶發(fā)起的分布式事務。 提供聲明型安全，大部分情況下不再搖要編寫安全代碼求（bean部署描述符里的條目指定準可以防問某個具體bean

51、）。121例：在兩個賬號間進行轉(zhuǎn)賬的服務。122123新設計是面向?qū)ο?、基于POJO, 而非基于EJB的過程式。它使用構(gòu)建在JDBC上的持久層框架來訪問數(shù)據(jù)庫, 并不直接使用JDBC。業(yè)務邏輯由POJO facade而非會話bean進行封裝。事務由Spring框架而非EJB容器進行管理。業(yè)務邏輯向表現(xiàn)層返回實際的業(yè)務對象,而不是DTO。應用程序通過將組件的依賴作為setter或構(gòu)造子參數(shù)傳入來進行組裝,而不是之前采用Java命名和目錄接口(JNDI )查詢的組件。由于該設計面向?qū)ο?并采用上述輕量級技術(shù),因此較之前看到的EJB版本對開發(fā)人員要友好。124基于輕量級框架設計的好處是，它提供事務和

52、持久化時并不要求應用程序類實現(xiàn)任何特殊接口。甚至當應用程序的類需要運行在事務里或是持久的時候，它們?nèi)允荘OJO，設計者可以繼續(xù)享受POJO的種種好處。125126面向?qū)ο蟮膬?yōu)點： 整個設計更易理解和維護。它并不是一個無所不能的大型類, 而是由大量小類組成, 每個類只共有若干職責。此外,諸如Account、BankingTransaction和OverdraftPolicy類都與現(xiàn)實世界的概念對應, 因此易于理解。 其次,面向?qū)ο笤O汁也更易測試: 所有類都能并且應當進行獨立的測試。EJB只能通過調(diào)用它的public 方法如Transter進行測試,難度大。(只能測試p-blic方法暴露的復雜功能

53、,無法測試其中簡單的部分）。 面向?qū)ο笙笤O計更易擴展, 它可使用設計模式，如Stategy和Template等。EJB風格的過程式設計往往需耍修改核心代碼。127不適合用面向?qū)ο蟮膱龊希?大量數(shù)據(jù)集合的關系操作。 以數(shù)據(jù)庫為中心的管理程序 ：這個領域所對應的現(xiàn)實世界是一個面向關系的世界，表與表的關聯(lián)體現(xiàn)的是彼此的業(yè)務關系。 復雜的SQL固然不好維護，但業(yè)務真是復雜到簡單的SQL都難以描述的程度，采用面向?qū)ο竺枋鰟t更加困難，維護也更困難，同時還損失了效率。 比較大的事務。 性能要求高的地方。（直接用Sql或者存儲過程；犧牲可維護性和可復用性） 上層流程。128消除DTO129部署POJO程序13

54、0131軟件架構(gòu)模式分析及其實際運用 軟件架構(gòu) 軟件架構(gòu)概論 架構(gòu)的目標 架構(gòu)的種類軟件框架常見的架構(gòu)模式軟件架構(gòu)概論系統(tǒng)架構(gòu)是一個軟件系統(tǒng)從整體到部分的最高層次的劃分。一個系統(tǒng)通常是由元件組成的，而這些元件如何形成、相互之間如何發(fā)生作用，則是關于這個系統(tǒng)本身結(jié)構(gòu)的重要信息。詳細地說，就是要包括架構(gòu)元件（Architecture Component）、聯(lián)結(jié)器（Connector）、任務流（Task-flow）。所謂架構(gòu)元素，也就是組成系統(tǒng)的核心磚瓦，而聯(lián)結(jié)器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結(jié)果，任務流則描述系統(tǒng)如何使用這些元件和聯(lián)結(jié)器完成某一項需求。建造一個系統(tǒng)所作出的最高

55、層次的、以后難以更改的，商業(yè)的和技術(shù)的決定。在建造一個系統(tǒng)之前會有很多的重要決定需要事先作出，而一旦系統(tǒng)開始進行詳細設計甚至建造，這些決定就很難更改甚至無法更改。顯然，這樣的決定必定是有關系統(tǒng)設計成敗的最重要決定，必須經(jīng)過慎重的研究和考察。架構(gòu)的種類根據(jù)我們關注的角度不同，可以將架構(gòu)分成三種： 邏輯架構(gòu) 物理架構(gòu) 系統(tǒng)架構(gòu)邏輯架構(gòu)軟件系統(tǒng)中元件之間的關系，比如用戶界面，數(shù)據(jù)庫，外部系統(tǒng)接口，商業(yè)邏輯元件等等。物理架構(gòu)軟件元件是怎樣放到硬件上的下圖描述了一個分布于北京和上海的分布式系統(tǒng)的物理架構(gòu)，圖中所有的元件都是物理設備，包括網(wǎng)絡分流器、代理服務器、WEB服務器、應用服務器、報表服務器、整合服

56、務器、存儲服務器、主機等等。系統(tǒng)架構(gòu)系統(tǒng)的非功能性特征，如可擴展性、可靠性、強壯性、靈活性、性能等。系統(tǒng)架構(gòu)的設計要求架構(gòu)師具備軟件和硬件的功能和性能的過硬知識，這一工作是架構(gòu)設計工作中最困難的工作。架構(gòu)的兩要素元件劃分和設計決定。邏輯元件： 一個軟件系統(tǒng)中的元件首先是邏輯元件。這些邏輯元件如何放到硬件上，以及這些元件如何為整個系統(tǒng)的可擴展性、可靠性、強壯性、靈活性、性能等做出貢獻，是非常重要的信息。設計決定： 進行軟件設計需要做出的決定中，必然會包括邏輯結(jié)構(gòu)、物理結(jié)構(gòu)，以及它們?nèi)绾斡绊懙较到y(tǒng)的所有非功能性特征。這些決定中會有很多是一旦作出，就很難更改的。基于數(shù)據(jù)庫的系統(tǒng)架構(gòu)： 一般有多少個數(shù)

57、據(jù)表，就會有多少頁的架構(gòu)設計文檔。比如一個中等的數(shù)據(jù)庫應用系統(tǒng)通常含有一百個左右的數(shù)據(jù)表，這樣的一個系統(tǒng)設計通常需要有一百頁左右的架構(gòu)設計文檔。從概念性架構(gòu)到實際架構(gòu)從概念性架構(gòu)到實際架構(gòu) 就是多 (Less is more.)。 - 密斯凡德羅 概念性架構(gòu)是對系統(tǒng)設計的最初構(gòu)想。 一般來說，實際的軟件架構(gòu)設計過程是，先進行概念性架構(gòu)的設計，把最關鍵的設計要素和交互機制確定下來，然后再考慮具體技術(shù)的運用，設計出實際架構(gòu)。 架構(gòu)設計中的關鍵要素及解決策略架構(gòu)設計中的關鍵要素及解決策略 策略是制勝的關鍵。- 張明正，擋不住的趨勢 最好的軟件開發(fā)人員都知道一個秘密：美的東西比丑的東西創(chuàng)建起來更廉價，

58、也更快捷。- Robert C. Martin, 軟件之美 時間就是系統(tǒng)架構(gòu)的生命。- Philippe Kruchten 方法產(chǎn)生于恐懼。 面對時間緊迫的壓力，我們有理由質(zhì)疑那種不顧時間花銷、一味追求軟件架構(gòu)高質(zhì)量的做法。軟件架構(gòu)是軟件系統(tǒng)質(zhì)量的核心，必須足夠重視，但在不適當?shù)臅r候“用時間換完美”會毀掉整個項目。 架構(gòu)設計并非“好的就是成功的”，而是“適合的才是成功的”。 方法論 Alistair Cockburn 的七條定理，總結(jié)為：溝通和反饋。 RUP、XP 重量之爭軟件架構(gòu)設計中的關鍵要素及解決策略： 關鍵要素關鍵要素 策略策略 - -1. 是否遺漏了至關重要的非功能需求？ 全面認識需

59、求。2. 能否馴服數(shù)量巨大且頻繁變化的需求？ 關鍵需求決定架構(gòu)。3. 能否從容地設計軟件架構(gòu)的不同方面？ 多視圖探尋架構(gòu)。4. 是否及早驗證架構(gòu)方案并作出了調(diào)整？ 及早驗證架構(gòu)。 軟件架構(gòu)設計過程總覽軟件架構(gòu)設計過程總覽一般的軟件過程： 需求分析的幾個概念 需求捕獲 vs 需求分析 vs 系統(tǒng)分析 需求捕獲是獲取知識的過程，知識從無到有。 需求分析是挖掘和整理知識的過程，它在已掌握知識的基礎上進行。 系統(tǒng)分析？如果說需求分析致力于“做什么”，那么系統(tǒng)分析則涉及“怎么做”。 軟件架構(gòu)師不必是需求捕獲專家，也不必是編寫軟件需求規(guī)格說明書的專家。但他一定應在需求分類、需求折衷和需求變更的研究方面是專

60、家，否則他和其他軟件架構(gòu)師相比，就輸在了“起跑線”上。 概念性架構(gòu)設計概念性架構(gòu)設計概念性架構(gòu)設計的迭代方式： 1. 魯棒性分析； 2. 引入架構(gòu)模式； 3. 質(zhì)量屬性分析。 魯棒性分析 所謂魯棒性分析是這樣一種方法：通過分析用例規(guī)約中的事件流，識別出實現(xiàn)用例規(guī)定的功能所需的主要對象及其職責，形成以職責模型為主的初步設計。 魯棒性分析是從功能需求向設計方案過度的第一步，所獲得的初步設計是一種理想化的職責模型，它的重點是識別組成軟件系統(tǒng)的高級職責塊、規(guī)劃它們之間的關系。 魯棒性分析填補了分析和設計之間的鴻溝。 魯棒圖包含三種元素：邊界對象、控制對象和實體對象。引入架構(gòu)模式 較為經(jīng)典的幾種架構(gòu)模式： 分層