Some General Things to Consider

I normally do not set exams that have a 90/80/70/60 grading scale. I'm just not that good at knowing in advance exactly how an A student will perform on a test so that I could set an exam with a firm 90 cutoff for an A, for example. My exams are usually longer than most students can do, the average is usually more like a 75 or so, and I always grade on the curve. In a class like this, there are enough students that we should get a reasonable bell-shaped curve about the mean.

Now, although my exams tend to run long, I like to set an exam for which I think about 50-60% of the exam is pretty routine, with many questions individually having smaller point values. Then I will have a few questions (perhaps 20-30%) that will separate the A and B students from the C and below students. Finally, there will be one or two questions that only the very best students will get right.

SO: knowing that the exam will be set up this way, don't come into the exam and plan to answer questions in numerical order. You should first answer the questions of which you are confident of the answers, and try to pile up the points that way. Do first the part you find easy, and then go on to what you feel is the next hardest question. If necessary, go through the test from start to finish more than once.

It is never my intent to have "trick" questions except possibly for the most difficult question on the exam. If it looks to you like a trick question, then it's probably a mistake on my part. Ask about it!

Topics

You should know your basic jargon terms. These can be found in the glossary of the book.

accessor method, algorithm, AND, argument, attribute, avenue, block, body, boolean expression, bug, class, class diagram, command, comment, comparison operator, compile, compiler, compile-time error, constructor, debug, declaration statement, documentation comment, else clause, evaluate, expression, file, flow of control, flowchart, hang, helper method, identifier, implicit parameter, infinite loop, inherit, initial value, instance, intent error, invoke, javadoc comment, keyword, local variable, logic error, loop, method, method resolution, multi-line comment, nest, object diagram, OR, overload, override, parameter variable, program, pseudocode, query, reserved word, return, return type, run time error, scope, self documenting code, service, side effect, signature, single line comment, source code, spaghetti code, statement, stepwise refinement, street, structured programming, stub, subclass, superclass, syntax, semantics, tag, temporary variable, then, thread, value, variable, variable declaration.

You should be able to write, with perfect syntax, simple examples of any of the basic language constructs of Java that we have covered so far. These include if, then, for, while, constructs, simple constructors, etc.

You should be able to state in a sentence or two what is meant by the invocation of specific things in Java. For example, given the program chunk

public class Harvester extends RobotSE
{
  public Harvester(City aCity, int str, int ave, Direction dir)
  {
    super(aCity, str, ave, dir);
  }
}

you should be able to explain what is the function of the super() line.

(While we're on that subject, notice that with this kind of example, you don't need to remember whether it's street then avenue or the other way around. Trust me; I'm not going to ask you a trick question. And if you need to remember, and you're not sure, then just indicate on the exam that you aren't sure which way around the parameters get called. That's in the documentation, and part of the test will include being able to read standard documentation.)

You should expect to be given a piece of standard javadoc documentation and explain what you should get from reading one piece of it.

You should expect to be able to write down a control structure to make a robot do a specific task. This will involve knowing about initial states, the steady state in the execution of a program, and the clean up afterwards to produce a good final state. You can expect a couple of questions to be reasonably routine, and you should expect one such question to require a little more thinking.

You should expect to be given a piece of standard javadoc documentation and explain what you should get from reading one piece of it.

You should expect to be given a piece of standard javadoc documentation and explain what you should get from reading one piece of it.