1. David Evans http://www.cs.virginia.edu/~evans CS201j: Engineering Software? University of Virginia Computer Science Lecture 2: Java Semantics, Validation

2. 2 September 2003CS 201J Fall 20032 Menu Objects in Java: Heap and Stack Validation: Testing and Analysis

3. 2 September 2003CS 201J Fall 20033 Java Semantics

4. 2 September 2003CS 201J Fall 20034 The Stack and Heap String s = new String (“hello”); s “hello” java.lang.String Objects live on the Heap new creates an Object on the Heap Local variables live on the Stack Point to objects on the Heap String is a type in the Java API for representing sequences of characters

5. 2 September 2003CS 201J Fall 20035 String s = new String (“hello”); s “hello” java.lang.String String t = s; t

6. 2 September 2003CS 201J Fall 20036 String s = new String (“hello”); s “hello” java.lang.String String t = s; t s = new String (“goodbye”); “goodbye” java.lang.String

7. 2 September 2003CS 201J Fall 20037 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

8. 2 September 2003CS 201J Fall 20038 String s = new String (“hello”); s “hello” java.lang.String String t = s; t int i = 201; i 201 int j = i; j 201 How can we see the difference between primitive types and objects?

9. 2 September 2003CS 201J Fall 20039 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

10. 2 September 2003CS 201J Fall 200310 “hi” “high” Mutability If an object is mutated, all references to the object see the new value sb java.lang.StringBuffer tb StringBuffer sb = new (“hi”); StringBuffer tb = sb; tb.append (“gh”);

11. 2 September 2003CS 201J Fall 200311 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

12. 2 September 2003CS 201J Fall 200312 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"); 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) }

13. 2 September 2003CS 201J Fall 200313 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!"); } } s “hello” java.lang.String t sb tb “hello” java.lang.String “he” java.lang.StringBuffer s1 t1 “hello” java.lang.String 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. 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

14. 2 September 2003CS 201J Fall 200314 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!"); } } s “hello” java.lang.String t sb tb “hello” java.lang.String “he” java.lang.StringBuffer s1 t1 “hello” java.lang.String “hello”

15. 2 September 2003CS 201J Fall 200315 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!"); } } s “hello” java.lang.String t sb tb “hello” java.lang.String “he” java.lang.StringBuffer s1 t1 “hello” java.lang.String “hello goodbye!”

16. 2 September 2003CS 201J Fall 200316 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!"); } } s “hello” java.lang.String t sb tb “hello” java.lang.String “he” java.lang.StringBuffer s1 t1 “hello” java.lang.String “hello goodbye!” java.lang.String

17. 2 September 2003CS 201J Fall 200317 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!” java.lang.String “hello goodbye!” java.lang.String

18. 2 September 2003CS 201J Fall 200318 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!” java.lang.String “hello goodbye!” java.lang.String After test returns?

19. 2 September 2003CS 201J Fall 200319 Validation

20. 2 September 2003CS 201J Fall 200320 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?

21. 2 September 2003CS 201J Fall 200321 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 THE END OF THIS AGREEMENT.

22. 2 September 2003CS 201J Fall 200322 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. …

23. 2 September 2003CS 201J Fall 200323 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.

24. 2 September 2003CS 201J Fall 200324 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

25. 2 September 2003CS 201J Fall 200325 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

26. 2 September 2003CS 201J Fall 200326 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!

27. 2 September 2003CS 201J Fall 200327 Exhaustive Testing Test all possible inputs PS1: 50x50 grid, all cells can be either dead or alive before starting 2 2500 = 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.

28. 2 September 2003CS 201J Fall 200328 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. 2 September 2003CS 201J Fall 200329 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.

30. 2 September 2003CS 201J Fall 200330 Black-Box Testing Test all paths through the specification (7 tests) Test boundary conditions 1.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.

31. 2 September 2003CS 201J Fall 200331 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)

32. 2 September 2003CS 201J Fall 200332 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

33. 2 September 2003CS 201J Fall 200333 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

34. 2 September 2003CS 201J Fall 200334 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