英语原文共 8 页，剩余内容已隐藏，支付完成后下载完整资料
MVC模式在普适、多客户端用户界面上的扩展
摘要：
本文描述基于模式-视图-控制器（MVC）设计模式在开发普适的JAVA前端程序的实现，我们将分层的任务型系统状态转换模型与MVC方法学进行结合，以此来获取在一个程序中的任务状态组件与视图状态组件的特征。跟确切的说，我们计划为每个任务状态组件添加一个与设备无关的名为“TASKSTATEBEAN”的状态组件和一个与设备相关的名为“WIEWSTATEBEAN”的视图组件作为J2EE工作者服务模式的扩展。此外，我们提议将任务状态组件与视图状态组件在有限状态下的转变模型自动的存储在两个XML文件集中。本文展示了在一个应用中任务状态组件与视图状态组件在人们认知直觉上与面对多模块（复杂）工作的巨大作用，就如后文提到的“让设备飞”一样。
关键字：
普适计算技术 泛在计算 流动计算 设备独立性 模型-视图-控制器 设计模式
- 介绍：
在用户界面的开发中，应用模型-视图-控制器设计模式是一个非常普遍的方法[1]。然而，一个在普适程序开发中重要的目标——当代码最少时可以最大程度上的支持设备，在MVC的开发方法学中并不是必要的。尤其是，如何提供合适的用户界面在普适程序的开发中成为一个典型的问题[2]。例如，一个安装在个人电脑上的单页网页模式的对话框，一定会被分解为多个在其它小屏幕设备（如 掌上电脑与手机）的子对话框
基于MVC模式的开发方法允许再没有重写全部用户界面代码的情况下支持这样的改编。分解一个模型-视图-控制器架构模式的结果是：设备无关的和设备相关的代码在分离出来的组件中不挂钩。从而，为了支持一个额外的系统，只需视图模块（在一些复杂的程序中，有时也包括控制器模块）的代码必须重写或改编。然而，这样可能会导致有太多相似的视图与控制器组件在代码上产生冗余。
一个基于MVC设计模式的J2EE程序的广泛应用是：将服务作为设计模式。这种方法覆盖了开发一个单独客户端的JAVA WEB程序的多个方面。尽管这个模式是建议用一个明确的状态状态转移模型来讲信息存储到一个XML文件中，但这个模型在普适程序中处理由不同设备引起的屏幕差异并不十分让人满意。其仅仅规定好了如何像转变总体JSP文件（例如：将“searchmask.jsp”转换为“resultlist.jsp”）一样转变系统整体状态。所以，在一个设备上的不同的屏幕流将需要非常自主的屏幕流模型。而且，可能需要一个不同的JSP文件集。
所以，保证设备上的屏幕模型和设备共同的任务模型在相似点的抽象介绍的一致性是非常必要的。为了处理这个问题，我们建议用一个双阶段JavaBean分层模型来存储一个程序中任务组件信息流与视图组件信息流的单独信息。
本文将通过对基于任务型的双层分层状态转变模型的介绍来将服务模式扩展到工作者模式，以此来支持多平台的客户端WEB程序。
剩下的章节内容组织如下 ︰ 在第 2 节，讨论了在面向普适计算中的 UI 开发的现有工作。在第3节，介绍基于任务的开发方法的部分设想，描述了在普适Web 应用程序，基于任务的实现算法和对“任务”的合适定义。在第 4 节中，我们将介绍服务工作者设计模式在普适计算方面的观点。然后，我们将介绍并描述普遍应用在更详细的开发方面的扩展-由几个 UML 关系图和代码示例说明的一种实现方法。在 5 节，我们将讨论一个程序在分离其任务状态组件与视图状态组件后在设计时间与运行时间方面的带来的收益。特别是，我们考虑为软件开发过程带来便利的可能性，一种让设备“飞”起来的可能性，讨论我们在其他相关领域的普适计算方法的适用性。
2. 相关的工作
普遍应用的具体要求有在 [2，4-7] 被广泛讨论。尤其是，巴纳瓦尔描述一个严格分开对待任务逻辑和用户交互的编程模型。他们开始创建基于任务模型的组件来覆盖用户的抽象交互和应用程序逻辑的程序结构，然后继续创建子模型来包含视图元素流。其实，基于模型的方法尚不支持现有的主要编程工具或设计模式。我们建议的发展战略是：从根本上基于这种任务驱动的开发方法。
有几个普适计算项目,旨在设计一个高级UI设计语言抽象的用户交互(看文章 [8, 9]如IBM的PIMA工程, http://www.research.ibm.com/PIMA/)。对这些方法进行类似: 在各自语言的抽象用户交互的建模阶段之后，是一个半自动生成特定于设备的代码。虽然我们的论文描述了一个自动化的发展过程,但提出的两级层次状态转换模型在随后的部分很可能使用任何语言支持运行时的先进特征，本文后面会详细解释。此外,这两个指定的Java bean在第4节也可以由相应的高级语言的代码生成。
IBM 苏黎世研究实验室设计了名为 流式计算 多个设备同时使用单个应用程序的一种方法。我们的方法，修改设备让其lsquo;飞rsquo;，也可以进行扩展以支持这种流式计算行为。
总的来说，本文的贡献是将应用程序的任务状态和其视图状态的分离与行之有效的 MVC 方法相结合。其结果是为普遍的基于 Java 的 Web 应用程序的实际的基于任务的开发提供指导方针。
- 基于任务的开发方法
作为开发普遍应用程序与多设备功能的一般方法，巴纳瓦尔等人 [4] 建议为任务逻辑之前用户交互 （例如，屏幕流）建模。一个应用程序的任务流，作为我们的定义，相比其屏幕流，不失一般性，必须共同到所有设备。因此，我们需要重新或至少修改部分对数据流任务这样的定义，以此来满足我们的要求。
任务模块，像伯格曼等人的定义 [11]，由用户执行单元来执行工作。此数据流，然而，没有指定任务与子任务的粒度。一个任务模块，当我们使用它，必须符合下列要求 ︰
它不能太细密，就像后续任务中的一个步骤应当是没有当前任务的部分程序的功能。例如，所有文本领域的用户无需任何额外的系统交互便完成工作一定必须都属于相同的任务。
它不能太粗粒度,存在两个步骤在单个任务与一个步骤需要输入的数据作为输出生产中的另一个步骤相同的任务。例如,搜索和一个搜索引擎查询的结果列表应该属于单独的任务。
换句话说，一项任务必须由从用户和系统的观点在逻辑上属于一起的步骤组成。此数据流的目的是任务能很好显示在单个视图中，即，在单个 Web 页上。
3.1 举例
在本节中讨论的数据库应用程序是基于 Web 的 intranet 应用程序为一个典型的例子 ︰ 一家公司想使其公司员工目录 (图 1) 从不同客户端平台，例如，访问一个典型的桌面浏览器和 PDA （与 HTML 浏览器）。在桌面 PC 上，由于其丰富的屏幕大小，应用程序可能包含的只有三个网站 ︰ 搜索面具，结果列表中，和额外的详细内容，员工页面。虽然它可能只有一个经验法则，在这个示例中，每个三个的桌面浏览器 Web 站点应代表前面数据流恰好只有一个任务 ︰ 整个搜索面具作为入口点，结果列表显示结果的目录查询和雇员的详细的形页，其中显示所选员工显示更多来自目录的属性的第二个查询的结果。任务流和屏幕流是在完全相同的桌面浏览器上。
不过，一个PDA任务流，其任务流界面将大为不同，由于其有限的屏幕大小是无庸置疑的。例如，它可能明智的减少了搜索接口-仅仅显示入口点和一个子集。只有最常用的输入接口 （例如，仅第一批和姓氏，以及部门代码） 和另外一个 扩大面具 按钮（将显示所有搜索接口）。这 “扩大面具按钮”上的单击只会改变应用程序的视图状态，而不是其任务状态。在扩展状态下，用户预计将通过滚动按钮来获取所有搜索接口。在以后的章节，我们应参考这个例子。
-
- 基于任务的普适计算应用设计周期
任务驱动的开发方法的想法现在必须投入更多具体和实际的发展方针。作为对我们的数据流结合基于任务的开发方法中的 任务 一词的含义，我们建议一个普适的 Web 应用程序的发展应如下进行 ︰
1.将模型应用于任务流的系统中，以表达用户需求，例如，使用一个 UML 活动图。
2. 因为这些任务应符合上述的数据流，所以上述每个任务代表系统的一个单一的视图组件。那就是，为每个设备和每个任务创建一个视图组件 (例如，空的 JSP file)。
3.对于每个目标设备和每个任务，检查一下设备的功能是否允许一个任务和视图之间的一对一关系。换句话说，确定在特定的设备任务作为一个单一的视图组件显示是否是可行的、 明智的。
4. 如果这是一个特定的视图组件的例子，任务流和视图流此页相同且没有必要进行变化。跳转到步骤 7。
5. 如果不是样子，任务不得不被分配为几个视图状态。任务的一部分将在单独屏幕上分组或者完全地省略掉，例如上一部手机与其受限制的屏幕大小和内存很少。
6. 此外，使用可用的视图状态信息，能使用户从相同任务的一个视图切换到另一个视图。在 J2EE Web 应用程序环境中，这可以通过将嵌入的 Java 代码添加到给定的 JSP 文件 （rep ─任务状态）。这些文件检索视图状态信息，从而决定使用哪些部分的 JSP file来显示。此外，必须提供视图状态的更改按钮，例如，插入”扩大面版按钮”。
7.优化设备具体演示，例如，通过调整字体大小或 defining CSS 文件。
这种方法的优点是将程序任务状态与视图状态的目标，在设计时 （Web设计团队可以在没有团队执行任务流和业务逻辑情况下创建复杂的视图流结构） 和在运行时明确的分离 （我们将会在第5节详细描述）。
视图2显示了之前提到的员工收索势力如何表示应用程序状态以及程序的状态转换的算法。
4. 实现的设计模式
在介绍了我们针对普适计算应用的基于任务的设计周期之后，我们现在要讨论其在J2EE环境中实现的设计模式。为了增强多设备兼容能力，因此，我们现在采用分离任务逻辑和用户交互的方案扩展一个在J2EE表现层著名的模式[3]。
4.1 工作者模式的服务
工作者模式是一种设计模式,主要解决开发Web应用程序单客户端的问题。尤其是，它把业务逻辑从视图组件中分离出来了，并允许明确的状态过渡处理。因此，我们认为它适合本文讨论的 Web 应用程序的类型，即，典型的瘦客户端 intranet 应用程序。虽然许多成功的概念也可以用与其他 J2EE 核心模式相结合 (http://java.sun.com/blueprints/corej2eepatterns/) 或更一般的 MVC 设计模式，服务工作模式提供我们扩展以便普适计算的应用程序的最佳基础发展。对工作者模式服务是的组合前端控制器和视图帮助器模式J2EE 的表示层。更严格的讨论J2EE 设计模式，请参阅 [3]和 http://java.sun.com/j2ee/。其主要的功能已经添加到MVC 架构，构成整体的能力并过渡到专用调度程序类的逻辑比控制器。调度程序访问 XML 文件定义所有的现有状态，并将相关联的用户操作与状态转换。与现有基于 MVC 的框架普适计算 Web 应用程序 （例如，MVCPortlets 的 IBM WebSphere 各地访问门户4.2.1 服务器） 本文所述的概念并不使用多个特定于设备的控制器类。在我们方法，该控制器具有只有两个责任 ︰在每次请求传递给调度程序和需要时，调用相应的业务服务。然而这些业务服务仅调用时的应用任务状态更改。既然所有设备都有共同之处，因此任务状态转移模型独立于设备的控制器类是可以的。
4.2 扩展工作者模式的服务
工作者模式的服务并没有充分满足普适计算发展的需要。作为在前一小节中提到工作者模式服务的 Sun 公司的规范,本文介绍了一个调度程序类来处理状态转换。然而，它既不规定如何模型状态过渡 （XML 文件），内部的逻辑，也不包括运行时的构件描述的实现这种模式。再者，由于工人提供的服务模式为单个设备访问设计。特定于设备的视图的问题必须加以解决。即使第 3 节中提供的算法不给任何实现细节。我们将就这些问题现在描述一种实现方法和更多的技术细节。
为了建模设备无关状态转型的逻辑，我们使用 XML 文件命名。（建议http://java.sun.com/mappings.xmlblueprints/patterns/FrontController.html)。对于特定于设备的视图逻辑，我们利用额外的文件来为每个支持的设备命名 viewmappings.xml。两个描述定义状态，有限状态自动机操作和转换。我们建议实施这些自动机作为两个专用 JavaBeans 类 ︰ TaskStateBean 和ViewStateBean (图 3)。两者都是使用数据初始化上面描述的 XML 文件。在运行时，他们提供 getstate （） 和 doAction(String) 方法。前者返回的当前状态和后者执行指定的操作和返回任一新状态或引发的异常-如果是非法的行动。
此外，TaskStateBean 可以引用设备特定的 ViewStateBean，为每个任务的状态，如果视图以前完成任务状态已被保留。例如，如果用户点击 返回搜索视图 他留在展开的状态，它可以当用户再次返回时呈现在展开状态。特定于设备的呈现被通过视图特定于精确的组件 （JSP文件）设备。存在一个单一的 JSP 文件为每个任务/设备。包含视图特定于标记的组合，因此，还必须包括用于访问代码的ViewStateBean 信息。所有 JSP 文件可能都被放置在一起，并在设备相关的子文件夹中放置合适的viewmapping
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[154039]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
