Title: Analyzing Interaction Orderings with Model Checking
1Analyzing Interaction Orderings with Model
Checking
Matthew B. Dwyer (University of Nebraska) Robby,
Oksana Tkachuk (Kansas State University) Willem
Visser (NASA Ames Research Center)
Support
US National Science Foundation (NSF CISE/SEL) US
Department of Defense Advanced Research Projects
Agency (DARPA/IXO PCES) US Army Research Office
(ARO CIP/SW)
2 Model Checking GUIs
- Problems
- State space explosion due
- to large data domains
- Swing framework complexity
- General Solutions
- Modular Verification
- Abstraction
- Reduction
3Our Solutions
- Modular verification
- Treat GUI implementation as module
- Domain-specific abstractions
- Swing framework
- Underlying application
- Domain-specific model checking
- Customized reductions
4Our Solutions
- Are implemented in
- Bandera Environment Generator (BEG)
- Extensible model generation/extraction tool
- Bogor
- Extensible model checker
5Bandera Environment Generator
- Finds points of interaction (unit interface)
- Identifies environment classes that directly
interact with the unit - Method calls
- Field access
- Cuts away classes that dont directly interact
with the unit - Generates models for the remaining classes
Unit
Code Base
6Environment Models in BEG
- Universal environments
- Safe but impractical
- Synthesized from environment assumptions
- User-supplied
- Automatically extracted from environment
implementation using static analysis techniques
7Modular Verification using BEG
Java modeling primitives
- Environment classes are broken into
- Active classes hold a thread of control (drivers)
- Passive classes (stubs)
Unit Properties ? Java Model Checker
Code Base
Closed Unit
8Bogor Domain Specific Model-Checking
Modeling language and Algorithms easily
customized to different domains
9Variety of System Descriptions
Different levels of abstraction!
10Domain-Specific Model Checking
BEG models
Model-checking Engine
11Bogor Extensions
- Modeling Language Extensions
- Type extensions
- Expression extensions
- Action extensions
- Module Extensions
- interpretative component extensions
- model checking component extensions
12Our Approach Modeling
Property
Display
User Model
BEG manual refinement
Swing Lib Model
Java to BIR Translator
GUI
BEG abstraction
Application Model
13Interaction Ordering Properties
- Automata-based sequencing properties
- For example, regular expressions
- . displayerror buttonok .
- English when an error message is displayed, the
only available user action is acknowledgement via
ok button
14Next
- 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
15Identifying 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
16BEG 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
17Example actual code
- public class Container extends Component
Component component new Component0
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 newcomponentsnew Component..
component newcomponents ... if
(index -1 index ncomponents)
componentncomponents comp else
componentindex comp ncomponents
...
18Method Analysis
//return locations param0
- public class Container extends Component
Component component new Component0
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 newcomponentsnew Component..
component newcomponents ... if
(index -1 index ncomponents)
componentncomponents comp else
componentindex comp ncomponents
...
// may side-effectsComponent component0 new
ComponentTOP_INT...this.component
component0
// must side-effects this.componentTOP_INT
param0this.ncomponents TOP_INT
19From Analysis to Model
//return locations param0
- public class Container extends Component
Component component new Component0
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 newcomponentsnew Component..
component newcomponents ... if
(index -1 index ncomponents)
componentncomponents comp else
componentindex comp ncomponents
...
public class Container extends Component
Component component int ncomponents
public Component add(Component param0)
componentncomponents param0
ncomponents return param0
// must side-effects this.componentTOP_INT
param0this.ncomponents TOP_INT
20Modeling User
- The user may click on any visible enabled
components
- On the most recently opened modal window or on
any non-modal window, if no modal windows are open
21Modal vs. Non-modal Dialogs
Set nonModalWindows
Stack modalWindows
22Modal vs. Non-modal Dialogs
Set nonModalWindows
Stack modalWindows
23Modal vs. Non-modal Dialogs
Set nonModalWindows
Stack modalWindows
24Modal vs. Non-modal Dialogs
Set nonModalWindows
Stack modalWindows
25Modal vs. Non-modal Dialogs
Set nonModalWindows
Stack modalWindows
26Choosing Top-Level Window
Set nonModalWindows
public Window chooseTopWindow() Window window
null if(!modalWindows.empty()) window
modalWindows.pop() else windowchooseReachabl
e("Window, nonModalWindows) return
window
Stack modalWindows
27Choosing Top-Level Window
Set nonModalWindows
public Window chooseTopWindow() Window window
null if(!modalWindows.empty()) window
modalWindows.pop() else windowchooseReachabl
e("Window, nonModalWindows) return
window
Stack modalWindows
28Choosing Top-Level Window
Set nonModalWindows
public Window chooseTopWindow() Window window
null if(!modalWindows.empty()) window
modalWindows.pop() else windowchooseReachabl
e("Window, nonModalWindows) return
window
Stack modalWindows
29Choosing Top-Level Window
Set nonModalWindows
public Window chooseTopWindow() Window window
null if(!modalWindows.empty()) window
modalWindows.pop() else windowchooseReachabl
e("Window, nonModalWindows) return
window
Stack modalWindows
30User Model
while (true) window chooseTopWindow()
container chooseReachable(
"JComponent", window,
isVisible, isEnabled) notifyListeners(con
tainer)
31User Model
while (true) window chooseTopWindow()
container chooseReachable(
"JComponent", window,
isVisible, isEnabled) notifyListeners(con
tainer)
32Notification
- 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
33Modeling 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)
34Bogor Extensions (Syntax)
- extension Choose for bogor.ext.ChooseModule
expdef boolean chooseBoolean() expdef int
chooseInt(int, int) expdef 'reca
chooseObjectlt'agt(boolean, 'reca -gt boolean
...) expdef 'reca chooseReachableObjectlt'reca
gt(boolean, Object, Object
-gt boolean, 'reca -gt boolean ...) - fun isVisible(Component c) returns boolean
c.visiblefun isEnabled(Component c) returns
boolean c.enabledfun isInvisibleComponent(Obje
ct o) returns boolean o instanceof Component
!isVisible((Component) o)
35Bogor Extensions (Semantics)
- 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
valuesindex
36Store-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
37Evaluating SSC Strategy
Example Measure ALL SSC
Voting Dialogs Objects 50 Choices 3 Locations 7563 Trans States Space (Mb) Time (s) 1920 1816 40.2 4 2045 7 39.6 0.8
Voting Dialogs Objects 120 Choices 4 Locations 8269 Trans States Space (Mb) Time (s) 3114 2930 45.5 10 4630 17 44.5 1
Dialog Demo Objects 257 Choices 14 Locations 8689 Trans States Space (Mb) Time (s) 88493 84439 74.3 512 181512 1033 47.6 38
Calculator Objects 362 Choices 24 Locations 8789 Trans States Space (Mb) Time (s) 29016 27903 66.4 183 35574 105 48.6 20
38Evaluating SSC Strategy
Example Measure ALL SSC
Voting Dialogs Objects 50 Choices 3 Locations 7563 Trans States Space (Mb) Time (s) 1920 1816 40.2 4 2045 7 39.6 0.8
Voting Dialogs Objects 120 Choices 4 Locations 8269 Trans States Space (Mb) Time (s) 3114 2930 45.5 10 4630 17 44.5 1
Dialog Demo Objects 257 Choices 14 Locations 8689 Trans States Space (Mb) Time (s) 88493 84439 74.3 512 181512 1033 47.6 38
Calculator Objects 362 Choices 24 Locations 8789 Trans States Space (Mb) Time (s) 29016 27903 66.4 183 35574 105 48.6 20
39Limitations
- 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
-
40Related 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.
41Summary
- 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