Analyzing Interaction Orderings with Model Checking 个人翻译，需要的拿

1、个人翻译，仅为分享，但转贴请注明出处。

2、翻译的不是很到位，因为一些原文的一些词汇很模棱两可，比如method是方法还是函数之类的。敬请谅解，欢迎指正。

3、Analyzing Interaction Orderings with Model Checking 一文需要的自己谷歌。还有，里面所有的figure，也就是图和代码，可以自己从原文中截取。

基于模型检查的交互管理分析

 

MatthewB. Dwyer, Robby, Oksana Tkachuk

KansasState University

Manhattan,KS 66506, USA

｛dwyer,robby,oksana｝@cis.ksu.edu

 

WillemVisser

RIACS,NASA Ames Research Center

MoffettField, CA 94035, USA

wvisser@email.arc.nasa.gov

 

摘要

人机交互(HCI)系统控制终端用户和计算机系统之间的互动。对于软件密集型系统，一个图形用户界面(GUI)通常被用于可用性的增强。在人机交互(HCI)系统传统的GUI方面可用性的验证方法涉及原型和live-subject测试。这些方法覆盖可能的人机交互的能力被限制在系统可能允许的范围，因为模式的交互可能是长期运行的，并且有大量的替代品。

在本文中，我们提出一个静态分析，能够对用Java编写并使用现代GUI框架的HCI应用程序的GUI部分进行用户交互属性的推理，例如Swing ^TM。我们的方法划分HCI应用程序为三个部分:Swing库，GUI的实现，即直接与Swing交互的代码，底层应用程序。我们为每一部分开发模型，用来保存与交互顺序有关的行为。我们将描述这些模型是如何生成的，以及我们如何定制了一个以有效地分析其组合的模型的框架。

1、介绍

    现代软件正在有越来越多的丰富功能集成到关键任务流程。图形用户界面（GUI）用来促进效率和有效的人机交互（HCI）的方式如下：（a）以窗体表格的形式展示应用程序数据，以使人类快速和清楚地了解该数据，（b）通过呈现用户基于底层应用数据状态可以被允许的行为来指导和控制交互行为。传统的GUI验证包括设计一个图形用户界面的原型并且执行现场测试以评估这些问题。接受现场测试显然是必要的，尤其是在评估图形界面的易用性以及人体工程学方面，但是在每一步交互中提供给用户的替代品的数量和用户和系统之间的交互作用的潜在交互的长期存在性使得测试所有可能的交互请求成为不可能。

在本文中，我们提出一个静态的方法来分析下在Java Swing框架实现的一个GUI系统所执行的所有可能的交互行为的程序的行为。我们将在第三章详细讨论Swing，但重要的是要明白，它提出了静态分析的几个挑战。

Swing是一个面向对象的框架，窗口和部件在窗口上（例如，按钮，选择框和文本输入框），文本和颜色关联到部件和窗口，以及众多的通过实例框架类定义的附加属性。这些类通过实例之间的引用定义了部件的可见性、形式以及可用性的信息对于定义用户界面响应用户行为的发展状态是至关重要的。

Swing是一个事件驱动的框架，可以转移和内部化应用程序的控制流。程序员定义的函数称为事件处理句柄，响应出现的称为事件的用户行为，比如按下一个按钮。句柄函数通过框架调用事件和句柄的对应关系记录来绑定到相关事件。该框架执行一个循环的事件分派线程，依次处理每个事件并调用相关的句柄函数。

对象的值和对象引用的关系被用来定义一个Swing GUI的结构和行为，这一事实意味着传统的不捕获程序数据值的静态分析方法是有限使用的;需要更精确、对象敏感的分析方法。这一观察结果带领我们在以往工作中探索GUI行为的推理手段的模型检查[8]。在本文中，我们应用软件模型检查方法[5，18，22]自动化和模型化的分析Java GUI在现实系统中的交互顺序。在本文中，我们应用软件模型检查方法[5，18，22]自动化和模型化的分析Java GUI在现实系统中的交互顺序。我们的做法将人机交互应用程序分割成三部分：Swing框架，GUI实现（即，与Swing GUI的配置结构，并实现其控制逻辑进行交互GUI设置和事件处理程序代码），和底层的应用程序（即GUI和应用程序的命令行版本的公共的代码）。以这种方式分解应用程序，我们可以针对不同技术的每个部分分别提取其行为的真实和合适的精确模型。这是至关重要的，因为众所周知的，据分析，模型检查的代价随着系统的规模成倍增长。为了实现GUI交互的顺序联系行为的有效的检查模型，我们建立了一个单一事件派发线程的GUI模型，有效的为用户每一步的交互体on过了较大的探索空间，并且抽象了底层应用程序的数据状态。

我们使用班德拉环境发生器(BEG)[20，21]来执行Swing框架的程序间副作用的精确的分析，以了解该框架的类和函数可以影响事件控制句柄的执行；这一分析结果构成了每一个框架方法的初步的近似的行为模型并且随后手工精制。我们也是用BUG来自动生成底层应用程序的类和函数的安全的近似模型。这些应用程序模型可扩展性通过折叠应用程序数据到少数有代表性的抽象值而牺牲了精度。在第三节的讨论，这一抽象并不妨碍分析，因为GUI的实现通常对特定的应用程序数据值并不敏感。最后，我们使用BEG的模型提取技术[5]生成有限状态模型，捕获控制流程结构、本地计算和Swing与GUI实现的应用程序函数调用。其结果的模型组合安全地捕获了事件相关的GUI行为，而抽象GUI的其他方面，例如，颜色，形状，大小，和底层应用程序。此外，该模型保留了事件驱动的Swing体系结构。我们利用这种结构，以尽量减少GUI的单一事件分派线程的分析过程中存储的可见的程序状态数量。我们自定义的模型检查框架中的这种优化实现，Bogor[18]，要求只有轻微的修改，但是，正如我们在第5节表明的，它可以显著降低分析成本。

本文的贡献包括：（i）提交了开发GUI应用程序的框架的组成和模型构建，（ii）描述了生成复制的库的框架的一个半自动化的方法，（iii）描述了通过自定义模型检查算法来利用GUI框架的语义减少状态空间的方法，（iv）初步证据表明，总体思路扩展到分析功能可以在JavaSwing GUI代码中建立。最后，我们相信，这项工作为灵活和可定制的模型检测框架，如Bogor，并利用特定的软件的域的属性以实现高效和精确的分析提供了进一步的证据。

下一节我们将给出我们的分析方法的概述，并给出一些关于我们模型检查工具的背景。第3节表述Swing框架和我们的框架行为模型，因为它涉及到用户交互和处理事件句柄的代码顺序。第4节给出了一个Bogor模型检测框架的概述，讨论了几个已经建立的减少分析成本的优化。我们在第5接描述了我们的方法的应用程序和一些Java的GUI工具，评估了扩展到大应用程序的可能性。第6节讨论相关工作，我们在第7节总结。

2、背景和概述

软件模型检查领域已经发展了五年。当前的工具已经可以处理上万行代码的Java程序并且支持几十个线程。这种形式的分析基础很复杂，然而这是不可避免的。确定语义保持状态空间的抽象和还原技术并允许在分析过程中跳过系统行为的某些细节这一发展日趋成熟的技术，已经取得了进展。在本节中，我们简要介绍一下Java程序，和Swing GUI的实现，在我们的分析的基础上介绍两个框架的各种形式的抽象和还原。

Bandera环境发生器（BEG）[20，21]，是分析Java规范和实现，综合且安全地接近他们的行为的模型的框架。本文与BEG最相关的方面，是其别名和副反应分析。BRG分析部分代码基础上的指定的程序的类或域的影响。一个指定集合包含了相关的类或领域，被称为单元，一个函数（或类）的集合进行分析。BEG计算基于单元的每个方法的总结的副反应；注意到总结编码从命名方法降序传递影响整个调用树。

BEG使用一个基于别名分析的上下文相关的进入路径来控制副反应计算，并且可以用来完善它可能的副反应的总结通过使用必须和路径敏感的副反应的信息。这些总结Java代码中使用特殊的建模原语，超过部分代表对象集的机制堆编码的非确定性选择操作的具体化。因此，BEG可以看作计算单位代码基地的行为的抽象。在以往的工作中，我们用BEG与Java探路者（JPF型）模型检查[22]结合分析了几个大的应用，包括多千条飞机线路模拟座舱显示。想获得更多关于BEG的信息请登录http://beg.projects.cis.ksu.edu.

Bogor[18]是一个可扩展的高度模块化的模型检查框架，被设计为缓和为了动态确定和并发软件的粗略和高效特殊域模型检查的发展。在之前的工作中，我们展示了模型检查的成本可以通过借用特定域信息显著减少（即，以重要性排序）。例如，特定域抽象[6]，状态空间结构[10]和对象访问及锁定原则[9]。

相对比，其他的模型检查器如Spin[13]，Bogor的模型检查语言（BIR）在现代编程语言中提供常见的高级功能，如对象和线程的动态创建，函数的动态分布，异常处理，等等。而且，BIR是可扩展的—它允许引用新的抽象数据类型和抽象操作作为语言的第一流的构建。相类似的，添加新的本地类型和本地说明到一个核心BIR虚拟机。

另一个Bogor的值得注意的功能是它的模块化架构。它被设计为使用著名的设计模式[11]来清理应用程序接口（API）。这将使算法合并很容易，以降低模型检查的成本。想获得更多关于Bogor的信息请登录http://bogor.projects.cis.ksu.edu。

2.1 我们的方法

图1的左侧阐明了Swing应用程序的三层架构。这一构架包含主要执行线程，控制显示图形的打印，并且处理用户输入产生关于应用程序的事件。GUI的实现部分的组成包括直接操作Swing类型的应用程序代码，例如，配置GUI的结构和定义注册事件处理函数。底层应用是应用程序的剩余部分，定义为不直接依赖于Swing类型的程序。

我们的目标是推论GUI的实现所允许的用户交互的顺序；我们称之为交互管理。直观地，不同的Swing应用层运用不同的影响角度来控制整体应用程序关于交互管理部分。

下一章的讨论结果，Swing被允许定义窗口对象以控制控件的可见性和可用性，该控件或为用户初始交互。Swing的事件控制句柄的调用机制同样也是一个在控制函数中的定义顶层控制流的重要的角色，这个机制可以依次改变呈献给用户的交互。另一方面Swing类型提供大量且多种多样的选项用来控制管理GUI的视觉方面；这些细节与交互管理并不相关。我们的方法是建立一个单一模型，是关于Swing框架的交互管理相关行为的。这一框架的模型的精确度是挑剔的，如果我们的分析是有用的话。为达到这样的目的，我们配置BEG来保存Swing框架的交互管理相关类型和域。这样的产物是一个总结，关于在Swing的API中每个函数的交互管理相关框架数据的副反应的总结。听起来，近似的，模型被当作一个起始点用来手动的建立更多的准确模型。这个模型在很多分析中可以被重复使用，因此它的架构的开销其实是被分摊的。

我们使用Bandera[5]中的技术将GUI实现代码直接转化为BIR，即Bogor的输入语言。在应用Bandera转换时一个需要关心的地方是对象被无限创建的可能性，但我们在GUI实现中没有遇到过这种情况。大量的Swing对象一般是被创建用来定义GUI的结构的，但是这些对象是从初始化以后基本上不变动的。事件控制函数可以创建本地数据用来运行计算，但是大多数的数据都是函数内的而且当函数返回时会会被当作垃圾回收，而且这些无法跳出函数的数据，例如输出到GUI显示的字符串，是抽象的，因为我们只保存交互管理而不保存涉及到交互的准确数据。

BEG被底层应用程序调用来计算它对GUI实现的数据的影响。在我们的实验中，这些影响都是最小的而且结果是应用程序的非常粗糙的抽象。这一趋势不会引起问题因为事件控制的行为是被应用程序函数调用精确测试返回的值或者事件控制流已经被精确模型化。

最后，用户也被模式化以使能够选择任何操作，在一个GUI中给定的状态的可见性和可用性。该模式描述了如上的定义，状态和一个Bogor扩展用来执行这些输入行为的不确定选择，详细的描述在第4章。

交互管理属性 在本文里，我们将焦点放在抽象和分析GUI交互管理属性，而不是他们自己的属性。在之前的工作中，我们探索了关于GUI系统[8]中的人机交互的一系列安全的属性。工作中，我们使用计算树逻辑[15]来表达属性，但是他们可以同样的使用基于模式[7]的方法来规则表达。例如，一个属性比方说“当一个错误消息显示出来的时候，唯一可用的用户行动就是众所周知的点击‘ok’按钮”这可以通过分析系统来检查以保证没有执行符合规则表达

.;display[error]; ^button[ok]]; .*

该式编码规则的相反（即，这个error信息的现实是跟随着通过一个其他不是按下ok按钮的行为）。Bogor有个扩展可以检查安全的属性表达作为有限状态自动机因此这个自适应我们的分析框架。

3、在Swing^TM模型化时间控制句柄

一个典型的GUI应用程序创建一些窗口和控件。用户跟应用程序交互的时候，这些窗口和控件随着交互的改变而可用。图2展示了一个简单的Swing例子。图中展示的状态，一个应用程序展示了四个窗口：主窗口（左侧），非模式对话框（右上侧）和两个模式对话框（右下侧）。

3.1 模型化组件

模型化GUI组件的重要的一步是标识他们的抽象状态。Swing是一个非常大的库，而不是详尽的描述各个组件的抽象状态，我们描述我们例子中的组件的抽象化原理。

一个模式对话框是一个限制了下一个可用的用户交互行为的窗口；所有其他行为是不可用的。我们通过保持模式的轨迹为对话的抽象状态的一部分来模型化这种限制。我们保持该系统中所有可用窗口的轨迹为两种结构：一组窗口而不限制用户交互（如，画面和非模式对话框）和一堆限制窗体（如，模式对话框）。在每一步，如果第二个结构是非空的，那么用户将与位于窗口顶部的模式对话框交互。如果这里没有模式对话框打开，那么用户可以与存在的任何窗口进行交互。在图2中，这一系列非限制窗口包括主窗口和非模式对话框；模式对话框包括其他两种窗口，错误消息对话框在顶部。在这一状态，用户被限制使用出错对话框。

一旦用户选择了一个窗口来使用，他或她将可以选择窗口的可见且可用的组件。不可见的组件和他们的子组件是不可以被绘制在屏幕上的，例如，图2中的主画面的左侧标签。不可用的组件不允许用户选择。我们模型化组件的这些方面通过包括每个插件的可用性和可见性的布尔值。如此，在每一步，用户可以选择从上层窗口可达的可用的组件，跟随一条由可见组件组成的路径。为了保持父子关系的轨迹，我们保存容器属性，例如，在图2中主画面包含一组两个标签的面板，标签和一些按钮。这组标签（或单选按钮），除了容器，显示选择：在某一时刻只有一个项目可被选定。这叫做单选模式，当要更新单选按钮的组件状态是，我们通过询问容器和选择信息来编码。

除了用户可点击的组件，GUI还提供用户可以输入数据的组件，例如，‘Quiz’对话框（译者注：图2中）包括一个输入域以使用户输入文本。用户输入在这种组件的值并不会被当作抽象状态的一部分来明白地存储；操作在这些丢失值必须假定它的类型是合法的。

正确的抽象状态，或者‘More Dialogs’（译者注：图2中），图2中的标签被定义有以下值：父：标签选择组，可见的，可用的，被选择的，包括｛单选按钮组，‘Show It！’按钮｝。

3.2 模型化事件控制

每个GUI组件的抽象状态都被定义有我们模型化的域的值；整个系统的抽象状态被定义通过每个构成的组件的状态。当一个用户在GUI组件上执行一个动作时，一个相应类型的事件将产生然后被送往监听订阅以告知发生了事件。Swing应用程序中的时间控制机制是一个发布-订阅类型的例子。我们的时间分派机制的模型是与早先选择的用户描述模型整合的；图3展示了模型的Java代码。一个窗口被选择来交互通过指定优先模式对话框和选定任何上层窗口或可达的子窗口，如果没有存在的话。窗口被分析来确定他包含的可见的和可用的组件而且它们中的一个被选中。注册该组件的控制器将被通知排队。这个模型的关键是在成堆分派的对象的集合上表达非确定的选择；模型化这些操作的基元将在第4章描述。

GUI事件可以被分离成两类：逻辑事件，与用户行为相一致的，需要与底层应用交互或者GUI控制逻辑，和低层事件，表明动作而且主要由默认的GUI框架自动地处理，例如，坚挺高亮组件或者当鼠标经过时显示一个工具条。我们在工作中关注逻辑事件和他们的控制，尽管低层事件可以被使用同样的机制来处理。

3.3 分析-指导模型定义

在Java中，一个客体可以被它的域的值所表述。举例来说，一个java.awt.Component的实例定义了80多个各种类型的值（如Color background，int width）。通过保存它所有的域的值记录一个Component实例的当前状态成本很高。幸运地，要确定交互管理行为，我们只需要记录关系到组件的逻辑状态的域的值而不是它的外观和感觉。在本章节的剩余部分，我们描述了这一过程，通过分析Swing框架函数以及我们如果转换分析结果为可被Bogor结构的模型。我们关注Component层级来做具体决定。

所有的Swing组件从Component继承属性，包括域visible和enabled。Java.awt.Container是一个Component的子类型，实现了容器属性，通过域Component[ ] component。模式是通过布尔域java.awt.Dialog的modal实现的。Javax.swing.JComponent，一个容器的子孙，生命了EventListenerList listenerList，在这里*Listener类型的监听器（如MouseListener,ComponentListener）可以使用add *Listener方法来注册。所有Swing组件继承这种监听机制。

除了继承特性外，Swing组件声明了域反射他们的特殊特性（例如，标签通过JTabbedPane实现，其声明了Vector pages来记录增加的标签和SingleSelectionModel来保持标签选择的轨迹）。整形域可以影响一个组件中控件的创建数量（例如，int optionType在JPOptionPane中定义了多少个按钮可以在这个面板显示）。幸运地是，这些域只有少量的预定义值（例如，optionType = YES_NO_OPTION产生了一个带有yes和no两个按钮的面板）。

我们使用BEG不良反应分析来指导Swing组件的模型化。我们对保存Swing组件的特殊属性很感兴趣（例如，容器，监听器的注册），我们定义一个专业的不良反应分析，以计算Swing组件的特殊域的不良反应，例如，布尔域（visible，enabled，等等），为容器（数组，列表，等等）和事件监听器服务。

我们通过Container类中的add方法来举例说明这一分析；图4（左侧）展示了它的Java实现的一部分。我们对不良反应分析感兴趣，上面谈论过，这一方法关系到抽象状态的定义。特别的，我们也对component域感兴趣，它用来实现容器属性。图4（右上）展示了BEG的输出，编码不良反应分析的结果。BEG通过分派参数对象给数组中的一个元素来计算方法在component域的不良反应。不幸的，Java代码是很复杂的，因其对函数输入和component域的状态的多重的检查。如果数组太小，一个新数组将被分派，然后每一个旧数组的元素都将被复制到新数组。很难设计静态分析来准确的跟踪这种行为，因此，分析结果可能极度不准确。举例来说，这个分析，当不能记录现实整型变量数据值时，使用TOP_INT值来代表任意整数值。然而，模型作者可以检查分析结果并决定是否还要为引起不准确的行为来建模。假定，我们不希望模型化新建立的数组因为任何这样的错误都可以通过简单的执行应用来检测，然后最终模型，图4（右下），将反应函数的很可能的不良反应。

除了实现容器属性和注册监听器（通过各种add方法）的识别方法之外，该分析是可以识别在特定域没有任何不良反应的方法。Swing中的多数方法只能影响GUI的外观和感觉，因此没有交互管理数据的不良反应。一旦没有不良反应的方法被标识，模型作者可以简单的使用分析结果来建立这些残余方法的行为的模型。

4、定制模型检查

在这一章，我们使用Bogor输入语言BIR来描述GUI应用程序的模型化，同时Bogor的状态存储策略的适配来减少使用单事件分派线程分析GUI的时间和存储需求。

4.1 用BIR模型化GUI应用程序

Java编程语言支持BIR的特性。实际上，Bogor经常被用在Bandera[5]工具集的下一代上，其提供自动化的支持来从Java源代码中提取安全、紧凑且有限状态的模型，以支持模型检查Java程序。然而BIR可以自然的模型化Java程序例如Swing应用程序，它没有原始的为模型描述中使用的不确定选择表达式，在第三章（例如，图3）。因此，我们定义BIR扩展来实现这些原是基础。

图5通过BEG展示了BIR扩展需求。它声明了一个扩展Choose，其有四个新的不确定表达式：（a）chooseBoolean()编码了一个不确定选项介于true和false（b）chooseInt(i, j) 编码了一个不确定选择覆盖了整型数范围i到j（i<j）（c）chooseObject<T>(subTypes, p1,. . . , pn)编码了一个不确定选择覆盖了类型为T的堆对象（例如，这个类型变量’rec$a 被T取代）其满足谓语p1,. . . , pn，这里subTypes表明了它是否需要包含T的子类型。（d）chooseReachableObject<T>(subTypes,o, f, p1,. . . , pn)编码了一个不确定选择覆盖了类型为T的堆对象满足谓语p1,. . . , pn且可从对象o到达而不用到达满足条件f的对象。

BIR提供不良反应自由的一级函数类似于功能编程语言如SML其可以满足条件p1,. . . , pn和f。举例来说，函数isVisble如果给定的Component对象是可见的则返回真值true。

为了说明这一点，BIR表达式（1）在图5中编码了一个不确定选项覆盖了｛0，1，2，3｝。BIR表达式（2）编码了一个不确定表达式覆盖了JComponent的实例（包括子类别）其都是在状态中可见且可用的，这里表达式被评价（或者返回空值，如果这里没有实例）。BIR表达式（3）编码了一个不确定选项覆盖了JButton的实力其是可见的可用的而且可以从对象o到达的而不用穿过不可用的Component组件。举例来说，假定我们有个Java堆对象如图6所示，这里c1，c2和c3都是Component，然后b1，b2和b3是JButton。假定c3不可见，那么评价（3）在部分状态将有不确定选项b1和b2.

图5阐明了BIR语言的句法扩展。类似于添加一个新的指令在解释器，我们也需要提供新表达式的语义。在图5中，我们声明了Choose扩展是一个bogor.ext.ChooseModule这一Java类的实现。图7阐明了chooseBoolean是如何使用Bogor的API实现的。

一般来说，一个BIR表达式扩展是同名的Java方法的实现（例如，Choose.chooseBoolean是ChooseModule.chooseBoolean的实现）。当实现不确定选项覆盖值如图5所示时，这里涉及到两步：（1）创建一个值的数组来选择由来（2）提交该数组到调度程序，以挑选一个值来返回和记录信息以确保所有的选项都是后来选择的。

举例来说，图7中的ChooseBoolean方法创建了一个数组包含一系列false和true值，分别用BIR的整型的数0和1表示。它通过使用Bogor的IValueFactory模块创建了值。一旦该选项数组被创建，它使用调度程序（例如，ISchedulingStrategist模块）通过调用它的advise方法来选择一个值。该调度程序通过存储目前产生的关于当前状态（例如，通过args.getSchedulingStrategyInfo()返回的对象）的与选项有关的信息以确保所有的值都被考虑了。这允许调度程序知道是否存在值来选择来源，和如果存在，当所有成功的状态都被浏览了。当实现chooseObject，只是第一步不同：穿过堆来收集适当类型的满足给定谓词的对象来产生数值数组。Bogor提供了一个可见模式API来穿过声明和堆结构，所以，它很容易实现扩展，就像chooseObject和chooseReachableObject。我们为GGUI相关扩展写的所有代码使用典型Java代码格式少于300 行（LOC）。

4.2 存储-陈述-在选择上的机制

Bogor的结构被设计来减轻它的模型的定制以开发应用程序领域的属性来减少模型检查的成本。我们定制了Bogor来有效检查前面章节提到的技术产生的GUI应用程序的模型。更具体地说，这些模型是单线程的，这反射了事实就是Swing GUI执行时间控制代码在一个单事件分布线程里。尽管是真实实现的简化，这种模型允许检查与交互管理有关的属性。

与一般的多线程应用程序相对比，这里交错可能在每个状态发生，在单事件分派线程的GUI模型中，状态空间中的分支只会当选择结构用来用户选择或底层应用程序的抽象时才会出现。所以，在这个模型中，我们可以减少可能的分支的存储的状态数量并且仍然保存所有的用户交互管理。

我们的方案是在Bogor中修改状态存储策略，只存储一个选择表达式被唤醒时的状态。直观的是这些最早的点使我们可以决定这一选择是否会引起不同状态。在状态空间里可能会有循环，有自由的选项表达式，而且为了避免搜索非中止，我们必须强制状态的存储；我们采取在每个存储的状态直接的转换的最大的数字处设置一个限制这样一个简单的方法。我们实现用Bogor描述来描述这一算法大概有30行代码。我们在下一章节提供数据，其阐明了关于GUI应用的减少获得原因。

4.3 评估其他搜索策略

上面描述的策略只是我们探索过的数个中的一个用来降低GUI应用程序的模型检查交互管理模型的成本。我们实现较少状态的搜索，这里没有状态被存储，然而，这证明了其无效率的随着GUI控件的数量增长；模型中的每一个控件需要一个非确定选项，而且，因此，路径的数量随着空间数量的增长以指数形式增长。

我们也考虑了一个用来减少模型检查系统的存储器需求的技术，其状态空间有一个循环结构[10]。一个系统是类循环的当且仅当在把状态空间投影到一个给定的状态变量的几何上之后可以找到循环。重复局部状态被定义为一个断言φ；φ-一致的状态定义了状态空间的领域的边界。这允许我们把状态空间搜索分开到一个趋于的个别搜索的集合。这个技术展示了卓越的性能用来设计事件触发的嵌入式软件[10]的模型。

GUI应用程序显示了一个类循环结构：Swing中的事件分派线程有一个环来选择事件，查阅他们的注册的控制器，然后调用这些控制器。我们以一个断言和时间循环的页眉为特逗，而且我们可以应用我们的类循环搜索。尽管这个比非优化搜索更减少了内存消耗，在所有情况下这个减少依然少于上面描述的只存储已选的状态的策略。

从这个经验中，我们推断出，不管复杂的减少框架或许会继续在模型检查工具中存在这一事实，这里仍有很大的提升空间。一个灵活的模型检查框架中，替换策略可以被规范和评估，我们可以利用洞察力来研究框架和系统中某个类的行为，像GUI应用程序那样，来建立相对简单且有效的减少。

5、模型检查实验

我们实现了之前章节描述的技术，并且应用他们在一些Java Swing GUI应用程序。这些应用程序，当然并不像大多数真正的程序一样大，包含一些典型的Swing组件。阳历程序的源代码和生成模型可以在线访问http://beg.projects.cis.ksu.edu。

表一呈现了计算整个程序的状态空间的结果，环境是，1.8GHz（32位模式）处理器和最大1Gb的堆，使用Java 2 平台。对于每个样本，我们给出系统运行期间总的对象的数量分配（大部分都是Swing组件和容器的子类型），为用户模型建模的非确定性选项的数量，和在Swing库、GUI实现以及底层应用的组合模型中的控制的数量。因为底层应用的抽象，一个应用的真实的代码行数可以比位置数大几倍。

在所有的测试中，我们使用所有的在Bogor（ALL）中可用的减少和存储压缩技术并且对照了新增的4.2章节中描述的存储-状态已选择的（SSC）这一策略。

我们注意到为这些系统生成模型的时间是可以忽略的，当然除了阅读Swing方法的不良反应总结的手工过程和基于我们对它们真实行为的理解进行的修剪。我们没有保存关于这一部分的过程的详细的时间需求的记录，但是它可能要花几天时间来很好的调整我们的Swing的模型，基于大的近似起始模型。幸运地是，这个过程只发生一次，并且它的开销可以被分摊到很多Java Swing应用程序的分析。

我们的实验并不是展示我们方法的利益通过简单的提交Java程序到工具例如JPF，但是我们注意到这些程序中没有一个可以不借助抽象形式被分析。真实程序的数据状态，Swing组件和容器对象和程序的全部细节和Swing方法，引发巨大的状态空间爆炸。

这个数据清晰的展示了为单分派线程的GUI来定制化分析的好处；运行时多余一份量级的减少在这些例子中获得。我们注意到存储空间的减少并没有如此明显当这些例子比较小之后。我们期待当GUI实现测量，尤其是在无模式对话框的数量方面，值得注意的存储空间减少将被发现。

最后，这个数据应该被考虑为模型检查GUI实现中的第一步。我们验证了很多附加的优化以减少模型检查交互管理的成本。举例来说，我们探索对称的使用来瓦解交互管理，其在不同的调整下突然出现独立的无模式对话框。

6、相关工作

一个目标与我们很相似的方法用GUI Ripper[16]实现，其提取了一个GUI模型当执行一个GUI系统时，使用一个DFS（分布式文件系统）式的程序来打开窗口，穿过事件，和记录GUI状态的信息；提取的模型可以被用来自动测试实例迭代。相对于GUI Ripper在执行GUI期间建立模型，我们的方法是基于静态分析的，保存模型仅仅与GUI的逻辑状态有关。

这里有一个很长的系列工作来应用普通方法来推出HCI应用程序的属性。大多数工作是关注于分析人机交互管理，其可以引起用户对系统状态的理解和计算机系统呈现出的状态这两者之间的不协调。关于这些问题的最好的研究是模式混淆在飞行器自动驾驶系统中[14,19]。这个分析在这个案例中操作一个手工建立的系统的设计或需求模型。其目的是一旦模型通过重复分析和对错误的修改达到更精确，它可以被作为基础来综合GUI控制逻辑。

一些研究[2，3，17]根据这个想法建立了一般的方法用来说明用户界面系统的交互行为，支持交互规范的分析的有模型检查和其他行为分析，和综合GUI实现的部分。从一个高层次的交互规范开始的好处是显而易见的：它消除了复杂的模型提取技术。不幸的是，综合模型发展始于不允许用来建立HCI系统的全功能GUI实现的产生。我们的工作是一个尝试，来度过这个缺口，通过发展模型提取技术来识别和保存编码了交互行为的部分代码的语义，抽象一个应用程序的支架以使其更容易处理检查。

有一些相关的小工作量工作尝试正常模型和推出GUI实现。一个值得注意的例外是Chen的在Java GUI中的事件控制的正常模型[4]，其有效地设置了工作的阶段，就像我们一样。一个相关尝试是建立网络交互模型[12]，在这里一个网络服务被作为一个单线程过程建立模型来通过一个单线程客户端发送事件；尽管模型很简单化，这个模型允许检查网络应用程序的多项特征和交互属性。

我们早先的工作曾考虑使用VisualBasicTM 框架[8]实现GUI。有为这个框架手动建立的模型，事件控制代码和应用程序和使用SMV[15]模型检查器来退出交互管理属性表达用计算树逻辑的有边界安全的属性。在这个文章中提出的这一工作是我们用来探讨Java Swing^TM GUI应用程序的手动模型提取方法的缩放和自动化。

此外，我们利用Bogor模型检查框架的灵活性来实现优化状态空间搜索算法，这利用了GUI应用程序的框架。我们的方式与Behrmann等人的工作很相近[1]，其工作探索了一些启发法的使用来避免状态存储。他们注意点他们的启发法在与深度优先搜索（DFS）算法相结合中性能并不是很好。我们的状态存储启发法与Bogor的基础DFS一起时性能较好，因为我们可以依据句法识别每一个状态需要被存储的点。

7、总结

人机交互的一个决定性的元素是控制逻辑，其引导和限制用户在每一个系统状态时可以被执行的用户操作。在现代Java Swing GUI实现中，控制逻辑通过Swing框架类的实例和用户定义的事件控制函数来扩展。我们建立了一个静态分析框架提取了Java源代码中的控制逻辑，因此可以详细的分析GUI实现的关于交互管理属性方面的行为。此外，SwingGUI有理解性的结构和行为的属性导致了洞察到特定领域的分析优化的可能性和进一步优化的希望。我们实验了这些分析，我们的初始结果在度量Swing GUI的特性和减轻分析成本的潜在的爆炸性增长这两个方面都很鼓舞人心。我们将做进一步的研究和实验，以理解正确性属性的范围和能使分析方法的成本节约的GUI程序的大小。

8、感谢

作者希望感谢堪萨斯州立大学的Santos小组的成员，因为很多关于这篇文章的话题的讨论是非常有用的。

这份论文的研究报告的支持者有美军研究办公室(DAAD190110564), DARPA/IXO’s PCES 项目 (AFRL Contract F33615-00-C-3044), NSF (CCR-0306607) LockheedMartin, Rockwell-Collins, 和IBM公司的Eclipse奖金。

参考文献

[1] G. Behrmann, K. G. Larsen, and R.Pelanek. To store or not to store. In ComputerAided Verification, pages 433–445, Sept. 2003.

[2] J. Berstel, S. C. Reghizzi, G. Roussel,and P. San Pietro. A scalable formal method for design and automatic checkingof user interfaces. In Proceedings of the23rd international conference on Software engineering, pages 453–462, 2001.

[3] J. Campos and M. Harrison. Modelchecking interactor specifications. AutomatedSoftware Engineering, 3(8):275–310, Aug. 2001.

[4] J. Chen. Formal modeling of Java GUIevent handling. In Formal Methods andSoftware Engineering : 4th International Conference on Formal EngineeringMethods, Oct. 2002.

[5] J. C. Corbett, M. B. Dwyer, J. Hatcliff,S. Laubach, C. S. P˘as˘areanu, Robby, and H. Zheng. Bandera : Extractingfinite-state models from Java source code. In Proceedings of the 22nd International Conference on SoftwareEngineering, June 2000.

[6] X. Deng, M. B. Dwyer, J. Hatcliff, G.Jung, and Robby. Modelchecking middleware-based event-driven real-time embeddedsoftware. In Proceedings of the 1stInternational Symposium on Formal Methods for Components and Objects, Nov.2002.

[7] M. B. Dwyer, G. Avrunin, and J.Corbett. Patterns in property specifications for finite-state verification. In Proceedings of the 21st InternationalConference on Software Engineering, May 1999.

[8] M. B. Dwyer, V. Carr, and L. Hines.Model checking graphical user interfaces using abstractions. In Proceedings of the 6th European SoftwareEngineering Conference held jointly with the 5th ACM SIGSOFT Symposium on theFoundations of Software Engineering, volume 1301 ofLecture Notes inComputer Science, pages 244–261. Springer-Verlag, Sept. 1997.

[9] M. B. Dwyer, J. Hatcliff, V. Ranganath,and Robby. Exploiting object escape and locking information in partial orderreduction for concurrent object-oriented programs. Formal Methods in System Design, 2004. (to appear).

[10] M. B. Dwyer, Robby, X. Deng, and J.Hatcliff. Space reductions for model checking quasi-cyclic systems. In Proceedings of the 3^rd InternationalConference on Embedded Software, Oct. 2003.

[11] E. Gamma, R. Helm, R. Johnson, and J.Vlissides. Design Patterns. Addison-WesleyPub. Co., Jan. 1995.

[12] P. Graunke, R. Findler, S.Krishnamurthi, and M. Felleisen. Modeling web interactions. In In Proc. 12th European Symposium on Programming,Lecture Notes in Computer Science, Warsaw, Poland, Apr. 2003. SpringerVerlag.,2003.

[13] G. Holzmann. The model checker SPIN. IEEE Transactions on Software Engineering,23(5):279–294, May 1997.

[14] G. L¨uttgen and V. Carre˜ no.Analyzing mode confusion via model checking. In D. Dams, R. Gerth, S. Leue, andM. Massink, editors, Theoretical andPractical Aspects of SPIN Model Checking (SPIN’99), volume 1680 ofLecture Notes in ComputerScience, pages 120–135, Toulouse, France, September1999. Springer-Verlag.

[15] K. McMillan. Symbolic Model Checking. Kluwer Academic Pub-lishers, 1993.

[16] A. M. Memon, I. Banerjee, and A.Nagarajan. Gui ripping: Reverse engineering of graphical user interfaces fortesting. In 10th Working Conference onReverse Engineering (WCRE’03), pages 260–269,2003.

[17] F. Paterno and C. Santoro. Integratingmodel checking and HCI tools to help designers verify user interfaceproperties. In Interactive Systems -Design, Specification, and Verification : 7th International Workshop, June2003.

[18] Robby, M. B. Dwyer, and J. Hatcliff.Bogor: An extensible and highly-modular model checking framework. In Proceedings of the 9th European SoftwareEngineering Conference held jointly with the 11th ACM SIGSOFT Symposium on theFoundations of Software En-gineering, 2003.

[19] J. Rushby. Using model checking tohelp discover mode confusions and other automation surprises. In D. Javaux,editor, Proceedings of the 3rd Workshopon Human Error, Safety, and System Development(HESSD’99), June 1999.

[20] O. Tkachuk and M. B. Dwyer. Adaptingside effects analysis for modular program model checking. In Proceedings of the 9th European softwareengineering conference held jointly with 10th ACM SIGSOFT internationalsymposium on Foundations of software engineering, pages 188–197. ACM Press,2003.

[21] O. Tkachuk, M. B. Dwyer, and C. S.P˘as˘areanu. Automated envi-ronment generation for software model checking. In Proceedings of the 18th IEEE InternationalConference on Automated Software Engineering, Oct. 2003.

[22] W. Visser, G. Brat, K. Havelund, andS. Park. Model checking programs. In Proceedingsof the 15th IEEE International Conference on Automated Software Engineering,Sept. 2000.