Data Abstraction II
SWE 619
Software Construction
Last Modified, Fall 2015
Paul Ammann
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
2
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?


SWE 619
Testing - need to recognize incorrect behavior
Analysis - need support (today’s lecture!)
3
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
4
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)

SWE 619
Illegal instances ≈ Bug in software
5
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
6
Alternate rep for IntSet


Old rep  Vector els
New rep  boolean[100] els
Vector otherEls
int size

SWE 619
More redundancy here, therefore more
constraints on the Rep!
7
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
8
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
9
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
10
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

SWE 619
Inspections, Testing, Analysis…
11
Verification


Is a method correct?
Two parts:



Maintains rep invariant
Satisfy the software contract
Proof?

First part by Inductive argument


SWE 619
Base case- constructors/producers
Inductive step – mutators/producers
12
Second part: Contract
verification


Need AF(c) to check this
Example: remove function in IntSet


Check every method



Details in upcoming slides
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
13
Verification In Diagram Form
Abstract State (Before)
Method
Contract
Abstract State (After)
?
AF()
AF()
Representation State (Before)
Representation State (After)
Method
Code
SWE 619
14
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); }
SWE 619
15