软件架构风格（上）
- 概述
- 架构风格
- 数据流架构风格
- 批处理风格
- 管道-过滤风格
- 调用/返回架构风格
- 主程序/子程序风格
- 面向对象风格
- 层次结构风格
- 客户端/服务器风格
- 以数据为中心的架构风格
- 仓库风格
- 黑板风格
- 虚拟机架构风格
- 解释器风格
- 规则系统风格
- 独立构件架构风格
- 进程通信风格
- 事件系统风格（隐式调用）
- 闭环控制架构风格
- C2架构风格
概述
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。
体系结构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件体系结构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。
架构设计的一个核心问题是能否达到架构级的软件复用，强调对架构设计的重用。
架构风格定义了用来描述系统的一个术语表和一组指导构建系统的规则。
架构风格
数据流架构风格
数据流体系结构是一种计算机体系结构，直接与传统的冯·诺依曼体系结构或控制流体系结构进行了对比。数据流体系结构没有概念上的程序计数器：指令的可执行性和执行仅基于指令输入参数的可用性来确定，因此，指令执行的顺序是不可预测的，即行为是不确定的。数据流体系结构风格主要包括批处理风格和管道-过滤器风格。
批处理风格
如下图，在批处理风格的软件体系结构中，每个处理步骤是一个单独的程序，每一步必须在前一步结束后才能开始，并且数据必须是完整的，以整体的方式传递。
它的基本构件是独立的应用程序，连接件是某种类型的媒介。
连接件定义了相应的数据流图，表达拓扑结构。
管道-过滤风格
如下图所示，管道-过滤器风格的基本构件是过滤器，连接件是数据流传输管道，将一个过滤器的输出传到另一过滤器的输入。
调用/返回架构风格
构件之间存在互相调用的关系，一般是显式的调用，代表的风格有主程序/子程序、面向对象、层次结构、客户端服务器。
主程序/子程序风格
主程序/子程序风格一般采用单线程控制，把问题划分为若干处理步骤，构件即为主程序和子程序。
子程序通常可合成为模块。
过程调用作为交互机制，即充当连接件。
调用关系具有层次性，其语义逻辑表现为子程序的正确性取决于它调用的子程序的正确性。
面向对象风格
如下图所示，抽象数据类型概念对软件系统有着重要作用，目前软件界已普遍转向使用面向对象系统。这种风格建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。这种风格的构件是对象，或者说是抽象数据类型的实例。
层次结构风格
如下图所示，层次系统组成一个层次结构，每一层为上层提供服务，并作为下层的客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层接口只对相邻的层可见。
这样的系统中构件在层上实现了虚拟机。
连接件由通过决定层间如何交互的协议来定义，拓扑约束包括对相邻层间交互的约束。
由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，这同样为软件重用提供了强大的支持。
客户端/服务器风格
如下图，C/S (客户端/服务器)软件体系结构是基于资源不对等，且为实现共享而提出的，在20世纪90年代逐渐成熟起来。两层 C/S 体系结构有3个主要组成部分：数据库服务器、客户应用程序和网络。服务器(后台)负责数据管理，客户机(前台)完成与用户的交互任务，称为“胖客户机，瘦服务器”。
与两层C/S 结构相比，三层C/S结构增加了一个应用服务器，见下图。整个应用逻辑驻留在应用服务器上，只有表示层存在于客户机上，故称为“瘦客户机”。应用功能分为表示层、功能层和数据层三层。表示层是应用的用户接口部分，通常使用图形用户界面；功能层是应用的主体，实现具体的业务处理逻辑；数据层是数据库管理系统。以上三层逻辑上独立。
以数据为中心的架构风格
以数据为中心的体系结构风格主要包括仓库体系结构风格和黑板体系结构风格。
仓库风格
仓 库 (Repository) 是存储和维护数据的中心场所。在仓库风格中，有两种不同的构件：中央数据结构说明当前数据的状态以及一组对中央数据进行操作的独立构件，仓库与独立构件间的相互作用在系统中会有大的变化。这种风格的连接件即为仓库与独立构件之间的交互。
黑板风格
适用于解决复杂的非结构化的问题，能在求解过程中综合运用多种不同知识源，使得问题的表达、组织和求解变得比较容易。
黑板风格的架构类似于一个黑板或公告板，多个独立的组件称为"专家"，共享一个公共存储区(黑板)，它们可以读取和写入数据。专家根据黑板上的信息进行推断和决策。
虚拟机架构风格
虚拟机体系结构风格的基本思想是人为构建一个运行环境，在这个环境之上，可以解析与运行自定义的一些语言，这样来增加架构的灵活性。虚拟机体系结构风格主要包括解释器风格和规则系统风格。
解释器风格
通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。涉及解析和执行一系列指令或命令，通常通过解释器来实现。解释器将文本或代码解析成可执行的操作。缺点是执行效率低。
如上图，具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用。解释器通常被用来建立一种虚拟机以弥合程序语义与硬件语义之间的差异。典型例子是专家系统。
规则系统风格
如下图，基于规则的系统包括规则集、规则解释器、规则/数据选择器及工作内存。
包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工智能领域和DSS(决策支持系统)中。适用于根据一组事先定义的规则或条件来控制系统的行为。这种风格通常用于实现灵活的业务规则和决策逻辑。
独立构件架构风格
独立构件风格主要强调系统中的每个构件都是相对独立的个体，它们之间不直接通信，以降低耦合度，提升灵活性。独立构件风格主要包括进程通信和事件系统风格。
进程通信风格
在进程通信风格中，构件是独立的过程，连接件是消息传递。这种风格的特点是构件通常是命名过程，消息传递的方式可以是点到点、异步或同步方式及远程过程调用等。
进程通信涉及不同的进程或线程之间的通信和数据共享。
这些进程可以运行在同一台计算机上，也可以分布在不同的计算机上。
典型的示例是一个多线程的文件下载器，其中一个线程负责下载文件，另一个线程负责监视下载进度。这两个线程需要通过进程通信来共享下载状态信息，以便监视线程可以显示下载进度。
事件系统风格（隐式调用）
构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。
主要优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便；缺点是构件放弃了对系统计算的控制，只能被动的控制。
闭环控制架构风格
当软件被用来操作一个物理系统时，软件与硬件之间可以粗略的表示为一个反馈循环，这个反馈循环通过接受一定的输入，确定一系列的输出，最终使环境达到一个新的状态，适合于嵌入式系统，涉及连续的动作与状态。
C2架构风格
C2架构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。
C2风格中的系统组织规则如下：
- 系统中的构件和连接件都有一个顶部和一个底部；
- 构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；
- 一个连接件可以和任意数目的其它构件和连接件连接；
- 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
