软件体系结构期末复习——软件体系结构风格
📙食用说明
emoji | 说明 |
---|---|
🥑 | 不考 |
🍌 | 了解 |
🍇 | 要考 |
🍉 | 重点 |
🚩 | flag |
🍌软件体系结构风格概述
软件体系结构表示系统的框架结构,用于从较高的层次上来描述各部分之间的关系和接口,主要包括:构件、构件性质和构件之间的关系
软件框架设计的核心问题是:能否复用已经成型的体系结构方案
不同系统的设计方案存在着许多共性问题,把这些共性部分抽取出来,就形成了具有代表性的和可广泛接受的体系结构风格
体系结构风格:体系结构设计方案的共性
软件体系结构风格包括
- 构件
- 连接件
- 约束:
- 诸如:拓扑限制和语义限制等
对于高质量的软件产品而言,首先要为其选择合适的体系结构风格,这样就能够更好地重用已有的设计方案和实现方案
利用软件体系结构风格中的不变部分,可以使系统大粒度地重用已有的实现代码
🍉 常用的软件体系结构风格
数据流风格
批处理和管道/过滤器
调用/返回风格
主程序/子程序、层次结构和客户机/服务器
面向对象风格
独立部件风格
进程通讯和事件驱动
虚拟机风格
解释器和基于规则的系统
数据共享风格
数据库系统和黑板系统
🍉 管道/过滤器体系结构风格
定义
管道/过滤器结构主要包括过滤器和管道两种元素
过滤器:负责对数据进行加工处理
- 每个过滤器都有一组输入端口和输出端口
- 从输入端口接收数据
- 经过内部加工处理
- 传送到输出端口上
管道:输入数据流和输出数据流之间的通路
- 数据通过相邻过滤器之间的连接件进行传输
示例:管道/过滤器 . 真
管道:水管
过滤器:
- 5μmPP滤芯
- 85c颗粒活性炭滤芯
- 1μmPP滤芯
- 反渗透膜
- 后置活性炭滤芯
Web请求中的过滤器
例1:
3个过滤器
全部正常处理,返回Page1内容
例2:
过滤器2异常结束
返回出错页
例3:
过滤器2,根据逻辑返回另一页面
如404、登录页等
常见的过滤器
- 字符集编码检查
- Header数据检查
- 重定向
- 身份验证过滤器(Authentication Filters)。
- 数据压缩过滤器(Data compression Filters)。
- 加密过滤器(Encryption Filters)。
- 触发资源访问事件过滤器。
- 图像转换过滤器(Image Conversion Filters)。
- 日志记录和审核过滤器(Logging and Auditing Filters)。
- MIME-TYPE 链过滤器(MIME-TYPE Chain Filters)。
- 标记化过滤器(Tokenizing Filters)。
- XSL/T 过滤器(XSL/T Filters),转换 XML 内容
链式调用语法糖
例1:Java
1 | Builder builder = new User.Builder(); |
例2:Node.js
1 | let sqlstr = sql.table('web_pages’) |
管道/过滤器——编译器
例:编译程序
管道/过滤器结构
- 将数据流处理分为几个顺序的步骤来进行
- 一个步骤的输出是下一个步骤的输入
- 每个处理步骤由一个过滤器来实现
- 每个过滤器独立完成自己的任务,不同过滤器之间不需要进行交互
- 在管道/过滤器结构中数据输出的最终结果与各个过滤器执行的顺序无关
每个过滤器都是一个独立的个体元素
- 状态无关性:各个过滤器的状态互不相关
- 信息无关性:非邻近过滤器不共享任何信息
- 顺序无关性:运行结果的正确性与各个过滤器运行的先后顺序无关
优点
简单性:
- 允许将系统的输入和输出看作是各个过滤器行为的简单组合
- 独立的过滤器能够减小构件之间的耦合程度
系统具有可扩展性和可进化性
- 易扩展:各个过滤器是相互独立的,因此可以很容易地将新过滤器添加到现有的系统之中,以扩展系统的业务处理能力
- 易进化:原有过滤器可以很方便地被改进的过滤器所替代
- 支持复用
- 如果一个过滤器的输出数据格式与另一个过滤器的输入数据格式是一致的,就可以将这两个过滤器连接在一起
- 系统并发性
- 各个过滤器能够独立运行,因此,不同子任务可以并行执行,提高了系统运行效率
- 便于系统分析
- 由于系统是独立构件的组合,具有清晰的拓扑结构,因而有利于对数据吞吐量、死锁和计算准确性进行分析
存在的问题
- 系统处理过程是批处理方式,过滤器具有很强的独立性,对于每一个过滤器,设计者必须考虑从输入到输出的转换过程,这种方式会造成过滤器对输入数据的批量转换处理
- 不适合用来设计交互式应用系统
- 由于没有通用的数据传输标准,因此每个过滤器都需要解析输入数据和合成数据,添加和去除标记需要花费一定的时间,从而导致了系统性能下降,增加了过滤器设计的复杂性
- 难以进行错误处理,管道/过滤器结构的固有特性,决定了很难制定错误处理的一般性策略
🍉面向对象体系结构风格
定义
在这种体系结构中,数据表示和相关原语操作都被封装在抽象数据类型中
构件:
- 对象,也称为抽象数据类型的实例
- 对象是一种被称为管理器的构件,负责保持资源的完整性
连接器:
- 函数调用和过程调用来进行交互
优点
- 封装:一个对象对外界隐藏了自己的详细信息,改变一个对象的表示,不会影响系统的其它部分
- 继承和封装方法为对象复用提供了技术支持
- 对象将数据和操作封装在一起,提高了系统内聚性,减小了模块之间的耦合程度,使系统更容易分解为既相互作用又相互独立的对象集合
- 面向对象体系结构风格也存在着一些问题:
- 依赖:如果一个对象要调用另一个对象,则必须知道它的标识和名称
- 会产生连锁反应,如果一个对象的标识发生改变,那么必须修改所有显式调用它的其它对象,并消除由此引发的副作用
🍉事件驱动体系结构风格
定义
根据事件声明和发展状况来驱动整个应用程序运行
系统提供处理事件的机制
部分构件具备响应事件的能力
部分构件触发事件(不再直接调用过程)
触发事件——系统管理事件——处理事件
事件驱动系统的构件提供了
- 一个过程集合
- 一组事件
过程可以使用显示方法进行调用,同时也可以由构件在系统事件中注册
在消息机制的控制下,系统作为一个整体与外界环境进行交互
示例
例1:
事件:下课铃响
响应:~~~
例2:
事件:本月生活费花完
响应:发微信/打电话
例3:
事件:上课铃响
响应:
IM聊天软件中的事件
- 用户连接
- 用户断开连接
- 会话过期
- 收到一条聊天消息
- 用户变为不活动
- 用户变为活动
- 与 UI 协调相关的其他所有事件
发布/订阅模型
点对点模型
存储/分发模型
请求/响应模型
优点
事件声明者不需要知道哪些构件会响应事件
- 因此,不能确定构件处理的先后顺序
- 甚至不能确定事件会引发哪些过程调用
提高了软件复用能力
- 只要在系统事件中注册构件的过程,就可以将该构件集成到系统中
便于系统升级
- 只要构件名和事件中所注册的过程名保持不变,原有构件就可以被新构件所替代
存在的问题
构件放弃了对计算的控制权
- 完全由系统来决定
- 当构件触发一个事件时,它不知道其余构件是如何对其进行处理的
- (微信特殊字符闪退事件)
存在数据传输问题
- 数据可以通过事件来进行传输
- 但是在大多数情况下,系统本身需要维护一定的存储空间,这将对系统的逻辑功能和资源管理有一定影响
🍉分层体系结构风格
定义
在分层风格中,系统将划分为一个层次结构
每一层都具有高度的内聚性
- 包含抽象程度一致的各种构件,支持信息隐藏
分层有助于将复杂系统划分为独立的模块
- 从而简化程序的设计和实现
通过分解,可以将系统功能划分为一些具有明确定义的层
- 较高层是面向特定应用问题的
较低层更具有一般性
每层都为上层提供服务,同时又利用了下层的逻辑功能
每层只对相邻层可见,层次之间的连接件是协议和过程调用,用以实现各层之间的交互
上层通过下层提供的接口来使用下层的功能,而下层却不能使用上层的功能
良好的层次结构将有助于对逻辑功能实施灵活的增加、删除和修改
常见分层体系结构
- 表示层
- 业务逻辑层
- 数据访问层
- 数据库
IBM定义的三层Web应用架构
- 表现层
- 业务逻辑层
- 数据存储/资源层
安卓操作系统体系结构
- 应用层
- 应用框架层
- 库/运行时
- Linux内核
网络协议
- OSI 7层
- Tcp/Ip4层
优点
- 设计者可以将系统分解为一个增量的步骤序列,从而完成复杂的业务逻辑
- 每一层至多和相邻的上下两层进行交互,每一层的功能变化最多只影响相邻两层,便于实现系统功能的扩展
- 只要给相邻层提供相同的接口,就可以使用不同的方法来实现每一层,支持软件资源的复用
存在的问题
并非所有系统都能够按照层次来进行划分,即使一个系统的逻辑结构是层次化的,但是出于对系统性能的考虑,需要把不同抽象程度的功能合并到一层,破坏了逻辑独立性
很难找到一种合适和正确的层次划分方法,其应用范围受到限制
在传输数据时,需要经过多个层次,导致了系统性能下降
多层结构难以调试,往往需要通过一系列的跨层次调用来实现
🥑C2体系结构风格
定义
C2结构是一个层次网络,包括构件和连接件两种软件元素
构件和连接件都是包含顶部和底部的软件元素
构件与构件之间只能通过连接件进行连接,连接件之间则可以直接进行连接
构件的顶部、底部分别与连接件的底部、顶部相连,连接件的顶部、底部也分别与连接件的底部、顶部相连
🍉数据共享体系结构风格
定义
数据共享风格也称为仓库风格,有两种不同类型的软件元素:
- 一种是中央数据单元,也称为资源库,用于表示系统的当前状态
- 一种是相互依赖的构件组
中央数据单元和构件之间可以进行信息交换
- 这是数据共享体系结构的技术实现基础
按控制策略分为两种类型:
- 一种是传统的数据库
- 一种是黑板
数据库应用系统:
- 输入流中的事件来驱动系统进行信息处理
- 执行结果存储到中央数据单元中
黑板应用系统:
- 由中央数据单元的当前状态来驱动系统运行
黑板是数据共享体系结构的一个特例,用以解决状态冲突并处理可能存在的不确定性知识源
黑板经常被用于
- 信号处理,例如:语音和模式识别,
- 自然语言处理领域中也有广泛的应用,例如:机器翻译和句法分析
黑板系统主要包括3部分:
知识源是主要的信息来源
- 知识源在逻辑上和物理上都是独立的
- 知识源只与产生它们的应用有关
- 通过中央数据单元与知识源的配合完成相关业务逻辑
- 这一过程对外部环境是透明的
中央数据单元
- 黑板系统的运行完全依赖于中央数据单元的状态变化
- 中央数据单元反映了业务逻辑的求解状态
- 在多个知识源之间,中央数据单元起到了通信机制的作用
控制单元
- 由中央数据单元的状态来驱动的
- 知识源的执行导致了中央数据单元的状态发生变化
- 控制单元根据预先定义的策略,启动相应的知识源,以完成系统的控制任务
示例
自然/科学类期刊
- 中央数据单元:期刊
- 知识源:科研人员/研究所
控制单元:评审机制
知识源发布最新研究结果到期刊上
- 期刊发布的最新研究,影响科研人员的新的研究方向
- 审稿人可以看作控制单元
IBM沃森
- 中央数据单元:问题的求解过程
- 知识源:不同信息库
- 商业信息文本,例如《世界百科全书》
- 维基百科和各类书籍。
- 控制单元:答案搜索和评估算法
在对沃森提出问题时
- 同时执行100多种不同算法分析问题寻找不同答案。
- 另一组算法对答案进行排序和打分。寻找可能支持或者反驳这个答案的证据。然后利用证据支持答案的程度进行评分。
- 最佳证据评估结果的答案将获得最高的可信度。评分最高的答案会成为最终答案。
🍉解释器体系结构风格
定义
解释器作为一种体系结构,主要用于构建虚拟,以弥合程序语义和计算机硬件之间的间隙
解释器是利用软件来创建的一种虚拟机,解释器风格又被称为虚拟机风格
程序的逻辑功能很复杂,用户需要采用复杂的方式来进行操作,一个较好的解决方案是提供面向领域的虚拟机语言
解释器体系结构有许多现实应用,可以将其作为整个软件系统的一个组成部分
- Java和Smalltalk的编译器
- 基于规则的系统,诸如:专家系统领域中的Prolog语言
- 脚本语言,例如:Awk和Perl
示例
Java运行过程中的JIT
JIT 编译器
Hot Spot 编译
不Hot的情况解释执行
- 性能比较
- 机器码
- 一次性解释执行
- 一次性Jit编译执行
LUA脚本语言
Lua解释器
游戏开发
Redis
Lightroom
Nginx
优点
- 能够提高应用程序的移植能力和编程语言的跨平台移植能力
- 实际测试工作可能非常复杂,测试代价极其昂贵,具有一定的风险性,可以利用解释器对未实现的硬件进行仿真
- 解释器体系结构风格也存在着一些问题:
- 由于使用了特定语言和自定义操作规则,因此增加了系统运行的开销
- 解释器系统难以设计和测试
🍉 反馈控制环体系结构风格
定义
反馈控制环是一种特定的数据流结构,传统数据流结构是线性的,控制连续循环过程的体系结构应该是环形的
在反馈控制环系统中,主要包括以下3个部分:
- 过程,指操纵过程变量的相关机制
- 数据元素
- 指连续更新的过程变量,包括:
- 输入变量
- 控制变量
- 操纵变量
- 相关参考值
- 控制器
- 通过控制规则来修正变量
- 收集过程的实际状态和目标状态
- 调节变量以驱动实际状态朝目标状态前进
示例
反馈控制环结构能够处理复杂的自适应问题,机器学习就是一个典型的实例
例:强化学习
- 智能体:被训练的模型
- 环境:Agent所能感知和控制的世界模型。提供带标签的训练、测试数据
- 状态:Agent能感知到的Environment情况
行为:Agent能在Environment中执行的行为
智能体执行一系列行为,获得环境的反馈
- 根据反馈调整智能体权重后重新执行
例:自动驾驶方面的应用
- 智能体:
- 自动驾驶软件
- 环境:
- 传感器探测的环境
- 状态:
- 环境各对象
- 行为:
- 软件决定如何行驶
例:机器人控制领域
- 机械臂控制
- 控制电机/伺服
- 传感器反馈状态
- 软件根据反馈调整控制
🍉客户机/服务器体系结构风格
定义
在集中计算时代,主要采用大型机/小型机模型,在这种模型中,通过与宿主机相连的非智能终端来实现宿主机程序的逻辑功能
个人计算机和工作站的采用,改变了这种协作计算模式,导致了分散计算模型的出现
分散计算模型的主要优点是:用户可以选择适合自己的工作站、操作系统和应用程序,在这一时期,集中计算模式逐渐被以PC机为主的网络计算模式所取代
客户机/服务器是20世纪90年代开始成熟的一项技术
- (Client/Server,C/S)
- 主要针对资源不对等问题而提出的一种共享策略
客户机/服务器是两个相互独立的逻辑系统,为了完成特定任务,它们形成了一种协作关系
在C/S体系结构中,主要包括三个部分:
- 服务器
- 客户机
- 网络
客户机向服务器发送操作请求,期待服务器的响应
二者之间具有一定的连接机制,遵循公共的通信协议
都需要处理请求表达、返回结果表示、连接关系和状态表达等一系列问题
数据和业务处理分布在一定范围内的多个构件上,包括客户机程序中的构件和服务器程序中的构件,构件与构件之间是通过网络进行连接的
定义了工作站与服务器的连接方法,从而使数据存储和逻辑计算可以分布到物理上的多个处理器上
服务器负责存储和管理数据信息,客户机负责数据显示、用户交互以及对业务逻辑的处理
C/S系统可以分为前台客户机程序和后台服务器程序两部分
- 客户机程序
- 表示层
- 包括用户界面和业务处理程序
- 服务器程序
- 数据层
- 包括中心数据库、数据查询程序、数据存储程序和数据更新程序
服务器程序负责管理系统资源
- 包括:管理数据库的安全性、控制数据库访问的并发性、定义全局数据完整性规则以及备份恢复数据库
服务器
- 永远处于激活状态
- 监听用户请求
- 为客户提供服务操作
客户机程序的主要任务
- 提供用户与数据库交互的界面
- 向服务器提交用户请求
- 接收来自服务器的信息以及对客户机数据执行业务逻辑操作
网络通信软件
- 主要功能是完成服务器程序和客户机程序之间的数据传输
代理风格
- 服务器将其服务和数据发布到代理服务器上,客户机通过代理服务器来访问服务,提高了系统的安全性
优点
- 客户机构件和服务器构件分别运行在不同的计算机上,有利于分布式数据的组织和处理
- 构件之间的位置是相互透明的,客户机程序和服务器程序都不必考虑对方的实际存储位置
- 客户机侧重数据的显示和分析,服务器则注重数据的管理,因此,客户机程序和服务器程序可以运行在不同的操作系统上,便于实现异构环境和多种不同开发技术的融合
- 构件之间是彼此独立和充分隔离的,这使得软件环境和硬件环境的配置具有极大的灵活性,易于系统功能的扩展
- 将大规模的业务逻辑分布到多个通过网络连接的低成本的计算机上,降低了系统的整体开销
存在的问题
- 开发成本较高,客户机的软件配置和硬件配置的要求比较高、多端适配要求多个开发组同时工作。
- 客户机程序的复杂度,负荷太重,降低了系统性能
- 信息内容和形式单一,在开发之初就已经确定
- 客户端运行环境复杂多样,兼容困难
- 客户端升级需要一定的技术保障,增加了维护难度
- 早期C/S结构采用了单一的服务器,同时以局域网为中心,因此难以扩展到Intranet和Internet
- 数据安全性不高,客户机程序可以直接访问数据库服务器,因此,客户机上的其它恶意性程序也有可能访问到数据库,无法保证中心数据库的安全
三层C/S体系结构
为了克服两层C/S结构的缺点,可以将客户机和服务器中的部分业务逻辑抽取出来,形成功能层,放在应用服务器上,这就是所谓的三层C/S体系结构
三层C/S结构包括:
- 客户机
- 应用服务器
- 数据库服务器
中间层,即功能层,配置在应用服务器上
应用服务器
- 负责处理客户机与数据库服务器之间的交互,而不是直接让客户机与中心数据库相连,因此减少了同数据库服务器相连的客户机的数目,提高了系统安全性
- 由于将数据存取构件放在应用服务器上,客户机只存放系统的表示层,因此,客户机程序不必关心数据的操作细节,便于实现软件的安装与维护
表示层
- 是系统和用户之间的接口
- 实现用户与系统之间的对话功能
- 用于检查从键盘和鼠标等设备输入的数据,显示输出结果
功能层
- 负责处理所有的业务逻辑
数据层
- 数据库管理系统,负责读写数据
- 数据库管理系统必须能够迅速地执行大量数据的更新和检索操作
在开发三层C/S结构的应用系统时,需要对这三层的功能进行明确地划分,使之在逻辑上相互独立
设计过程中的难点是:如何从两层C/S结构的表示层和数据层中分离各自的应用程序,同时使层次之间的接口简单明了
在实现三层C/S体系结构时,通常可以采用中间件技术
- 中间件是一个用API定义的软件层,是一种具有强大通信能力和良好扩展能力的分布式软件管理框架
- 在客户机和服务器以及服务器和服务器之间,使用中间件来传送数据,完成客户机群和服务器群之间的通信任务
在配置三层C/S结构的系统时,通常有多种不同的选择方案
- 将表示层放在客户机上,功能层和数据层都放在同一个服务器上,与两层C/S结构相比,虽然提高了程序的可维护性,但两层C/S结构的缺陷并未得到完全解决
三层C/S体系结的优点
- 如果合理地划分三层结构的功能,可以使系统的逻辑结构更加清晰,提高了软件的可维护性和可扩充性
- 在实现三层C/S结构时,可以更有效地选择运行平台和硬件环境,从而使每一层都具有清晰的逻辑结构、良好的负荷处理能力和较好的开放性,清晰和合理地划分三层C/S结构,使各层之间保持相互独立,可以降低每一层应用的修改难度
- 在三层C/S结构中,可以分别选择合适的编程语言来并行地开发每一层的逻辑功能,以提高开发效率,同时,每一层的维护也更加容易
- 系统具有较高的安全性,可以充分利用功能层来将数据层和表示层分隔开来,使未授权用户难以绕过功能层,无法利用数据库工具和黑客手段来非法访问数据层,从而保证了中心数据库的安全性,整个系统也更加便于控制,管理层次也更加合理
三层C/S体系结的存在的问题
- 如果各层之间的通信效率不高,即使每一层的硬件配置都很高,系统的整体性能也不会太高
- 必须慎重考虑三层之间的通信方法、通信频率和传输数据量,这和提高各层的独立性一样也是实现三层C/S结构的关键性问题
🍉浏览器/服务器体系结构风格
定义
浏览器/服务器(Browser/Server,B/S)
- 是三层C/S体系结构的一种实现方式
- 主要包括:浏览器、Web服务器和数据库服务器
B/S结构:
- B = 浏览器+HTML+CSS+脚本语言
- S = Web服务器+数据库等
核心:Web服务器
- 用户在浏览器中键入相应的URL
- 浏览器向Web服务器提出HTTP请求
- Web服务器调用相关的应用程序
- Web服务器返回HTML格式的结果
- 浏览器渲染HTML呈现给用户
特点
- 主要功能由Web服务器来完成(数据请求、网页生成、数据库访问)
- 系统的安装、修改和维护都在Web服务器和数据库服务器上进行
- 客户端:仅使用一个浏览器
- B/S结构有利于异构机、异构网和异构应用服务的集成
优点
- 客户端只需要浏览器
- 标准统一(HTTP标准协议)跨平台通信容易
- 同步更新便捷
存在的问题
- 个性化程度比较低
- 客户端兼容性问题较大
- 服务器端性能问题较大
- 可扩展性比较差(受限于浏览器)
- 系统安全性难以保障
- 速度要远低于C/S体系结构
🍉公共对象请求代理体系结构风格
定义
CORBA :Common Object Request Broker Architecture
OMG对象管理组织(Object Management Group)
在异构分布式环境下,可以利用CORBA来实现应用程序之间的交互操作
CORBA规范主要包括:
- 对象请求代理ORB
- 对象适配器(Object Adapter,OA)
- 接口定义语言IDL ( Interface description language )
- 接口存储(Interface Repository,IR)
- ORB内部的相关协议
CORBA体系结构的核心是ORB
- Object Request Broker
- ORB作为“软件总线”用来连接网络上的不同应用对象
ORB的任务是定位服务器,通过对象适配器OA将操作请求传送给相应的服务器
OA(Object Adapter)
- 位于ORB和对象之间
- 屏蔽ORB内部的实现细节
- 为服务器对象提供了抽象接口
- 其功能包括:登录服务器、注册对象、创建对象、激活对象、分发客户请求和认证客户请求
CORBA提供了透明访问对象的相关方法
- 能够屏蔽实现方式、对象状态、通信机制和开发技术之间的差异
Internet ORB内部协议(Internet Inter-ORB Protocol,IIOP)
- ORB的内部协议
- 用以描述IDL类型的在线表示方法和协议数据单元
- 负责实现传输:IIOP使用TCP/IP来传输ORB之间的操作请求和相关参数
接口存储(Interface Repository,IR)
- IR包含了运行时所需要的IDL规范
- 定义了基本类型映射机制
Implementation Repository
- IMR存储服务器的详细信息
动态工作方式
客户端:动态调用接口
- (Dynamic Invocation Interface,DII)
- 客户端用来发送操作请求,提供了动态调用方法
- 以API的形式出现
服务器端:动态框架接口
- Dynamic Skeleton Interface,DSI)
- 用来传输操作请求,提供了动态实现方法
静态工作方式
接口定义语言
- (Interface Definition Language,IDL)
- 用来定义客户端和服务器之间的静态接口
- IDL不是编程语言
- CORBA规范的一种中性定义语言,描述对象接口
客户端与ORB之间的静态接口
- 静态调用接口
- (Static Invocation Interface,SII)
服务器与ORB之间的静态接口
- 静态框架接口
- (Static Skeleton Interface,SSI)
优点
- 实现了客户端程序与服务器程序的分离,客户不再直接与服务器发生联系,而仅需要和ORB进行通信,客户端和服务器之间的关系更加灵活
- 将分布式计算模式与面向对象技术结合起来,提高了软件复用效率
- 提供了软件总线机制
- 软件总线是指一组定义完整的接口规范,应用程序、软件构件和相关工具只要具有与接口规范相符的接口定义,就能集成到应用系统中,这个接口规范是独立于编程语言和开发环境的
- CORBA能够支持异构系统
- 支持不同的编程语言和操作系统,在更大的范围内,开发人员能够相互利用已有的开发成果
🥑 正交体系结构风格
定义
线性代数的概念,是垂直这一直观概念的推广
线性代数中:内积为0的两个或多个向量
物理中:力的正交分解
分子生物学:互相独立的元件称为互相正交的
正交:表示某种不相依赖性或是解耦性
优点
- 结构清晰,线索与线索之间是独立的,不进行相互调用,构件的位置可以清楚地说明它所实现的抽象层次和担负的功能
- 便于修改和维护,因为线索之间是相互独立的,因此,某一条线索的修改不会影响到其它线索,当需求发生变动时,可以将新需求分解为独立的子需求,然后使用线索和构件来实现每一个子需求
- 易于重用,在同一应用领域中,不同软件系统往往具有相同的层次和线索,因此,可以共享同一个框架结构
🍉基于层次消息总线的体系结构风格
在HMB体系结构中,主要包括构件和消息总线两种软件元素
消息总线
- 系统的连接件,负责消息的分派、传递和过滤,并返回处理结果
- 可以支持构件的分布式存储和并发运行
- 构件挂接在消息总线上,向总线登记自己所感兴趣的消息类型
层次
- 叶结点是原子构件,不再包含子构件可以采用不同的软件体系结构风格
- 复杂构件通过局部消息总线进行分解,从而形成复合构件
- 系统将形成树状的拓扑结构
HMB构件主要包括接口、行为和结构
- 接口:
- 定义了构件与外界之间交互的信息和承担的责任,HMB构件的接口是一种基于消息的互连接口
- 行为:
- 使用有限状态自动机来描述构件的功能
- 构件行为要同时受到外来消息和自身状态的影响
- 结构:
- 消息总线连接构件;
- 复合构件由简单的子构件组合
构件可以生产消息
构件可以消费消息
消息总线:
- 在HMB体系结构中,消息总线是连接件
- 消费者构件向消息总线登记自己感兴趣的消息,形成构件—消息响应登记表
- 消息总线接收到的消息查阅构件—消息响应登记表确定能够响应该消息的构件将消息传递给消费者构件返回处理结果给生产者
- 逻辑上,消息总线是一个整体
- 物理上,可以分布在多个不同的机器
消息登记:
- 消费者构件需要向消息总线登记自己所感兴趣的消息
- 不关心消息生产者是哪个构件
消息分派和传递:
- 消息总线接收消息
- 根据构件—消息响应登记表把消息分派给对其感兴趣的构件
- 返回处理结果
消息过滤:
- 在不同的构件中,同一消息可能使用了不同的名字,不同的消息也可能使用了相同的名字,在构件集成时,需要对消息进行过滤
优点
- HMB体系结构风格支持运行时系统演化
- 动态增加和删除构件:
- 保持接口不变就可以方便地实施构件替换
- 动态改变构件所响应的消息
- 构件可以动态地改变自己所提供的服务
- 消息过滤
- 可以解决构件集成中的不匹配问题
- 可以阻塞构件对某些消息的响应
- 动态增加和删除构件:
🍉 MVC体系结构风格
在开发具有人机界面的软件系统时,比较适合使用模型-视图-控制器体系结构
在MVC结构中,主要包括模型、视图和控制器:
- 模型:是应用程序的核心,封装了问题的核心数据、逻辑关系和计算功能,提供了处理问题的操作过程
- 视图:是模型的表示,提供了交互界面,显示模型信息
- 控制器:负责处理用户与系统之间的交互
优点
- 多个视图与一个模型相对应,变化-传播机制确保了所有相关视图都能够及时地获取模型变化信息,从而使所有视图和控制器同步,便于维护
- 具有良好的移植性:由于模型独立于视图,因此,可以方便地实现不同部分的移植
- 系统被分割为三个独立的部分,当功能发生变化时,改变其中的一个部分就能够满足要求
存在的问题
- 增加了系统设计和运行复杂性
- 视图与控制器连接过于紧密,妨碍了二者的独立重用
- 视图访问模型的效率比较低
🍉 异构体系结构集成
原因
- 不同体系结构风格有各自的优点和缺陷,应该根据具体情况来选择系统的框架结构,以解决实际问题
- 关于框架、通信和体系结构问题,目前,存在着多种不同的标准,在某一段时间内,一种标准占据了统治地位,但其变动最终是绝对的
- 在实际工作中,总会遇到一些遗留下来的代码,它们仍然有用,但是与新系统的框架结构不一致,出于技术与经济因素的考虑,决定不再重写
- 在某一单位中,规定了共享软件包和某些标准,但仍会存在解释和表示习惯上的不同,选择异构体系结构风格,可以解决这一问题
方式
- 空间异构。允许构件使用不同的连接件,不同子系统采用了不同的体系结构
- 分层异构。软件元素按层次结构进行组织,每一层使用了不同的体系结构
“内外有别”模型:
- 在企业内部使用C/S结构,内部用户可以通过局域网直接访问数据库服务器
- 在企业外部使用B/S结构,外部用户通过Internet访问Web服务器,Web服务器再访问数据库服务器,
“内外有别”模型的优点
- 企业外部用户无法直接访问数据库服务器,能够保证企业数据库的安全
- 企业内部用户的交互操作比较多,采用C/S结构能够提高查询和修改的响应速度
“内外有别”模型的缺点:
- 对于企业外部用户而言,采用了B/S结构,在修改和维护数据时,需要经过Web服务器,因此响应速度比较慢,数据动态交互性不强
“查改有别”模型:
- 不管用户采用何种方式与系统互联,如果需要执行维护和修改操作,就采用C/S结构
如果只是执行查询和浏览操作,则采用B/S结构
“查改有别”模型体现了B/S结构和C/S结构的共同优点
外部用户能够直接通过Internet访问服务器,给企业信息安全造成了一定的威胁
基于HMB的异构体系结构
整体框架采用HMB,各个复合构件分别采用HMB结构、管道/过滤器结构和数据共享结构