软件体系结构风格

数据流风格

1.数据流风格的特征

数据的可用性决定着处理计算单元是否执行
系统结构为数据在各处理之间的有序移动
在纯数据流系统中，处理之间除了数据交换，没有任何其他的交互

2.数据流风格的基本构件

基本构件：数据处理

构件接口：输入端口和输出端口（从输入端口读取数据，向输出端口写入数据）
计算模型：从输入端口读数，经过计算/处理，然后写到输出端口

3.数据流风格的连接件

连接件：数据流

单向、通常是异步、有缓冲
接口角色：reader和writer
计算模型: 把数据从一个处理的输出端口传送到另一个处理的输入端口

4.数据流风格的拓扑结构

一般来说，数据的流向是无序的，自由流动，但是我们主要关注近似线性的数据流，或者在限度内的循环数据流

5.两种典型的数据流风格（重要，尤其是案例）

①Pipe-and-Filter（管道-过滤器）

直观结构

基本构成（重要）
构件：过滤器（一个过滤器封装了一个处理步骤、数据源点和数据终点可以看作是特殊的过滤器）、处理数据流
连接件：管道，连接一个源和一个目的过滤器
递增的读取和消费数据流：数据到来时便被处理，不是收集然后处理，即在输入被完全消费之前，输出便产生了

过滤器
作用：将源数据变换为目标数据
过滤器对数据流的五种变换类型：

管道
作用：在过滤器之间传送数据

管道-过滤器风格的例子（重要）
编译器：

Unix Shell：

一个单词排序程序 案例分析（重要）

WordSortGenerator：单词产生器负责从磁盘中读取文件
Pipe：管道，负责数据的传输工作，将数据传送到单词排序过滤器WordSortGenerator进行处理
WordSortFilter：过滤器，能够对传入的数据流进行排序然后将结果写入文件

②批处理风格（Batch Sequential Style）

基本构件：独立的应用程序
连接件：某种类型的媒质
特征：
每个处理步骤是一个独立的程序
每一步必须在前一步结束后才能开始
数据必须是完整的，以整体的方式传递

案例分析

基于Eclipse的代码重复检测工具：

③管道-过滤器与批处理的比较

相似点：
把任务分解成为一系列固定顺序的计算单元
彼此间只通过数据传递交互

不同点：

过程调用风格

常见的过程调用风格

1.主程序-子过程风格

即将大系统分解为若干模块（模块化），主程序调用这些模块实现完整的系统功能
构件：主程序、子程序
连接器：调用-返回机制
拓扑结构：层次化结构

2.面向对象风格

即系统被看作对象的集合，每个对象都有一个它自己的功能集合，数据及作用在数据上的操作被封装成抽象数据类型–对象
构件：类和对象
连接件：对象之间通过功能与函数调用实现交互

3.数据流风格与调用返回风格的对比分析

以“管道-过滤器”和“主程序-子过程”风格为例

独立构件风格

1.进程通信体系结构风格

构件：独立的进程
连接件：消息传递（通常用来实现进程之间的同步和对共享资源的互斥操作）
典型例子：客户-服务器架构，其中服务器通常用来为一个或多个客户端提供数据服务，客户端则用来向服务器发出请求，针对这些请求服务器通过同步或异步方式进行请求响应

2.基于事件的隐式调用风格

事件：用户使用鼠标或键盘对窗口中的组件进行交互时所发生的事情
事件处理程序：对这些事件做出响应的程序，称为事件处理程序(Event Handler)，为了处理事件源发生的事件，监听者会自动调用一个方法来处理事件。这些处理事件的方法就是事件处理程序
事件源：能够产生事件的对象。如按钮、鼠标、文本框、键盘等
事件监听者：监听者有专门的方法来处理事件，事件监听者是一个对事件源进行监视的对象，当事件源上发生事件时，事件监听者能够监听到，并调用相应的方法对发生的事件做出相应的处理
委托事件模型的过程：监听者对象会等待事件的发生，并在事件发生时收到通知，事件源会在事件产生时，将相关于该事件的信息封装在一个对象中，称之为“事件对象”，并将该对象传递给事件监听者，监听者就可以根据该“事件对象”内的信息决定适当的处理方式，即调用相应的事件处理程序
委托事件模型的工作原理：

基于事件的隐式调用风格：
构件不直接调用一个过程，而是触发或广播一个或多个事件
系统中的其它构件中的过程在一个或多个事件中注册
当一个事件被触发/发布，系统自动调用在这个事件中注册的所有过程
这样，一个事件的触发就导致了另一模块中的过程的调用
**注：**由于事件的触发者并不知道哪些构件会被这些事件影响，相互保持独立

构件：事件的发布者或接收者
连接件：事件-过程绑定

实例
Model-View-Control（MVC）

Java程序中的事件处理分析
在Java程序中，处理事件的一般步骤是：
（1）注册监听器以监听事件源产生的事件(如通过ActionListener来响应用户点击按钮)；
（2）定义处理事件的方法(如在ActionListener中的actionPerformed中定义相应方法)
两种事件派遣实现方式：
（1）选择广播式：事件（如点击按钮）发生时，该事件仅会传递到注册过的监听器（ActionListener）中，并进行处理；
（2）广播式：利用继承自父类的监听器以及多个if语句来决定是哪个组件产生的事件并加以处理

层次风格

1.层次系统

层次体系结构风格特征：
①在层次系统中，系统被组织成若干个层次，每个层次由一系列构件组成
②下层构件向上层构件提供服务
③上层构件被看作是下层构件的客户端。即层次之间存在接口，通过接口形成call/return调用-返回机制

基本构件：各层次内部包含的构件
连接件：层间的交互协议
拓扑结构：分层
拓扑约束：对相邻层间交互的约束
分层风格与主程序-子过程调用风格的不同：

• 前者各层模块具有不同类型的功能
• 后者各层次模块的功能具有同样的类型

2.分层模式

①严格分层(Strict System Layering)

严格分层系统要求严格遵循分层原则，限制一层中的构件只能与对等实体以及与它紧邻的下面一层进行交互，即第N 层只能与第 N-1 和N+1层中的构件进行交互，第N-1 层只能与第 N和N-2 层进行交互，依次类推
这一特点允许每层用不同的方法实现，同样为软件复用提供了强大的支持

②松散分层（Loosely Layering System）

松散分层允许构件与位于它下面的任意层中的组件进行交互（注意:交互的方向依旧未变）

3.分层系统中的交互模式

①由上而下的交互模式

较高层直接调用较低层，因此高层依赖于低层

②由下而上的交互模式

较低层通过事件(event)、回调和委派(callback delegate)来与较高层通信

③双向模式（核心）

1）逻辑分层

层次软件体系结构风格侧重于把软件中的相关功能和组件分成独立的逻辑分组，即逻辑层（Layer），从而组织成一个层次结构
常见的逻辑分层

表现层：这个层包含面向用户的功能，负责管理用户和系统之间的交互，通常使用GUI，不包含或仅包含一部分业务逻辑，表现层通常会包含如下两类组件：用户界面组件和表现逻辑组件
业务层：这个层实现了系统的核心功能并且封装了相关业务逻辑，通常由如下一些组件构成：应用程序外观，业务逻辑组件
数据层：数据层通常包含数据访问组件，这些组件抽象了访问底层数据存储的必要逻辑；服务代理组件，如果业务组件必须访问由外部服务提供的数据时使用

2）物理分层

物理层(Tier) 描述的却是如何把功能和组件从物理上部署到独立服务器、计算机、网络或远程位置
①逻辑层和物理层之间的映射
1对1，即一个逻辑层运行在一个物理层
1对多，即一个逻辑层运行在多个物理层
多对1，即多个逻辑层运行在一个物理层
②多层系统物理部署模式
1）非分布式部署

2）两层部署

3）三层部署

4）四层部署

5）富客户端应用程序部署

4.分层系统案例分析

①一个简单的用户信息查询程序（三层逻辑架构）

②J2EE框架（四层逻辑架构）

③DBMS中的“三级模式-两层映像（严格分层模式）

④ISO/OSI网络的分层模型（严格分层模式）

ISO/OSI采用了7层体系结构，从高到低分别是：应用层、表示层、会话层、传输层、网络层、数据链路层和物理层，如图所示
其最高层为第7层应用层，用于同应用服务之间交换数据；最低层为第1层物理层，用于连接物理传输介质实现真正的数据通信
层与层之间的联系是通过各层之间的接口来实现的，上层通过接口向下层提出服务请求，而下层通过接口向上层提供服务
两台计算机通过网络进行通信时，只有两物理层之间能够通过媒体进行真正的数据通信，其余各对等层之间均不存在直接的通信关系，各对等层之间只能通过各对等层的协议来进行虚拟通信
⑤计算机操作系统(OS)的层次结构（松散分层模式、自上而下、自下而上相结合的交互方式）

⑥C/S（Client/Server）模式（两层部署）

⑦B/S（Browser/Server）模式（三层部署）

5.分层原则与层次系统设计过程

Step 1: 为把任务分组成层而定义抽象准则
Step 2: 根据抽象准则定义抽象层数
Step 3: 给每个层命名并指定它们的任务
Step 4: 设计层次内部的构件
Step 5: 为每个层次定义接口并指定相邻层间的通信
Step 6: 弱化相邻层之间的耦合
Step 7: 设计错误处理策略

虚拟机风格/解释器风格

1.虚拟机（了解）

虚拟机是一种软件
它创建了一种虚拟的环境
将用户与底层平台隔离开来

JVM（Java Visual Machine）：
JVM可适应所有的硬件与OS平台，从而使得Java具有“一次书写，到处运行”的能力
在JVM上运行的程序必须首先被编译为标准的二进制格式的文件：.class
Java class文件并不是机器代码或目标代码，而是一种具有标准中间格式的二进制文件，无法直接在任何OS平台上执行
在执行具体的class代码之前，JVM需要针对特定的OS环境，进行以下转换：将JAVA CLASS代码转化为特定OS所能支持的程序运行模式

2.解释器（Interpreter）（重要）

①解释器的定义
解释器是一个用来执行其他程序的程序
解释器针对不同的硬件平台实现了一个虚拟机
将高抽象层次的程序翻译为低抽象层次所能理解的指令，以消除在程序语言与硬件之间存在的语义差异
②解释器的组成
一个解释器就是一个虚拟机
就解释器或者从作用上来说，一个解释器包括：伪程序（Pseudoprogram）和解释引擎（Interpretation engine）两个部分
就虚拟机或者从物理上来说，包括：计算状态机CSM和存储器两个部分
下图为解释器风格：

基本构件：解释器引擎、存储区
连接件：对存储区的数据访问

③解释器的三种策略（重要）
1）传统解释器（纯粹的解释执行）

解释器直接读取源代码并加以执行
如：ASP、Excel、JavaScript、MATLAB、etc

2）基于字节码的解释器（先编译后解释执行）

在该类解释器下，源代码首先被“编译”为高度压缩和优化的字节码，但并不是真正的机器目标代码，因而与硬件平台无关；
编译后得到的字节码然后被解释器加以解释
如：Java、Perl、PHP、Python、etc

3）Just-in-Time（JIT）实时编译器（先部分编译后解释执行）

一种在运行时期把字节码编译成原生机器码的技术，一句一句翻译源代码，但是会将翻译过的代码缓存起来以降低性能耗损。这项技术是被用来改善虚拟机的性能的
JIT只会对经常执行的字节码进行编译。如循环，高频度使用的方法等，它会以整个方法为单位，一次性将整个方法的字节码编译为本地机器码，然后直接运行编译后的机器码
通俗的来说：
第一步是编译得到字节码
字节码被配置到目标系统中
当字节码被执行时，运行环境下的编译器将其翻译为本地机器码
JIT模糊了解释器、字节码解释器和编译器之间的边界与区分

3.基于规则的系统（Rule-based System）

把频繁变化的、复杂的业务逻辑抽取出来，形成独立的规则库。这些规则可以独立于软件系统而存在，可被随时的更新
即将“频繁变化的规则”与“较少发生变化的规则执行代码”分离
业务逻辑=固定业务逻辑+可变业务逻辑（规则）+规则引擎
故基于规则的系统的定义为：一个使用模式匹配搜索来寻找规则并在正确的时候应用正确的逻辑知识的虚拟机
下图的基于规则的系统与解释器风格是一个映射关系：

用解释器风格的模式来描述基于规则的系统：

4.基于规则的系统与解释器风格的比较（很重要）

基于规则的系统使用规则定义语言（IF…THEN…的形式，通常基于XML或自然语言，但绝不是程序设计语言），将这些变化部分定义为“规则”
为什么将“基于规则的系统”归为虚拟机体系结构风格中？
基于规则的系统本质上是与解释器风格一致的，都是通过“解释器”（“规则引擎”），在两个不同的抽象层次之间建立起一种虚拟的环境，如下图所示，基于规则的系统的构件与解释器风格中的构件是类似的

二者的不同：
解释器风格：在高级语言程序源代码和OS/硬件平台之间建立虚拟机环境；
基于规则的系统：在自然语言/XML的规则和高级语言的程序源代码之间建立虚拟机环境

5.规则的表达形式

任何规则都包含两部分：
IF：规则的前提或条件
THEN：规则的结论或触发的行为
一个规则可以有多个条件，使用AND或OR连接
例子：

客户/服务器风格

略 之前在层次风格的物理分层中有介绍过