編譯器系統的主要模型

① 有哪些體系結構模式

一、體系結構定義：

體系結構是一個計算機術語，由G. Amdahl於1964年首次提出體系結構概念，為以後計算機系統的設計與開發奠定了良好的基礎。體系結構包括數據流系統、調用－返回系統、獨立部件、虛擬機、以數據為中心的系統（庫）、特殊領域風格、特殊結構風格、不同風格合成建立的異構結構、最初始最基本的主程序/子程序九大內容。

二、體系結構由來：

在傳統的程序設計領域中，人們使用流程圖來表達系統的基本功能和實現的具體邏輯，但是，流程圖實際上僅僅是源程序的圖形化表示，無法給系統的分析和開發者提供更多的信息，所以沒有在實際的系統開發過程中得到廣泛的應用。隨著軟體系統的規模和復雜性的增加，對軟體系統的整體結構（數據和控制的邏輯）進行分析和描述成為大型系統開發的一個不可缺少的重要部分，顯然，使用流程圖是無法達到這個目標的，我們必須使用新的方法和概念來對系統的整體結構進行把握。

三、體系結構的分類：

1.數據流系統，包括順序批處理、管道和過濾器；

2. 調用－返回系統，包括主程序和子程序、面向對象系統、層次結構；

3. 獨立部件，包括通信進程、事件隱式調用；

4.虛擬機，包括解釋器、規則基系統；

5. 以數據為中心的系統（庫），包括資料庫、超文本系統、黑板系統；

6. 特殊領域風格；例如過程式控制制、模擬器；

7. 特殊結構的風格，例如分布式處理、狀態轉移系統；

8. 不同風格合成建立的異構結構；

9. 最初始、最基本的主程序/子程序。

四、結構範式：

1.管道和過濾器

每個組件具有輸入和輸出的集合，從流中讀出數據作為輸入，產生輸出數據的流。整個系統可以看成多個過濾器復合形成的數據處理組件。

過濾器A

過濾器B

過濾器C

管道

特點：

過濾器之間是相互獨立的（不能共享狀態），其中一個過濾器的操作和行為不能影響另外過濾器的操作和行為，流的傳送沒有副作用。

過濾器對所輸入流的來源和輸出流的去向不關心，不需要知道流的來源和流的去向，來源和去向對於過濾器的數據處理沒有任何影響。

過濾和流的傳送可以是並發的，可以同時有多個流的傳送存在於系統之中。

實例：

一個最著名的實例是unix的shell編程，多個對數據進行處理的程序（組件）通過管道聯結起來，產生總和的效果；還有傳統的編譯器，源代碼經過詞法分析、語法分析、中間代碼生成、目標代碼生成等步驟生成輸出的目標代碼。

優點：

整個系統的功能是多個過濾器作用的總和，這樣可以簡化系統的分析和設計，可以經過需求的分析之後將整個系統作為一個過濾器處理，然後再逐步的細化成為多個相互連接的過濾器。

支持組件的重用，同一個過濾器可以多次出現在系統的不同位置。

易於維護和增強，過濾器可以被替換，可以增加新的過濾器到系統中而不改變原有的過濾器，不改變原來系統的基本功能。

本質上的並發性支持，這種體系結構由於本質上是與各個獨立的過濾器的狀態無關的，與並行的流的通過次序也是無關的，所以並發是一個基本的體系結構自然具有的特性。

缺點：

由於過濾器之間本質上是獨立的，所以設計者必須獨立考慮每一個過濾器的輸入、處理和輸出的過程，對於過濾器邏輯上的共同點和相互關系無法在設計中加以體現。

由於這種體系的批處理特性，所以不適合開發和用戶交互的應用程序。

系統的多個處理流之間的共同特性無法提取、多個過濾器之間的共同特性也無法提取，所以增加了設計的復雜性。

2.面向對象的體系

在這種體系中，數據和數據上的操作被封裝成抽象數據類型或者對象。系統由大量的對象組成，在物理上，對象之間通過函數或者過程調用相互作用；在邏輯上，對象之間通過集成、復合等方式實現設計的復用。

對象D

對象B

對象A

對象E

對象C

對象調用

對象調用

對象調用

類A

類B

類C

類G

對象A

對象E

類F

復合

繼承

物理結構邏輯結構

特點：

面向對象系統分析和設計的資料已經太多，這里就不再詳細說明了。

優點：

由於封裝，實現了靈活性和擴充性，隱藏了實現的細節，提高代碼的質量；

使用繼承和多態、提高了軟體的可重用性。

缺點：

最主要的缺點是，由於對象之間的交互是通過明確的對象函數調用進行的，所以當一個對象需要實現一個特定功能的時候，必須知道哪一個對象提供這種服務，這就降低了系統的靈活性。管道和過濾器模型不需要明確指明數據的來源和去向。

事件驅動的體系

對象E

對象E

對象E

事件分發的匯流排

事件的創建

事件接收者的注冊的創建

對象E

這是面向對象和數據抽象體系的一種變形，系統同樣是由大量的對象組成的，但是對象之間的交互不是通過明確指明對象的函數或者過程調用進行的，相反，系統提供事件的創建和發布的機制，對象產生事件，一個或者多個對象通過向系統注冊關注這個事件並由此觸發出相應的行為或者產生新的事件。

實例：

一個最著名的例子是GUI的模型，滑鼠、鍵盤或者其他輸入設備產生各種事件，窗口、程序或者其他對象有這些事件所觸發，產生新的事件、進行數據處理或者其他操作。

優點：

用於函數和過程的調用調用不需要指明特定的對象，所以系統具有非常好的靈活性和擴展性，新的組件只需要向系統的事件處理部分注冊就可以立刻加入系統中，同樣，老的組件也可以方便的從系統中刪除。對於動態性要求特別高的系統，特別是如果需要在運行時對系統進行擴充，應該採用該結構。

缺點：

由於函數調用是通過事件發送進行的，所以，發出事件的對象不能確認是否有對象處理了這個事件、是否是期望的對象處理了這個事件、是否獲得期望的結果，同樣也無法控制事件發生的次序，系統的邏輯和時序的正確性必須通過復雜的時序邏輯和前後條件的斷言加以保證。

3.分層次的體系

將系統功能和組件分成不同的功能層次，一般而言，只有最上層的組件和功能可以被系統外的使用者訪問，只有相鄰的層次之間才能夠有函數調用。

下面是一個基本的商務處理系統的層次結構：

用戶界面層

事務邏輯層

核心層

實例：

顯然，ISO的OSI（開放系統互連）參考模型是最著名的層次模型的例子，通過將開放系統的功能和組件劃分成7個層次，定義清晰的（很多時候是過於復雜的）層次之間的介面，實現復雜的互操作性。

優點：

系統的開發和設計可以逐步的分層次的進行，從底層的簡單的功能逐步建立高層的復雜和抽象的功能。

靈活性和擴展性，由於相鄰層次之間通過清晰的介面交互，所以特定的層次可以被替換和增強，甚至可以增加新的層次。

缺點：

不是所有的系統都可以分解成為清楚的層次

劃分清晰、邏輯上一致的層次是非常困難的（OSI的失敗和TCP/IP的成功說明了這一點）

嚴格的層次調用結構會降低系統的性能。

4.知識庫體系

使用一個中心數據結構表示系統的當前狀態，一組相互獨立的組件在中心資料庫上進行操作。如果組件負責對中心數據進行選擇、處理，這種體系就是傳統的資料庫模型；如果中心數據結構自主的引發一系列的行為，則這種體系可以看成一個黑板模型。

中心資料庫（知識庫）

客戶組件A

客戶組件B

客戶組件C

實例：

大量的傳統資料庫應用程序實際上就是這一體系的具體實例。在很多研究系統中，使用的基於知識庫的黑板模型，實際上也是這種體系

優點：

以數據為中心的體系結構，可以自然的表示大量的數據和事務處理的邏輯，適合表達以數據為重新的應用程序。

缺點：

只有很少一部分簡單的資料庫存儲應用可以完全採用這種體系結構表示，在大量實際的商業應用中，完成師傅處理和其他邏輯的應用程序必須採用其他的體系結構表達

5.解釋器體系

用戶

如果應用程序的邏輯非常復雜，例如，AutoCAD的各種繪圖指令，而且，用戶可能以非常復雜的方式使用這個系統，一個較好的體系就是提供面向領域的一組指令（語言），系統解釋這種語言，產生相應的行為，用戶使用這種指令（語言）完成復雜的操作。

使用虛擬機語言描述的業務邏輯

虛擬機解釋器

完成實際操作任務的基本指令

實際的問題領域

實例：

大量的開發工具、二次開發工具體現了這一思想：微軟在其產品中大量使用的Visual Basic for Application，以及在AutoDesk產品中大量使用的AutoLisp語言，實際上就是給用戶提供了一種面向領域的語言，然後核心解釋執行這一語言的指令和指令序列。從而擴充產品的功能，方便用戶按照自己的需要定製系統。

優點：

非常好的擴展性，用戶可以實現對軟體系統的二次開發

缺點：

軟體開發復雜，特別是這種指令集的設計非常困難。

是否可以採用一種成熟的語言作為二次開發的基礎（例如，基於Java）