1. 管道和过滤器风格

【数据流风格，因为管道里都是数据流】

（1）构件：过滤器。它对输入流进行处理、转换。处理后的结果在输出端流出。

【过滤器之间是相互独立的，无需进行状态信息的交互（主要特点）。每个过滤器都有输入输出，过程是：输入流->进行处理->输出流】

（2）连接件：管道。位于过滤器之间，起到信息流的导管作用。

（3）优点：

a. 使得软构件具有良好的隐蔽性和高内聚、低耦合的特点，系统中已有的过滤器很容易用于新的待设计系统。

【隐蔽性：构件本身是封装好的实体              高内聚、低耦合：因为构件彼此之间是独立的】

b. 允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成

【便于划分功能】

c. 支持软件重用。

【只需要控制过滤器的输入流，就可以将两个过滤器连接起来】

d. 具有较强的可维护性和可扩展性。

【可维护性：更新和升级--增加、修改过滤器，只需要考虑涉及到的过滤器，其他不相关的不受影响】

【可扩展性：添加新的功能，只需要在原有基础上添加新的端口】

e. 支持并行执行。

【构件之间相互独立，所以可以并行执行】

f. 为系统的性能分析提供了方便。

【吞吐量、死锁、计算机正确性等属性】

（4）缺点：

a. 通常导致进程成为批处理的结构。

【过滤器是对输入的批量转换处理，对输入和输出有相应的说明限制】

b. 不适合交互应用要求高的情况

【过滤器对输入流有着严格的限制】

c. 因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。

（5）例子：

Unix的Shell程序

Cat file | grep xyz | sort |uniq>out

系统先在文件中查找含有xyz的行，排序，然后去掉相同的行，最后结果放到out中

2. 面向对象的体系结构风格

【这是一种调用/返回风格】

（1）构件：对象，或者说是抽象数据类型的实例。

        连接件：通过函数和过程的调用。

（2）优点：

a. 信息隐藏保证了对象行为的可靠性。

【用户只能通过函数调用来影响一个对象，避免了访问的随意性】

b. 受封装的独立运行对象把数据和操作捆绑在一起，提高了对象作为一种模块的内聚力，使系统分解成相互作用又相对独立的对象集合。

c. 对象方法的调用将操作请求和实现细节实现分离，使得可能在不影响使用者的情况下改变操作的实现，为系统的维护升级提供了便利的条件。

d. 对象可以是多线程的，也可以是单线程的

【对象之间通过函数和过程的调用相互影响】

（3）缺点：

a. 为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。

【如果一个对象标识改了，所有地方都要改】

b. 不同对象的操作关联性弱。

【如果两个对象同时访问另一个对象，彼此之间可能会互相影响】

c. 采用面向对象，分解出的是小粒度的基本类或对象。从系统总体结构到构件的设计，缺乏有效的描述和设计方法。

【就是一开始做体系结构设计，分解出的构件很难做到对象这么精准】

3. 基于事件的风格

【这是一种独立构件风格，构件之间彼此都不知道】

（1）构件：一些模块，模块既可以是一些过程，又可以是一些事件的集合。

（2）构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其它构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程。

【构件触发或者广播事件->调用在这个事件中注册的所有过程（包括一些构件）】

（3）过程可以用通用的方式调用，也可以在系统事件中注册一些过程，当发生这些事件时，过程被调用。

（4）特点： 这种风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。这样不能假定构件的处理顺序，甚至不知道哪些过程会被调用。

【这里说的是隐式调用】

（5）优点：

a. 为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中。

b. 为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响到其它构件的接口。

【构件之间相互独立】

c. 事件广播者不必知道哪些部件将会被调用，部件之间的关系将弱化。

【降低了构件之间的耦合性】

（6）缺点：

a. 构件放弃了对系统计算的控制。

【构件只知道自己需要调用的事件，不知道涉及的其他构件和它们的顺序】

b. 数据交换的问题。有时数据可被一个事件传递，但另一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互。

c. 很难对系统正确性进行推理。

【Debug有问题】

（7）例子：

在某系统中，编辑器和变量监视器可以登记相应Debugger的断点事件。当Debugger在断点处停下来时，它声明该事件，由系统自动调用处理程序。

【Debugger本身只声明事件，并不关心哪些过程会启动，也不关心这些过程做什么处理。】

4. 分层的体系结构风格

【这是一种调用/返回风格】

（1）连接件：通过决定层间如何交互的协议来定义。

        拓扑约束：包括对相邻层间交互的约束。

（2）分层风格有助于将任务分解成多个子任务组，其中每个子任务组处于某个特定的抽象层次上。

（3）层次系统组织成一个层次结构，每一层为上层服务，并作为下层客户。最上层只调用下层提供的函数功能，最底层只负责为直接相邻的上层提供服务。

（4）在一些层次系统中，除了一些精心挑选的输出函数外，内部的层只对相邻的层可见。

【由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，这为软件重用提供了强大的支持。】

（5）这种风格支持基于可增加抽象层的设计。允许将一个复杂问题分解成一个增量步骤序列的实现。

【就是对问题可以横向分解和纵向分解结合】

（6）优点：

a. 支持基于抽象程度递增的系统设计

【就是可以由简单到复杂】

b. 支持功能增强

【因为每一层基本只影响相邻两层，所以对功能的修改最多影响相邻两层】

c. 支持重用。

【层与层之间通过服务接口进行交互，所以只要接口不变，层就可以重用】

（7）缺点：

a. 并不是每个系统都可以很容易地划分为分层的模式，有时候为了性能考虑，要把一些综合起来。

b. 效率低下。

【上面的层过分依赖下面的层提供服务，相关数据传达的时间长】

c. 缺少公认合适的、正确的层次抽象方法。

【层次太少，分层不能完全发挥这种风格的可重用性、可更改性和可移植性上的潜力。层次太少，会引入不必要的复杂性和层间隔离冗余以及层间传输的开销。】

5. 仓库风格

（1）构件：中央数据结构说明当前状态，独立构件在中央数据存贮上执行。

（2）控制原则的选取产生两个主要的子类。

        若输入流中某类时间触发进程执行的选择，则仓库是一传统型数据库；

        若中央数据结构的当前状态触发进程执行的选择，则仓库是一黑板系统。

6. 黑板系统

【是一种仓库风格】

（1）组成元素：

知识源：包含独立的、与应用程序相关的知识。

黑板数据：是按照与应用程序相关的层次来组织的解决问题的数据。知识源通过不断的改变黑板数据来解决问题。

黑板：保存着系统的输入、问题求解各个阶段的中间结果和反映整个问题的求解状态。

【知识之间不直接通信，它们之间的交互通过黑板完成】

控制：完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识。

（2）应用：传统应用是信号处理领域，如语音和模式识别，另一应用是松耦合代理数据共享存取�。

7. C2（Component and Connector）风格

（1）C2风格是一种基于构件和消息的体系结构风格，用于构件灵活的、可扩展的软件系统。C2对具有图形用户界面的应用有良好的支持。

（2）C2风格的体系结构是一个层次网络，这个网络由相互协作的构件和负责将它们链接在一起的连接件按照一套风格规则组成。

【也可以理解为通过连接件绑定在一起的按照一组规则运作的并行构件网络。】

（3）系统中的构件和连接件都有一个顶部和一个底部。

（4）构件与构件之间的直接连接是不允许的，连接件和连接件之间可以直接连接。

（5）中心原则：有限可视原则，或者说是与下层独立的原则。

【某一构件只能感知层次高于自己的构件所提供的服务，而不能感知到层次比自己更低的构件的服务】

（6）通信规则：所有构件之间的通讯是通过以连接件为中介的异步消息交换机制来实现的；消息是构件之间唯一通信途径。

【以连接件为中介：构件之间不能直接通讯】

（7）特点：

a. 基于构件的风格。

b. 可扩展性。

c. 适应性

【可同时有多个用户进行交互】