體系結構模式

黑板模式是一種常用的架構模式，應用中的多種不同數據處理邏輯相互影響和協同來完成數據分析處理。就好像多位不同的專家在同一黑板上交流思想，每個專家都可以獲得別的專家寫在黑板上的信息，同時也可以用自己的分析去更新黑板上的信息，從而影響其它專家。

在實際應用中常見的實現模式有：

利用數據庫充當黑板，不同的應用共享數據庫中信息，並且可以更新數據信息。這也是最常見的實現方式。

特點：

1 便於實現信息的查詢、篩選和統計，這方面關係數據庫提供了SQL 92的強大支持。

2 不能用於較高實時性要求的環境，這種實現是工作在“拉模式”下的，並且高頻率的訪問數據庫會導致嚴重的系統性能問題。

這種實現方式通常採用消息隊列作為黑板，隊列工作在主題模式（Topic），專家作為隊列的訂閲者，同時可以向隊列發送消息，消息會被髮送至所有訂閲者。以上過程實現了專家間的信息交流。

特點：

1 可以有效應用於實時性要求較高的系統，這種實現工作在“推模式”下。

2 難於實現信息的統計分析，不像實現方式一那樣可以通過SQL支持，這些工作必須開發者自己完成。

用户界面，特別是圖形用户界面，承擔着向用户顯示問題模型和與用户進行操作和I/O交互的作用。用户希望保持交互操作界面的相對穩定，但更希望根據需要改變和調整顯示的內容和形式。例如，要求支持不同的界面標準或得到不同的顯示效果，適應不同的操作需求。這就要求界面結構能夠在不改變軟件的功能和模型情況下，支持用户對界面構成的調整。

要做到這一點，從界面構成的角度看，困難在於：在滿足對界面要求的同時，如何使軟件的計算模型獨立於界面的構成。模型-視圖-控制（MVC：Model-View-Controller）就是這樣的一種交互界面的結構組織模型

對於界面設計可變性的需求，MVC把交互系統的組成分解成模型、視圖、控制三種部件。

模型部件是軟件所處理問題邏輯在獨立於外在顯示內容和形式情況下的內在抽象，封裝了問題的核心數據、邏輯和功能的計算關係，他獨立於具體的界面表達和I/O操作。

視圖部件把表示模型數據及邏輯關係和狀態的信息及特定形式展示給用户。它從模型獲得顯示信息，對於相同的信息可以有多個不同的顯示形式或視圖。

控制部件是處理用户與軟件的交互操作的，其職責是控制提供模型中任何變化的傳播，確保用户界面於模型間的對應聯繫；它接受用户的輸入，將輸入反饋給模型，進而實現對模型的計算控制，是使模型和視圖協調工作的部件。通常一個視圖具有一個控制器。

模型、視圖與控制器的分離，使得一個模型可以具有多個顯示視圖。如果用户通過某個視圖的控制器改變了模型的數據，所有其它依賴於這些數據的視圖都應反映到這些變化。因此，無論何時發生了何種數據變化，控制器都會將變化通知所有的視圖，導致顯示的更新。這實際上是一種模型的變化-傳播機制。

分析應用問題，分離出系統的內核功能、對功能的控制輸入、系統的輸出行為三大部分。設計模型部件使其封裝內核數據和計算功能，提供訪問顯示數據的操作，提供控制內部行為的操作以及其他必要的操作接口。以上形成模型類的數據構成和計算關係。這部分的構成與具體的應用問題緊密相關。

設計每個視圖的顯示形式，它從模型中獲取數據，將它們顯示在屏幕上。

對於每個視圖，指定對用户操作的響應時間和行為。在模型狀態的影響下，控制器使用特定的方法接受和解釋這些事件。控制器的初始化建立起與模型和視圖的聯繫，並且啓動事件處理機制。事件處理機制的具體實現方法依賴於界面的工作平台。

使用可安裝和卸載的控制器

控制器的可安裝性和可卸載性，帶來了更高的自由度，並且幫助形成高度靈活性的應用。控制器與視圖的分離，支持了視圖與不同控制器結合的靈活性，以實現不同的操作模式，例如對普通用户、專業用户、或不使用控制器建立的只讀視圖。這種分離還為在應用中集成新的I/O設備提供了途徑。

類似的結構模式還有PAC（Presentation-Abstraction-Control）、Forward-Receiver、Publisher-Subscriber、各類可視化用户界面控件等。

其中，"表示-抽象-控制"結構模式（PAC）也是從數據模型及其可是化關係的處理上提出的。其中，表示與視圖對應，抽象與模型對應，控制與控制對應。從邏輯本質上，兩者沒有太大區別。但是，MVC和PAC還是存在着不同的地方。

（1） MVC的控制更側重於在視圖上的用户的I/O處理，而PAC的控制主要指從抽象到表示的傳遞和協調作用。

（2） 此外，PAC把系統分割為協作但鬆散耦合的智能體，而MVC是專門處理交互界面的，各個部件之間的關聯更密切一些。

（3） 另外，從體系結構上看，PAC是屬於系統級別的，因為它解決的問題更傾向於系統及部件之間的協作和關聯關係。

運行模式：子系統的體制和運作方式