軟件體系結構風格與模式

課程編號：74100152

第二講軟件體系結構的風格和模式

覃征教授

THUSAGroup

建筑模式

?：?ChristopherAlexander,TheTimelessWayof

Building,p247,1979

■每個模式是一個由三部分組成的規(guī)則，表達了特定環(huán)境、問題

和解(solution)之間的關系。

-作為現(xiàn)實世界的一個成分，每個模式表達了下列三者之間的一

種關系：特定環(huán)境，在該環(huán)境中反復出現(xiàn)的力(forces)的系統(tǒng),

以及協(xié)調(diào)這些力的某種空間排列。

-作為語言的一個成分，每個模式是一條指令，展示了這種空間

排列如何被一再重復使用，目的是協(xié)調(diào)同特定環(huán)境相關的力的

系統(tǒng)。

-簡單地說，模式既是存在于現(xiàn)實世界中的事物，又是告訴我們

如何以及何時創(chuàng)造該事物的規(guī)則。模式既是過程，又是事物；

既是活生生的事物的描述，又是創(chuàng)造該事物的過程的描述。

軟件體系結構的構建模式

軟件體系結構的特點之一就是抽象出了很

多常見的系統(tǒng)構建模式，這些模式（或者說結

構風格）是系統(tǒng)設計人員多年工作經(jīng)驗的總結

軟件體系結構風格和模式的概念

?軟件體系結構風格(ArchitecturalStyle)

-一種體系結構風格以結構組織模式定義了一個系統(tǒng)家族

?關于構件和連接件類型的術語；一組約束對它們組合方式的規(guī)

定；一個或多個語義模型，規(guī)定了如何從各成分的特性決定系

統(tǒng)整體特性

■概括地說，一種軟件體系結構風格刻劃一個具有共享結構和語

義的系統(tǒng)家族

?軟件體系結構模式(ArchitecturalPattern)

-一種軟件體系結構模式是對某個具體環(huán)境下問題的結構性解決

方法

??體系結構風格3模式系統(tǒng)中的詞匯

-目前尚不完善

■每個風格可以視為一組構件的集合，以及構件間的交互(連接

布)

■構件(Components)+連接器(Connectors)

■E.g.C/S結構中

,構件：Client,Server

?連接器：C/S間的通訊協(xié)議

軟件體系結構的構建風格

務風格分類:

1.管道-過濾器風格

2.面向?qū)ο箫L格

3.事件驅(qū)動風格

4.分層風格

5.數(shù)據(jù)共享風格

6.解釋器風格

7.反饋控制環(huán)風格

8.異構風格的集成

不特別注意：體系結構風格不是對軟件進行分類的標準。

它僅僅是表示描述軟件的不同角度而已

■例如一個系統(tǒng)采用了分層風格，但這并不妨礙它用面向?qū)ο蟮?/p>

方法來實現(xiàn)。同一個系統(tǒng)采用多種風格造成了所謂體系結構風

格的異構組合。

管道■過濾器風格

q?概述

■在管道?過濾器風格下，每個功能模塊都有一組輸入和輸出。功

能模塊稱作過濾器（filters）；功能模塊間的連接可以看作輸

入、輸出數(shù)據(jù)流之間的通路，所以稱作管道（pipes）。

■管道?過濾器風格的特性之一在于過濾器的相對獨立性，即過濾

器獨立完成自身功能，相互之間無需進行狀態(tài)交互。

管道■過濾器風格特性

務過濾器是獨立運行的構件

-非臨近的過濾器之間不共享狀態(tài)

-過濾器自身無狀態(tài)

*過濾器對其處理上下連接的過濾器“無知”

-對相鄰的過濾器不施加任何限制

結果的正確性不依賴于各個過濾器運行的先后次序

?各過濾器在輸入具備后完成自己的計算。完整的計算過程包含

在過濾器之間的拓撲結構中。

士，,

管道■過濾器風格

一個管道-過濾器風格的示意圖如下圖所示:

管道■過濾器風格

個采用了嵌套的管道過濾器的系統(tǒng)示例:

管道■過濾器風格優(yōu)點

W?設計者可以將整個系統(tǒng)的輸入、輸出特性簡單的理解為

各個過濾器功能的合成。

■設計人員將整個系統(tǒng)的輸入輸出行為理解為單個過濾器行為的

疊加與組合。這樣可以將問題分解，化繁為簡。將系統(tǒng)抽象成

一個“黑箱”，其輸入是系統(tǒng)中第一個過濾器的輸入管道，輸

出是系統(tǒng)中最后一個過濾器的輸出管道，而其內(nèi)部各功能模塊

的具體實現(xiàn)對用戶完全透明。

管道■過濾器風格優(yōu)點

*管道■過濾器風格支持功能模塊的復用

■任何兩個過濾器，只要它們之間傳送的數(shù)據(jù)遵守共同的規(guī)約，

就可以相連接。每個過濾器都有自己獨立的輸入輸出接口，如

果過濾器間傳輸?shù)臄?shù)據(jù)遵守其規(guī)約，只要用管道將它們連接就

可以正常工作。

管道■過濾器風格優(yōu)點

。基于管道■過濾器風格的系統(tǒng)具有較強的可維護性和可擴

展性。

■舊的過濾器可以被替代，新的過濾器可以添加到已有的系統(tǒng)上

O軟件的易于維護和升級是衡量軟件系統(tǒng)質(zhì)量的重要指標之一

,在管道?過濾器模型中，只要遵守輸入輸出數(shù)據(jù)規(guī)約，任何一

個過濾器都可以被另一個新的過濾器代替，同時為增強程序功

能，可以添加新的過濾器。這樣，系統(tǒng)的可維護性和可升級性

得到了保證。

管道■過濾器風格優(yōu)點

*支持一些特定的分析，如吞吐量計算和死鎖檢測等。

-利用管道?過濾器風格的視圖，可以很容易的得到系統(tǒng)的資源使

用和請求的狀態(tài)圖。然后，根據(jù)操作系統(tǒng)原理等相關理論中的

死鎖檢測方法就可以分析出系統(tǒng)目前所處的狀態(tài)，是否存在死

鎖可能及如何消除死鎖等問題。

管道■過濾器風格優(yōu)點

不管道■過濾器風格具有并發(fā)性

-每個過濾器作為一個單獨的執(zhí)行任務，可以與其它過濾器并發(fā)

執(zhí)行。過濾器的執(zhí)行是獨立的，不依賴于其它過濾器的。在實

際運行時，可以將存在并發(fā)可能的多個過濾器看作多個并發(fā)的

任務并行執(zhí)行，從而大大提高系統(tǒng)的整體效率，加快處理速度

O

管道■過濾器風格不足

。交互式處理能力弱

■管道?過濾器模型適于數(shù)據(jù)流的處理和變換，不適合為與用戶交

互頻繁的系統(tǒng)建模。在這種模型中，每個過濾器都有自己的數(shù)

據(jù)，這些數(shù)據(jù)或者是從磁盤存儲器中讀取來，或者是由另一個

過濾器的輸出導入進來，整個系統(tǒng)沒有一個共享的數(shù)據(jù)區(qū)。這

樣，當用戶要操作某一項數(shù)據(jù)時，要涉及到多個過濾器對相應

數(shù)據(jù)的操作，其實現(xiàn)較為復雜。由以上的缺點，可以對每個過

濾器增加相應的用戶控制接口，使得外部可以對過濾器的執(zhí)行

進行控制。

管道■過濾器風格不足

數(shù)據(jù)輸入數(shù)據(jù)輸入

改進的過濾器

管道■過濾器風格不足

多管道■過濾器風格往往導致系統(tǒng)處理過程的成批操作。

?:?設計者也許不得不花費精力協(xié)調(diào)兩個相對獨立但又存在

某種關系的數(shù)據(jù)流之間的關系，例如多過濾器并發(fā)執(zhí)行

時數(shù)據(jù)流之間的同步問題等。

?根據(jù)實際設計的需要，設計者也需要對數(shù)據(jù)傳輸進行特

定的處理（如為了防止數(shù)據(jù)泄漏而采取加密等手段），

導致過濾器必須對輸入、輸出管道中的數(shù)據(jù)流進行解析

或反解析，增加了過濾器具體實現(xiàn)的復雜性。

道■過濾器風格實例—數(shù)字通信系統(tǒng)

務通信的目的是傳遞消息。消息具有不同的形式，例如：

符號、文字、語音、音樂、數(shù)據(jù)、圖片、圖像等等。因

而，根據(jù)所傳遞消息的不同，目前通信業(yè)務可以分為電

報、電話、傳真、數(shù)據(jù)傳輸及可視電話等。對于基本的

點對點通信，是把發(fā)送端的消息傳遞到接收端。

發(fā)送端---------->接收端

數(shù)字通信概念模型

道■過濾器風格實例—數(shù)字通信系統(tǒng)

務將上圖發(fā)送端進一步細分為信息源和發(fā)送設備，將接收

端細分為接收設備和受信者；同時，在通信過程中會有

噪聲干擾，在模型中添加噪聲源可得到圖所示的數(shù)字通

信系統(tǒng)粗略模型。

噪聲源

信息源一發(fā)送設備—一接收設備—受信者

信道

數(shù)字通信系統(tǒng)粗略模型

道■過濾器風格實例—數(shù)字通信系統(tǒng)

*圖中各單元作用：

-信息源把各種可能信息轉換成原始電信號；

■發(fā)送設備對原始電信號完成某種變化，便于原始信號在信道中

傳輸，然后再送入信道；

■信道是指信號傳輸?shù)耐ǖ溃瓤梢钥闯墒枪艿溃ㄒ驗樗哪?/p>

的并不是為了實現(xiàn)某種功能，僅僅是為了信號的傳輸），也可

以從某種意義上看做是過濾器（因為信號經(jīng)過信道后會產(chǎn)生

一些變化，比如加入噪聲的影響，從而改變了發(fā)送設備發(fā)出的

信號）。

-接收設備從接收信號中恢復出相應的原始信號；

-受信者（也稱為信息宿或接收終端）是將復原的原始信號轉換

成相應的消息。

-噪聲源是信道中的噪聲以及分散在通信系統(tǒng)其它各處的噪聲的

集中體現(xiàn)，它使原信號受到了干擾，產(chǎn)生畸變。

道■過濾器風格實例—數(shù)字通信系統(tǒng)

*在數(shù)字通信中存在以下幾個突出的問題：

■數(shù)字信號傳輸時，信道噪聲或干擾所造成的差錯，原則上都可

以通過差錯控制編碼等手段來控制。為此，在發(fā)送端需要增加

一個編碼器，而在接收端相應的需要一個解碼器。

■當需要保密時，可以有效的對基帶信號進行加密，防止信息被

竊取或通信被破壞。此時，在接收端就需要進行解密。

-由于數(shù)字通信傳輸?shù)氖且粋€接一個按節(jié)拍傳送的數(shù)字信號單元

,即碼元，因而接收端必須與發(fā)送端按相同的節(jié)拍進行接收。

不然，會因接收節(jié)拍不一致而造成混舌L,使接收倒的數(shù)據(jù)全部

無效。因此，數(shù)字通信系統(tǒng)中必須有同步控制構件。

?:?針對上述問題，可得到數(shù)字通信系統(tǒng)詳細模型（下圖）

道■過濾器風格實例—數(shù)字通信系統(tǒng)

數(shù)字通信系統(tǒng)詳細模型

管道■過濾器風格實例

?:?管道■過濾器模式的體系結構是面向數(shù)據(jù)流的軟件體系結

構。它最典型的應用是在編譯系統(tǒng)。一個普通的編譯系

統(tǒng)包括詞法分析器，語法分析器，語義分析與中間代碼

生成器，優(yōu)化器，目標代碼生成器等一系列對源程序進

行處理的過程。人們可以將編譯系統(tǒng)看作一系列過濾器

的連接體，按照管道&過濾器的體系結構進行設計。

需求描述：假設有一批實時的二維坐標點數(shù)據(jù)需要變換

（即對點的橫、縱坐標進行縮放），并在屏幕上進行顯

示，要求外部要能設置變換規(guī)則（如縮放倍數(shù)）和顯示

規(guī)則（如顯示模式和顯示顏色）。

管道■過濾器風格實例

?:?體系結構建模

■這是一個對坐標點的數(shù)據(jù)流進行順序處理的過程，可以應用管

道?過濾器體系結構建模。將這個系統(tǒng)分為兩個過濾器，一個為

坐標點數(shù)據(jù)流變換過濾器，另一個為坐標點數(shù)據(jù)流實時顯示過

濾器。其中，坐標點數(shù)據(jù)流變換過濾器有一個外部控制接口對

變換規(guī)則如縮放倍數(shù)進行設置，坐標點數(shù)據(jù)流實時顯示過濾器

有一個外部控制接口對顯示規(guī)則如顯示模式和顯示顏色進行設

置。整個系統(tǒng)的體系結構如圖所示。

管道■過濾器風格實例

系統(tǒng)體系結構圖

管道■過濾器風格實例

爭過濾器的設計

-可以將過濾器用狀態(tài)轉換圖表示。過濾器有如下狀態(tài)：停止狀

態(tài)，工作狀態(tài)，等待狀態(tài)，休眠狀態(tài)。

-停止狀態(tài)：表示過濾器處于待啟動狀態(tài)，當外部啟動過濾器后

,過濾器處于處理狀態(tài)；

-處理狀態(tài)：表示過濾器正在處理輸入數(shù)據(jù)隊列中的數(shù)據(jù)；

■等待狀態(tài)：表示過濾器的輸入數(shù)據(jù)隊列為空，此時過濾器等待

,當有新的數(shù)據(jù)輸入時，過濾器處于處理狀態(tài)；

-休眠狀態(tài)：表示過濾器已經(jīng)啟動，但被掛起。掛起的原因可能

是由于外界用戶要設置過濾器的控制參數(shù)，這樣暫時將過濾器

掛起但不中止它，當控制參數(shù)設置完畢后再將過濾器還原，繼

續(xù)運行。這樣，實現(xiàn)了較高的效率。

管道■過濾器風格實例

過濾器狀態(tài)轉換圖

使用示例

?Unix系統(tǒng)中的管道過濾器結構

Is-al|grepmy

通訊協(xié)議的信息封裝(egSDH)

1^139246kbs

TelecomBus<

34368kb/s

VC-3*C-3#

一2048kb.s

VC-12.C-12.

過濾器介紹

?過濾器的作用：對輸入數(shù)據(jù)的處理

■enriches:computingandaddinginfo

■refines:concentratingorextractinginfo

■transforms:deliveringdataintosomeotherrepresentation

被動式過濾器(Passivefilter)

■adjacentpipespulls/pushesoutput/inputdatafrom/intothe

filter

■activeeitherasafunction(pull)orasaprocedure(push)

?主動式過濾器(Activefilter)

■filterisactiveinaloop,checkthepipesfordata

■processingonitsownasaseparateprogramorthread

數(shù)據(jù)源、數(shù)據(jù)接收端、管道介紹

vDataSource（數(shù)據(jù)源）

■inputdatastreamtothesystem,forexample

?Afileconsistingoflinesoftext

?Asensordeliveringasequenceofnumbers

■datacanbepushedorpulledintofirstprocessingstage

?Pipes（管道）

■connectionsbetweenfilters,betweendatasourceandthe

firstfilter,betweenthelastfilterandthedatasink

■synchronizesjoinedactivefilters,forexample,byaFIFO（

first-in-first-out）buffer

■forpassivefilters,thepipescanbeimplementedbyadirect

call

?Makethefilterrecombinationharder

?DataSink（數(shù)據(jù)接收端）

■consumesoutputdata

管道■過濾器風格的類型

務類型

■pipelines—linearsequencesoffilters

■boundedpipes—limitedamountofdataonapipe

■typedpipes—datastronglytyped

■batchsequential—datastreamsarenotincremental

面向?qū)ο箫L格特征

q?概述

-面相對象模式集數(shù)據(jù)抽象、抽象數(shù)據(jù)類型、類繼承為一體，使

軟件工程公認的模塊化、信息隱藏、抽象、重用性等原則在面

向?qū)ο箫L格下得以充分實現(xiàn)。

應用場合

■面向?qū)ο蟮捏w系結構模式適用于數(shù)據(jù)和功能分離的系統(tǒng)中，同

樣也適合于問題域模型比較明顯，或需要人機交互界面的系統(tǒng)

0大多數(shù)應用事件驅(qū)動風格的系統(tǒng)也常常應用了面向?qū)ο箫L格

O

面向?qū)ο箫L格

面向?qū)ο箫L格的體系結構

面向?qū)ο箫L格優(yōu)點

?高度模塊性

?封裝功能

?:?代碼共享

*靈活性

*易維護性

*可擴充性

面向?qū)ο箫L格不足

面向?qū)ο箫L格最大的不足在于如果一個對象需要調(diào)用另

一個對象，它就必須知道那個對象的標識（對象名或?qū)?/p>

象引用），這樣就無形之中增強了對象之間的依賴關系

O如果一個對象改變了自己的標識，就必須通知系統(tǒng)中

所有和它有調(diào)用關系的對象，否則系統(tǒng)就無法正常運行

面向?qū)ο箫L格實例

務實例背景

-目前，一個標準的計算機應用系統(tǒng)應該由三部分組成：計算機

操作系統(tǒng)（包括各種應用軟件系統(tǒng)）、數(shù)據(jù)庫管理系統(tǒng)和網(wǎng)絡

環(huán)境（包括網(wǎng)絡硬件設備和各種協(xié)議棧、網(wǎng)絡服務等），這樣

一個具有分布式特性和開放性的系統(tǒng)稱為開放分布式系統(tǒng)（

ODS,OpenDistributedSystem）。

面向?qū)ο箫L格示例

?:*CBA方法：它有三個基本的建模概念：協(xié)作、類型和細

化。

■協(xié)作(Collaboration):根據(jù)構件所承擔的不同角色，協(xié)作定

義了一組構件之間的動作(Action)集合。

-類型(Type):通過描述一個構件的可視外部行為來定義構件

在系統(tǒng)中所承擔的功能。

■細化(Refinement):體現(xiàn)了對同一事物的兩種不同描述之間

的關系，抽象(Abstraction)描述為基礎，實現(xiàn)(

Realization)描述可以看作抽象描述的具體的形式。

面向?qū)ο箫L格

J^ODS系統(tǒng)中構件、連接器和配置的模型，如下圖所示:

面向?qū)ο箫L格實例

?:?構件的描述方法:利用GUI體系結構框架自動生成工具,

可以完成下述幾點功能：

■生成構件模型，包括構件的屬性、接口和實現(xiàn)；

-建立連接器模型，包括協(xié)議、屬性和實現(xiàn)；

-體系結構的抽象和封裝；

-類型和類型檢查；

■主動規(guī)范，提供設計向?qū)В?/p>

■多視圖模式，對不同層次的用戶顯示不同的內(nèi)容；

-生成實現(xiàn)，如將構件對應為面向?qū)ο蠹夹g中的類；

■將系統(tǒng)的修改動態(tài)映射到實現(xiàn)。

面向?qū)ο箫L格實例

不具有自適應穩(wěn)定性的連接器模型

?:?連接器中的通信協(xié)議棧

構件通信傳輸控制協(xié)議

構件通信傳輸協(xié)議構件通信管理協(xié)議

構件命名和尋址協(xié)議

連接器的自適應穩(wěn)定算法:為了提高通信協(xié)議棧在構件通信過程中的穩(wěn)定

性，需要設計某種自適應穩(wěn)定算法，這樣可以修復構件通信時出現(xiàn)的錯誤。

對象風格實例—人事檔案管理系統(tǒng)

人事檔案管理系統(tǒng)

信

檔檔檔統(tǒng)系系

息

案案案計統(tǒng)統(tǒng)

檢

管借轉報維幫

索

理閱遞表護助

系統(tǒng)功能結構

對象風格實例—人事檔案管理系統(tǒng)

務系統(tǒng)功能介紹：

■檔案管理根據(jù)高校人事檔案管理的特點，本模塊可通過錄入各

類人事檔案信息，來構造檔案數(shù)據(jù)庫，編制各種目錄索檢。針

對檔案材料錄入工作量較大，在該功能模塊中設置了多種方式

快速錄入法，如對指定的部分內(nèi)容可采用代碼錄入和菜單選項

等輸入方法.

■信息檢索該模塊主要是檢索有關的人事檔案信息，其檢索方式

為姓氏筆畫檢索目錄。在具體檢索中又可分為精確查詢和模糊

查詢，并可將檢索內(nèi)容動態(tài)輸出，滿足檔案查詢的需要。

?檔案借閱該模塊主要是對檔案的借閱情況、歸還情況、利用登

記等方面進行管理。它能為研究如何更有效地利用人事檔案資

料提供必要的信息。

對象風格實例—人事檔案管理系統(tǒng)

■檔案轉遞該模塊包括人事檔案的轉進和轉出管理，編制清單，

并能在檔案轉遞后，對已變更檔案數(shù)據(jù)庫進行相應地調(diào)整，以

完成相應檔案的刪加。

■統(tǒng)計報表該模塊主要用于統(tǒng)計庫存的各類人事檔案的實際數(shù)量

,及每年歸檔的各類檔案數(shù)量，并可完成相應的圖形繪制和報

表打印。其中，在報表生成中，該模塊可根據(jù)管理人員對報表

的自定義設置來生成相應的非范式報表。

■系統(tǒng)維護由于高校人事檔案的數(shù)據(jù)管理是一項非常重要的工作

,尤其是它的安全可靠性。因此，在進入本模塊操作之前，系

統(tǒng)會提醒用戶輸入姓名、操作口令和權限級別。同時該功能模

塊還包括操作員管理、口令修改、重新登錄、權限級別設置、

系統(tǒng)日志及系統(tǒng)初始化六個子模塊。

-系統(tǒng)幫助本模塊提供了在線聯(lián)機幫助，可實現(xiàn)幫助主題的查詢

,還提供了計算器、日記/日歷等系統(tǒng)工具和關于本系統(tǒng)的簡介

可對象風格實例一一人事檔案管理系統(tǒng)

收集信息'保存檔案芬美管逋

4檔案分類

檔案轉遞

____±_

使用文檔

訪問注冊

統(tǒng)計報表

打E|j

系統(tǒng)活動圖

可對象風格實例一一人事檔案管理系統(tǒng)

系統(tǒng)類結構圖

事件驅(qū)動風格

W?特征

■事件驅(qū)動系統(tǒng)的基本觀點是一個系統(tǒng)對外部的表現(xiàn)可以從它對

事件的處理表征出來。如圖示：

輸入畫出A

>事件接收器事件處理器

反饋

事件驅(qū)動風格特征

令事件驅(qū)動系統(tǒng)具有以下一些特點：

-系統(tǒng)是由若干子系統(tǒng)或元素所組成的一個整體；

■系統(tǒng)有一定的目標，各子系統(tǒng)在某一種消息機制的控制下，為

了這個目標而協(xié)調(diào)行動；

■在某一種消息機制的控制下，系統(tǒng)作為一個整體與環(huán)境相適應

和協(xié)調(diào)；

事件驅(qū)動風格特征

*事件驅(qū)動系統(tǒng)具有以下一些特點（續(xù)）：

■在一個系統(tǒng)的若干子系統(tǒng)中，必定有一個子系統(tǒng)起著主導作用

,而其他子系統(tǒng)則處于從屬地位；

■任一系統(tǒng)和系統(tǒng)內(nèi)的任一元素，都有1個事件收集機制和1個事

件處理機制，通過這種機制與周圍環(huán)境發(fā)生作用和聯(lián)系；

事件驅(qū)動風格特征

下圖是一個基于事件驅(qū)動的軟件系統(tǒng)的示意圖:

事件驅(qū)動風格特征

務事件驅(qū)動風格系統(tǒng)設計時有下述幾條基本原則

-從系統(tǒng)論的角度來看待描述的對象，合理分解子系統(tǒng)，保證各

個子系統(tǒng)的獨立性和社會性；

-無論系統(tǒng)多么復雜，子系統(tǒng)性質(zhì)的差異多么大，任何子系統(tǒng)都

可以按照有無子系統(tǒng)這一性質(zhì)分為2類：管理系統(tǒng)和執(zhí)行系統(tǒng)。

■為了達到系統(tǒng)的目標，系統(tǒng)內(nèi)的各個子系統(tǒng)通過傳遞消息和執(zhí)

行消息來協(xié)同操作。

■為了達到系統(tǒng)的目標，系統(tǒng)內(nèi)的各個子系統(tǒng)通過傳遞消息和執(zhí)

行消息來協(xié)同操作。

事件驅(qū)動風格特征

事件驅(qū)動風格系統(tǒng)設計時有下述幾條基本原則（續(xù)）

■在一個完整系統(tǒng)中，必須有這樣一個子系統(tǒng)，它沒有上級，必

須收集系統(tǒng)外的事件及下級發(fā)出的事件。

-管理類型的子系統(tǒng)一般不執(zhí)行具體操作，它的主要功能是按照

自己的職能指揮下級完成任務，功能性操作一般由執(zhí)行類型的

子系統(tǒng)完成。

-在一般情況下，除最高級管理子系統(tǒng)外，子系統(tǒng)一般是“有問

才答”，即使在必要的情況下需要積極尋找事件時，也必須征

得上級系統(tǒng)得許可，保證了系統(tǒng)的控制流不會分散。

事件驅(qū)動風格基本結構

事件驅(qū)動系統(tǒng)具有某種意義上的遞歸性，形成了“部分

一整體”的層次結構，可以用屬性結構加以表示。一個

簡單的表示方法是為執(zhí)行系統(tǒng)定義一些類，另外定義一

些類作為這些執(zhí)行系統(tǒng)的容器類，也就是管理系統(tǒng)。

事件驅(qū)動風格

事件驅(qū)動風格的基本結構，如下圖:

事件驅(qū)動風格優(yōu)點

?:?事件驅(qū)動風格非常適合于描述系統(tǒng)族，在屬于同一族的

任何系統(tǒng)中，系統(tǒng)的高級管理子系統(tǒng)的描述是完全類似

的，便于重用；

?由于最高管理子系統(tǒng)牢牢的掌握著控制權，又因為各同

級子系統(tǒng)一般不直接發(fā)生關系，因此容易實現(xiàn)并發(fā)處理

和多任務操作；

?基于事件驅(qū)動風格的系統(tǒng)具有良好的可擴展性，設計者

只需為某個對象注冊一個事件處理接口就可以將該對象

引入整個系統(tǒng)，同時并不影響其它的系統(tǒng)對象。

事件驅(qū)動風格優(yōu)點

?定義了包含執(zhí)行子系統(tǒng)和管理子系統(tǒng)的類層次結構;

?:?簡化客戶代碼；

?:?使整個系統(tǒng)的設計更具有一般化。

事件驅(qū)動風格不足

?:?事件驅(qū)動風格最大的不足在于構件削弱了自身對系統(tǒng)計

算的控制能力

事件驅(qū)動風格中存在的另一個問題在于數(shù)據(jù)共享

系統(tǒng)中各個對象的邏輯關系變得更加復雜

X牛驅(qū)動風格和面向?qū)ο箫L格的關系

?基于面向?qū)ο箫L格的系統(tǒng)由多個封裝起來的對象構成，

對象之間通過消息傳遞實現(xiàn)通信，而事件驅(qū)動正是對消

息傳遞機制的一種實現(xiàn)。所以基于事件驅(qū)動風格的系統(tǒng)

往往都是面向?qū)ο蟮摹?/p>

事件驅(qū)動風格實例

?:?事件驅(qū)動風格實例：JavaBean系統(tǒng)概述

-事件從事件源到監(jiān)聽者的傳遞是通過對目標監(jiān)聽者對象的Java

方法調(diào)用進行的。對每個明確的事件的發(fā)生，都相應地定義一

個明確的Java方法。這些方法都集中定義在事件監(jiān)聽者(

EventListener)接口中，這個接口要繼承

java.util.EventListener0

事件驅(qū)動風格實例

?JavaBean系統(tǒng)（續(xù)）

-事件狀態(tài)對象

■與事件發(fā)生有關的狀態(tài)信息一般都封裝在一個事件狀態(tài)對象中

，這種對象是java.util.EventObject的子類。按設計習慣，這

種事件狀態(tài)對象類的名應以Event結尾。

事件驅(qū)動風格實例

?JavaBean系統(tǒng)(續(xù))

■事件監(jiān)聽者接口(EventListenerInterface)與事件監(jiān)聽者

-由于Java事件模型是基于方法調(diào)用，因而需要一個定義并組織

事件操縱方法的方式。JavaBean中，事件操縱方法都被定義在

繼承了java.util.EventListener類的EventListener接口中,按

規(guī)定，EventListener接口的命名要以Listener結尾。任何一個

類如果想操縱在EventListener接口中定義的方法都必須以實現(xiàn)

這個接口方式進行。這個類也就是事件監(jiān)聽者。

事件驅(qū)動風格實例

?JavaBean系統(tǒng)（續(xù)）

-事件監(jiān)聽者的注冊與注銷

■為了各種可能的事件監(jiān)聽者把自己注冊人合適的事件源中，建

立源與事件監(jiān)聽者間的事件流，事件源必須為事件監(jiān)聽者提供

注冊和注銷的方法。在前面的bound屬性介紹中已看到了這種

使用過程，在實際中，事件監(jiān)聽者的注冊和注銷要使用標準的

設計格式：

,publicvoidadd<ListenerType>(<ListenerType>listener)

,publicvoidremove<ListenerType>(<ListenerType>listener)

事件驅(qū)動風格實例

務適配類

-適配類是JavaBean事件模型中極其重要的一部分。在一些應用

場合，事件從源到監(jiān)聽者之間的傳遞要通過適配類來“轉發(fā)”

■適配類成為了事件監(jiān)聽者，事件源實際是把適配類作為監(jiān)聽者

注冊入監(jiān)聽者隊列中，而真正的事件響應者并未在監(jiān)聽者隊列

中，事件響應者應做的動作由適配類決定。

事件驅(qū)動風格實例

?：?TurboVision

■Borland公司開發(fā)的TurboPascal6.0中提供了一種面向?qū)ο蟮?/p>

事件驅(qū)動程序設計的工具包TurboVisionoTurboVision把各

種屏幕上的可見對象歸納為2大類：一類為執(zhí)行對象，另一類為

管理對象，分別稱為TView和TGroup類對象。又因為TGroup

和TView類有相同之處，故TGroup是從TView派生而得，在

TurboVision中，TGroup類的對象一般不進行實際操作，不直

接在屏幕上顯示自己，而是通過自己的下屬顯示自己，所有的

實際操作都是通過TView類對象進行的。

事件驅(qū)動風格實例

■TurboVision很好地體現(xiàn)了面向?qū)ο蠓椒ê褪录?qū)動程序設計

方法的精髓，TApplication是一個可以運行的交互式程序?qū)ο?/p>

,除了啟動和退出之外，它不提供任何功能，使用Turbo

Vision,就能高效和快速地開發(fā)出高質(zhì)量地應用程序。

事件驅(qū)動風格實例

TurboVision

TurboVision軟件包中對象的分類結構如圖所示:

TViewTGroupTProgramTApplication

?TBackGroundTWindow-TDialog

TDestop

TMenuViewTMenuBar

TMenuBox

1TStatusLine

TListBox

THistoryViewer

TStaticTextTLaole

TParaText

TClusterTCheckBox

TRadioButton

TButton

TScrollBar

TScrollerTTextDeviceTTerminal

TurboVision中對象的分類結構

事件驅(qū)動風格實例

TurboVision

TurboVision對象的組裝結構一般說來，TApplication對象擁有并管理

它創(chuàng)建的3個子對象TMemiBar,TDeskTop和TStatusLine,如圖所示.

TurboVision的組裝結構

事件驅(qū)動風格實例

TurboVision

在程序的實際運行中，Application對象通常創(chuàng)建各種TWindow類和

Tdialog類對象，并委托DeskTop代為管理.因此，DeskTop對象的組裝常常隨

程序的運行而改變.窗口對象（Twindow類）和對話框?qū)ο螅═oialog類）隨應用

的不同而不同，典型的窗口和對話框?qū)ο蟮慕M裝結構如圖所示.

窗口和對話框?qū)ο蟮慕M裝結構

事件驅(qū)動風格實例

TurboVision

TurboVision把事件抽象為3種類型的事件:位置事件、聚焦事件和廣播事

件。典型的位置事件是鼠標器事件，TGroup類視圖把位置事件交給管理該區(qū)

域的子視圖;典型的聚焦事件是擊鍵和命令事件（典型的命令事件是由狀態(tài)行或

菜單條、下拉菜單將擊鍵事件或鼠標器事件轉換而得），TGroup類視圖把該事

件交給處于聚焦狀態(tài)的下級視圖;廣播事件是管理視圖不知道該交給誰的那種

事件，對于這種事件，它將該事件交給所有的視圖。

TurboVision程序在運行時，由TApplication對象收集鼠標器事件和健盤事

件以及各種其它事件，然后按一定的規(guī)則交給下屬去處理.例如，對于鼠標器

事件，如果它發(fā)生在菜單條上，則將它交給菜單條來處理;如果它發(fā)生在狀態(tài)

行，則將它交給狀態(tài)行來處理;如果它發(fā)生在DeskTop上，則將它交給DeskTop

來處理?？傊?，細節(jié)問題總是交給下屬來處理.狀態(tài)行和菜單條的任務是將鍵

盤事件和自己轄區(qū)的鼠標器事件轉換成為命令事件，再上交給TApplication。

分層風格

孝特征

-一個分層系統(tǒng)采用層次化的組織方式構建，系統(tǒng)中的每一層都

要承擔兩個角色。

?首先，它要為結構中的上層提供服務；

?其次，它要作為結構中下面層次的客戶，調(diào)用下層提供的功

能函數(shù)。

分層風格特征

務一個概念上的分層模型如下圖所示:

應用層

C最冏層）

分層風格優(yōu)點

分層風格具有一些系統(tǒng)設計者無法抗拒的優(yōu)勢:

-分層風格支持系統(tǒng)設計過程中的逐級抽象

■基于分層風格的系統(tǒng)具有較好的可擴展性

-分層風格支持軟件復用

分層風格不足

*并不是所有的系統(tǒng)都適合用分層風格來描述的

?:?對于抽象出來的功能具體應該放在哪個層次上也是設計

者頭疼的一個問題

分層風格實例

務分層風格實例：計算機網(wǎng)絡的設計

*概述

■網(wǎng)絡協(xié)議設計者將計算機網(wǎng)絡中的各個部分按其功能劃分為若

干個層次（Layer）,其中的每一個層次都可以看成是一個相對

獨立的黑箱、一個封閉的系統(tǒng)。用戶只關心每一層的外部特性

,只需要定義每一層的輸入、數(shù)據(jù)處理和輸出等外部特性。

分層風格實例

三?ISO/OSI網(wǎng)絡體系結構

ISO/OSI采用了7層體系結構，從高到低分別是：應用層、表示層、會話層、

傳輸層、網(wǎng)絡層、數(shù)據(jù)鏈路層和物理層，如圖所示。其最高層為第7層應用層,

用于同應用服務之間交換數(shù)據(jù)；最低層為第1層物理層，用于連接物理傳輸介

質(zhì)實現(xiàn)真正的數(shù)據(jù)通信。層與層之間的聯(lián)系是通過各層之間的接口來實現(xiàn)的，

上層通過接口向下層提出服務請求，而下層通過接口向上層提供服務。兩臺

計算機通過網(wǎng)絡進行通信時，只有兩物理層之間能夠通過媒體進行真正的數(shù)

據(jù)通信，其余各對等層之間均不存在直接的通信關系，各對等層之間只能通

過各對等層的協(xié)議來進行虛擬通信。

ISO/OSI網(wǎng)絡體系結構

分層風格實例

令ISO/OSI網(wǎng)絡體系結構

?為了理解ISO/OSI各層的功能，以運輸公司進行貨物運輸為

例來進行說明，也就是利用人們熟知的東西來理解陌生抽象

的概念。其中，第1?3層3個層次相當于由運輸公司負責的貨

物運輸過程中的具體細節(jié)、具體操作方式；第4層相當于運

輸公司與用戶之間的接口；第5?7層3個層次相當于由用戶公

司負責的將貨物交去運輸所需要做的準備工作。

■第1層是物理層(PhysicalLayer),它負責在物理信道上傳輸

原始的數(shù)據(jù)bit流。它應該提供為建立、維護和拆除物理鏈路連

接所需的機械的、電氣的、功能和規(guī)程的特性，這類似于運輸

車輛只需要負責將裝在車輛內(nèi)的貨物(類似于bits)運送到某

地就行了。

分層風格實例

■第2層是數(shù)據(jù)鏈路層(DataLinkLayer),它的主要功能是糾

錯和流量控制，負責在可能出現(xiàn)差錯的物理線路中實現(xiàn)無差錯

的數(shù)據(jù)傳送。它應該在物理層的基礎上，建立相鄰結點之間的

數(shù)據(jù)鏈路，通過差錯控制提供數(shù)據(jù)幀(Frame)的無差錯傳輸

,并進行數(shù)據(jù)流量控制。這類似于運輸公司的運輸管理和質(zhì)量

監(jiān)督部門，需要負責在可能出現(xiàn)問題的運輸線路之中保質(zhì)保量

地完成運輸任務。

分層風格實例

■第3層是網(wǎng)絡層（NetworkLayer）,它的主要功能是路由控制

（找路）、擁塞控制和數(shù)據(jù)打包。它應該為其上一層傳輸層的

數(shù)據(jù)傳輸提供建立、維護和終止網(wǎng)絡連接的手段，把上層傳來

的數(shù)據(jù)分割成一個一個的數(shù)據(jù)包（Packet,也叫報文分組）在

結點之間進行交換傳送，并且負責路由控制和擁塞控制。這類

似于運輸公司需要將用戶發(fā)送的貨物進行分割打包，并在現(xiàn)有

的交通網(wǎng)絡之中負責找出一條從源地址到目的地址的線路（即

找路），在找路時需要考慮到能否到達、擁塞狀況、安全可靠

性、甚至交通費用等諸多方面的因素。

分層風格實例

■第4層是傳輸層(TransportLayer),它的主要功能是在上層

和下層之間起到一種接口的功能。它應該為上層提供端到端(

最終用戶到最終用戶)、的透明的、可靠的數(shù)據(jù)傳輸服務。所

謂透明的傳輸是指在通信過程中上層可以將下面各層看作是一

個封閉的黑箱系統(tǒng)，傳輸層對上層屏蔽了傳輸系統(tǒng)的具體細節(jié)

0這類似于運輸公司在各個地方設置的業(yè)務接洽處，它負責在

用戶和公司之間建立起一個貨物交接的橋梁，使得用戶不用去

管運輸公司將以什么樣的方式將貨物運送到目的地，也就是說

業(yè)務接洽處對用戶屏蔽了貨物運輸中的具體細節(jié)。

分層風格實例

■第5層是會話層(SessionLayer),它的主要功能是負責收發(fā)

數(shù)據(jù)的交接工作、并組織和管理數(shù)據(jù)。它應該為表示層提供建

立、維護和結束會話連接的功能，并提供會話管理服務。這類

似于用戶公司的貨物收發(fā)室，它負責與運輸公司打交道，完成

用戶公司貨物的收發(fā)的交接工作、并組織管理公司內(nèi)部要收發(fā)

的貨物。

分層風格實例

■第6層是表示層(PresentationLayer),它的主要功能是為數(shù)

據(jù)提供收發(fā)、存放的具體格式和規(guī)范。它應該為應用層提供信

息表示方式的服務，如數(shù)據(jù)格式的變換、文本壓縮、加密技術

等。這類似于用戶公司的貨物收發(fā)員，它負責與用戶公司內(nèi)部

要收發(fā)貨物的部門或個人打交道，在收集要發(fā)送的貨物時告訴

用戶應該怎樣填寫發(fā)貨資料，在向用戶發(fā)放貨物時告訴用戶應

該完清哪些具體手續(xù)，等等。

分層風格實例

■第7層是應用層(ApplicationLayer),它的主要功能是為數(shù)

據(jù)提供各種可行的收發(fā)方式。它應該為網(wǎng)絡用戶或應用程序提

供各種應用服務，如文件傳輸、電子郵件(E-mail)、分布式

數(shù)據(jù)庫、網(wǎng)絡管理等。這類似于用戶公司內(nèi)部的部門或個人在

收發(fā)貨物時，都必須遵循用戶公司內(nèi)部的有關規(guī)定，只能使用

用戶公司所允許的方式來收發(fā)貨物。從另一方面來說，用戶公

司也要為公司內(nèi)部的部門或個人收發(fā)貨物提供各種可行的收發(fā)

方式，讓用戶公司內(nèi)部的部門或個人知道他們能夠使用哪些方

式來收發(fā)貨物。

分層風格

*ISO/OSI層次分組關系：有兩種分組方法

■|第一種可以從數(shù)據(jù)處理分工的角度，將ISO/OSI七個層次分為

三組：第1、2層解決有關網(wǎng)絡信道問題；第3、4層解決傳輸服

務問題；第5、6、7層則處理對應用進程的訪問。

-從數(shù)據(jù)傳輸控制的角度，將ISO/OSI七個層次分為三組：下三

層（1、2、3層）可以看作是傳輸控制組，負責通信子網(wǎng)的工作

,解決網(wǎng)絡中的通信問題；上三層（5、6、7層）為應用控制組

,負責有關資源子網(wǎng)的工作，解決應用進程之間的信息轉換問

題；中間層（4層）則為通信子網(wǎng)和資源子網(wǎng)的接口，起到連接

傳輸和應用的作用。

分層風格實例

.Net平臺也是一個明顯的分層系統(tǒng):

率托筒應用程序

數(shù)據(jù)共享風格

孝特征

■采用數(shù)據(jù)共享風格構建的系統(tǒng)中通常有兩個截然不同的功能構

件；

■中央數(shù)據(jù)單元構件；

-一些相對獨立的構件的集合。

?:?信息交互方式的差異導致了控制策略的不同。主要的控

制策略有兩種，正是依據(jù)這兩種不同的控制策略，基于

數(shù)據(jù)共享風格的系統(tǒng)被分成兩個子類：

?基于傳統(tǒng)數(shù)據(jù)庫型數(shù)據(jù)共享風格的應用系統(tǒng)

-基于黑板型數(shù)據(jù)共享風格的應用系統(tǒng)

數(shù)據(jù)共享風格特征

當黑板型數(shù)據(jù)共享風格的示意圖如下圖所示:

數(shù)據(jù)共享風格

寫一個典型的黑板型數(shù)據(jù)庫系統(tǒng)包括以下三個部分:

1.知識源：知識源中包含獨立的、與應用程序相關的知識，知識

源之間不直接進行通訊，它們之間的交互只通過黑板來完成。

2.黑板數(shù)據(jù)結構：黑板數(shù)據(jù)是按照與應用程序相關的層次來組織

的解決問題的數(shù)據(jù)，知識源通過不斷地改變黑板數(shù)據(jù)來解決問

題。

3.控制：控制完全由黑板的狀態(tài)驅(qū)動，黑板狀態(tài)的改變決定使用

的特定知識。

?：.黑板模式對于無確定性求解策略的問題比較有用，在專

家系統(tǒng)中，這種模式應用的比較廣泛。

數(shù)據(jù)共享風格優(yōu)點

?:?解決問題的多方法性：

■對于一個專家系統(tǒng)，針對于要解決的問題，如果在其領域中沒

有獨立的方法存在，而且對解空間的完全搜索也是不可行的，

在黑板模式中可以用多種不同的算法來進行試驗，并且也允許

用不同的控制方法。

?具有可更改性和可維護性：

-因為在黑板模式中每個知識源是獨立的，彼此之間的通信通過

黑板來完成，所以這使整個系統(tǒng)更具有可更改性和可維護性。

數(shù)據(jù)共享風格優(yōu)點

?:?有可重用的知識源：

■由于每個知識源在黑板系統(tǒng)中都是獨立的，如果知識源和所基

于的黑板系統(tǒng)有理解相同的協(xié)議和數(shù)據(jù)，我們就可以重用知識

源。

*支持容錯性和健壯性：

-在黑板模式中所有的結果都是假設的，并且只有那些被數(shù)據(jù)和

其它假設強烈支持的才能夠生存。這對于噪聲數(shù)據(jù)和不確定的

結論有很強的容錯性。

數(shù)據(jù)共享風格缺點

爭測試困難：

■由于黑板模式的系統(tǒng)有中央數(shù)據(jù)構件來描述系統(tǒng)的體現(xiàn)系統(tǒng)的

狀態(tài)，所以系統(tǒng)的執(zhí)行沒有確定的順序，其結果的可再現(xiàn)性比

較差，難于測試。

*不能保證有好的求解方案：

■一個黑板模式的系統(tǒng)所提供給我們的往往是所解決問題的一個

百分比，而不是最佳的解決方案。

效率低：

-黑板模式的系統(tǒng)在拒絕錯誤假設的時候要承受多余的計算開銷

,所以導致效率比較低。

數(shù)據(jù)共享風格缺點

?:?開發(fā)成本高:

■絕大邨個黑板模式的系統(tǒng)需要用幾年的時間來進化，所以開發(fā)

成本較圖0

缺少對并行機的支持：

-黑板模式要求黑板上的中心數(shù)據(jù)同步并發(fā)訪問，所以缺少對不

并行機的支持。

數(shù)據(jù)共享風格實例

&數(shù)據(jù)共享風格實例：專家系統(tǒng)(ES,ExpertSystem

)概述：

■專家系統(tǒng)實質(zhì)就是一組程序；

■從功能上：可定義為“一個在某領域具有專家水平解題能力的

程序系統(tǒng)”，能像領域?qū)＜乙粯庸ぷ?，運用專家積累的工作經(jīng)

驗與專門知識，在很短時間內(nèi)對問題得出高水平的解答。

■從結構上講：可定義為“由一個專門領域的知識庫，以及一個

能獲取和運用知識的機構構成的解題程序系統(tǒng)”。

數(shù)據(jù)共享風格實例

型啰ES一般結構如下圖所示:實例

數(shù)據(jù)庫及其管理系統(tǒng)知識庫及其管理系統(tǒng)

知識庫系統(tǒng)實例

IECRMAS知識生態(tài)系統(tǒng)的構建

IECRMAS知識生態(tài)系統(tǒng)知識流

3./

~FIECRMAS知識生態(tài)系統(tǒng)

容

優(yōu)

刑

滲

與

旅

信用評估知識庫的形成

IECRMAS知識生態(tài)系統(tǒng)

CRMAPS知識生態(tài)系統(tǒng)中知識流動

IECRMAS知識生態(tài)系統(tǒng)

傳遞

更新、

評估客戶＞

習數(shù)據(jù)庫

AgentAgent

咨

笳

濡

評估

Agent管理

學習

Agent評估系統(tǒng)

\知識基,

個體知識進化圖

IECRMAS知識生態(tài)系統(tǒng)

解釋器風格

?:?特征

-基于解釋器風格的系統(tǒng)核心在于虛擬機。

-一個基于解釋器風格的系統(tǒng)通常包括：正在被解釋執(zhí)行的偽碼

和解釋引擎；

■偽碼：由需要被解釋執(zhí)行的源代碼和解釋引擎分析所得的中間

代碼組成；

■解釋引擎包括：語法解釋器和解釋器當前的運行狀態(tài)

解釋器風格特征

解釋器風格優(yōu)點

?在文法規(guī)則比較簡單的情況下，解釋器風格工作的很好

*

9

?:?易于改變和擴展文法。因為解釋器風格使用類來表示文

法規(guī)則，用戶可以使用繼承來改變和擴展文法。已有的

表達式可以采用增量的方式逐漸擴充，而新的表達式可

以定義為舊表達式的變體；

易于實現(xiàn)文法。

*可以用多種操作來“解釋”一個句子。

解釋器風格缺點

?無法解釋復雜的文法規(guī)則：對于比較簡單的文法規(guī)則，

解釋器風格工作的很好，而對于復雜的文法規(guī)則，則由

于文法層次的龐大而難于管理；

?:?應用范圍比較狹窄；

?:?在文法規(guī)則比較復雜，則文法的層次變得無法管理，系

統(tǒng)中需要包含許多表示文法規(guī)則的類。

解釋器風格實例

解釋器風格實例：一個布爾表達式解釋器

-目標：布爾表達式求值系統(tǒng)

■現(xiàn)定義由如下文法定義的布爾正則表達式

BooleanExpression::=VariableExpressionIConstantIOrExpressionI

AndExpressionINotExpressionI1(*BooleanExpression1)1

AndExpressionBooleanExpression'and1BooleanExpression

OrExpression::=BooleanExpression'or1BooleanExpression

NotExpression::='not1BooleanExpression

Constant::=1true1I1false\

VariableExpression'A'I'B1...|'Y'I'Z'

編譯器(1)

、F系統(tǒng)的體系結構可以隨技術的發(fā)展而發(fā)生變化

-傳統(tǒng)的編譯器模型

-具有共享符號表的傳統(tǒng)編譯器模型

編譯器(2)

?隨著時間的推移，編譯技術變得更加復雜，更多的注意

力轉移到程序在編譯過程的中間表示，例如屬性文法樹

■典型的現(xiàn)代編譯器模型

Computations

(transducersand

transforms)

解釋器風格實例

三?布爾表達式求值系統(tǒng)類圖，如下圖所示:

解釋器風格示例

三?布爾表達式抽象語法樹實例，如下圖所示:

解釋器風格實例

令布爾表達式求值系統(tǒng)的優(yōu)缺點：

-在文法規(guī)則比較簡單的情況下，解釋器風格工作的很好，但如

果文法規(guī)則復雜，則文法的層次變得龐大而無法管理，系統(tǒng)中

需要包含許多表示文法規(guī)則的類。

■最高效的解釋器通常不是通過直接解釋語法分析數(shù)實現(xiàn)的，而

是首先將它們轉換成另一種形式。

■易于改變和擴展文法。

■易于實現(xiàn)文法。

解釋器風格實例

令布爾表達式求值系統(tǒng)中的角色：

■BooleanExpression（抽象布爾表達式）

■TerminalExpression（終結符表達式，如

VariableExpresssion和Constant）

■NonterminalExpression（非終結符表達式，如

AndExpression>OrExpression和NotExpression）

-Context（上下文，也就是“解釋引擎內(nèi)部狀態(tài)”）

■Client（客戶）

解釋器風格實例

令布爾表達式求值系統(tǒng)的實現(xiàn)

-在具體實現(xiàn)布爾表達式求值系統(tǒng)時還有許多細節(jié)的問題要處理

,這些細節(jié)問題處理的好壞甚至會直接影響整個系統(tǒng)的性能。

這些問題主要表現(xiàn)在以下幾個方面：

?創(chuàng)建抽象語法樹

?定義求值操作

?共享終結符

解釋器風格示例

解釋器風格定義了特定語言的文法表示和解釋該文法的

解釋器。這種模式如同樂譜。其中，音階和它的持續(xù)時

間可以用五線譜上的符號表示。這些符號就是音樂語言

O音樂家按照樂譜演奏，就可以反復重現(xiàn)同樣的音樂。

解釋器實例

使用音樂例子的解釋器風格對象圖

解釋器實例

羅馬數(shù)字轉換系統(tǒng)

解釋器實例

3AbstractExpression(Expression)

?聲明執(zhí)行特定操作的接口。

>TerminalExpression(ThousandExpression,

HundredExpression,TenExpression,OneExpression)

-實現(xiàn)一個與語法中終結符相關的解釋操作。

■句子中的每一個終結符都需要一個實例。

>NonterminalExpression

'語法中的每個規(guī)則R:尸R1R2...Rn都需要這樣的一個類。

■管理從R1到Rn每一個符號的AbstractExpression類型變量的實例。

-實現(xiàn)語法中非終結符的解釋操作，在解釋中可能需要遞歸調(diào)用自身。

：?Context(Context)

?包含對于解釋器來說是全局的信息。

：?Client(InterpreterApp)

?建立(或者給定)一個抽象語法樹。抽象語法樹是由

NonterminalExpression和TerminalExpression類的實例組合而成。

'調(diào)用解釋操作。程序源為馬

反饋控制環(huán)風格

?:?概述

-所謂對一個對象（或過程）進行控制，意味著設法使這個被控

對象（或被控過程）的功能或特性有效的達到所期望的目標。

■為了成功設計一個控制系統(tǒng)，必須事先知道被控對象所具有的

性質(zhì)和特征，同時還須了解和掌握這些性質(zhì)和特征隨環(huán)境等因

素變化的情況。

反饋控制環(huán)風格

-控制工程是一個十分強調(diào)方法論的專業(yè)領域，因此控制工程方

法完全是獨立于各種應用領域的。

-為了將過程控制方法從單純的控制領域中抽象出來，我們引入