FSM Extraction from Model Based Specification languages

1. FSM Extraction from Model Based Specification languages Presented By: Shafaq Khalid Supervised By: Dr. Aamir Nadeem

2. Introduction: • Finite State Machine: • Contains States & Transitions • Presents interactions between Operations • Can be used as a basis for specification based testing • Presents a Realization of Specifications

3. Paper 1 From Object Z specifications to Class Bench Test Suites (Carrington, MacColl,McDonald, Murray, & Strooper, 2003)

4. Paper 1 • Proposed an approach for specification based class testing that incorporates • Test case Generation • Test case Execution • Test case Evaluation • Steps Followed By the approach are: • Test Template Framework (TTF) (Carrington et al. 1996) • Generation of FSM from TTs • ClassBench Tool (Strooper et al. 1997)

5. Paper 1 (contd…) • TTF • Applies A testing strategy on the VIS to obtain finer TTs than VIS. • Applies the similar process over output space of an operation to obtain output templates (OT) and treated as oracle • Generation of FSM from TTs • States are formed from Init schema and Final TTs & OTs • Transitions: If an operation exists between a pair of state Templates mapping them, is a transition.

6. Paper 1 (contd…) • Class Bench Tool: • is used for test case generation and execution. • inputs are generated from specification Three steps of using class bench tool: • Generating test graph: • A test graph is generated from FSM consisting of only those states and transitions that are to be tested. • Generating test oracle • oracle class is independently generated from Object-Z specification of class under test. • Test case execution and evaluation • test graph, test oracle and implementation of the class under test are given as an input to ClassBench. • The automated tool then generates, execute and evaluate test cases.

7. Conclusion • Framework is only used for Z & object Z Specification languages. • TTF is partially automated, i.e TinMan Tool helps generating Test templates by applying certain strategies. • FSM generation from Test templates is a manual process, and hence needs to be automated. • Transformation of FSM into Test Graph is also a manual process.

8. Paper 2 An approach to formalizing specification-based class testing. (Huaikou, M., & Ling, L. (2006))

9. Paper 2: • Proposed Test Class Framework (TCF), to formalize the process of class testing from Object-Z specification. • TCF focuses on intra-method and intra-class testing levels. • Extension of framework for z operation (Ling et.al 2000) • TCF for intra method testing introduces • Test Space (TS), Test Method Template (TMT), Test Method Function (TMF), Instance Template (IT), Method Testing Adequacy Function (MTAF)

10. Paper 2 (contd…) • TCF for intra-class testing (proposed by Ling et.al. 2002) introduces notions of • State template (ST), Test class (TC), Class testing adequacy function (CTAF) States are derived: • STs are formed by TMTs, • by hiding input/output variables from pre-condition and other from post-condition. Transitions are derived: • If a pair of STs is selected and if such a TMT exist whose pre-condition corresponds to one ST and post-condition corresponds to other ST After FSM, different sequences of methods are selected according to some criterion to make TCs.

11. Conclusion • TCF has similarity with the Carrington’s approach • Notions introduced by TCF have resemblance with that of TTF. • Test Classes are generated in TCF • Generation of Test classes is a manual process and hence can be automated. • Applied On Z & object Z Specification languages.

12. Paper 3 Extracting FSMs from Object-Z specifications with history invariants. (Sun, J., & Dong, S., J. (2005))

13. Paper 3 (contd…) • Proposed an approach to extract FSM from Object-Z specifications with history invariants. • Handles state explosion problem of FSM generation by predicate abstraction. • Abstract states are determined by abstract predicates • Transitions can be determined by abstracting each operation i.e., it is determined from which abstract states an operation can be invoked (pre-state) and to which abstract states it can lead to (post-states).

14. Paper 3 (contd…) • History invariants are used to represent liveness properties (must be true) • Büchi automaton is extracted from history invariant. • pruning of FSM is done according to proposed algorithm to fulfill 2 requirements of open systems • After pruning, guard conditions are determined of transitions where necessary which completes the final FSM. • A Java based tool is developed taking Object-Z specifications and abstract predicates in XML form and partially automates the approach.

15. Conclusion • State explosion problem of FSM generation has been focused by the approach • Predicate abstraction effectively helps to make abstract states • proposed generation of FSM from Object-Z specifications with history invariants

16. Testing from a Z specification. (Hierons, M., R. (1997))

17. Paper 4 • Proposed an approach for testing based on partition analysis from Z specifications. • Variables are categorized into input/ output variables, • Specification is then flattened to input/ output predicates. • Specification is then re-written according to some rules such that every pre-condition becomes a conjunct with its corresponding post-condition. • Whole specification is now disjunction of such pairs.

18. Paper 4 (contd…) • States are identified from those partitions disjoint) i.e. each partition represent a state. • Transitions between identified states is evaluated for every pair of states and operation. • If predicate evaluates true then a transition between A and B exist which is labeled by Op. • After Identification of every transition FSM is formed from which testing is done.

19. Conclusion • The Work focused on the Z specification language & not object Z. • Discussed the identification of pre- and post-conditions. • FSM is generated manually, no automation details are discussed.

20. Table: Comparison of techniques

21. Major Challenge • Fully automated Identification of pre and post states • Identification of Reachable (realizable) states • Scalability Problem • And then automated formation of FSM from these states • Abstraction

22. Problem Statement • Extraction of FSM from Formal Specifications (object Z). • None of Existing technique in literature is fully automated. • Detailed mechanical work and calculation is needed to derive states and transition from a specification.

23. Proposed Work • Step 1: Initial state identification • Step 2: Separation of input & output Predicates. • Step 3: Identification of States and operations from those input and out put predicates • Step4: Analysis of states to remove any overlapping state and maximal partition of states, in order to make states disjoint • Step 5: Determining Transitions, which represent a valid pair of states, represented as an arc labeled with operation. • Step 6: Maping transitions with states to derive a complete FSM.

24. Example

25. Input & Output Predicates Extraction • Step1: Initial State Identification • Step 2: Input & Output Predicates Extraction • Applying rules used by TEIOPZ, Input & Pre state variables, Out put or post state variables can be categorized.

26. Input & Output Predicates Extraction • Categorizing variables in elementary stage: • OV={items!, items’} • IV={items?, items} • ITV = {} • Categorizing predicates in elementary stage: • IP={items=<>, # items< max, #items≤max, items=<items!> ^ items’, items≠<>} • OP={items’=<items?> ^ items}

27. States Identification • Identification of states from extracted predicates: • P1: items = <> • P2: items < max • P3: items ≤ max • P4: items ≠ <> • P5: items=<items!> ^ items’ • P6: items’=<items?> ^ items

28. States Identification • Initial State: • State o: items = <> (items= 0) • State 1: items < max (0,1,,,max-1) • State 2: items ≤ max • State 3: items ≠ <> (1,2,,,max)

29. States Identification • Boundary analysis needs to be applied for cardinality of items where it is either maximum permitted or less then maximum. • BA can be applied on State 2: • Giving • State 2: items = max (items = max) • State 3: items < max (0,1,,,max-1)

30. Final Set of states • State o: items = <> (items= 0) • State 1: items < max (0,1,,,max-1) • State 2: items = max (items = max) • Note: State: items ≠ <> (1,2,,,max) is a subset of state 1 so is removed from set of states • State: items < max (0,1,,,max-1) is an overlapping state

31. Transition determination • Each operation requires n2 (n is no. of states) valid transition calculations. • OP1: Push • OP2: Pop • Transition 1: So Λ Push Λ S0 = False • Transition 2:So Λ Push Λ S1 = True • Transition 3: So Λ Pop Λ So = False • Transition 4: So Λ Pop Λ S1 = False • Transition 5: S1 Λ Pop Λ So = True

32. Maping Transition into FSM push push push S1 So S2 pop pop pop