Data Abstraction II SWE 619 Software Construction Last

Data Abstraction II SWE 619 Software Construction Last Modified, Spring 2009 Paul Ammann

Main agenda n n n n 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 n n n 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? n n SWE 619 Testing - need to recognize incorrect behavior Analysis - need support (today’s lecture!) 3

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

What does AF(c) do? n n n 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) n SWE 619 Illegal instances ≈ Bug in software 5

RI for Poly n n n 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 n trms ≠ null can never be null. n n Relation between deg and trms. length n n Therefore dereferencing must never throw NPE Redundancy hence relationship trms. length = deg +1 deg >= 0 trms[deg] ≠ 0 Is this true? n n SWE 619 Not necessarily - possible if deg = 0. How do you find this special case? 7

Alternate rep for Int. Set n n Old rep Vector els New rep boolean[100] els Vector other. Els int size n SWE 619 More redundancy here, therefore more constraints on the Rep! 8

Rep Invariant for new Int. Set n n n els ≠ null && other. Els ≠ null [0. . 99 elements] not in other. Els no duplicates in other. Els only Integers in other. Els no null in other. Els size = number of True in els (i. e. cardinality of boolean set) + no. of elements in other. Els SWE 619 9

rep. Ok() n n n 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 rep. Ok() Non standard, not in Java. Should be! Code you write in this class will have rep. Ok() n SWE 619 not hard! 10

rep. Ok() for Poly public boolean rep. Ok() n Good reasons to make access public n Client is there a bug in your code? is the object state messed up? n Returns true or false – not exposes rep. n if false contract violated somewhere cannot trust the object SWE 619 11

Where to call rep. Ok()? n n rep. Ok() can be used as a diagnostic tool Implementer – verify the execution of a procedure. n n 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 n Meyer’s only exception n n n when procedure is at fault, not client call to rep. OK() 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 Failure. Exception! SWE 619 13

Verification and Validation n n n Are my specifications desirable? More on this in Chapter 9 Verification n Do my implementations satisfy my specifications? Standard “Computer Science” analysis question Lots of ways to address this question n SWE 619 Inspections, Testing, Analysis… 14

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

Second part: Contract verification n n Need AF(c) to check this Example: remove function in Int. Set n n Check every method n n n 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() 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 = get. Index(new Integer(x)); if (i < 0) return; els. set(i, els. last. Element()); els. remove(els. size() - 1); } SWE 619 18

Data Abstraction Operation Categories n Creators n n Producers n n Take objects of their type as input and create other objects of their type Mutators n n Create objects of a data abstraction Modify objects of their type Observers n SWE 619 Take objects of their type as inputs and return results of other types 19

Adequacy of a Data Type n n n 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 n SWE 619 Possible to obtain every possible abstract object state 20