Automated Objectâ€™s Statechart Generation and Testing from Class-Method Contracts

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

Organization • Motivation • Underlying Models • Automated Statechart Generation • V&V Using Statechart • Outcomes • Related Work • Conclusions

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

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 Object Contracts: Constrained Class Diagram

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

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

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’, ‘X = 0’, and ‘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.

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

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

Method invocation at a State

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

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 Effective V&V using statechart

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

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){} • }

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

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

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]

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.

Automated Objectâ€™s Statechart Generation and Testing from Class-Method Contracts