【正文】 風格與模式 ? 從更詳細的層面上，為了分清不同模式間的差異，需要有一個公共的框架以便對這些模式進行比較。然而，體系結構模式與體系結構風格在許多基本方面存在不同： – l）模式涉及的范圍要小一些，它更多集中在體系結構的某一方面而不是體系結構的整體； – 2）模式在體系結構上施加規(guī)則，描述了軟件是如何在基礎設施層次（例如，并發(fā)）上處理某些功能性方面的問題。連接件表示工作產(chǎn)品之間的關系，特性標識每項的特征。遵照這個模型，系統(tǒng)可以組合 Unix命令、使用管道和 Unix shell控制工具來實現(xiàn)。第三，系統(tǒng)容易維護和擴展：新的過濾器容易加入到系統(tǒng)中，舊的過濾器也可被改進的過濾器替換。 表 63 分層體系結構模式 圖 66 分層系統(tǒng)（分層體系結構） 核 心 層實 用 工 具 層應 用 層用 戶 界 面 層構 件 分層系統(tǒng) ? 每一層向它的上層提供服務，同時它又是下層的客戶。最底層包括了系統(tǒng)支持軟件，比較典型的是數(shù)據(jù)庫和操作系統(tǒng)支持。（最好的例子是 ISO的 OSI模型和 X Window System協(xié)議。在這個例子中，容器或許就是一個能跟蹤軟件變更并允許回滾到先前版本的版本控制環(huán)境。 ? 控制方式的選擇將知識庫風格分成了兩種主要的子類。這個模型的主要組成部分是： – （ 1）一組給其他組件提供服務的服務器。它們是以壓縮的形式存儲的，所以視頻服務器需要對于各種不同的格式處理視頻壓縮和解壓縮。 數(shù)據(jù)抽象和面向?qū)ο蠼M織 ? 但是，面向?qū)ο笙到y(tǒng)最大的缺點是，當一個對象和其他對象交互（過程調(diào)用），它必須知道其他對象的標識。過程可能以一般的方式被調(diào)用，但構件可以將過程注冊到與其相關聯(lián)的系統(tǒng)事件中，這樣，當事件發(fā)生時，過程會被間接調(diào)用。這和傳統(tǒng)的過程調(diào)用驗證不同，當對調(diào)用功能行為進行驗證時，傳統(tǒng)的過程調(diào)用只需考慮過程前和過程后的條件。 過程控制 – ⑦ 閉環(huán)系統(tǒng)：在這種系統(tǒng)中，通過過程變量中的信息調(diào)整過程變量，補償過程變量和操作環(huán)境的變化。 圖 614 主程序 /子程序體系結構 應 用 子 程 序 應 用 子 程 序 應 用 子 程 序應 用 子 程 序 應 用 子 程 序應 用 子 程 序應 用 子 程 序控 制 器 子 程 序 控 制 器 子 程 序控 制 器 子 程 序主 程 序 主程序 /子程序組織 ? 此外，特定領域的軟件體系結構（ Domainspecific Software Architectures）是指為特定領域開發(fā)“參考”模型。一個系統(tǒng)構件被組織成某種體系結構風格，但它的內(nèi)部結構可能是另一種完全不同的風格。盡管這些系統(tǒng)實例在細節(jié)上有所不同，但是當開發(fā)同一類型的新系統(tǒng)時，我們是可以復用通用體系結構架構的。 – 5）作為交流應用類型的詞匯。 圖 615 事務處理應用的體系結構 輸 入 / 輸 出處 理應 用 邏 輯 事 務 管 理 器 數(shù) 據(jù) 庫 事務處理系統(tǒng) ? 事務處理系統(tǒng)可以組織成“管道 過濾器”的結構，分別由系統(tǒng)組件負責輸入、處理和輸出。 – 2）第二層提供用戶接口的功能，這是通過 Web瀏覽器來傳送的。源語言指令定義了將要執(zhí)行的程序，翻譯器會轉(zhuǎn)換這些稱為抽象機指令。因此，系統(tǒng)最好組織成容器的模型，如圖 621所示。在詞法分析、語法和語義分析階段組成一個串行結構，如圖 620所示，它們之間的通信是通過共享符號表實現(xiàn)的。我們最為熟悉的語言處理系統(tǒng)就是編譯器了。這個模型中的層能直接映射到基于因特網(wǎng)系統(tǒng)的服務器上。首先，用戶通過 I/O處理組件向系統(tǒng)發(fā)出請求?？梢苑峙扇蝿战o團隊成員，在同一個體系結構框架下實現(xiàn)不同的組件。因此，這些業(yè)務所使用的應用系統(tǒng)也有很多共同點。而設計模式和應用框架更加面向具體問題。很多系統(tǒng)的主要組織結構反映了所使用的編程語言的特點。 過程控制 ? 過程控制中的一些有用的定義包括： – ① 過程變量：可測的過程屬性：一些具體的過程變量需要被區(qū)分開來； – ② 被控變量：一種過程變量，系統(tǒng)通過控制它的值來達到控制目標； – ③ 輸入變量：一種過程變量，用來測量過程的輸入。另一個問題涉及到數(shù)據(jù)交換。 ? 當一個調(diào)試器停止在一個中斷點上，它會發(fā)布一個事件，這個事件會使系統(tǒng)自動地調(diào)用那些已注冊工具的相應過程。一些系統(tǒng)允許“對象”是并發(fā)的任務；還有一些系統(tǒng)允許對象擁有多個接口。本質(zhì)上，客戶機向服務器提出請求，然后等待直到它收到回答為止。 知識庫（容器） ? 黑板系統(tǒng)通常用在復雜信號處理解釋上，比如語音和模式識別，也被用在其他的系統(tǒng)中，比如通過松散連接代理共享數(shù)據(jù)。 知識庫（容器） ? 以數(shù)據(jù)為中心的體系結構促進了可集成性，也就是說，現(xiàn)有的構件可以被修改，而且新的客戶構件可以加入到體系結構之中，而無需考慮其他的客戶（因為客戶構件是獨立運作的）。因此，這個模型適合于數(shù)據(jù)是由一個組件產(chǎn)生而由其他組件使用的倩形。和管線模式相比，由于分層系統(tǒng)每一層最多和上下兩層交互，對于任意一層的功能的改變最多只影響其他兩層。如果一層的接口被保留下來，這個層就能被另外的一個對等層替換。分層體系結構模式是實現(xiàn)分離性和獨立性的一個方式，表 63和圖 66顯示了這種模式。當系統(tǒng)中每個過濾器作為一個單一實體處理輸入數(shù)據(jù)，即對數(shù)據(jù)的轉(zhuǎn)換是順序進行時，就成了一個退化的管線結構，這時管道 過濾器模式就變成了批處理模型。數(shù)據(jù)從一個處理單元流到另一個處理單元，每經(jīng)過一個單元就做一次變換。與結構相關的特性包括優(yōu)先級、搶先占有以及執(zhí)行時間 ” 。每種風格描述一種系統(tǒng)類別，包括： – l）完成系統(tǒng)需要的某種功能的一組構件（例如，數(shù)據(jù)庫、計算模塊）； – 2）能使構件間實現(xiàn)“通信、合作和協(xié)調(diào)”的一組連接件； – 3）定義構件如何集成為系統(tǒng)的約束； – 4）語義模型，能使設計者通過分析系統(tǒng)組成成分的已知屬性來理解系統(tǒng)的整體性質(zhì)。隨著系統(tǒng)設計人員對詳細的組織原則和某類軟件結構價值的認識不斷加深，這些慣用模式（或稱體系結構模式）被逐漸總結出來。 體系結構類型 ? 可見，游戲系統(tǒng)類型可以用專門設計的強調(diào)游戲系統(tǒng)關注點的體系結構風格來描述。 – 行政管理 ——支持各級政治實體的管理和運作方式的系統(tǒng)。應當開發(fā)出這種視圖，它有益于溝通而不在乎體系結構文檔是否完整。圖 61所描述的打包機器人的體系結構就是概念性系統(tǒng)視圖的一個例子。 第 6章 體系結構的模式與結構 體系結構視圖 ? 在單個體系結構模型中不可能提出所有與系統(tǒng)體系結構相關的信息，因為每一種模型只能顯示系統(tǒng)的一種角度和視圖。 – 2）進程視圖。概念視圖給出系統(tǒng)的本質(zhì)內(nèi)容供不同的信息持有者之間交流。例如，在建筑物類型中，會有房子、單元樓、公寓、辦公樓、工廠廠房、倉庫等一般風格。 – 操作系統(tǒng) ——位于硬件之上提供基本軟件服務的系統(tǒng)。 表 61 MVC（模型 視圖 控制器）模式 體系結構類型 ? 圖 62和圖 63顯示了與 MVC模式相關的體系結構的圖形模型，它們從不同的角度展現(xiàn)體系結構 ——圖 62是概念視圖，而圖 63則給出了當該模式用于基于 Web系統(tǒng)交互管理時的一個可能的體系結構。我們將采用的框架是把某個特定系統(tǒng)的體系結構看成計算構件集，或者簡單地說，由構件再加上描述構件間交互的連接件組成。 – 3）體系結構模式傾向于在體系結構環(huán)境中處理特定的行為問題（例如，實時應用系統(tǒng)如何處理同步和中斷）。 ? 每一種結構表示體系結構的不同視圖，顯示出進行建模和構建時對軟件團隊的有用信息?！斑^濾器”這個詞很形象地描述了數(shù)據(jù)從輸入到輸出這樣一個過程。第四，支持某些特定的分析，如吞吐量和死鎖檢測。在某些分層系統(tǒng)中，內(nèi)層只對其相鄰的層和某些用于輸出的函數(shù)是可見的，對其他外部的層是隱藏的。再上一層是應用程序?qū)?，包括與應用功能相關的組件、可以被其他應用組件利用的實用工具組件等。） 分層系統(tǒng) ? 但是分層系統(tǒng)也有缺點，并不是所有的系統(tǒng)都容易用這種模式來構建。 圖 610 IDE系統(tǒng)的容器體系結構 U M L編 輯 器代 碼生 成 器設 計翻 譯 器J a v a編 輯 器P y t h o n編 輯 器設 計 分 析 器 報 告 生 成 器項 目 容 器 知識庫（容器） ? 把所有適合使用容器的工具組織起來是共享大量數(shù)據(jù)的一種高效方式。如果由輸入流中事務觸發(fā)系統(tǒng)相應的進程執(zhí)行，這是傳統(tǒng)的數(shù)據(jù)庫型知識庫。包括：打印服務器，提供打印服務；文件服務器，提供文檔管理服務；編譯服務器，負責對程序的編譯服務。靜態(tài)圖片必須保持高分辨率，所以將它們單獨放在一個服務器上是比較妥當?shù)摹Ｅc此相反，例如，在管道 過濾器系統(tǒng)中，過濾器之間交互不需要知道系統(tǒng)中其他過濾器的存在。這種模式主要特點是事件發(fā)布者不知道哪些構件會受到事件的影響。 解釋器 ? 一個解釋器包括正在被解釋執(zhí)行的偽碼和解釋引擎本身。 – ⑧ 反饋控制系統(tǒng)：被控變量是可測量的，并且使用測量的結果操作一個或更多的過程變量。這種體系結構提供一種被剪裁成應用程序族的組織結構，比如航空電子技術，命令和控制，汽車駕駛系統(tǒng)。連接件通常也能從層次上分解。應用系統(tǒng)體系結構的一般模型能幫助我們理解應用的運作，比較相同類型的應用，驗證應用系統(tǒng)設計的有效性并能達到對大粒度組件的復用。如果在討論一個特殊的應用或者試圖比較幾個具有相同類型的應用時，可以使用在一般體系結構中所有的概念來談論應用。例如，允許客戶在ATM機上查詢賬戶余額和提取現(xiàn)金的銀行系統(tǒng)。該層包括允許用戶登錄系統(tǒng)的組件和確保他們使用的操作符合他們身份的檢驗組件。這些指令然后由另一個組件解釋，它首先取指令，然后（在必要的時候）再使用來自環(huán)境中的數(shù)據(jù)去執(zhí)行它們。 圖 621 語言處理系統(tǒng)的容器體系結構 抽 象 語 法 樹詞 法 分 析 器 語 法 分 析 器 語 義 分 析 器優(yōu) 化 器語 法 定 義符 號 表 輸 出 定 義容 器代 碼 生 成 器美 編 工 具編 輯 器 語言處理系統(tǒng) ? 圖 621說明了一個語言處理系統(tǒng)是如何成為集成化編程支持工具的一部分的。在編譯器的體系結構中，符號表是共享數(shù)據(jù)容器。它們包括一個翻譯器和一個執(zhí)行生成的語言的抽象機。用戶通信層處理所有來自用戶界面的輸入和輸出，信息檢索層包括應用相關的訪問和更新數(shù)據(jù)庫的邏輯。圖 615給出了事務處理應用的概念體系結構。應用體系結構尋找系統(tǒng)體系結構的穩(wěn)定的結構特征，而且，在很多情況下，是可能并行地開發(fā)這些的。除了一般的業(yè)務功能之外，所有的電話公司都需要系統(tǒng)去連通線路、管理它們的網(wǎng)絡、向客戶開單據(jù)等。體系結構風格描述了軟件系統(tǒng)的整體組織結構，它獨立于實際問題。圖 614描述了該類型的體系結構。尤其是，為了對過程做出調(diào)整，被控變量要與控制系統(tǒng)的某些屬性聯(lián)系起來，這些屬性能夠被控制系統(tǒng)改變（過程變量不能和程序變量混淆）。即使它能夠肯定該事件會被其他構件響應，它也不能依賴事件被處理的先后順序。比如在 Field系統(tǒng)中，諸如編輯器和變量監(jiān)視器等工具會注冊調(diào)試器的中斷點事件。 ? 抽象數(shù)據(jù)類型的使用，以及面向?qū)ο笙到y(tǒng)的使用己經(jīng)非常普遍?？蛻魴C通過遠程過程調(diào)用來獲取服務器提供的服務，遠程過程調(diào)用使用一個請求 回答協(xié)議，比如在 WWW上使用的 協(xié)議。因此實際的控制器或者它的實現(xiàn)可以在知識源中，也可以在黑板中，獨立的模塊中或者在它們的組合中。到底激活哪個工具要視對數(shù)據(jù)的分析結果而定。 知識庫（容器） ? 大多數(shù)使