软件体系结构知识点总结 (2)

黑板的作用相当于“共享内存”,如同多位不同专长的专家在同一黑板上交流思想,每个专家都可以获得别的专家写在黑板上的信息,同时也可以用自己的分析去更新黑板上的信息,从而影响其他专家。

解决无确定性求解策略问题

组成

知识源(专家)

包含独立的、与应用程序相关的知识,知识源之间不直接进行通讯,他们之间的交互只通过黑板来完成,一个知识源只能解决问题的一部分

提供解决问题的知识

变现为过程、规则、逻辑断言

仅能修改黑板,无法与其他知识源交互

知道何时能发挥作用

低耦合的子任务,或者有特别的能力

黑板数据结构

按照与应用程序相关的层次结构来组织的解决问题的数据,知识源利用黑板的接口对黑板进行读写,通过不断地改变黑板数据来解决问题

保存知识源要使用的数据

保存来自解空间的数据

分层;同层或者不同层的对象的之间的关联

与仓库的区别

黑板:黑板的状态触发进一步的操作

仓库:操作的执行次序是预先确定的

控制(仲裁者)

控制完全由黑板的状态驱动,监控黑板的变化,决定下一步选哪个知识源进行工作

让知识源响应偶然事件

连接各个知识源的能力,决策解决问题的步骤

控制机制是与时俱进、随机应变的

黑板的结构图:

snipaste_20180414_171943

黑板模型:

Knowledge Sources

把问题分成几个部分,每个部分独立计算

对黑板的变化做出反应

Blackboard Data Structure

全局数据库包含解决方案的全部状态

知识源互相关联的唯一媒介

Control

完全由黑板的状态驱动,黑板的状态的改变决定使用的特定知识

Knowledge sources respond "opportunistically",让知识源响应偶然事件

Blackboard Problem Characteristics

没有直接的算法可解

多种方法都可能解决问题

需要多个领域的专门知识协作解决

不确定性 uncertainty

数据和解决方法可能错误或变化

数据中信噪比的变化

算法接口的变化

问题没有唯一个解答,或者“正确”答案会变化

Virtual Machine 什么是虚拟机

一种软件

创建了虚拟的环境

屏蔽了底层平台

分类:

系统级(硬件虚拟机):将一台电脑虚拟为运行不同os的电脑

进程级(应用程序虚拟机):JVM

机器耦合:云计算

分类 解释器(Interpreters)

结构图:

snipaste_20180414_172058

组件:一个状态机(解释引擎)、三个存储区

连接件:过程调用/对存储区的数据访问

优点:

功能性 Functionality

可以仿真非本地的功能

测试性 Testing

能够仿真灾难的模式

灵活性 Flexibility

多用途的工具

缺点:

效率 Efficiency

比硬件效率慢的多

比编译系统慢

测试性 Testing

增加了软件要去验证的层数

解释器和编译器的区别:

解释器的执行速度慢于编译器产生的目标代码的执行速度,但低于“编译+链接+执行”的总时间

每次解释执行时,都需要分析程序结构,而编译器只需要一次性编译代码

规则系统 Rule-based system

结构:

snipaste_20180414_172109

解决的问题:

业务规则很复杂时,并且规则总是发生变化,不宜用if-else结构

按照OCP(开放/封闭原则),应把可变部分与不变部分进行分离,在前者变化时不影响后者‘

基于规则的系统:一种特殊的虚拟机,使用模式匹配搜索来寻找规则,并在正确时机应用正确的规则

特点:

1引擎

rule interpreter

3存储区

knowledge base

rule/data selection

working memory

优点:

降低修改业务逻辑的成本与风险

缩短开发时间

规则可在多个应用中共享

与解释器风格的不同:

解释器:在高级程序语言与OS/硬件平台间建立虚拟机

基于规则的系统:在自然语言/XML规则和高级程序语言建立虚拟机

常见的规则:

用户界面输入的合法性检查

安全规则/权限控制规则

业务策略(如VIP折扣策略等)

独立构件(Independent Component) 分类: Communicating Processes

结构:

snipaste_20180414_172138

完成任务需要多个proc协同,proc间的协同通过msg完成,msg是显性的,即需要指明源和目的地。

组件间相对独立,依靠发消息通信。

模型:

解决方案

系统模型:独立的通信的(communicating)进程

组件:收发消息的过程

连接件:消息

控制结构:每一个进程有自己的控制线程

重要的变量

通信网络的拓扑结构

每条消息接收者的数量

Event Systems

组件对事件进行订阅,并在事件被触发时得到通知。而事件并不知道都有谁订阅了自己。

隐式调用:

解决方案:

系统模型: 独立的反应过程

组件:一个进程,不知道接收者信号的重要的事件

连接件:自动地调用

控制结构:分散的;没有意识到接受者信息的独立的构件

基于事件的隐式调用风格的思想:

构件不直接调用一个过程,而是触发一个或者多个事件

其他构件中的过程注册一个或多个事件,当一个事件被触发,系统自动调用在这个事件中注册的所有过程

构件是一些模块(过程,或者事件的集合)

主要特点是:事件的触发者并不知道哪些构件会被这些事件影响

不能假定构件的处理顺序,甚至不知道哪些过程会被调用

许多隐式调用的系统也包含显示调用作为构建交互的补充形式

优点:

问题分解:

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zwpfxw.html