Analyzing Interaction Orderings with Model Checking Matthew B
Analyzing 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)
Model Checking GUIs n Problems n State space explosion due to large data domains n Swing framework complexity n n General Solutions Modular Verification n Abstraction n Reduction n
Our Solutions n Modular verification n n Treat GUI implementation as module Domain-specific abstractions Swing framework n Underlying application n n Domain-specific model checking n Customized reductions
Our Solutions Are implemented in n Bandera Environment Generator (BEG) n n Extensible model generation/extraction tool Bogor n Extensible model checker
Bandera Environment Generator n n Finds points of interaction (unit interface) Identifies environment classes that directly interact with the unit n n Method calls Field access Unit n Code Base n Cuts away classes that don’t directly interact with the unit Generates models for the remaining classes
Environment Models in BEG n Universal environments n n Safe but impractical Synthesized from environment assumptions User-supplied n Automatically extracted from environment implementation using static analysis techniques n
Modular Verification using BEG Java + modeling primitives Drivers Unit Environment classes are broken into n Active classes hold a thread of control (drivers) n Passive classes (stubs) Stubs Closed Code Base Unit + Unit Properties Java Model Checker
Bogor – Domain Specific Model-Checking Modeling language and Algorithms easily customized to different domains Domain X Domain Y Domain Z Extensible modeling language and plug-in architecture allows Bogor to be customized to a variety of application domains
Variety of System Descriptions State Machines Design Notations Model Checker Byte code Different levels of abstraction! Source code
Domain-Specific Model Checking BEG models GUI Model-checking Engine Domain & Abstraction Extensions Abstract machine tailored to domain and level of abstraction
Bogor Extensions n Modeling Language Extensions n n Type extensions Expression extensions Action extensions Module Extensions n n interpretative component extensions model checking component extensions
Our Approach: Modeling User Property Display Swing Lib BEG + manual refinement User Model Swing Lib Model Java to BIR Translator GUI Application BEG abstraction Application Model
Interaction Ordering Properties n Automata-based sequencing properties n 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… n Extension of BEG to n n n Discover/Analyze Swing classes Model Swing classes Extension of Bogor to n n Handle BEG modeling primitives Implement domain-specific state storage strategies
Identifying GUI components n BEG scans GUI implementation for Swing references GUI Impl Swing Components n BEG analyzes the actual code of Swing classes and generates models for them based on analysis results
BEG Analysis for Swing Classes n Customized Side-Effects analysis is used to identify: n n n Containment relationships Publish-Subscribe relationships Visibility Enabledness Modality Analysis results/models can be used across multiple examples
Example: actual code public class Container extends Component{ Component[] component = new Component[0]; public Component add(Component comp) { add. Impl(comp, null, -1); return comp; } protected void add. Impl(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 //return locations { param 0 } public class Container extends Component{ Component[] component = new Component[0]; public Component add(Component comp) { add. Impl(comp, null, -1); // may side-effects return comp; Component[] component 0 = new } Component[TOP_INT]; protected void add. Impl(Component comp, . . . Object constraints, int index){ this. component = component 0; if (ncomponents == component. length) { Component newcomponents[]=new Component[. . ]; component = newcomponents; . . . } if (index == -1 || index == ncomponents) { component[ncomponents++] = comp; } else { component[index] = comp; ncomponents++; }. . . } } // must side-effects this. component[TOP_INT] = param 0; this. ncomponents = TOP_INT
From Analysis to Model //return locations { param 0 } public class Container extends Component{ Component[] component = new Component[0]; public Component add(Component comp) { add. Impl(comp, null, -1); return comp; public class Container extends Component { } Component[] component; protected void add. Impl(Component comp, int ncomponents; Object constraints, int index){ public Component if (ncomponents == component. length) { add(Component param 0){ Component newcomponents[]=new Component[. . ]; = param 0; component[ncomponents] component = newcomponents; . . . ncomponents++; } param 0; { if (index == -1 || index ==return ncomponents) } component[ncomponents++] = comp; } else { } component[index] = comp; ncomponents++; }. . . } } // must side-effects this. component[TOP_INT] = param 0; this. ncomponents = TOP_INT
Modeling User n The user may click on any visible enabled components User GUI Impl n 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 non. Modal. Windows Stack modal. Windows
Modal vs. Non-modal Dialogs Set non. Modal. Windows Stack modal. Windows
Modal vs. Non-modal Dialogs Set non. Modal. Windows Stack modal. Windows
Modal vs. Non-modal Dialogs Set non. Modal. Windows Stack modal. Windows
Modal vs. Non-modal Dialogs Set non. Modal. Windows Stack modal. Windows
Choosing Top-Level Window Set non. Modal. Windows public Window choose. Top. Window() { Window window = null; if(!modal. Windows. empty()) window = modal. Windows. pop(); else window=choose. Reachable("Window“, non. Modal. Windows); return window; Stack modal. Windows }
Choosing Top-Level Window Set non. Modal. Windows public Window choose. Top. Window() { Window window = null; if(!modal. Windows. empty()) window = modal. Windows. pop(); else window=choose. Reachable("Window“, non. Modal. Windows); return window; Stack modal. Windows }
Choosing Top-Level Window Set non. Modal. Windows public Window choose. Top. Window() { Window window = null; if(!modal. Windows. empty()) window = modal. Windows. pop(); else window=choose. Reachable("Window“, non. Modal. Windows); Stack modal. Windows return window; }
Choosing Top-Level Window Set non. Modal. Windows public Window choose. Top. Window() { Window window = null; if(!modal. Windows. empty()) window = modal. Windows. pop(); else window=choose. Reachable("Window“, non. Modal. Windows); Stack modal. Windows return window; }
User Model while (true) { window = choose. Top. Window(); container = choose. Reachable( "JComponent", window, is. Visible, is. Enabled); notify. Listeners(container) }
User Model while (true) { window = choose. Top. Window(); container = choose. Reachable( "JComponent", window, is. Visible, is. Enabled); notify. Listeners(container) }
Notification n n 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) n express environment nondeterminism n choose() n choose. Int(int n, int m) n n choose. Class(boolean sub. Type, String type, boolean is. Visible, boolean is. Enabled) choose. Reachable(boolean sub. Type, String type, Object from, boolean is. Invisible. Component, boolean is. Visible, boolean is. Enabled)
Bogor Extensions (Syntax) extension Choose for bogor. ext. Choose. Module { expdef boolean choose. Boolean(); expdef int choose. Int(int, int); } expdef 'rec$a choose. Object<'a>(boolean, 'rec$a -> boolean. . . ); expdef 'rec$a choose. Reachable. Object<'rec$a>(boolean, Object -> boolean, 'rec$a -> boolean. . . ); fun is. Visible(Component c) returns boolean = c. visible; fun is. Enabled(Component c) returns boolean = c. enabled; fun is. Invisible. Component(Object o) returns boolean = o instanceof Component && !is. Visible((Component) o);
Bogor Extensions (Semantics) package bogor. ext. Choose. Module. . . public class Choose. Module implements IModule {. . . public IValue choose. Boolean(IExt. Arguments args) { IValue[] values = new IValue[] { vf. new. Int. Value(0), vf. new. Int. Value(1) }; int index = ss. advise(. . . , values, args. get. Scheduling. Strategy. Info()); return values[index]; } }
Store-States-On-Choose (SSC ) Strategy n n 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 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
Evaluating 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
Limitations n n n 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 n n n 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 n n n Overview of BEG Overview of Bogor Presentation of n n n Modeling and Model checking strategies for checking ordering properties of GUIs For more information on tools http: //bandera. projects. cis. ksu. edu
- Slides: 41