Automated Object

1
Automated Objects Statechart Generation and
Testing from Class-Method Contracts

• Atul Gupta
• PhD Scholar, IIT Kapur, India

2
Organization

• Motivation
• Underlying Models
• Automated Statechart Generation
• VV Using Statechart
• Outcomes
• Related Work
• Conclusions

3
Organization

• Motivation
• Underlying Models
• Automated Statechart Generation
• VV 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 VV

5
Organization

• Motivation
• Underlying Models
• Automated Statechart Generation
• VV 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 Objects Abstract States

• Objects 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 objects
  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 sizelt0, size0,
  sizegt0 size lt maxElement, size maxElement,
  and sizegtmaxElement
• 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 lt 0, X 0, and X gt 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
• VV 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 objects 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 ? ltexprgt ( X is a Numeric state variable)
• X rop ltexprgt (X is a Numeric state variable or an
  ltexprgt containing Numeric variables)
• If ltC1gtthen ltexprgt-else if ltC2gt

The ltexprgt is evaluated and the results are
mapped to set of states
15
Organization

• Motivation
• Underlying Models
• Automated Statechart Generation
• VV Using Statechart
• Outcomes
• Related Work
• Conclusions

16
Effective VV 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 gt 0 post
curQtr ? curQtr_at_pre 1 if (curQtr gt 2)
then allowVend ? TRUE retQtrs( ) //
returning quarters back to the user pre curQtr
gt 0 post curQtr ? 0 allowVend ?
FALSE vend( ) // deliver a drink pre
allowVend TRUE quantity gt 0 post
curQtr ? 0 allowVend ? FALSE quantity ?
quantity_at_pre 1 totalQtrs ? totalQtrs_at_pre
curQtr addDrink(m ) // add m unit of drink in
the //machine pre quantity 0 post
quantity ? quantity_at_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.isAllowV
end()) assertEquals(0, cbox.getCurrectQty()) c
box.addDrink(2) assertEquals(0,
cbox.getCurrectQtrs()) assertFalse(cbox.isAllowV
end()) assertTrue(cbox.getCurrectQty()gt
0) catch (Exception e)fail(Unwanted exception
is raised
public void testaddQtrRaiseExceptionAtA() try as
sertEquals(0, cbox.getCurrectQtrs()) assertFalse(
cbox.isAllowVend()) assertEquals(0,
cbox.getCurrectQty()) cbox.addQtr() fail(.Except
ion should be raised.) catch (Exception e)
19
Organization

• Motivation
• Underlying Models
• Automated Statechart Generation
• VV 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

• Binders work on abstract state notion and state
  based testing
• FSM generation from object/system specifications.
  Grieskamp02, Strooper96
• Tao Xie et al Testing Framework Symstra
• Work on Symbolic Execution
• From scenarios to statecharts Whittle00

23
Conclusions

• The approach supports better software evolution
  (tightly-coupled modeling)
• Performing effective VV.
• 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.