Analyzing Interaction Orderings with Model

Checking

SupportUS National Science Foundation (NSF CISE/SEL)US Department of Defense Advanced Research Projects Agency (DARPA/IXO PCES) US Army Research Office (ARO CIP/SW)

Matthew B. Dwyer (University of Nebraska) Robby, Oksana Tkachuk (Kansas State

University)Willem Visser (NASA Ames Research Center)

Model Checking GUIs

Problems State space explosion due

to large data domains Swing framework complexity

General Solutions Modular Verification Abstraction Reduction

Our Solutions

Modular verification Treat GUI implementation as

module Domain-specific abstractions

Swing framework Underlying application

Domain-specific model checking Customized reductions

Our Solutions

Are implemented in Bandera Environment Generator

(BEG) Extensible model generation/extraction

tool Bogor

Extensible model checker

Unit

Code Base

Finds points of interaction (unit interface)

Identifies environment classes that directly interact with the unit

Method calls Field access

Cuts away classes that don’t directly interact with the unit

Generates models for the remaining classes

Bandera Environment Generator

Environment Models in BEG

Universal environments Safe but impractical

Synthesized from environment assumptions User-supplied Automatically extracted from

environment implementation using static analysis techniques

Modular Verification using BEG

Unit

Code Base

Drivers

Environment classes are broken into

Active classes hold a thread of control (drivers)

Passive classes (stubs)

Stubs

Closed Unit

Java + modeling primitives

+ Unit Properties Java Model Checker

Bogor – Domain Specific Model-Checking

Extensible modeling language and plug-in architecture allows Bogor to be customized to a variety of application domains

Modeling language and Algorithmseasily customized to different domains

Domain Y Domain Z

Domain X

Model Checker

Variety of System Descriptions

Design NotationsDesign Notations

Byte codeByte code

State MachinesState Machines

Source codeSource code

Different levels of

abstraction!

Different levels of

abstraction!

Abstract machine tailored to domain and level of abstractionAbstract machine tailored to domain and level of abstraction

Domain-Specific Model Checking

Model-checkingEngine

BEG modelsBEG models

Domain & AbstractionExtensions

GUI GUI

Bogor Extensions

Modeling Language Extensions Type extensions Expression extensions Action extensions

Module Extensions interpretative component extensions model checking component extensions

Our Approach: Modeling

BEG + manual refinement

BEG abstraction

Swing Lib Model

GUI

Application Model

User Model

Display

Swing Lib

GUI

Application

User Property

Java to BIR

Translator

Interaction Ordering Properties

Automata-based sequencing properties For example, regular expressions

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

English: when an error message is displayed, the only available user action is acknowledgement via ok button

Next…

Extension of BEG to Discover/Analyze Swing classes Model Swing classes

Extension of Bogor to Handle BEG modeling primitives Implement domain-specific state storage

strategies

Identifying GUI components

BEG scans GUI implementation for Swing references

BEG analyzes the actual code of Swing classes and generates models for them based on analysis results

GUI Impl

Swing Components

BEG Analysis for Swing Classes

Customized Side-Effects analysis is used to identify: Containment relationships Publish-Subscribe relationships Visibility Enabledness Modality

Analysis results/models can be used across multiple examples

public class Container extends Component{ Component[] component = new Component[0]; public Component add(Component comp) { addImpl(comp, null, -1); return comp; } protected void addImpl(Component comp, Object constraints, int index){ if (ncomponents == component.length) { Component newcomponents[]=new Component[..]; component = newcomponents; ... } if (index == -1 || index == ncomponents) { component[ncomponents++] = comp; } else { component[index] = comp; ncomponents++; } ... }}

Example: actual code

public class Container extends Component{ Component[] component = new Component[0]; public Component add(Component comp) { addImpl(comp, null, -1); return comp; } protected void addImpl(Component comp, Object constraints, int index){ if (ncomponents == component.length) { Component newcomponents[]=new Component[..]; component = newcomponents; ... } if (index == -1 || index == ncomponents) { component[ncomponents++] = comp; } else { component[index] = comp; ncomponents++; } ... }}

Method Analysis

// must side-effects this.component[TOP_INT] = param0;this.ncomponents = TOP_INT

// may side-effectsComponent[] component0 = new Component[TOP_INT];...this.component = component0;

//return locations{ param0 }

public class Container extends Component{ Component[] component = new Component[0]; public Component add(Component comp) { addImpl(comp, null, -1); return comp; } protected void addImpl(Component comp, Object constraints, int index){ if (ncomponents == component.length) { Component newcomponents[]=new Component[..]; component = newcomponents; ... } if (index == -1 || index == ncomponents) { component[ncomponents++] = comp; } else { component[index] = comp; ncomponents++; } ... }}

From Analysis to Model

// must side-effects this.component[TOP_INT] = param0;this.ncomponents = TOP_INT

//return locations{ param0 }

public class Container extends Component { Component[] component; int ncomponents; public Component add(Component param0){ component[ncomponents] = param0; ncomponents++; return param0; }}

Modeling User

The user may click on any visible enabled components

GUI Impl

User

On the most recently opened modal window or on any non-modal window, if no modal windows are open

Modal vs. Non-modal Dialogs

Set nonModalWindows

Stack modalWindows

Modal vs. Non-modal Dialogs

Set nonModalWindows

Stack modalWindows

Modal vs. Non-modal Dialogs

Set nonModalWindows

Stack modalWindows

Modal vs. Non-modal Dialogs

Set nonModalWindows

Stack modalWindows

Modal vs. Non-modal Dialogs

Set nonModalWindows

Stack modalWindows

Choosing Top-Level Window

Set nonModalWindows

Stack modalWindows

public Window chooseTopWindow() {

Window window = null;

if(!modalWindows.empty()) window = modalWindows.pop(); else

window=chooseReachable("Window“, nonModalWindows);

return window;

}

Choosing Top-Level Window

Set nonModalWindows

Stack modalWindows

public Window chooseTopWindow() {

Window window = null;

if(!modalWindows.empty()) window = modalWindows.pop(); else

window=chooseReachable("Window“, nonModalWindows);

return window;

}

Choosing Top-Level Window

Set nonModalWindows

Stack modalWindows

public Window chooseTopWindow() {

Window window = null;

if(!modalWindows.empty()) window = modalWindows.pop(); else

window=chooseReachable("Window“, nonModalWindows);

return window;

}

Choosing Top-Level Window

Set nonModalWindows

Stack modalWindows

public Window chooseTopWindow() {

Window window = null;

if(!modalWindows.empty()) window = modalWindows.pop(); else

window=chooseReachable("Window“, nonModalWindows);

return window;

}

User Model

while (true) { window = chooseTopWindow();

container = chooseReachable( "JComponent", window,

isVisible, isEnabled);

notifyListeners(container) }

User Model

while (true) { window = chooseTopWindow();

container = chooseReachable( "JComponent", window,

isVisible, isEnabled);

notifyListeners(container) }

Notification

An event object is created and passed to the event-handling code of listeners registered on the clicked component

This event object is abstract If the event is queried, the query will

result in a nondeterministic choice This leads to exploring all possible

events

Modeling Primitives (Recap)

express environment nondeterminism choose()

chooseInt(int n, int m)

chooseClass(boolean subType, String type, boolean isVisible, boolean isEnabled)

chooseReachable(boolean subType, String type, Object from, boolean isInvisibleComponent, boolean isVisible, boolean isEnabled)

extension Choose for bogor.ext.ChooseModule { expdef boolean chooseBoolean(); expdef int chooseInt(int, int); expdef 'rec$a chooseObject<'a>(boolean, 'rec$a -> boolean ...); expdef 'rec$a chooseReachableObject<'rec$a>(boolean, Object, Object -> boolean, 'rec$a -> boolean ...);}

fun isVisible(Component c) returns boolean = c.visible;fun isEnabled(Component c) returns boolean = c.enabled;fun isInvisibleComponent(Object o) returns boolean = o instanceof Component && !isVisible((Component) o);

Bogor Extensions (Syntax)

package bogor.ext.ChooseModule...public class ChooseModule implements IModule { ... public IValue chooseBoolean(IExtArguments args) { IValue[] values = new IValue[] { vf.newIntValue(0), vf.newIntValue(1) }; int index = ss.advise(..., values, args.getSchedulingStrategyInfo()); return values[index]; }}

Bogor Extensions (Semantics)

Store-States-On-Choose (SSC ) Strategy

BEG models execute event-handling code in a single thread

BEG models are sufficient to check ordering properties

State-space branching occurs only in states where choose primitives are evaluated, only such states are stored

Such strategy preserves interaction properties

Evaluating SSC StrategyExample Measure ALL SSC

Voting DialogsObjects: 50Choices: 3Locations: 7563

TransStatesSpace (Mb)Time (s)

1920181640.24

2045739.60.8

Voting DialogsObjects: 120Choices: 4Locations: 8269

TransStatesSpace (Mb)Time (s)

3114293045.510

46301744.51

Dialog DemoObjects: 257Choices: 14Locations: 8689

TransStatesSpace (Mb)Time (s)

884938443974.3512

181512103347.638

Calculator:Objects: 362Choices: 24Locations: 8789

TransStatesSpace (Mb)Time (s)

290162790366.4183

3557410548.620

Evaluating SSC StrategyExample Measure ALL SSC

Voting DialogsObjects: 50Choices: 3Locations: 7563

TransStatesSpace (Mb)Time (s)

1920181640.24

2045739.60.8

Voting DialogsObjects: 120Choices: 4Locations: 8269

TransStatesSpace (Mb)Time (s)

3114293045.510

46301744.51

Dialog DemoObjects: 257Choices: 14Locations: 8689

TransStatesSpace (Mb)Time (s)

884938443974.3512

181512103347.638

Calculator:Objects: 362Choices: 24Locations: 8789

TransStatesSpace (Mb)Time (s)

290162790366.4183

3557410548.620

Limitations

Real GUIs are not single-threaded To address deadlock/locking

properties, sophisticated analyses needed to

extract models that preserve threading/locking behavior

This work treats ordering properties only

Related Work

GUI Ripping: reverse engineering of GUIs [Memon et al.]

SMV MC GUI models [Dwyer et al.] MC HCI models [Campos, Harrison,

Rushby] (Murphi, SMV, SPIN) Modeling Event-Handling [Chen] Modeling and MC of GUIs [Berstel et

al.]

Summary

Overview of BEG Overview of Bogor Presentation of

Modeling and Model checking strategies for checking

ordering properties of GUIs For more information on tools

http://bandera.projects.cis.ksu.edu