【正文】 及規(guī)定它們?cè)鯓咏M合起來(lái)的約束集合。 風(fēng)格與模式 ? 從更詳細(xì)的層面上，為了分清不同模式間的差異，需要有一個(gè)公共的框架以便對(duì)這些模式進(jìn)行比較。隨著系統(tǒng)設(shè)計(jì)人員對(duì)詳細(xì)的組織原則和某類軟件結(jié)構(gòu)價(jià)值的認(rèn)識(shí)不斷加深，這些慣用模式（或稱體系結(jié)構(gòu)模式）被逐漸總結(jié)出來(lái)。可以把體系結(jié)構(gòu)模式看作是對(duì)好的實(shí)踐所做的格式化的抽象描述，它們已經(jīng)在不同的系統(tǒng)和環(huán)境中多次嘗試和測(cè)試過(guò)。 風(fēng)格與模式 ? 體系結(jié)構(gòu)風(fēng)格（ Architecture styles）強(qiáng)調(diào)組織模式，是描述特定系統(tǒng)組織方式的慣用范例。此外，還應(yīng)該包括這種模式的應(yīng)用時(shí)機(jī)和優(yōu)缺點(diǎn)。 體系結(jié)構(gòu)類型 ? 可見(jiàn)，游戲系統(tǒng)類型可以用專門(mén)設(shè)計(jì)的強(qiáng)調(diào)游戲系統(tǒng)關(guān)注點(diǎn)的體系結(jié)構(gòu)風(fēng)格來(lái)描述。考慮一個(gè)游戲系統(tǒng)的軟件體系結(jié)構(gòu)，游戲系統(tǒng)有時(shí)被稱作沉浸式交互應(yīng)用（ immersive interactive application) ，它需要密集型算法的計(jì)算方法、成熟的計(jì)算機(jī)圖形圖像技術(shù)、流媒體數(shù)據(jù)源、通過(guò)常規(guī)或非常規(guī)輸入進(jìn)行的實(shí)時(shí)的交互操作以及許多其他專業(yè)知識(shí)。 – 工具 ——用來(lái)開(kāi)發(fā)其他系統(tǒng)的系統(tǒng)。 – 軍事 ——用于商議、通信、指揮、控制和信息的系統(tǒng)，也有用于進(jìn)攻和防衛(wèi)武器的系統(tǒng)。 – 行政管理 ——支持各級(jí)政治實(shí)體的管理和運(yùn)作方式的系統(tǒng)。 – 設(shè)備 ——與物理世界交互的系統(tǒng)，可以為個(gè)人提供某種有意義的服務(wù)。 體系結(jié)構(gòu)類型 ? 例如，可以有以下幾種軟件系統(tǒng)的體系結(jié)構(gòu)類型： – 人工智能 ——模擬或擴(kuò)大人類認(rèn)知、運(yùn)動(dòng)或其他有機(jī)體過(guò)程的系統(tǒng)。在每種類別中，會(huì)有很多的子類別。應(yīng)當(dāng)開(kāi)發(fā)出這種視圖，它有益于溝通而不在乎體系結(jié)構(gòu)文檔是否完整。不過(guò)，由于它的專業(yè)性，領(lǐng)域和應(yīng)用專家很難理解和使用ADL。設(shè)計(jì) UML是為了描述面向?qū)ο笙到y(tǒng)，在體系結(jié)構(gòu)設(shè)計(jì)階段，我們常常要以更高層次的抽象化來(lái)描述系統(tǒng)。 體系結(jié)構(gòu)視圖 ? 實(shí)際上，在設(shè)計(jì)過(guò)程中通常都會(huì)形成概念視圖，它對(duì)體系結(jié)構(gòu)的決策很有幫助。圖 61所描述的打包機(jī)器人的體系結(jié)構(gòu)就是概念性系統(tǒng)視圖的一個(gè)例子。顯示了系統(tǒng)硬件和系統(tǒng)中軟件組件是如何分布在處理器上的。 – 3）開(kāi)發(fā)視圖。通過(guò)邏輯視圖，可以將系統(tǒng)需求和實(shí)體關(guān)聯(lián)起來(lái)。 第 6章 體系結(jié)構(gòu)的模式與結(jié)構(gòu) 體系結(jié)構(gòu)視圖 ? 在單個(gè)體系結(jié)構(gòu)模型中不可能提出所有與系統(tǒng)體系結(jié)構(gòu)相關(guān)的信息，因?yàn)槊恳环N模型只能顯示系統(tǒng)的一種角度和視圖。一個(gè)設(shè)計(jì)良好的通用模式是工程領(lǐng)域中技術(shù)成熟的標(biāo)志之一。 第 6章 體系結(jié)構(gòu)的模式與結(jié)構(gòu) ? 軟件體系結(jié)構(gòu)是有關(guān)軟件系統(tǒng)如何組織的描述。通常體系結(jié)構(gòu)可能會(huì)從許多不同的視角和視圖被文檔化，我們需要提供系統(tǒng)體系結(jié)構(gòu)的多重視圖。 – 2）進(jìn)程視圖。顯示了軟件是如何為了開(kāi)發(fā)而被分解的，即將軟件分解成可以由單獨(dú)的開(kāi)發(fā)人員或開(kāi)發(fā)團(tuán)隊(duì)實(shí)現(xiàn)的組件。這種視圖對(duì)系統(tǒng)工程師規(guī)劃系統(tǒng)部署非常有用。該圖顯示了一個(gè)打包機(jī)器人系統(tǒng)體系結(jié)構(gòu)的抽象模型，描述了所要開(kāi)發(fā)的子系統(tǒng)。概念視圖給出系統(tǒng)的本質(zhì)內(nèi)容供不同的信息持有者之間交流。當(dāng)需要詳細(xì)地文檔化一個(gè)體系結(jié)構(gòu)或使用模型驅(qū)動(dòng)開(kāi)發(fā)的時(shí)候， UML是非常有價(jià)值的。 ADL語(yǔ)言是為特定領(lǐng)域設(shè)計(jì)的（例如，汽車(chē)系統(tǒng)），或許可以作為模型驅(qū)動(dòng)開(kāi)發(fā)的基礎(chǔ)。不過(guò)，例外的情況是，當(dāng)正在開(kāi)發(fā)關(guān)鍵性系統(tǒng)，當(dāng)需要做一個(gè)詳細(xì)的系統(tǒng)可依賴性分析時(shí)，或許需要使外部的管理者確定我們的系統(tǒng)符合他們的規(guī)則而且可能會(huì)需要完整的體系結(jié)構(gòu)文檔。例如，在建筑物類型中，會(huì)有房子、單元樓、公寓、辦公樓、工廠廠房、倉(cāng)庫(kù)等一般風(fēng)格。 – 商業(yè)和非盈利的 ——工商企業(yè)營(yíng)運(yùn)必要的系統(tǒng)。 – 娛樂(lè)與運(yùn)動(dòng) ——管理公眾事件或者提供大眾娛樂(lè)體驗(yàn)的系統(tǒng)。 – 工業(yè) ——模擬或控制物理過(guò)程的系統(tǒng)。 – 操作系統(tǒng) ——位于硬件之上提供基本軟件服務(wù)的系統(tǒng)。 – 運(yùn)輸 ——控制水上、地面、空中或者太空交通工具的系統(tǒng)。 體系結(jié)構(gòu)類型 ? 例如，一種可應(yīng)用于游戲環(huán)境的 immersipresence軟件體系結(jié)構(gòu)描述如下： – immersipresence軟件體系結(jié)構(gòu)（ Software Architecture for Immersipresence, SAI）是一種新的體系結(jié)構(gòu)模型，用于設(shè)計(jì)、分析和實(shí)現(xiàn)執(zhí)行一般數(shù)據(jù)流的分布式、異步并行處理的應(yīng)用系統(tǒng)。 ? 表 61描述了 MVC（模型 視圖 控制器）模式。 表 61 MVC（模型 視圖 控制器）模式 體系結(jié)構(gòu)類型 ? 圖 62和圖 63顯示了與 MVC模式相關(guān)的體系結(jié)構(gòu)的圖形模型，它們從不同的角度展現(xiàn)體系結(jié)構(gòu) ——圖 62是概念視圖，而圖 63則給出了當(dāng)該模式用于基于 Web系統(tǒng)交互管理時(shí)的一個(gè)可能的體系結(jié)構(gòu)。組織模式即靜態(tài)表述的樣例，慣用范例則是反映眾多系統(tǒng)共有的結(jié)構(gòu)和語(yǔ)義。所以，體系結(jié)構(gòu)模式應(yīng)當(dāng)描述一種系統(tǒng)構(gòu)成，這種構(gòu)成在以往的系統(tǒng)中是很成功的。通過(guò)熟悉一些體系結(jié)構(gòu)風(fēng)格，可以了解軟件體系結(jié)構(gòu)豐富的選擇空間以及在這個(gè)基礎(chǔ)上對(duì)風(fēng)格選擇的一些權(quán)衡。我們將采用的框架是把某個(gè)特定系統(tǒng)的體系結(jié)構(gòu)看成計(jì)算構(gòu)件集，或者簡(jiǎn)單地說(shuō)，由構(gòu)件再加上描述構(gòu)件間交互的連接件組成。對(duì)于很多風(fēng)格來(lái)說(shuō)，也可能存在一個(gè)或多個(gè)語(yǔ)義模型，其中規(guī)定了怎樣從系統(tǒng)的各部分屬性來(lái)確定系統(tǒng)的總體屬性。必須進(jìn)一步規(guī)定房子的細(xì)節(jié)，具體說(shuō)明它的最終尺寸，進(jìn)一步給出定制的特征，確定建筑材料等。 風(fēng)格與模式 ? 一種體系結(jié)構(gòu)風(fēng)格就是施加在整個(gè)系統(tǒng)設(shè)計(jì)上的一種變換，目的是為系統(tǒng)的所有構(gòu)件建立一個(gè)結(jié)構(gòu)。 – 3）體系結(jié)構(gòu)模式傾向于在體系結(jié)構(gòu)環(huán)境中處理特定的行為問(wèn)題（例如，實(shí)時(shí)應(yīng)用系統(tǒng)如何處理同步和中斷）。 基本體系結(jié)構(gòu) ? 5種典型的基本體系結(jié)構(gòu)（構(gòu)件、連接件和特性）是： – 功能結(jié)構(gòu)：構(gòu)件表示功能或處理實(shí)體，連接件表示接口，它提供“ 使用 ” 構(gòu)件或 “ 傳遞數(shù)據(jù)到 ” 構(gòu)件的功能。特性關(guān)注于結(jié)構(gòu)實(shí)現(xiàn)時(shí)的質(zhì)量特征（例如，可維護(hù)性、可重用性）。 基本體系結(jié)構(gòu) – 物理結(jié)構(gòu)：物理結(jié)構(gòu)類似于設(shè)計(jì)開(kāi)發(fā)中的部署模型，構(gòu)件是物理硬件，軟件駐留在硬件、上。 ? 每一種結(jié)構(gòu)表示體系結(jié)構(gòu)的不同視圖，顯示出進(jìn)行建模和構(gòu)建時(shí)對(duì)軟件團(tuán)隊(duì)的有用信息。構(gòu)件間如何進(jìn)行數(shù)據(jù)通信？數(shù)據(jù)流是否是連續(xù)地傳遞給系統(tǒng)，或數(shù)據(jù)對(duì)象是否是零散地傳遞給系統(tǒng)？數(shù)據(jù)傳遞的模式是什么（即，數(shù)據(jù)是從一個(gè)構(gòu)件傳遞到另一個(gè)構(gòu)件，還是數(shù)據(jù)被系統(tǒng)中的構(gòu)件全局共享）？是否存在數(shù)據(jù)構(gòu)件（如黑板或中心存儲(chǔ)庫(kù)）？如果存在，它們的作用是什么？功能構(gòu)件如何和數(shù)據(jù)構(gòu)件交互？數(shù)據(jù)構(gòu)件是被動(dòng)的還是主動(dòng)的（即數(shù)據(jù)構(gòu)件是否主動(dòng)地和系統(tǒng)的其他構(gòu)件交互）？數(shù)據(jù)和控制如何在系統(tǒng)中交互？ ? 這些問(wèn)題有助于設(shè)計(jì)者對(duì)設(shè)計(jì)質(zhì)量進(jìn)行早期評(píng)估，也為更詳細(xì)地分析體系結(jié)構(gòu)奠定了基礎(chǔ)。一旦需求工程揭示了待構(gòu)建系統(tǒng)的特征和約束，就可以選擇最適合這些特征和約束的體系結(jié)構(gòu)風(fēng)格和（或）風(fēng)格的組合。輸入數(shù)據(jù)流經(jīng)過(guò)這些變換直到轉(zhuǎn)換為輸出?！斑^(guò)濾器”這個(gè)詞很形象地描述了數(shù)據(jù)從輸入到輸出這樣一個(gè)過(guò)程。這些構(gòu)件從輸入源讀入數(shù)據(jù)流，通過(guò)管道（ Pipe）連接，管道將數(shù)據(jù)從一個(gè)構(gòu)件傳送到下一個(gè)構(gòu)件，并在輸出池產(chǎn)生輸出數(shù)據(jù)流。 ? 管道 過(guò)濾器的通用結(jié)構(gòu)如管線（ Pipelines），限制系統(tǒng)的拓?fù)浣Y(jié)構(gòu)只能是過(guò)濾器的線性序列；有界管道（ Bounded Pipes）限制了在管道中能容納的數(shù)據(jù)量；類型定義管道（ Typed Pipes）要求明確定義在兩個(gè)過(guò)濾器間傳輸?shù)臄?shù)據(jù)類型。 管道 過(guò)濾器 ? 管道 過(guò)濾器系統(tǒng)有很多優(yōu)點(diǎn)。第四，支持某些特定的分析，如吞吐量和死鎖檢測(cè)。雖然系統(tǒng)中的過(guò)濾器對(duì)數(shù)據(jù)采取增量的方式，但過(guò)濾器的獨(dú)立性很強(qiáng)，這樣設(shè)計(jì)者必須考慮每個(gè)過(guò)濾器完成從輸入到輸出的完整轉(zhuǎn)換。 ? 第三，根據(jù)實(shí)際應(yīng)用的要求，設(shè)計(jì)者也需要在數(shù)據(jù)傳輸時(shí)被迫使用底層公共命名，導(dǎo)致過(guò)濾器必須對(duì)輸入、輸出管道中的數(shù)據(jù)進(jìn)行解析或反解析的額外工作。這里，一個(gè)分層系統(tǒng)（ Layered Systems）按照層次結(jié)構(gòu)組織，系統(tǒng)的功能被劃分成幾個(gè)獨(dú)立的層次，每一層只依賴緊接的下一層所提供的服務(wù)和設(shè)施。在某些分層系統(tǒng)中，內(nèi)層只對(duì)其相鄰的層和某些用于輸出的函數(shù)是可見(jiàn)的，對(duì)其他外部的層是隱藏的。 分層系統(tǒng) ? 這種體系結(jié)構(gòu)模式最著名的例子就是分層通信協(xié)議。 分層系統(tǒng) ? 分層的方法支持系統(tǒng)的增量式開(kāi)發(fā)。當(dāng)一層的接口改變或增加了新設(shè)施的時(shí)候，只有毗鄰的層受影響。再上一層是應(yīng)用程序?qū)?，包括與應(yīng)用功能相關(guān)的組件、可以被其他應(yīng)用組件利用的實(shí)用工具組件等。圖 67中的任何一層都可以分為兩層或更多層。首先，它支持基于逐級(jí)抽象的系統(tǒng)設(shè)計(jì)。第三，它支持重用。） 分層系統(tǒng) ? 但是分層系統(tǒng)也有缺點(diǎn)，并不是所有的系統(tǒng)都容易用這種模式來(lái)構(gòu)建。比如，實(shí)際的通信協(xié)議體就很難映射到OSI框架中，因?yàn)槠渲性S多協(xié)議跨多個(gè)層。在某些情況下，數(shù)據(jù)存儲(chǔ)庫(kù)是被動(dòng)的，也就是說(shuō)，客戶軟件獨(dú)立于數(shù)據(jù)的任何變化或其他客戶軟件的動(dòng)作而訪問(wèn)數(shù)據(jù)。這種類型的系統(tǒng)例子包括指揮和控制系統(tǒng)、管理信息系統(tǒng)、 CAD系統(tǒng)和軟件的交互開(kāi)發(fā)環(huán)境等。 圖 610 IDE系統(tǒng)的容器體系結(jié)構(gòu) U M L編 輯 器代 碼生 成 器設(shè) 計(jì)翻 譯 器J a v a編 輯 器P y t h o n編 輯 器設(shè) 計(jì) 分 析 器 報(bào) 告 生 成 器項(xiàng) 目 容 器 知識(shí)庫(kù)（容器） ? 把所有適合使用容器的工具組織起來(lái)是共享大量數(shù)據(jù)的一種高效方式。若一個(gè)新組件的數(shù)據(jù)模型與該模型有沖突，那么要想將它集成到該系統(tǒng)中來(lái)就可能很困難。另外一種方法源于人工智能，即使用所謂的“黑板”模型，當(dāng)有特別的數(shù)據(jù)可用時(shí)，就會(huì)主動(dòng)通報(bào)組件。另外，數(shù)據(jù)可以在客戶間通過(guò)“黑板”機(jī)制傳送（即黑板構(gòu)件負(fù)責(zé)協(xié)調(diào)信息在客戶間的傳遞），客戶構(gòu)件獨(dú)立地執(zhí)行過(guò)程。如果由輸入流中事務(wù)觸發(fā)系統(tǒng)相應(yīng)的進(jìn)程執(zhí)行，這是傳統(tǒng)的數(shù)據(jù)庫(kù)型知識(shí)庫(kù)。知識(shí)源僅通過(guò)黑板進(jìn)行交互。一旦黑板的狀態(tài)使某個(gè)知識(shí)源可用，知識(shí)源就會(huì)適時(shí)地響應(yīng)。 客戶機(jī) 服務(wù)器 ? 容器模式與系統(tǒng)的靜態(tài)結(jié)構(gòu)有關(guān)，但是不能展現(xiàn)出它的運(yùn)行組織。包括：打印服務(wù)器，提供打印服務(wù)；文件服務(wù)器，提供文檔管理服務(wù)；編譯服務(wù)器，負(fù)責(zé)對(duì)程序的編譯服務(wù)。絕大多數(shù)客戶機(jī) 服務(wù)器系統(tǒng)實(shí)現(xiàn)為分布式系統(tǒng)，通過(guò)互聯(lián)網(wǎng)的協(xié)議連接在一起。 客戶機(jī) 服務(wù)器 ? 客戶機(jī)必須知道可用的服務(wù)器的名字及它們所提供的服務(wù)。 客戶機(jī) 服務(wù)器 ? 圖 612所示是一個(gè)基于 Web的提供電影和圖片庫(kù)的多用戶系統(tǒng)。靜態(tài)圖片必須保持高分辨率，所以將它們單獨(dú)放在一個(gè)服務(wù)器上是比較妥當(dāng)?shù)?。這種模式的構(gòu)件是對(duì)象（封裝了數(shù)據(jù)和必須用于控制該數(shù)據(jù)的操作），或者也可稱為抽象數(shù)據(jù)類型的實(shí)例，構(gòu)件間通過(guò)信息傳遞進(jìn)行通信與合作。特別是，因?yàn)樗](méi)有定義系統(tǒng)中構(gòu)件的交互關(guān)系，我們認(rèn)為繼承關(guān)系不是一種連接件。 數(shù)據(jù)抽象和面向?qū)ο蠼M織 ? 面向?qū)ο笙到y(tǒng)有很多眾所周知的優(yōu)點(diǎn)。與此相反，例如，在管道 過(guò)濾器系統(tǒng)中，過(guò)濾器之間交互不需要知道系統(tǒng)中其他過(guò)濾器的存在。 ? 在一個(gè)系統(tǒng)中，比如面向?qū)ο笙到y(tǒng)，構(gòu)件接口提供了過(guò)程和函數(shù)的集合，典型的情況是，構(gòu)件通過(guò)顯式地調(diào)用這些例程來(lái)與其他構(gòu)件交互。當(dāng)這個(gè)事件發(fā)生時(shí)，系統(tǒng)本身會(huì)調(diào)用所有注冊(cè)了這個(gè)事件的過(guò)程。這些過(guò)程會(huì)使編輯器滾動(dòng)到相應(yīng)的代碼行，或者重新顯示被監(jiān)視的變量的值。這種模式主要特點(diǎn)是事件發(fā)布者不知道哪些構(gòu)件會(huì)受到事件的影響。 ? 隱式調(diào)用對(duì)重用提供了很好的支持。 ? 隱式調(diào)用的主要缺點(diǎn)是構(gòu)件放棄了自身對(duì)系統(tǒng)計(jì)算的控制。有時(shí)數(shù)據(jù)通過(guò)事件傳遞，但在某些情況下，事件系統(tǒng)必須依賴一個(gè)共享緩沖區(qū)，