The Australian National University Object Test Coverage Using Finite
Total Page:16
File Type:pdf, Size:1020Kb
The Australian National University TR-CS-95-06 Object Test Coverage Using Finite State Machines Oscar Bosman and Heinz W. Schmidt September 1995 Joint Computer Science Technical Report Series Department of Computer Science Faculty of Engineering and Information Technology Computer Sciences Laboratory Research School of Information Sciences and Engineering This technical report series is published jointly by the Department of Computer Science, Faculty of Engineering and Information Technology, and the Computer Sciences Laboratory, Research School of Information Sciences and Engineering, The Australian National University. Please direct correspondence regarding this series to: Technical Reports Department of Computer Science Faculty of Engineering and Information Technology The Australian National University Canberra ACT 0200 Australia or send email to: [email protected] A list of technical reports, including some abstracts and copies of some full reports may be found at: http://cs.anu.edu.au/techreports/ Recent reports in this series: TR-CS-95-05 Jeffrey X. Yu, Kian-Lee Tan, and Xun Qu. On balancing workload in a highly mobile environment. August 1995. TR-CS-95-04 Department of Computer Science. Annual report 1994. August 1995. TR-CS-95-03 Douglas R. Sweet and Richard P. Brent. Error analysis of a partial pivoting method for structured matrices. June 1995. TR-CS-95-02 Jeffrey X. Yu and Kian-Lee Tan. Scheduling issues in partitioned temporal join. May 1995. TR-CS-95-01 Craig Eldershaw and Richard P. Brent. Factorization of large integers on some vector and parallel computers. January 1995. TR-CS-94-10 John N. Zigman and Peiyi Tang. Implementing global address space in distributed local memories. October 1994. Ob ject Test Coverage Using Finite State Machines Oscar Bosman Heinz W. Schmidt Department of Computer Science Department of Software Development Australian National University Monash University, Cau eld Campus Canb erra, ACT, 0200 PO Box 197, Cau eld East, 3145 Australia Australia Email: [email protected] [email protected] .edu .au August 1995 submitted to TOOLS Paci c '95 also available as TR95-15, Dept. Software Development, Monash University Abstract Ob jects have b een describ ed as having identity, state and b ehaviour, but there are di ering views as to what are an ob ject's states. For a programmer using an ob ject-oriented programming language, the state is the currentvalues of all the attributes, hidden and accessible. In most ob ject-oriented design metho ds, an ob ject's state is an abstraction of this: design states are determined by the observable b ehaviour of the ob ject. The di erence is signi cant, for example the two views b ehave di erently under inheritance, and this can make it dicult to validate an implementation against its design sp eci cation. We describ e a technique for resolving these di erent views of state. The representation states of an ob ject can b e partitioned into abstract states by predicates on the attributes. We relate this to an op erational semantics for the ob ject-oriented programming language Sather. A direct implication is that the b ehaviour of ob jects can b e describ ed by nite state machines. Since there are testing techniques based on proving the equivalence of two state machines for example, a design sp eci cation and its implementation, it is now feasible to prove test coverage of automatically generated tests for ob ject oriented programs to the level of abstract states. Keywords: Ob ject-Oriented Programming, Ob ject-Oriented Design, Testing, Finite State Machines 1 Intro duction In the community of practitioners and researchers in ob ject technology there is a recognisable distinction b etween programmers and software engineers. Among the rst there has b een a concen- tration on ob ject-oriented programming languages, their features and extensions. From the latter wehave seen an explosion of \metho dologies" for ob ject-oriented analysis and design. Testing, however, needs to have a fo ot in b oth camps. Avalid and useful testing technology must understand ob ject-oriented analysis and design in order to nd inconsistencies b etween a mo del and its implementation; and it must understand the implementation language in order to concentrate the search for faults e ectively. So, while it is dicult to still claim that ob ject technology is \new", it is no surprise that there has b een little headway in testing technology for ob ject-oriented software. In this pap er, we fo cus on the b ehaviour of ob jects in terms of states and state transitions. We develop a technique for testing ob ject state that b oth reconciles the design view of ob ject state 1 with that of ob ject-oriented programming, and also builds up on established technology for testing nite state machines FSM. The next section describ es these two views of ob ject state and our metho d for reconciling them. Later, we couch this reconciliation in the formal setting of an op erational semantics for ob ject- oriented programs. The op erational semantics we build up on is that of ob ject machines [SZ94b], app endix A provides the necessary de nitions and background. 2 FSM Mo dels of Design From the p oint of view of ob ject-oriented design, ob jects have state and b ehaviour see, for example, + [Bo o94 , RBP 91 , HSE94]. These two asp ects of ob jects are closely related: the state of an ob ject a ects its b ehaviour in resp onse to the messages sent to it, and this b ehaviour may change the ob ject's state, in turn. Abstract b ehaviour of ob jects can b e represented by FSMs. Most ob ject-oriented design meth- o ds use statecharts [Har87 ] or some derivative of them to sp ecify the dynamic b ehaviour of ob jects + see, for example, [CHB92 , RBP 91 ]. Figure 1 shows the statechart for a stack. States are indi- cated by rounded b oxes and transitions b etween them by arrows. Transitions are lab elled by the message that causes them, and mayhave a \ ring condition" in square brackets. The initial state is indicated by an arrow with no source. This corresp onds to a creation message in ob ject-oriented programs. To avoid cluttering the diagram, some metho ds that do not change the state of the ob ject, suchastop, are not shown. push pop [#elts > 1] Empty Not empty pop [#elts = 1] Figure 1: Statechart describing the dynamic b ehaviour of a stack ob ject We call such a FSM mo del a design FSM, its states design states and its transitions design transitions FSMs are formally de ned in the app endix. In Sather, design states can b e represented as predicates or Bo olean functions as in gure 4 and design transitions as metho d names with their asso ciated ring conditions as metho d preconditions. When multiple inheritance is used to combine di erent facets of state into one ob ject, concurrent states called \AND states" in [Har87 ] can b e used. Any state of the design FSM then can b e expressed as a formula in terms of the state predicates of the FSM using disjunction OR for alternative states and conjunction AND for concurrent states. In Sather, this formula b ecomes part of the class invariant as in the example in gure 4. Under subtyping, a design FSM for a sub class may only vary from its parent's FSM in a limited number of ways. States may be mo di ed, but can only be added as substates of one of the parents states or as concurrent states. Concurrent states commonly result from multiple inheritance. Transitions can b e added b etween existing and new states or changed. Neither states nor transitions may b e deleted [CHB92 , MD93 ]. For sub classes that represent subtyp es these are distinct in Sather transition constraints preconditions can only b e weakened. If a sp ecialisation is wanted, such as in the example for Bounded stack b elow, one uses inheritance without subtyping. In this way, it is p ossible to ensure substitutability, allowing an ob ject of any subtyp e to act in the r^ole of its parenttyp e. Figure 2 shows the statechart for a sp ecialisation of stack: the b ounded stack. Notice that the 2 new states have b een added as substates and the FSM of the parent has b een preserved. In this case, however not all stack traces are legitimate for the b ounded stack, for example a b ounded stack of length 10 will not supp ort a sequence of 11 consecutive pushes. A Sather implementation of this design app ears in gure 5. Not empty push [#elts < max-1] pop [#elts = 1] Empty push [#elts = max-1] Not full Full push pop pop [#elts > 1] Figure 2: Statechart describing the dynamic b ehaviour of a b ounded stack ob ject 3 Representation and Implementation In an ob ject-oriented programming language, ob jects are instances of classes. Classes describ e the attributes and metho ds that can op erate on those attributes. The state of such an ob ject is the values of the attributes of an ob ject at a particular p oint in time. Obviously the numb er of states of an ob ject may b e arbitrarily large, or even in nite. For the purp oses of reasoning ab out the b ehaviour of ob ject oriented programs, it is natural to think of the representation state of an ob ject as a graph [GG94 , SZ94b].