1. Automated Object’s Statechart Generation and Testing from Class-Method Contracts Atul Gupta PhD Scholar, IIT Kapur, India

2. Organization  Motivation  Underlying Models  Automated Statechart Generation  V&V Using Statechart  Outcomes  Related Work  Conclusions

3. Organization  Motivation  Underlying Models  Automated Statechart Generation  V&V Using Statechart  Outcomes  Related Work  Conclusions

4. Motivation  Most development is maintenance.  Most specification is incremental.  Domain knowledge is important.  The connections between Structural and Behavior Specifications in OO Systems are weak Hence there is a need for tightly- coupled deigns for better evolution of software objects. Aim: Effective semi-automated V&V

5. Organization  Motivation  Underlying Models  Automated Statechart Generation  V&V Using Statechart  Outcomes  Related Work  Conclusions

6. Object Contracts: Constrained Class Diagram  A pre-condition to a method which is a restriction that must be true at the moment that the method is going to be executed.  A post-condition to an method which is a restriction that must be true at the moment that the method has just ended its execution.  An invariant which is a restriction that must be true before as well as after a method invocation. Specification Language: UML class diagram with OCL constraints

7. Notion of Object’s Abstract States  Object’s concrete states are infinite  Behavior typically depends on regions, defined by a set of ‘domain variables’ and their values.  Typically, these variables are part of object’s method contracts  Variables with abstracted-out values forms the state variables  A state is an specific assignment of these state variables

8. Example: A Bounded List  ‘size’ is the ‘domain variable’ which exhibit important behavior for the List  Five states corresponding to size 0 && size maxElement  Two invalid (Error) states and three valid states

9. Data Types: Abstract State Model  Numeric data types like integer, float, etc. are to be mapped to a finite set of disjoint partitions over its entire state space, e.g., an integer state variable X is mapped to three abstract states ‘X 0’.  Boolean and enumeration data types are considered inherently abstract.  Object references X are mapped either to the abstract state ‘X = null’, or to the abstract state ‘X isInstance Of C’ for each class C, of the object referenced by X.

10. Organization  Motivation  Underlying Models  Automated Statechart Generation  V&V Using Statechart  Outcomes  Related Work  Conclusions

11. Statechart Elements  Generated as a Directed Graph with States representing ‘nodes’ and method calls as ‘edges’ in the graph.  Edges may be associated with ‘conditions’.  If-statements in the method-conditions are represented by a ‘choice’ node in the graph  An start state modeled by a constructor of the class

12. Some Assumptions  Method contracts are available  Pre-conditions are in CNF  Numeric Variables appearing in method contracts but not the state variables, are specified with their range constraints. Search for all those object’s methods which may be invoked at a given state

13. Method invocation at a State

14. Obtaining Resulting States Post-conditions may be one of the following type  X  ( X is a Numeric state variable)  X rop (X is a Numeric state variable or an containing Numeric variables)  If then -else if … aMethod() [C1] [C2] A B C The is evaluated and the results are mapped to set of states

15. Organization  Motivation  Underlying Models  Automated Statechart Generation  V&V Using Statechart  Outcomes  Related Work  Conclusions

16. Effective V&V using statechart The resulting statechart can be inspected to find out discrepancies in the object behavior. E.g. - Incorrect transitions - Incorrect resulting states - Incorrect end-states - Un-reachable states  A correct statechart can be used for performing automated testing which includes - Method test sequence generation - test input generation - Generation of test-oracles

17. An Example: Class CoinBox Class CoinBox { int curQtr, quantity, totalQtrs boolean allowVend addQtr( ) // adding a quarter in the machine pre: quantity > 0; post : curQtr  curQtr@pre +1 if (curQtr >= 2) then allowVend  TRUE retQtrs( ) // returning quarters back to the user pre: curQtr > 0; post : curQtr  0 allowVend  FALSE vend( ) // deliver a drink pre: allowVend = TRUE && quantity > 0; post : curQtr  0 allowVend  FALSE quantity  quantity@pre – 1 totalQtrs  totalQtrs@pre + curQtr addDrink(m ) // add m unit of drink in the //machine pre: quantity = 0; post : quantity  quantity@pre + m

18. Automated Testing public class CoinBoxTest extends TestCase { CoinBox cbox; public CoinBoxTest(String name) { super(name); cbox = new CoinBox(); } public void testAddDrinkAtA(){ //testing addDrink(m) // in state A Try{ assertEquals(0, cbox.getCurrectQtrs()); assertFalse(cbox.isAllowVend()); assertEquals(0, cbox.getCurrectQty()); cbox.addDrink(2); assertEquals(0, cbox.getCurrectQtrs()); assertFalse(cbox.isAllowVend()); assertTrue(cbox.getCurrectQty()> 0) }catch (Exception e){fail(“Unwanted exception is raised”} } public void testaddQtrRaiseExceptionAtA(){ try{ assertEquals(0, cbox.getCurrectQtrs()); assertFalse(cbox.isAllowVend()); assertEquals(0, cbox.getCurrectQty()); cbox.addQtr(); fail(.Exception should be raised.) }catch (Exception e){} }

19. Organization  Motivation  Underlying Models  Automated Statechart Generation  V&V Using Statechart  Outcomes  Related Work  Conclusions

20. Discussions  The approach identifies various discrepancies like incomplete and inconsistent class specifications  A correct and consistent object statechart model is obtained from which reliable automated code and unit tests can easily be generated  It facilitates essential and effective verification for software re-use  The resulting statechart and class specifications are in a lock-steps which facilitates effective incremental development and change management  It allows a modeler to specify object's dynamic requirements declaratively on structural level, without the need to use full operational dynamic diagrams

21. Limitations  Variability in selecting ‘state variables’  All test-inputs may not be generated automatically  Limitations of symbolic execution

22. Related Work  Binder’s work on abstract state notion and state based testing  FSM generation from object/system specifications. [Grieskamp’02, Strooper’96]  Tao Xie et al Testing Framework ‘Symstra’  Work on Symbolic Execution  From scenarios to statecharts [Whittle’00]

23. Conclusions  The approach supports better software evolution (tightly-coupled modeling)  Performing effective V&V.  Nicely fit with ‘Design by Contract’ approach.  The model developed are human- comprehensible which can be further used for effective and efficient change management and requirements elicitation and validation.  Some case studies and proper evaluations are needed.