1 / 20

Data Abstraction II

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.

geoff
Download Presentation

Data Abstraction II

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Data Abstraction II SWE 619 Software Construction Last Modified, Spring 2009 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?

  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!)

  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 

  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

  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’ • What are the rules for rep used in Poly?

  7. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Verification In Diagram Form Abstract State (Before) Abstract State (After) Method Contract ? AF() AF() Representation State (After) Representation State (Before) Method Code

  18. 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. 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. 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

More Related