1.軟件架構風格
軟件架構分為以下幾種風格：
（1）數據流風格：批處理序列；管道/過濾器。
（2）調用/返回風格：主程序/子程序；面向對象風格；層次結構。
（3）獨立構件風格：進程通信；事件系統。
（4）虛擬機風格：解釋器；基於規則的系統。
（5）倉庫風格：數據庫系統；超文本系統；黑板系統。
在架構評估過程中，評估人員所關注的是系統的質量屬性。
1.1 數據流風格
數據流風格的軟件架構是一種最常見，結構最為簡單的軟件架構。這樣的架構下，所有的數據按照流的形式在執行過程中前進，不存在結構的反復和重構，就像工廠中的汽車流水線一樣，數據就像汽車零部件一樣在流水線的各個節點上被加工，最終輸出所需要的結果（一部完整的汽車）。在流動過程中，數據經過序列間的數據處理組件進行處理，然后將處理結果向后傳送，最后進行輸出。
數據流風格架構主要包括兩種具體的架構風格：批處理序列和管道-過濾器。
- 批處理序列
批處理風格的每一步處理都是獨立的，並且每一步是順序執行的。只有當前一步處理完，后一步處理才能開始。數據傳送在步與步之間作為一個整體。（組件為一系列固定順序的計算單元，組件間只通過數據傳遞交互。每個處理步驟是一個獨立的程序，每一步必須在前一步結束后才能開始，數據必須是完整的，以整體的方式傳遞）批處理的典型應用：
（1）經典數據處理；
（2）程序開發；
（3）Windows 下的 BAT 程序就是這種應用的典型實例。
2.管道和過濾器
在管道/過濾器風格的軟件架構中，每個構件都有一組輸入和輸出，構件讀輸入的數據流，經過內部處理，然后產生輸出數據流。這個過程通常通過對輸入流的變換及增量計算來完成，所以在輸入被完全消費之前，輸出便產生了。因此，這里的構件被稱為過濾器，這種風格的連接件就像是數據流傳輸的管道，將一個過濾器的輸出傳到另一過濾器的輸入。此風格特別重要的過濾器必須是獨立的實體，它不能與其他的過濾器共享數據，而且一個過濾器不知道它上游和下游的標識。一個管道/過濾器網絡輸出的正確性並不依賴於過濾器進行增量計算過程的順序。
圖 9-5 是管道/過濾器風格的示意圖。一個典型的管道/過濾器架構的例子是以 UNIX shell 編寫的程序。UNIX 既提供一種符號，以連接各組成部分（UNIX 的進程），又提供某種進程運行時機制以實現管道。另一個著名的例子是傳統的編譯器。傳統的編譯器一直被認為是一種管道系統，在該系統中，一個階段（包括詞法分析、語法分析、語義分析和代碼生成）的輸出是另一個階段的輸入。
管道/過濾器風格的軟件架構具有許多很好的特點：
（1）使得軟構件具有良好的隱蔽性和高內聚、低耦合的特點；
（2）允許設計者將整個系統的輸入/輸出行為看成是多個過濾器的行為的簡單合成；
（3）支持軟件重用。只要提供適合在兩個過濾器之間傳送的數據，任何兩個過濾器都可被連接起來；
（4）系統維護和增強系統性能簡單。新的過濾器可以添加到現有系統中來；舊的可以被改進的過濾器替換掉；
（5）允許對一些如吞吐量、死鎖等屬性的分析；
（6）支持並行執行。每個過濾器是作為一個單獨的任務完成，因此可與其他任務並行執行。
但是，這樣的系統也存在着若干不利因素。
（1）通常導致進程成為批處理的結構。這是因為雖然過濾器可增量式地處理數據，但它們是獨立的，所以設計者必須將每個過濾器看成一個完整的從輸入到輸出的轉換；
（2）不適合處理交互的應用。當需要增量地顯示改變時，這個問題尤為嚴重；
（3）因為在數據傳輸上沒有通用的標准，每個過濾器都增加了解析和合成數據的工作，這樣就導致了系統性能下降，並增加了編寫過濾器的復雜性。
3. 批處理序列風格與管道過濾器風格對比
把批處理序列風格與管道過濾器風格比較：
共同點：把任務分成一系列固定順序的計算單元（組件）。組件間只通過數據傳遞交互。
區別：批處理是全部的、高潛伏性的，輸入時可隨機存取，無合作性、無交互性。而管道過濾器是遞增的，數據結果延遲小，輸入時處理局部化，有反饋、可交互。批處理強調數據傳送在步與步之間作為一個整體，而管理過濾器無此要求。
1.2 調用/返回風格
調用返回風格顧名思義，就是指在系統中采用了調用與返回機制。利用調用-返回實際上是一種分而治之的策略，其主要思想是將一個復雜的大系統分解為一些子系統，以便降低復雜度，並且增加可修改性。程序從其執行起點開始執行該構件的代碼，程序執行結束，將控制返回給程序調用構件。
調用/返回風格架構主要包括三種具體的架構風格：主程序/子程序；面向對象風格；層次結構。
- 主程序/子程序
主程序/子程序風格是結構化開發時期的經典架構風格。這種風格一般采用單線程控制，把問題划分為若干處理步驟，構件即為主程序和子程序。子程序通常可合成為模塊。過程調用作為交互機制，即充當連接件。調用關系具有層次性，其語義邏輯表現為子程序的正確性，取決於它調用的子程序的正確性。 - 面向對象風格
抽象數據類型概念對軟件系統有着重要作用，目前軟件界已普遍使用面向對象系統。這種風格建立在數據抽象和面向對象的基礎上，數據的表示方法和它們的相應操作封裝在一個抽象數據類型或對象中。這種風格的構件是對象，或者說是抽象數據類型的實例。對象是一種被稱作管理者的構件，因為它負責保持資源的完整性。對象是通過函數和過程的調用來交互的。
圖 9-6 是數據抽象和面向對象風格的示意圖。
這種風格的兩個重要特征為：
（1）對象負責維護其表示的完整性；
（2）對象的表示對其他對象而言是隱蔽的。因為一個對象對它的客戶隱藏了自己的表示，所以這些對象可以不影響它的客戶就能改變其實現方法。
面向對象的系統有許多優點，並早已為人所知：
（1）因為對象對其他對象隱藏它的表示，所以可以改變一個對象的表示，而不影響其他的對象；
（2）設計者可將一些數據存取操作的問題分解成一些交互的代理程序的集合。
但是，面向對象的系統也存在着某些問題：
（1）為了使一個對象和另一個對象通過過程調用等進行交互，必須知道對象的標識。只要一個對象的標識改變了，就必須修改所有其他明確調用它的對象；
（2）必須修改所有顯式調用它的其他對象，並消除由此帶來的一些副作用。例如，如果 A 使用了對象 B，C 也使用了對象 B，那么，C 對 B 的使用所造成的對 A 的影響可能是料想不到的。 - 層次結構風格
層次系統組織成一個層次結構，每一層為上層服務，並作為下層客戶。在一些層次系統中，除了一些精心挑選的輸出函數外，內部的層只對相鄰的層可見。這樣的系統中構件在一些層實現了虛擬機（在另一些層次系統中層是部分不透明的）。連接件通過決定層間如何交互的協議來定義，拓撲約束包括對相鄰層間交互的約束。
這種風格支持基於可增加抽象層的設計。這樣，允許將一個復雜問題分解成一個增量步驟序列的實現。由於每一層最多只影響兩層，同時只要給相鄰層提供相同的接口，允許每層用不同的方法實現，同樣為軟件重用提供了強大的支持。
圖 9-7 是層次系統風格的示意圖。層次系統最廣泛的應用是分層通信協議。在這一應用領域中，每一層提供一個抽象的功能，作為上層通信的基礎。較低的層次定義低層的交互，最低層通常只定義硬件物理連接。
層次系統有許多可取的屬性：
（1）支持基於抽象程度遞增的系統設計，使設計者可以把一個復雜系統按遞增的步驟進行分解；
（2）支持功能增強，因為每一層至多和相鄰的上下層交互，因此功能的改變最多影響相鄰的上下層；
（3）支持重用。只要提供的服務接口定義不變，同一層的不同實現可以交換使用。這樣，就可以定義一組標准的接口，而允許各種不同的實現方法。
但是，層次系統也有其不足之處：
（1）並不是每個系統都可以很容易地划分為分層的模式，甚至即使一個系統的邏輯結構是層次化的，出於對系統性能的考慮，系統設計師不得不把一些低級或高級的功能綜合起來；
（2）很難找到一個合適的、正確的層次抽象方法。
1.3 獨立構件風格
獨立構件風格主要強調系統中的每個構件都是相對獨立的個體，它們之間不直接通信，以降低耦合度，提升靈活性。獨立構件風格主要包括：進程通訊和事件系統子風格。
- 進程通信架構風格進程通信架構風格：構件是獨立的過程，連接件是消息傳遞。這種風格的特點是構件通常是命名過程，消息傳遞的方式可以是點到點、異步和同步方式及遠過程調用等。
- 事件系統風格基於事件的隱式調用風格的思想是構件不直接調用一個過程，而是觸發或廣播一個或多個事件。系統中的其他構件中的過程在一個或多個事件中注冊，當一個事件被觸發，系統自動調用在這個事件中注冊的所有過程，這樣，一個事件的觸發就導致了另一模塊中的過程的調用。
從架構上說，這種風格的構件是一些模塊，這些模塊既可以是一些過程，又可以是一些事件的集合。過程可以用通用的方式調用，也可以在系統事件中注冊一些過程，當發生這些事件時，過程被調用。
基於事件的隱式調用風格的主要特點是事件的觸發者並不知道哪些構件會被這些事件影響。這樣不能假定構件的處理順序，甚至不知道哪些過程會被調用，因此，許多隱式調用的系統也包含顯式調用作為構件交互的補充形式。
支持基於事件的隱式調用的應用系統很多。例如，在編程環境中用於集成各種工具，在數據庫管理系統中確保數據的一致性約束，在用戶界面系統中管理數據，以及在編輯器中支持語法檢查。例如在某系統中，編輯器和變量監視器可以登記相應 Debugger 的斷點事件。當 Debugger 在斷點處停下時，它聲明該事件，由系統自動調用處理程序，如編輯程序可以卷屏到斷點，變量監視器刷新變量數值。而 Debugger 本身只聲明事件，並不關心哪些過程會啟動，也不關心這些過程做什么處理。
隱式調用系統的主要優點有：
（1）為軟件重用提供了強大的支持。當需要將一個構件加入現存系統中時，只需將它注冊到系統的事件中。
（2）為改進系統帶來了方便。當用一個構件代替另一個構件時，不會影響到其他構件的接口。
隱式調用系統的主要缺點有：
（1）構件放棄了對系統計算的控制。一個構件觸發一個事件時，不能確定其他構件是否會響應它。而且即使它知道事件注冊了哪些構件的過程，它也不能保證這些過程被調用的順序。
（2）數據交換的問題。有時數據可被一個事件傳遞，但另一些情況下，基於事件的系統必須依靠一個共享的倉庫進行交互。在這些情況下，全局性能和資源管理便成了問題。
（3）既然過程的語義必須依賴於被觸發事件的上下文約束，關於正確性的推理存在問題。
1.4 虛擬機風格
虛擬機風格的基本思想是人為構建一個運行環境，在這個環境之上，可以解析與運行自定義的一些語言，這樣來增加架構的靈活性，虛擬機風格主要包括解釋器和規則為中心兩種架構風格。
1.解釋器
一個解釋器通常包括完成解釋工作的解釋引擎，一個包含將被解釋的代碼的存儲區，一個記錄解釋引擎當前工作狀態的數據結構，以及一個記錄源代碼被解釋執行進度的數據結構。
具有解釋器風格的軟件中含有一個虛擬機，可以仿真硬件的執行過程和一些關鍵應用。解釋器通常被用來建立一種虛擬機以彌合程序語義與硬件語義之間的差異。其缺點是執行效率較低。典型的例子是專家系統。
2. 規則為中心
基於規則的系統包括規則集、規則解釋器、規則/數據選擇器及工作內存。
1.5 倉庫風格
在倉庫（repository）風格中，有兩種不同的構件：中央數據結構說明當前狀態，獨立構件在中央數據存儲上執行，倉庫與外構件間的相互作用在系統中會有大的變化。
倉庫風格包括的子風格有：數據庫系統、超文本系統、黑板風格。
數據庫架構是庫風格最常見的形式。構件主要有兩大類，一個是中央共享數據源，保存當前系統的數據狀態；另一個是多個獨立處理元素，處理元素對數據元素進行操作。而超文本系統的典型代表，就是早期的靜態網頁。三種架構子風格中，最復雜的是黑板系統。
黑板系統是在抽象與總結語言理解系統 HEARSAY-11 的基礎上產生的，適合於解決復雜的非結構化的問題，能在求解過程中綜合運用多種不同知識源，使得問題的表達、組織和求解變得比較容易。黑板系統是一種問題求解模型，是組織推理步驟、控制狀態數據和問題求解之領域知識的概念框架。它將問題的解空間組織成一個或多個應用相關的分級結構。分級結構的每一層信息由一個唯一的詞匯來描述，它代表了問題的部分解。領域相關的知識被分成獨立的知識模塊，它將某一層次中的信息轉換成同層或相鄰層的信息。各種應用通過不同知識表達方法、推理框架和控制機制的組合來實現。影響黑板系統設計的最大因素是應用問題本身的特性，但是支撐應用程序的黑板體系結構有許多相似的特征和構件。
對於特定應用問題，黑板系統可通過選取各種黑板、知識源和控制模塊的構件來設計；也可以利用預先定制的黑板體系結構的編程環境。圖 9-8 是黑板系統的組成。黑板系統的傳統應用是信號處理領域，如語音和模式識別。另一應用是松耦合代理數據共享存取。
我們從圖 9-8 中可以看出，黑板系統主要由三部分組成：
（1）知識源。知識源中包含獨立的、與應用程序相關的知識，知識源之間不直接進行通信，它們之間的交互只通過黑板來完成。
（2）黑板數據結構。黑板數據是按照與應用程序相關的層次來組織的解決問題的數據，知識源通過不斷地改變黑板數據來解決問題。
（3）控制。控制完全由黑板的狀態驅動，黑板狀態的改變決定使用的特定知識。
2.相關考題
軟件架構中，（）模式包括主程序/子程序、數據抽象和面向對象，以及層次結構。
A.數據流
B.調用/返回
C.虛擬機
D.獨立構件
根據1中的描述，正確選擇B