求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
要资料
 
追随技术信仰

随时听讲座
每天看新闻
 
 
软件架构与设计教程
1.介绍
2.关键原则
3.架构建模
4.面向对象范式
5.数据流体系结构
6.以数据为中心的架构
7.分层架构
8.面向交互的架构
9.分布式架构
10.基于组件的架构
11.用户界面
12.架构设计
 
 
软件架构与设计-面向交互的架构
来源: Tutorials Point     翻译:Alice(火龙果软件)

您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码: 验证码,看不清楚?请点击刷新验证码 必填



292 次浏览
5次

面向交互的体系结构的主要目标是将用户的交互与数据抽象和业务数据处理分开。面向交互的软件架构将系统分解为三个主要分区:

  • 数据模块 - 数据模块提供数据抽象和所有业务逻辑。

  • 控制模块 - 控制模块标识控制和系统配置操作的流程。

  • 视图演示模块 - 视图演示模块负责数据输出的视觉或音频演示,它还提供用户输入的接口。

面向交互的架构有两种主要风格——模型-视图-控制器 (MVC) 和表示-抽象-控制 (PAC)。MVC 和 PAC 都提出了三个组件分解,并用于交互式应用程序,例如具有多个对话和用户交互的 Web 应用程序。它们在控制和组织流程上有所不同。PAC 是基于代理的分层架构,但 MVC 没有明确的分层结构。

模型-视图-控制器 (MVC)

MVC 将给定的软件应用程序分解为三个相互关联的部分,这些部分有助于将信息的内部表示形式与呈现给用户或从用户接受的信息分开。

模型

模型是 MVC 的核心组件,它直接管理应用程序的数据、逻辑和约束。它由数据组件组成,这些组件维护原始应用程序数据和接口的应用程序逻辑。

  • 它是一个独立的用户界面,可捕获应用程序问题域的行为。

  • 它是特定于领域的软件模拟或应用程序中心结构的实现。

  • 当其状态发生更改时,它会通知其关联的视图以生成更新的输出,并通知控制器更改可用的命令集。

视图

视图可用于以图形形式(如图表或图表)表示任何信息输出。它由提供数据可视化表示的表示组件组成

  • 视图从其模型中请求信息,并向用户生成输出表示形式。

  • 可以有相同信息的多个视图,例如用于管理的条形图和用于会计师的表格视图。

控制器

控制器接受输入并将其转换为模型或视图的命令。它由输入处理组件组成,这些组件通过修改模型来处理来自用户的输入。

  • 它充当关联模型和视图与输入设备之间的接口。

  • 它可以向模型发送命令以更新模型的状态,并可以向其关联的视图发送命令以更改视图对模型的表示形式。

MVC -I

它是MVC架构的简单版本,其中系统分为两个子系统:

  • 控制器视图 - 控制器视图充当输入/输出接口并完成处理。

  • 模型 - 该模型提供所有数据和域服务。

MVC-I 体系结构

模型模块将任何数据更改通知控制器视图模块,以便相应地更改任何图形数据显示。控制器还会对更改采取适当的措施。

控制器视图和模型之间的连接可以设计为订阅-通知模式(如上图所示),其中控制器视图订阅模型,模型通知控制器视图任何更改。

MVC - II

MVC–II 是 MVC-I 体系结构的增强功能,其中视图模块和控制器模块是分开的。模型模块通过提供数据库支持的所有核心功能和数据,在 MVC-I 中发挥着积极作用。

视图模块提供数据,而控制器模块接受输入请求,验证输入数据,启动模型、视图、它们的连接,并调度任务。

MVC-II 体系结构

MVC 应用程序

MVC 应用程序对于交互式应用程序非常有效,在这些应用程序中,单个数据模型需要多个视图,并且易于插入新的或更改的界面视图。

MVC 应用程序适用于模块之间有明确划分的应用程序,以便可以指派不同的专业人员同时处理此类应用程序的不同方面。

优势

  • 有许多可用的 MVC 供应商框架工具包。

  • 使用同一数据模型同步的多个视图。

  • 易于插入新界面视图或替换界面视图。

  • 用于图形专业专业人员、编程专业人员和数据库开发专业人员在设计项目团队中工作的应用程序开发。

缺点

  • 不适用于面向代理的应用程序,例如交互式移动和机器人应用程序。

  • 基于同一数据模型的多对控制器和视图使任何数据模型更改的成本都很高。

  • 在某些情况下,视图和控制器之间的划分并不明确。

表示-抽象-控制 (PAC)

在PAC中,系统被安排成许多合作代理(三合会)的层次结构。它是从 MVC 开发的,除了支持交互要求外,还支持多个代理的应用程序要求。

每个代理都有三个组件 -

  • 表示组件 - 格式化数据的视觉和音频表示。

  • 抽象组件 - 检索和处理数据。

  • 控制组件 - 处理其他两个组件之间的控制流和通信等任务。

PAC 架构类似于 MVC,从某种意义上说,表示模块类似于 MVC 的视图模块。抽象模块看起来像 MVC 的模型模块,控制模块类似于 MVC 的控制器模块,但它们在控制流程和组织流程上有所不同。

每个代理中的抽象组件和表示组件之间没有直接连接。每个代理中的控制组件负责与其他代理的通信。

下图显示了 PAC 设计中单个代理的框图。

具有多个代理的 PAC

在由多个代理组成的 PAC 中,顶级代理提供核心数据和业务逻辑。底层代理定义详细的特定数据和表示。中级或中级代理充当低级代理的协调者。

  • 每个代理都有自己特定的分配工作。

  • 对于某些中级代理,交互式演示不是必需的,因此它们没有演示组件。

  • 所有代理都需要控制组件,所有代理都通过该组件相互通信。

下图显示了参与 PAC 的多个代理。

应用

  • 对于交互式系统有效,其中系统可以分层分解为许多协作代理。

  • 当智能体之间的耦合预计松散时有效,因此智能体上的更改不会影响其他智能体。

  • 适用于分布式系统,其中所有代理都分布在远处,并且每个代理都有自己的数据和交互式界面功能。

  • 适用于具有丰富 GUI 组件的应用程序,其中每个组件都保留自己的当前数据和交互式界面,并需要与其他组件进行通信。

优势

  • 支持多任务处理和多视图

  • 支持代理的可重用性和可扩展性

  • 易于插入新代理或更改现有代理

  • 支持多个代理在不同线程或不同设备或计算机中并行运行的并发性

缺点

  • 由于表示和抽象之间的控制桥以及代理之间的控制通信而产生的开销。

  • 由于代理之间的松散耦合和高度独立性,很难确定正确的代理数量。

  • 每个代理中的控件将表示和抽象完全分离,这会产生开发复杂性,因为代理之间的通信只发生在代理的控件之间

 

292 次浏览
5次