📜  分层体系结构

📅  最后修改于: 2020-12-14 03:30:22             🧑  作者: Mango


层次结构体系将整个系统视为层次结构,其中软件系统被分解为层次结构中不同级别的逻辑模块或子系统。这种方法通常用于设计系统软件,例如网络协议和操作系统。

在系统软件层次结构设计中,低级子系统向其相邻的上级子系统提供服务,这些子系统调用下级方法。下层提供更多特定功能,例如I / O服务,事务,调度,安全服务等。中间层提供更多与域相关的功能,例如业务逻辑和核心处理服务。并且,上层以用户界面的形式提供了更多抽象的功能,例如GUI,shell编程工具等。

它也用于组织类库,例如命名空间层次结构中的.NET类库。所有设计类型都可以实现此分层体系结构,并且通常与其他体系结构样式结合在一起。

分层建筑风格分为-

  • 主子程序
  • 主从
  • 虚拟机

主子程序

这种风格的目的是重用模块并自由开发单个模块或子例程。以这种方式,根据系统所需的功能,通过使用自上而下的优化将软件系统划分为子例程。

这些改进一直沿垂直进行,直到分解后的模块足够简单以承担其唯一的独立责任。功能可以被上层的多个调用者重用和共享。

有两种方法将数据作为参数传递给子例程,即-

  • 按值传递-子例程仅使用过去的数据,但不能对其进行修改。

  • 通过引用传递-子例程的使用以及更改参数引用的数据的值。

主子程序

好处

  • 易于根据层次细化来分解系统。

  • 可用于面向对象设计的子系统。

缺点

  • 易受攻击,因为它包含全局共享的数据。

  • 紧密耦合可能会引起更多的变化波纹效应。

主从

这种方法采用“分而治之”的原则,并支持故障计算和计算精度。它是对主子例程体系结构的修改,可提供系统的可靠性和容错能力。

在这种体系结构中,从站向主站提供重复的服务,并且主站通过特定的选择策略在从站中选择特定的结果。从机可以通过不同的算法和方法或完全不同的功能执行相同的功能任务。它包括并行计算,其中所有从机均可并行执行。

主从

主从模式的实现遵循五个步骤-

  • 指定如何将任务的计算划分为一组相等的子任务,并标识处理子任务所需的子服务。

  • 指定如何通过处理单个子任务获得的结果来计算整个服务的最终结果。

  • 为步骤1中标识的子服务定义一个接口。该接口将由从属实现并由主控使用,以委派各个子任务的处理。

  • 根据上一步开发的规范实施从组件。

  • 根据步骤1到3中制定的规范实施主机。

应用领域

  • 适用于软件可靠性至关重要的应用。

  • 广泛应用于并行和分布式计算领域。

好处

  • 更快的计算和容易的可伸缩性。

  • 提供可靠性,因为可以复制从站。

  • 从站可以以不同方式实现,以最大程度地减少语义错误。

缺点

  • 通信开销。

  • 并非所有问题都可以解决。

  • 难以实施和可移植性问题。

虚拟机架构

虚拟机体系结构伪装了某些功能,这些功能不是实现它的硬件和/或软件所固有的。虚拟机基于现有系统构建,并提供虚拟抽象,一组属性和操作。

在虚拟机体系结构中,主服务器使用来自从服务器的“相同”子服务,并执行诸如拆分工作,调用从服务器以及合并结果之类的功能。它允许开发人员模拟和测试尚未构建的平台,并模拟过于复杂,昂贵或危险的“灾难”模式,以致无法在实际系统中进行测试。

在大多数情况下,虚拟机从执行平台拆分编程语言或应用程序环境。主要目的是提供可移植性。通过虚拟机对特定模块的解释可能被视为-

  • 解释引擎从正在解释的模块中选择一条指令。

  • 根据指令,引擎将更新虚拟机的内部状态,并重复上述过程。

下图显示了单个物理机上的标准VM基础结构的体系结构。

虚拟机架构

系统管理程序(也称为虚拟机监视器)在主机OS上运行,并将匹配的资源分配给每个来宾OS。当来宾进行系统调用时,系统管理程序将其拦截并将其转换为主机OS支持的相应系统调用。系统管理程序控制每个虚拟机对CPU,内存,持久性存储,I / O设备和网络的访问。

应用领域

虚拟机架构适用于以下领域-

  • 如果没有直接解决方案,则适合通过模拟或翻译解决问题。

  • 示例应用程序包括微程序的解释器,XML处理,脚本命令语言执行,基于规则的系统执行,Smalltalk和Java解释器类型的编程语言。

  • 虚拟机的常见示例是解释器,基于规则的系统,语法外壳和命令语言处理器。

好处

  • 便携性和机器平台独立性。

  • 软件开发简单。

  • 通过中断和查询程序的能力提供灵活性。

  • 灾难工作模型仿真。

  • 在运行时引入修改。

缺点

  • 由于口译员的性质,口译员执行缓慢。

  • 由于执行中涉及额外的计算,因此存在性能成本。

分层样式

在这种方法中,系统被分解为一个层次结构中的多个较高和较低的层,并且每一层在系统中都有自己的责任。

  • 每一层都由一组相关的类组成,这些相关的类封装在程序包,已部署的组件中,或者封装为方法库或头文件格式的子例程组。

  • 每个层都向其上一层提供服务,并充当下层的客户端,即,对第i +1层的请求将通过第i层的接口调用由第i层提供的服务。如果任务完成,则响应可以返回到i +1层;否则,第i层将继续从下面的第i -1层调用服务。

应用领域

分层样式适用于以下领域-

  • 涉及不同服务类别的应用程序,可以按层次进行组织。

  • 可以分解为特定于应用程序和特定于平台的部分的任何应用程序。

  • 在核心服务,关键服务和用户界面服务等之间有清晰区分的应用程序

好处

  • 基于增量抽象级别的设计。

  • 提供增强独立性,因为对一层函数的更改最多影响另外两层。

  • 标准接口及其实现的分离。

  • 通过使用基于组件的技术来实现,这使系统更容易实现即插即用的新组件。

  • 每层可以是独立部署的抽象机,支持可移植性。

  • 易于根据任务的定义以自上而下的细化方式分解系统

  • 同一层的不同实现(具有相同的接口)可以互换使用

缺点

  • 许多应用程序或系统不容易以分层方式构建。

  • 较低的运行时性能,因为客户端的请求或对客户端的响应必须经过可能的多层。

  • 每个层的数据封送和缓冲开销也存在性能问题。

  • 打开层间通信可能会导致死锁,“桥接”可能会导致紧密耦合。

  • 异常和错误处理是分层体系结构中的一个问题,因为一层中的故障必须向上扩展到所有调用层