【正文】 有一個(gè)公共的框架以便對(duì)這些模式進(jìn)行比較。構(gòu)件如客戶機(jī)、服務(wù)器、過濾器、層、數(shù)據(jù)庫等，連接件如過程調(diào)用、事件廣播、數(shù)據(jù)庫協(xié)議和管道等。更明確地說，一個(gè)體系結(jié)構(gòu)風(fēng)格定義了構(gòu)件和連接件類型的符號(hào)集，以及規(guī)定它們?cè)鯓咏M合起來的約束集合。 風(fēng)格與模式 ? 利用這個(gè)框架，我們可以通過回答下面的問題以確定體系結(jié)構(gòu)風(fēng)格，即： – 設(shè)計(jì)符號(hào)集，即構(gòu)件和連接件的類型是什么？ – 被認(rèn)可的結(jié)構(gòu)模式是什么？ – 根本的計(jì)算模型是什么？ – 最基本的特點(diǎn)是什么？ – 使用這種風(fēng)格的通用例子有哪些？ – 使用這種風(fēng)格有什么優(yōu)點(diǎn)和缺點(diǎn)？ – 通用的規(guī)格說明是什么？ 風(fēng)格與模式 ? 例如，當(dāng)建筑師用“小高層”來描述某座房子時(shí)，大多數(shù)人將能夠獲得對(duì)房子的整體畫面，對(duì)建筑主平面圖可能像什么樣子也會(huì)有所了解。但更重要的是，體系結(jié)構(gòu)風(fēng)格也是建筑的樣板。實(shí)際上是建筑風(fēng)格 ——“小高層” ——指導(dǎo)了建筑師的工作。每種風(fēng)格描述一種系統(tǒng)類別，包括： – l）完成系統(tǒng)需要的某種功能的一組構(gòu)件（例如，數(shù)據(jù)庫、計(jì)算模塊）； – 2）能使構(gòu)件間實(shí)現(xiàn)“通信、合作和協(xié)調(diào)”的一組連接件； – 3）定義構(gòu)件如何集成為系統(tǒng)的約束； – 4）語義模型，能使設(shè)計(jì)者通過分析系統(tǒng)組成成分的已知屬性來理解系統(tǒng)的整體性質(zhì)。在對(duì)已有體系結(jié)構(gòu)再工程時(shí)，一種體系結(jié)構(gòu)風(fēng)格的強(qiáng)制采用會(huì)導(dǎo)致軟件結(jié)構(gòu)的根本性改變，包括對(duì)構(gòu)件功能的再分配。然而，體系結(jié)構(gòu)模式與體系結(jié)構(gòu)風(fēng)格在許多基本方面存在不同： – l）模式涉及的范圍要小一些，它更多集中在體系結(jié)構(gòu)的某一方面而不是體系結(jié)構(gòu)的整體； – 2）模式在體系結(jié)構(gòu)上施加規(guī)則，描述了軟件是如何在基礎(chǔ)設(shè)施層次（例如，并發(fā)）上處理某些功能性方面的問題。 – 模式可以與體系結(jié)構(gòu)風(fēng)格結(jié)合起來建立整個(gè)系統(tǒng)結(jié)構(gòu)的外形。無論是構(gòu)件還是連接件，它們都與一組特性相關(guān)，這組特性使設(shè)計(jì)者能夠區(qū)別所使用的構(gòu)件和連接件的類型。特性描述構(gòu)件的特征和接口的組織。連接件包括傳遞數(shù)據(jù)和控制、共享數(shù)據(jù)、 “ 使用 ” 以及 “ 是一個(gè)實(shí)例 ” 等能力。 – 并發(fā)結(jié)構(gòu)：構(gòu)件表示 “ 并發(fā)單元 ” ，這些 “ 并發(fā)單元 ” 被組織為并行任務(wù)或線程。與結(jié)構(gòu)相關(guān)的特性包括優(yōu)先級(jí)、搶先占有以及執(zhí)行時(shí)間 ” 。連接件是硬件構(gòu)件之間的接口，特性用來描述容量、帶寬、性能和其他屬性。連接件表示工作產(chǎn)品之間的關(guān)系，特性標(biāo)識(shí)每項(xiàng)的特征。 組織和求精 ? 由于設(shè)計(jì)過程經(jīng)常會(huì)留下許多種可供選擇的體系結(jié)構(gòu)方案，因此建立一組用于評(píng)估所導(dǎo)出的體系結(jié)構(gòu)設(shè)計(jì)的設(shè)計(jì)標(biāo)準(zhǔn)是非常重要的。在體系結(jié)構(gòu)中如何管理控制？是否存在清楚的控制層次？如果存在，構(gòu)件在控制層次中有什么作用？構(gòu)件如何在系統(tǒng)中傳遞控制？構(gòu)件間如何共享控制？控制的拓?fù)浣Y(jié)構(gòu)（即控制呈現(xiàn)的幾何形狀）如何？控制是否同步或者構(gòu)件操作是否異步？ 組織和求精 – 數(shù)據(jù)。 典型的體系結(jié)構(gòu)模式 ? 盡管在過去的幾十年中人們已經(jīng)創(chuàng)建了眾多的計(jì)算機(jī)系統(tǒng)，但其中絕大多數(shù)都可以歸為少數(shù)幾種體系結(jié)構(gòu)風(fēng)格之一。 典型的體系結(jié)構(gòu)模式 ? 這些體系結(jié)構(gòu)風(fēng)格也僅僅是可用風(fēng)格中的一小部分。在很多情況下，會(huì)有多種模式是適合的，需要對(duì)可選的體系結(jié)構(gòu)風(fēng)格進(jìn)行設(shè)計(jì)和評(píng)估。數(shù)據(jù)從一個(gè)處理單元流到另一個(gè)處理單元，每經(jīng)過一個(gè)單元就做一次變換。這些轉(zhuǎn)換可能順序地或并行地執(zhí)行，數(shù)據(jù)加工可以是一項(xiàng)一項(xiàng)地處理，也可以成批處理。遵照這個(gè)模型，系統(tǒng)可以組合 Unix命令、使用管道和 Unix shell控制工具來實(shí)現(xiàn)。 管道 過濾器 ? 管道 過濾器模式又稱數(shù)據(jù)流體系結(jié)構(gòu)。管道 過濾器模式擁有一組稱為過濾器（ Filter）的構(gòu)件，每個(gè)構(gòu)件都有一組輸入集和輸出集。 管道 過濾器 ? 構(gòu)件對(duì)輸入流進(jìn)行內(nèi)部轉(zhuǎn)換和增量計(jì)算，因此在輸入數(shù)據(jù)流被全部處理之前，輸出就已經(jīng)開始了。然而，過濾器沒有必要了解與之相鄰的過濾器的工作。 管道 過濾器 ? 另一個(gè)著名的管線系統(tǒng)例子是傳統(tǒng)編譯器，在這個(gè)管線系統(tǒng)中包括詞法分析、句法分析、語義分析、代碼生成階段。當(dāng)系統(tǒng)中每個(gè)過濾器作為一個(gè)單一實(shí)體處理輸入數(shù)據(jù)，即對(duì)數(shù)據(jù)的轉(zhuǎn)換是順序進(jìn)行時(shí)，就成了一個(gè)退化的管線結(jié)構(gòu)，這時(shí)管道 過濾器模式就變成了批處理模型。首先，設(shè)計(jì)者可以將整個(gè)系統(tǒng)的輸入、輸出特性理解為各個(gè)過濾器功能的簡單合成。第三，系統(tǒng)容易維護(hù)和擴(kuò)展：新的過濾器容易加入到系統(tǒng)中，舊的過濾器也可被改進(jìn)的過濾器替換。最后，它具有天然的并發(fā)特性，每一個(gè)過濾器既可以獨(dú)立的運(yùn)行，也可以和其他過濾器并發(fā)執(zhí)行。首先，這種系統(tǒng)往往導(dǎo)致處理過程的成批操作。此外，由于過濾器的傳輸特性，管道 過濾器模式通常不適合于交互性很強(qiáng)的應(yīng)用。 管道 過濾器 ? 第二，維持兩個(gè)相對(duì)獨(dú)立但又存在某種關(guān)系的數(shù)據(jù)流之間的通信可能很困難。這樣，降低了系統(tǒng)的效率，同時(shí)增加了編寫過濾器本身的復(fù)雜性。分層體系結(jié)構(gòu)模式是實(shí)現(xiàn)分離性和獨(dú)立性的一個(gè)方式，表 63和圖 66顯示了這種模式。定義的一系列不同層次各自完成其自身的操作，這些操作逐漸接近機(jī)器的指令集。 表 63 分層體系結(jié)構(gòu)模式 圖 66 分層系統(tǒng)（分層體系結(jié)構(gòu)） 核 心 層實(shí) 用 工 具 層應(yīng) 用 層用 戶 界 面 層構(gòu) 件 分層系統(tǒng) ? 每一層向它的上層提供服務(wù)，同時(shí)它又是下層的客戶。在這些系統(tǒng)中，構(gòu)件在某些層中實(shí)現(xiàn)虛擬機(jī)。）連接件通過協(xié)議來定義，而協(xié)議規(guī)定了層次之間交互的方式，還限制了相鄰層間的交互。在這個(gè)應(yīng)用中，在某種抽象程度上，每一層向其他層提供通訊基礎(chǔ)。其他的應(yīng)用領(lǐng)域包括數(shù)據(jù)庫系統(tǒng)和操作系統(tǒng)。如一個(gè)層被開發(fā)完，該層提供的服務(wù)就可以被用戶使用了。如果一層的接口被保留下來，這個(gè)層就能被另外的一個(gè)對(duì)等層替換。因?yàn)榉謱酉到y(tǒng)的抽象機(jī)依賴的是內(nèi)層中的抽象機(jī)，因此，轉(zhuǎn)換到其他機(jī)器上實(shí)現(xiàn)是比較容易的，此時(shí)只有內(nèi)部與具體機(jī)器相關(guān)的層需要重新實(shí)現(xiàn)以適應(yīng)不同的操作系統(tǒng)或數(shù)據(jù)庫。最底層包括了系統(tǒng)支持軟件，比較典型的是數(shù)據(jù)庫和操作系統(tǒng)支持。第三層與用戶界面管理相關(guān)，并提供用戶的身份驗(yàn)證和授權(quán)。當(dāng)然，分層的數(shù)量是隨意的。 圖 67 通用分層體系結(jié)構(gòu) 系 統(tǒng) 支 持 （ 操 作 系 統(tǒng) 、 數(shù) 據(jù) 庫 等 ）核 心 業(yè) 務(wù) 邏 輯 / 應(yīng) 用 領(lǐng) 域系 統(tǒng) 實(shí) 用 程 序用 戶 界 面 管 理身 份 驗(yàn) 證 和 授 權(quán)用 戶 界 面 分層系統(tǒng) ? 圖 68是分層體系結(jié)構(gòu)模式應(yīng)用于一個(gè)叫做 LIBSYS的圖書館系統(tǒng)的示例，能夠控制對(duì)一組大學(xué)圖書館中版權(quán)資料的電子訪問。 圖 68 LIBSYS系統(tǒng)的體系結(jié)構(gòu) 圖 書 館 索 引 分 布 式 文 檔 版 權(quán) 記 賬 搜 索 恢 復(fù) 管 理 器 L I B S Y S 表 單 和 查 詢 打 印 系 統(tǒng) 登 錄 管 理 器 管 理 器W e b 瀏 覽 器 界 面數(shù) 據(jù)庫 1數(shù) 據(jù)庫 2數(shù) 據(jù)庫 3數(shù) 據(jù)庫 4數(shù) 據(jù)庫 n. . . 分層系統(tǒng) ? 分層系統(tǒng)有許多理想的性質(zhì)。這就允許設(shè)計(jì)者將一個(gè)復(fù)雜的問題分解成一系列遞增的步驟。和管線模式相比，由于分層系統(tǒng)每一層最多和上下兩層交互，對(duì)于任意一層的功能的改變最多只影響其他兩層。像抽象數(shù)據(jù)類型一樣，假如能夠保證為相鄰的層提供一致的接口，它允許系統(tǒng)中同一層的不同實(shí)現(xiàn)相互交換使用。（最好的例子是 ISO的 OSI模型和 X Window System協(xié)議。而且即使一個(gè)系統(tǒng)能夠從邏輯上被構(gòu)建成層次結(jié)構(gòu)，出于對(duì)性能的考慮，也需要將邏輯上高層次的功能和相對(duì)低層次的實(shí)現(xiàn)結(jié)合起來。特別是對(duì)于標(biāo)準(zhǔn)化的層次模型來說，尤其如此。 知識(shí)庫（容器） ? 知識(shí)庫（ Repositories）模式又稱容器（ Repository）模式（見表 64），是以數(shù)據(jù)為中心的體系結(jié)構(gòu)。圖 69描述了一種典型的以數(shù)據(jù)為中心的體系結(jié)構(gòu)風(fēng)格，其中，客戶軟件訪問中心存儲(chǔ)庫。該方法的一個(gè)變種是將中心存儲(chǔ)庫變換成“黑板”，當(dāng)客戶感興趣的數(shù)據(jù)發(fā)生變化時(shí)，它將通知客戶軟件。因此，這個(gè)模型適合于數(shù)據(jù)是由一個(gè)組件產(chǎn)生而由其他組件使用的倩形。 ? 圖 610說明了一個(gè)可能會(huì)用到容器的情形。在這個(gè)例子中，容器或許就是一個(gè)能跟蹤軟件變更并允許回滾到先前版本的版本控制環(huán)境。這就不需要顯式地把數(shù)據(jù)從一個(gè)組件傳送到另一個(gè)組件。這不可避免地要在每個(gè)工具的特定需求之間做出妥協(xié)。實(shí)際上，將容器分布到多臺(tái)機(jī)器上可能是困難的。 知識(shí)庫（容器） ? 如圖 610中所示，容器是被動(dòng)的，對(duì)它的控制是組件的職責(zé)。在容器數(shù)據(jù)的結(jié)構(gòu)組織得不是很好的時(shí)候，這個(gè)方法比較合適。 知識(shí)庫（容器） ? 以數(shù)據(jù)為中心的體系結(jié)構(gòu)促進(jìn)了可集成性，也就是說，現(xiàn)有的構(gòu)件可以被修改，而且新的客戶構(gòu)件可以加入到體系結(jié)構(gòu)之中，而無需考慮其他的客戶（因?yàn)榭蛻魳?gòu)件是獨(dú)立運(yùn)作的）。 知識(shí)庫（容器） ? 通常知識(shí)庫模式中有兩個(gè)截然不同的功能構(gòu)件：一個(gè)是中央數(shù)據(jù)結(jié)構(gòu)構(gòu)件，代表系統(tǒng)當(dāng)前狀態(tài)；另一個(gè)是一些相對(duì)獨(dú)立的構(gòu)件的集合，這些構(gòu)件對(duì)中央數(shù)據(jù)存儲(chǔ)進(jìn)行操作。 ? 控制方式的選擇將知識(shí)庫風(fēng)格分成了兩種主要的子類。另一方面，如果由中心數(shù)據(jù)結(jié)構(gòu)的當(dāng)前狀態(tài)觸發(fā)系統(tǒng)相應(yīng)的進(jìn)程執(zhí)行，稱為黑板知識(shí)庫。 圖 611 黑板體系結(jié)構(gòu) 知 識(shí) 源 4知 識(shí) 源 3知 識(shí) 源 2知 識(shí) 源 1知 識(shí) 源 5知 識(shí) 源 6知 識(shí) 源 8黑 板（ 共 享 數(shù) 據(jù) ）知 識(shí) 源 7直 接 存 取計(jì) 算存 儲(chǔ) 器 知識(shí)庫（容器） ? 黑板模型通常由三個(gè)部分組成： – l）知識(shí)源：分離的，獨(dú)立的，依賴于應(yīng)用的知識(shí)包。 – 2）黑板數(shù)據(jù)結(jié)構(gòu)：問題求解狀態(tài)數(shù)據(jù)，被組織成依賴于應(yīng)用的層次結(jié)構(gòu)。 – 3）控制器：完全由黑板的狀態(tài)驅(qū)動(dòng)。 ? 圖 611并沒有顯式地表示出控制構(gòu)件，因?yàn)橹R(shí)源的調(diào)用是通過黑板的狀態(tài)激活的。 知識(shí)庫（容器） ? 黑板系統(tǒng)通常用在復(fù)雜信號(hào)處理解釋上，比如語音和模式識(shí)別，也被用在其他的系統(tǒng)中，比如通過松散連接代理共享數(shù)據(jù)。表 65描述了客戶機(jī) 服務(wù)器模式。這個(gè)模型的主要組成部分是： – （ 1）一組給其他組件提供服務(wù)的服務(wù)器。 – （ 2）一組向服務(wù)器請(qǐng)求服務(wù)的客戶機(jī)。 – （ 3）一個(gè)連接客戶機(jī)和服務(wù)器的網(wǎng)絡(luò)。 客戶機(jī) 服務(wù)器 ? 客戶機(jī) 服務(wù)器體系結(jié)構(gòu)經(jīng)常被認(rèn)為是分布式系統(tǒng)體系結(jié)構(gòu)，但是運(yùn)行在分散服務(wù)器上的獨(dú)立服務(wù)的邏輯模型可以在單個(gè)計(jì)算機(jī)上實(shí)現(xiàn)。服務(wù)和服務(wù)器可以改變而不會(huì)影響系統(tǒng)其他部分。反之，服務(wù)器沒有必要知道客戶機(jī)的身份以及到底有多少客戶機(jī)在訪問它們的服務(wù)。本質(zhì)上，客戶機(jī)向服務(wù)器提出請(qǐng)求，然后等待直到它收到回答為止。在這個(gè)系統(tǒng)中，有管理和放映不同類型媒體的多個(gè)服務(wù)器。它們是以壓縮的形式存儲(chǔ)的，所以視頻服務(wù)器需要對(duì)于各種不同的格式處理視頻壓縮和解壓縮。 客戶機(jī) 服務(wù)器 ? 要求目錄能夠支持各種查詢，能與包含電影和視頻片段的Web信息系統(tǒng)鏈接，并能與支持發(fā)售圖片、電影和視頻片段的電子商務(wù)系統(tǒng)保持鏈接。 數(shù)據(jù)抽象和面向?qū)ο蠼M織 ? 在基于數(shù)據(jù)抽象和面向?qū)ο蠼M織結(jié)構(gòu)（ Data Abstraction and ObjectOriented Organization）模式中，數(shù)據(jù)表示和相關(guān)的基本操作封裝在抽象數(shù)據(jù)類型或?qū)ο笾?。這種模式有兩個(gè)重要的方面： – ① 對(duì)象維護(hù)自身表示的完整性（通常是通過保持其