1. Data Abstraction II SWE 619 Software Construction Last Modified, Spring 2009 Paul Ammann

2. SWE 6192 Main agenda Abstraction function- AF(c) Rep Invariant- RI Verification Why should I care? What are they? How to implement? How to use?

3. SWE 6193 Correctness What does it mean for a procedure to be “correct”? Correctness is a property of an implementation with respect to some specification. As an implementer, how do you verify correctness? Testing - need to recognize incorrect behavior Analysis - need support (today’s lecture!)

4. SWE 6194 AF(c) Example Poly: c 0 +c 1 x 1 +…+c n x n Rep int [] trms  array of integers int deg  degree of the Poly Redundant variable deg AF() = c i = trms[i] for i <=deg and 0 for all other i 

5. SWE 6195 What does AF(c) do? Capture the intent behind choosing a rep Map from instance variables to abstract object represented Rep invariant splits the instances in the rep into legal and illegal instances (AF only maps legal ones) Illegal instances ≈ Bug in software

6. SWE 6196 RI for Poly RI is the “invariant” All legitimate objects must satisfy RI In other words: RI is the collection of rules for legitimate rep objects RI tells if the object is in a ‘bad state’ What are the rules for rep used in Poly?

7. SWE 6197 RI for Poly trms ≠ null  can never be null. Therefore dereferencing must never throw NPE Relation between deg and trms.length Redundancy hence relationship trms.length = deg +1 deg >= 0 trms[deg] ≠ 0 Is this true? Not necessarily - possible if deg = 0. How do you find this special case?

8. SWE 6198 Alternate rep for IntSet Old rep  Vector els New rep  boolean[100] els Vector otherEls int size More redundancy here, therefore more constraints on the Rep!

9. SWE 6199 Rep Invariant for new IntSet els ≠ null && otherEls ≠ null [0..99 elements] not in otherEls no duplicates in otherEls only Integers in otherEls no null in otherEls size = number of True in els (i.e. cardinality of boolean set) + no. of elements in otherEls

10. SWE 61910 repOk() It’s a method, shows up in code you write! If you make a mistake, not easy to identify in spec Locate mistakes sooner if you can run repOk() Non standard, not in Java. Should be! Code you write in this class will have repOk() not hard!

11. SWE 61911 repOk() for Poly public boolean repOk() Good reasons to make access public Client  is there a bug in your code?  is the object state messed up? Returns true or false – not exposes rep. if false  contract violated somewhere  cannot trust the object

12. SWE 61912 Where to call repOk()? repOk() can be used as a diagnostic tool Implementer – verify the execution of a procedure. call at the end of public (mutators, constructors, producers) basically call whenever you mess with the state Client – wherever Production – assertion management tools

13. SWE 61913 Meyer’s Failure Exception Meyer’s only exception when procedure is at fault, not client call to repOK() at end of execution returns false What does it mean? Usual exceptions because some precondition doesn’t hold. This because procedure performed an invalid computation! You should throw FailureException!

14. SWE 61914 Verification and Validation Validation Are my specifications desirable? More on this in Chapter 9 Verification Do my implementations satisfy my specifications? Standard “Computer Science” analysis question Lots of ways to address this question Inspections, Testing, Analysis…

15. SWE 61915 Verification Is a method correct? Two parts: Maintains rep invariant Satisfy the software contract Proof? First part by Inductive argument Base case- constructors/producers Inductive step – mutators/producers

16. SWE 61916 Second part: Contract verification Need AF(c) to check this Example: remove function in IntSet Details in upcoming slides Check every method One method at a time Irrespective of number of methods in class Use the results to document and prove that your code is correct

17. SWE 61917 Verification In Diagram Form Method Contract Method Code AF() Abstract State (After)Abstract State (Before) Representation State (After) Representation State (Before) ?

18. SWE 61918 Example: Verifying remove() public void remove (int x) //Modifies: this //Effects: Removes x from this, i.e., this_post=this –{x} public void remove (int x) { //Modifies: this //Effects: Remove x from this int i = getIndex(new Integer(x)); if (i < 0) return; els.set(i, els.lastElement()); els.remove(els.size() - 1); }

19. SWE 61919 Data Abstraction Operation Categories Creators Create objects of a data abstraction Producers Take objects of their type as input and create other objects of their type Mutators Modify objects of their type Observers Take objects of their type as inputs and return results of other types

20. SWE 61920 Adequacy of a Data Type Should provide enough operations so that users can manipulate its objects conveniently and efficiently Should have at least three of the four category operations Should be fully populated Possible to obtain every possible abstract object state