1. SWE 619 Software Construction Last Modified, Fall 2015 Paul Ammann
Data Abstraction II
SWE 619
Software Construction
Last Modified, Fall 2015
Paul Ammann

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

3. 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!)
SWE 619

4.  AF(c) Example Poly: c0+c1x1+…+cnxn
Rep int [] trms  array of integers
int deg  degree of the Poly
Redundant variable deg
AF() = ci= trms[i] for i <=deg and 0 for all other i 
SWE 619

5. 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
SWE 619

6. 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’
See in-class exercise for example
SWE 619

7. 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!
SWE 619

8. 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
SWE 619

9. 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()
SWE 619

10. 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 state is modified
Client – wherever
Production – assertion management tools
SWE 619

11. Verification and 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…
SWE 619

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

13. 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
SWE 619

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

15. 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) {
//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); }
SWE 619