CSE 12 – Basic Data Structures

48
CSE 12 – Basic Data Structures Cynthia Bailey Lee Some slides and figures adapted from Paul Kube’s CSE 12 CS2 in Java Peer Instruction Materials by Cynthia Lee is licensed under a Creative Commons Attribution - NonCommercial 4.0 International License. Based on a work at http://peerinstruction4cs.or g . Permissions beyond the scope of this license may be available at http://peerinstruction4cs.or g .

description

- PowerPoint PPT Presentation

Transcript of CSE 12 – Basic Data Structures

Page 1: CSE 12 – Basic Data Structures

CSE 12 – Basic Data StructuresCynthia Bailey Lee

Some slides and figures adapted from Paul Kube’s CSE 12

                          

CS2 in Java Peer Instruction Materials by Cynthia Lee is

licensed under a Creative Commons Attribution-

NonCommercial 4.0 International License.

Based on a work at http://peerinstruction4cs.org.

Permissions beyond the scope of this license may be available at 

http://peerinstruction4cs.org.

Page 2: CSE 12 – Basic Data Structures

Reading Quiz!

1) Which of the following would qualify as a mutator method?

A. A method that does not return a value but changes the state of an object.

B. A method that returns a value without changing the state of the object.

Page 3: CSE 12 – Basic Data Structures

Reading Quiz!2) Which of the following would NOT be part of the an ADT specification?

I. What operations are supported on the data type.II. The language that it should be implemented in.III. The values that the data type might take.IV. How the data type should be implemented.

Options:A. I and IVB. I and IIIC. II and IIID. II and IV

Page 4: CSE 12 – Basic Data Structures

Reading Quiz!

3) Testing a class based on the ADT specification, without knowing the implementation is called:

A. Test driven developmentB. Black-box testingC. White-box testingD. Unit testing

Page 5: CSE 12 – Basic Data Structures

Reading Quiz!

4) Which of the following demonstrates a Composition design pattern?

A. A class ArrayList implementing the List interface.

B. A class Queue using a LinkedList object internally, to store and retrieve items.

C. A class Circle extending a class Shape.

Page 6: CSE 12 – Basic Data Structures

Inheritance vs. CompositionDesign patterns using UML

Page 7: CSE 12 – Basic Data Structures

Collections A collection is an ADT that contains data

elements, and provides operations on them

7

There are different ways that elements can be “collected”: Set List Sorted list …

All collections implement the interface Collection

Page 8: CSE 12 – Basic Data Structures

Java Generics Key to Java’s Collections are generics

Generics answer the question: “what is the collection a collection of?”

If this question isn’t enforced with generics, there can be runtime errors when the what comes out of the collection is not what you expected

Set<E> means a set of things that are of type E.

Page 9: CSE 12 – Basic Data Structures

Which choice is the most reasonable model of our bag of presents?

A. public class Present<Bag> implements Collection<Bag>

B. public class Bag<Collection> implements Present<Collection>

C. public class Present<Collection> implements Bag<Collection>

D. public class Bag<Present> implements Collection<Present>

E. Other/none/more than one

Page 10: CSE 12 – Basic Data Structures

Placing limits on what kind of thing our collection can store

This is a kid, so we ONLY want the bag to hold presents that are: Wrapable (can be wrapped in paper)

Implements a “wrap()” method Playable (can be played with)

Implements a “play()” method

How can we represent these requirements in Java?

Page 11: CSE 12 – Basic Data Structures

Java InterfacesADTs in the Java language

Page 12: CSE 12 – Basic Data Structures

12

Actual Google interview question (given to a UCSD student)

Given an interface called Set with the functions union, intersect and subtract, implement that interface in a class.

Page 13: CSE 12 – Basic Data Structures

13

Actual Google interview question (given to a UCSD student)

Given an interface called Set with the functions union, intersect and subtract, implement that interface in a class.

What would our implementation start with?

A. public class Set<E> {B. public class MySet<E> extends Set<E> {C. public class FancySet<E> implements

Set<E> {

D. Other/none/more than one

Page 14: CSE 12 – Basic Data Structures

UML Class Diagram: Implementation

LinkedList and ArrayList “is-a” List List is a datatype, but you cannot create a List

by new List() To create a List, you must create an instance of a

class that implements the List interface

<<interface>>List

add(Object)

size()

ArrayListLinkedList

14

Page 15: CSE 12 – Basic Data Structures

Back to the presents example: How can we represent the Playable and Wrapable requirements in Java?

1. Create interfaces Playable (has a method void play())and a method Wrapable (has a method void wrap())

2. Now how do we use those interfaces to impose the requirements on Present?

<<interface>>Wrapable

wrap()

Present

<<interface>>Playable

play()

<<interface>>Wrapable

wrap()

Present

<<interface>>Playable

play()

A.

B.

C. Other/ none/ more than one

D. I don’t understand this!!

Page 16: CSE 12 – Basic Data Structures

Back to the presents example: How can we represent the Playable and Wrapable requirements in Java?

1. Create interfaces Playable and Wrapable

2. Create a class* Present that implements Wrapable and Playable.

3. Create classes for different kinds of presents, all of which extend* Present

4. Now objects of those classes can be stored in the Bag<Present> collection!

<<interface>>Wrapable

wrap()

Present

<<interface>>Playable

play()

Doll

ToyCar

NerfGun

Page 17: CSE 12 – Basic Data Structures

Interfaces and Implementation• A class implementing an interface defines an “is a”

relationship between the class and the interface

– A LinkedList “is a” List

– A class inherits method signatures from interfaces it implements

• An interface can extend one or more other interfaces

– A Set “is-a” Collection

– An interface inherits method signatures from interfaces it extends

17

Page 18: CSE 12 – Basic Data Structures

Some Interfaces in JCF

18

Page 19: CSE 12 – Basic Data Structures

Some Classes Implementing Interfaces in JCF

19

Page 20: CSE 12 – Basic Data Structures

Software TestingBlack box and clear box

Page 21: CSE 12 – Basic Data Structures

In CSE 12 we will take a test-driven development approach, with unit testing

Test-driven development means: first writing tests, and then writing the software that will be tested

21

Test-driven Development

Page 22: CSE 12 – Basic Data Structures

Black-box Testing You don’t know (or you pretend you don’t know)

how something is implemented You test only based on inputs and outputs

Clear-box Testing (Also known as “white-box testing”) If you can look inside the black box and see how a

method is implemented, you can do more detailed testing

Page 23: CSE 12 – Basic Data Structures

Designing clear-box tests How many test cases would you need to do thorough

clear-box testing on this code?

public void mysteryMethod(int x){someMethod();if (x < 5){methodCall();} else {otherMethod();}anotherOne();

}

23

A. 1 test caseB. 2 test casesC. 3 test casesD. > 3 test

cases

Page 24: CSE 12 – Basic Data Structures

Discussion What do you think are advantages and

disadvantages to each? When might you do black-box testing? When might you do clear-box testing?

Page 25: CSE 12 – Basic Data Structures

Software TestingJava’s JUnit system

Page 26: CSE 12 – Basic Data Structures

Unit testing• Whether you are doing black-box or clear-box

testing, you should test every important unit of a software system

• What is a unit? In object-oriented programming, usually a software unit is taken to be a single method

• So: we should test every method of every class in the software

• JUnit is a widely used framework for unit testing of Java software…

26

Page 27: CSE 12 – Basic Data Structures

Unit testing with the swingui of Junit 3.8.1: all tests passed

The green bar of happiness;all tests passed!

Names of the testing methodscorresponding to the test casesyou prepared. A green check mark means the test passed.

27

Page 28: CSE 12 – Basic Data Structures

When one or more tests fail

The red bar of sadness;some tests failed

Names of the testing methodsin your test suite. A red X means the test failed.

Stack trace telling what wasexpected, what was generated and where the test failed;very handy!

28

Page 29: CSE 12 – Basic Data Structures

JUnit basics To do unit testing in the Junit framework: Define a subclass of junit.framework.TestCase Optional:

Define instance variables that store the state of the “test fixture”, i.e. the objects that will be tested

Initialize the fixture state by overriding the setUp() instance method

Clean-up the fixture state after a test by overriding the tearDown() instance method

Define public void no-argument methods with names that start with test. Each “testXXX” method should be written to test a particular aspect of the test fixture

Define a main() method to run your TestCase class as a program

29

Page 30: CSE 12 – Basic Data Structures

import junit.framework.*;

public class RectangleTester extends TestCase {

private Rectangle r1, r2; // test fixtures

TestCase and test fixtures Define a subclass of junit.framework.TestCase Define instance variables that store the state of the

“test fixture”, i.e. the objects that will be tested

To inherit the testing and test run methods we will need

30

Page 31: CSE 12 – Basic Data Structures

setUp() and tearDown()

/* Called AUTOMATICALLY before each testXXX() method is run */protected void setUp() { r1 = new Rectangle();

r2 = new Rectangle(2.0,3.0);}

/* Called AUTOMATICALLY after each testXXX() method is run */protected void tearDown() {

r1 = null; r2 = null;}

setup();testXXX();teardown();

This is the sequence of calls the JUnit framework does for you automatically for each test method testXXX() that is invoked.

Make sure each test method startswith a clean copy of the test fixture.

31

Page 32: CSE 12 – Basic Data Structures

Coding a test case as a “testXXX” method/** Test case 2.1: verify that default constructor sets default instance variable values correctly*/public void testDefaultInstance() {

assertEquals(1.0,r1.getLength()); assertEquals(1.0,r1.getHeight());

}

/** Test case 2.6: verify that mutator for length throws * exception on illegal input.*/public void testMutatorIllegalInput() {

try {r1.setLength(0); // 0 is illegal, should throwfail();

} catch (IllegalArgumentException e) {// test passes

}}

Remember: setUp() will be called prior to each test method getting called, creating test object r1 anew for each test

32

Page 33: CSE 12 – Basic Data Structures

Running your TestCase class

/** Run RectangleTester as a gui application */

public static void main(String args[]) { junit.swingui.TestRunner.main(new String[] {“RectangleTester”});}

To run a class as a program, the class must have a public static void main() method. Here are two ways to define it in the Junit 3.8.1 framework, depending on whether you want a GUI or text version:

/** Run RectangleTester as a text console application */

public static void main(String args[]) { junit.textui.TestRunner.main(new String[] {“RectangleTester”});}

33

Page 34: CSE 12 – Basic Data Structures

More JUnit basics Test fixture instance variables are optional: you

can do the same thing with local variables inside the test methods

If you are not using test fixture instance variables, you do not need to define setUp() and tearDown() either

When you run your TestCase class as a program, each “testXXX” method is called automatically…

If a Junit assertion fails when a testXXX method runs, that test fails

If testXXX method throws an exception, that is considered an error, not a test failure!

If a testXXX method returns normally, that test passes

34

Page 35: CSE 12 – Basic Data Structures

JUnit 3.8.1 assertion methods The JUnit framework provides many useful assertion

methods to use in your testXXX() methods

assertEquals(x,y) // fail if x is not equal to yassertTrue(b) // fail if b has boolean value falseassertFalse(b) // fail if b has boolean value trueassertSame(x,y) // fail if x and y point to different objectsassertNotSame(x,y) // fail if x and y point to the same objectassertNull(x) // fail if x is not nullassertNotNull(x) // fail if x is nullfail() // always fails

All these assertion methods are overloaded with a version that takes an additional first argument of type String, a message which will be printed out in some contexts

35

Page 36: CSE 12 – Basic Data Structures

Specifying an ADT An ADT specifies the possible values instances of the ADT can

have, and specifies the operations the ADT provides on those values

In more detail, an ADT specification should generally include these:

ADT name: The name of the data type.

ADT description: A brief summary description of the type.

ADT invariants: Assertions that must always be true of any instance of this type.

ADT attributes: Aspects of the state of an instance of the type,

as observable by a client

ADT operations: The behavior of an instance of the type, as observable by a client.

36

Page 37: CSE 12 – Basic Data Structures

Specifying operations of an ADT Specifying ADT operations is particularly important: these

operations constitute the API, and are the primary way that users of the ADT interact with its instances.

For each ADT operation, you should specify:

responsibilities: A brief summary of what the operation does.

pre-conditions: What must be true on entry to the operation if the operation is to execute successfully. This may include assumptions about the state of the object, assumptions about the parameters passed in, etc. An operation's pre-conditions must be consistent with all of the ADT's invariants.

post-conditions: What the operation guarantees to be true when it returns, if the pre-conditions were true when the operation was called. An operation's post-conditions must be consistent with all of the ADT’s invariants.

returns: The value, if any, returned by the operation. exceptions: A description of the exceptions the operation

may throw.

37

Page 38: CSE 12 – Basic Data Structures

Programming by contract A precise and complete specification of an

ADT operation is a contract for the operation It lays out the responsibilities of the

provider (the method) and the client (any caller of the method)

If both sides meets their responsibilities, the operation will work

The contract is a guide both for the implementer and the users of the method

Writing these specifications first, then implementing them, is sometimes called programming by contract

38

Page 39: CSE 12 – Basic Data Structures

Pre- and Post-conditions

Think of method preconditions as the method saying:

“I require this.” Think of method postconditions as the method saying:

“I ensure this.”

If the preconditions are satisfied when the method is called, then the method guarantees that the postconditions will be satisfied when the method returns. If the preconditions are not satisfied -- that is, if the client does not meet its end of the contract -- then the method does not guarantee anything!

39

Page 40: CSE 12 – Basic Data Structures

Checkpoint

What is the relationship between ADT or class invariants and an operation’s pre- and post-conditions?

How do pre- and post-conditions relate to writing a test for the operation?

Can you write a test for what the operation does when its pre-conditions are not met?

40

Page 41: CSE 12 – Basic Data Structures

Example ADT specification: Rectangle

Description A rectangle is a four-sided shape in which opposite sides

are parallel and equal in size. The size of a side must be greater than 0. A rectangle has four right angles.

Invariants Opposite sides are of equal size. Length and height must be greater than 0.

Attributes DEFAULT_SIZE a constant, the default size for the

dimensions length size of the “top” and “bottom” sides height size of the “left” and “right” sides surface area the surface area of the rectangle perimeter the perimeter of this rectangle

41

Page 42: CSE 12 – Basic Data Structures

Review of Java Exceptions Exceptions are a way of signaling that something

exceptional has happened at runtime

When an “exceptional condition” occurs, an exception object is created storing information about the nature of the exception (kind, where it occurred, etc.), and then this exception object is thrown

The JVM looks back through the chain of method calls for a block of code to catch and handle the exception

If there isn't a catch block for the exception, your program will be killed, and some diagnostic info printed to the terminal

42

Page 43: CSE 12 – Basic Data Structures

remember, thismeans extends

43

Page 44: CSE 12 – Basic Data Structures

Kinds of exceptions Checked exceptions –

Descended from class Throwable, but not descended from RuntimeException or Error.

The compiler will check that you either catch or rethrow checked exceptions

Unchecked exceptions – Descended from RuntimeException or from

Error The compiler does not check to see that

you catch or explictly rethrow these exceptions (though of course you can catch or declare them if you want)

44

Page 45: CSE 12 – Basic Data Structures

Creating and Throwing an Exception Though it is not strictly required by the

Programming-by-Contract paradigm, a method can check to see if its own preconditions are met

If it finds that its preconditions are not met, what should it do?

Creating and throwing an exception, instead of attempting to complete the operation or returning a value, is often a good design decision

If so, this should be documented as part of the specification of the method

Example: setLength() method in a Rectangle class…

45

Page 46: CSE 12 – Basic Data Structures

Creating and Throwing an ExceptionTwo ways to specify the setLength() operation…

setLength( newLength )pre-condition: newLength > 0responsibilities: sets length to newLength post-condition: rectangle’s length field is set to newLengthreturns: nothing

Becomes:

setLength( newLength )pre-condition: newLength > 0responsibilities: sets length to newLength post-condition: rectangle’s length field is set to newLengthreturns: nothingthrows: IllegalArgumentException if precondition

is not met

46

Page 47: CSE 12 – Basic Data Structures

Implementing setLength

/** * Set the length dimension of this <tt>Rectangle</tt>. * @param theLength the new length of this <tt>Rectangle</tt>; * must be > 0 * @throws IllegalArgumentException if <tt>theLength</tt> is <= 0. */public void setLength( double theLength ) { if ( theLength <= 0 ) throw new IllegalArgumentException(“Illegal Rectangle length (“ + theLength + “): must be > 0 “); this.length = theLength;}

Create an exception object the way you create any other kindof object, with new.Throw the exception with the reserved word throw.

Document that the method throws an exception

47

Page 48: CSE 12 – Basic Data Structures

Next time

o Test plans, test cases, and more about JUnito The Collection and List Interfaces in the JCFo Iterators and the Iterator Patterno Developing a test plan for a Collection or List

class

Reading: Gray, Ch 4 and Ch 5

48