Virtual Machine Software Architecture Style(虚拟机风格)

最新推荐文章于 2024-03-21 07:00:00 发布

阳墨余

最新推荐文章于 2024-03-21 07:00:00 发布

阅读量2.9k

点赞数 3

分类专栏：学习笔记

本文链接：https://blog.csdn.net/weixin_43452424/article/details/104961036

版权

学习笔记专栏收录该内容

37 篇文章 9 订阅

订阅专栏

软件体系结结构——虚拟机风格

Review
一、虚拟机风格
- 1、JVM介绍
- 2、虚拟机风格
二、解释器风格
- 1、介绍
三、规则引擎

Review

书读百遍其义自见，图见百回也能记住。
在这里插入图片描述

一、虚拟机风格

1、JVM介绍

首先问大家一个问题：你觉得JAVA最吸引你的地方在哪里？
也许你会想到自己在使用JAVA编程时的那些乐趣，或者相比其他的方便性与功能强大，但是你们有没有经历过这样的场景，许多编程语言在跨机器编程时不好使用。但是JAVA却不会出现这种情况，这是为什么呢？请一直保持你的好奇。
在这里插入图片描述
最终还是归咎于JVM（JAVA Virtual Machine）的强大，为什么这么说呢？JVM为JAVA的编程提供了一个PC机的虚拟环境，所以不管你在哪台PC机器上编程，但是最终它对应的虚拟JVM还是可以支持的。因此，它能支持——“一次编程，随处运行”。
在这里插入图片描述
那么JVM是如果运作的呢？这里不作详细介绍，简单过程如图。

因此，虚拟机风格的系统在其他技术的基础上提供了语义层。

2、虚拟机风格

在这里插入图片描述

解释器
—模拟硬件系统没有的功能，然后对它进行模拟或者仿真
规则系统
—解释器的策划系统
其他
—脚本语言
—命令行的处理器

此模式适用于无法直接使用最适合执行解决方案的语言或计算机的应用程序。该模式也适用于核心问题是定义表示解决方案的符号（例如脚本）的应用程序。解释程序被运用在一系列阶段中从所需的语言/机器翻译到可用的语言/机器。
解释器通常被设计成在所需的机器或语言和执行环境已经支持的某些（可能是虚拟的）机器或语言之间架起桥梁。

解决方案：
一、系统模型：虚拟机
一个组件：一个状态机（执行引擎）和三个存储器（当前
执行引擎的状态，正在解释的程序，正在解释的程序的当前状态
解释的）
-连接器：数据访问和过程调用
-控制结构：通常是执行引擎的状态转换；输入驱动用于选择
解释什么
重要的变体：专家系统通常作为
代表专业知识的规则或产品的集合。因为制作
需要一个复杂的选择规则，专门形式的口译员已经演变。

二、解释器风格

1、介绍

MS-DOS的命令解释器

内核提供了操作系统中的许多基本功能。因此，当用户执行应用程序时，应用程序通过系统调用线程或者进程，从而使用内核中的基本功能，但是它们不能直接使用内核中的基本功能，必须通过编译器进行转换后才能进行相应的操作。
在这里插入图片描述
解释器是一个用来执行其他程序的程序

—解释器针对不同的硬件平台实现了一个虚拟机
—将高抽象层次的程序翻译为低抽象层次所能理解的指令，以消除在程序语言与硬件之间存在的语义差异
在这里插入图片描述

解释器

解释器通常用来在程序语言定义的计算和有效硬件操作确定的计算之间建立对应和联系。
—简单和小规模的解释器只完成基本的信息识别和转换
—复杂的解释器需要从词法到句法、到语法的复杂识别和处理。
作为一种体系结构风格，解释器已经被广泛应用在从系统软件到应用软件的各个层面.
—包括各类语言环境、Internet浏览器、数据分析与转换等;
—LISP、 Prolog、 JavaScript、 VBScript、 HTML、Matlab、数据库系
统(SQL解释器)、各种通信协议等。
在这里插入图片描述
基本构件:
-解释器引擎
- 解释器内存:
●被解释的源代码
●解释器引擎当前的控制状态的表示
●程序当前执行状态的表示
连接器:
- 对存储区的数据访问

编译器

编译器不会执行输入的源程序代码而是将其翻译为另种语言通常是可执行的机器码或目标码并输代码，而是将其翻译为另一种语言，通常是可执行的机器码或目标码，并输出到文件中以便随后链接为可执行文件并加以执行.
在这里插入图片描述

编译器与解释器的不同

在这里插入图片描述
1、解释器的执行速度要慢于编译器产生的目标代码的执行速度，但是却低 ( 解释器的执行速度要慢于编译器产生的目标代码的执行速度但是却低于编译器“编译+链接+执行”的总时间
2、解释器通常省略了链接与编译的步骤，从而降低编程时间
3、解释器执行速度之所以慢，是因为每次解释执行的时候，都需要分析程序的结构，而编译代码则直接执行而无需重复编译
4、解释器对内存的分配是在解释时才进行的；而编译器则是在编译时进行，因此运行时直接将程序代码装入内存并执行即可

传统解释器

在这里插入图片描述

JVM解释器

Java的源程序不是直接交给解释器解释，而是先经过一个编译过程，把Java源程序翻译成一种特定的二进制字节码编译过程，把Java源程序翻译成种特定的二进制字节码文件(Bytecode)，再把字节码文件交给Java解释器执行
–源代码首先被“编译”为高度压缩和优化的字节码，但并不是真正的机源码首被编译为高度缩和化字节码并不是真机器目标代码，因而与硬件平台无关，而是基于JVM
–采用类似机制的还有Perl、PHP、Pathyn等字节然解释解释
• 编译后得到的字节码然后被解释器加以解释
在这里插入图片描述
优势
功能性：
-可以模拟非本机功能
测试：
-可以模拟“灾难”模式（例如，为了安全-关键应用）
灵活性：
-非常通用的工具

缺点
●效率：
-比硬件慢得多
-比编译系统慢得多
●测试：
-待验证的附加软件层

三、规则引擎

在现实里的业务需求经常频繁的发生变化，软件系统也要随之适应。如果每一次的需求变化都需要程序员来修改代码，那么，效率将会非常低，成本也非常高。软件工程要求从“需求——>设计——>编码”，然而很多业务逻辑常常在需求阶段可能还可以明确，在设计和编码后还在变化。

业务规则

业务规则在程序中通常是以if-then-else-endif分支结构的形式书写的。业务越复杂，判断逻辑越多，程序越来理解，越难维护。业务变化导致程序修改，通常是对程序进行局部修改。
在这里插入图片描述

那么如何解决业务逻辑上的不断改变的问题呢？请往下看。
OO设计的一个重要原则：固定部分与可变部分分离（OCP开发封闭原则），将两者分离开来，当可变部分发生变化时，不会影响固定部分。

最好的办法是把频繁变化的业务逻辑抽取出来，形成独立的规则库。这些规则可独立于软件系统而存在，可被随时的更新。**业务逻辑 = 固定业务逻辑 + 可变业务逻辑(规则) +规则引擎 ** （“频繁变化的规则”与“较少发生变化的规则执行代码”分离。）
基于规则的系统：一个使用模式匹配搜索来寻找规则并在正确的时候应用正确的逻辑知识的虚拟机。
在这里插入图片描述
核心思想
将业务逻辑中可能频繁发生变化的代码从源代码中分
基本过程
–使用规则定义语言(IF…THEN…的形式，通常基于XML或自然语言，但决不是程序设计语言)将这些变化部分定义为“规则”；
–在程序运行的时候，规则引擎根据程序执行的当前状态，判断需要调用并执行哪些规则，进而通过“解释器”的方式来解释执行要调用并执行哪则，解释器式来解释执行这些规则。
–其他直接写在源代码里的程序，仍然通过传统的“编译”或“解释办法执释”的办法加以执行。
在这里插入图片描述
规则
1、任何规则都包含两个部分：
1、IF：规则的前提条件
2、THEN：规则的结论或触发的行为
2、一个规则可以有多个条件，使用AND或者OR连接
IFAND(OR) • IF <antecedent 1> AND (<antecedent 2> OR <antecedent 3>) THEN

实例

当使用者寻找一个人的姓名和性别时，可以通过如下的形式获得其信息，但是当其需要的内容不止这些时，就需要更多的IF条件，会导致编程的消耗内存过多，而且每次业务规则的变化都会导致其编程的变化，所以采用如此的编程实现这些业务就不太灵活，但是如果将整个编程转换为业务规则（如下代码），当出现业务需求变更就可以在When后面添加条件即可，不用过多的改变。

/*JAVA 实现:匹配某一个人的名字和性别，当满足两个IF后便输出其姓名和性别*/
#JAVA 编程：
if( "Joe" .equal( people.getName())){
	if( "Male" .equal( people.getSex() )){
		System.out.pritn("This is a man, name is Joe.");
	}
}

#规则
rule "GoodBye"
	when
		People( name = "Joe", sex = "Male")
	then
		System.out.printn(("This is a man, name is Joe.");
end

复杂规则系统实例

当我们拿到这样的一个系统图，是不是第一时间感到了迷惑？那么仔细看看它与规则系统是否有所关联呢？
在这里插入图片描述
没错，当我们对上图的整个系统进行抽象，就可以得到一个完整的规则系统的模样，所以当我们遇到大而繁杂的系统时，一定要找到其主干，然后抽象它，才能得到我们熟悉的体系结构，从而使用我们熟悉的知识进行学习。
在这里插入图片描述
规则引擎实例：ILOGJRules

开源规则引擎JBoss Drools开发实例
在这里插入图片描述

优势

1、降低了修改业务逻辑的成本
2、缩短了开发时间
3、将规则外部化，可在多个应用之间共享
4、对规则的改变将非常迅速并且具有较低的风险

上一篇：Data-centered Style(以数据为中心的体系结构风格)

阳墨余

关注

3
点赞
踩
29

收藏

觉得还不错? 一键收藏
1
评论
Virtual Machine Software Architecture Style(虚拟机风格)

软件体系结结构——虚拟机风格Review一、虚拟机风格1、JVM介绍2、虚拟机风格二、解释器风格1、介绍MS-DOS的命令解释器解释器编译器编译器与解释器的不同传统解释器JVM解释器三、规则引擎业务规则实例优势Review 书读百遍其义自见，图见百回也能记住。一、虚拟机风格1、JVM介绍首先问大家一个问题：你觉得JAVA最吸引你的地方在哪里？也许你会想到自己在使用JAVA...
复制链接

扫一扫