David Evanshttp://www.cs.virginia.edu/~evans

CS201j: Engineering Software?University of VirginiaComputer Science

Lecture 2: Java Semantics,Validation

2 September 2003 CS 201J Fall 2003 2

Menu

• Objects in Java: Heap and Stack

• Validation: Testing and Analysis

2 September 2003 CS 201J Fall 2003 3

Java Semantics

2 September 2003 CS 201J Fall 2003 4

The Stack and HeapString s = new

String (“hello”);s

“hello”

java.lang.String

Objects live on the Heapnew creates an Object on the Heap

Local variables live on the StackPoint to objects on the Heap

String is a type in the Java API for representing sequences of characters

2 September 2003 CS 201J Fall 2003 5

String s = new String (“hello”);

s

“hello”

java.lang.String

String t = s;

t

2 September 2003 CS 201J Fall 2003 6

String s = new String (“hello”);

s

“hello”

java.lang.String

String t = s;

t

s = new String (“goodbye”);

“goodbye”

java.lang.String

2 September 2003 CS 201J Fall 2003 7

Primitive Types

• Not everything in Java is an Object

• Some types are primitive types– boolean, byte, char, double, float, int,

long, short

• Values of primitive types are stored directly on the stack

2 September 2003 CS 201J Fall 2003 8

String s = new String (“hello”);

s

“hello”

java.lang.String

String t = s;

t

int i = 201;

i 201

int j = i;

j 201How can we see the difference betweenprimitive types and objects?

2 September 2003 CS 201J Fall 2003 9

Equality

x == yObject Types: same objects

Primitive Types: same value

x.equals (y)Object Types: method that compares

values of objectsPrimitive Types: doesn’t exist

2 September 2003 CS 201J Fall 2003 10

“hi”“high”

Mutability

• If an object is mutated, all references to the object see the new value

sbjava.lang.StringBuffer

tb

StringBuffer sb = new (“hi”);StringBuffer tb = sb;tb.append (“gh”);

2 September 2003 CS 201J Fall 2003 11

Immutable/Mutable Types

• Types can be mutable or immutable– Objects of an immutable type never change

value after they are created

• String is immutable, StringBuffer is mutable– String.concat creates a new String object– StringBuffer.append mutates the old object

2 September 2003 CS 201J Fall 2003 12

Java Semantics Questionpublic class Strings { public static void test (String [] args) { String s = new String ("hello"); String t = new String ("hello"); StringBuffer sb = new StringBuffer ("he"); StringBuffer tb = sb; String s1 = "hello"; String t1 = "hello";

sb.append (“llo"); tb.append (" goodbye!"); s.concat (" goodbye!"); t = s.concat (" goodbye!");

// What are the values of s, t, sb and tb now?// Which of these are true:// a) s == t b) s1 == t1 c) s == s1 d) s.equals (t) e) sb == tb f) t.equals (tb) }}

2 September 2003 CS 201J Fall 2003 13

Java Semantics Questionpublic class Strings { public static void test () { String s = new String ("hello"); String t = new String ("hello"); StringBuffer sb = new StringBuffer

("he"); StringBuffer tb = sb; String s1 = "hello"; String t1 = "hello";

sb.append (“llo"); tb.append (" goodbye!"); s.concat (" goodbye!"); t = s.concat (" goodbye!"); } }

s“hello”

java.lang.String

t

sb

tb

“hello”

java.lang.String

“he”

java.lang.StringBuffer

s1

t1 “hello”

java.lang.StringString spec is not enough todetermine if s, t, s1 and t1 arethe same objects! This is what Sun’s JDK 1.4 does. Other implementations could correctly do different things. Note (added Feb 2005): Nora Sovarel noticed that

this isn’t actually true. The JLS section on String literals specifies the behavior as shown.http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#101083

2 September 2003 CS 201J Fall 2003 14

Java Semantics Questionpublic class Strings { public static void test () { String s = new String ("hello"); String t = new String ("hello"); StringBuffer sb = new StringBuffer

("he"); StringBuffer tb = sb; String s1 = "hello"; String t1 = "hello";

sb.append (“llo"); tb.append (" goodbye!"); s.concat (" goodbye!"); t = s.concat (" goodbye!"); } }

s“hello”

java.lang.String

t

sb

tb

“hello”

java.lang.String

“he”

java.lang.StringBuffer

s1

t1 “hello”

java.lang.String

“hello”

2 September 2003 CS 201J Fall 2003 15

Java Semantics Questionpublic class Strings { public static void test () { String s = new String ("hello"); String t = new String ("hello"); StringBuffer sb = new StringBuffer

("he"); StringBuffer tb = sb; String s1 = "hello"; String t1 = "hello";

sb.append (“llo"); tb.append (" goodbye!"); s.concat (" goodbye!"); t = s.concat (" goodbye!"); } }

s“hello”

java.lang.String

t

sb

tb

“hello”

java.lang.String

“he”

java.lang.StringBuffer

s1

t1 “hello”

java.lang.String

“hello goodbye!”

2 September 2003 CS 201J Fall 2003 16

Java Semantics Questionpublic class Strings { public static void test () { String s = new String ("hello"); String t = new String ("hello"); StringBuffer sb = new StringBuffer

("he"); StringBuffer tb = sb; String s1 = "hello"; String t1 = "hello";

sb.append (“llo"); tb.append (" goodbye!"); s.concat (" goodbye!"); t = s.concat (" goodbye!"); } }

s“hello”

java.lang.String

t

sb

tb

“hello”

java.lang.String

“he”

java.lang.StringBuffer

s1

t1 “hello”

java.lang.String

“hello goodbye!”

“hello goodbye!”

java.lang.String

2 September 2003 CS 201J Fall 2003 17

public class Strings { public static void test () { String s = new String ("hello"); String t = new String ("hello"); StringBuffer sb = new StringBuffer

("he"); StringBuffer tb = sb; String s1 = "hello"; String t1 = "hello";

sb.append (“llo"); tb.append (" goodbye!"); s.concat (" goodbye!"); t = s.concat (" goodbye!"); } }

s“hello”

java.lang.String

t

sb

tb

“hello”

java.lang.String

“he”

java.lang.StringBuffer

s1

t1 “hello”

java.lang.String

“hello goodbye!”

“hello goodbye!”

java.lang.String

“hello goodbye!”

java.lang.String

2 September 2003 CS 201J Fall 2003 18

public class Strings { public static void test () { String s = new String ("hello"); String t = new String ("hello"); StringBuffer sb = new StringBuffer

("he"); StringBuffer tb = sb; String s1 = "hello"; String t1 = "hello";

sb.append (“llo"); tb.append (" goodbye!"); s.concat (" goodbye!"); t = s.concat (" goodbye!"); } }

s“hello”

java.lang.String

t

sb

tb

“hello”

java.lang.String

“he”

java.lang.StringBuffer

s1

t1 “hello”

java.lang.String

“hello goodbye!”

“hello goodbye!”

java.lang.String

“hello goodbye!”

java.lang.String

After test returns?

2 September 2003 CS 201J Fall 2003 19

Validation

2 September 2003 CS 201J Fall 2003 20

Dictionary Definition

val·i·date

1. To declare or make legally valid.

2. To mark with an indication of official sanction.

3. To establish the soundness of; corroborate.

Can we do any of these with software?

2 September 2003 CS 201J Fall 2003 21

Java’s LicenseREAD THE TERMS OF THIS AGREEMENT AND ANY PROVIDED SUPPLEMENTAL LICENSE TERMS (COLLECTIVELY "AGREEMENT") CAREFULLY BEFORE OPENING THE SOFTWARE MEDIA PACKAGE.  BY OPENING THE SOFTWARE MEDIA PACKAGE, YOU AGREE TO THE TERMS OF THIS AGREEMENT.  IF YOU ARE ACCESSING THE SOFTWARE ELECTRONICALLY, INDICATE YOUR ACCEPTANCE OF THESE TERMS BY SELECTING THE "ACCEPT" BUTTON AT THE END OF THIS AGREEMENT.  IF YOU DO NOT AGREE TO ALL THESE TERMS, PROMPTLY RETURN THE UNUSED SOFTWARE TO YOUR PLACE OF PURCHASE FOR A REFUND OR, IF THE SOFTWARE IS ACCESSED ELECTRONICALLY, SELECT THE "DECLINE" BUTTON AT THE END OF THIS AGREEMENT.

2 September 2003 CS 201J Fall 2003 22

Java’s License5.  LIMITATION OF LIABILITY.  TO THE EXTENT

NOT PROHIBITED BY LAW, IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED TO THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.  …

2 September 2003 CS 201J Fall 2003 23

Java’s License

2.  RESTRICTIONS.  … Unless enforcement is prohibited by applicable law, you may not modify, decompile, or reverse engineer Software.  You acknowledge that Software is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility.  Sun disclaims any express or implied warranty of fitness for such uses. 

2 September 2003 CS 201J Fall 2003 24

Software Validation

• Process designed to increase our confidence that a program works as intended

• For complex programs, cannot often make guarantees

• This is why typical software licenses don’t make any claims about their program working

2 September 2003 CS 201J Fall 2003 25

Increasing Confidence• Testing

– Run the program on set of inputs and check the results

• Verification– Argue formally or informally that the program

always works as intended

• Analysis– Poor programmer’s verification: examine the

source code to increase confidence that it works as intended

2 September 2003 CS 201J Fall 2003 26

Testing

• If all the test cases produce the correct results, you know that a particular execution of the program on each of the test cases produced the correct result

• Concluding that this means the program is correct is like concluding there are no fish in the river because you didn’t catch one!

2 September 2003 CS 201J Fall 2003 27

Exhaustive Testing

• Test all possible inputs• PS1: 50x50 grid, all cells can be either dead or alive

before starting

22500 = 375828023454801203683362418972386504867736551759258677056523839782231681498337708535732725752658844333702457749526057760309227891351617765651907310968780236464694043316236562146724416478591131832593729111221580180531749232777515579969899075142213969117994877343802049421624954402214529390781647563339535024772584901607666862982567918622849636160208877365834950163790188523026247440507390382032188892386109905869706753143243921198482212075444022433366554786856559389689585638126582377224037721702239991441466026185752651502936472280911018500320375496336749951569521541850441747925844066295279671872605285792552660130702047998218334749356321677469529682551765858267502715894007887727250070780350262952377214028842297486263597879792176338220932619489509376

But that’s not all: all possible start stop step interactions, different platforms, how long to you need to run it, etc.

2 September 2003 CS 201J Fall 2003 28

Selective Testing

• We can’t test everything, pick test cases with high probability of finding flaws

• Black-Box Testing: design tests looking only at specification

• Glass-Box Testing: design tests looking at code– Path-complete: at least one test to exercise

each path through code

2 September 2003 CS 201J Fall 2003 29

Black-Box Testing

Test all paths through the specification:1. currently dead, three live neighbors

2. currently alive, two live neighbors

3. currently alive, three live neighbors

4. currently dead, < 3 live neighbors

5. currently dead, > 3 live neighbors

6. currently alive, < 2 live neighbors

7. currently alive, > 3 live neighbors

public CellState getNextState () // MODIFIES: this // EFFECTS: Returns the next state for this cell. If a cell is currently // dead cell and has three live neighbors, then it becomes a live cell. // If a cell is currently alive and has two or three live neighbors it // remains alive. Otherwise, the cell dies.

2 September 2003 CS 201J Fall 2003 30

Black-Box Testing

Test all paths through the specification (7 tests)

Test boundary conditions1. all neighbors are dead

2. all neighbors are alive

3. cell is at a corner of the grid

4. cell is at an edge of the grid

public CellState getNextState () // MODIFIES: this // EFFECTS: Returns the next state for this cell. If a cell is currently // dead cell and has three live neighbors, then it becomes a live cell. // If a cell is currently alive and has two or three live neighbors it // remains alive. Otherwise, the cell dies.

2 September 2003 CS 201J Fall 2003 31

Glass-Box Testing public CellState getNextState () // MODIFIES: this // EFFECTS: Returns the next state for this cell. If a cell is currently // dead cell and has three live neighbors, then it becomes a live cell. // If a cell is currently alive and has two or three live neighbors it // remains alive. Otherwise, the cell dies. { if (countAliveNeighbors () == 3) { return CellState.createAlive (); } else if (getState ().isAlive () && countAliveNeighbors () == 2) { return CellState.createAlive (); } else { return CellState.createDead (); } }

Test all paths through the code (4)

2 September 2003 CS 201J Fall 2003 32

Path-Complete Testing

• Insufficient– Often, bugs are missing paths

• Impossible– Most programs have essentially infinite

number of paths– Loops and recursion

• Test with zero, one and several iterations

2 September 2003 CS 201J Fall 2003 33

Testing Recap• Testing can find problems, not to prove

your program works– Since exhaustive testing is impossible, select

test cases with maximum probability of finding bugs

– A successful test case is one that reveals a bug in your program!

• Typically at least 40% of cost of software project is testing, often ~80% of cost for safety-critical software

2 September 2003 CS 201J Fall 2003 34

Charge• Increase confidence a program works by:

– Testing: sample possible executions, trying to find ones that don’t work

– Analysis: check properties about all possible executions by examining code

• PS2: a lot longer and harder than PS1