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

Slides:



Advertisements
Similar presentations
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
Advertisements

Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Composition CMSC 202. Code Reuse Effective software development relies on reusing existing code. Code reuse must be more than just copying code and changing.
Mutability SWE 332 Fall 2011 Paul Ammann. SWE 3322 Data Abstraction Operation Categories Creators Create objects of a data abstraction Producers Create.
David Evans CS201J: Engineering Software University of Virginia Computer Science Lecture 6: Reasoning about Data Abstractions.
1 Design by Contract Building Reliable Software. 2 Software Correctness Correctness is a relative notion  A program is correct with respect to its specification.
CSE 331 SOFTWARE DESIGN & IMPLEMENTATION ABSTRACT DATA TYPES II Autumn 2011.
Software Testing and Quality Assurance
OOP #10: Correctness Fritz Henglein. Wrap-up: Types A type is a collection of objects with common behavior (operations and properties). (Abstract) types.
Specifications Liskov Chapter 9 SWE 619 Last Updated Fall 2008.
CSE 331 Software Design & Implementation Dan Grossman Fall 2014 Data Abstraction: Abstract Data Types (ADTs) (Based on slides by Mike Ernst, David Notkin,
Computer Science 340 Software Design & Testing Design By Contract.
Ranga Rodrigo. Class is central to object oriented programming.
Cs2220: Engineering Software Class 8: Implementing Data Abstractions Fall 2010 University of Virginia David Evans.
Cs205: engineering software university of virginia fall 2006 Data Abstraction David Evans
SWE 619 © Paul Ammann Procedural Abstraction and Design by Contract Paul Ammann Information & Software Engineering SWE 619 Software Construction cs.gmu.edu/~pammann/
Comp 302: Software Engineering Data Abstractions.
Reasoning about programs March CSE 403, Winter 2011, Brun.
Type Abstraction Liskov, Chapter 7. 2 Liskov Substitution Principle In any client code, if the supertype object is substituted by a subtype object, the.
Data Abstractions EECE 310: Software Engineering.
CSE 331 Software Design & Implementation Hal Perkins Autumn 2012 Abstract Data Types – Examples / Summary (Based on slides by Mike Ernst and David Notkin)
Type Abstraction SWE Spring October 05Kaushik, Ammann Substitution Principle “In any client code, if supertype object is substituted.
Data Abstraction Gang Qian Department of Computer Science University of Central Oklahoma.
Polymorphism Liskov 8. Outline equals() Revisiting Liskov’s mutable vs. not rule Polymorphism Uniform methods for different types “easy” polymorphism.
ANU COMP2110 Software Design in 2003 Lecture 10Slide 1 COMP2110 Software Design in 2004 Lecture 12 Documenting Detailed Design How to write down detailed.
L13: Design by Contract Definition Reliability Correctness Pre- and post-condition Asserts and Exceptions Weak & Strong Conditions Class invariants Conditions.
Data Abstraction SWE 619 Software Construction Last Modified, Spring 2009 Paul Ammann.
SWE 4743 Abstract Data Types Richard Gesick. SWE Abstract Data Types Object-oriented design is based on the theory of abstract data types Domain.
Understanding ADTs CSE 331 University of Washington.
Representation invariants and abstraction functions CSE 331 UW CSE.
PROGRAMMING PRE- AND POSTCONDITIONS, INVARIANTS AND METHOD CONTRACTS B MODULE 2: SOFTWARE SYSTEMS 13 NOVEMBER 2013.
Polymorphism SWE 619. Outline equals() Revisiting Liskov’s mutable vs. not rule Polymorphism Uniform methods for different types “easy” polymorphism Element.
CSE 331 Software Design & Implementation Dan Grossman Fall 2014 Abstraction Functions (Based on slides by Mike Ernst, David Notkin, Hal Perkins)
Iteration Abstraction SWE Software Construction Fall 2009.
Abstraction, Specification and Verification. Comp 302, Spring Abstraction Hiding or overlooking detail that is not relevant for the task at hand.
Mutability SWE 332 Fall 2015 Paul Ammann. SWE 3322 Data Abstraction Operation Categories Creators Create objects of a data abstraction Producers Create.
David Evans CS201J: Engineering Software University of Virginia Computer Science Lecture 7: A Tale of Two Graphs (and.
CPSC 252 ADTs and C++ Classes Page 1 Abstract data types (ADTs) An abstract data type is a user-defined data type that has: private data hidden inside.
David Evans CS201J: Engineering Software University of Virginia Computer Science Lecture 5: Implementing Data Abstractions.
Zach Tatlock / Winter 2016 CSE 331 Software Design and Implementation Lecture 6 Representation Invariants.
Interface specifications At the core of each Larch interface language is a model of the state manipulated by the associated programming language. Each.
Reasoning and Design (and Assertions). How to Design Your Code The hard way: Just start coding. When something doesn’t work, code some more! The easier.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
Programming Techniques Lec05 Data Abstraction (Chapter 5) Software Engineering Fall 2005.
EECE 310: Software Engineering
EECE 310: Software Engineering
Input Space Partition Testing CS 4501 / 6501 Software Testing
Reasoning about code CSE 331 University of Washington.
Specifications Liskov Chapter 9
Type Abstraction SWE Spring 2009.
Abstraction Functions and Representation Invariants
CSE 331 Software Design and Implementation
CSE 331 Software Design and Implementation
Abstraction functions, Reasoning About ADTs
CSE 331 Software Design & Implementation
Type Abstraction Liskov, Chapter 7.
Data Abstraction David Evans cs205: engineering software
Iteration Abstraction
SWE 619 Software Construction Last Modified, Fall 2015 Paul Ammann
Method Verification CS/SWE 332 Paul Ammann.
Lecture 7: A Tale of Two Graphs CS201j: Engineering Software
Lecture 4: Data Abstraction CS201j: Engineering Software
619 Final Review Last updated Spring 2010 © : Paul Ammann.
EECE 310: Software Engineering
Assertions References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 4/25/2019.
Computer Science 340 Software Design & Testing
Type Abstraction SWE Spring 2013.
Software Specifications
Basic Mutability Paul Ammann.
Method Verification Paul Ammann.
Presentation transcript:

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

SWE 6192 Main agenda Abstraction function- AF(c) Rep Invariant- RI Verification Why should I care? What are they? How to implement? How to use?

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

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

SWE 6195 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

SWE 6196 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 6197 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?

SWE 6198 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!

SWE 6199 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 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!

SWE 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 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 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 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…

SWE 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

SWE 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

SWE Verification In Diagram Form Method Contract Method Code AF() Abstract State (After)Abstract State (Before) Representation State (After) Representation State (Before) ?

SWE 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 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

SWE 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