CSE 331 Software Design & Implementation Dan Grossman Fall 2014 Data Abstraction: Abstract Data Types (ADTs) (Based on slides by Mike Ernst, David Notkin,

Slides:



Advertisements
Similar presentations
Identity and Equality Based on material by Michael Ernst, University of Washington.
Advertisements

Mutability SWE 332 Fall 2011 Paul Ammann. SWE 3322 Data Abstraction Operation Categories Creators Create objects of a data abstraction Producers Create.
COMPSCI 105 S Principles of Computer Science 12 Abstract Data Type.
Data Abstraction II SWE 619 Software Construction Last Modified, Spring 2009 Paul Ammann.
CSE 331 SOFTWARE DESIGN & IMPLEMENTATION ABSTRACT DATA TYPES II Autumn 2011.
CSE341: Programming Languages Lecture 12 Modules Dan Grossman Fall 2011.
Abstraction Functions. Announcements Exam 1 on Tuesday March 3 rd Closed book/phone/laptop 2 cheat pages allowed (handwritten or typed) 1 double-sided.
Class Design CSC 171 FALL 2004 LECTURE 11. READING Read Chapter 7 It’s abstract But it should help with project #1.
CSC 395 – Software Engineering Lecture 21: Overview of the Term & What Goes in a Data Dictionary.
Understanding class definitions Looking inside classes.
Cs205: engineering software university of virginia fall 2006 Semantics and Specifying Procedures David Evans
Slides by Vinod Rathnam with material from Alex Mariakakis Kellen Donohue, David Mailhot, and Hal Perkins Midterm Review.
CSE 331 Software Design & Implementation Hal Perkins Autumn 2012 Java Classes, Interfaces, and Types 1.
Chapter 3 Introduction to Collections – Stacks Modified
Cs2220: Engineering Software Class 8: Implementing Data Abstractions Fall 2010 University of Virginia David Evans.
Data Abstraction CS 201j: Engineering Software University of Virginia Computer Science Nathanael Paul
Cs205: engineering software university of virginia fall 2006 Data Abstraction David Evans
CSE 331 SOFTWARE DESIGN & IMPLEMENTATION MIDTERM REVIEW Autumn 2011.
Design Patterns Gang Qian Department of Computer Science University of Central Oklahoma.
Comp 302: Software Engineering Data Abstractions.
Topic 1 Object Oriented Programming. 1-2 Objectives To review the concepts and terminology of object-oriented programming To discuss some features of.
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)
CSCI 1100/1202 April 1-3, Program Development The creation of software involves four basic activities: –establishing the requirements –creating.
Chapter 3 Collections. Objectives  Define the concepts and terminology related to collections  Explore the basic structures of the Java Collections.
Polymorphism Liskov 8. Outline equals() Revisiting Liskov’s mutable vs. not rule Polymorphism Uniform methods for different types “easy” polymorphism.
Data Abstraction SWE 619 Software Construction Last Modified, Spring 2009 Paul Ammann.
Data Design and Implementation. Definitions Atomic or primitive type A data type whose elements are single, non-decomposable data items Composite type.
Understanding ADTs CSE 331 University of Washington.
Representation invariants and abstraction functions CSE 331 UW CSE.
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.
Zach Tatlock / Winter 2016 CSE 331 Software Design and Implementation Lecture 13 Generics 1.
CSE 331 Software Design & Implementation Hal Perkins Winter 2015 Data Abstraction: Abstract Data Types (ADTs) (Based on slides by Mike Ernst, Dan Grossman,
CSE 331 SOFTWARE DESIGN & IMPLEMENTATION ABSTRACT DATA TYPES Autumn 2011.
Slides with material from Alex Mariakakis, Krysta Yousoufian, Mike Ernst, Kellen Donohue Section 3: HW4, ADTs, and more.
1 CSE 331 Specifications slides created by Marty Stepp based on materials by M. Ernst, S. Reges, D. Notkin, R. Mercer, Wikipedia
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.
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.
Representation Invariants and Abstraction Functions.
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.
CSCE 240 – Intro to Software Engineering Lecture 3.
Lecture 5:Interfaces and Abstract Classes Michael Hsu CSULA.
Slides by Alex Mariakakis Section 5: Midterm Review.
CSE 331 Software Design & Implementation Hal Perkins Autumn 2012 Data Abstraction: Abstract Data Types (ADTs) (Based on slides by Mike Ernst and David.
Advanced Data Structures Lecture 1
EECE 310: Software Engineering
CSE 331 Software Design & Implementation
CSE 331 Software Design & Implementation
Subroutines Idea: useful code can be saved and re-used, with different data values Example: Our function to find the largest element of an array might.
CSC 480 Software Engineering
Representation Invariants and Abstraction Functions
Abstraction functions, Reasoning About ADTs
Section 6: Midterm Review
Data Abstraction David Evans cs205: engineering software
CSE 331 Software Design & Implementation
SWE 619 Software Construction Last Modified, Fall 2015 Paul Ammann
Method Verification CS/SWE 332 Paul Ammann.
Lecture 4: Data Abstraction CS201j: Engineering Software
CSE 331 Software Design & Implementation
EECE 310: Software Engineering
CSE 331 Software Design & Implementation
CSE 331 Software Design & Implementation
CSE 331 Software Design & Implementation
Software Specifications
Method Verification Paul Ammann.
Presentation transcript:

CSE 331 Software Design & Implementation Dan Grossman Fall 2014 Data Abstraction: Abstract Data Types (ADTs) (Based on slides by Mike Ernst, David Notkin, Hal Perkins)

Outline This lecture: 1.What is an Abstract Data Type (ADT)? 2.How to specify an ADT? 3.Design methodology for ADTs Very related next lectures: Representation invariants Abstraction functions Two distinct, complementary ideas for reasoning about ADTs 2CSE331 Fall 2014

Procedural and data abstractions Procedural abstraction: –Abstract from details of procedures (e.g., methods) –Specification is the abstraction Abstraction is the specification –Satisfy the specification with an implementation Data abstraction: –Abstract from details of data representation –Also a specification mechanism A way of thinking about programs and design –Standard terminology: Abstract Data Type, or ADT 3CSE331 Fall 2014

Why we need Data Abstractions (ADTs) Organizing and manipulating data is pervasive –Inventing and describing algorithms is less common Start your design by designing data structures –How will relevant data be organized –What operations will be permitted on the data by clients –Cf. CSE 332 Potential problems with choosing a data abstraction: –Decisions about data structures often made too early –Duplication of effort in creating derived data –Very hard to change key data structures (modularity!) 4CSE331 Fall 2014

An ADT is a set of operations ADT abstracts from the organization to meaning of data ADT abstracts from structure to use Representation should not matter to the client –So hide it from the client Instead, think of a type as a set of operations create, getBase, getAltitude, getBottomAngle, … Force clients to use operations to access data class RightTriangle { float base, altitude; } class RightTriangle { float base, hypot, angle; } 5CSE331 Fall 2014

Are these classes the same? class Point { public float x; public float r; public float y; public float theta; } Different: cannot replace one with the other in a program Same: both classes implement the concept “2-d point” Goal of ADT methodology is to express the sameness: –Clients depend only on the concept “2-d point” 6CSE331 Fall 2014

Benefits of ADTs If clients “respect” or “are forced to respect” data abstractions… –For example, “it’s a 2-D point with these operations…” Can delay decisions on how ADT is implemented Can fix bugs by changing how ADT is implemented Can change algorithms –For performance –In general or in specialized situations … We talk about an “abstraction barrier” –A good thing to have and not cross (also known as violate) CSE331 Fall 20147

Concept of 2-d point, as an ADT class Point { // A 2-d point exists in the plane,... public float x(); public float y(); public float r(); public float theta(); //... can be created,... public Point(); // new point at (0,0) public Point centroid(Set points); //... can be moved,... public void translate(float delta_x, float delta_y); public void scaleAndRotate(float delta_r, float delta_theta); } 8 Observers Creators/ Producers Mutators CSE331 Fall 2014

Point x y r theta translate scale_rot rest of program abstraction barrier Abstract data type = objects + operations Implementation is hidden The only operations on objects of the type are those provided by the abstraction clients implementation 9CSE331 Fall 2014

Specifying a data abstraction A collection of procedural abstractions –Not a collection of procedures An abstract state –Not the (concrete) representation in terms of fields, objects, … –“Does not exist” but used to specify the operations –Concrete state, not part of the specification, implements the abstract state More in upcoming lecture Each operation described in terms of “creating”, “observing”, “producing”, or “mutating” –No operations other than those in the specification 10CSE331 Fall 2014

Specifying an ADT Mutable 1. overview 2. abstract state 3. creators 4. observers 5. producers (rare) 6. mutators Immutable 1. overview 2. abstract state 3. creators 4. observers 5. producers 6. mutators Creators: return new ADT values (e.g., Java constructors) Producers: ADT operations that return new values Mutators: Modify a value of an ADT Observers: Return information about an ADT CSE331 Fall

Implementing an ADT To implement a data abstraction (e.g., with a Java class): –See next two lectures –This lecture is just about specifying an ADT –Nothing about the concrete representation appears in the specification 12CSE331 Fall 2014

Poly, an immutable datatype: overview /** * A Poly is an immutable polynomial with * integer coefficients. A typical Poly is * c 0 + c 1 x + c 2 x **/ class Poly { Overview: –State whether mutable or immutable –Define an abstract model for use in operation specifications Difficult and vital! Appeal to math if appropriate Give an example (reuse it in operation definitions) –State in specifications is abstract, not concrete 13 Abstract state (specification fields) CSE331 Fall 2014

Poly: creators // effects: makes a new Poly = 0 public Poly() // effects: makes a new Poly = cx n // throws: NegExponent if n < 0 public Poly(int c, int n) Creators –New object, not part of pre-state: in effects, not modifies –Overloading: distinguish procedures of same name by parameters (Example: two Poly constructors) Footnote: slides omit full JavaDoc comments to save space; style might not be perfect either – focus on main ideas 14CSE331 Fall 2014

Poly: observers // returns: the degree of this, // i.e., the largest exponent with a // non-zero coefficient. // Returns 0 if this = 0. public int degree() // returns: the coefficient of the term // of this whose exponent is d // throws: NegExponent if d < 0 public int coeff(int d) 15CSE331 Fall 2014

Notes on observers Observers –Used to obtain information about objects of the type –Return values of other types –Never modify the abstract value –Specification uses the abstraction from the overview this –The particular Poly object being accessed –Target of the invocation –Also known as the receiver Poly x = new Poly(4, 3); int c = x.coeff(3); System.out.println(c); // prints 4 16CSE331 Fall 2014

Poly: producers // returns: this + q (as a Poly) public Poly add(Poly q) // returns: the Poly equal to this * q public Poly mul(Poly q) // returns: -this public Poly negate() 17CSE331 Fall 2014

Notes on producers Operations on a type that create other objects of the type Common in immutable types like java.lang.String – String substring(int offset, int len) No side effects –Cannot change the abstract value of existing objects 18CSE331 Fall 2014

IntSet, a mutable datatype: overview and creator // Overview: An IntSet is a mutable, // unbounded set of integers. A typical // IntSet is { x1,..., xn }. class IntSet { // effects: makes a new IntSet = {} public IntSet() 19CSE331 Fall 2014

IntSet: observers // returns: true if and only if x  this public boolean contains(int x) // returns: the cardinality of this public int size() // returns: some element of this // throws: EmptyException when size()==0 public int choose() 20CSE331 Fall 2014

IntSet: mutators // modifies: this // effects: this post = this pre  {x} public void add(int x) // modifies: this // effects: this post = this pre - {x} public void remove(int x) 21CSE331 Fall 2014

Notes on mutators Operations that modify an element of the type Rarely modify anything (available to clients) other than this –List this in modifies clause (if appropriate) Typically have no return value –“Do one thing and do it well” –(Sometimes return “old” value that was replaced) Mutable ADTs may have producers too, but that is less common 22CSE331 Fall 2014