軟件體系結構期末考試知識點總結

軟件危機的表現(xiàn)：軟件成本日益增長。開發(fā)進度難以控制。軟件質(zhì)量差。軟件維護困難軟件危機的原因：用戶需求不明確。缺乏正確的理論指導。軟件規(guī)模變大，復雜度變高軟件工程的三要素：方法，工具，過程構件概念：是指語義完整、語法正確和有可重用價值的單位軟件，是軟件重用過程中可以明確辨識的系統(tǒng)；結構上，它是語義描述、通訊接口和實現(xiàn)代碼的復合體常見構件模型：OMG的CORBA。Sun的EJB。Microsoft的DCOM（分布式構件對象模型）構件分類方法：關鍵字分類法?？堂娣诸惙?。超文本組織方法。軟件體系結構的定義：指定了系統(tǒng)的組織結構和拓撲結構，顯示了系統(tǒng)需求和構成系統(tǒng)的元素之間的對應關系，提供了一些設計決策的基本原理軟件體系結構的意義：1是風險承擔者進行交流的手段2是早期設計決策的體現(xiàn)3是可傳遞和可重用的模型軟件體系結構模型及功能：結構模型：以體系結構的構件、連接件和其他概念來刻畫結構，并力圖通過結構來反映系統(tǒng)的重要語義內(nèi)容?？蚣苣Ｐ停簜戎赜谡w結構。主要以一些特殊問題為目標建立只針對和適應該問題的結構。動態(tài)模型：是對結構或框架模型的補充，研究系統(tǒng)的“大顆?！钡男袨樾再|(zhì)。例如，描述系統(tǒng)的重新配置或演化。動態(tài)可以指系統(tǒng)總體結構的配置、建立或拆除通信通道或計算的過程。過程模型：過程模型研究構造系統(tǒng)的步驟和過程。功能模型：認為體系結構是由一組功能構件按層次組成，下層向上層提供服務?？梢钥醋魇且环N特殊的框架模型?！?+1”視圖模型及功能作用：邏輯視圖：主要支持系統(tǒng)的功能需求，即系統(tǒng)提供給最終用戶的服務。在邏輯視圖中，系統(tǒng)分解成一系列的功能抽象，這些抽象主要來自問題領域。這種分解不但可以用來進行功能分析，而且可用作標識在整個系統(tǒng)的各個不同部分的通用機制和設計元素。在面向對象技術中，通過抽象、封裝和繼承，可以用對象模型來代表邏輯視圖，用類圖來描述邏輯視圖。開發(fā)視圖：也稱模塊視圖，主要側重于軟件模塊的組織和管理。開發(fā)視圖要考慮軟件內(nèi)部的需求，如軟件開發(fā)的容易性、軟件的重用和軟件的通用性，要充分考慮由于具體開發(fā)工具的不同而帶來的局限性。開發(fā)視圖通過系統(tǒng)輸入輸出關系的模型圖和子系統(tǒng)圖來描述。進程視圖：側重于系統(tǒng)的運行特性，主要關注一些非功能性的需求。進程視圖強調(diào)并發(fā)性、分布性、系統(tǒng)集成性和容錯能力，以及從邏輯視圖中的主要抽象如何適合進程結構。它也定義邏輯視圖中的各個類的操作具體是在哪一個線程中被執(zhí)行的。物理視圖：主要考慮如何把軟件映射到硬件上，它通常要考慮到系統(tǒng)性能、規(guī)模、可靠性等。解決系統(tǒng)拓撲結構、系統(tǒng)安裝、通訊等問題。場景視圖：可以看作是那些重要系統(tǒng)活動的抽象，它使四個視圖有機聯(lián)系起來，從某種意義上說場景是最重要的需求抽象。在開發(fā)體系結構時，它可以幫助設計者找到體系結構的構件和它們之間的作用關系。同時，也可以用場景來分析一個特定的視圖，或描述不同視圖構件間是如何相互作用的。場景可以用文本表示，也可以用圖形表示。核心模型的基本元素：構件、連接件、配置、端口、角色。生命周期模型階段：軟件體系結構的非形式化描述階段；規(guī)范描述和分析階段；求精及其驗證；實施；演化和擴展；提供評價和度量；終結；9.軟件體系結構風格定義：是描述某一特定應用領域中系統(tǒng)組織方式的慣用模式10.經(jīng)典的軟件體系結構風格：1數(shù)據(jù)流風格：批處理序列；管道/過濾器。2調(diào)用/返回風格：主程序/子程序；面向對象風格；層次結構。3獨立構件風格：進程通訊；事件系統(tǒng)。4虛擬機風格：解釋器；基于規(guī)則的系統(tǒng)。5倉庫風格：數(shù)據(jù)庫系統(tǒng)；超文本系統(tǒng)；黑板系統(tǒng)。11.C/S（客戶-服務器）風格定義：C/S軟件體系結構是基于資源不對等，且為實現(xiàn)共享而提出來的。它定義了工作站如何與服務器相連，以實現(xiàn)數(shù)據(jù)和應用分布到多個處理機上。有三個主要組成部分：數(shù)據(jù)庫服務器、客戶應用程序和網(wǎng)絡。C/S風格優(yōu)點：1）對于軟硬件的變化有極大的靈活性2）把大的應用處理任務分布到低成本計算機上節(jié)約費用3）強大的數(shù)據(jù)操作和事務處理能力缺點：開發(fā)成本較高。客戶端程序設計復雜。信息內(nèi)容和形式單一。用戶界面風格不一，使用繁雜，不利于推廣使用。軟件移植困難。軟件維護和升級困難。新技術不能輕易應用。12.三層C/S風格：三層：表示層，功能層，數(shù)據(jù)層。優(yōu)點：1合理地劃分三層結構的功能，在邏輯上保持相對獨立性，能提高系統(tǒng)和軟件的可維護性和可擴展性2更靈活有效地選用相應的平臺和硬件系統(tǒng)，在處理負荷能力上與處理特性上分別適應于結構清晰的三層；并且這些平臺和各個組成部分可以具有良好的可升級性和開放性3應用各層可以并行開發(fā)，可以選擇各自最適合的開發(fā)語言4利用功能層有效地隔離開表示層與數(shù)據(jù)層，為嚴格的安全管理奠定了堅實的基礎缺點：1三層C/S結構各層間的通信效率若不高2設計時必須慎重考慮三層間的通信方法、通信頻度及數(shù)據(jù)量。13．B/S風格（瀏覽/服務器）：三層C/S應用結構的一種實現(xiàn)方式，其具體結構為：瀏覽器/Web服務器/數(shù)據(jù)庫服務器優(yōu)點：1）節(jié)約成本2）易于升級3）充分的利用網(wǎng)上的資源4）減少維護的工作量缺點：1B/S體系結構缺乏對動態(tài)頁面的支持能力，沒有集成有效的數(shù)據(jù)庫處理功能2系統(tǒng)擴展能力差，安全性難以控制3在數(shù)據(jù)查詢等響應速度上，要遠遠地低于C/S體系結構4數(shù)據(jù)提交一般以頁面為單位，數(shù)據(jù)的動態(tài)交互性不強，不利于在線事務處理(OLTP)應用14.HMB風格（基于層次消息總線的體系結構風格）：HMB風格基于層次消息總線/支持構件的分布和并發(fā)，構件之間通過消息總線進行通信。消息總線是系統(tǒng)的連接件，負責消息的分派、傳遞和過濾以及處理結果的返回。各個構件掛接在消息總線上，向總線登記感興趣的消息類型。構件根據(jù)需要發(fā)出消息,由消息總線負責把該消息分派到系統(tǒng)中所有對此消息感興趣的構件，消息是構件之間通信的唯-方式。構件接收到消息后,根據(jù)自身狀態(tài)對消息進行響應,并通過總線返回處理結果。由于構件通過總線進行連接,并不要求各個構件具有相同的地址空間或局限在一臺機器上。15.HMB風格消息總線的功能：1消息登記2消息分派和傳遞3消息過濾UML中的關系：依賴，關聯(lián)，泛化，實現(xiàn)。類之間的關系：關聯(lián)，依賴，泛化，聚合，組合，實現(xiàn)，流關系。UML包含的圖：類圖、對象圖、構建圖、組合結構圖、用例圖、順序圖、通信圖、定時圖、狀態(tài)圖、活動圖、部署圖、制品圖、包圖、交互概覽圖軟件質(zhì)量屬性：性能、可靠性（容錯，健壯性），可用性，安全性，可修改性（可維護性，可擴展性，結構重組，可移植性），功能性，可變性，繼承性，互操作性。評估主要方式：基于調(diào)查問卷或檢查表、基于場景、基于度量的評估方式ATAM評估步驟：描述ATAM方法；描述業(yè)務動機；描述架構；確定架構方法；生成質(zhì)量屬性效用樹；分析架構方法；討論場最和對場景分級.；分析架構方法；描述評估結果。SAAM評估步驟：形成場景、描述體系結構、對場景進行分類和確定優(yōu)先級、對間接場景進行單個評估、評估場景的相互作用、形成總體評價軟件產(chǎn)品線定義：產(chǎn)品線是一個產(chǎn)品集合，這些產(chǎn)品共享一個公共的、可管理的特征集，這個特征集能滿足選定的市場或任務領域的特定需求。這些系統(tǒng)遵循一個預描述的方式，在公共的核心資源基礎上開發(fā)的XML概念：XML是一套定義語義標記的規(guī)則，也是元標記語言，用于定義其他與特定領域有關的，語義的，結構化的標記語言的句法語言。SOA定義：是一種應用程序體系結構，在這種體系結構中，所有功能都定義為獨立服務，這些服務帶有定義明確的可調(diào)用接口，能夠以定義好的順序調(diào)用這些服務來形成業(yè)務流程。SOA特征：松散耦合、粗粒度服務、標準化接口SOA設計原則：明確定義的接口；自包含和模塊化；粗粒度；松耦合；互操作性、兼容和策略聲明SOA每一層的作用（技術）：發(fā)現(xiàn)服務層（UDDI、DISCO）：幫助客戶端應用程序解析遠程服務位置，通過UDDI來實現(xiàn)。描述服務層（WSDL、XML

Schema）：為客戶端應用程序提供正確的與遠程服務交互的描述信息，通過WSDL來實現(xiàn)消息格式層（SOAP、REST）：保證客戶端應用程序和服務器端在格式上一致，SOAP實現(xiàn)編碼層（XML）：主要為客戶端和服務器之間提供一個標準的，獨立于平臺的數(shù)據(jù)交換編碼格式。通過XML實現(xiàn)。傳輸層（HTTP、SMTP等）：為客戶端和服務器之間提供兩者交互的網(wǎng)絡通信協(xié)議，通過HTTP和SMTP實現(xiàn)SOAP應用：HTTP、RPC6.SOAP包含幾部分？1）SOAP封裝。定義整體框架，用來表示消息中包含的內(nèi)容，誰處理這些內(nèi)容，以及這些內(nèi)容是可選的或是必需的2）SOAP編碼規(guī)則。定義序列化的機制，用于交換系統(tǒng)定義的數(shù)據(jù)類型的實例3）SOAPRPC表示。定義用來表示遠程過程調(diào)用和應答的協(xié)議4）SOAP綁定。定義使用底層傳輸協(xié)議來完成在節(jié)點間交換SOAP信封的約定設計模式：設計模式描述了一個出現(xiàn)在特定設計語境中的特殊的再現(xiàn)設計問題，并為它的解決方案提供了一個經(jīng)過充分驗證的通用圖示。設計模式的組成：模式名稱、問題、解決方案、后果。設計模式的分類：創(chuàng)建型模式：工廠方法模式，抽象工廠模式，原型模式，單例模式，構建器模式；結構型：適配器模式、橋接模式、組合模式、裝飾模式、外觀模式，享元模式，代理模式；行為型模式：職責鏈模式，命令模式，解釋器模式，迭代器模式，中介者模式，備忘錄模式，觀察者模式，狀態(tài)模式，策略模式，模板方法模式，訪問者模式MVC與SpringMVC：MVC：是模型(model)視圖(view)控制器(controller)縮寫。是用一種業(yè)務邏輯、數(shù)據(jù)與界面顯示分離的方法來組織代碼，將眾多的業(yè)務邏輯聚集到一個部件里面，在需要改進和個性化定制界面及用戶交互的同時，不需要重新編寫業(yè)務邏輯，達到減少編碼的時間。（2）MVC構成：Model：封裝領域數(shù)據(jù)及邏輯；View：查詢領域數(shù)據(jù)并展現(xiàn)給用戶Conctroller：截獲用戶請求并改變領域數(shù)據(jù)（2）SpringMVC分層：實體類也是POJO類，也就是MVC的數(shù)據(jù)模型，實體類僅有屬性以及獲取和設置屬性的get和set方法，沒有事務處理方法。DAO負責數(shù)據(jù)訪問Service業(yè)務層主要用來處理業(yè)務邏輯Controller層負責具體業(yè)務模塊流程控制，在此層調(diào)用Serice層的接口來控制業(yè)務流程。（4）IOC“控制反轉”：借助于“第三方”實現(xiàn)具有依賴關系的對象之間的解耦。一種將控制權轉移的設計模式，由傳統(tǒng)的程序控制轉移到容器控制。（5）DI依賴注入：就是由IOC容器在運行期間，動態(tài)地將某種依賴關系注入到對象之中。常用的有兩種方式：構造方法注入和setter方法注入。publicclassSingleton{privatestaticSingletoninstance;privateSingleton(){}publicstaticSingletongetInstance(){if(instance==null){instance=newSingleton();}returninstance;}}單例模式保證一個類只有一個實例，并提供一個訪問它的全局訪問點抽象工廠模式：提供接口，可以創(chuàng)建一系列相關或相互依賴的對象，而無需指定具體的類publicinterfaceAbstractFactory{//創(chuàng)建產(chǎn)品的方法publicAbstractProductACreateProductA();publicAbstractProductBCreateProductB();}publicinterfaceAbstractProductA{/*抽象產(chǎn)品接口*/}publicinterfaceAbstractProductB{}/*實際的產(chǎn)品*/publicclassProductA1implementsAbstractProductA{//實際的產(chǎn)品A1}publicclassProductA2implementsAbstractProductA{//實際的產(chǎn)品A2}publicclassProductB1implementsAbstractProductB{//實際的產(chǎn)品B1}publicclassCFactory1implementsAbstractFactory{/*CFactory是ConcreteFactory的簡寫*/publicAbstractProductACreateProductA(){returnnewProductA1();/*在第1個車間中，創(chuàng)建實際產(chǎn)品A1*/}}publicclassCFactory1implementsAbstractFactory{publicAbstractProductBCreateProductB(){returnnewProductB1();}}publicclassCFactory2implementsAbstractFactory{publicAbstractProductACreateProductA(){returnnewProductA2();}}觀察者模式：對象間一對多的依賴關系，對象改變，依賴它的對象得到通知并自動更新importjava.util.*;publicclassObserverPattern{publicstaticvoidmain(String[]args){Subjectsubject=newConcreteSubject();Observerobs1=newConcreteObserver1();subject.add(obs1);subject.notifyObserver();}}abstractclassSubject{//抽象目標protectedList<Observer>observers=newArrayList<Observer>();publicvoidadd(Observerobserver){observers.add(observer);}publicvoidremove(Observerobserver){observers.remove(observer);}publicabstractvoidnotifyObserver();//通知觀察者方法}classConcreteSubjectextendsSubject{//具體目標publicvoidnotifyObserver(){for(Objectobs:observers){((Observer)obs).response();}具體目標發(fā)生改變}}//抽象觀察者interfaceObserver{voidresponse();//反應}classConcreteObserver1implementsObserver{publicvoidresponse(){具體觀察者反應！");}}importjava.util.ArrayList;組合模式：將對象組合成樹型結構表示“整體-部分”結構importjava.util.List;publicclassEmployee{privateStringname;privateintsalary;privateList<Employee>subordinates;publicEmployee(Stringname,intsal){//構造函數(shù)=name;this.salary=sal;subordinates=newArrayList<Employee>();}publicvoidadd(Employeee){subordinates.add(e);}publicvoidremove(Employeee){subordinates.remove(e);}publicList<Employee>getSubordinates(){returnsubordinates;}publicStringtoString(){return("Employee:[Name:"+name+",salary:"+salary+"]");}}importjava.util.ArrayList;importjava.util.List;publicclassEmployee{privateStringname;privateintsalary;privateList<Employee>subordinates;publicEmployee(Stringname,intsal){//構造函數(shù)=name;this.salary=sal;subordinates=newArrayList<Employee>();}publicvoidadd(Employeee){subordinates.add(e);}publicvoidremove(Employeee){subordinates.remove(e);}publicList<Employee>getSubordinates(){returnsubordinates;}publicStringtoString(){return("Employee:[Name:"+name+",salary:"+salary+"]");}}中間件概念