软件架构风格概念：

软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式（ idiomatic paradigm）。架构风格定义了一个系统家族，即一个架构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。按这种方式理解，软件架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。

架构风格不变的部分使不同的系统可以共享同一个实现代码。
只要系统是使用常用的、规范的方法来组织，就可使别的设计者很容易地理解系统的架构。  软件架构风格为大粒度的软件重用提供了可能。  要为系统选择或设计某一个架构风格，必须根据特定项目的具体特点，进行分析比较后再确定，架构风格的使用几乎完全是特定的。 

软件架构风格分类：
（1）设计词汇表是什么？
（2）构件和连接件的类型是什么

（3）可容许的结构模式是什么？
（4）基本的计算模型是什么？
（5）风格的基本不变性是什么？
（6）其使用的常见例子是什么？
（7）使用此风格的优缺点是什么？
（8）其常见的特例是什么？

架构风格 四要素：提供一个词汇表、定义一套配置规则、定义一套语义解释原则和定义对基于这种风格的系统所进行的分析。 
软件架构风格：
（1）数据流风格：批处理序列；管道–过滤器。
（2）调用/返回风格：主程序/子程序；面向对象风格；层次结构。
（3）独立构件风格：进程通信；事件系统。
（4）虚拟机风格：解释器；基于规则的系统。
（5）仓库风格：数据库系统；超文本系统；黑板系统。

数据流风格-批处理序列：

批处理风格的每一步处理都是独立的，并且每一步是顺序执行的。只有当前一步处理完，后一步处理才能开始。数据传输在步与步之间作为一个整体。（组件唯一系列固定顺序的计算单元，组件只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须前一步结束才能开始，数据必须是完整的，以整体的方式传递）批处理的典型应用：（1）经典数据处理（2）程序开发（3）Windows下的BAT程序

 数据流风格-管道和过滤器

在管道/过滤器的软件架构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常对输入流的变换及增量计算来完成，所以在输入被完全消费之前，输出便产生了。这里的构件成为过滤器，这种风格的连接件就像是数据流传输的管道，讲一个过滤器的输出传到另一个过滤器的输入。此风格特别重要的过滤器必须是独立的实体，他不能与其他的过滤器共享数据，而且一个过滤器不知道它上游和下游的标识。一个管道/过滤器网络输出的正确性并不依赖于过滤器进行增量计算过程的顺序。

一个典型的管道/过滤器架构的例子是以Unix shell编写的程序。Unix既提供一种符号，以连接各组称部分（Unix的进程），有提供某种进程运行时机制以实现管道。另一个著名的例子就是传统的编译器。传统的编译器一直被认为是一种管道系统，在该系统中，一个阶段（包括词法分析，语法分析，语义分析，代码生成）的输出是另一个阶段的输入。

管道/过滤器风格的软件架构具有的优点：

（1）使得软构件具有良好的隐蔽性和高内聚、低耦合的特点；
（2）允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成；
（3）支持软件重用。只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来；
（4）系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉；
（5）允许对一些如吞吐量、死锁等属性的分析；
（6）支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其他任务并行
执行。

管道/过滤器风格的缺点

（1）通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换；
（2）不适合处理交互的应用。当需要增量地显示改变时，这个问题尤为严重；
（3）因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。 

批处理风格与管道-过滤器异同：

同：把任务分成一系列固定顺序的计算单元（组件）。组建之间只通过数据传递交互。

异：批处理是全部的，高潜伏性，输入时可随机存取，无合作，无交互性。  管道过滤器是递增的，数据结果延迟小，输入时，处理局部化，有反馈，可交互，批处理强调数据传递在步与步之间作为一个整体。而管道过滤器无要求。

 调用-返回风格

调用返回风格是一种分而治之的策略，其主要思想是讲一个复杂的大系统分级为一个子系统，以便降低复杂度，并且增加可修改性。程序从其执行起点开始执行该构件的代码，程序执行结束，将控制返回给程序调用构件、

 调用-返回风格——–主程序/子程序

程序/子程序风格是结构化开发时期的经典架构风格。这种风格一般采用单线程控制，把问题划分为若干处理步骤，构件即为主程序和子程序。子程序通常可合成为模块。过程调用作为交互机制，即充当连接件。调用关系具有层次性，其语义逻辑表现为子程序的正确性，取决于它调用的子程序的正确性。 

 调用-返回风格——–面向对象风格

这种风格建立在数据抽象和面向对象的基础上，数据的表示方法和他们的相应操作封装在一个抽象数据类型或对象中。这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种称作管理者的构件，因为它负责保持资源的完整性，对象是通过函数和过程的调用来交互的。

主程序/子程序 与面向对象 相同点：

（1）对象负责维护其表示的完整性

（2）对象的表示对其他对象而言是隐蔽的。因为一个对象对他的客户隐藏了自己的表示，所以这些独享可以不影响它的客户就能改变其他实现方法、。

面向对象的优点：

（1）因为对象对其他对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其他的对象；
（2）设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。

缺点：

（1）为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象；

（2）必须修改所有显式调用它的其他对象，并消除由此带来的一些副作用。例如，如果 A 使用了对象 B， C 也使用了对象 B，那么， C 对 B 的使用所造成的对 A 的影响可能是料想不到的。 

 调用-返回风格——–层次结构风格

　　层次结构系统组织成一个层次结构，每层为上层服务，并作为下层客户。在一层次系统中，除了一些精心挑选的输出函数外，内部的层只对相邻的层可见。这样系统中构件在一些层实现了虚拟机，（在另一些层次系统中是部分不透明的）连接件通过决定层间如何交互的协议来定义，拓扑约束包括对相邻层间交互的约束。

　　这种风格支持基于可增加抽象层的设计。这样允许将一个复杂问题分解成一个增量步骤序列的实现。由于每层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现。同样为软件重用提高强大的支持。

　　层次系统最广泛的应用是分层通信协议。在这一应用领域中，每一层提供一个抽象的功能，作为上层通信的基础。较低的层次定义低层的交互，最低层通常只定义硬件物理连接 

 层次系统优点：

（1）支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解；

（2）支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层；

（3）支持重用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，而允许各种不同的实现方法。 

层次系统缺点：

（1）并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来；

（2）很难找到一个合适的、正确的层次抽象方法。

独立构件风格

概念：
　　独立构件风格强调系统中的每个构件都是相对独立的个体，它们之间不知结同心，以降低耦合度，提升灵活性。

独立构件风格——-进程通讯架构风格：

　　构件是独立的过程，连接件是消息传递。这种风格的特点是构件通常是命名过程，消息传递方法是可以是点到点，异步和同步方式及远程调用等。

独立构件风格——–事件系统风格

　　事件系统风格基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发和广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一个模块中的过程调用

　　进程通讯架构和事件系统风格异同：

同：

　　这种风格的构件是一些模块，这些模块可以是一些过程，又可以是一些事件集合。过程可以通用的方式调用，也可以在系统时间中注册一些过程，当发生这些事件时，过程被调用。

异：

　　基于事件的隐式调用风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。这样不能假定构件的处理顺序，甚至不知道那些过程被调用，因此，许多隐式用的系统也包含显示调用作为构件交互的补充形式。

　　支持隐式调用的应用系统。在编程环境中用于集成各种工具，在数据库管理系统中确保数据的一致性约束，在用户界面系统中管理数据，以及在编辑器中支持语法检查。eg.Debugger 断点事件，

隐式调用系统的主要优点有：
（1）为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中。

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

隐式调用系统的主要缺点有：
（1）构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其他构件是否会响应它。而且即使它知道事件注册了哪些构件的过程，它也不能保证这些过程被调用的
顺序。
（2）数据交换的问题。有时数据可被一个事件传递，但另一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下，全局性能和资源管理便成了问题。
（3）既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问题。
 
虚拟机风格：
　　概念：

　　　　虚拟机风格的基本思想是人为构建一个运行环境，在这个环境之上，可以解析与运行自定义的一些语言，这样来增加架构的灵活性

　　虚拟机风格———-解释器

　　一个解释器通常包含完成解释器工作的解释引擎，一个包涵将被届时的代码的存储区，一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行进度的数据结构。

　　具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用。解释器通常被用来建立一种虚拟机以弥合程序语义与硬件语义之间的差异。其缺点是执行效率较低。典型的例子是专家系统。 

　　虚拟机风格———-规则中心

 　　基于规则的系统包括规则集、规则解释器、规则/数据选择器及工作内存。

仓库风格：

在仓库（repository）风格中，有两种不同的构件:中央数据结构说明当前状态，独立构件在中央数据存储上执行，仓库与构件间的相互作用在系统中会有大的变化。

仓库风格——–数据库架构。

　　数据库架构是库风格最常见的形式，构件主要有两大类，一个是中央共享数据源，保存当前系统的数据状态；另一个是多个独立处理元素，处理元素对数据元素进行操作。

仓库风格——–超文本

　　超文本系统的典型代表，就是早期的静态网页。超文本系统中出现的构件以网状连接方式相互连接，用户可以在构件之间行按照人类的联想思维方式任意跳转到相关构建，超文本是一种非线性的网状信息组织方法，

它一节点为基本单位，链作为结点之间的联想式关联

仓库风格——–黑板风格

　　黑板系统是在抽象与总结语言理解系统 HEARSAY-11 的基础上产生的，适合于解决复杂的非结构化的问题，能在求解过程中综合运用多种不同知识源，使得问题的表达、组织和求 解变得比较容易。黑板系统是一种问题求解模型，是组织推理步骤、控制状态数据和问题求解之领域知识的概念框架。它将问题的解空间组织成一个或多个应用相关的分级结构。分级结构的每一层信息由一个唯一的词汇来描述，它代表了问题的部分解。领域相关的知识被分成独立的知识模块，它将某一层次中的信息转换成同层或相邻层的信息。各种应用通过不同知识表达方法、推理框架和控制机制的组合来实现。影响黑板系统设计的最大因素是应用问题本身的特性，但是支撑应用程序的黑板体系结构有许多相似的特征和构件。 

黑板系统主要由三部分组成：
（1）知识源。知识源中包含独立的、与应用程序相关的知识，知识源之间不直接进行通信，它们之间的交互只通过黑板来完成。

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

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