200 likes | 419 Views
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?. Correctness.
E N D
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?
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!)
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
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
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?
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?
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!
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
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!
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
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
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!
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…
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
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
Verification In Diagram Form Abstract State (Before) Abstract State (After) Method Contract ? AF() AF() Representation State (After) Representation State (Before) Method Code
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); }
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
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