定义

描述某一类特定应用领域中软件的组织方式和惯用模式。组织方式描述的是系统的组成构件和构件的组织方式,惯用模式反应众多系统所共有的结构和语义特征。

架构风格四要素

  • 提供一个词汇表
  • 定义一套配置规则
  • 定义一套语义解释原则
  • 定义对基于这种架构风格的系统所进行分析

分类

概括

  • 数据流分析: 批处理序列;管道/过滤器
  • 调用/返回风格: 主程序/子程序;面向对象风格;层次结构
  • 独立构件风格: 进程通信;事件系统
  • 虚拟机风格: 解释器;基于规则的系统
  • 仓库分格: 数据库分析;超文本系统;黑板系统

数据流风格:

所有的数据按照流的形式在执行过程中前进,不存在结构的反复和重构

  • 批处理序列

    批处理风格的每一步处理都是独立的,并且每一步是顺序执行的。只有当前一步处理完(经典数据处理;程序开发)
  • 管道-过滤器

    每个构件都有一组输入和输出,构件接受数据输入,并经过内部处理产生输出。这里的构件成为过滤器,构件之间的连接件成为数据 的流传输的管道

调用/返回风格:

采用调用返回机制

  • 主程序/子程序

    所有计算构件作为子程序协作工作,并由一个主程序顺序调用这些子程序,构件通过共享存储区交换数据
  • 面向对象架构风格

    将数据的基本表示和基本操作封装在对象中,构件是对象。对象维护自身完整性,对象之间通过消息机制进行通信,对象通信时需要知道彼此之间的标识,对象之间通过协作完成计算过程
    • 层次结构

    层次系统组织成一个层次结构,每一层为上层服务,并作为下层客户。在一些层次系统中,除了一些精心挑选的输出函数外,内部的层只对相邻的层可见。

独立构件风格:

强调系统中的每个构件是相对独立的个体,它们之间不直接通信,以降低耦合度,提升灵活性。

  • 隐式调用架构风格

    构件不直接调用一个过程,而是触发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中注册,当一个事件被触发,系统自动调用在这个事件中注册的所有过程,这样,一个事件的触发就导致了另一模块中的过程的调用。
  • 显示调用架构风格

    构件是对象,对象是抽象数据类型的实例。在抽象数据类型中,数据的表示和他们之间的相应操作被封装起来,对象的行为体现在其接受和请求的动作,连接件既是对象交互的方式,对象通过函数和过程调用来交互

虚拟机风格:

人为构建一个运行环境,在这个环境上可以解析与运行自己定义的语言

  • 解释器架构风格

    一个解释器通常包括完成解释工作的解释引擎,一个包含将被解释的代码的存储区,一个记录解释引擎当前工作状态的数据结构,以及一个记录源代码被解释执行进度的数据结构。解释器通常被用来建立一种虚拟机以弥合程序语义与硬件语义之间的差异。
  • 规则为中心

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

仓库风格:

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

  • 数据库架构

    构件主要有两大类,一个是中央共享数据源,保存当前系统的数据状态;另一个是多个独立处理元素,处理元素对数据元素进行操作。
  • 而超文本系统

    典型代表,就是早期的静态网页。
  • 黑板系统

    适合于解决复杂的非结构化的问题,能在求解过程中综合运用多种不同知识源,使得问题的表达、组织和求解变得比较容易。黑板系统的传统应用是信号处理领域,如语音和模式识别。另一应用是松耦合代理数据共享存取。

其他考试中出现的架构风格

  • 控制环路架构风格

    将过程的输出制定属性维护在一个特定的参考值(设定点)。控制环路风格包括过程变量、输入变量、操纵变量和设定点等构件,通过收集实际和理想的过程状态信息,并能调整过程变量使得实际状态趋于理想状态。
  • MVC架构风格

MVC架构最初是Smalltalk-80用来构建用户界面时采用的架构设计风格。其中M代表模型(Model),V代表视图(View),C代表控制器(Controller)。在该风格中模型表示待展示的对象,试图表示模型的展示,控制器负责把用户的动作转化成针对对象模型的操作。模型通过通过更新视图来反应自身的变化
软件架构风格

优点

  • 允许多种界面的扩展,视图的变更与增加与模型无关
  • 易于维护,控制器和视图都随着模型的扩展而扩展,只要保持公共接口。控制器和视图的旧版本可以继续使用
  • 可支持功能强大的用户界面
  • MVP 架构风格

  • MVP 是从经典的模式 MVC 演变而来,它们的基本思想有相通的地方:Controller/Presenter 负责逻辑的处理,Model 提供数据,View 负责显示。当然 MVP
    与 MVC 也有一些显著的区别,MVC 模式中元素之间“混乱”的交互主要体现在允许 View
    和 Model 直接进行“交流”,这在 MVP 模式中是不允许的。在 MVP 中 View 并不直接使
    用 Model,它们之间的通信是通过 Presenter (MVC 中的 Controller)来进行的,所有的
    交互都发生在 Presenter 内部,而在 MVC 中 View 会直接从 Model 中读取数据而不是通
    过 Controller。软件架构风格

    优点

  • 模型与视图完全分离,我们可以修改视图而不影响模型。
  • 可以更高效地使用模型,因为所有的交互都发生在一个地方—Presenter 内部。
  • 我们可以将一个 Presenter 用于多个视图,而不需要改变 Presenter 的逻辑。这
    个特性非常的有用,因为视图的变化总是比模型的变化频繁。
  • 如果我们把逻辑放在 Presenter 中,那么我们就可以脱离用户接口来测试这些逻
    辑(单元测试)。

相关文章: