高級軟件架構(gòu)設計師實戰(zhàn)

1高級軟件架構(gòu)設計師實戰(zhàn)康凱軟件系統(tǒng)開始壞死的病癥一個軟件系統(tǒng)開始壞死時表現(xiàn)的病癥有:硬化Rigidity——系統(tǒng)變得越來越難以變更,修復或增添新功能的代價高昂;脆弱Fragility——對系統(tǒng)的任何哪怕是微小的變更都可能造成四處(甚至是與變更處沒有邏輯上的關聯(lián)之處J崩潰;綁死Immobility——抽取系統(tǒng)的任何局部用來復用都非常困難;膠著Viscosity——以與原有設計保持一致的方式來對實施變更已經(jīng)非常困難,誘使開發(fā)人員繞過它選擇容易但有害的途徑,其結(jié)果卻使系統(tǒng)死的更快。

什么是軟件架構(gòu)軟件架構(gòu)的概念很混亂。如果你問五個不同的人，可能會得到五種不同的答案。軟件架構(gòu)概念主要分為兩大流派：組成派：軟件架構(gòu)=組件+交互。決策派：軟件架構(gòu)=重要決策集。組成派和決策派的概念相輔相成。軟件架構(gòu)要層次化并隔離關注點復雜性是層次化的。--《人月神話》好的架構(gòu)設計必須把變化點錯落有致地封裝到軟件系統(tǒng)的不同局部(即關注點別離)。通過關注點別離，到達“系統(tǒng)中的一局部發(fā)生了變化，不會影響其他局部”的目標。軟件單元的粒度：粒度最小的單元通常是“類”。幾個類緊密協(xié)作形成“模塊”。完成相對獨立的功能的多個模塊構(gòu)成了“子系統(tǒng)”。多個子系統(tǒng)相互配合才能滿足一個完整應用的需求，從而構(gòu)成了軟件“系統(tǒng)”。一個大型企業(yè)往往使用多套系統(tǒng)，多套系統(tǒng)通過互操作形成“集成系統(tǒng)”。軟件單元的粒度是相對的。同一個軟件單元，在不同場景下我們會以不同的粒度看待它。架構(gòu)(Architecture)與框架(Framework)?？蚣苤皇且环N特殊的軟件，框架也有架構(gòu)。可以通過架構(gòu)框架化到達“架構(gòu)重用”的目的，如很多人都在用Spring框架提供的控制反轉(zhuǎn)和依賴注入來構(gòu)建自己的架構(gòu)。軟件架構(gòu)的作用如果一個工程的系統(tǒng)架構(gòu)(包括理論根底)尚未確定，就不應該進行此系統(tǒng)的全面開發(fā)。--BarryBoehm,《EngineeringContext》一個缺陷充滿的系統(tǒng)，將始終是一個缺陷充滿的系統(tǒng)。--TimothyC.Lethbridge,《面向?qū)ο筌浖こ獭奋浖軜?gòu)設計為什么這么難？因為它是跨越現(xiàn)實世界與計算機世界之間鴻溝的一座橋。軟件架構(gòu)設計要完成從面向業(yè)務到面向技術的轉(zhuǎn)換，在鴻溝上架起一座橋梁。需求->架構(gòu)設計->軟件架構(gòu)->系統(tǒng)開發(fā)->軟件系統(tǒng)軟件架構(gòu)對新產(chǎn)品開發(fā)的作用：上承業(yè)務目標。下接技術決策?？刂茝碗s性。先進行架構(gòu)設計，后進行詳細設計和編碼實現(xiàn)，符合“基于問題深度分而治之”的理念。組織開發(fā)。軟件架構(gòu)方案在小組中間扮演了“橋梁”和“合作契約”的作用。利于迭代開發(fā)和增量交付。以架構(gòu)為中心進行開發(fā)，為增量交付提供了良好的根底。在架構(gòu)經(jīng)過驗證之后，可以專注于功能的增量提交。提高質(zhì)量。軟件產(chǎn)品線：指具有一組可管理的、公共特性的、軟件密集性系統(tǒng)的集合，這些系統(tǒng)滿足特定的市場需求或任務需求，并且按照預定義方式從一個公共的核心資產(chǎn)集開發(fā)得到。軟件產(chǎn)品線架構(gòu)：針對一個公司或組織內(nèi)的一系列產(chǎn)品而設計的通用架構(gòu)。軟件架構(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ā)布系統(tǒng)：功能需求：用戶可以通過瀏覽器瀏覽媒體的發(fā)布。據(jù)此初步設計出采用瀏覽器插件的方案；約束條件：不能影響用戶瀏覽器的平安性；細化設計方案，需要對插件進行認證，自動判別客戶端是否存在，及版本比較；自動下載注冊等。使用期質(zhì)量屬性：為保證瀏覽的流暢，應減少中間等待的時間，因此應對下一步需使用的媒體做預測等。制作發(fā)布期的質(zhì)量保證：保證在遇到較大的媒體時能保持瀏覽的流暢，應在發(fā)布時將視頻等流式化。軟件系統(tǒng)的需求種類復雜什么是軟件架構(gòu)視圖個架構(gòu)視圖是對于從某一視角或某一點上看到的系統(tǒng)所做的簡化描述，描述中涵蓋了系統(tǒng)的某一特定方面，而省略了于此方面無關的實體。架構(gòu)要涵蓋的內(nèi)容和決策太多了，超過了人腦“一蹴而就”的能力范圍，因此采用“分而治之”的方法從不同視角分別設計；同時，也為軟件架構(gòu)的理解、交流和歸檔提供了方便。多視圖方法是軟件架構(gòu)歸檔的方法，更是指導我們進行架構(gòu)設計的思維方法。邏輯架構(gòu)邏輯架構(gòu)關注功能。其設計著重考慮功能需求。開發(fā)架構(gòu)開發(fā)架構(gòu)關注程序包。其設計著重考慮開發(fā)期質(zhì)量屬性，如可擴展性、可重用性、可移植性、易理解性和易測試性等。運行架構(gòu)運行架構(gòu)關注進程、線程、對象等運行時概念，以及相關的并發(fā)、同步、通信等問題。其設計著重考慮運行期質(zhì)量屬性，例如性能、可伸縮性、持續(xù)可用性和平安性等。物理架構(gòu)物理架構(gòu)關注軟件系統(tǒng)最終如何安裝或部署到物理機器。其設計著重考慮“安裝和部署需求”。以及如何部署機器和網(wǎng)絡來配合軟件系統(tǒng)的可靠性、可伸縮性等要求。數(shù)據(jù)架構(gòu)數(shù)據(jù)架構(gòu)關注持久化數(shù)據(jù)的存儲方案。設計著重考慮“數(shù)據(jù)需求”。關系邏輯視圖。邏輯視圖不僅關注用戶可見的功能，還包括為實現(xiàn)用戶功能而必須提供的“輔助功能模塊”；它們可能是邏輯層、功能模塊等。開發(fā)視圖。開發(fā)視圖關注程序包，不僅包括要編寫的源程序，還包括可以直接使用的第三方SDK和現(xiàn)成框架、類庫，以及開發(fā)的系統(tǒng)將運行于其上的系統(tǒng)軟件或中間件。開發(fā)視圖和邏輯視圖之間可能存在一定的映射關系：比方邏輯層一般會映射到多個程序包等。運行視圖。和開發(fā)視圖的關系：開發(fā)視圖一般偏重程序包在編譯時期的靜態(tài)依賴關系，而這些程序運行起來之后會表現(xiàn)為對象、線程、進程，運行視圖比較關注的正是這些運行時單元的交互問題。物理視圖。和運行視圖的關系：運行視圖特別關注目標程序的動態(tài)執(zhí)行情況，而物理視圖重視目標程序的靜態(tài)位置問題；物理視圖是綜合考慮軟件系統(tǒng)和整個IT系統(tǒng)相互影響的架構(gòu)視圖。

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

。42架構(gòu)要進行到什么程度軟件架構(gòu)是團隊開發(fā)的根底，應明確規(guī)定后期分頭開發(fā)所必須的公共設計約定，為分頭開發(fā)提供足夠的指導和限制。另一方面，具體的架構(gòu)設計程度還會因軟件工程的不同而不同。架構(gòu)設計對軟件的不同局部的設計程度并不是整齊劃一的。(通信機制、持久化機制、消息機制等對應的公共模塊；具體的業(yè)務功能模塊在架構(gòu)設計中往往設計程度不深。〕歸納：由于工程的不同、開發(fā)團隊情況的不同，軟件架構(gòu)的設計程度會有不同;軟件架構(gòu)應當為開發(fā)人員提供足夠的指導和限制。43高來高去式架構(gòu)設計的病癥不能為開發(fā)人員提供足夠的指導和限制的那種架構(gòu)設計方案。高來高去式架構(gòu)設計現(xiàn)象極為普遍，危害：缺少來自架構(gòu)的足夠的指導和限制，開發(fā)人員在進入分頭開發(fā)階段之后會碰到很多問題，并且容易造成管理混亂，溝通和協(xié)作效率低；對軟件質(zhì)量非常關鍵的全局性設計決定被拖延到分頭開發(fā)期間草率決定；沒有完成化解重大技術風險的職責；團隊成員對架構(gòu)師意見大，團隊士氣受到打擊。44病癥一：缺失重要架構(gòu)視圖。給團隊的不同角色提供指導。病癥二：架構(gòu)設計方案停留在概念性架構(gòu)的層面，全局性的設計決策最后由具體開發(fā)人員從局部視角考慮并確定下來，造成技術和管理上的種種問題。病癥三：名不副實的分層架構(gòu)。對各層之間交互接口和交互機制的設計嚴重缺乏。45架構(gòu)設計過程重型和輕型方法重型方法：偏重于方案、過程和中間產(chǎn)物敏捷方法：更加看重人和溝通。人和溝通永遠是第一位的，而方案、過程和中間產(chǎn)物，只是保證溝通、實現(xiàn)目標的手段。并非方案、過程、中間產(chǎn)物不重要，但不能本末倒置。評判軟件成功的標準：很多。對敏捷方法：首先在于交付可用的軟件。為了保證軟件的可用性，需求是根本。對于架構(gòu)設計工作，從需求出發(fā)來設計架構(gòu)，是保證軟件可用性的根本的保證。

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

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

僅針對需求設計架構(gòu)不要做未來才有用的事情。有時我們會把架構(gòu)考慮得非常復雜，主要原因是把很多未來的因素放入到現(xiàn)在來考慮。或在開發(fā)第一個產(chǎn)品的時候就試圖做成完美的框架。以上的這兩種思路有沒有錯呢？沒有錯，這只是如何看待投入的問題，有人希望開始的時候多投入一些，這樣后續(xù)的投入就會節(jié)省下來。但在現(xiàn)實中，由于需求的不確定性，希望通過增加開始階段的投入來將降低未來的投入往往是難以做到的，框架的設計也絕非一蹴而就的，因此這種做法并不好。同其它很多事物一樣，架構(gòu)設計應保持簡單性和迭代過程！引入模式模式幫助我們抓住重點。為了解決設計文檔編輯器引出的七個問題，一共使用了8種不同的模式。這8種模式的組合其實就是架構(gòu)，因為它們解決的，都是系統(tǒng)中最高層的問題。架構(gòu)也是存在模式的。比方，對于系統(tǒng)結(jié)構(gòu)設計，我們使用層模式；對于分布式系統(tǒng)，我們使用代理模式；對于交互系統(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界面的功能并沒有太大的差異。把處理邏輯和界面別離開來還有額外的好處，可以在添加功能的同時，不涉及界面的改動，反之亦然?！柴詈隙鹊膯栴}〕。

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)，分布和交互就是這兩個系統(tǒng)的重點。那么，如果說我們面對的是一個分布式的交互系統(tǒng)，那么，我們就需要把這兩種特性做為重點來考慮，并以此為根底，設計架構(gòu)。而寵物商店的范例也是類似的，除了MVC的架構(gòu)，還有很多的設計問題需要解決，例如用于數(shù)據(jù)庫訪問的數(shù)據(jù)對象，用于視圖管理的前端控制器等。但是這些相對于MVC模式來說，屬于局部的，優(yōu)先級較低的局部，可以在架構(gòu)確定后再來設計。架構(gòu)設計和領域?qū)＜乙粋€架構(gòu)要設計的好，和對需求的理解是分不開的。因此在現(xiàn)實中，業(yè)務領域?qū)＜覒{借著他對業(yè)務領域的了解，能夠幫助開發(fā)人員設計出優(yōu)秀的架構(gòu)來。架構(gòu)是需要抽象的，它是現(xiàn)實社會活動的一個根本模型，而業(yè)務領域的模型僅僅憑開發(fā)人員是很難設計出來的。在ERP的開展史上，MRP開展為MRPII，再開展到閉環(huán)MRP，直到開展成為現(xiàn)在的ERP，主要的因素是管理思想的演化，也就是說，對業(yè)務領域的理解進步了，架構(gòu)才有可能進步。因此，敏捷型架構(gòu)設計的過程中，我們也非常強調(diào)領域?qū)＜业淖饔谩＼浖s束條件與架構(gòu)的影響資金時間業(yè)務運行環(huán)境開發(fā)團隊實現(xiàn)技術等63領域模型設計領域模型〔DomainModel〕商業(yè)建模范疇的概念：同行業(yè)企業(yè)的業(yè)務模型必定有很大的共性和內(nèi)在的規(guī)律性，由這個行業(yè)內(nèi)的各個企業(yè)的業(yè)務模型再向上抽象出來整個行業(yè)的業(yè)務模型，即領域模型。技術建模范疇的概念：用編程語言來實現(xiàn)商業(yè)領域模型。關系：對行業(yè)經(jīng)驗積累缺乏的軟件公司，開發(fā)軟件由需求驅(qū)動，而非商業(yè)的領域模型驅(qū)動。商業(yè)領域模型與編程語言的不是一對一的對應關系。例如用EJB2模型，需要最少兩個以上的EJB，即一個SessionBean，處理面向流程的控制邏輯，一個EntityBean，處理面向持久化的實體邏輯〔持久化操作附著在EntityBean的Home接口上〕。如果是更加復雜的領域模型，那么需要更多的EJB，一般一個領域模型需要多個EntityBean和多個SessionBean。使用基于POJO模型的實現(xiàn)，那么粗顆粒度的EJB要繼續(xù)細分：一個EntityBean對應三個以上POJO：一個或者多個實體類，DAO接口、DAO接口實現(xiàn)類；一個SessionBean要切分為多個業(yè)務Bean。6465層次結(jié)構(gòu)領域模型從EJB到輕量級框架66層次結(jié)構(gòu)表現(xiàn)層〔present〕業(yè)務層業(yè)務層外觀業(yè)務效勞層領域?qū)ο蠊芾?效勞/倉庫層領域?qū)ο髮映志脤訑?shù)據(jù)訪問層數(shù)據(jù)庫67領域模型中的各種角色：實體--有唯一的標識,并且要有屬性和行為(非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è)務邏輯可以分散到實體對象中。682、層次之間的交互A、頁面提交表單數(shù)據(jù)到Action，Action創(chuàng)立DTO對象并設置相應屬性值為表單數(shù)據(jù)B、Action傳遞DTO對象給FacadeC、Facade中套用ServiceTemplate事務模板以參加事務管理，在ServiceTemplate中根據(jù)具體業(yè)務調(diào)用Factory或Reposistory，分別create或者load出DomainModel對象D、Facade傳遞DomainModel對象給ServiceE、Service執(zhí)行具體業(yè)務邏輯〔調(diào)用DomainModel對象相應的業(yè)務方法〕F、Service調(diào)用Reposistory對狀態(tài)已改變的DomainModel對象進行持久化操作〔調(diào)用相應DAO〕69注：在Facade或Service中如果需要查詢DomainModel對象中的屬性值，調(diào)用DomainModel對象的getDataInfo()方法得到DataInfo對象，通過DataInfo對象查詢所需數(shù)據(jù)，包括Service返回給Fa?ade業(yè)務處理結(jié)果中所包含的業(yè)務數(shù)據(jù)。7071領域模型失血模型貧血模型充血模型脹血模型72失血模型DO只有屬性及其getter/setter方法，沒有任何業(yè)務邏輯。缺點：行為與數(shù)據(jù)別離，很多情況導致維護與理解困難。73貧血模型DO包含不依賴于持久化的領域邏輯；依賴持久化的領域邏輯歸入Service層。Service(業(yè)務邏輯，事務封裝)DAODO優(yōu)點：各層單向依賴，結(jié)構(gòu)清楚，易于實現(xiàn)和維護。設計簡單易行，底層模型非常穩(wěn)定。缺點：DO局部的持久化邏輯被放入Service層，不夠OO。Service層過重。74充血模型與貧血模型類似，不同處在于如何劃分業(yè)務邏輯：絕大多業(yè)務邏輯都應該放在DO里(包括持久化邏輯)，而Service層很薄，僅僅封裝事務和少量邏輯，不和DAO層打交道。Service(事務封裝)DODAO優(yōu)點：符合OOService層很薄，只充當Facade的角色，不和DAO打交道。75缺點：DAO和DO雙向依賴。如何劃分Service層邏輯和Domain層邏輯沒有確定的規(guī)那么，取決與設計人員自己的理解。Service層封裝事務，須對所有的DO邏輯提供相應的事務封裝方法，造成重定義所有的Domainlogic。Service的事務化封裝的意義等于把OO的Domainlogic轉(zhuǎn)換為過程的Service事務腳本。充血模型在domain層實現(xiàn)的OO在Service層又變成了面向過程。76脹血模型取消Service層，只剩下DO和DAO層，在DO的domainlogic上面封裝事務。DO(事務封裝，業(yè)務邏輯)DAO(RoR甚至合并為一層〕

優(yōu)點：分層簡化符合OO缺點：service邏輯也強行放入DO，引起了DO不穩(wěn)定。DO暴露給web層過多的信息，可能引起不必要的耦合。77原那么：業(yè)務對象封裝了內(nèi)在的業(yè)務邏輯，而應用效勞封裝了外在于業(yè)務對象的業(yè)務邏輯。78EJB到輕量級框架EJBPOJO〔業(yè)務邏輯〕+輕量級框架〔[Hibernate、JDO、iBATIS]〔持久化〕、Spring〔事務管理、平安〕〕79EJBEJB：編寫分布式業(yè)務應用程序的Java標準架構(gòu)。提供大量效勞：聲明型事務,EIB容器自動啟動、提交和回滾事務。業(yè)務邏輯能參與由遠程客戶發(fā)起的分布式事務。提供聲明型平安，大局部情況下不再搖要編寫平安代碼求〔bean部署描述符里的條目指定準可以防問某個具體bean〕。80例：在兩個賬號間進行轉(zhuǎn)賬的效勞。8182新設計是面向?qū)ο?、基于POJO,而非基于EJB的過程式。它使用構(gòu)建在JDBC上的持久層框架來訪問數(shù)據(jù)庫,并不直接使用JDBC。業(yè)務邏輯由POJOfacade而非會話bean進行封裝。事務由Spring框架而非EJB容器進行管理。業(yè)務邏輯向表現(xiàn)層返回實際的業(yè)務對象,而不是DTO。應用程序通過將組件的依賴作為setter或構(gòu)造子參數(shù)傳入來進行組裝,而不是之前采用Java命名和目錄接口(JNDI)查詢的組件。由于該設計面向?qū)ο?并采用上述輕量級技術,因此較之前看到的EJB版本對開發(fā)人員要友好。83基于輕量級框架設計的好處是，它提供事務和持久化時并不要求應用程序類實現(xiàn)任何特殊接口。甚至當應用程序的類需要運行在事務里或是持久的時候，它們?nèi)允荘OJO，設計者可以繼續(xù)享受POJO的種種好處。8485面向?qū)ο蟮膬?yōu)點：整個設計更易理解和維護。它并不是一個無所不能的大型類,而是由大量小類組成,每個類只共有假設干職責。此外,諸如Account、BankingTransaction和OverdraftPolicy類都與現(xiàn)實世界的概念對應,因此易于理解。其次,面向?qū)ο笤O汁也更易測試:所有類都能并且應當進行獨立的測試。EJB只能通過調(diào)用它的public方法如Transter進行測試,難度大。(只能測試p-blic方法暴露的復雜功能,無法測試其中簡單的局部〕。面向?qū)ο笙笤O計更易擴展,它可使用設計模式，如Stategy和Template等。EJB風格的過程式設計往往需耍修改核心代碼。86不適合用面向?qū)ο蟮膱龊希捍罅繑?shù)據(jù)集合的關系操作。以數(shù)據(jù)庫為中心的管理程序：這個領域所對應的現(xiàn)實世界是一個面向關系的世界，表與表的關聯(lián)表達的是彼此的業(yè)務關系。復雜的SQL固然不好維護，但業(yè)務真是復雜到簡單的SQL都難以描述的程度，采用面向?qū)ο竺枋瞿敲锤永щy，維護也更困難，同時還損失了效率。比較大的事務。性能要求高的地方?！仓苯佑肧ql或者存儲過程；犧牲可維護性和可復用性〕上層流程。87消除DTO88部署POJO程序899091用GRASP模式指導設計9293949596979899100101102103104105106107108109110質(zhì)量屬性驅(qū)動架構(gòu)設計策略軟件質(zhì)量及質(zhì)量模型軟件質(zhì)量是一個復雜的概念，不同的人從不同的角度來看軟件質(zhì)量問題，會有不同的理解。從用戶的角度看，質(zhì)量就是滿足客戶的需求；從開發(fā)者的角度看，質(zhì)量

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

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

愿意購置。

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

市場時機〔TimetoMarket〕：軟件用戶要面臨同業(yè)競爭，軟件提供商也要面臨同業(yè)競爭。以最快的速度爭奪市場先機非常重要。131軟件可維護性軟件的可維護性概述軟件可維護策略軟件可擴展性〔Extensibility〕設計策略軟件靈活性〔Flexibility〕設計策略軟件可插入性〔Pluggability〕設計策略132軟件的可維護性概述軟件可維護性的定義：軟件能夠被理解、校正、適應及增強功能的容易程度。軟件的可維護性、可使用性、可靠性是衡量軟件質(zhì)量的幾個主要特性，也是用戶十分關心的幾個問題。軟件的可維護性是軟件開發(fā)階段的關鍵目標。影響軟件可維護性的因素較多，設計、編碼及測試中的疏忽和低劣的軟件配置，缺少文檔等都對軟件的可維護性產(chǎn)生不良影響。軟件可維護性可用下面七個質(zhì)量特性來衡量，即可理解性、可測試性、可修改性、可靠性、可移植性、可使用性和效率。對于不同類型的維護,這七種特性的側(cè)重點也是不相同。133可維護性和可復用性一般來說，一個易于維護的系統(tǒng)，就是復用率較高的系統(tǒng)；一個復用率較好的的系統(tǒng)，就是一個易于維護的系統(tǒng)。但是，實際上，可維護性和可復用性是兩個獨立的目標。軟件維護就是軟件的再生。一個好的軟件設計，必須能夠允許新的設計要求以比較容易和平穩(wěn)的方式參加到已有的系統(tǒng)中去，從而使這個系統(tǒng)能夠不斷的的煥發(fā)出活力。一個可維護性較好的系統(tǒng)，應當允許維護工作能夠以容易、準確、平安和經(jīng)濟的形式進行。134導致可維護性較低的原因：1.過于僵硬：在系統(tǒng)中參加一個新的功能，不管大小都很難，不僅意味著建造一個獨立的新的模塊，而且因為這個新功能會涉及很多其他模塊，最后成跨越幾個模塊的改動。2.過于脆弱：與軟件的過于僵硬同時存在，是軟件系統(tǒng)在修改已有代碼時過于脆弱。對一個地方的修改，往往會導致看上去沒有什么關系的另外一個地方發(fā)生故障。3.復用率低：所謂復用，就是指一個軟件的組成局部，可以在同一個工程的不同地方甚至另一個工程中重復使用。復用率低，指當一段代碼，函數(shù)，模塊的功能可以在新的模塊或新的系統(tǒng)使用，但是已有代碼依賴于其他很多東西，很難分開。1354.黏度過高：一個改動可以保存原始設計意圖和原始設計框架的方式進行，也可以以破壞原始意圖和框架進行。第一種方法對系統(tǒng)的未來有利，第二種方法是權(quán)宜之計，可以解決短期的問題，但是會犧牲中長期的利益。如果一個系統(tǒng)中使用第二種方法比使用第一種方法容易，那么就是黏度過高。設計的目標：1.可擴張性2.靈活性3.

插入性136系統(tǒng)的可復用性：復用性的重要性：1.較高的生產(chǎn)效率2.較高的軟件質(zhì)量3.恰當使用復用可以改善系統(tǒng)的可維護性統(tǒng)的復用和面向?qū)ο蟮南到y(tǒng)設計中復用的區(qū)別1.傳統(tǒng)的復用：代碼的剪貼復用；算法的復用；數(shù)據(jù)結(jié)構(gòu)的復用。2.面向?qū)ο蟮脑O計的復用：在OO中數(shù)據(jù)的抽象化、繼承、封裝和多態(tài)是幾個重要的語言特性，這些特性使得一個系統(tǒng)可以在更高的層次上提供可復用性。137數(shù)據(jù)的抽象化和繼承關系使得概念和定義可以復用；多態(tài)性使得實現(xiàn)和應用可以復用；抽象化和封裝可以保持和促進系統(tǒng)的可維護性。138可復用和可維護性的關系1.適當?shù)氖褂脧陀?，可以提高可維護性，即支持可維護性的復用，就是在保持甚至提高系統(tǒng)的可維護性的同時，實現(xiàn)系統(tǒng)的復用。2.適當提高系統(tǒng)的可復用性可以提高系統(tǒng)的可擴展性：系統(tǒng)的可擴展性由“開-閉”原那么、里氏代換原那么、依賴倒轉(zhuǎn)原那么和組合/聚合復用原那么所保證。3.適當提高系統(tǒng)的可復用性，可以提高系統(tǒng)的靈活性。系統(tǒng)的靈活性由“開-閉”原那么、迪米特法那么、接口隔離原那么所保證的。4.適當提高系統(tǒng)的可復用性，可以提高系統(tǒng)的可插入性。系統(tǒng)的可插入性由“開-閉”原那么、里氏代換原那么、組合/聚合復用原那么和依賴倒轉(zhuǎn)原那么所保證。139復用原那么：1.“開-閉”原那么:OCP2.里氏代換原那么:LSP3.依賴倒轉(zhuǎn)原那么:DIP4.接口隔離原那么:ISP5.組合/聚合復用原那么:CARP6.迪米特法那么:LoD140軟件可維護策略從下面五個方面來闡述如何提高軟件的可維護性：1.建立明確的軟件質(zhì)量目標如果要程序滿足可維護性七個特性的全部要求，那么要付出很大的代價，甚至是不現(xiàn)實的，但有些可維護性是相互促進的，因此要明確軟件所追求的質(zhì)量目標。2.使用先進的軟件開發(fā)技術和工具利用先進的軟件開發(fā)技術能大大提高軟件質(zhì)量和減少軟件費用。面向?qū)ο蟮能浖_發(fā)方法就是一個非常實用而強有力的軟件開發(fā)方法，用面向?qū)ο蠓椒ㄩ_發(fā)出來的軟件系統(tǒng)，穩(wěn)定性好，比較容易修改，比較容易理解，易于測試和調(diào)試，因此，可維護性好。1413.建立明確的質(zhì)量保證質(zhì)量保證是指為提高軟件質(zhì)量所做的各種檢查工作。質(zhì)量保證檢查是非常有效的方法，不僅在軟件開發(fā)的各階段中得到了廣泛應用，而且在軟件維護中也是一個非常主要的工具。為了保證可維護性，以下四類檢查是非常有用的：(1)在檢查點進行檢查。(2)驗收檢查。(3)周期性的維護檢查。(4)對軟件包的檢查。4.選擇可維護的語言程序設計語言的選擇對維護影響很大。低級語言很難掌握，很難理解，因而很難維護。一般來說，高級語言比低級語言更容易理解，第四代語言更容易理解，容易編程，程序容易修改，改進了可維護性。1425.改進程序的文檔程序文檔是對程序功能、程序各組成局部之間的關系、程序設計策略、程序?qū)崿F(xiàn)過程的歷史數(shù)據(jù)等的說明和補充。程序文檔對提高程序的可閱讀性有重要作用。為了維護程序，人們必須閱讀和理解程序文檔。143一些經(jīng)驗1。首先在軟件設計的時候就應盡量考慮全面，防止在后期開發(fā)到一定階段之后在進行需求和功能上的改動。軟件設計完成之后需要所有的工程負責人，工程經(jīng)理，主要程序員，主要的測試人員一起討論，討論通過之后才能進行開發(fā)。2。強調(diào)開發(fā)人員的代碼標準。公司一定要形成自己的編程標準，所有的開發(fā)人員須遵守。

3。軟件開發(fā)的時候必須遵守一定的流程標準。例如代碼統(tǒng)一放在vss中進行管理，每次checkin之前必須完成codereview，須有兩個同事一起檢查等，盡量在前期發(fā)現(xiàn)問題。1444。重視測試。除了單元測試與集成測試，由非開發(fā)人員和非設計人員來進行的黑盒測試非常重要。測試組未確認質(zhì)量過關的軟件不可release。

5。重視文檔。設計文檔，需求文檔，程序架構(gòu)文檔，測試文檔，用戶手冊，白皮書，等都應完善。

6。在經(jīng)歷多個工程以后，要總結(jié)出一套對質(zhì)量和可維護性的度量方法和標準，才能持續(xù)不斷改進。145軟件可擴展性設計策略應用框架(ApplicationFramework)軟件設計師用這個詞描述有助于軟件應用開發(fā)的一組可重用的設計和代碼?！敖Y(jié)構(gòu)”一詞著實反映了任何框架的本質(zhì)。在應用開發(fā)中，一個相當復雜的應用包含了如此之多的不斷變化的細枝局部，而結(jié)構(gòu)幫助我們將這些不斷變化的細枝局部，組織成易于理解的少數(shù)幾個局部?！皯每蚣堋睘殚_發(fā)者提供了結(jié)構(gòu)和模板，開發(fā)者以此為基線〔Baseline)來構(gòu)建他們的應用系統(tǒng)。用戶界面1.模型-視圖控制器(Model-ViewController,MVC)2.MacApp3.MFC業(yè)務領域1.SanFrancisco通用應用開發(fā)1.CommonPoint2.Java語言和運行時虛擬機的Java環(huán)境應用框架作用模塊化(modularity)可重用性(reusability)可擴展性(extensibility)簡單性(simplicity)可維護性(maintainability)應用框架解析----框架開發(fā)過程在明確了需要應用框架之后，首先要確定框架開發(fā)過程包括的四個主要階段：分析、設計、實現(xiàn)和穩(wěn)定。分析設計構(gòu)造穩(wěn)定范圍目標文檔測試培訓架構(gòu)識別通用點和擴展點實現(xiàn)應用框架解析----框架開發(fā)過程框架開發(fā)的通用技術：通用點(Commonspots)擴展點(Hotspots):占位符號/擴展點黑盒框架(Black-boxframework)白盒框架(White-boxframework)灰盒框架(Gray-boxframework)設計模式(Designpattern)其中，通用點、擴展點、設計模式是用于開發(fā)框架的技術，黑盒、白盒、灰盒是開發(fā)框架的方法。151軟件可復用性軟件的可復用性概述軟件復用是將已有的軟件及其有效成分用于構(gòu)造新的軟件或系統(tǒng)。它不僅是對軟件程序的復用，還包括對軟件生產(chǎn)過程中其它勞動成果的復用，如工程方案書、可行性報告、需求分析、概要設計、詳細設計、編碼(源程序)、測試用例、文檔與使用手冊等等。因此，軟件復用包括軟件產(chǎn)品復用和軟件過程復用兩局部的內(nèi)容。152從對復用產(chǎn)品的了解程度和復用方式看，也可分為白盒復用與黑盒復用。黑盒復用指對已有產(chǎn)品或構(gòu)件不需作任何修改，直接進行復用，這是理想的復用方式。它主要基于二進制代碼的復用，包括可執(zhí)行程序的復用和基于庫〔包括動態(tài)鏈接庫和靜態(tài)庫〕的復用。白盒復用指根據(jù)用戶需求對已有產(chǎn)品進行適應性修改后才可使用。白盒復用一般為源代碼一級的復用，以及相應的測試用例、文檔等的復用。無論白盒復用還是黑盒復用，都需要花費一定的代價熟悉和掌握被復用的軟件系統(tǒng)。作為經(jīng)濟上的考慮，要求復用的代價必須大大小于重新開發(fā)的代價，否那么就不應該考慮。153軟件復用的一個關鍵因素是抽象。軟件的復用性很大程度上取決于對可復用對象的認識深度或者說可復用對象的抽象層次。抽象層次越高、與具體環(huán)境和特定細節(jié)越無關，那么它被未來系統(tǒng)復用的可能性也越大。領域分析那么是進行抽象的有力工具。軟件復用根本原那么必須有可以復用的對象，所復用的對象必須是有用的；復用者需要知道如何去使用被復用的對象。154在復用軟件設計中，根據(jù)面向?qū)ο笤?，可考慮幾個方面：1〕封裝性2〕重載3〕繼承4〕聚合5〕多態(tài)性中間件及相關軟件是商業(yè)化的軟件復用。僅看程序方面，軟件復用后的制品也不只包括中間件軟件，還包括軟件框架、應用框架、通用業(yè)務構(gòu)件等多種可復用形式。155常見問題：在編程相關的各種書籍中一直在強調(diào)代碼的可重用性，之前所寫的代碼也一直遵循著這一規(guī)那么，但是最近越來越感覺這種規(guī)那么很麻煩，當費力心機的想使一段代碼變得可重用，就不得不加上各種條件的判斷，代碼中充滿了各種if...else...使代碼變得很難看懂，有時自己都會被各種不同的屬性與條件判斷搞暈，這樣的代碼對于后期的維護來說肯定是十分困難的。所以我現(xiàn)在都是把不同的業(yè)務邏輯用不同的方法實現(xiàn)，即使有些邏輯是相似的，我也使用了不同的方法，雖然這樣造成了許多重復代碼，但是這樣的代碼看起來邏輯更清晰，也更利于后期的維護，包括轉(zhuǎn)交給別人時也更容易讓人看懂，盡管這樣會造成代碼量的增加。所以現(xiàn)在對代碼的可重用性這個問題很困惑。156建議：在面向?qū)ο蟮恼Z言里，如果ifelse大多，也許說明抽象不夠。多態(tài)、功能邊界定義不夠、模塊細化不夠。抽象錯誤的情況下考慮代碼級別的重用是比較傷神的。業(yè)務描述真正正確以后,維護方案也真正就浮現(xiàn)出來了。反之業(yè)務錯了可維護性設計也會預測錯誤,設計無用接口。誤區(qū)：面向?qū)ο笫勾a、邏輯更簡單。157軟件架構(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)元件〔ArchitectureComponent〕、聯(lián)結(jié)器〔Connector〕、任務流〔Task-flow〕。所謂架構(gòu)元素，也就是組成系統(tǒng)的核心"磚瓦"，而聯(lián)結(jié)器那么描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結(jié)果，任務流那么描述系統(tǒng)如何使用這些元件和聯(lián)結(jié)器完成某一項需求。建造一個系統(tǒng)所作出的最高層次的、以后難以更改的，商業(yè)的和技術的決定。在建造一個系統(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效勞器、應用效勞器、報表效勞器、整合效勞器、存儲效勞器、主機等等。系統(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ù)據(jù)表，就會有多少頁的架構(gòu)設計文檔。比方一個中等的數(shù)據(jù)庫應用系統(tǒng)通常含有一百個左右的數(shù)據(jù)表，這樣的一個系統(tǒng)設計通常需要有一百頁左右的架構(gòu)設計文檔。從概念性架構(gòu)到實際架構(gòu)就是多(Lessismore.)。--密斯·凡德羅概念性架構(gòu)是對系統(tǒng)設計的最初設想。一般來說，實際的軟件架構(gòu)設計過程是，先進行概念性架構(gòu)的設計，把最關鍵的設計要素和交互機制確定下來，然后再考慮具體技術的運用，設計出實際架構(gòu)。架構(gòu)設計中的關鍵要素及解決策略策略是制勝的關鍵。--張明正，《擋不住的趨勢》最好的軟件開發(fā)人員都知道一個秘密：美的東西比丑的東西創(chuàng)立起來更廉價，也更快捷。--RobertC.Martin,《軟件之美》時間就是系統(tǒng)架構(gòu)的生命。--PhilippeKruchten方法產(chǎn)生于恐懼。面對時間緊迫的壓力，我們有理由質(zhì)疑那種不顧時間花銷、一味追求軟件架構(gòu)高質(zhì)量的做法。軟件架構(gòu)是軟件系統(tǒng)質(zhì)量的核心，必須足夠重視，但在不適當?shù)臅r候“用時間換完美”會毀掉整個工程。架構(gòu)設計并非“好的就是成功的”，而是“適合的才是成功的”。方法論

AlistairCockburn的七條定理，總結(jié)為：溝通和反響。RUP、XP重量之爭軟件架構(gòu)設計中的關鍵要素及解決策略：

關鍵要素

策略

----------------------------------------------- -----------------------1.是否遺漏了至關重要的非功能需求？

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

關鍵需求決定架構(gòu)。3.能否沉著地設計軟件架構(gòu)的不同方面？

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

及早驗證架構(gòu)。軟件架構(gòu)設計過程總覽一般的軟件過程：需求分析的幾個概念需求捕獲vs需求分析vs系統(tǒng)分析需求捕獲是獲取知識的過程，知識從無到有。需求分析是挖掘和整理知識的過程，它在已掌握知識的根底上進行。系統(tǒng)分析？如果說需求分析致力于“做什么”，那么系統(tǒng)分析那么涉及“怎么做”。軟件架構(gòu)師不必是需求捕獲專家，也不必是編寫《軟件需求規(guī)格說明書》的專家。但他一定應在需求分類、需求折衷和需求變更的研究方面是專家，否那么他和其他軟件架構(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)模式：分層、MVC、微內(nèi)核、基于元模型的架構(gòu)、管道-過濾器等。質(zhì)量屬性分析“屬性-場景-決策”表方法：細化架構(gòu)設計架構(gòu)細化工作主要表達在基于五視圖方法進行架構(gòu)細化：

約束

↓

┌───────┐

領域模型->│基于五視圖方法│

關鍵需求->│

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

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

└───────┘

↑

經(jīng)驗邏輯架構(gòu)設計中，“發(fā)現(xiàn)通用機制”是應被特別強調(diào)的。機制(Mechanism)是模式的實例。機制是特定上下文中重復出現(xiàn)的問題的特定解決方案。具有良好架構(gòu)的系統(tǒng)具備概念完整性。它通過對系統(tǒng)架構(gòu)建立一種清晰的認識來發(fā)現(xiàn)通用的抽象和機制。利用這種共性使最終產(chǎn)生的系統(tǒng)結(jié)構(gòu)更為簡單。實現(xiàn)并驗證軟件架構(gòu)好的策略必須是一再求證、測試、發(fā)現(xiàn)瑕疵漏洞，另想途徑或方法來彌補策略缺乏，有時甚至得全盤放棄，重新籌劃。--張明正，《擋不住的趨勢》架構(gòu)原型對功能性需求的實現(xiàn)非常有限，那么“架構(gòu)驗證”要驗證什么？答案是要驗證架構(gòu)對質(zhì)量屬性需求的支持程度，包括運行期質(zhì)量屬性和開發(fā)期質(zhì)量屬性。驗證架構(gòu)的兩種方法：原型法。對于工程型開發(fā)，常采用“原型法”。即對一組架構(gòu)設計決策在非功能需求方面的滿足程度進行驗證。該原型往往是演進型，而非拋棄型?？蚣芊āτ诋a(chǎn)品型開發(fā)，采用“框架法”有更多優(yōu)點。該方法將架構(gòu)設計方案用框架的形式實現(xiàn)，并在此根底上進行評估驗證。在框架實現(xiàn)后，在框架根底上實現(xiàn)局部應用的功能，即實現(xiàn)一個小的垂直原型，從而進行實際非功能測試和開發(fā)期質(zhì)量屬性評價。軟件框架什么是框架框架與架構(gòu)的區(qū)別常見的框架為什么要用框架因為軟件系統(tǒng)開展到今天已經(jīng)很復雜了，特別是效勞器端軟件，設計到的知識，內(nèi)容，問題太多。在某些方面使用成熟的框架，可以防止重復做已有的根底工作，而只需要集中精力完成系統(tǒng)的業(yè)務邏輯設計。框架一般是成熟，穩(wěn)健的，可以處理系統(tǒng)很多細節(jié)問題，比方，事物理，平安性，數(shù)據(jù)流控制等問題?？蚣芤话愣冀?jīng)過很多人使用，所以結(jié)構(gòu)很好，所以擴展性也很好，而且它是不斷升級的，使用框架的開發(fā)者可以直接享受別人升級代碼帶來的好處?？蚣芤话闾幵诘蛯討闷脚_〔如J2EE〕和高層業(yè)務邏輯之間的中間層。185常見的JAVA框架EJBStrutsSpringHibernateIBatisJSFtapestryWAFTurbineCOCOONECHOJATOTCFExt…186.NET框架.NET框架是創(chuàng)立、部署和運行Web效勞及其他應用程序的一個環(huán)境。它包括三個主要局部：公共語言運行時、框架類和ASP.NET。.NET框架對Web站點的支持：ASP.NET在編寫Windows軟件〔使用ATL/COM、MFC、VB或標準Win32〕方面，與當前創(chuàng)立應用程序的方式相比.NET都具有的優(yōu)勢。C++框架標準庫DinkumwareC++Library、RogueWaveStandardC++Library、SGISTL、STLportGUIMFC、QT、WxWindows、Fox、WTL、GTK、BCG、XtremeToolkit網(wǎng)絡通信ACE、StreamModule、SimpleSocket綜合P::Classes、ACDK-ArtefakturComponentDevelopmentKit、dlibC++library、ChilkatC++Libraries、C++PortableTypesLibrary(PTypes)、LFC其他庫Loki、ATL、FC++:TheFunctionalC++Library、FACT!、Crypto++BoostRegex正那么表達式庫SpiritLLparserframework，用C++代碼直接表達EBNFGraph圖組件和算法Lambda在調(diào)用的地方定義短小匿名的函數(shù)對象conceptcheck檢查泛型編程中的conceptMpl用模板實現(xiàn)的元編程框架Thread可移植的C++多線程庫、Python把C++類和函數(shù)映射到Python之中Pool內(nèi)存池管理smart_ptr智能指針XMLXerces、XMLBooster、PullParser、Xalan、CMarkup、libxml++

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

C++Threads、ZThreads序列化

s11n、SimpleXMLPersistenceLibrary字符串

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

軟件為什么要分層？

為了實現(xiàn)“高內(nèi)聚、低耦合”。把問題劃分開來各個解決，易于控制，易于延展，易于分配資源…面向?qū)ο蟮?、基于模塊化的組件設計需要能夠方便地修改應用程序的各個局部。完成這一目標的一種好方法就是在層上工作，將一個應用程序的主要功能別離到不同的層或者級中。分層模型從本質(zhì)上講，層代表了一個應用程序主要的功能。一般地，我們將應用程序功能分為三個方面，對應3層架構(gòu)模式。它們是數(shù)據(jù)層〔datalayer〕、商務層〔businesslayer〕和表示層〔presentationlayer〕。數(shù)據(jù)層：包含數(shù)據(jù)存儲和與它交互的組件或效勞。這些組件和效勞在功能上和中間層相互獨立〔盡管在物理上不必一定相互獨立--它們可以在同一臺效勞器上〕。中間層：包括一個或者多個組件效勞，它們應用商務規(guī)那么、實現(xiàn)應用程序邏輯并完成應用程序運行所需要的數(shù)據(jù)處理。作為這個過程的一局部，中間層負責處理來自數(shù)據(jù)存儲或者發(fā)送給數(shù)據(jù)存儲的數(shù)據(jù)。表示層：從中間層獲得信息并顯示給用戶。該層同時也負責和用