第三章軟件體系結構風格與模式_第1頁
第三章軟件體系結構風格與模式_第2頁
第三章軟件體系結構風格與模式_第3頁
第三章軟件體系結構風格與模式_第4頁
第三章軟件體系結構風格與模式_第5頁
已閱讀5頁,還剩152頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1軟件體系結構的風格和模式SoftwareArchitecture建筑模式ChristopherAlexander,TheTimelessWayofBuilding,p247,1979每個模式是一個由三部分組成的規則,表達了特定環境、問題和解(solution)之間的關系。作為現實世界的一個成分,每個模式表達了下列三者之間的一種關系:特定環境,在該環境中反復出現的力(forces)的系統,以及協調這些力的某種空間排列。作為語言的一個成分,每個模式是一條指令,展示了這種空間排列如何被一再重復使用,目的是協調同特定環境相關的力的系統。簡單地說,模式既是存在于現實世界中的事物,又是告訴我們如何以及何時創造該事物的規則。模式既是過程,又是事物;既是活生生的事物的描述,又是創造該事物的過程的描述。軟件體系結構的構建模式軟件體系結構的特點之一就是抽象出了很多常見的系統構建模式,這些模式(或者說結構風格)是系統設計人員多年工作經驗的總結。軟件體系結構風格和模式的概念軟件體系結構風格(ArchitecturalStyle)一種體系結構風格以結構組織模式定義了一個系統家族關于構件和連接件類型的術語;一組約束對它們組合方式的規定;一個或多個語義模型,規定了如何從各成分的特性決定系統整體特性概括地說,一種軟件體系結構風格刻劃一個具有共享結構和語義的系統家族軟件體系結構模式(ArchitecturalPattern)一種軟件體系結構模式是對某個具體環境下問題的結構性解決方法體系結構風格模式系統中的詞匯目前尚不完善每個風格可以視為一組構件的集合,以及構件間的交互(連接器)構件(Components)+連接器(Connectors)E.g. C/S結構中構件:Client,Server連接器:C/S間的通訊協議軟件體系結構的構建風格風格分類:

1.管道-過濾器風格

2.面向對象風格

3.事件驅動風格

4.分層風格

5.數據共享風格

6.解釋器風格

7.反饋控制環風格

8.異構風格的集成特別注意:體系結構風格不是對軟件進行分類的標準。它僅僅是表示描述軟件的不同角度而已例如一個系統采用了分層風格,但這并不妨礙它用面向對象的方法來實現。同一個系統采用多種風格造成了所謂體系結構風格的異構組合。管道-過濾器風格概述在管道-過濾器風格下,每個功能模塊都有一組輸入和輸出。功能模塊稱作過濾器(filters);功能模塊間的連接可以看作輸入、輸出數據流之間的通路,所以稱作管道(pipes)。管道-過濾器風格的特性之一在于過濾器的相對獨立性,即過濾器獨立完成自身功能,相互之間無需進行狀態交互。管道-過濾器風格特性過濾器是獨立運行的構件非臨近的過濾器之間不共享狀態過濾器自身無狀態過濾器對其處理上下連接的過濾器“無知”對相鄰的過濾器不施加任何限制結果的正確性不依賴于各個過濾器運行的先后次序各過濾器在輸入具備后完成自己的計算。完整的計算過程包含在過濾器之間的拓撲結構中。管道-過濾器風格一個管道-過濾器風格的示意圖如下圖所示:管道-過濾器風格一個采用了嵌套的管道過濾器的系統示例:管道-過濾器風格優點設計者可以將整個系統的輸入、輸出特性簡單的理解為各個過濾器功能的合成。設計人員將整個系統的輸入輸出行為理解為單個過濾器行為的疊加與組合。這樣可以將問題分解,化繁為簡。將系統抽象成一個“黑箱”,其輸入是系統中第一個過濾器的輸入管道,輸出是系統中最后一個過濾器的輸出管道,而其內部各功能模塊的具體實現對用戶完全透明。管道-過濾器風格優點管道-過濾器風格支持功能模塊的復用任何兩個過濾器,只要它們之間傳送的數據遵守共同的規約,就可以相連接。每個過濾器都有自己獨立的輸入輸出接口,如果過濾器間傳輸的數據遵守其規約,只要用管道將它們連接就可以正常工作。管道-過濾器風格優點基于管道-過濾器風格的系統具有較強的可維護性和可擴展性。舊的過濾器可以被替代,新的過濾器可以添加到已有的系統上。軟件的易于維護和升級是衡量軟件系統質量的重要指標之一,在管道-過濾器模型中,只要遵守輸入輸出數據規約,任何一個過濾器都可以被另一個新的過濾器代替,同時為增強程序功能,可以添加新的過濾器。這樣,系統的可維護性和可升級性得到了保證。管道-過濾器風格優點支持一些特定的分析,如吞吐量計算和死鎖檢測等。利用管道-過濾器風格的視圖,可以很容易的得到系統的資源使用和請求的狀態圖。然后,根據操作系統原理等相關理論中的死鎖檢測方法就可以分析出系統目前所處的狀態,是否存在死鎖可能及如何消除死鎖等問題。管道-過濾器風格優點管道-過濾器風格具有并發性每個過濾器作為一個單獨的執行任務,可以與其它過濾器并發執行。過濾器的執行是獨立的,不依賴于其它過濾器的。在實際運行時,可以將存在并發可能的多個過濾器看作多個并發的任務并行執行,從而大大提高系統的整體效率,加快處理速度。管道-過濾器風格不足交互式處理能力弱管道-過濾器模型適于數據流的處理和變換,不適合為與用戶交互頻繁的系統建模。在這種模型中,每個過濾器都有自己的數據,這些數據或者是從磁盤存儲器中讀取來,或者是由另一個過濾器的輸出導入進來,整個系統沒有一個共享的數據區。這樣,當用戶要操作某一項數據時,要涉及到多個過濾器對相應數據的操作,其實現較為復雜。由以上的缺點,可以對每個過濾器增加相應的用戶控制接口,使得外部可以對過濾器的執行進行控制。管道-過濾器風格不足改進的過濾器管道-過濾器風格不足管道-過濾器風格往往導致系統處理過程的成批操作。設計者也許不得不花費精力協調兩個相對獨立但又存在某種關系的數據流之間的關系,例如多過濾器并發執行時數據流之間的同步問題等。根據實際設計的需要,設計者也需要對數據傳輸進行特定的處理(如為了防止數據泄漏而采取加密等手段),導致過濾器必須對輸入、輸出管道中的數據流進行解析或反解析,增加了過濾器具體實現的復雜性。管道-過濾器風格實例——數字通信系統通信的目的是傳遞消息。消息具有不同的形式,例如:符號、文字、語音、音樂、數據、圖片、圖像等等。因而,根據所傳遞消息的不同,目前通信業務可以分為電報、電話、傳真、數據傳輸及可視電話等。對于基本的點對點通信,是把發送端的消息傳遞到接收端。數字通信概念模型發送端接收端管道-過濾器風格實例——數字通信系統將上圖發送端進一步細分為信息源和發送設備,將接收端細分為接收設備和受信者;同時,在通信過程中會有噪聲干擾,在模型中添加噪聲源可得到圖所示的數字通信系統粗略模型。數字通信系統粗略模型信息源發送設備接收設備受信者噪聲源信道管道-過濾器風格實例——數字通信系統圖中各單元作用:信息源把各種可能信息轉換成原始電信號;發送設備對原始電信號完成某種變化,便于原始信號在信道中傳輸,然后再送入信道;信道是指信號傳輸的通道,它既可以看成是管道(因為它的目的并不是為了實現某種功能,僅僅是為了信號的傳輸),也可以從某種意義上看做是過濾器(因為信號經過信道后會產生一些變化,比如加入噪聲的影響,從而改變了發送設備發出的信號)。接收設備從接收信號中恢復出相應的原始信號;受信者(也稱為信息宿或接收終端)是將復原的原始信號轉換成相應的消息。噪聲源是信道中的噪聲以及分散在通信系統其它各處的噪聲的集中體現,它使原信號受到了干擾,產生畸變。管道-過濾器風格實例——數字通信系統在數字通信中存在以下幾個突出的問題:數字信號傳輸時,信道噪聲或干擾所造成的差錯,原則上都可以通過差錯控制編碼等手段來控制。為此,在發送端需要增加一個編碼器,而在接收端相應的需要一個解碼器。當需要保密時,可以有效的對基帶信號進行加密,防止信息被竊取或通信被破壞。此時,在接收端就需要進行解密。由于數字通信傳輸的是一個接一個按節拍傳送的數字信號單元,即碼元,因而接收端必須與發送端按相同的節拍進行接收。不然,會因接收節拍不一致而造成混亂,使接收倒的數據全部無效。因此,數字通信系統中必須有同步控制構件。針對上述問題,可得到數字通信系統詳細模型(下圖)管道-過濾器風格實例——數字通信系統數字通信系統詳細模型管道-過濾器風格實例管道-過濾器模式的體系結構是面向數據流的軟件體系結構。它最典型的應用是在編譯系統。一個普通的編譯系統包括詞法分析器,語法分析器,語義分析與中間代碼生成器,優化器,目標代碼生成器等一系列對源程序進行處理的過程。人們可以將編譯系統看作一系列過濾器的連接體,按照管道&過濾器的體系結構進行設計。需求描述:假設有一批實時的二維坐標點數據需要變換(即對點的橫、縱坐標進行縮放),并在屏幕上進行顯示,要求外部要能設置變換規則(如縮放倍數)和顯示規則(如顯示模式和顯示顏色)。管道-過濾器風格實例體系結構建模這是一個對坐標點的數據流進行順序處理的過程,可以應用管道-過濾器體系結構建模。將這個系統分為兩個過濾器,一個為坐標點數據流變換過濾器,另一個為坐標點數據流實時顯示過濾器。其中,坐標點數據流變換過濾器有一個外部控制接口對變換規則如縮放倍數進行設置,坐標點數據流實時顯示過濾器有一個外部控制接口對顯示規則如顯示模式和顯示顏色進行設置。整個系統的體系結構如圖所示。管道-過濾器風格實例系統體系結構圖管道-過濾器風格實例過濾器的設計可以將過濾器用狀態轉換圖表示。過濾器有如下狀態:停止狀態,工作狀態,等待狀態,休眠狀態。停止狀態:表示過濾器處于待啟動狀態,當外部啟動過濾器后,過濾器處于處理狀態;處理狀態:表示過濾器正在處理輸入數據隊列中的數據;等待狀態:表示過濾器的輸入數據隊列為空,此時過濾器等待,當有新的數據輸入時,過濾器處于處理狀態;休眠狀態:表示過濾器已經啟動,但被掛起。掛起的原因可能是由于外界用戶要設置過濾器的控制參數,這樣暫時將過濾器掛起但不中止它,當控制參數設置完畢后再將過濾器還原,繼續運行。這樣,實現了較高的效率。管道-過濾器風格實例過濾器狀態轉換圖使用示例Unix系統中的管道過濾器結構

lsinvoices|grep–eAugust|sort過濾器介紹過濾器的作用:對輸入數據的處理enriches:computingandaddinginforefines:concentratingorextractinginfotransforms:deliveringdataintosomeotherrepresentation被動式過濾器(Passivefilter)adjacentpipespulls/pushesoutput/inputdatafrom/intothefilteractiveeitherasafunction(pull)orasaprocedure(push)主動式過濾器(Activefilter)filterisactiveinaloop,checkthepipesfordataprocessingonitsownasaseparateprogramorthread數據源、數據接收端、管道介紹DataSource(數據源)inputdatastreamtothesystem,forexampleAfileconsistingoflinesoftextAsensordeliveringasequenceofnumbersdatacanbepushedorpulledintofirstprocessingstagePipes(管道)connectionsbetweenfilters,betweendatasourceandthefirstfilter,betweenthelastfilterandthedatasinksynchronizesjoinedactivefilters,forexample,byaFIFO(first-in-first-out)bufferforpassivefilters,thepipescanbeimplementedbyadirectcallMakethefilterrecombinationharderDataSink(數據接收端)consumesoutputdata管道-過濾器風格的類型類型pipelines—linearsequencesoffiltersboundedpipes—limitedamountofdataonapipetypedpipes—datastronglytypedbatchsequential—datastreamsarenotincremental面向對象風格特征概述面相對象模式集數據抽象、抽象數據類型、類繼承為一體,使軟件工程公認的模塊化、信息隱藏、抽象、重用性等原則在面向對象風格下得以充分實現。應用場合面向對象的體系結構模式適用于數據和功能分離的系統中,同樣也適合于問題域模型比較明顯,或需要人機交互界面的系統。大多數應用事件驅動風格的系統也常常應用了面向對象風格。面向對象風格面向對象風格的體系結構面向對象風格優點高度模塊性封裝功能代碼共享靈活性易維護性可擴充性面向對象風格不足面向對象風格最大的不足在于如果一個對象需要調用另一個對象,它就必須知道那個對象的標識(對象名或對象引用),這樣就無形之中增強了對象之間的依賴關系。如果一個對象改變了自己的標識,就必須通知系統中所有和它有調用關系的對象,否則系統就無法正常運行。面向對象風格面向對象風格實例實例背景目前,一個標準的計算機應用系統應該由三部分組成:計算機操作系統(包括各種應用軟件系統)、數據庫管理系統和網絡環境(包括網絡硬件設備和各種協議棧、網絡服務等),這樣一個具有分布式特性和開放性的系統稱為開放分布式系統(ODS,OpenDistributedSystem)。面向對象風格示例CBA方法:它有三個基本的建模概念:協作、類型和細化。協作(Collaboration):根據構件所承擔的不同角色,協作定義了一組構件之間的動作(Action)集合。類型(Type):通過描述一個構件的可視外部行為來定義構件在系統中所承擔的功能。細化(Refinement):體現了對同一事物的兩種不同描述之間的關系,抽象(Abstraction)描述為基礎,實現(Realization)描述可以看作抽象描述的具體的形式。面向對象風格面向對象風格面向對象風格ODS系統中構件、連接器和配置的模型,如下圖所示:面向對象風格面向對象風格面向對象風格實例構件的描述方法:利用GUI體系結構框架自動生成工具,可以完成下述幾點功能:生成構件模型,包括構件的屬性、接口和實現;建立連接器模型,包括協議、屬性和實現;體系結構的抽象和封裝;類型和類型檢查;主動規范,提供設計向導;多視圖模式,對不同層次的用戶顯示不同的內容;生成實現,如將構件對應為面向對象技術中的類;將系統的修改動態映射到實現。面向對象風格實例具有自適應穩定性的連接器模型連接器中的通信協議棧面向對象風格面向對象風格連接器的自適應穩定算法:為了提高通信協議棧在構件通信過程中的穩定性,需要設計某種自適應穩定算法,這樣可以修復構件通信時出現的錯誤。面向對象風格實例——人事檔案管理系統系統功能結構面向對象風格實例——人事檔案管理系統系統功能介紹:檔案管理根據高校人事檔案管理的特點,本模塊可通過錄入各類人事檔案信息,來構造檔案數據庫,編制各種目錄索檢。針對檔案材料錄入工作量較大,在該功能模塊中設置了多種方式快速錄入法,如對指定的部分內容可采用代碼錄入和菜單選項等輸入方法.信息檢索該模塊主要是檢索有關的人事檔案信息,其檢索方式為姓氏筆畫檢索目錄。在具體檢索中又可分為精確查詢和模糊查詢,并可將檢索內容動態輸出,滿足檔案查詢的需要。檔案借閱該模塊主要是對檔案的借閱情況、歸還情況、利用登記等方面進行管理。它能為研究如何更有效地利用人事檔案資料提供必要的信息。面向對象風格實例——人事檔案管理系統檔案轉遞該模塊包括人事檔案的轉進和轉出管理,編制清單,并能在檔案轉遞后,對已變更檔案數據庫進行相應地調整,以完成相應檔案的刪加。統計報表該模塊主要用于統計庫存的各類人事檔案的實際數量,及每年歸檔的各類檔案數量,并可完成相應的圖形繪制和報表打印。其中,在報表生成中,該模塊可根據管理人員對報表的自定義設置來生成相應的非范式報表。系統維護由于高校人事檔案的數據管理是一項非常重要的工作,尤其是它的安全可靠性。因此,在進入本模塊操作之前,系統會提醒用戶輸入姓名、操作口令和權限級別。同時該功能模塊還包括操作員管理、口令修改、重新登錄、權限級別設置、系統日志及系統初始化六個子模塊。系統幫助本模塊提供了在線聯機幫助,可實現幫助主題的查詢,還提供了計算器、日記/日歷等系統工具和關于本系統的簡介。面向對象風格實例——人事檔案管理系統系統活動圖面向對象風格實例——人事檔案管理系統系統類結構圖事件驅動風格特征事件驅動系統的基本觀點是一個系統對外部的表現可以從它對事件的處理表征出來。如圖示:事件驅動風格特征事件驅動系統具有以下一些特點:系統是由若干子系統或元素所組成的一個整體;系統有一定的目標,各子系統在某一種消息機制的控制下,為了這個目標而協調行動;在某一種消息機制的控制下,系統作為一個整體與環境相適應和協調;事件驅動風格特征事件驅動系統具有以下一些特點(續):在一個系統的若干子系統中,必定有一個子系統起著主導作用,而其他子系統則處于從屬地位;任一系統和系統內的任一元素,都有1個事件收集機制和1個事件處理機制,通過這種機制與周圍環境發生作用和聯系;事件驅動風格特征下圖是一個基于事件驅動的軟件系統的示意圖:事件驅動風格特征事件驅動風格系統設計時有下述幾條基本原則從系統論的角度來看待描述的對象,合理分解子系統,保證各個子系統的獨立性和社會性;無論系統多么復雜,子系統性質的差異多么大,任何子系統都可以按照有無子系統這一性質分為2類:管理系統和執行系統。為了達到系統的目標,系統內的各個子系統通過傳遞消息和執行消息來協同操作。為了達到系統的目標,系統內的各個子系統通過傳遞消息和執行消息來協同操作。事件驅動風格特征事件驅動風格系統設計時有下述幾條基本原則(續)在一個完整系統中,必須有這樣一個子系統,它沒有上級,必須收集系統外的事件及下級發出的事件。管理類型的子系統一般不執行具體操作,它的主要功能是按照自己的職能指揮下級完成任務,功能性操作一般由執行類型的子系統完成。在一般情況下,除最高級管理子系統外,子系統一般是“有問才答”,即使在必要的情況下需要積極尋找事件時,也必須征得上級系統得許可,保證了系統的控制流不會分散。事件驅動風格基本結構事件驅動系統具有某種意義上的遞歸性,形成了“部分-整體”的層次結構,可以用屬性結構加以表示。一個簡單的表示方法是為執行系統定義一些類,另外定義一些類作為這些執行系統的容器類,也就是管理系統。事件驅動風格事件驅動風格的基本結構,如下圖:事件驅動風格優點事件驅動風格非常適合于描述系統族,在屬于同一族的任何系統中,系統的高級管理子系統的描述是完全類似的,便于重用;由于最高管理子系統牢牢的掌握著控制權,又因為各同級子系統一般不直接發生關系,因此容易實現并發處理和多任務操作;基于事件驅動風格的系統具有良好的可擴展性,設計者只需為某個對象注冊一個事件處理接口就可以將該對象引入整個系統,同時并不影響其它的系統對象。事件驅動風格優點定義了包含執行子系統和管理子系統的類層次結構;簡化客戶代碼;使整個系統的設計更具有一般化。事件驅動風格不足事件驅動風格最大的不足在于構件削弱了自身對系統計算的控制能力事件驅動風格中存在的另一個問題在于數據共享系統中各個對象的邏輯關系變得更加復雜事件驅動風格和面向對象風格的關系基于面向對象風格的系統由多個封裝起來的對象構成,對象之間通過消息傳遞實現通信,而事件驅動正是對消息傳遞機制的一種實現。所以基于事件驅動風格的系統往往都是面向對象的。事件驅動風格實例事件驅動風格實例:JavaBean系統概述事件從事件源到監聽者的傳遞是通過對目標監聽者對象的Java方法調用進行的。對每個明確的事件的發生,都相應地定義一個明確的Java方法。這些方法都集中定義在事件監聽者(EventListener)接口中,這個接口要繼承java.util.EventListener。事件驅動風格實例JavaBean系統(續)事件狀態對象與事件發生有關的狀態信息一般都封裝在一個事件狀態對象中,這種對象是java.util.EventObject的子類。按設計習慣,這種事件狀態對象類的名應以Event結尾。事件驅動風格實例JavaBean系統(續)事件監聽者接口(EventListenerInterface)與事件監聽者由于Java事件模型是基于方法調用,因而需要一個定義并組織事件操縱方法的方式。JavaBean中,事件操縱方法都被定義在繼承了java.util.EventListener類的EventListener接口中,按規定,EventListener接口的命名要以Listener結尾。任何一個類如果想操縱在EventListener接口中定義的方法都必須以實現這個接口方式進行。這個類也就是事件監聽者。事件驅動風格實例JavaBean系統(續)事件監聽者的注冊與注銷為了各種可能的事件監聽者把自己注冊入合適的事件源中,建立源與事件監聽者間的事件流,事件源必須為事件監聽者提供注冊和注銷的方法。在前面的bound屬性介紹中已看到了這種使用過程,在實際中,事件監聽者的注冊和注銷要使用標準的設計格式:publicvoidadd<ListenerType>(<ListenerType>listener)publicvoidremove<ListenerType>(<ListenerType>listener)事件驅動風格實例適配類適配類是JavaBean事件模型中極其重要的一部分。在一些應用場合,事件從源到監聽者之間的傳遞要通過適配類來“轉發”。適配類成為了事件監聽者,事件源實際是把適配類作為監聽者注冊入監聽者隊列中,而真正的事件響應者并未在監聽者隊列中,事件響應者應做的動作由適配類決定。事件驅動風格實例TurboVisionBorland公司開發的TurboPascal6.0中提供了一種面向對象的事件驅動程序設計的工具包TurboVision。TurboVision把各種屏幕上的可見對象歸納為2大類:一類為執行對象,另一類為管理對象,分別稱為TView和TGroup類對象。又因為TGroup和TView類有相同之處,故TGroup是從TView派生而得,在TurboVision中,TGroup類的對象一般不進行實際操作,不直接在屏幕上顯示自己,而是通過自己的下屬顯示自己,所有的實際操作都是通過TView類對象進行的。

事件驅動風格實例TurboVision很好地體現了面向對象方法和事件驅動程序設計方法的精髓,TApplication是一個可以運行的交互式程序對象,除了啟動和退出之外,它不提供任何功能,使用TurboVision,就能高效和快速地開發出高質量地應用程序。事件驅動風格實例TurboVision

TurboVision軟件包中對象的分類結構如圖所示:TurboVision中對象的分類結構事件驅動風格實例TurboVision

TurboVision對象的組裝結構一般說來,TApplication對象擁有并管理它創建的3個子對象TMenuBar,TDeskTop和TStatusLine,如圖所示.

TurboVision的組裝結構事件驅動風格實例TurboVision在程序的實際運行中,Application對象通常創建各種TWindow類和Tdialog類對象,并委托DeskTop代為管理.因此,DeskTop對象的組裝常常隨程序的運行而改變.窗口對象(Twindow類)和對話框對象(Toialog類)隨應用的不同而不同,典型的窗口和對話框對象的組裝結構如圖所示.窗口和對話框對象的組裝結構事件驅動風格實例TurboVision

TurboVision把事件抽象為3種類型的事件:位置事件、聚焦事件和廣播事件。典型的位置事件是鼠標器事件,TGroup類視圖把位置事件交給管理該區域的子視圖;典型的聚焦事件是擊鍵和命令事件(典型的命令事件是由狀態行或菜單條、下拉菜單將擊鍵事件或鼠標器事件轉換而得),TGroup類視圖把該事件交給處于聚焦狀態的下級視圖;廣播事件是管理視圖不知道該交給誰的那種事件,對于這種事件,它將該事件交給所有的視圖。TurboVision程序在運行時,由TApplication對象收集鼠標器事件和健盤事件以及各種其它事件,然后按一定的規則交給下屬去處理.例如,對于鼠標器事件,如果它發生在菜單條上,則將它交給菜單條來處理;如果它發生在狀態行,則將它交給狀態行來處理;如果它發生在DeskTop上,則將它交給DeskTop來處理。總之,細節問題總是交給下屬來處理.狀態行和菜單條的任務是將鍵盤事件和自己轄區的鼠標器事件轉換成為命令事件,再上交給TApplication。分層風格特征一個分層系統采用層次化的組織方式構建,系統中的每一層都要承擔兩個角色。首先,它要為結構中的上層提供服務;其次,它要作為結構中下面層次的客戶,調用下層提供的功能函數。分層風格特征一個概念上的分層模型如下圖所示:分層風格優點分層風格具有一些系統設計者無法抗拒的優勢:分層風格支持系統設計過程中的逐級抽象基于分層風格的系統具有較好的可擴展性分層風格支持軟件復用分層風格不足并不是所有的系統都適合用分層風格來描述的對于抽象出來的功能具體應該放在哪個層次上也是設計者頭疼的一個問題分層風格實例分層風格實例:計算機網絡的設計概述網絡協議設計者將計算機網絡中的各個部分按其功能劃分為若干個層次(Layer),其中的每一個層次都可以看成是一個相對獨立的黑箱、一個封閉的系統。用戶只關心每一層的外部特性,只需要定義每一層的輸入、數據處理和輸出等外部特性。分層風格實例ISO/OSI網絡體系結構ISO/OSI采用了7層體系結構,從高到低分別是:應用層、表示層、會話層、傳輸層、網絡層、數據鏈路層和物理層,如圖所示。其最高層為第7層應用層,用于同應用服務之間交換數據;最低層為第1層物理層,用于連接物理傳輸介質實現真正的數據通信。層與層之間的聯系是通過各層之間的接口來實現的,上層通過接口向下層提出服務請求,而下層通過接口向上層提供服務。兩臺計算機通過網絡進行通信時,只有兩物理層之間能夠通過媒體進行真正的數據通信,其余各對等層之間均不存在直接的通信關系,各對等層之間只能通過各對等層的協議來進行虛擬通信。ISO/OSI網絡體系結構分層風格實例ISO/OSI網絡體系結構分層風格實例ISO/OSI網絡體系結構為了理解ISO/OSI各層的功能,以運輸公司進行貨物運輸為例來進行說明,也就是利用人們熟知的東西來理解陌生抽象的概念。其中,第1~3層3個層次相當于由運輸公司負責的貨物運輸過程中的具體細節、具體操作方式;第4層相當于運輸公司與用戶之間的接口;第5~7層3個層次相當于由用戶公司負責的將貨物交去運輸所需要做的準備工作。第1層是物理層(PhysicalLayer),它負責在物理信道上傳輸原始的數據bit流。它應該提供為建立、維護和拆除物理鏈路連接所需的機械的、電氣的、功能和規程的特性,這類似于運輸車輛只需要負責將裝在車輛內的貨物(類似于bits)運送到某地就行了。分層風格實例第2層是數據鏈路層(DataLinkLayer),它的主要功能是糾錯和流量控制,負責在可能出現差錯的物理線路中實現無差錯的數據傳送。它應該在物理層的基礎上,建立相鄰結點之間的數據鏈路,通過差錯控制提供數據幀(Frame)的無差錯傳輸,并進行數據流量控制。這類似于運輸公司的運輸管理和質量監督部門,需要負責在可能出現問題的運輸線路之中保質保量地完成運輸任務。分層風格實例

第3層是網絡層(NetworkLayer),它的主要功能是路由控制(找路)、擁塞控制和數據打包。它應該為其上一層傳輸層的數據傳輸提供建立、維護和終止網絡連接的手段,把上層傳來的數據分割成一個一個的數據包(Packet,也叫報文分組)在結點之間進行交換傳送,并且負責路由控制和擁塞控制。這類似于運輸公司需要將用戶發送的貨物進行分割打包,并在現有的交通網絡之中負責找出一條從源地址到目的地址的線路(即找路),在找路時需要考慮到能否到達、擁塞狀況、安全可靠性、甚至交通費用等諸多方面的因素。分層風格實例第4層是傳輸層(TransportLayer),它的主要功能是在上層和下層之間起到一種接口的功能。它應該為上層提供端到端(最終用戶到最終用戶)、的透明的、可靠的數據傳輸服務。所謂透明的傳輸是指在通信過程中上層可以將下面各層看作是一個封閉的黑箱系統,傳輸層對上層屏蔽了傳輸系統的具體細節。這類似于運輸公司在各個地方設置的業務接洽處,它負責在用戶和公司之間建立起一個貨物交接的橋梁,使得用戶不用去管運輸公司將以什么樣的方式將貨物運送到目的地,也就是說業務接洽處對用戶屏蔽了貨物運輸中的具體細節。分層風格實例第5層是會話層(SessionLayer),它的主要功能是負責收發數據的交接工作、并組織和管理數據。它應該為表示層提供建立、維護和結束會話連接的功能,并提供會話管理服務。這類似于用戶公司的貨物收發室,它負責與運輸公司打交道,完成用戶公司貨物的收發的交接工作、并組織管理公司內部要收發的貨物。分層風格實例第6層是表示層(PresentationLayer),它的主要功能是為數據提供收發、存放的具體格式和規范。它應該為應用層提供信息表示方式的服務,如數據格式的變換、文本壓縮、加密技術等。這類似于用戶公司的貨物收發員,它負責與用戶公司內部要收發貨物的部門或個人打交道,在收集要發送的貨物時告訴用戶應該怎樣填寫發貨資料,在向用戶發放貨物時告訴用戶應該完清哪些具體手續,等等。分層風格實例第7層是應用層(ApplicationLayer),它的主要功能是為數據提供各種可行的收發方式。它應該為網絡用戶或應用程序提供各種應用服務,如文件傳輸、電子郵件(E-mail)、分布式數據庫、網絡管理等。這類似于用戶公司內部的部門或個人在收發貨物時,都必須遵循用戶公司內部的有關規定,只能使用用戶公司所允許的方式來收發貨物。從另一方面來說,用戶公司也要為公司內部的部門或個人收發貨物提供各種可行的收發方式,讓用戶公司內部的部門或個人知道他們能夠使用哪些方式來收發貨物。分層風格ISO/OSI層次分組關系:有兩種分組方法I第一種可以從數據處理分工的角度,將ISO/OSI七個層次分為三組:第1、2層解決有關網絡信道問題;第3、4層解決傳輸服務問題;第5、6、7層則處理對應用進程的訪問。從數據傳輸控制的角度,將ISO/OSI七個層次分為三組:下三層(1、2、3層)可以看作是傳輸控制組,負責通信子網的工作,解決網絡中的通信問題;上三層(5、6、7層)為應用控制組,負責有關資源子網的工作,解決應用進程之間的信息轉換問題;中間層(4層)則為通信子網和資源子網的接口,起到連接傳輸和應用的作用。分層風格實例

.Net平臺也是一個明顯的分層系統:數據共享風格特征采用數據共享風格構建的系統中通常有兩個截然不同的功能構件;中央數據單元構件;一些相對獨立的構件的集合。信息交互方式的差異導致了控制策略的不同。主要的控制策略有兩種,正是依據這兩種不同的控制策略,基于數據共享風格的系統被分成兩個子類:基于傳統數據庫型數據共享風格的應用系統基于黑板型數據共享風格的應用系統數據共享風格特征黑板型數據共享風格的示意圖如下圖所示:數據共享風格一個典型的黑板型數據庫系統包括以下三個部分:知識源:知識源中包含獨立的、與應用程序相關的知識,知識源之間不直接進行通訊,它們之間的交互只通過黑板來完成。黑板數據結構:黑板數據是按照與應用程序相關的層次來組織的解決問題的數據,知識源通過不斷地改變黑板數據來解決問題。控制:控制完全由黑板的狀態驅動,黑板狀態的改變決定使用的特定知識。黑板模式對于無確定性求解策略的問題比較有用,在專家系統中,這種模式應用的比較廣泛。

數據共享風格優點解決問題的多方法性:對于一個專家系統,針對于要解決的問題,如果在其領域中沒有獨立的方法存在,而且對解空間的完全搜索也是不可行的,在黑板模式中可以用多種不同的算法來進行試驗,并且也允許用不同的控制方法。具有可更改性和可維護性:因為在黑板模式中每個知識源是獨立的,彼此之間的通信通過黑板來完成,所以這使整個系統更具有可更改性和可維護性。數據共享風格優點有可重用的知識源:由于每個知識源在黑板系統中都是獨立的,如果知識源和所基于的黑板系統有理解相同的協議和數據,我們就可以重用知識源。支持容錯性和健壯性:在黑板模式中所有的結果都是假設的,并且只有那些被數據和其它假設強烈支持的才能夠生存。這對于噪聲數據和不確定的結論有很強的容錯性。數據共享風格缺點測試困難:由于黑板模式的系統有中央數據構件來描述系統的體現系統的狀態,所以系統的執行沒有確定的順序,其結果的可再現性比較差,難于測試。不能保證有好的求解方案:一個黑板模式的系統所提供給我們的往往是所解決問題的一個百分比,而不是最佳的解決方案。效率低:黑板模式的系統在拒絕錯誤假設的時候要承受多余的計算開銷,所以導致效率比較低。數據共享風格缺點開發成本高:絕大部分黑板模式的系統需要用幾年的時間來進化,所以開發成本較高。缺少對并行機的支持:黑板模式要求黑板上的中心數據同步并發訪問,所以缺少對不并行機的支持。數據共享風格實例數據共享風格實例:專家系統(ES,ExpertSystem)概述:專家系統實質就是一組程序;從功能上:可定義為“一個在某領域具有專家水平解題能力的程序系統”,能像領域專家一樣工作,運用專家積累的工作經驗與專門知識,在很短時間內對問題得出高水平的解答。從結構上講:可定義為“由一個專門領域的知識庫,以及一個能獲取和運用知識的機構構成的解題程序系統”。數據共享風格實例ES一般結構如下圖所示:實例知識庫系統實例IECRMAS知識生態系統

IECRMAS知識生態系統的構建知識生態系統

IECRMAS環境有機體知識生產者

評估者知識知識消費者

評估知識分解者

AgentAgentCKOKDD評估者評估者IECRMAS知識生態系統知識流IECRMAS知識生態系統

知識系統環境

知識生產者

知識消費者

知識分解者

信用評估知識庫的形成IECRMAS知識生態系統知識庫系統實例客戶數據倉交易數據倉違約數據倉經驗教訓數據倉DRM/DWE…信息庫數據庫知識庫知識Agent信用評估知識基IECRMAPS知識生態系統中知識流動評估

Agent

評估

Agent

評估

Agent

知識

Agent

管理

Agent

檢索

評估系統知識基

更新

傳遞

傳遞

傳遞

學習

學習

學習

客戶

Agent

更新

更新

檢索

數據庫信息庫知識庫外部知識協作交流IECRMAS知識生態系統個體知識進化圖評估Agent

學習

外部知識輸入

知識輸出

個體知識含量

KAS

UPS

CES

知識Agent

知識貢獻IECRMAS知識生態系統解釋器風格特征基于解釋器風格的系統核心在于虛擬機。一個基于解釋器風格的系統通常包括:正在被解釋執行的偽碼和解釋引擎;偽碼:由需要被解釋執行的源代碼和解釋引擎分析所得的中間代碼組成;解釋引擎包括:語法解釋器和解釋器當前的運行狀態解釋器風格特征解釋器風格示意圖如下圖所示:解釋器風格優點在文法規則比較簡單的情況下,解釋器風格工作的很好;易于改變和擴展文法。因為解釋器風格使用類來表示文法規則,用戶可以使用繼承來改變和擴展文法。已有的表達式可以采用增量的方式逐漸擴充,而新的表達式可以定義為舊表達式的變體;易于實現文法。可以用多種操作來“解釋”一個句子。解釋器風格缺點無法解釋復雜的文法規則:對于比較簡單的文法規則,解釋器風格工作的很好,而對于復雜的文法規則,則由于文法層次的龐大而難于管理;應用范圍比較狹窄;在文法規則比較復雜,則文法的層次變得無法管理,系統中需要包含許多表示文法規則的類。解釋器風格實例解釋器風格實例:一個布爾表達式解釋器目標:布爾表達式求值系統現定義由如下文法定義的布爾正則表達式編譯器(1)系統的體系結構可以隨技術的發展而發生變化傳統的編譯器模型具有共享符號表的傳統編譯器模型編譯器(2)隨著時間的推移,編譯技術變得更加復雜,更多的注意力轉移到程序在編譯過程的中間表示,例如屬性文法樹典型的現代編譯器模型解釋器風格實例布爾表達式求值系統類圖,如下圖所示:解釋器風格示例布爾表達式抽象語法樹實例,如下圖所示:解釋器風格實例布爾表達式求值系統的優缺點:在文法規則比較簡單的情況下,解釋器風格工作的很好,但如果文法規則復雜,則文法的層次變得龐大而無法管理,系統中需要包含許多表示文法規則的類。最高效的解釋器通常不是通過直接解釋語法分析數實現的,而是首先將它們轉換成另一種形式。易于改變和擴展文法。易于實現文法。解釋器風格實例布爾表達式求值系統中的角色:BooleanExpression(抽象布爾表達式)TerminalExpression(終結符表達式,如VariableExpresssion和Constant)NonterminalExpression(非終結符表達式,如AndExpression、OrExpression和NotExpression)Context(上下文,也就是“解釋引擎內部狀態”)Client(客戶)解釋器風格實例布爾表達式求值系統的實現在具體實現布爾表達式求值系統時還有許多細節的問題要處理,這些細節問題處理的好壞甚至會直接影響整個系統的性能。這些問題主要表現在以下幾個方面:創建抽象語法樹定義求值操作共享終結符解釋器風格示例解釋器風格定義了特定語言的文法表示和解釋該文法的解釋器。這種模式如同樂譜。其中,音階和它的持續時間可以用五線譜上的符號表示。這些符號就是音樂語言。音樂家按照樂譜演奏,就可以反復重現同樣的音樂。解釋器實例使用音樂例子的解釋器風格對象圖解釋器實例羅馬數字轉換系統解釋器實例AbstractExpression

(Expression)聲明執行特定操作的接口。TerminalExpression

(ThousandExpression,HundredExpression,TenExpression,OneExpression)實現一個與語法中終結符相關的解釋操作。句子中的每一個終結符都需要一個實例。NonterminalExpression

語法中的每個規則R::=R1R2...Rn都需要這樣的一個類。管理從R1到Rn每一個符號的AbstractExpression類型變量的實例。實現語法中非終結符的解釋操作,在解釋中可能需要遞歸調用自身。Context

(Context)包含對于解釋器來說是全局的信息。Client

(InterpreterApp)建立(或者給定)一個抽象語法樹。抽象語法樹是由NonterminalExpression和TerminalExpression類的實例組合而成。調用解釋操作。程序源碼反饋控制環風格概述所謂對一個對象(或過程)進行控制,意味著設法使這個被控對象(或被控過程)的功能或特性有效的達到所期望的目標。為了成功設計一個控制系統,必須事先知道被控對象所具有的性質和特征,同時還須了解和掌握這些性質和特征隨環境等因素變化的情況。反饋控制環風格控制工程是一個十分強調方法論的專業領域,因此控制工程方法完全是獨立于各種應用領域的。為了將過程控制方法從單純的控制領域中抽象出來,我們引入了動態系統的概念。反饋控制環風格動態系統表示信號處理和傳輸的一個功能單元(例如:信號可以是能量、材料、信息、資金及其他形式),其中系統的起因和由此引起的時間上的效果分別作為系統的輸入量和輸出量來考慮。如此定義的系統具有共同的特征,即在其中一定存在有目標的作用、信息處理、閉環和開環控制過程,正如N.Wiener所提出的,以上概念可以用控制論這個更高級的概念來總結。控制論也可以應用于軟件體系結構的創建。反饋控制環風格描述手段根據上述的動態系統的定義,在系統中必然存在信號的處理和傳輸。這時系統也可描述為傳輸環節或傳輸系統。傳輸環節具有唯一的作用方向,這由輸入、輸出信號的箭頭方向給出。單變量系統如下圖所示:

反饋控制環風格描述手段多變量系統如下圖所示:反饋控制環風格描述手段除了用方框圖來表達動態系統以外,還可以用信號流圖,如下圖所示:反饋控制環風格開環與閉環控制一般的動態系統描述框圖可以分為開環控制和閉環控制系統,但在實際應用中這兩種不同的動態系統往往很容易混淆在一起,對它們之間的區別強調的不夠。現在通過一個市內暖氣系統來指出這兩者之間的不同和相同之處。反饋控制環風格開環與閉環控制開環控制圖如下圖所示:反饋控制環風格開環與閉環控制閉環控制圖如下圖所示:反饋控制環風格開環與閉環控制開環控制和閉環控制的差別:閉環控制:表示一個閉合的作用過程,(控制回環);根據閉環作用原理可增加抗干擾性(負反饋);可能不穩定,也即被控量不再衰減,而是增長到無窮大(理論上)。反饋控制環風格開環與閉環控制開環控制和閉環控制的差別(續):開環控制表示一個開放的作用過程(控制序列);只能對抗指定由其處理的干擾,對于其他一些干擾因素無法消除;只要被控制對象自己保持穩定,整個開環控制系統也就保持穩定。反饋控制環風格基本結構以閉環控制系統為例分析過程控制環的基本結構;一個自動控制系統包括如下4個主要組成部分:被控對象、測量環節、調節器和執行環節,如下圖所示:反饋控制環風格-自適應自適應反饋控制環需要包括以下3方面的工作:辨識被控對象的特征;在辨識的基礎上作出控制決策;在決策的基礎上實施修正動作.按照構成自適應控制環的目的的不同可將其分為兩種類型:參數自適應控制環;性能自適應控制環;反饋控制環風格-自適應反饋控制環參數自適應控制環參數自適應控制環如下圖所示:反饋控制環風格-自適應反饋控制環性能自適應控制環性能自適應控制環如下圖所示:反饋控制環風格-自適應反饋控制環在性能自適應控制環中,最典型的代表就是所謂模型參考自適應控制系統。模型參考自適應控制系統按照其控制方式又可分為兩種A.直接法B.間接法反饋控制環風格-自適應反饋控制環直接法模型如下圖所示:間接法模型如下圖所示:反饋控制環風格實例鋼鐵燒結工藝控制體系結構

控制系統組成如下圖所示。燒結機過程控制系統采用兩套Quantum控制器,共配置600路模擬量輸入輸出點,分別實現對配混料工序、燒結工序的全生產過程控制。配混系統下設3個遠程站,燒結系統下設5個遠程站。整個系統主要由以太網、MB+網和遠程I/O網構成。遠程I/O網是一個高速(1.544Mb/s)局域網絡,傳輸介質采用同軸電纜,在本系統中采用介質冗余的方式,當一個通道有通信故障時,系統自動轉到另一通道,確保了PLC與遠程I/O之間數據采集與控制的正常運行。系統簡介:反饋控制環風格實例鋼鐵燒結工藝控制體系結構打印機服務器工作站1工作站N交換機以太網Quantum系列Quantum系列遠程I/O遠程I/OMB+網控制系統組成反饋控制環風格實例鋼鐵燒結工藝控制體系結構 下面,我們主要介紹混合料水控制和點火溫度控制。系統主要功能:自動配料控制混合料水分控制點火溫度控制混合料總量控制生產中固體燃料的消耗控制自動布料控制等功能。反饋控制環風格實例鋼鐵燒結工藝控制體系結構

混合料水分的自動控制:

通過實時跟蹤混合料中各種原料的重量,計算其干重和濕重。根據物料平衡原理調整混合料中的水含量。在上位機輸入各種原料的含水量及一混、二混、三混內的目標水分,系統即可根據流量自動調節混合料的含水量。一混、二混、三混內自動給水系統構成相同,由電磁流量計、電動調節閥、快中子水分計等檢測設備組成,與PLC一起實現混合料加水系統的前饋控制與反饋控制及串級控制相結合的控制方法。實現加水流量的閉環控制,控制混合料的含水量。控制原理如下圖所示。反饋控制環風格實例鋼鐵燒結工藝控制體系結構實際水分-測量變送器混合料水分控制原理主PID調節器副PID調節器電動調節閥流量對象水分對象測水儀信號模型運算目標水分實測水分-反饋控制環風格實例鋼鐵燒結工藝控制體系結構

點火溫度自動控制:

點火器溫度的穩定是保證燒結礦產品質量的重要因素,利用PLC對點火溫度進行實時控制,對提高生產率和燒結礦質量、節約能源有著積極的意。把熱電偶檢測到4~20mA標準信號送入模擬量輸入模塊,在CPU內部,將此次采樣值作為過程值與設定值進行比較計算,通過模擬量輸出模塊輸出4~20mA信號,控制執行機構動作,改變煤氣流量,達到控制溫度的目的。同時,為保證燃燒的經濟性,煤氣量與空氣量必須按一定比例混合,本系統采用比值控制系統,通過控制煤氣、空氣的流量,使點火溫度保持在一定范圍內。控制原理如下圖所示。反饋控制環風格實例鋼鐵燒結工藝控制體系結構測量值-信號流量點火溫度控制原理溫度調節煤氣流量調節器電動調節閥溫度對象電動調節閥空氣流量測量變送器溫度設定Q(煤氣流量)-溫度測量變送器煤氣流量測量變送器比值器空氣流量調節器-T(點火溫度)(空氣流量)Q2七種構建模式的比較軟件體系結構的七種構建模式各有自己的特點、局限、應用范圍和優缺點,比較各種構建模式的不同將有助于在實際的項目開發過程中選擇適合項目的構建模式。七種構建模式的比較見下表所示:

七種構建模式的比較構建模式主要特點主要優點主要缺點適合領域說明管道-過濾器風格過濾器相對獨立功能模塊復用;強可維護性和可擴展性;具有并發性;模塊獨立性高不適于交互性強的應用;對于存在關系的數據流必須進行協調系統可劃分清晰的模塊;模塊相對獨立;有清晰的模塊接口每個功能模塊有一組輸入輸出,模塊劃分限制較大。面向對象風格力取實現問題空間和軟件系統空間結構的一致性高度模塊性;實現封裝;代碼共享;靈活;易維護;可擴充性好增加了對象之間的依賴關系多種領域是現在使用非常多的一種構建模式事件驅動風格系統由若干子系統構成且成為一個整體;系統有統一的目標;子系統有主從之分;每一子系統有自己的事件收集和處理機制適合描寫系統組;容易實現并發處理和多任務;可擴展性好;具有類層次結構;簡化代碼;因為樹型結構所以削弱了對系統計算的控制能力;各個對象的邏輯關系復雜一個系統對外部的表現可以從它對事件的處理表征出來事件驅動系統具有某種意義上的帝歸性,形成了“部分-整體”的層次結構七種構建模式的比較構建模式主要特點主要優點主要缺點適合領域說明分層風格各個層次的組件形成不同功能級別的虛擬機;多層相互協同工作,而且實現透明支持系統設計過程中的逐級抽象;可擴展性好;支持軟件復用不同層次之間耦合度高的系統很難實現適合功能層次的抽象和相互之間低耦合的系統數據共享風格采用兩個常用構件中央數據單元和一些相對獨立的組件集合中央數據單元實現了數據的集中,以數據為中心適合于特定領域適合于專家系統等人工智能領域問題的求解數據和處理功能分界明顯,解釋器風格系統核心是虛擬機可以用多種操作來解釋一個句子適合于特定領域適合于模式匹配系統和語言編譯器反饋控制環風格通過不斷地測量被控對象,認識和掌控被控對

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論