Liskov 5.5-5.10

advertisement
Data Abstraction II
SWE 619
Software Construction
Last Modified, Spring 2009
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’
What are the rules for rep used in Poly?
SWE 619
6
RI for Poly

trms ≠ null  can never be null.


Relation between deg and trms.length




Therefore dereferencing must never throw NPE
Redundancy hence relationship
trms.length = deg +1
deg >= 0
trms[deg] ≠ 0 Is this true?


SWE 619
Not necessarily - possible if deg = 0.
How do you find this special case?
7
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!
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
not hard!
10
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
SWE 619
11
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
SWE 619
12
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!
SWE 619
13
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…
14
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
15
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
16
Verification In Diagram Form
Abstract State (Before)
Method
Contract
Abstract State (After)
?
AF()
AF()
Representation State (Before)
Representation State (After)
Method
Code
SWE 619
17
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
18
Data Abstraction Operation
Categories

Creators


Producers


Take objects of their type as input and create
other objects of their type
Mutators


Create objects of a data abstraction
Modify objects of their type
Observers

SWE 619
Take objects of their type as inputs and return
results of other types
19
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

SWE 619
Possible to obtain every possible abstract
object state
20
Download