This next lab will spread over two days. Be sure to e-mail the code to your partner at the end of the first day. That way you both have copies of what you've accomplished so far. Be sure to come to lab on both days even if you finish early as I may make some changes or additions. The goal for the labs on 2/13 and 2/15 is to learn about private variables and public mirror functions. We'll also write some convenience functions. Finally we'll add yet another routine to each of Conversation and Ruler. Seems the boss wants us to report some statistics.

1. Same partners, switch roles.

2. Start with the Conversation system as you had it last time.

3. If you haven't already done so, take the printing of numRulers out of MainConversation. It was just there to illustrate public variables. Keep the variable numRulers in Conversation as we'll use it later, but make it private. In fact, make all variables in both Conversation and Ruler private.

4. As always use javac *.java to compile. Always use java MainConversation to run.

5. In Ruler, add in public mirror functions for the name, title, people, and country variables.

6. Add in public convenience functions: Start with getIdentity(), which combines the title and name. Use it at least once in your code.

7.  Add in two more public convenience functions: getIdentityWithCountry(), which combines title, name and country; and getIdentityWithPeople(), which combines title, name, and people. Use at least one of these with otherRuler in your sayHelloTo() routine.

8. The boss says we need a way to print out statistics for each ruler. There will be more statistics to come, but the boss first wants to see how many conversations each ruler has started.

9. Add a report() routine to Ruler and a reportRulers() routine to Conversation. The reportRulers routine will tell each Ruler to report its stats. For the moment just have the Rulers say who they are (use one of our three convenience functions to do this, you pick which one) when report() is called.

10. Introduce a new variable, numConversations, into Ruler. This variable should represent the number of conversations that a Ruler has started. Note that numConversations is fundamentally different from name, title and the others. We need the Conversation class to tell us what our name and title will be. We don't need Conversation to tell us anything about numConversations. The Ruler class can handle this all by itself.

11. As is often the case with variables you need to declare numConversations, initialize it, update it, and output it. Each of these will be done in a different place in the Ruler code. Figure out where and implement.

12. You should be about here by the end of the first day. Maybe a little further, maybe not quite this far, but right around here. Wherever you are, e-mail your code to your partner!

13.  At this point the output from report() should look something like: I'm President Lincoln from America and I've started 2 conversations. Unfortunately it might just as likely say: I'm Queen Cleopatra from Egypt and I've started 1 conversations.

14. Talk to your partner about how we might avoid that last grammatical error. Then implement the plan.

15. Once the above is working, add code so that as many as three different messages come out.

    1. For 0 conversations, something like: I'm the lonely Queen Cleopatra and I need someone to talk to.

    2. For 1 conversation, something like: I'm President Abraham Lincoln and I've started just one conversation.

    3. For 2 or more conversations, something like: I'm Saint Joan of Arc and I've started 72 conversations. Of course it won't really be 72; it'll be however many conversations Joan actually started.

16. Change the code in Conversation so that at least one Ruler doesn't talk at all, at least one talks just once, and at least one talks two or more times. This will test that all your code in Ruler is actually working.
17. Finally, the boss wants to see to whom everybody spoke most recently. Specifically, he wants to see additional output in cases (b) and (c) above. For (b) something like: I'm President Abraham Lincoln. I've started just one conversation and that was with Saint Joan of Arc. For (c) something like: I'm King Hammurabi. I've started 28 conversations, the last with President Abraham Lincoln.
18. Talk to your partner and make a plan. Note that you will not need any new routines to implement this requirement. Nor will you need to make any change at all to Conversation.java. In fact, except for adding the reportRulers routine we've made no changes to Conversation.java this whole week. This is a sign that the structure we have in place is pretty well designed.
19. You will need a new variable, so think about what type of variable it should be, where it will be declared, where it will be given a value, and where it will be output. That last one should be obvious, I hope.
20. Implement the new functionality. Test it.

21. E-mail Conversation and Ruler to your partner and to me.

The goal for the lab on 2/8 is to further understand how classes and routines communicate with each other. We'll also give our Rulers a people to, well, rule.

1. Same partners, switch roles.

2. Start with the Conversation system as you had it last time. Fix any problems with that version. For example a few teams didn't have an identifyRulers() routine in Conversation. Others didn't have good spacing in their output.

3. When you give a ruler its name, title, and country, these strings should not contain any leading or trailing spaces. Or any extraneous words like "of". If you have anything like that, take it out. If you now need to fix the output of identify(), do so.

4. Always compile using javac *.java. Always run using java MainConversation.

5. Give each Ruler a people. Abe's people are Americans, Joan's are French, Cleo's are Egyptians, and so on. To do this, look at how we're currently giving each Ruler a name, title, and country, and do likewise. Print the people in identify() as in Hello world, I am Abraham Lincoln, President of the glorious Americans! You don't need to use that exact phrasing, but the message should include the name, title, and people of the Ruler. Don't lose the country variable, we'll use it later.

6. Make the variables name, title, country, and people in Ruler public for today. You'll see why in a bit.

7. Add a routine called sayHelloTo() to Ruler. As discussed in class this routine should take a String parameter for the moment. This is similar to what the Ruler() constructor does, but call this one otherName.

8. Invoke this new routine from Conversation. The call will look something like lincoln.sayHelloTo("Joan"). In this case the program should print something like: Hey Joan this is Abraham Lincoln.

9. Similarly if you call this with joan.sayHelloTo("George"), the program should print: Hey George this is Joan of Arc. Note that we could send any string as a parameter: joan.sayHelloTo("Once upon a time") will compile and run.

10. Add a converse routine to the Conversation class. This is where all the calls to sayHelloTo should go. Make sure that each of your rulers is involved in the talking.

11. As discussed in class, change the sayHelloTo() routine so that it accepts a Ruler object as a parameter instead of a String. My parameter is now called otherRuler. We still want the output to be the same. You'll have to think a little about how to get the other ruler's name to come out.

12. Once you've got that, change the sayHelloTo() routine to include title and country of both rulers, as in Hello, Saint Joan of Arc from France. This is President Abraham Lincoln and I bring greetings from America.

13. E-mail Conversation.java, and Ruler.java to me (and your partner)

The goal for the lab on 2/6 is to understand how different classes work together to make up a system at compile time and then to see how the objects spawned from these classes make up a system at runtime. We'll also get more practice with routines and see how to send information from one routine (and one class) to another.

• New partners, see above. Outside of class, please update and send in your partner evaluations.

• Start with MainConversation, Conversation, and Ruler all together in one directory, probably named conversation. Both partners should probably download these three classes, then have one person drive. If you haven't been the driver for a while, it's time.

• Compile the system. Type javac *.java. This will compile all three classes in your new system.

• Remember you only have to type that once. Then use the arrow keys to apply it again when you make changes to the code.

• Always run it using java MainConversation. Do that now and note the output statements and where they're coming from in the code.

• Add a public variable, numRulers, to the Conversation class as we did in lecture. Usually variables should be private, but do it this way for today. Print this variable from the MainConversation class. Compile and run.

• Add a new ruler of your choosing to the Conversation class. Compile and run.

• You should see the message from Ruler coming out twice. This is because two Ruler objects have now been created.

• Change the Ruler class so that the name of the Ruler is printed out along with the message. To do this, think about how the name is communicated from Conversation to Ruler.

• Compile and run. Note that the changes you made to Ruler show up.

• Add a name variable to Ruler. This variable will be used in multiple routines and so should be declared at the top of the class. Use it to save the name of the Ruler passed in from Conversation. The name variable is of type String. A string is any sequence of letters, punctuation, digits and other characters. So your declaration should look something like private String name; Again, variables should usually be private, the one case above was an exception.

• Add an identify() routine to Ruler. Have it print a nice message, not just "creating so and so", that includes the Ruler's name. Call this routine from Conversation so that each ruler identifies itself. Remember the dot notation: lincoln.identify();

• Get rid of all extraneous prints so that the only things that come out are the two Rulers identifying themselves and then the number of rulers.

• Modify Conversation so that it is broken into routines as well. In particular, write createRulers() and identifyRulers() routines. Call these routines from the Conversation() constructor. Have each one do the obvious thing. E.g. identifyRulers() should contain the code that tells each ruler to identify itself.

• Give your rulers a bit more personality in the form of a title and a country. Do this by sending three strings from Conversation to Ruler. E.g lincoln = new Ruler( "President", "Abraham Lincoln", "America" ); You'll also have to receive these in Ruler. E.g. public Ruler( String ttl, String nme, String cntry). Then save them, as you're already doing with name, and use all three when the Ruler identifies itself.

• At this point Lincoln should be saying something like: Hello, I'm President Abraham Lincoln of America. And your other Ruler should be saying something similar but with its own data.

• Add at least two more leaders. Have them initialize and identify themselves.

• E-mail your partner and me all three files: MainConversation.java, Conversation.java, and Ruler.java

One more time on GradingSystem. The goal this time (2/1) is to revamp the code to use routines. Once we have these we'll see that variables that are used in more than one routine need to be declared outside of any routine, traditionally at the top of the class. So we'll do that too. We'll learn about the visibility of routines and variables from outside the class we're working in. And we'll learn more about if statements.

• Same partners, switch roles.

• Start with the code as you had it last time.

• As in class replace the three if statements with one structure. That one structure will have three parts: if, else if, and else.

• As in class, add a computeGPA() routine. This will necessitate moving some variables out of the GradingSystem() constructor routine. Some of these, like gpa, should be declared outside of any routine, as they will be used in more than one place. All such variables should be declared as private to prevent accidental (or nefarious) corruption from outside. Other variables, like adjustment, will still only be used in one routine, so declare them there. These are automatically only available from the routines they're in.

•  For now we'll make all routines public.

• Add a routine, updateCounters(), that checks the computed gpa and increments the appropriate counter. Call it from GradingSystem(). Note you may have to adjust the variable declarations again.

• Add a routine named output, and put all the print statements in it.

• Note how easily the GradingSystem() code reads now. It has effectively become the manager and it farms out details to the routines it calls. In addition to being easier to follow, it will be easier to make changes now.

• What we've done so far is to look at students with the lowest possible grades (all B's) that would keep their scholarships under the straight system, and then we ran an experiment to see how many would lose them under the +/- system. You can make an argument that these are the students most likely to be hurt by the change. To be fair in our analysis, we need to think about the reverse. Which students are most likely to be helped under the +/- system? That is, which students would lose their scholarship under the straight system, but would stand the best chance of keeping them under the +/- system? Work with your partner to design an experiment that would simulate large numbers of such students. We will still assume students are taking 10 courses, each worth three credits, so again the real question is what grades should we assume they get in those courses? Your answer should be in the form of 10 straight letter grades. Write down your answer in your e-mail message. Don't change your code, just answer the question.

• What changes would you have to make in your code if we wanted to simulate the folks discussed above? Don't actually make the changes, just write down what the changes would be in the same e-mail message.

• Attach your code, and send it to your partner and to me.

OK, it's 1/30 and we're making good progress on GradingSystem.

• Same partners, switch roles.

• Start with the version of the system you had last time.

• As discussed in class, put in variables for numCourses and numStudents. Set the first one to 10 and the second to 15. Add a print statement that outputs numStudents in an appropriate sentence. E.g. We simulated 15 students to see the effect of the change in the grading system. Compile and test. Always compile and test.

• Set numStudents to 1000. Take out the statements that print the GPAs as we don't need them anymore (and we really don't want to see 1000 lines printed out!). At this point, nothing but the message above should be printed.

• As discussed in class we'll need three new variables. You can choose your own names if you wish, but mine are numAbove, numBelow, and numAt. These represent the numbers of students whose GPAs are above, below, or at 3.0.

• Work with numAbove first as we did in class. Declare and initialize it, use it inside an if statement and then print both the number and percentage of students whose GPAs go up. E.g. We found that 412 or 41.2% of GPAs came out above 3.0.

• As you know converting to a percentage involves dividing and then multiplying by 100. So you'd expect something like numAbove /numStudents * 100 to work. You should try this but to your chagrin you'll always get 0%! The problem is that numAbove and numStudents are whole number variables and the computer divides whole numbers the way you did in fourth grade. It doesn't get a decimal answer, it gets a quotient and a remainder. Because numAbove is smaller than numStudents, the quotient is always 0. The easiest way to fix it in this case is to multiply by 100.0 first and then divide: numAbove * 100.0/numStudents. Adding the decimal point and changing the order ensures that Java knows we want decimal arithmetic all the way through.

• Once that's working, do the same for the other two variables.

• Change numStudents to 1000000. Write down the number whose grades are now below 3.0 and include it in your e-mail message.

• Attach the code for GradingSystem.java, and send it along to your partner and to me.

Lab on 1/25. The eventual goal for the GradingSystem project is to simulate a large number of students who had all B's in the old system and see what likely happened to them when the system changed. We'd expect some percentage of student gpas to go up, an equal percentage to go down, and a somewhat smaller percentage to stay at 3.0. The question is, what exactly are these percentages? We'll take another step towards that goal today and learn some more about coding and design as we go.

• Please download (save first, then open) and fill out the first few lines of the partner form and then e-mail it to me. We'll do this every time we change partners. Don't delete the old form, we'll update it each time. Note that the only requirement is that you fill out the form. You get a point each time you submit the form when asked, but the information you provide will not affect either your or your partner's grade. If a person receives low ratings from more than one partner, I will likely have a chat with that person to see if there's something I can do to improve the situation, but that's the extent that they'll be used.

• New partners, see above. Decide on roles.

• Download MainGradingSystem.java and the new GradingSystem.java into a new directory. Compile and run.

• To compile use javac *.java and to run use java MainGradingSystem. That first bit actually compiles all the .java files in your directory. Since from now on we'll have systems with multiple .java files this is the easiest way to be sure all your changes get compiled.

• You always run the "main" object, which is why java MainGradingSystem works in this case.

• For today all changes will be to GradingSystem.java.

• Make the changes discussed in class so that we are simulating 15 students each taking 10 courses as in the previous lab, but without all the copying and pasting you had to do before. Compile and test.

• We don't need to see the individual grades any more so take out that print statement. We do still want to see each student's gpa though, so keep printing it. Compile and test.

•  Modify the code so that the output looks something like this

  			
  			GPA for student #1: 3.1111111
  			GPA for student #2: 2.7333333
  			and so on through all 15 students.

•  That last one will require some thought. I recommend you start by printing student #1 all 15 times (compile and test). Then talk to your partner about how to make the number you print change every time. Hint: You already have a variable in your code that's counting the students. Use it.

• E-mail the code to your partner and to me.

The goal for the lab on 1/23 is to begin an experiment regarding the uses of plusses and minuses in the grading system at Winthrop and the effect on students' Life scholarships. We'll do this by looking at what might happen to a student who gets a B under the straight (no plusses or minuses) system in all of her first 10 courses at Winthrop. Note that because we're still very much beginning programmers our simulation will necessarily be overly simplified as that restriction shows. We'll assume that each course counts 3 credits, so we're effectively looking at the student's first 30 credits. This also means that computing the GPA is just a matter of averaging the course grades. The current system adds +'s and -'s to grades so that if a teacher uses the +/- system our B student might get any of 3 grades (B+, B, or B-) in any one course. We'll assume each of these is equally likely. In the current system a B+ counts 3.33, a B counts 3.0, and a B- counts 2.67. So in theory a student who used to get all B's in all 10 courses (and hence a 3.0 average) could now average anywhere from 2.67 to 3.33. Proponents argued that the additional accuracy is important and that over time students will be helped as much as they're hurt. Opponents were (still are) concerned that students who are hurt initially may lose their Life Scholarships (cutoff is 3.0 on 30 credits) and may have to drop out of school. These students won't be around to benefit from the "over time" argument. The goal of our (admittedly oversimplified) simulation is to try to get a handle on the proportion of students affected by the +/- system.

• Same partners, switch roles.

• Download GradingSystem.java and save it in a new directory. Remember to save first then open.

• Compile and run the program as usual. Note that it is just computing the GPA of two courses.

• Add documentation to the existing code. At the top, add in some discussion of the simplifying assumptions we're making. Don't just copy what's above; put it in your own words.

• In addition, add comments to the lines where the adjustment and grades are actually calculated.

• The documentation shouldn't just mirror the code. People can read the code. It should explain what the code is doing. For example, what are the possible outcomes for grade1?

• Compile and run to make sure you didn't inadvertently change any code.

• Add in one other course. This will be mostly copying and pasting, with some minor changes. Compile and test. Once you have a handle on those changes add in the rest of the courses for a total of 10. Compile and test.

• The code you have now represents one student. Add a loop, as we did in class for Geometry, so that the code that represents one student is repeated 15 times. Now we're simulating what happens to 15 students. Of course we'd really like to be able to handle 30 or 100 or 1000000, but we'll deal with that next time.

• How would the code have to change if a B+ counted as 3.25 and a B- counted as 2.75? Do not change the code you send me, in fact you don't have to change your code at all, just tell me what you would do in an e-mail message.

• Attach the code to that message and send it to me and your partner.

The goal for the lab on 1/18 is to understand how Random numbers can be generated in Java. As we will see random numbers are quite important for simulations.

• Same partners as last time. Decide who will drive and who will kibitz.

• We'll be adding to the Geometry program today, so bring that up for editing, compiling, running etc.

• Look at the code for RandomNumbers.java. You don't need to save this one, just study it. Well, actually, you might want to save it for future reference, but we won't be making any changes to it.

• Add code to Geometry.java so that numPolySides is set to a random integer between 3 and 30. Let's say numPolySides ends up as 17. Then your program should print something like: A randomly chosen polygon might have 17 sides. (Note: Most of you already have a variable with this name. If you don't, now's the time to add it.)

• Note: It's perfectly ok to copy code from RandomNumbers to your Geometry class and then modify it as needed. Also, be sure to copy the import line.

• Further note: You will have to modify whatever you copy! Think about how to make the ideas from the RandomNumbers class fit in the context of your Geometry class.

• The possible values should always be between 3 and 30. You'll need to think about how to make sure this actually happens.

• Because of the randomness you should get different results almost every time you run it. The second time you might get: A randomly chosen polygon might have 23 sides.

• Use the same ideas to print another message that tells how many sides a polygon that is not a triangle might have. Use an upper bound of 100 in this case.

• Attach Geometry.java to a message and e-mail it to me and your partner. Once again, I really want you to send one message to both so that I can see your partner gets it and so when I respond with a grade you both receive it. It'll cost you a point if you don't do this.

The goal for the lab on 1/11 is to get you reading some simple Java code and making minor changes.

• See partners above. Decide who will drive and who will kibitz.

• Only the drivers should log on. No surfing kibitzers allowed! Well, OK, the kibitzer can log on if you promise to visit only this web site, so it's easy to see what you need to do!

• Download Facts.java into a new subdirectory of csci151. Mine's called facts. Always save first and then open.

• As demonstrated in class, bring up a command tool, change directories as appropriate, compile and run Facts.

• Open with JEdit to edit the code. Add a numerical fact of your own choosing. Note that this should be a new fact, not a replacement of one that's already there.

• Compile and run the new version.

• Show me what you got.

• E-mail the revised Facts.java file to your partner. Your partner should always have a copy of what you accomplish during the lab. You don't need to e-mail this one to me provided it was approved in class.

• Switch roles.

• Download Geometry.java and save it in a new directory. Always save first and then open. If you do things the other way around the file will have the wrong name.

• Compile and run the program as usual.

• Look at the code, particularly noting the use of the variable numSides.

• Add code that uses a new variable numPolySides to print out a new geometrical fact.

• The driver should e-mail the new Geometry.java code to the kibitzer and to me.

• It's quite important that the driver e-mail the same message to both of us as that way I can verify that the kibitzer received it and you'll both get the grade when I reply.

The goal of the first lab, 1/9, is to make sure everyone can log onto the system, send e-mail, and work with Java files. A secondary goal is for me to collect some info about you. So....

• Please send me e-mail (mckimj@winthrop.edu) that includes your

• Name as you'd like me to address you.

• Major

• Computer Science experience. Could be none. Could be strictly as a user, e.g. games, word processing. Could be as a programmer, e.g. Java, Visual Basic, C++.

• Reason for taking the course

• Interests. Tell me something that will help me get to know you better. I'm especially interested in any extra curricular activities at Winthrop.

• Make a directory on your Z drive for all the work you do for this class. You can call it anything you want, but I recommend csci151. If you're not sure how to do this, start by double clicking on the Z drive icon on your desk top. If you're not sure what to do next, ask for help.

• Download Lincoln.java into a new subdirectory of your csci151 directory (mine's called lincoln) on your z drive. Note: Just save it at this point. If you open it first the system assigns a different name to it and you'll get all confused later. If you do this correctly you should see Lincoln.java as the only file in the lincoln directory. (You may just see the name Lincoln with a note beside it that it's a .java file. That's fine.)

• At the bottom left of the keyboard find the <windows> key. It's the one with the little flag on it. Press <windows><r>

• In the space provided type cmd. This will bring up a black "command shell"

• In the command shell change drives if necessary to get to your Z drive. Just type z: if you need to do this.

• Then change directories to get to your lincoln directory.

• E.g. something like cd csci151\lincoln should work. Or you could do this in two steps: cd csci151 and then cd lincoln. "cd" stands for "change directory". If you follow this with dir (for directory) you'll see the same files in the command shell as you saw graphically before.

• Type javac Lincoln.java to compile the code. Note that the upper case L matters. When you're dealing with Java, you have to be careful of upper and lower case.

• Think of Java as a language that's halfway between what a human can understand and what a computer can understand. With practice, humans can read and write Java code, thus creating what you will soon see in Lincoln.java. But the computer needs a little more help. So javac translates Lincoln.java into code the computer can understand (but humans can't). This code is stored in a new file called Lincoln.class. If you check the directory again at this point, you'll see the new file.

• Type java Lincoln to run the program.

• Find the icon for Lincoln.java, right click and select "open with JEdit" to edit the file. It may take a few seconds, but it will come up. Look it over for a bit. What does "System.out.println" do?

• Change the code so that it presents a quote by you (instead of Lincoln) and then change the quote.

• Compile and run your new program. Any time you make a change to a program you must save and recompile it (using javac) before you can run it (using java) and see the differences.

• Show me the results.

    The last few semesters the students in this course designed and built a small system that allowed world leaders to speak to each other. Unless inspiration strikes, we'll do something similar. I'll demo some student versions of this system in the next few days.

Lecture notes:

    I'll hand these out in class, but they'll always be here as well. Except for the first chapter I tend to use coding examples instead of powerpoint lectures. See below for some examples we'll likely cover.

    Chapter 1, Computer Systems

Java Listings. These are examples, mostly from the text. As we get into the appropriate chapters we'll use some of these in lab. You'll want to download others just for practice. Compile 'em, run 'em, and experiment on 'em.

    Chapter 1, Lincoln. java

    Chapter 2, Countdown. java

    Chapter 2, Facts. java

    Chapter 2, PianoKeys.java

    Chapter 2, Geometry.java

    Chapter 2, Echo.java

    Chapter 2, GasMileage.java

    Chapter 2, Roses.java

    Chapter 2, Snowman.java and Snowman.html (It may be easier to right click on this second one to save it properly)

    Chapter 3, RandomNumbers.java

    Chapter 3, Authority.java

    Chapter 3, NestedPanels.java

    Chapter 3, LabelDemo.java. For this one, you also need devil.gif. Again, right-clicking will allow you to save almost anything properly.

    Chapter 4, PushCounter.java and PushCounterPanel.java. These two make up a single system. Compiling PushCounter.java will force automatic compilation of PushCounterPanel.java. It'd be illuminating for you to put both these into an empty directory, compile the first one, and then notice how many files are created.

    Chapter 4, Splat.java, SplatPanel.java, and Circle.java. These three make up a single system. This is a really nice example of constructing multiple Circle objects from one Circle class.

    Chapter 5 (sort of), We need to distinguish between left and right button mouse events to implement Minesweeper, or just about any highly interactive graphics system. TwoButtonListener is a reusable class that will make this easy, and PushCounter and PushCounterPanel have been updated so that they now show how to use it. As usual, right click and save all these.

    Chapter 5, Splat.java, SplatPanel.java, and Circle.java. These are the updated versions reflecting work done on SplatPanel in class through 10/27. Illustrates if-else and switch statements.

    Chapter 5 with a touch of Chapter 7, Splat.java, SplatPanel.java, Circle.java, and AudioPlayer.java. These are the updated versions reflecting work done on SplatPanel in class through 11/1. Illustrates Arrays, For loops, and the use of sound.