Download Lecture 2 - University of Virginia, Department of Computer Science

Lecture 2:
Java Semantics,
Validation
CS201j: Engineering Software?
University of Virginia
David Evans
Computer Science
http://www.cs.virginia.edu/~evans
Menu
• Survey Results
• Objects in Java: Heap and Stack
• Validation: Testing and Analysis
29 August 2002
CS 201j Fall 2002
2
Survey Results
29 August 2002
CS 201j Fall 2002
3
Experience
•
•
•
•
Almost everyone: C++
Only 2 with a little Java experience
Scheme, PHP, Python, Basic, VHDL
Largest Program:
– 16: CS101/CS200 (few hundred lines)
– 5 people had experience with 1000+ line
programs
• Only 4 of you did any programming over
the summer!
29 August 2002
CS 201j Fall 2002
4
Other Answers
• On the course web site
• My answers also…
29 August 2002
CS 201j Fall 2002
5
Java Semantics
29 August 2002
CS 201j Fall 2002
6
The Stack and Heap
s
String s = new String
(“hello”);
java.lang.String
“hello”
String is a type in the Java
API for representing
sequences of characters
Objects live on the Heap
new creates an Object on the Heap
Local variables live on the Stack
Point to objects on the Heap
29 August 2002
CS 201j Fall 2002
7
String s = new String
(“hello”);
String t = s;
s
t
29 August 2002
java.lang.String
“hello”
CS 201j Fall 2002
8
String s = new String
(“hello”);
String t = s;
s
t
java.lang.String
“hello”
java.lang.String
“goodbye”
s = new String
(“goodbye”);
29 August 2002
CS 201j Fall 2002
9
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
29 August 2002
CS 201j Fall 2002
10
String s = new String
(“hello”);
s
java.lang.String
t
String t = s;
int i = 201;
int j = i;
“hello”
i
201
j
201
How can we see the difference between
primitive types and objects?
29 August 2002
CS 201j Fall 2002
11
Equality
x == y
Object Types: same objects
Primitive Types: same value
x.equals (y)
Object Types: method that compares
values of objects
Primitive Types: doesn’t exist
29 August 2002
CS 201j Fall 2002
12
Mutability
• If an object is mutated, all references to
the object see the new value
StringBuffer sb = new (“hi”);
StringBuffer tb = sb;
tb.append (“gh”);
sb
tb
29 August 2002
java.lang.StringBuffer
“high”
“hi”
CS 201j Fall 2002
13
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
29 August 2002
CS 201j Fall 2002
14
Java Semantics Question
public class Strings {
public static void test (String [] args) {
String s = new String ("hello");
String t = new String ("hello");
StringBuffer sb = new StringBuffer ("he");
s
StringBuffer tb = sb;
String s1 = "hello";
t
String t1 = "hello";
sb.append (“llo");
tb.append (" goodbye!");
s.concat (" goodbye!");
t = s.concat (" goodbye!");
java.lang.String
“hello”
java.lang.String
“hello”
sb
201
tb
201
// 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)
}
}
29 August 2002
CS 201j Fall 2002
15
Java Semantics Question
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!"); } }
String spec is not enough to
determine if s, t, s1 and t1 are
the same objects! This is what
Sun’s JDK 1.4 does. Other
implementations could correctly
do different things.
29 August 2002
java.lang.String
s
t
“hello”
java.lang.String
“hello”
sb
java.lang.StringBuffer
tb
“he”
s1
t1
CS 201j Fall 2002
java.lang.String
“hello”
16
Java Semantics Question
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!"); } }
java.lang.String
s
t
java.lang.String
“hello”
sb
java.lang.StringBuffer
tb
“hello”
“he”
s1
t1
29 August 2002
“hello”
CS 201j Fall 2002
java.lang.String
“hello”
17
Java Semantics Question
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!"); } }
java.lang.String
s
t
sb
tb
s1
t1
29 August 2002
CS 201j Fall 2002
“hello”
java.lang.String
“hello”
java.lang.StringBuffer
“hello
“he”
goodbye!”
java.lang.String
“hello”
18
Java Semantics Question
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!"); } }
java.lang.String
“hello
goodbye!”
29 August 2002
java.lang.String
s
t
sb
tb
s1
t1
CS 201j Fall 2002
“hello”
java.lang.String
“hello”
java.lang.StringBuffer
“hello
“he”
goodbye!”
java.lang.String
“hello”
19
java.lang.String
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!"); } }
java.lang.String
“hello
goodbye!”
29 August 2002
“hello
goodbye!”
java.lang.String
s
t
sb
tb
s1
t1
CS 201j Fall 2002
“hello”
java.lang.String
“hello”
java.lang.StringBuffer
“hello
“he”
goodbye!”
java.lang.String
“hello”
20
java.lang.String
After test returns?
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!"); } }
java.lang.String
“hello
goodbye!”
29 August 2002
“hello
goodbye!”
java.lang.String
s
t
sb
tb
s1
t1
CS 201j Fall 2002
“hello”
java.lang.String
“hello”
java.lang.StringBuffer
“hello
“he”
goodbye!”
java.lang.String
“hello”
21
Validation
29 August 2002
CS 201j Fall 2002
22
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?
29 August 2002
CS 201j Fall 2002
23
Java’s License
READ 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
29 August 2002
CS 201j Fall 2002
24
THE END OF THIS AGREEMENT.
Java’s License
5. 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. …
29 August 2002
CS 201j Fall 2002
25
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.
29 August 2002
CS 201j Fall 2002
26
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
29 August 2002
CS 201j Fall 2002
27
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
29 August 2002
CS 201j Fall 2002
28
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!
29 August 2002
CS 201j Fall 2002
29
Exhaustive Testing
• Test all possible inputs
• PS1: 50x50 grid, all cells can be either
dead or alive before starting
22500 =
37582802345480120368336241897238650486773655175925867705652383978223168149833770853573272575265884
43337024577495260577603092278913516177656519073109687802364646940433162365621467244164785911318325
93729111221580180531749232777515579969899075142213969117994877343802049421624954402214529390781647
56333953502477258490160766686298256791862284963616020887736583495016379018852302624744050739038203
21888923861099058697067531432439211984822120754440224333665547868565593896895856381265823772240377
21702239991441466026185752651502936472280911018500320375496336749951569521541850441747925844066295
27967187260528579255266013070204799821833474935632167746952968255176585826750271589400788772725007
0780350262952377214028842297486263597879792176338220932619489509376
But that’s not all: all possible start stop step interactions,
different platforms, how long to you need to run it, etc.
29 August 2002
CS 201j Fall 2002
30
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
29 August 2002
CS 201j Fall 2002
31
Black-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.
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 CS
live
neighbors
29 August 2002
201j Fall 2002
32
Black-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.
Test all paths through the specification (7 tests)
Test boundary conditions
1.
2.
3.
4.
all neighbors are dead
all neighbors are alive
cell is at a corner of the grid
cell is at an edge of the grid
29 August 2002
CS 201j Fall 2002
33
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)
29 August 2002
CS 201j Fall 2002
34
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)
29 August 2002
CS 201j Fall 2002
35
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
29 August 2002
CS 201j Fall 2002
36
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
29 August 2002
CS 201j Fall 2002
37
If we can’t test all possible paths
through a program, how can we
increase our confidence that it
works?
29 August 2002
CS 201j Fall 2002
38
Analysis
• Make claims about all possible paths by
examining the program code directly, not
executing it
• Use formal semantics of programming
language to know what things mean
• Use formal specifications of procedures to
know that they do
29 August 2002
CS 201j Fall 2002
39
Hopelessness of Analysis
• It is impossible to correctly determine if
any interesting property is true for an
arbitrary program!
The Halting Problem: it is
impossible to write a program
that determines if an arbitrary
program halts.
More on this later in the class…
29 August 2002
CS 201j Fall 2002
40
Compromises
• Accept unsoundness and incompleteness
• False positives: sometimes an analysis
tool will report warnings for a program,
when the program is actually okay
(unsoundness)
• False negatives: sometimes an analysis
tool will report no warnings for a program,
even when the program violates properties
it checks (incompleteness)
29 August 2002
CS 201j Fall 2002
41
ESC/Java
• Extended Static Checking for Java
• Analysis tool developed at
DEC/Compaq/HP Research Lab
• Is unsound and incomplete:
– Just because it finds no warnings, doesn’t
mean your code is correct
• PS2: use without adding annotations
• Later: use annotations to document
program assumptions
29 August 2002
CS 201j Fall 2002
42
CS201J Bug Bounty
• If you find a bug in the code we provide,
you get 10 bonus points.
• If you find a bug in the Java compiler or
API code, you get 50 bonus points.
• If you find a bug in ESC/Java or the
ESC/Java Specs, you get 5 bonus points.
29 August 2002
CS 201j Fall 2002
43
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
Remember to take pictures!
29 August 2002
CS 201j Fall 2002
44