ANSIIEEEStd1471一200对体系结构的定义：一个系统的基本组织，表现为系统的组件、组件之间的相互关系、组件和环境之间的相互关系以及设计和进化的原则。

黑板模式是一种常用的架构模式，应用中的多种不同数据处理逻辑相互影响和协同来完成数据分析处理。就好像多位不同的专家在同一黑板上交流思想，每个专家都可以获得别的专家写在黑板上的信息，同时也可以用自己的分析去更新黑板上的信息，从而影响其它专家。

在实际应用中常见的实现模式有：

利用数据库充当黑板，不同的应用共享数据库中信息，并且可以更新数据信息。这也是最常见的实现方式。

特点：

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、各类可视化用户界面控件等。

（1） MVC的控制更侧重于在视图上的用户的I/O处理，而PAC的控制主要指从抽象到表示的传递和协调作用。

（2） 此外，PAC把系统分割为协作但松散耦合的智能体，而MVC是专门处理交互界面的，各个部件之间的关联更密切一些。

（3） 另外，从体系结构上看，PAC是属于系统级别的，因为它解决的问题更倾向于系统及部件之间的协作和关联关系。

运行模式：子系统的体制和运作方式