系統分析/系統架構設計案例分析復習指南馬飛

目錄1 軟件開發方法 51.1. 結構化方法和面向對象方法的比擬 51.2. XP與原型方法的比擬 51.3. XP與Scrum開發的區別 61.4. 建立軟件產品線相關知識 61.5. 快速應用開發〔RAD〕 61.6. 敏捷方法〔原那么，問題〕 71.7. 原型法需求定義與嚴格需求定義的比擬 71.8. 系統運行與維護 81.9. CBSD開發的優缺點 81.10. 快速原型的特點 91.11. ABSD開發方法的特點及過程 91.12. RUP開發方法的特點及過程 92 系統分析 10 分布式軟件體系結構的原理 10 4+1視圖模型 10 系統建模〔需求建模〕 11 政務信息系統建設 11 活動圖，狀態圖，交互圖三者的區別 12 數據流圖〔DFD〕與處理流程圖的區別 12 數據流圖〔DFD〕和業務流程圖〔TFD〕的區別 12 高質量數據流圖設計原那么 13 模塊獨立性 13 業務流程分析的方法 13 業務流程建模的方法〔處理流程設計〕 14 類之間的關系 143 需求工程 14 需求分析的任務 14 需求分類方法FURPS+ 14 非功能性需求分類技術〔PIECES框架〕 14 需求分析方法，SA和OOA的區別 15 用例的獲取步驟 15 面向對象的需求分析過程 16 需求收集——聯合會議〔JRP〕 16 需求獲取常用技術及適用場景 164 架構設計 17 OOD的過程 17 軟件架構，架構風格的含義 17 架構風格及特點 17 SOA架構 19 傳統應用集成與面向效勞集成的比擬 21 基于SOA的企業集成中的數據整合——信息效勞有哪些方案 22 系統可靠度計算 22 架構評估〔質量屬性效用樹〕 22 逆向工程 23 開發框架的選擇與比擬 24 負載均衡技術 25 GFS與HDFS的比擬 25 P2P技術概述 26 DOM、SAX、JDOM和DOM4J比擬 26 并發編程模型比擬 27 XML_DTD和XML_Schema的比擬 29 增強：性能，可用性，平安性，可修改性的措施 305 設計模式 30 抽象工廠〔Abstractfactory〕 30 構造模式(Builder) 31 工廠方法(FactoryMethod*) 31 原型模式(Prototype) 32 適配器模式(Adapter*) 32 橋渠模式(Bridge) 33 合成模式(Composite) 33 裝飾模式(Decorator) 34 享元模式(FlyWeight) 34 代理模式(Proxy) 35 職責鏈模式(Chainofresponsibility) 35 命令模式(Command) 36 解釋器模式(Interpreter*) 37 迭代模式(Iterator) 38 中介者模式(Mediator) 38 觀察者模式(ObServer) 39 狀態模式(State) 39 策略模式(Strategy) 40 模板方法(TemplateMethod*) 40 訪問者模式(Visitor) 41 外觀模式〔Fa?ade〕 41 單例模式〔Singleton〕 41 備忘錄模式〔Memento〕 416 數據庫方面 41 反標準化技術 41 數據倉庫方面相關 42 數據備份與恢復 43 基于檢查點方法的數據庫恢復步驟 44 數據庫——表分區 44 分布式數據庫 45 性能優化 46 數據倉庫和聯邦數據庫集成方案的特點 46 事務特性 47 數據庫平安，從技術層面應重點考慮的因素 47 數據倉庫的開發與實施步驟 477 工程管理 47 PERT和Gantt圖的具體含義和開發過程差異 47 時間，本錢，績效管理 47 工程管理中的質量模型 48 架構評估過程關注的質量屬性 48 CMM和CMMI各級別的特點及關鍵過程域 49 質量控制與質量保證的區別 498 計算機網絡與信息平安 49 平安解決方案 49 信息系統平安 509 企業應用集成 5110 測試 51

軟件開發方法結構化方法和面向對象方法的比擬兩種方法的比擬結構化方法主要關注的是系統功能，強調業務過程中的數據流和控制流，采用模塊化，自上而下，逐步求精的設計過程，適合規模較大，結構化程度較高的系統開發。面向對象方法主要關注于處理的數據，以對象為中心，對象能夠將數據及其行為統一起來，對象之間通過消息交換引發對象行為。對象模型極大的提高了數據和功能的復用程度，簡化了開發過程，可維護性得到了改善。結構化分析包含哪些階段以及各階段的目標及任務包含五個階段，分別為：初始研究，問題分析，需求分析，邏輯建模，方案分析〔1〕需求分析階段的目標及任務為：目標：定義系統的業務需求。具體：定義需求，排列需求的優先級，修改工程方案，交流需求陳述。〔2〕邏輯建模階段目標：使用系統模型進一步記錄業務需求并對需求進行驗證。任務：結構化功能需求，建立功能需求的原型，驗證功能需求，定義驗收測試用例。XP與原型方法的比擬原型系統和XP的主要差異主要差異是功能。原型系統主要是與用戶確認需求，或者用來驗證關鍵技術，所展示的功能并不是實際系統的功能，不能用來評價實際的系統。XP，雖不包括足夠的功能，但是每個功能和可發布的產品定義是一樣的。在完整性上，它配備了一系列實用的功能集，在質量上可以健壯運行。原型系統的使用場境？工程存在一定技術難度，需要提前驗證一些關鍵技術；需求確實認較為困難，需要借助原型；工程需求復雜，開發周期較長，后續修改的代價較大，需要通過原型進行確認。原型開發存在的問題客戶似乎已經看到了軟件的工作版本，卻無法理解，由于從原型到真正可以使用，還需要相當長的開發時間。開發者為了使原型盡可能快的可使用，在整體質量，可維護性方面往往考慮不夠。敏捷開發的4大價值觀，12個最正確實踐？4大價值觀：溝通，勇氣，簡單，反應5大原那么：快速反應，簡單性假設，逐步修改，提高更改，優質工作12個最正確實踐：敏捷開發存在的問題開發團隊，管理層以及客戶的不理解，阻礙該方法論的實施；導致開發團隊無視文檔，甚至是必需的文檔；XP是針對單一團隊設計，外包方的參與將會為有效的組織帶來很大的困難；XP不適合大型復雜工程；對客戶，開發人員和管理者的素質要求較高；缺乏客戶的參與，將會導致一些必要的溝通，確認工作遇到困難，進而影響工期。XP如何與傳統軟件開發過程的融合可以將XP和增量式開發過程相結合；將大規模工程分解為小規模工程，用XP方法論組織小工程開發，用傳統的方法論監控全局；建立面向目標的工程管理。XP與Scrum開發的區別區別點在于：迭代周長度不同。XP一般為1至2周，Scrum為2至4周；迭代中對是否允許修改需求的要求不同。XP可以，SCRUM不可以。開發過程中是否嚴格按照優先級別來實現的要求不同。XP不需要，SCRUM需。實施過程中是否采用嚴格的工程方法來保證進度或質量。SCRUM沒有嚴格要求，XP有嚴格要求。建立軟件產品線相關知識評估軟件產品線建立的標準關鍵點：確認企業是否存在擁有共性領域模型的產品集合。建立產品線的兩種主要方式演化式將現有的產品演化為產品線，也就是將特定的產品的構件逐漸轉化到產品線的共用構件庫中。該方式具有：降低風險，但對總的周期和總的投資都較大。革命式即用產品線替代現有的產品集，也就是根本停止現有產品的開發，直接針對產品線的核心資源開發。該方式具有：較高的風險，但對完成產品線核心資源開發所需的總投資和工期都會減少。成功實施產品線的主要因素對企業所在領域具有長期和深厚的經驗；是否有一個用于構建產品的好的核心資源庫；需要有一個良好的開放的產品線體系結構；需要良好的管理〔包括軟件資源，人員組織，過程〕支持。快速應用開發〔RAD〕RAD方法的根本思想讓用戶更主動的參與到工程分析，設計和構造活動中來；將工程開發組織成一系列重點突出的研討會，然后讓工程投資方，用戶，分析員，設計人員，開發人員一同參與討論。通過一種迭代的構造方法，加速需求分析和設計階段；讓用戶提前看到一個可以工作的系統。RAD與傳統的結構化分析方法相比主要優點：強調用戶參與，可以盡快明確需求，降低系統開發風險，縮短系統的開發周期；通過大量使用可復用的構件，加快開發速度；工期要求較短。局限性：系統的整體和長期目標可能得不到很好的滿足；對產品質量，連貫性和設計標準化要求不高；要求系統必須支持可以模塊化；有高性能要求，技術風險很高的工程不適宜。適用場景：有較好的集成工具支持；沒有技術難度或是技術難度低，工期要求較短；任務便于分解，可并行開發；系統性能要求低。包括的工具：數據庫編程語言；界面生成器；與辦公應用的集成連接；報告生成器。RAD開發的根本過程：業務建模；數據建模；過程建模；應用生成；測試和交付。敏捷方法〔原那么，問題〕根本原那么客戶參與增量式移交；以人為主；接受變更；簡單設計。敏捷方法的哪些原那么在實踐中難以實施客戶參與——客戶參與及客戶自身的代表性；以人為本——團隊成員個性問題，可能會導致溝通困難；歡送變更——變更時，對優先級的排序可能非常困難；簡單——可能沒有時間執行系統的簡化過程，簡潔性可能較差。原型法需求定義與嚴格需求定義的比擬原型法適用的場合并非所有的需求在系統開發前都能準確地說明；有快速的系統建造工具；工程參與者之間經常存在通信上的障礙；需要實際的，可供用戶參考的系統模型；需求一旦確定就可以遵守嚴格定義的方法；大量的反復是不可防止的，必要的，應該加以鼓勵。嚴格定義法適用的場合所有需求都能被預先定義；修改定義不完備的系統代價大且實施困難；工程參與者之間能夠清晰而準確地進行通信；靜態描述和圖形模型對應用系統的反映是充分的；嚴格方法的生命周期中各階段劃分都是正確的。原型生命周期具有的約束建立一個完整的模型；原型人員要建立初始模型；原型化要從定義階段開始；實際系統將用自己的資源來建立。改變原型生命周期約束的方法僅對屏幕的原型化；使用購置的應用系統作為初始模型；子系統原型化；原型與需求建議；最終用戶進行原型化。基于原型法的工程管理根本內容估計過程；費用重新分配；變化控制；活動停止。系統運行與維護正確性維護【20%】：為了識別和糾正軟件錯誤，改正軟件性能上的缺陷，排除實施中的誤使用，應用進行的診斷和改正錯誤的過程應稱為正確性維護；適應性維護【25%】：在使用過程中，由于外部環境〔包括軟硬件環境〕或是通信協議發生改變，為使軟件能正常工作，而進行的修改正程。完善性維護【50%】：是對新的功能，性能上的修改和開發。預防性維護【5%】：預先提高系統的可維護性，可靠性等，為以后進一步改良軟件打下良好的根底。CBSD開發的優缺點優點：復用現有的組件，提高了軟件開發的效率；可以更細的分工〔包括：定義，開發，使用分開〕；可并行開發，降低費用，可分步交付。缺點：缺乏通用的組裝結構和標準，風險大；高效與可重用不易協調，對技術人員的要求較高；產品質量受構件庫質量制約。CBSD的開發過程：需求分析與定義；軟件架構設計；構件庫建立；應用軟件構建；測試和發布。快速原型的特點優點〔適合的場景〕：采用迭代式開發；強調用戶參與；適合需求不確定性較大的場景；需要快速對備選方案進行評價；可針對系統某個局部采用快速原型開發；不排斥其它開發模型，可以很好的互補。缺點〔不適宜的場景〕：需要有良好的原型開發工具；需要用戶積極參與和良好配合；要求在數據資源方面有良好的組織和管理。ABSD開發方法的特點及過程特點：體系結構驅動遞歸設計和需求抽取和分析并行過程：主要階段：需求分析——?設計——?文檔化——?復審——?實現——?演化詳細實施過程：功能分解——?選擇體系結構風格——?為風格分配功能——?細化模板——?功能校驗——?檢查并發視圖——?創立配置視圖——?驗證質量場景——?驗證約束。RUP開發方法的特點及過程特點：用例驅動架構為中心迭代和增量式開發過程：業務建模需求分析系統分析與設計開發實現測試部署配置與變更管理工程管理環境管理核心概念：角色(Who)，活動(How)，制品〔交付產物〕(What)，流程(WorkFlow)系統分析分布式軟件體系結構的原理客戶端透明調用分布式對象的原理客戶端和效勞端不是直接進行交互，而是利用客戶端存根和效勞端框架來間接進行通信，這樣，客戶端程序和效勞端程序就不需要考慮底層的通信細節問題。由于客戶端存根和效勞端框架一般由平臺自動生成，不需程序員手工編寫，所以這種通信模型的最大好處是可以省去程序員自己寫程序來處理底層通信的問題。自己利用底層協議解決系統間的通信時需要解決的主要問題異構系統間交互的兼容性，例如處理不同操作系統的字節順序，數據長度，數據表示方式等；通信的可靠性問題，例如出錯處理，重傳機制；通信的平安性問題；接口的可用性，易用性，性能等問題。主要的分布式對象體系結構框架有OMG的CORBAMicrosoft開發的DCOM(分布式構件對象模型)；Sun開發的EJB(企業級JAVABEAN)4+1視圖模型軟件架構={構成系統的元素，指導元素集成的形式，關系和約束}各種視圖的意義及面向的對象邏輯視圖：面向最終用戶，提供給最終用戶的效勞，在面向對象技術中，通過抽象、封裝和繼承，可以用對象模型來代表邏輯視圖，用類圖來描述邏輯視圖。開發視圖〔模塊視圖/實現視圖〕：面向編程人員，主要側重于描述軟件模塊的組織和管理。通過系統的輸入輸出關系模型圖〔IPO〕和子系統圖來描述。進程視圖：面向系統集成人員，側重于系統的運行特性，主要關注非功能性需求。物理視圖：面向系統工程人員，側重于軟件到硬件的映射，通常考慮系統的性能，規模，可靠性等，解決系統拓撲結構，系統安裝，通信等問題。場景視圖：重要系統活動的抽象——用例視圖。工程干系人是最終用戶和開發人員，組件元素是步驟。〔1〕，〔2〕是靜態結構；〔3〕，〔4〕是動態結構。2、軟件架構基于場景驅動的迭代式設計過程〔1〕開始階段；基于風險和重要性為某次迭代選擇一些場景。識別主要場景，然后分布到4個視圖中，然后實施，測試，評估該架構。總結經驗教訓。〔2〕循環階段；〔3〕測試階段；〔4〕評審5個視圖；〔5〕更新設計準那么和根本原理；〔6〕總結經驗教訓。3、構建開發視圖需要考慮的主要問題〔1〕開發難度，開發框架選型。〔2〕軟件管理〔相關標準，代碼目錄或是模塊的劃分〕〔3〕重用性和通用性〔4〕工具集，編程語言所帶來的限制與約束。4、開發視圖對工程管理的影響〔1〕開發工作量預算；〔2〕開發任務安排；〔3〕開發方案編制；〔4〕進度控制開發視圖是需求分解，任務管理，本錢管理，進度管理等方面的根底。系統建模〔需求建模〕電子政務主要包括如下三個應用領域政務信息查詢〔各種政策，信息查詢效勞〕公共政務辦公〔申請，申報〕政府辦公自動化〔OA等〕電子政務系統中主要存在的三種信息流：政務辦公信息流；公共事務信息流；政務咨詢信息流。需求建模包括：域建模：指為問題域創立相應的模型并且把它劃分為假設干個內聚組的過程。用例建模：描述各種參與者〔人和系統〕和要分析的系統之間的主要交互。組件建模：描述子系統，組件和模塊的層次結構分配需求和職責；〔簡單理解就是系統由哪些組件構成，每個組件所要實現的功能〕效勞建模：將應用程序定義為一組位于外部邊界，架構層之間的抽象效勞接口，并且提供了通用的應用程序和根底結構。性能建模：通過各種各樣的方式來度量性能。確定每個組件的性能指標，具體包括：執行時間，資源利用，開發復雜性，維護復雜性等質量屬性。政務信息系統建設系統統一規劃，統一建設，統一管理的優勢可共享網絡和軟硬件設備，節省本錢；集中有助于進行高可靠性配置，平安管理，可用性，平安性更有保障，本錢更低；統一維護管理后，各個部門的運行維護和管理費用將大大降低，整體上更節省費用；底層的集中共享，能夠對業務提供更好的支撐。建設過程中，需要重點規劃建設的內容災備系統〔容災系統〕；表達可靠性和可用性CA認證系統〔身份識別系統〕；表達平安性入侵檢測系統；平安審計系統；防火、防盜等物理平安措施；高可用性設施〔如多機集群，網絡冗余，電源冗余等〕；較好性能的網絡管理系統，監控網絡流量。活動圖，狀態圖，交互圖三者的區別活動圖與狀態圖的區別活動圖著重描述對象類響應內部處理的內部行為，狀態圖著重描述對象類響應事件的外部行為；活動圖著重表現一個活動到另一個活動的控制流，是內部處理驅動的流程，狀態圖著重表現的是一個狀態到另一個狀態的流程，常用于異步事件發生的情形；活動圖適合表達工作流和并發處理，狀態圖適合描述一個對象穿越多個用例的行為。狀態圖與交互圖的區別交互圖表示假設干對象在一起協同工作完成某項效勞；狀態圖是為一個對象的生命期間的情況建立模型。三者的聯系都是為對象或類的動態行為建模。都是對控制流進行建模。交互圖是對用例中的控制流建模，狀態圖是對一種狀態到另一種狀態的控制流建模，活動圖是對一種活動到另一種活動的控制流建模。數據流圖〔DFD〕與處理流程圖的區別1、含義不同數據流圖：作為一種圖形化工具，用來說明業務處理過程，系統邊界內所包含的功能和系統中的數據流。重點強調數據流。流程圖：以圖形化的方式展示應用程序從數據輸入開始到獲得數據輸出為止的邏輯過程，描述處理過程的控制流。重點強調控制流。2、兩者的主要區別數據流圖中的處理過程可并行；流程圖在某個時間點只能有一個處理過程。數據流圖展現系統的數據流；流程圖展現系統的控制流；數據流圖展全局的處理過程，過程之間遵循不同的計時標準；流程圖中處理過程遵循一致的計時標準；數據流圖適用于系統分析中的邏輯建模階段；流程圖適用于系統設計中的物理建模階段。數據流圖〔DFD〕和業務流程圖〔TFD〕的區別業務流程圖是從業務入手，從與企業生產經營直接有關的機構開始，進行業務調查而形成的。反映現有系統各部門的業務處理過程和它們之間的業務分工與聯系，以及連接各部門的物流，信息流的傳遞和流動關系，表達現有系統的邊界、環境、輸入、輸出，存儲、處理等內容。數據流程圖是業務流程圖的數據抽象，它屏蔽了業務流程的物理背景而抽象出數據的特征，它描述了數據在業務活動中的運動狀況。高質量數據流圖設計原那么復雜性最小化原那么：采用分層，逐步細化。接口最小化原那么：在設計模式時，應使得模型中各個元素之間的接口數或連接數最小化；數據流一致性原那么：父過程和子過程在數據流內容中是否有差異？防止有輸入，沒有輸出或是有輸出，沒有輸入的情況。任何處理模塊〔加工模塊〕必須有輸入，輸出，有輸入沒輸出，產生數據黑洞，有輸出，沒有輸入，無中生有；外部實體與外部實體之間，外部實體與存儲之間，不能沒有處理模塊〔加工處理〕。同一處理單元的輸入和輸出數據流名稱不能相同。模塊獨立性模塊獨立是指每個模塊完成一個相對獨立的子功能，并且與其他模塊之間的聯系簡單。衡量模塊獨立程度的度量標準有兩個：耦合和內聚。耦合是指模塊之間聯系的緊密程度。耦合度越高那么模塊的獨立性越差。按耦合度從低到高依次有7種耦合方式。非直接耦合〔獨立運行〕數據耦合〔用參數表傳遞簡單數據〕標記耦合〔傳遞數據結構或者一局部〕控制耦合〔傳遞的信息包括控制模塊的信息〕外部耦合〔模塊與軟件之外的環境有關〕公共耦合〔多個模塊引用同一全局的數據區〕內容耦合〔訪問內部數據，代碼重疊或者多個入口〕內聚是指模塊內部各元素之間聯系的緊密程度內聚度越低模塊的獨立性越差。按內聚度從低到高依次有7種內聚種類。偶然內聚〔模塊完成的多個任務，任務之間的關系松散〕邏輯內聚〔模塊完成邏輯相關的一組任務〕瞬時內聚〔模塊的所有任務必須在同一時間間隔內執行〕過程內聚〔模塊的處理元素相關而且按照特定的次序執行〕通信內聚〔模塊的所有元素集中在一個數據結構區域上〕順序內聚〔模塊的處理元素相關，必須順序執行〕功能內聚〔模塊完成單一的功能，各個局部協調工作，而且不可缺少〕業務流程分析的方法價值鏈分析法客戶關系分析法供給鏈分析法基于ERP的分析法業務流程重組業務流程建模的方法〔處理流程設計〕標桿瞄準IDEF〔集成定義方法〕DEMO〔組織動態本質建模〕Petri網業務流程建模語言基于效勞的BPM類之間的關系關聯關系〔Associate〕依賴關系〔Dependency〕泛化關系〔Generalize〕需求工程需求分析的任務確定系統的上文關系〔需求范圍〕UI&UE原型確定需求的優先級分析可行性建模〔面向過程，面向對象〕建立數據字典使用QFD需求分類方法FURPS+F〔function〕功能包括：特性，能力〔功能〕，平安性U〔usability〕易用性：人性化因素，幫助，文檔R〔reliability〕可靠性：故障周期，可恢復性，可預測性P〔performance〕性能：響應時間，吞吐量，準確性，有效性，資源利用率S〔supportability〕可支持性：適應性，可維護性，國際化，可配置性“加〞的屬性包括：實現需求：資源限制，語言工具，硬件接口需求：由外部系統施加的約束操作需求：系統管理和操作設置方面的約束包裝需求：系統實際提交方面的約束非功能性需求分類技術〔PIECES框架〕PIECES：是系統非功能性需求分類技術。PIECES框架的主要內容性能〔Performance〕：吞吐量：單位時間內處理的任務量；響應時間：完成一項任務所消耗的平均時間；信息〔Information〕主要是指信息或是數據在：輸出，輸入，存儲方面的問題經濟〔Economics〕本錢：本錢過高；是未知數，不可跟蹤的。收益：新的市場需求已經形成；當前的營銷方式已經改良了；訂單數量提高了。控制〔Control〕平安性機制或是控制手段太少：平安控制手段太多：效率〔Efficiency〕人或計算機浪費時間：數據被重復輸入或復制，數據被重復處理；信息被重復生成，物料浪費，付出的努力多，所需的物料是多余的。效勞〔Service〕結果不準確；結果數據不一致；結果不可靠；系統不易學，不易用，兼容性差，可修改性差。需求分析方法，SA和OOA的區別SA關注功能的分層和分解；假設問題域可定義，問題域是有限的；將問題分解到可分解的程度只需要有限的步驟；采用因果律，歸納法和邏輯法，測量和分解，最終得到問題域的邏輯模型；OOA基于抽象，信息隱藏，功能獨立和模塊化為根底，對系統進行分析；通過觀察外在表象；建立邏輯對象；斷定對象與現實事物的一致性；記錄到對象集合，對象關系模型，對象行為模型；對象間通過接口進行通信。區別SA，假定問題域能完全被理解，識別，分解。OOA，不做SA的假設，只承諾一種可以持續觀察并理解的方法，以及觀察后建立的對象和現實世界的外在表象是一致的。用例的獲取步驟用例獲取的根本步驟定義應用系統的邊界；識別出參與該應用系統所有的角色；合并需求獲得用例；細化用例模型確定角色參與的每一種業務活動；確定業務活動的完整的事件序列；確定激發每一個事件的序列的角色。去掉重復的事件序列；用結構化的自然語言來描述每個事件序列，得到初步確定的每一個用例。調整用例間的關系用例的三種關系包含關系：兩個或兩個以上的用例中提取公共行為時，應該使用包含關系來表示它們，抽取出來的公共用例稱為抽象用例，原始用例稱為根本用例。擴展關系：一個用例明顯地混合了兩種或兩中以上的不同場景，即根據情況可能發生多種分支。泛化關系：當多個用例共同擁有一種類似的結構和行為時，可以將共性抽象成為父用例，其它的用例作為泛化關系的子用例。面向對象的需求分析過程建立用例模型參考用例獲取步驟。建立分析模型定義概念類確定類之間的關系為類添加行為和屬性建立交互圖1，2，3被稱為CRC〔類-責任-協作者〕建模。需求收集——聯合會議〔JRP〕JRP的根本思想，什么是JRP？JRP是通過召開一系列高度結構化的分組會議，快速地分析問題，定義需求，它是JAD技術的一個子集，其主要目的是收集需求，而不是對需求進行分析和驗證。原那么：提前制定議程，嚴格遵守望議程；按照既定的時間安排進行；完整的會議記錄；討論時，盡量防止專業術語；充分利用解決沖突的技能；會議期間有休息時間；鼓勵團隊取得一致意見；確定與會人員遵守會議規那么。提高問卷返回率的方法需求獲取常用技術及適用場景收集資料調查的根本手段JRP適合于對系統的定性調查。個別訪問〔用戶訪談〕是JRP的補充是收集數據的主要來源之一。書面調查〔問卷調查〕系統比擬復雜，工程干系人很多，涉及的范圍很廣。抽樣調查需要全面資料而又不可能全面調查，或者全面調查困難，或者沒有必要進行全面調查的情況。現場觀摩系統有較為復雜的流程和操作，且比擬難以用語言清楚的表達。參加業務實踐需要有效發現問題本質和尋找解決問題的方法閱讀歷史文檔對數據流比擬復雜，工作表單較多的工程，有時是難以通過說或者通過觀察來了解系統細節。原型法架構設計OOD的過程根據用例模型和分析模型：設計系統的整體架構，即系統/模塊劃分，確定依賴關系，相關接口，約束等，可用“包圖〞或“組件圖〞表示用交互圖逐一描述核心用例的實現過程，可用順序圖或通信圖表示設計完整，精確的類圖，用“類圖〞或“對象圖〞表示核心業務流程的狀態圖或活動圖設計部署方案，即畫“部署圖〞軟件架構，架構風格的含義軟件架構={構成系統的元素，指導元素集成的形式，關系和約束}詳細描述：為軟件系統提供一個結構，行為和屬性的高級抽象，由構件的描述，構件的相互作用〔連接件〕，指導構件集成的方式，以及這些模式的約束組成。其目標是“構件級〞的軟件復用。架構風格的含義描述特定軟件系統組織方式的慣用模式。組織方式描述了系統的組成構件和這些構件的組織方式，慣用模式那么反映眾多系統共有的結構和語義。架構風格及特點批處理風格構件為一系列固定順序的計算單元，構件之間只通過數據傳遞交互。每個處理步驟是一個獨立的程序，每一步必須在其前一步結束之后才能開始，數據必須是完整的，以整體的方式傳遞。管道-過濾器風格每個構件都有一組輸入和輸出，構件讀輸入的數據流經過內部處理，然后產生輸出數據流。過濾器指的是構件，連接件就是數據流傳輸的管道。主子程序單線程控制，把問題劃分為假設干個處理步驟，構件即主程序和子程序，子程序通常可合并為模塊。過程調用作為交互機制，即充當連接件的角色。調用關系具有層次性，其語義邏輯表現為主程序的正確性取決于它調用的子程序的正確性。面向對象顯示調用。構件是對象，對象是抽象的數據類型的實例。在抽象的數據類型中，數據的表示和它們的相應操作被封裝起來，對象的行為表達在其接受和請求的動作。連接件即是對象間交互的方式，對象是通過函數和過程的調用來交互的。層次結構構件組織成一個層次結構，連接件通過決定層間如何交互的協議來定義。某個層只能見到與自己鄰接的層。進程通信獨立構件。構件是獨立的過程，連接件是消息傳遞。構件通常是命名過程，消息傳遞的方式可以是點對點，異步或同步方式，以及遠程過程〔方法〕調用等。事件驅動隱式調用。構件不直接調用一個過程，而是觸發或播送一個或多個事件。構件中的過程在一個或多個事件中注冊，當前某個事件被觸發時，系統自動調用在這個事件中注冊的所有過程。優點：為軟件復用提供了強大的支持，為構件的維護和演化帶來了方便。缺陷：放棄了對系統計算的控制。解釋器通常包括一個完成解釋工作的解釋引擎，一外包含將被解釋的代碼的存儲區，一個記錄解釋引擎當前工作狀態的數據結構，以及一個記錄源代碼被解釋執行的進度的數據結構。基于規那么的系統包括規那么集，規那么解釋器，規那么/數據選擇器和工作內存，一般用在人工智能領域和DSS中。數據庫系統數據共享。構件主要有兩在類，一類是中央共享數據源，保存當前系統的數據狀態；另一類是多個獨立處理單元，處理單元對數據元素進行操作。黑板系統包括知識源，黑板和控制三個部份。通常用于解決問題沒有確定性算法的軟件中〔如信號處理，問題規劃和編譯器優化等〕語音識別應用中。超文本系統構件以網狀鏈接方式相互連接，用戶可以在構件之間進行按照人類的聯想思維方式任意跳轉到相關構件。兩層C/S架構的缺陷開發本錢高；客戶端程序設計復雜；信息內容和形式單一；用戶界面風格不一；軟件移植困難；軟件升級維護困難；新技術不能輕易應用。三層C/S架構的優點各層在邏輯上保持相對獨立，整個系統的邏輯結構更為清晰，能提高系統和軟件的可維護性和可擴展性；允許靈活有效地選用相應的平臺和硬件系統，具有良好的可升級性和開放性；各層可以并行開發，各層也可以選擇各自最適合的開發語言；功能層有效地隔離表示層和數據層，為嚴格的平安管理奠定了堅實的根底；整個系統的管理層次也更加合理和可控制。需要考慮的問題：各層之間的通信方式；通信頻度；通信的數據量.三層B/S架構的缺陷缺乏對動態頁面的支持能力，沒有集成有效的數據庫處理能力。？B/S架構的平安性難以控制；在數據查詢響應速度上，遠低于C/S架構；數據提交一般以頁面為單位，數據的動態交互性不強，不利于OLTP應用。富互聯網應用架構〔RIA〕結合了B/S和C/S的優勢；簡化并改良了B/S架構的用戶交互；數據能夠被緩存到客戶端，從而可以實現一個比基于HTML的響應速度更快且數據往返于效勞器的次數更少的用戶界面。SOA架構SOA的概念面向效勞的體系結構是一個軟件架構模型，它將業務的不同功能單元〔稱為效勞〕通過效勞之間的接口〔和契約〕聯系起來。接口獨立于實現效勞的硬件平臺，操作系統和開發語言。WebService與SOA的關系：WebService是技術標準，SOA是設計原那么.SOA的設計原那么明確定義的接口；自包含和模塊化；粗粒度；松耦合；互操作性，兼容和策略聲明；無狀態和透明性。基于SOA的關鍵技術UDDI統一描述、發現、集成提供了一種效勞發布，查找和定位的方法，是效勞的信息注冊標準，以便被需要該效勞的用戶發現和使用它。WSDLWeb效勞描述定義語言，是對效勞進行描述的語言，它有一套基于XML的語法定義。描述的重點是效勞，它包含效勞實現定義和效勞接口定義。SOAP簡單對象訪問協議定義了效勞請求者和效勞提供者之間的消息傳輸標準。基于XML來格式化消息，用HTTP來承載消息。REST表述性狀態轉移是一種使用HTTP和XML基于Web通信的技術，可以降低開發復雜性，提高系統可伸縮性。它從資源的角度來定義整個網絡系統結構，分布在各處的資源由統一資源標識符確定，客戶端應用程序通過URI獲取資源的表現，并通過獲得資源表現使得其狀態發生改變。關注點：資源，資源表現，獲取資源動作。基于SOA的優勢和缺陷優勢：可復用各種應用資源〔如軟件資產〕，降低本錢；可增強各個業務的集成性和靈活性；業務流程變更時便于快速的構建應用系統；更易于維護，易于管理；具有更高的可用性；具有更好伸縮性；支持多種客戶類型；可以快速整合或集成。缺陷：高度依賴于網絡，可靠性低；平安性需要重點考慮；性能相對較低；遺留系統支持；可編排性較差(各種效勞按業務流程集成)。SOA的實現方法WebService包括效勞提供者，效勞請求者，效勞注冊中心，三者之間的關系？操作包括：發布——?查找——?綁定。采用WebService作為SOA的實現技術時，應用系統分為：底層傳輸層(HTTP,JMS,SMTP)效勞通信協議層(SOAP,REST)效勞描述層(WSDL)效勞層(WSDL)業務流程層(WSBPEL)效勞注冊層(UDDI)效勞注冊表〔ServiceRegistry〕提供一個策略執行點，在這個點上，效勞可以在其中注冊，從而可以被發現和使用。效勞注冊表產品具有的功能如下(SOA治理功能)：效勞注冊：應用開發者或效勞提供者向注冊表公布其功能，由效勞提供者公布其效勞合同信息，具體包括：效勞身份，位置，方法，綁定，配置，方案和策略等.SOA治理有效方法：限制哪些效勞可以向注冊表發布，由誰發布以及誰批準，根據什么條件批準。2〕效勞位置〔效勞查找功能〕：注冊中心幫助效勞消費者查詢注冊效勞，尋找符合自身要求的效勞，注冊表讓效勞的消費者檢索效勞合同。SOA治理有效方法：(1)對訪問用戶進行用戶身份驗證；(2)需要限制哪些用戶可以訪問注冊；(3)限制哪些效勞屬性可以通過效勞注冊進行暴露；3〕效勞綁定：效勞消費者利用檢索到的效勞合同來開發代碼，再將代碼與注冊的效勞綁定，調用注冊的效勞，以及與它們實現互動。工具驅動對效勞綁定的控制，有效地管理效勞在ESB上的互動。企業效勞總線〔ESB〕提供一種根底設施，消除效勞請求者與效勞提供者之間的直接連接，使請求者與效勞者之間進一步解耦。ESB具有的根本功能：提供位置透明性的路由和尋址效勞；控制效勞尋址和命名的管理功能；支持多種形式的消息傳遞〔例如：請求/響應，發布/訂閱等〕支持至少一種可以廣泛使用的傳輸協議和協議轉換；支持效勞提供的多種集成方式；(支持多種數據格式及其相互轉換)提供平安和擁有者機制，以保證消息和效勞使用的認證，授權和完整性。提供日志和監控功能。基于SOA平安性解決方案基于用戶身份的識別；采用簽名技術；授權；完整性，機密性；審查和審計不可否認性或抗抵賴性；威脅預防。面向對象開發技術和面向效勞開發技術的區別〔1〕從業務功能方面：面向對象技術以對象為核心概念，通過對象之間的消息交互完成業務功能；面向效勞開發技術以效勞為核心概念，業務功能需要封裝成效勞。〔2〕從系統功能集成方面：前者以對象為單元進行功能集成，通常采用工作流技術定制業務流程；后者以效勞為單元進行功能集成，采用效勞組合技術實現靈活的業務集成與重組。傳統應用集成與面向效勞集成的比擬傳統的應用集成方法基于SOA〔ESB〕的集成方法集成方法涉及不同的集成層次，集成方法復雜多樣將現有系統看作抽象的效勞提供者，集成方法統一明確對企業集成需求的符合程度不同層次的集成方法關注點不同，功能組合方面能力較弱強調功能的暴露與效勞組合，便于提供增值效勞集成系統體系結構一般為中心輻射型，系統之間的耦合度較高基于總線的體系結構，系統耦合度低集成系統的可擴展性原有系統集成方法多樣，系統耦合度高，可擴展性差模塊化，松耦合的特點，可擴展性較好基于SOA的企業集成中的數據整合——信息效勞有哪些方案聯邦效勞：提供各種類型的數據聚合的能力，它既支持關系型數據庫，也支持XML數據等非關系型數據，所有的數據仍然按照自己本身的方式處理。復制效勞：提供遠程數據的良好訪問能力，它通過自動的實時復制和數據轉換，在本地維護一個數據源的副本，本地數據和數據源在技術實現上是可以獨立的。轉換效勞：用于數據源格式到目標格式的轉換，可以是批量或者是基于記錄的。搜索效勞：提供對企業數據的查詢和檢索效勞，即支持數據庫等結構化數據，也支持PDF等非結構化數據。系統可靠度計算可靠度：就是系統在規定的條件下，規定的時間內不發生失效的概率。MTTF=1/失效率MTTR：系統平均故障修復時間；MTBF：系統平均故障間隔時間；MTBF=MTTF+MTTR可用性=MTTF/MTBF=MTTF/(MTTR+MTTF)檢錯技術的優缺點，常用檢錯方式和處理方式優點：代價低于容錯技術和冗余技術。缺點：不能自動解決故障，出現故障后如果人工不干預，將最終導致軟件系統不能正常運行。常用的檢錯方式：判斷返回結果；判斷返回時間是否超過預期時間；置狀態標志位。處理方式：大多數采用“查處故障——選擇/停止軟件運行——報警〞的處理方式。架構評估〔質量屬性效用樹〕性能，平安性，可修改性，可用性，可靠性性能：指系統的響應能力，響應的時間，單位時間內的處理任務的個數。平安性：允許合法用戶訪問，阻止非法用戶訪問的能力。可修改性：指對系統進行變更的性價比。通過變更來表達。可用性：系統能正常運行的時間比例。一般用故障間隔和恢復的速度來表示。可靠性：指在單位時間系統失效的次數。敏感點，權衡點，架構風險的概念敏感點：為了實現某種特定的質量屬性，一個或多個構件所具有的特性。權衡點：影響多個質量屬性的特性，是多個質量屬性的敏感點。風險點：架構設計中潛在的，存在問題的架構決策所帶來的隱患。主要評估方法SAAM評估過程：ATAM分析評估過程：逆向工程設計恢復的四種級別實現級：過程的設計模型結構級：程序和數據結構信息。功能級：對象模型，數據和控制模型。領域級：UML狀態圖和部署圖。軟件重構的三個級別及常見重構方法三個級別：代碼級別，設計級別，架構級別常見的重構方法：提取方法提取類提取接口用委托來替代繼承用子類代替型別碼用多態來代替條件判斷模板函數開發框架的選擇與比擬基于EJB和struts等的輕量級框架的比擬組件EJBStrutsModelEJB的構件實現JavaBean構件實現ViewJSP構件實現JSP構件實現ControllerServlet實現Servlet實現總結：輕量級框架側重于減少開發的復雜度，但處理能力有所減弱〔如事務功能，分布式處理〕，比擬適合于中小型企業應用開發。一般基于POJO的方法進行開發，使應用不依賴于任何容器，可提升開發調試的效率；基于開源，有良好的設計工具，豐富的快速構建工具，大量的現成源碼，有利于快速開發。EJB，強調高可伸縮性，適合于開發大型企業應用。在EJB體系結構中，一切與根底結構效勞相關的問題和底層分配問題都由容器來處理。針對事務處理，分布式處理提供了專門的系統性能解決方案，能充分解決系統性能問題。開發復雜，商業級容器效勞產品較昂貴。重量級〔EJB〕：占用資源過多，在開發的過程中效率很低；大部份時間花在配置，運行的過程上，修改復雜；單元測試比擬麻煩；輕量級：提高了開發的速度；立即可以看到結果；做單元測試也非常簡單；大量現成可供參考的開源代碼。MVC和MVP的區別組件耦合度方面MVP中視圖并不直接使用模型，通過Presenter進行，從而實現視圖與模型的別離。MVC中，視圖直接與模型交互。組件分工方面MVP中視圖需要處理鼠標及鍵盤等觸發的界面事件；MVC中，一般由控制器完成工作。MVP中，系統的核心業務邏輯組織集中在P中，MVC中，C一般只是完成事件的分發。開發工程化支持方面MVP，能更好地支持單元測試，MVC中由于視圖與模型綁定，難以實施相應的單元測試；MVP中，P基于約定的接口與視圖和模型交互，可更好地支持組件的重用。負載均衡技術常用負載均衡技術基于特定軟件的負載均衡

,如HTTP重定向，屬于應用層負載均衡技術，其主要原理是效勞器使用HTTP重定向指令，將一個客戶端重新路由到另一個位置，效勞器返回一個重定向響應，而不是返回請求的對象，客戶端確認新地址后重發請求，從而到達負載均衡的目的。基于DNS的負載均衡：屬于傳輸層負載均衡技術，DNS中為同一個主機配置多個地址，在應答DNS查詢時，DNS效勞器對每個查詢將以DNS文件中主機記錄的IP地址按順序返回不同的解析結果，將客戶端的訪問引導到不同的節點上去，使得不同的客戶端訪問不同的節點，從而到達負載均衡的目的。基于NAT的負載均衡：有NAT模式，隧道模式，直接路由模式。基于反向代理的負載均衡：使用范圍有限，主要用于對WEB效勞器的負載均衡；其次每一次代理，代理效勞器均要翻開兩個連接，一個對外，一個對內。在并發連接請求數量非常大的時候，代理效勞器的負載也就非常大，代理效勞器本身有可能會成為一個瓶頸。混合型負載均衡總結為三大類：即基于DNS；基于應用層重定向或是反向代理；基于IP路由〔傳輸層〕GFS與HDFS的比擬相同點：單一控制機和多臺工作機；通過數據分塊和復制實現可靠性和高性能；樹狀文件系統結構。不同點：屢次寫入和多客戶端并發增加數據；Master單點失效問題；數據快照的支持；實時性支持。GFS的優勢：多客戶端并發寫入文件支持；解決主效勞器單點失效問題；系統補償操作需要數據快照。GFS和HDFS的單點故障解決方案GFS：采用主從模式備份Master的系統元數據，當主Master失效時，可以隨時通過分布式選舉備機接替主Master繼續對外提供效勞。HDFS：由于復制及主備切換本身有一定的復雜性，HDFS的持久化數據只寫入本機〔可寫入多份在同一主機的多個磁盤上，以防某個磁盤損害〕，出現故障時，需要人工介入處理。P2P技術概述1、技術特點非集中化；可擴展性；健壯性；匿名與隱私保護；自組織；所有權本錢；Ad-hoc連接；高性價比；平安；透明性和可用性；故障適應能力；交互能力；負載均衡。關鍵技術資源查詢與定位技術；網絡地址轉換與路由轉換；IP地址解析技術；平安技術；應用層的數據描述與交換技術；3、網絡結構集中式為第一代；分布式非結構化為第二代；分布式結構化為第三代需要解決的關鍵問題資源放置資源定位 集中方式索引；播送方式；分布哈希表的方式資源獲取DOM、SAX、JDOM和DOM4J比擬DOM〔Document

Object

Model)【優點】

①允許應用程序對數據和結構做出更改。

②訪問是雙向的，可以在任何時候在樹中上下導航，獲取和操作任意局部的數據。

【缺點】

①通常需要加載整個XML文檔來構造層次結構，消耗資源大。SAX〔Simple

API

for

XML)【優勢】

①不需要等待所有數據都被處理，分析就能立即開始。

②只在讀取數據時檢查數據，不需要保存在內存中。

③可以在某個條件得到滿足時停止解析，不必解析整個文檔。

④效率和性能較高，能解析大于系統內存的文檔。【缺點】

①需要應用程序自己負責TAG的處理邏輯〔例如維護父/子關系等〕，文檔越復雜程序就越復雜。

②單向導航，無法定位文檔層次，很難同時訪問同一文檔的不同局部數據，不支持XPath。JDOM(Java-based

Document

Object

Model)【優點】

①使用具體類而不是接口，簡化了DOM的API。

②大量使用了Java集合類，方便了Java開發人員。【缺點】

①沒有較好的靈活性。

②性能較差。DOM4J(Document

Object

Model

for

Java)【優點】

①大量使用了Java集合類，方便Java開發人員，同時提供一些提高性能的替代方法。

②支持XPath。

③有很好的性能。【缺點】

①大量使用了接口，API較為復雜。根本指導思想如果XML文檔較大且不考慮移植性問題建議采用DOM4J；如果XML文檔較小那么建議采用JDOM；如果需要及時處理而不需要保存數據那么考慮SAX。并發編程模型比擬傳統的并發編程模型主要有兩種，一種是Thread-basedconcurrency,

另一種是Event-drivenconcurrency。下面分別介紹這兩種模型，并比擬這兩種模型的優劣。1、Thread-basedconcurrency

模型優點：編程簡單；有很好的隔離性。缺點：擴展性較差，資源管理復雜。2、Event-drivenconcurrency模型考慮到Thread-pre-request模型的可擴展性問題，人們創造了Event-drivenconcurrency模型。在這種模型中，效勞器由一組線程/進程〔一般是oneperCPU〕循環處理各種來自隊列的事件(Event)。OS，應用都可以產生這些事件，表示某些操作需要執行，如：network或

diskI/O

準備就緒，或者完成通知，定時器，或者應用層的自定義事件。優點：有較高的靈活性；支持高并發缺點：對技術要求較高；模型的通用性不理想。3、SEDA并發模型SEDA將應用分通過事件隊列鏈接的網狀Stage，每個Stage由一個線程池，一個業務相關的事件處理器〔EventHandler〕，一個事件輸入隊列和一個多個資源控制器組成。如圖6所示。SEDA的幾點重要設計：〔1〕Efficient,event-drivenconcurrency:

SEDA并發模型依賴于Event-drivenconcurrency

模型來支持高并發。利用一組線程來處理每個請求，而不是每一個請求一個線程，利用

NonblockingI/O來防止資源的阻塞。〔2〕Dynamicthreadpooling:

為了防止設計事件調度和到達非阻塞操作的要求，SEDA利用一系列線程組〔Threadpool〕,

每一個事件處理器利用一個動態的線程池。這樣就可以利用OS的線程調度來調度事件的處理，并且可以允許事件處理代碼阻塞一小段時間，因為有多個線程〔一個動態線程池〕可以處理一個事件。〔3〕Structuredqueuesforcodemodularityandloadmanagement:

通過事件隊列將一個應用分割成一系列的Stage，可以讓應用開發者只關注具體的業務邏輯〔事件處理器〕,然后通過隊列將各個State組裝成應用，也可以動態的添加何卸載Stage。這樣可以獨立開發每一個Stage。應用也可以在每個Stage中控制每一個請求的執行，如執行路徑的改變，或終止請求等。每一個Stage可以更具自身的狀態來控制請求的執行，如某一個Stage的負載太高，可能會拒絕處理這個請求。當然也可以讓資源管理與控制在更細的粒度，沒一個Stage都可以有自己的資源管理宇控制。XML_DTD和XML_Schema的比擬數據類型：DTD的數據類型有限，Schema的數據類型豐富，且可擴展。元素順序的支持：DTD沒有提供對無序情況的描述，Schema有。命合空間支持：DTD不持，Schema支持。對于API的支持：DTD支持有限，schema在DOM,SAX,JDOM,DOM4j都能很好的支持。注釋的支持：XMLSchema提供了更靈活和有用的注釋方式：documentation和appinfo。對數據庫的支持：DTD對關系數據的描述方面明顯存在著缺乏,schema那么由于有豐富的數據類型能很好的描述關系數據。增強：性能，可用性，平安性，可修改性的措施性能：增加計算資源；改善資源需求〔減少計算復雜度等〕；資源管理〔并發，數據復制〕；資源調度〔先進先出隊列，優先級隊列等〕；可用性：Ping/Echo；心跳；異常和主動冗余；平安性：抵御攻擊〔授權，認證和限制訪問等〕；攻擊檢測〔入侵檢測等〕；從攻擊中恢復〔部份可用性策略〕和信息審計等。可修改性：軟件模塊泛化；限制模塊之間通信；使用中介和延遲綁定等。設計模式創立型模式：主要用于創立對象，為設計類實例化新對象提供指南。結構型模式：主要用于處理類或對象的組合，對類如何設計以形成更大的結構提供指南。行為型模式：主要用于描述類或對象的交互以及職責的分配，對類之間的交互以及分配責任的方式提供指南。抽象工廠〔Abstractfactory〕客戶類和工廠類分開。消費者任何時候需要某種產品，只需向工廠請求即可。消費者無須修改就可以接納新產品。缺點是當產品修改時，工廠類也要做相應的修改。如：如何創立及如何向客戶端提供。構造模式(Builder)將產品的內部表象和產品的生成過程分割開來，從而使一個建造過程生成具有不同的內部表象的產品對象。建造模式使得產品內部和表象可以獨立的變化，客戶不必知道產品內部組成的細節。建造模式可以強制實行一種分步驟進行的建造過程。構建與表示別離，簡化復雜對象的創立。工廠方法(FactoryMethod*)核心工廠類不再負責所有產品的創立，而是將具體創立的工作交給子類去做，成為一個抽象工廠角色，僅負責給出具體工廠類必須實現的接口，而不接觸哪一個產品類應當被實例化這種細節。原型模式(Prototype)通過給出一個原型對象來指明所要創立的對象的類型，然后用復制這個原型對象的方法創立出更多同類型的對象。原始模型模式允許動態的增加或減少產品類，產品類不需要非得有任何事先確定的等級結構，原始模型模式適用于任何的等級結構。缺點是每一個類都必須配備一個克隆方法。通過克隆方法來動態創立對象。適配器模式(Adapter*)把一個類的接口變換成客戶端所期待的另一種接口，從而使原本因接口原因不匹配而無法一起工作的兩個類能夠一起工作。適配類可以根據參數返還一個適宜的實例給客戶端。橋渠模式(Bridge)將抽象化與實現化別離，使得二者可以獨立的變化，也就是說將他們之間的強關聯變成弱關聯，也就是指在一個軟件系統的抽象化和實現化之間使用組合/聚合關系而不是繼承關系，從而使兩者可以獨立的變化。多繼承替代方案。合成模式(Composite)合成模式將對象組織到樹結構中，可以用來描述整體與局部的關系。合成模式就是一個處理對象的樹結構的模式。合成模式把局部與整體的關系用樹結構表示出來。合成模式使得客戶端把一個個單獨的成分對象和由他們復合而成的合成對象同等看待。裝飾模式(Decorator)裝飾模式以對客戶端透明的方式擴展對象的功能，是繼承關系的一個替代方案，提供比繼承更多的靈活性。動態給一個對象增加功能，這些功能可以再動態的撤消。增加由一些根本功能的排列組合而產生的非常大量的功能。享元模式(FlyWeight)將可以共享的狀態和不可以共享的狀態從常規類中區分開來，將不可以共享的狀態從類里剔除出去。客戶端不可以直接創立被共享的對象，而應當使用一個工廠對象負責創立被共享的對象。享元模式大幅度的降低內存中對象的數量。代理模式(Proxy)職責鏈模式(Chainofresponsibility)在責任鏈模式中，很多對象由每一個對象對其下家的引用而接起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求。客戶并不知道鏈上的哪一個對象最終處理這個請求，系統可以在不影響客戶端的情況下動態的重新組織鏈和分配責任。處理者有兩個選擇：承當責任或者把責任推給下家。一個請求可以最終不被任何接收端對象所接受。命令模式(Command)命令模式把一個請求或者操作封裝到一個對象中。命令模式把發出命令的責任和執行命令的責任分割開，委派給不同的對象。命令模式允許請求的一方和發送的一方獨立開來，使得請求的一方不必知道接收請求的一方的接口，更不必知道請求是怎么被接收，以及操作是否執行，何時被執行以及是怎么被執行的。系統支持命令的撤消。回調的替代方案.解釋器模式(Interpreter*)給定一個語言后，解釋器模式可以定義出其文法的一種表示，并同時提供一個解釋器。客戶端可以使用這個解釋器來解釋這個語言中的句子。解釋器模式將描述怎樣在有了一個簡單的文法后，使用模式設計解釋這些語句。在解釋器模式里面提到的語言是指任何解釋器對象能夠解釋的任何組合。在解釋器模式中需要定義一個代表文法的命令類的等級結構，也就是一系列的組合規那么。每一個命令對象都有一個解釋方法，代表對命令對象的解釋。命令對象的等級結構中的對象的任何排列組合都是一個語言。迭代模式(Iterator)迭代子模式可以順序訪問一個聚集中的元素而不必暴露聚集的內部表象。多個對象聚在一起形成的總體稱之為聚集，聚集對象是能夠包容一組對象的容器對象。迭代子模式將迭代邏輯封裝到一個獨立的子對象中，從而與聚集本身隔開。迭代子模式簡化了聚集的界面。每一個聚集對象都可以有一個或一個以上的迭代子對象，每一個迭代子的迭代狀態可以是彼此獨立的。迭代算法可以獨立于聚集角色變化。中介者模式(Mediator)調停者模式包裝了一系列對象相互作用的方式，使得這些對象不必相互明顯作用。從而使他們可以松散偶合。當某些對象之間的作用發生改變時，不會立即影響其他的一些對象之間的作用。保證這些作用可以彼此獨立的變化。調停者模式將多對多的相互作用轉化為一對多的相互作用。調停者模式將對象的行為和協作抽象化，把對象在小尺度的行為上與其他對象的相互作用分開處理。觀察者模式(ObServer)觀察者模式定義了一種一對多的依賴關系，讓多個觀察者對象同時監聽某一個主題對象。這個主題對象在狀態上發生變化時，會通知所有觀察者對象，使他們能夠自動更新自己。狀態模式(State)狀態模式允許一個對象在其