軟件體系結構風格軟件框架設計的核心問題是：能否復用已經(jīng)成型的體系結構方案不同系統(tǒng)的設計方案存在著許多共性問題，把這些共性部分抽取出來，就形成了具有代表性的和可廣泛接受的體系結構風格什么是軟件體系結構風格？軟件體系結構風格是描述某一特定應用領域中系統(tǒng)組織方式的慣用模式。軟件體系結構風格的作用是什么？1.指導如何將各個模塊和子系統(tǒng)有效地組織成一個完整的系統(tǒng)。2.有關風格的使用帶來了設計者的交流形式。關于設計元素的詞匯促進了設計者理解和交流。3.使用風格能夠使代碼的重用性得到提高。當用不同的系統(tǒng)時，基本的架構代碼風格不需要修改，它能夠用于不同的系統(tǒng)中。體系結構風格對于高質量的軟件產(chǎn)品而言，首先要為其選擇合適的體系結構風格，這樣就能夠更好地重用已有的設計方案和實現(xiàn)方案體系結構風格最關鍵的四要素◎提供一個詞匯表◎定義一套配置規(guī)則◎定義一套語義解釋原則◎定義對基于這種風格的系統(tǒng)所進行的分析體系結構的風格有哪些？管道-過濾器風格面向對象風格事件驅動風格分層風格數(shù)據(jù)共享風格解釋器風格反饋控制環(huán)風格特點：1.每個構件都有輸入輸出，構件完成對輸入數(shù)據(jù)的處理產(chǎn)生輸出。2.構件之間相對獨立，相互之間無交互狀態(tài),非鄰近過濾器不共享任何信息。3.整個體系結構的最終輸出與格構件執(zhí)行的順序無關。詞匯：過濾器：構件管道：連接管道-過濾器風格優(yōu)點◎使得軟構件具有良好的隱蔽性和高內聚、低耦合的特點；◎允許設計者將整個系統(tǒng)的輸入/輸出行為看成是多個過濾器的行為的簡單合成；◎支持軟件重用。只要提供適合在兩個過濾器之間傳送的數(shù)據(jù)，任何兩個過濾器都可被連接起來；◎系統(tǒng)維護和增強系統(tǒng)性能簡單。新的過濾器可以添加到現(xiàn)有系統(tǒng)中來；舊的可以被改進的過濾器替換掉；◎允許對一些如吞吐量、死鎖等屬性的分析；◎支持并行執(zhí)行。每個過濾器是作為一個單獨的任務完成，因此可與其它任務并行執(zhí)行。缺點◎通常導致進程成為批處理的結構。這是因為雖然過濾器可增量式地處理數(shù)據(jù)，但它們是獨立的，所以設計者必須將每個過濾器看成一個完整的從輸入到輸出的轉換?！虿贿m合處理交互的應用。當需要增量地顯示改變時，這個問題尤為嚴重?！蛞驗樵跀?shù)據(jù)傳輸上沒有通用的標準，每個過濾器都增加了解析和合成數(shù)據(jù)的工作，這樣就導致了系統(tǒng)性能下降，并增加了編寫過濾器的復雜性。◎難以進行錯誤處理，管道/過濾器結構的固有特性，決定了很難制定錯誤處理的一般性策略實例：傳統(tǒng)的編譯器是管道/過濾器體系結構風格的一個實例這種風格建立在數(shù)據(jù)抽象和面向對象的基礎上，數(shù)據(jù)的表示方法和它們的相應操作封裝在一個抽象數(shù)據(jù)類型或對象中。特點：1.對象是構件。2.在對象和對象之間，通過函數(shù)調用和過程調用來進行交互。面向對象風格優(yōu)點◎一個對象對外界隱藏了自己的詳細信息，改變一個對象的表示，不會影響系統(tǒng)的其它部分◎繼承和封裝方法為對象復用提供了技術支持?！驅ο髮?shù)據(jù)和操作封裝在一起，提高了系統(tǒng)內聚性，減小了模塊之間的耦合程度，使系統(tǒng)更容易分解為既相互作用又相互獨立的對象集合缺點：◎如果一個對象要調用另一個對象，則必須知道它的標識和名稱◎會產(chǎn)生連鎖反應，如果一個對象的標識發(fā)生改變，那么必須修改所有顯式調用它的其它對象，并消除由此引發(fā)的副作用

構件不直接調用一個過程，而是觸發(fā)或廣播一個或多個事件。系統(tǒng)中的其它構件中的過程在一個或多個事件中注冊，當一個事件被觸發(fā)，系統(tǒng)自動調用在這個事件中注冊的所有過程，這樣，一個事件的觸發(fā)就導致了另一模塊中的過程的調用。特點：1.構件是模塊，模塊可以是過程也可以是事件的集合。2.連接件：往往是以過程之間的隱式調用(ImplicitInvocation)來實現(xiàn)的事件驅動風格例：觀察者模式

publicinterfaceSubject

{

publicvoidattach(Observerobserver);

publicvoiddetach(Observerobserver);

voidnotifyObservers();

}

publicclassConcreteSubjectimplementsSubject

{

publicvoidattach(Observerobserver)

{

observersVector.addElement(observer);

}

publicvoiddetach(Observerobserver)

{

observersVector.removeElement(observer);

}

publicvoidnotifyObservers()

{

Enumerationenumeration=observers();

while(enumeration.hasMoreElements())

{

((Observer)enumeration.nextElement()).update();

}

}

publicEnumerationobservers()

{

return(（Vector)observersVector.clone()).elements();

}

privateVectorobserversVector=newjava.util.Vector();

}

publicinterfaceObserver

{

voidupdate();

}publicstaticvoidmain(Stringargs[]){ Subjects=newConcreteSubject(); s.attach(newObserver(){publicvoidupdate(){ System.out.println("ok"); } }); s.notifyer(); }優(yōu)點：◎事件聲明者不需要知道哪些構件會響應事件，因此，不能確定構件處理的先后順序，甚至不能確定事件會引發(fā)哪些過程調用◎提高了軟件復用能力，只要在系統(tǒng)事件中注冊構件的過程，就可以將該構件集成到系統(tǒng)中◎便于系統(tǒng)升級，只要構件名和事件中所注冊的過程名保持不變，原有構件就可以被新構件所替代缺點：◎構件放棄了對系統(tǒng)計算的控制。一個構件觸發(fā)一個事件時，不能確定其它構件是否會響應它。而且即使它知道事件注冊了哪些構件的構成，它也不能保證這些過程被調用的順序?！驍?shù)據(jù)交換的問題。有時數(shù)據(jù)可被一個事件傳遞，但另一些情況下，基于事件的系統(tǒng)必須依靠一個共享的倉庫進行交互。在這些情況下，全局性能和資源管理便成了問題實例：1.Debugger2.在用戶界面中分離數(shù)據(jù)和表示特點：分層系統(tǒng)采用多個層次組織，每一層必須起兩個作用：（1）使用下層提供的功能。（2）為上層提供服務。分層風格publicinterfaceStudentDAO(){ListselectAll(){}StudentSelect(intid){}voidupdate(Students){}voiddelete(intid){}voidadd(Students){}}publicclassStudentDAOImpl(){}publicclassStudentBusiness{ StudentDaodao; publicStudent(StudentDaodao){ this.dao=dao } publicliststudentChoice(Listids){ Listlist=newArrayList(); for(inti=0;i<ids.size();i++){ intid=list.get(i);Students=dao.select(id); list.add(s); } returnlist;}優(yōu)點◎支持基于抽象程度遞增的系統(tǒng)設計，使設計者可以把一個復雜系統(tǒng)按遞增的步驟進行分解；◎支持功能增強，因為每一層至多和相鄰的上下層交互，因此功能的改變最多影響相鄰的上下層；◎支持重用。只要提供的服務接口定義不變，同一層的不同實現(xiàn)可以交換使用。這樣，就可以定義一組標準的接口，而允許各種不同的實現(xiàn)方法。缺點：◎并不是每個系統(tǒng)都可以很容易地劃分為分層的模式，甚至即使一個系統(tǒng)的邏輯結構是層次化的，出于對系統(tǒng)性能的考慮，系統(tǒng)設計師不得不把一些低級或高級的功能綜合起來；◎很難找到一個合適的、正確的層次抽象方法。實例：操作系統(tǒng)、數(shù)據(jù)庫系統(tǒng)、計算機網(wǎng)絡協(xié)議組數(shù)據(jù)共享風格也稱為倉庫風格，有兩種不同類型的軟件元素：一種是中央數(shù)據(jù)單元，也稱為資源庫，用于表示系統(tǒng)的當前狀態(tài)，另一種是相互依賴的構件組,中央數(shù)據(jù)單元和構件之間可以進行信息交換，這是數(shù)據(jù)共享體系結構的技術實現(xiàn)基礎數(shù)據(jù)共享體系結構風格根據(jù)所使用的控制策略不同，數(shù)據(jù)共享體系結構可以分為兩種類型：一種是傳統(tǒng)的數(shù)據(jù)庫，另一種是黑板如果由輸入流中的事件來驅動系統(tǒng)進行信息處理，把執(zhí)行結果存儲到中央數(shù)據(jù)單元中，則這個系統(tǒng)就是數(shù)據(jù)庫應用系統(tǒng)如果由中央數(shù)據(jù)單元的當前狀態(tài)來驅動系統(tǒng)運行，則這個系統(tǒng)就是黑板應用系統(tǒng)一個典型的黑板型數(shù)據(jù)共享系統(tǒng)包括以下三個部分：知識源：知識源中包含獨立的、與應用程序相關的知識，知識源之間不直接進行通訊，它們之間的交互只通過黑板來完成。黑板數(shù)據(jù)結構：黑板數(shù)據(jù)是按照與應用程序相關的層次來組織的解決問題的數(shù)據(jù)，知識源通過不斷地改變黑板數(shù)據(jù)來解決問題。控制：控制完全由黑板的狀態(tài)驅動，黑板狀態(tài)的改變決定使用的特定知識。黑板模式對于無確定性求解策略的問題比較有用，在專家系統(tǒng)中，這種模式應用的比較廣泛。例：問題：設字符轉換規(guī)則

A∧B→C A∧C→D B∧C→G B∧E→F D→E

已知：A，B

求：F一、綜合數(shù)據(jù)庫

{x}，其中x為字符二、規(guī)則集

1，IFA∧BTHENC 2，IFA∧CTHEND 3，IFB∧CTHENG 4，IFB∧ETHENF 5，IFDTHENE三、控制策略 順序排隊四、初始條件

{A，B}五、結束條件

F∈{x}綜合數(shù)據(jù)庫可觸發(fā)規(guī)則被觸發(fā)規(guī)則A，B（1）（1）A，B，C（2）（3）（2）A，B，C，D（3）（5）（3）A，B，C，D，G（5）（5）A，B，C，D，G，E（4）（4）A，B，C，D，G，E，F(xiàn)1，IFA∧BTHENC 2，IFA∧CTHEND3，IFB∧CTHENG 4，IFB∧ETHENF5，IFDTHENE求解過程例：傳教士與野人問題（M-C問題）

問題：

N個傳教士，N個野人，一條船，可同時乘坐k個人，要求在任何時刻，在河的兩岸及船上，傳教士人數(shù)不能少于野人的人數(shù)。

問：如何過河。 以N=3，k=2為例求解。1.解決問題的多方法性：對于一個專家系統(tǒng)，針對于要解決的問題，如果在其領域中沒有獨立的方法存在，而且對解空間的完全搜索也是不可行的，在黑板模式中可以用多種不同的算法來進行試驗，并且也允許用不同的控制方法。2.具有可更改性和可維護性：因為在黑板模式中每個知識源是獨立的，彼此之間的通信通過黑板來完成，所以這使整個系統(tǒng)更具有可更改性和可維護性。優(yōu)點：3.有可重用的知識源：由于每個知識源在黑板系統(tǒng)中都是獨立的，如果知識源和所基于的黑板系統(tǒng)有理解相同的協(xié)議和數(shù)據(jù)，我們就可以重用知識源。4.支持容錯性和健壯性：在黑板模式中所有的結果都是假設的，并且只有那些被數(shù)據(jù)和其它假設強烈支持的才能夠生存。這對于噪聲數(shù)據(jù)和不確定的結論有很強的容錯性。1.測試困難：由于黑板模式的系統(tǒng)有中央數(shù)據(jù)構件來描述系統(tǒng)的體現(xiàn)系統(tǒng)的狀態(tài)，所以系統(tǒng)的執(zhí)行沒有確定的順序，其結果的可再現(xiàn)性比較差，難于測試。2.不能保證有好的求解方案：一個黑板模式的系統(tǒng)所提供給我們的往往是所解決問題的一個百分比，而不是最佳的解決方案。3.效率低：黑板模式的系統(tǒng)在拒絕錯誤假設的時候要承受多余的計算開銷，所以導致效率比較低。缺點4.開發(fā)成本高：絕大部分黑板模式的系統(tǒng)需要用幾年的時間來進化，所以開發(fā)成本較高。5.缺少對并行機的支持：黑板模式要求黑板上的中心數(shù)據(jù)同步并發(fā)訪問，所以缺少對不并行機的支持。數(shù)據(jù)共享風格實例：專家系統(tǒng)、語音識別等在開發(fā)具有人機界面的軟件系統(tǒng)時，比較適合使用模型-視圖-控制器體系結構在MVC結構中，主要包括模型、視圖和控制器：模型，是應用程序的核心，封裝了問題的核心數(shù)據(jù)、邏輯關系和計算功能，提供了處理問題的操作過程視圖，是模型的表示，提供了交互界面，為用戶顯示模型信息控制器，負責處理用戶與系統(tǒng)之間的交互，為用戶提供操作接口MVC體系結構風格MVC體系結構具有以下優(yōu)點：多個視圖與一個模型相對應，變化-傳播機制確保了所有相關視圖都能夠及時地獲取模型變化信息，從而使所有視圖和控制器同步，便于維護具有良好的移植性，由于模型獨立于視圖，因此，可以方便地實現(xiàn)不同部分的移植系統(tǒng)被分割為三個獨立的部分，當功能發(fā)生變化時，改變其中的一個部分就能夠滿足要求MVC體系結構風格也存在著一些問題：增加了系統(tǒng)設計和運行復雜性視圖與控制器連接過于緊密，妨礙了二者的獨立重用視圖訪問模型的效率比較低packagemypack;importcom.opensymphony.xwork2.ActionSupport;publicclassUserActionextendsActionSupport{ privateStringusername; privateStringuserpass;

publicStringgetUsername(){ returnusername; } publicvoidsetUsername(Stringusername){ this.username=username; } publicStringgetUserpass(){ returnuserpass; } publicvoidsetUserpass(Stringuserpass){ this.userpass=userpass; } @Override publicStringexecute()throwsException{ if("Mike".equals(username)&&"123".equals(userpass) ||"張三".equals(username)&&"abc".equals(userpass)) return"success"; else return"error"; }}<?xmlversion="1.0"encoding="UTF-8"?><!DOCTYPEstrutsPUBLIC"-//ApacheSoftwareFoundation//DTDStrutsConfiguration2.0//EN""/dtds/struts-2.0.dtd"><struts><!--定義包管理配置的action繼承struts-default.xml中的配置

--> <packagename="actions"extends="struts-default"><!--定義Action(login.action)--> <actionname="login"class="mypack.UserAction"><!--定義轉發(fā)路徑對應的字符串名

--> <resultname="success">/Success.jsp</result> <resultname="error">/Error.jsp</result> </action> </package></struts><!--過濾器類

--><filter><filter-name>struts2</filter-name><filter-class>org.apache.struts2.dispatcher.FilterDispatcher</filter-class></filter><!--過濾所有的url請求

--><filter-mapping><filter-name>struts2</filter-name><url-pattern>/*</url-pattern></filter-mapping><%@pagelanguage="java"import="java.util.*"pageEncoding="utf-8"%><html>

<body><!--提交到action--> <formaction="login.action"method="post">

用戶名:<!--參數(shù)名和action中的屬性名一樣

--> <inputtype=textname=username> <br>

密

碼: <inputtype=passwordname=userpass> <br> <inputtype=submitname=submvalue="提交"> <inputtype=resetname=resetvalue="取消"> </form> </body></html>特征基于解釋器風格的系統(tǒng)核心在于虛擬機。一個基于解釋器風