Peter Andreae Computer Science Victoria University of Wellington Copyright: Peter Andreae, Victoria University of Wellington Design, Debugging & Introduction to GUIs COMP 102 #

© Peter Andreae COMP102 17:2 Menu Modularity and Design Class Diagrams Two techniques for Debugging Nicer interaction with User: GUI’s and Event-driven input

© Peter Andreae COMP102 17:3 Breaking tasks into modules The central problem in programming is handling complexity The central techniques to handle complexity are: Modularity: Breaking problems into smaller parts that can be solved separately. ⇒ methods: a separate method for each subtask ⇒ classes: a separate class for each component of the program Questions: how big is a module? Abstraction: Hiding the details of a module, so that other parts of the program only need to know a little bit about it: eg: name, parameters, return type constructor and possible actions Questions: what should you show? what should you hide?

© Peter Andreae COMP102 17:4 Designing Methods Work out a subtask that “belongs together” Give it a name ⇒ method name Work out what information it will need ⇒ parameters: types and internal descriptive names Work out what type of value it will give back ⇒ return type Write comments describing what it accomplishes Write the body Making local variables for temporary information accessing fields for “permanent” information making up new methods for any sub-subtasks.

© Peter Andreae COMP102 17:5 Choosing the “right” subtasks There is no fixed formula!!! “Good program design” involves choosing a good way of breaking down subtasks. Good method design ⇒ simpler to understand ⇒ less duplication ⇒ easier to write the rest of the program using the methods

© Peter Andreae COMP102 17:6 Designing Classes Interesting programs require multiple classes How do you break a program into classes? CartoonStory CartoonFigure BouncingBall (Assig 5) Garden Flower BounceSimulator

© Peter Andreae COMP102 17:7 Choosing Classes No fixed Formula! It is a matter of good design. Separate the user interface from the rest of the program. One class to set up the interface and handle the interaction (typically only one object of this class is created) Other classes to store and manipulate the information (typically multiple objects of these classes are created) Have a separate class for each type of information One class for MovingShape; one class for Butterfly Separate class for the Flower. Textbook Ch 5.1 (old book: 6.2) talks about an approach for identifying potential classes for a problem.

© Peter Andreae COMP102 17:8 Class Diagrams and BlueJ Understanding a program with lots of classes can be difficult! Class diagrams can help: Box for each class Arrows to show that one class uses / refers to another class. (plus other kinds of arrows …) BlueJ automatically draws class diagrams for you (though it sometimes misses out some arrows ) UML class diagrams also show: [ LDC: 5.2 ] fields of a class:the kind of information in each object of the class methods of a class:the actions that can be performed on objects of the class

© Peter Andreae COMP102 17:9 Designing Algorithms How do you write out the design for a method? eg, dailyLists Informal English or Java comments Flow Diagrams

© Peter Andreae COMP102 17:10 Algorithms: dailyLists For each day (1 to 30) Print a header for the day initialise total, courseCount…. for each line of the data file read code, room, day, count, names if the day is the one we are working on, then If it is the code is a new course and its not the first one, then print out the count of the previous course reset the count of the current course to 0 add the count to the total add the count to the count of the current course print out the count of the last course of current day print out the total count

© Peter Andreae COMP102 17:11 Algorithms: dailyLists "Flow Chart" Not useful for tricky algorithms currentday = 1 currentday>30? print header for day file done? read newcode, room, day,count, etc day == currentday? newcode == code add count to total add count to coursetotal set code to newcode code != "" print code and coursetotal coursetotal = 0 increment currentday ++

© Peter Andreae COMP102 17:12 Debugging Techniques Print statements: record progress and state through program public void draw(double left, double top){ Trace.printf("Debug: enter House.draw(%d, %d)\n", left, top); UI.drawRect(left, top, size, size); UI.drawLine(left, top, left+size/2, top-size/2); UI.drawLine(left+size, top, left+size/2, top-size/2); this.drawWindow(left+size/8, top+size*3/8, size/4 ); this.drawWindow(left+size*5/8, top+size*3/8, size/4 ); Trace.printf("Debug: exit House.draw\n"); } public void drawWindow(double left, double top, double sz){ Trace.printf("Debug: enter House.drawWindow(%d, %d, %d)\n", left, top, sz); UI.drawRect(left, top, sz, sz); UI.drawLine(left, top+sz/2, left+sz, top+sz/2); UI.drawLine(left+sz/2, top, left+sz/2, top+sz); Trace.printf("Debug: exit House.drawWindow\n"); }

© Peter Andreae COMP102 17:13 Debugging Techniques Print statements: record progress and state through program public void printCourse(){ Trace.println("Debug: entering printCourse"); String targetCode = UI.AskString("Enter course code: ").toUpperCase(); UI.printf("Exam room data for %s:\n", targetCode); try{ Scanner fileScan = new Scanner(new File("examdata.txt")); while (fileScan.hasNext()){ String code = fileScan.next(); String restOfLine = fileScan.nextLine(); Trace.printf("Debug: comparing %s to %s\n", code, targetCode); if (code.equals(targetCode)) { UI.println(code+"\t"+restOfLine); } fileScan.close(); }catch (IOException e){UI.println("File reading failed: "+e);} Trace.println("Debug: exiting printCourse"); }

© Peter Andreae COMP102 17:14 Debugging: Use BlueJ debugger Lets you step through your code. Compile your code place stop signs in left margin run program In debugger window Step ⇒ perform the next statement Step Into ⇒ step inside the method calls in the next statement Continue ⇒ run until you hit another stop sign Terminate ⇒ stop your program You can double click on local variables to look inside them. Watch the Tutorial video on this.

© Peter Andreae COMP102 17:15 Nicer User Interaction Designing good User Interfaces is an art! Text based interaction has strengths and limitations; eg + very flexible + good for expert users – slow for new/infrequent users and slow typists. – have to know the options and possiblities – hard to deal with graphical elements – error/typo prone Graphical User Interfaces have strengths and limitations: – limitations on options – only what is shown on screen – slow for expert users (unless very well designed) + good for new/infrequent users + options are explicit and obvious + excellent for graphical elements – more complicated to construct Each kind is appropriate for different tasks

© Peter Andreae COMP102 17:16 GUI’s and Event driven input In a GUI, the interaction is controlled by the user, not by the program User initiates "events" Program responds

© Peter Andreae COMP102 17:17 PuppetMaster How does Java respond to buttons etc? Smile Frown Left Right Talk Distance

© Peter Andreae COMP102 17:18 Event Driven Input Smile Frown The JVM (Java Virtual Machine) = the "clerk" Listeners: listening to Smile button: PuppetMaster-3 listening to Frown button: PuppetMaster-3 : listening to Distance slider: PuppetMaster-3 listening to Talk textField: PuppetMaster-3 PuppetMaster-3 When user clicks button: JVM notices the event, tells PuppetMaster-3 buttonPerformed("smile") watching PuppetMaster Constructor: - sets up buttons and records "Listeners" - makes figure - then stops Talk Distance Move

© Peter Andreae COMP102 17:19 GUI’s with buttons Setting up the GUI: Add buttons, slider, and textfield to the UI ⇒ specify which object is going to respond to them. Setting up the “responding object”: declare that it is a kind of object that can respond to buttons define a “buttonPerformed” method that specifies how to respond. declare that it is a kind of object that can respond to sliders define a “sliderPerformed” method that specifies how to respond. declare that it is a kind of object that can respond to textFields define a “textFieldPerformed” method that specifies how to respond.