【正文】 因此，語法制向的編輯器能夠在程序輸入時檢查程序的語法是正確的，而程序格式轉換器能夠以一種十分方便閱讀的格式創(chuàng)建程序清單。工具或小程序通過它來實現(xiàn)通信。 圖 621 語言處理系統(tǒng)的容器體系結構 抽 象 語 法 樹詞 法 分 析 器 語 法 分 析 器 語 義 分 析 器優(yōu) 化 器語 法 定 義符 號 表 輸 出 定 義容 器代 碼 生 成 器美 編 工 具編 輯 器 語言處理系統(tǒng) ? 圖 621說明了一個語言處理系統(tǒng)是如何成為集成化編程支持工具的一部分的。在這種情況下，來自一個組件的變化需要立即反映到其他組件中。 圖 620 編譯器的管道 過濾器體系結構 符 號 表語 法 樹詞 法 分 析 句 法 分 析 語 義 分 析 代 碼 生 成 語言處理系統(tǒng) ? 語言編譯的管道 過濾器模型對于程序的編譯和執(zhí)行無需用戶交互的批處理環(huán)境很有效，例如，把一個 XML文件翻譯成另一個文件。在編譯器的體系結構中，符號表是共享數(shù)據(jù)容器。 ? 在語言處理系統(tǒng)中可能會用到的還有另外可用的體系結構模式。 語言處理系統(tǒng) ? 還會有其他一些組件，這些組件可能用于從所生成的機器代碼中分析和變換語法樹來提高效率和降低冗余。 語言處理系統(tǒng) ? 程序語言編譯器是更一般化的編程環(huán)境的一部分，它具有一般的體系結構，包括以下組件： – ① 詞法分析器，將一個輸入的語言記號轉換為內部形式； – ② 符號表，保持實體名字相關的信息（變量、類名字、對象名字等），實體是正在翻譯的文本； – ③ 語法分析器，它檢查正在翻譯的語言的語法。 圖 619 語言處理系統(tǒng)的體系結構 翻 譯 器 檢 查 語 法 檢 查 語 義 生 成 抽 象 機 m / c 指 令解 釋 器 取 執(zhí) 行源 語 言 指 令數(shù) 據(jù) 結 果 語言處理系統(tǒng) ? 當然，對于很多編譯器，解釋器是一個處理機器指令的硬件單元，抽象機是一個真處理器。這些指令然后由另一個組件解釋，它首先取指令，然后（在必要的時候）再使用來自環(huán)境中的數(shù)據(jù)去執(zhí)行它們。 語言處理系統(tǒng) ? 圖 619給出了編程語言的一種語言處理系統(tǒng)的可能的體系結構。它將高層語言翻譯成機器代碼。它們包括一個翻譯器和一個執(zhí)行生成的語言的抽象機。這些系統(tǒng)總是實現(xiàn)大多層的客戶機 /服務器體系結構。在電子商務系統(tǒng)中，應用相關層包括額外的功能，支持所謂的“購物車”，即用戶可以在不同的事務中購買多個項目，然后在一個事務中完成對所有項目的叉付。 信息系統(tǒng) ? 信息和資源管理系統(tǒng)通?；?Web系統(tǒng)，用戶接口使用Web瀏覽器實現(xiàn)。 信息系統(tǒng) – 3）第三層實現(xiàn)系統(tǒng)的功能，并提供：實現(xiàn)有關系統(tǒng)信息安全，病人信息的建立和更新，從其他數(shù)據(jù)庫載入和導出病人數(shù)據(jù)，以及報告生成器建立管理報告。該層包括允許用戶登錄系統(tǒng)的組件和確保他們使用的操作符合他們身份的檢驗組件。在這個例子中， UI是用 Web瀏覽器實現(xiàn)的。 圖 617 分層的信息系統(tǒng)體系結構 事 務 管 理 數(shù) 據(jù) 庫信 息 檢 索 和 修 改 用 戶 身 份 驗 證 通 信 和 授 權用 戶 界 面 信息系統(tǒng) ? 作為分層模型的一個實例，圖 618給出了 MHCPMS系統(tǒng)的體系結構，這個系統(tǒng)維護并管理那些具有心理問題前來咨詢專家的病人的詳細信息。用戶通信層處理所有來自用戶界面的輸入和輸出，信息檢索層包括應用相關的訪問和更新數(shù)據(jù)庫的邏輯。 ? 圖 617 是一個信息系統(tǒng)的一般模型。這些大數(shù)據(jù)庫例子有圖書館書目庫、航班時刻表、醫(yī)院的病人記錄等。 圖 616 ATM機系統(tǒng)的軟件體系結構 獲 取 客 戶賬 戶 標 識 符驗 證 卡選 擇 服 務查 詢 賬 戶更 新 賬 戶打 印 明 細返 回 卡分 發(fā) 現(xiàn) 金輸 入 處 理 輸 出A T M 數(shù) 據(jù) 庫 A T M 信息系統(tǒng) ? 所有涉及與共享數(shù)據(jù)庫交互的系統(tǒng)都可以看成是基于事務的信息系統(tǒng)。輸入輸出組件實現(xiàn)為 ATM機上的軟件，而處理組件位于銀行數(shù)據(jù)庫服務器上。例如，允許客戶在ATM機上查詢賬戶余額和提取現(xiàn)金的銀行系統(tǒng)。在事務管理器正確完成事務后，傳遞一個信號給應用，報告處理完畢。請求會被應用相關的邏輯進行處理。圖 615給出了事務處理應用的概念體系結構。如果用戶事務不要求數(shù)據(jù)庫發(fā)生改變，那么就沒有必要把它作為數(shù)據(jù)庫事務。事務中的所有操作都必須在數(shù)據(jù)庫永久改變之前完成，確保在事務中操作失敗不會導致數(shù)據(jù)庫的不一致性。這種類型系統(tǒng)包括交互式銀行系統(tǒng)、電子商務系統(tǒng)、信息系統(tǒng)和預訂系統(tǒng)。這些是最為平常的一類交互式業(yè)務系統(tǒng)類型。如果在討論一個特殊的應用或者試圖比較幾個具有相同類型的應用時，可以使用在一般體系結構中所有的概念來談論應用。在希望復用時，可以將它們與一般結構做比較來看在應用體系結構中是否有類似的組件。 – 4）作為評估組件以便復用的手段。應用體系結構尋找系統(tǒng)體系結構的穩(wěn)定的結構特征，而且，在很多情況下，是可能并行地開發(fā)這些的。如果已經(jīng)為一個應用系統(tǒng)完成了系統(tǒng)體系結構設計，可以將它與一般應用體系結構進行比較，來檢查自己的設計和一般體系結構是否一致。當然，這些都必須針對被開發(fā)的專門系統(tǒng)進行特殊處理，但不管怎樣，它們都是設計的一個很好的開始。 體系結構的應用方式 ? 軟件設計人員可以以多種方式來使用這些應用體系結構模型： – 1）作為體系結構設計過程的一個起點。例如出自 SAP和 Oracle公司的企業(yè)資源規(guī)劃（ ERP）系統(tǒng)以及為特殊應用所提供的垂直軟件包（ COTS），在這些系統(tǒng)中，我們可以發(fā)現(xiàn)存在一個通用的配置，通過調整它們來產(chǎn)生專門的業(yè)務應用。應用系統(tǒng)體系結構的一般模型能幫助我們理解應用的運作，比較相同類型的應用，驗證應用系統(tǒng)設計的有效性并能達到對大粒度組件的復用。例如，在實時系統(tǒng)中就有不同系統(tǒng)類型的通用的體系結構模型，像數(shù)據(jù)采集系統(tǒng)或監(jiān)控系統(tǒng)。這些共性導致了用來描述特殊類型軟件系統(tǒng)的結構和組成的軟件體系結構的發(fā)展。除了一般的業(yè)務功能之外，所有的電話公司都需要系統(tǒng)去連通線路、管理它們的網(wǎng)絡、向客戶開單據(jù)等。 應用框架 ? 第三種組合方法是用完全不同的體系結構風格來闡述體系結構描述的一個角度。這是一個知識庫，它通過隱式調用來激活外部的構件。（事實上， Unix管道 過濾器就是以這種方式組織的；文件系統(tǒng)充當知識庫的角色，初始化轉換器充當控制器的角色。 應用框架 ? 第二種組合風格的方式是允許單一構件使用復合的連接件。連接件通常也能從層次上分解。 ? 一種組合方式是使用層次結構。 應用框架 ? 體系結構風格、設計模式和應用框架的概念是基于不同的目的和出發(fā)點來討論軟件體系結構，它們之間的概念經(jīng)?；ハ嘟梃b和引用。體系結構風格描述了軟件系統(tǒng)的整體組織結構，它獨立于實際問題。 應用框架 ? 框架的關鍵還在于框架內對象間的交互模式和控制流模式?？梢哉f，一個框架是一個可復用的設計構件，它規(guī)定了應用的體系結構，闡明了整個設計、協(xié)作構件之間的依賴關系、責任分配和控制流程，表現(xiàn)為一組抽象類以及其實例之間協(xié)作的方法，它為構件復用提供了上下文（ Context）關系。這些系統(tǒng)被定義成狀態(tài)集合和指定的轉換集合，轉換將系統(tǒng)從一個狀態(tài)轉換到另一個狀態(tài)。在很多案例中，可執(zhí)行系統(tǒng)就是從體系結構描述本身自動或半自動生成的。這種體系結構提供一種被剪裁成應用程序族的組織結構，比如航空電子技術，命令和控制，汽車駕駛系統(tǒng)。主程序 /子程序體系結構的構件分布在網(wǎng)絡中的多臺計算機上，則構成遠程過程調用體系結構。對于一個沒有模塊化支持的語言，系統(tǒng)通常會被組織成一個主程序和一系列子程序的集合。圖 614描述了該類型的體系結構。家庭自動調溫器就是一個常見的例子：自動調溫器中的氣體溫度被測量出，根據(jù)設定的期望溫度（即設定點），控制爐子的開關。通常，通過監(jiān)測諸如溫度、壓力和流速這類屬性，計算它們的值，再通過改變設備（比如氣閥，加熱器，冷卻器）的設置，來控制過程。這樣的一個過程稱為開環(huán)系統(tǒng)（ Openloop System）。 ? 過程控制系統(tǒng)的目標是將過程輸出的指定屬性維持在一個（充分接近的）特定的參考值即設定點。 – ⑧ 反饋控制系統(tǒng)：被控變量是可測量的，并且使用測量的結果操作一個或更多的過程變量。 – ⑥ 開環(huán)系統(tǒng)：在這種系統(tǒng)中，過程變量的相關信息不用于調整系統(tǒng)。 – ④ 操縱變量：一種過程變量，它的值能被控制器改變。尤其是，為了對過程做出調整，被控變量要與控制系統(tǒng)的某些屬性聯(lián)系起來，這些屬性能夠被控制系統(tǒng)改變（過程變量不能和程序變量混淆）。系統(tǒng)狀態(tài)（材料、設備設置等）可測屬性的值稱為過程變量，用來測量輸出材料的過程變量稱為過程被控變量。 過程控制 ? 基于過程控制環(huán)路是另一個體系結構模式，這種模式在軟件開發(fā)中并沒有得到廣泛認可；這種模式不像面向對象或功能設計那樣以出現(xiàn)的某類構件為特征，控制環(huán)路的設計特點是不僅具有某類構件，還具有在構件間必須保持的特殊關系。 圖 613 解釋器 數(shù) 據(jù)（ 程 序 狀 態(tài) ）被 解 釋 的 程 序（ 偽 碼 ）內 部解 釋 器狀 態(tài)解 釋 引 擎存 儲 區(qū)選 擇 的 指 令 和 數(shù) 據(jù)數(shù) 據(jù) 存 取輸 入輸 出計 算（ 狀 態(tài) 機 ） 解釋器 ? 解釋器模式通常用來構建虛擬機，以彌合程序語義所期望的與硬件提供的計算引擎之間的差距。而解釋引擎包括語法、解釋器的定義和解釋器當前執(zhí)行狀態(tài)。 解釋器 ? 一個解釋器包括正在被解釋執(zhí)行的偽碼和解釋引擎本身。最后，正確性驗證也可能是個問題，因為發(fā)布事件的過程的具體含義與事件激發(fā)的上下文有關。有時數(shù)據(jù)通過事件傳遞，但在某些情況下，事件系統(tǒng)必須依賴一個共享緩沖區(qū)，以便于數(shù)據(jù)的交換。即使它能夠肯定該事件會被其他構件響應，它也不能依賴事件被處理的先后順序。 ? 隱式調用的主要缺點是構件放棄了自身對系統(tǒng)計算的控制。第二個優(yōu)點是隱式調用能夠簡化系統(tǒng)的演化。 ? 隱式調用對重用提供了很好的支持。正因為這個原因，許多隱式調用系統(tǒng)也包括顯式調用（比如，正常的過程調用），以此作為構件交互的補充。這種模式主要特點是事件發(fā)布者不知道哪些構件會受到事件的影響。 ? 從體系結構的角度說，隱式調用模式中的構件是模塊，其接口不僅提供過程的集合（像抽象數(shù)據(jù)類型），也提供事件的集合。這些過程會使編輯器滾動到相應的代碼行，或者重新顯示被監(jiān)視的變量的值。比如在 Field系統(tǒng)中，諸如編輯器和變量監(jiān)視器等工具會注冊調試器的中斷點事件。當這個事件發(fā)生時，系統(tǒng)本身會調用所有注冊了這個事件的過程。 ? 隱式調用的思想是，不直接調用一個過程，而是發(fā)布或廣播一個或多個事件。 ? 在一個系統(tǒng)中，比如面向對象系統(tǒng)，構件接口提供了過程和函數(shù)的集合，典型的情況是，構件通過顯式地調用這些例程來與其他構件交互。在模塊化語言中，當一個模塊改變后需要修改每一個引用了這個模塊的“導入”列表。與此相反，例如，在管道 過濾器系統(tǒng)中，過濾器之間交互不需要知道系統(tǒng)中其他過濾器的存在。另外，由于把操作的數(shù)據(jù)和一組存取例程綁定在一起，使得設計者能夠把問題分解成交互作用的代理集合。 數(shù)據(jù)抽象和面向對象組織 ? 面向對象系統(tǒng)有很多眾所周知的優(yōu)點。 ? 抽象數(shù)據(jù)類型的使用，以及面向對象系統(tǒng)的使用己經(jīng)非