Theory and Practice of Co-verification Process Uni Tes

Theory and Practice of Co-verification Process: Uni. Tes. K Story Red. Verst group of ISP RAS http: //www. ispras. ru/groups/rv/rv. html Alexander K. Petrenko (petrenko@ispras. ru) Victor V. Kuliamin (kuliamin@ispras. ru)

Overview • Introduction : Why co-verification? slides 3 -13 • Main part : What is Uni. Tes. K? Solving Engineering Problems slides 14 -55 • Case studies slides 56 -64

What do these numbers mean? 9 : 1 180 109 $ 21 109 $ total revenue of US software development companies loss caused by inadequate testing infrastructure for US economy 1 1. The Economic Impacts of Inadequate Infrastructure for Software Testing, 2. NIST Report, May 2002

Waterflow Process Model Requirements Design Implementation Testing Deployment

Iterative Process Model Inception Requirements Design Implementation Testing Deployment Elaboration Construction Transition

Race for Quality : CMM Certified Organizations According to Compiled List of Organizations Publicly Announced their Maturity Levels, http: //seir. sei. cmu. edu/pml/

Race for Flexibility : Agile Development Methods Percent of organizations using modern development processes According to “The Decision is in: Agile versus Heavy Methodologies” by Robert Charette, Cutter IT Journal, vol. 2, No. 19 http: //www. cutter. com/freestuff/apmupdate. html

Need for Quick Change Response Percent of organizations recognizing more than 50% of projects as agile According to “The Decision is in: Agile versus Heavy Methodologies” by Robert Charette, Cutter IT Journal, vol. 2, No. 19 http: //www. cutter. com/freestuff/apmupdate. html

Inadequate Quality of Software Loss Software Vendors Software Users Total 21. 2 109 $ Potential Cost Reduction 10. 6 109 $ 38. 3 109 $ 11. 7 109 $ 59. 5 109 $ Total Sales 22. 2 109 $ 180 109 $ The Economic Impacts of Inadequate Infrastructure for Software Testing, NIST Report, May 2002

Evolution of Testing • Localization of errors • Demonstration of errors – Testing is the process of executing a program or system with the intent of finding errors [Myers, 1979] – The purpose of testing is to show that a program has bugs [Hetzel, 1988] • Evaluation of quality – Testing is the process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component [IEEE 90]

Co-verification Verification confirms that activity products properly reflect the requirements specified for them at the beginning of the activity. Co-verification process • Perform verification of activity before proceeding to the dependent activities • Prepare all the artifacts needed for verification concurrently with main activity products

Traditional Development Process Business Modeling Deployment Requirements Integration Architecture Design Implementation Component Design

Co-verification Development Process Business Modeling Deployment Requirements Integration Architecture Design Implementation Component Design

Main Part Overview • Traditional approaches to verification • Uni. Tes. K approach • Example

Traditional Software Development Process Design and development • Requirements Analysis • Design • Implementation and debugging Verification • • • Requirements Elicitation Test Case Design Test Implementation Test Execution Test Result Analysis

Co-verification Process Design and development • Requirements Analysis • Design • Implementation and debugging Verification • • • Requirements Elicitation Test Case Design Test Implementation Test Execution Test Result Analysis

Uni. Tes. K Approach Foundations Uniform Specification Extension Uniform Test Architecture Model Based Testing . N@T VDM++Tes. K CTes. K J@T Tools Uni. Tes. K Integration with Development Environments

Requirements Formalization Requirements Formal Specifications

Co-verification Support Requirements Ambiguity? Incompleteness? Formal Specifications Inconsistency?

Engineering Problems (1) • Specification technique should support – Easy transformation of requirements into specifications – Easy automation of further test development – Functional test coverage definition – High reusability of specifications • Specification notation should not require special education and skills

Specification Techniques • Executable Imperative state based specifications • Constraints State based data type constraints, pre- and postconditions, internal invariants • Axiomatic Action based axioms

Comparison of Specification Techniques

Comparison Results

Specification Notation • Specification language – – Suitable for capture abstract properties Has formal semantics Requires complex mediator layer for implementation Requires special education, mastering is enduring • Extension of programming language – – Abstract concepts can be added by libraries Ambiguous parts of language can be excluded Complex mediators are not required Mastering can be made more effective – Facilitates co-verification

Uni. Tes. K Specification Technique Uniform Specification Extension • Constraint Specifications Uniform Specification Extension Uniform Test Architecture Model Based Testing . N@T CTes. K J@T • Functional coverage description based on Uni. Tes. K specification structure VDM++Tes. K – Preconditions and postconditions of operations – Data type constraints Integration with Development Environments

Uni. Tes. K Specification Technique • Constraint Specifications – Preconditions and postconditions of operations specification Operation() pre block, returning Boolean value post block, returning Boolean value use @ to refer to pre-value of expressions – Data type constraints invariant Inv() block, returning Boolean value

J@va : Specification Extension of Java Uniform Specification Extension Architecture Model Based Testing . N@T CTes. K J@T public class PQueue. Specification { specification public void enq(Object obj, int prty) reads obj, prty updates items. ? , priorities. ? { pre { return obj != null; } post { Uni. Tes. K int i = 0; for(i = 0; i < items. size() && priorities. element. At(i) > prty; i++ ); . . . Uniform Test VDM++Tes. K specification package pqueue; Integration with Development Environments

Coverage Goals Definition Formal Specifications pre post --------------------------------------------------------------------------------------------------- Requirements Formal Specifications Test Case 1 ------------------ pre post 1 2 3 ---------------------------------------------------------------------------------------------------

Co-verification Support Formal Specifications pre post --------------------------------------------------------------------------------------------------- Uni. Tes. K supports this transformation with techniques and tools Software ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Testable Specifications pre post ---------------------------------------------------------------------------------------------------

Engineering Problems (2) • Automatic extraction of coverage goals from the specification structure • More than one coverage metric is needed • Test designer should be able to introduce additional goals

Several Levels of Coverage Metrics 1. 2. 1 1. 2. 2 Formal Specifications pre post 1 2 3 --------------------------------------------------------------------------------------------------- 1. 1 1. 2 1. 3. 1 1. 3. 2 1. 3. 3 2. 1 2. 2 3. 1 3. 2 3. 1. 1 3. 1. 2 3. 1. 3

Definition of Coverage Goals : Functionality Branches • Functional coverage description based on specification structure post if(a || b). . . branch “Case 1”; . . . else if(!c && d). . . branch “Case 2”; . . . else. . . branch “Case 3”; . . . Branches Case 1 Case 2 Case 3 Disjuncts a !a b !a !b !c d !a !b c !a !b !c !d

Definition of Additional Coverage Goals : Marked Paths post if(a || b || c) { if(a) mark “a holds”; branch “Case 1”; . . . } Branches Disjuncts “a holds”; “Case 1” Case 1 Marked Paths a “Case 1” !a b !a !b c

Test Implementation Formal Specifications Test Case 1 ------------------ Test Program pre post --------------------------------------------------------------------------------------------------- Test Scenario

Co-verification Support Formal Specifications pre post Testable Specifications --------------------------- pre post ---------------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------- Uni. Tes. K supports this transformations with techniques and tools Software ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Test Scenario

Engineering Problems (3) • Test construction technique should ensure coverage goals achievement • Test designer should be able to introduce additional tests • Tests should be decoupled with implementation

Overview of Uni. Tes. K Approach to Test Implementation • Test construction technique : traversal of FSM – FSM is constructed in so far that its traversal ensures coverage • FSM represented implicitly as test scenario – Implicit representation saves a lot of work – Test scenarios can be • Generated on the base of templates and specifications • Developed manually • Developed in mixed way • Mediators are used to decouple test scenarios and implementation – The same three ways to develop mediators

Uni. Tes. K Test Architecture • From specification we can generate oracle to check the conformance of system behavior • The entire test is constructed as a test sequence intended to achieve some coverage Uniform Specification Extension Uniform Test Architecture Model Based Testing . N@T VDM++Tes. K CTes. K J@T – Test sequence required is produced on-the-fly Uni. Tes. K during test execution as a transition tour of FSM model Integration with Development Environments

Uni. Tes. K Test Architecture Test sequence construction Test Engine Test Action Iterator Oracle Target system Specification

Test Sequence Construction Test Engine Executes Describes Test Action Iterator

Engineering Problems: FSM Construction (4) • Implicit specifications are hard to resolve • Nondeterminism • Huge numbers of states and transitions

Factorization Based on Coverage Goals Helps to cope with state explosion and nondeterminism I. B. Bourdonov, A. S. Kossatchev, V. V. Kuliamin. Using Finite State Machines in Program Testing. Programming and Computer Software, Vol. 26, No. 2, 2000, pp. 61 -73

Implicit State Machine Description Allows not to resolve implicit constraints Makes factorization easier

State Machine Construction Based on Coverage Goals operation domain defined by precondition parameters 2 3 coverage goals 1 states resulting implicit FSM description

Test Sequence Construction for Implicit FSM Test Engine Executes and obtains the complete structure Test Action Iterator

Test Scenario Test sequence construction Test Engine Test Action Iterator Test Scenario Oracle Specification Target system

Using Nondeterministic FSMs : Bounded Queue Empty Single element add Empty empty Single element Intermediate Almost full remove Intermediate Almost full Full fill

Testing Concurrency • Fair Concurrency Axiom : Concurrent execution of several operations is correct if and only if it is equivalent to somehow ordered one • So, to test the concurrent execution of calls we should check that it behaves like some sequence of the same calls – The system can be modeled as an ordinary FSM – Test engine generates pairs, triples, and so on, of concurrent actions • System not satisfying Fair Concurrency Axiom should be modeled as asynchronous FSM

Asynchronous FSM • Some transitions are fired by a stimulus • Some transitions are fired along with a reaction • Some transitions are empty, modeling internal operation b/ /y /x a/ b/ a/ Possible behavior: /y /x input: aba ouput: yyx xxyxyyyxy all possible outputs: { x*yx*yy*x, x*yy*x }

Co-verification Support : Changes Formal Specifications pre post Testable Specifications --------------------- pre post ---------------------------------------------------------------------------------------- ------------------------------------------------- Prototype Test Scenario ------------------------------------------------------------------------------------ Interface changed Software ------------------------------------------------------------------------------------ ? ? ?

Engineering Problems (5) • Tests and implementation should be decoupled – Tests can be reused many times – Easy regression testing • Specification should be as abstract as possible • Specification should be even more reusable than tests

Mediator decouples specification and implementation Test sequence construction Oracle Mediator Target system

Mediator Construction Test Engine Test Action Iterator Test Scenario Oracle Specification Mediator Target system Mediator in Extended Language

Open State Testing • Mediator constructs new model state only on the base of new implementation state • Requires: Implementation state should be accessible by public fields or reliable observers • Implies: Current model state actually corresponds to implementation one – Detected failure demonstrates a fault in the last operation – Transition tour is sufficient to ensure reliability Target system Mediator call response get state data construct new model state

Hidden State Testing • Mediator constructs new model state on the base of old one and implementation call results • Implies: Current model state is actually a hypothesis – Detected failure can be manifestation of a fault in any previously called operation – Transition tour is insufficient to ensure reliability Target system Mediator call response construct new model state

Uni. Tes. K Practice Overview • • • Uni. Tes. K tools Uni. Tes. K history Training courses QUTILUI project Other case studies

Uni. Tes. K Tools J@T CTes. K VDM++Tes. K. N@T Uniform Specification Extension Uniform Test Architecture Model Based Testing . N@T VDM++Tes. K CTes. K Uni. Tes. K J@T • • Integration with Development Environments

Uni. Tes. K History pre-Uni. Tes. K • 1994 – 1996 ISP RAS – Nortel Networks contract on functional test suite development for Switch Operating System kernel – Hundreds of bugs found in the OS kernel, which had been 10 years in use • About 600 K lines of Nortel code tested by 2000 But failed to be introduced in Nortel processes

Uni. Tes. K Tools History • 2000 – Conception • 2001 – J@T Prototype – CTes. K Lite • 2002 – VDM++ Tes. K – J@T Product • 2003 – J@T 1. 2 – CTes. K Full –. N@T

Sqrt Specification in J@va and Extended C class Sqrt. Specification { specification static double sqrt(double x) reads x { pre { return x >= 0; } post { if(x == 0) { branch "Zero argument"; return sqrt == 0; } else { branch "Positive argument"; return sqrt >= 0 && Math. abs((sqrt*sqrt-x)/x < epsilon; } } operation signature declaration access constraints precondition specification double SQRT(double x) reads (double)x { pre { return x >= 0. ; } coverage ZP { if(x == 0. ) return (ZERO, "Zero argument"); else return (POS, "Positive argument"); } post { if(coverage(ZP, ZERO)) return SQRT == 0. ; else return SQRT >= 0. && abs((SQRT*SQRT - x)/x) < epsilon; } } } functional branches definition postcondition

Training Courses CTes. K training was conducted for Tercom (Russia) J@T training was conducted for Systematic Software Engineering (Denmark), Saarland University (Germany)

QUTILUI Project • Goal Redesign of SOS Queue Manipulation Utilities Subsystem • Activities – – – – Requirements elicitation Specification development Specification review Architecture design Component design Implementation Testing and debugging

QUTILUI Project Results • Bugs removed – No bugs found after the project end! • 25% decrease of implementation size • Design documentation appeared – And it became actual! --------- • Tests demonstrated conformance with requirements -------------

Other Examples of Uni. Tes. K Usage • IPv 6 implementations – Microsoft Research – Mobile IPv 6 (in Windows CE 4. 1) • mp. C Workshop – Debug API – mp. C expression static and dynamic semantics • Optimization units in Intel compilers • Uni. Tes. K tools – J@T test system runtime support – Components of J@va translator – CTes. K abstract types library • Lanit-Tercom – IPv 6 implementation – DSP software

Appendices • References slide 66 • Detailed comparison of specification techniques slide 67 -69 • Priority Queue Example – – – – Description Specifications Functional branches Additional coverage goals FSM construction Test scenario Mediator and its usage slide 70 slides 71 -79 slides 80 -82 slides 83 -86 slides 87 -91 slides 92 -96 slides 97 -101

References 1. 2. 3. 4. 5. 6. 7. V. Kuliamin, A. Petrenko, I. Bourdonov, A. Kossatchev. Uni. Tes. K Test Suite Architecture // Proceedings of FME’ 2002 conference, Copenhagen, Denmark, LNCS, No. 2391, 2002, pp. 77 -88. V. Kuliamin, A. Petrenko, I. Burdonov, A. Demakov, A. Jarov, A. Kossatchev, S. Zelenov. J@va : extension of Java for real-life specification and testing // Proc. of Andrei Ershov Fourth International Conference PCI’ 01, Novosibirsk, LNCS, Vol. 2244, 2001, pp. 301 -308. A. Petrenko, V. Kuliamin, I. Bourdonov, A. Kossatchev. Experiences in using testing tools and technology in real-life applications // Proceedings of SETT’ 01, India, Pune, 2001 A. Petrenko. Specification Based Testing: Towards Practice // Proceedings of PSI’ 01, Novosibirsk, LNCS 2244, 2001, pp. 157 -162. A. Petrenko, A. Vorobiev. Industrial Experience in Using Formal Methods for Software Development in Nortel Networks // Proceedings of Testing Computer Software Conference TCS 2000, Washington, June, 2000. I. Bourdonov, A. Kossatchev, V. Kuliamin. Using Finite State Machines in Program Testing // Programming and Computer Software, Vol. 26, No. 2, 2000, pp. 61 -73. I. Bourdonov, A. Kossatchev, A. Petrenko, and D. Galter. KVEST: Automated Generation of Test Suites from Formal Specifications // Proceedings of World Congress of Formal Methods, Toulouse, France, LNCS, No. 1708, 1999, pp. 608 -621

Executable Specifications • Are very close to some implementation – Are easy to use in the industry – Can be transformed into prototypes • Are not close to requirements ( √¯ = e½ln = lim(xn+1 = ½(xn +x/xn)) ) – Unsuitable for test coverage measurement – Can cause problems with conformance checking How to compare the results? • Are highly reusable as executable code • But are low reusable as criteria of correctness

Constraint Specifications • Have the structure similar with implementation – Are easy to use in the industry • But have different form • Are close to requirements in most cases – Are easy to construct from requirements – Suitable for test coverage measurement – Counterexample: memory management subsystem • Can be directly used in conformance checking • Special constructs enabling reuse can be added

Axiomatic Specifications • Are far from common implementations and have greatly different structure – Can hardly be introduced in the industry • Are usually far from requirements – Are hard to develop in real-life projects – Can hardly be used for coverage measurement – But sometimes are the only appropriate form • Can be used for conformance checking • But sharpen error localization problems • Reusability is a problem

Priority Queue Example 5 deq () 5 enq () 4 0 2 3 enq () 1 1 size () • void enq (Object obj, int priority) priority [Min_Priority, Max_Priority] • Object deq () • int size ()

Model State Definition public class PQueue. Specification { // List of elements of the queue public Vector items = new Vector(); // Accompanying list of their priorities public Int. List priorities = new Int. List(); }

Data Integrity Constraints : Lists are not Null public class PQueue. Specification { public List items = new List(); public Int. List priorities = new Int. List(); invariant Lists. Are. Not. Null() { return items != null && priorities != null; } }

Data Integrity Constraints : Lists’ Sizes are Equal public class PQueue. Specification { invariant Lists. Sizes. Are. Equal() { return items. size() == priorities. size(); } }

Data Integrity Constraints : Priorities Lie in the Range public class PQueue. Specification { public static int Min_Priority; public static int Max_Priority; invariant Priorities. Lie. In. The. Range() { for(int i = 0; i < priorities. size(); i++) { if( priorities. get(i) < Min_Priority || priorities. get(i) > Min_Priority ) return false; } return true; } }

Data Integrity Constraints : Priorities do not Increase public class PQueue. Specification { invariant Priorities. Do. Not. Increase() { for(int i = 1; i < priorities. size(); i++) { if( priorities. get(i-1) < priorities. get(i) ) return false; } return true; } }

Operation Specification : size() Method public class PQueue. Specification { specification public int size () reads this. ? { pre { return true; } post { return size == items. size(); } } }

Operation Specification : enq() Method public class PQueue. Specification { specification public void enq (Object obj, int prty) reads obj, prty updates this. ? { pre { return obj != null; } post { int i = 0; for(i = 0; i < items. size() && priorities. get(i) >= prty; i++ ); PQueue. Specification new_state = (PQueue. Specification)@clone(); new_state. items. add(i, obj); new_state. priorities. add(i, prty); return this. equals(new_state); } } }

Auxiliary Methods public class PQueue. Specification { public boolean equals (PQueue. Specification other) { return items. equals(other. items) && priorities. equals(other. priorities); } public Object clone () { PQueue. Specification result = new PQueue. Specification(); result. items = (List)items. clone(); result. priorities = (Int. List)priorities. clone(); return result; } }

Operation Specification : deq() Method public class PQueue. Specification { specification public Object deq () updates this. ? { post { if(items. is. Empty()) return deq == null && items. is. Empty(); else { PQueue. Specification new_state = (PQueue. Specification)@clone(); Object result = new_state. items. first(); new_state. items. remove. First(); new_state. priorities. remove. First(); return } } this. equals(new_state) && deq == result;

Functionality Branches in size() Method public class PQueue. Specification { specification public int size () reads this. ? { pre { return true; } post { branch “Single branch”; return size == items. size(); } } }

Functionality Branches in enq() Method specification public void enq (Object obj, int prty) reads obj, prty updates this. ? { pre { return obj != null; } post { int i = 0; for(i = 0; i < items. size() && priorities. get(i) >= prty; i++ ); branch “Single branch”; PQueue. Specification new_state = (PQueue. Specification)@clone(); new_state. items. add(i, obj); new_state. priorities. add(i, prty); return this. equals(new_state); } }

Functionality Branches in deq() Method specification public Object deq () updates this. ? { post { if(items. is. Empty()) { branch “Empty queue”; return deq == null && items. is. Empty(); } else { branch “Nonempty queue”; PQueue. Specification new_state = (PQueue. Specification)@clone(); Object result = new_state. items. first. Element(); new_state. items. remove. First. Element(); new_state. priorities. remove. First. Element(); return } } } this. equals(new_state) && deq == result;

Additional Coverage Tasks : enq() 7 5 5 5 4 4 3 1 1 1 2 1 1 0

Additional Coverage Tasks : deq() 5 5 4 3 3 1 1 1

Marked Paths in enq() Method post { int i = 0; for(i = 0; i < items. size() && priorities. get(i) >= prty; i++ ); if( items. is. Empty() ) mark "Insertion in the empty queue "; else if( prty > priorities. maximum() ) mark "Insertion in the head"; else if( prty == priorities. maximum() && prty == priorities. minimum() ) mark "Insertion with single existing priority "; else if( prty == priorities. maximum() ) mark "Insertion with maximum priority "; else if( prty < priorities. minimum() ) mark "Insertion in the tail with new priority "; else if( prty == priorities. minimum() ) mark "Insertion with minimum priority "; else if( !priorities. contains(prty) ) mark "Insertion in the middle with new priority "; else mark "Insertion in the middle with existing priority "; branch “Single branch”; . . . }

Marked Paths in deq() Method post { if(items. is. Empty()) { branch “Empty queue”; . . . } else { if( items. size() == 1 ) mark "Single element in the queue "; else if( !(priorities. maximum() == priorities. get(1)) ) mark "Single element with maximum priority, several elements in the queue "; else if( priorities. to. Set(). size() > 1 ) mark "Several elements with maximum priority, there are other priorities "; else mark "Several elements in the queue with the same priority "; branch “Nonempty queue”; . . . } }

Priority Queue Example : enq() Coverage Goals if( items. is. Empty() ) mark "Insertion in the empty queue "; else if( prty > priorities. maximum() ) mark "Insertion in the head"; else if( prty == priorities. maximum() && prty == priorities. minimum() ) mark "Insertion with single existing priority "; else if( prty == priorities. maximum() ) mark "Insertion with maximum priority "; else if( prty < priorities. minimum() ) mark "Insertion in the tail with new priority "; else if( prty == priorities. minimum() ) mark "Insertion with minimum priority "; else if( !priorities. contains(prty) ) mark "Insertion in the middle with new priority "; else mark "Insertion in the middle with existing priority "; States: Empty queue Single priority is used At least two priorities are used At least three priorities are used Arguments: At least three different priorities should be provided

Priority Queue Example : deq() Coverage Goals if(items. is. Empty()) branch “Empty queue”; else if( items. size() == 1 ) mark "Single element in the queue "; else if( !(priorities. maximum() == priorities. get(1)) ) mark "Single element with maximum priority, several elements in the queue "; else if( priorities. to. Set(). size() > 1 ) mark "Several elements with maximum priority, there are other priorities "; else mark "Several elements in the queue with the same priority "; States: Empty queue Single element in the queue Single element with maximum priority, several priorities Several elements with the single used priority

Priority Queue Example : Analysis of Determinism 0 1 2 deq() 0 : Empty queue 1 : Single element in the queue 2 : Several elements with single used priority To make the behavior deterministic we should split this state according to the number of elements

Priority Queue Example : Analysis of Determinism 0 1 2 A 3 … deq() 0, 1, 2, … : Number of elements with maximum priority A : Single element with maximum priority, several priorities To make the behavior deterministic we should split this state according to the number of elements with the next priority And so on, for all priorities (by induction)

Priority Queue Example : Resulting State Resulting state S : int → int is map from integers to integers, where key is priority value is the number of queue elements having such the priority

Reference to Specification Object scenario public class PQueue. Test. Scenario { // Reference to the object under test public PQueue. Specification queue; }

State Construction Method scenario public class PQueue. Test. Scenario { public Abstract. Gen. State get. Gen. State() { Int. To. Int. Map. Gen. State state = new Int. To. Int. Map. Gen. State(); for(int p = PQueue. Specification. Min_Priority; p < queue. priorities. to. Set(). size(); p++ ) { int n = queue. priorities. number. Of(p); if( n != 0 ) state. put(p, n); } return state; } }

Definition of Test Actions : size() method scenario public class PQueue. Test. Scenario { scenario public boolean size() { queue. size(); return true; } }

Definition of Test Actions : enq() method scenario public class PQueue. Test. Scenario { scenario public boolean enq() { Object arg = new Object(); iterate( int priority = PQueue. Specification. Min_Priority; priority <= PQueue. Specification. Max_Priority; priority++; queue. priorities. to. Set(). size() <= 3 || queue. priorities. contains(priority) && queue. priorities. number. Of(priority) < 2 ) { queue. enq(param, priority); } return true; } }

Definition of Test Actions : deq() method scenario public class PQueue. Test. Scenario { scenario public boolean deq() { queue. deq(); return true; } }

Mediator for Priority Queue mediator public class PQueue. Mediator // Extends specification class extends PQueue. Specification { // Reference to an implementation object implementation public Priority. Queue target; }

Mediator Methods (Open State Testing) mediator public class PQueue. Mediator { public int size() { return target. size(); } public void enq(Object obj, int prty) { target. enq(obj, prty); } public Object deq() { return target. deq(); } }

Model State Synchronization Method (Open State Testing) mediator public class PQueue. Mediator { public void map. State. Up() { items. clear(); priorities. clear(); if( target != null ) { for(int i = target. _clusters. size()- 1; i >= 0; i--) { Vector v = (Vector)target. _clusters. element. At(i); for(int j = 0; j < v. size(); j++) { items. add(v. element. At(j)); priorities. add(i); } } }

Mediator Methods (Hidden State Testing) mediator public class PQueue. Mediator { public int size() { return target. size(); } public void enq(Object obj, int prty) { target. enq(obj, prty); items. add(obj); priorities. add(prty); } public Object deq() { Object result = target. deq(); items. remove. First(); priorities. remove. First(); return result; } }

Test Scenario Initialization scenario public class PQueue. Test. Scenario { public PQueue. Test. Scenario() { set. Test. Engine ( new Deterministic. FSM_Test. Engine() ); PQueue. Mediator. init. Class. State(); queue = PQueue. Mediator. create(new Priority. Queue()); queue. attach. Oracle(); } }