1. Analyzing Interaction Orderings with Model Checking 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) Matthew B. Dwyer (University of Nebraska) Robby, Oksana Tkachuk (Kansas State University) Willem Visser (NASA Ames Research Center)

2. Model Checking GUIs Problems State space explosion due to large data domains Swing framework complexity General Solutions Modular Verification Abstraction Reduction

3. Our Solutions Modular verification Treat GUI implementation as module Domain-specific abstractions Swing framework Underlying application Domain-specific model checking Customized reductions

4. Our Solutions Are implemented in Bandera Environment Generator (BEG) Extensible model generation/extraction tool Bogor Extensible model checker

5. 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

6. Environment Models in BEG Universal environments Safe but impractical Synthesized from environment assumptions User-supplied Automatically extracted from environment implementation using static analysis techniques

7. 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

8. 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 Algorithms easily customized to different domains Domain YDomain Z Domain X

9. Model Checker Variety of System Descriptions Design Notations Byte code State Machines Source code Different levels of abstraction!

10. Abstract machine tailored to domain and level of abstraction Domain-Specific Model Checking Model-checking Engine BEG models Domain & Abstraction Extensions GUI

11. Bogor Extensions Modeling Language Extensions Type extensions Expression extensions Action extensions Module Extensions interpretative component extensions model checking component extensions

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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-effects Component[] component0 = new Component[TOP_INT];... this.component = component0; //return locations { param0 }

19. 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; } }

20. 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

21. Modal vs. Non-modal Dialogs Set nonModalWindows Stack modalWindows

22. Modal vs. Non-modal Dialogs Set nonModalWindows Stack modalWindows

23. Modal vs. Non-modal Dialogs Set nonModalWindows Stack modalWindows

24. Modal vs. Non-modal Dialogs Set nonModalWindows Stack modalWindows

25. Modal vs. Non-modal Dialogs Set nonModalWindows Stack modalWindows

26. 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; }

27. 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; }

28. 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; }

29. 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; }

30. User Model while (true) { window = chooseTopWindow(); container = chooseReachable( "JComponent", window, isVisible, isEnabled); notifyListeners(container) }

31. User Model while (true) { window = chooseTopWindow(); container = chooseReachable( "JComponent", window, isVisible, isEnabled); notifyListeners(container) }

32. 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

33. 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)

34. extension Choose for bogor.ext.ChooseModule { expdef boolean chooseBoolean(); expdef int chooseInt(int, int); expdef 'rec$a chooseObject (boolean, 'rec$a -> boolean...); expdef 'rec$a chooseReachableObject (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)

35. 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)

36. 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

37. Evaluating SSC Strategy ExampleMeasureALLSSC 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

38. Evaluating SSC Strategy ExampleMeasureALLSSC 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

39. 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

40. 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.]

41. 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