Download Method Sequence Specification and Verification in Object-Oriented Protocol Testing - Prof. and more Study notes Computer Science in PDF only on Docsity!
Dependable Software Systems
Testing the Protocols of
Classes in
Object-Oriented Programs
Material drawn from [Kirani, Tsai, 1994]
Method Sequence Specification
- An object accessing the services of other objects must know the proper interface protocol of the objects.
- The Method Sequence Specification technique documents the correct order in which methods can be invoked.
- Regular Expressions are used to represent method sequence specifications.
Stack Example
- The objects of a Stack class should receive a pop() message only after receiving a push() message.
- Some ordering rules are due to implementation issues: - E.g., objects must receive a constructor message before receiving any other message.
Method Sequence
- Methods(C) is the set of all public methods defined in class C. - For a Stack class the set of methods can be: Methods(Stack) = {push,pop,isempty,isfull,top}
- A method sequence S of C is a finite sequence of methods M of C , (M0.M1. … .Mn) , where Mi (0 <= i <=N) are in set M. - E.g., for the Stack class, a method sequence is: (push.top.pop.isempty)
Example of a Regular Definition
moreoccurancesof a symbol. Theregularexpression can use"*"/" "forspecifyingzero/one or over ( ) { , ,..., }. whereeach isa distinct label,andeach isa regular expression ... 2 2 1 1
! " " " i i n i i n n Methods C l l l l r l r l r l r
Specification of a Simple
Bank Account Class
- Interface methods of the Account class:
- = {Create,Deposit,Open,Withdraw,Close,Delete}
- The regular expression of the method sequence specification for class Account is: ! Create. Open .( Deposit .( Deposit | Withdraw ) ). Close. Delete
- The regular expression is equivalent to the set:
- {(Create.Open.Deposit.Withdraw.Close.Delete), (Create.Open.Deposit.Deposit.Withdraw.Close.Delete), …}
Verification of Implementation
- The method sequence specification of a class specifies the correct sequence usage for all objects of the class.
- But the implementation of a class may contain method invocation sequences that are inconsistent with the method sequence specification.
- It is important to identify and correct all such inconsistencies.
Verification of Implementation (Cont’d)
- We can use manual inspection or static analysis of the implementation to identify inconsistencies.
- Note that pointers, polymorphism, and dynamic binding in OO programs complicates the control-flow analysis. - For dynamic binding of methods to messages, the static analysis must consider all possible methods that can be bound to a message.
Run-time Verification System
- What if all the invalid method sequences are not identified using inspection and static analysis?
- For safety-critical systems it may be necessary to identify all invalid method sequences during execution.
- The run-time verification system helps identify and recover from invalid method invocations.
Run-time Verification System
(Cont’d)
- Each object maintains an access pointer to the method sequence specification of its corresponding class.
- For each method invocation, a check is made for sequence consistency (if the sequence is in the regular language) with respect to the stored sequence specification.
- If the method invoked is not in correct sequence, an exception is raised and handled.
Efficient Algorithm for
Consistency Checking
- We must be able to verify whether one regular expression is the same as another.
- Each regular expression defines a finite automata (FA).
- An FA accepts a set of strings and all of the acceptable strings form a language L.
- If L1 and L2 are the languages represented by two regular expressions, then the two regular expressions are equal if L1=L2.
Algorithm for
Consistency Checking (Cont’d)
- One can verify that L1=L2 by constructing a finite automaton, D1, that satisfies L1 L2. - is the exclusive-or operator.
- If D1 only accepts the empty string, then L1=L2. ! !
Test Case Generation from
Sequence Specification (Cont’d)
- All-node coverage criterion:
- (M1.M2.M3) and (M1.M2.M4)
- All-edge coverage criterion:
- (M1.M2.M3.M3.M4) and (M1.M2.M4.M4.M3) S0 S1 S S S M1 M M M M4 M M M
Test Case Generation from
Sequence Specification (Cont’d)
- For each method in the sequence, data input of each parameter and the expected output must be determined.
- If a method invokes methods of other objects, then during testing test stubs can be used to supply return values.