架构风格

标签：集合   全局   优点   工作   步骤   渐进   amp   事件驱动   源代码   

传统的架构风格

依据David Calvert在1996年给出了一份架构风格/模式的清单，架构风格包括了：

• 数据流系统——批处理，管道-过滤器。
• 调用-返回系统——主程序和子程序，面向对象系统，分层。
• 独立组件——通信过程，事件系统。
• 虚拟机——解释器，基于规则的系统。
• 以数据为中心的系统（仓库）——数据库，超文本系统，黑板。

数据流风格

面向数据的架构风格，软件的处理粒度是赤裸裸的“数据”，而不需对数据进行任何的“包装”。

批处理序列

组件为一系列固定顺序的计算单元（独立程序），组件间只通过数据传递交互。数据计算单元的执行必须在前一单元完全结束后才能开始，数据以整体的方式传递。

管道/过滤器

每个构件都有一组输入和输出，构件读取输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常通过对输入流的变换及增量计算来完成，包括通过计算和增加信息丰富数据，通过浓缩和删除精炼数据，通过改变记录方式转化数据，递增地转化数据等。在输入被完全消费之前，输出便产生了。这里构件被称为过滤器，连接件就是数据流传输的管道，将一个过滤器的输出传到另一个过滤器的输入。

此风格要求过滤器必须是独立的实体，它不能与其它的过滤器共享数据，而且一个过滤器不知道它上游和下游的标识。一个管道/过滤器网络输出的正确性并不依赖于过滤器进行增量计算过程的顺序。 

总结

优势：

• 使得软构件具有良好的隐蔽性和高内聚、低耦合的特点；
• 构件之间的组合、重用十分简单，易于拼接成业务功能块；

限制：

• 不适合处理交互的应用。由于业务功能块是按照结构化的流程设计的，所以只适用于处理特定的逻辑流程。当需要增量地显示改变时，这个问题尤为严重。
• 数据由于没有任何封装，传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。

调用/返回风格

主程序 & 子程序

采用单线程控制，把问题划分为若干处理步骤，构件即为主程序和子程序。子程序通常可合成为模块。过程调用作为交互机制，即充当连接件。调用关系具有层次性，其语义逻辑表现为子程序的正确性，取决于它调用的子程序的正确性。

面向对象

这种风格的构件是对象。对象是抽象数据类型的实例。在抽象数据类型中，数据的表示和它们的相应操作被封装起来。对象的行为体现在其接受和请求的动作。连接件即对象间交互的方式，对象是通过函数和过程的调用来交互的。这种结构风格中包含有封装、交互、多态、集成和重用等特征。

层次结构

层次系统组织成一个层次结构。连接件通过决定层间如何交互的协议来定义，拓扑约束包括对相邻导间交互的约束。这个风格将大的问题分解为若干个渐进的小问题，逐步解决，隐藏了很多复杂度。修改一层，最多影响两层，而通常只能影响上层。上层必须知道下层的身份，不能调整层次之间的顺序。

优点：

• 支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解；
• 支持重用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。

独立构件风格

进程间通信

构件是独立的过程，连接件是消息传递。这种风格的特点是构件通常是命名过程（进程），消息传递的方式可以是点到点、异步和同步方式及远过程调用（RPC）等。在这种架构中，消息的传递目标是显式声明的——明确指向另外一个构件。

事件驱动架构

构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的处理机制。一个事件的触发就导致了另一个模块中过程的调用——这本身属于一种异步机制的实现（实际上有些事件的响应是以同步方式实现的）。

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

构件之间交互的连接件往往是以过程之间的隐式调用（Implicit Invocation）来实现的。基于事件的隐式调用风格的主要优点是为软件重用提供了强大的支持，为构件的维护和演化带来了方便；其缺点是构件放弃了对系统计算的控制。

优点：

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

缺点：

• 构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其它构件是否会响应它。而且即使它知道事件注册了哪些构件的构成，它也不能保证这些过程被调用的顺序；
• 既然过程的语义必须依赖于被触发事件的上下文约束。

虚拟机

解释器

一个解释器通常包括完成解释工作的解释引擎，一个包含将被解释的代码的存储区，一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用；其缺点是执行效率较低。

基于规则的系统

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

仓库风格

在仓库风格中，有两种不同的构件：中央数据结构（仓库）说明当前状态，独立构件在中央数据存贮上执行。

数据库架构（共享数据）

数据库架构是仓库风格最常见的形式。构件主要有两大类，一个是中央共享数据源，保存当前系统的数据状态；另一个是多个独立处理元素，处理元素对数据元素进行操作。例如二层C/S架构中不同的服务项对服务数据库的访问模型。

黑板架构

黑板架构包括知识源、黑板和控制3个部分。

• 知识源包括若干独立计算的不同单元，提供解决问题的（与应用程序相关的）知识，知识源响应黑板上的变化，也只修改黑板  ==> 独立算法模块；
• 黑板是一个全局数据库，包含问题域解空间的全部状态。黑板数据是按照与应用程序相关的层次来组织的解决问题的数据，知识源通过不断地改变黑板数据来解决问题。
• 控制逻辑：控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识。

黑板通常应用在对于解决问题没有确定性算法的系统中，例如信号处理、问题规划及编译器优化等软件系统的设计中。

超文本系统

构件以网状连接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。超文本是一种非线性的网状信息组织方法，它以结点为基本单位，链作为结点之间的联想式关联。超文本系统通常应用在互联网领域。

架构风格

标签：集合   全局   优点   工作   步骤   渐进   amp   事件驱动   源代码   

原文地址：https://www.cnblogs.com/brt3/p/9859933.html