COM1204 Summer 2003 Quiz #2 Review - Prof. Futrelle

To be given Thursday 14 August - Closed book/notes

Version of 5 August


This review covers both Java code and UML. The UML section in particular gives you most of what you'll need to know to answer the questions on the exam.

What to know for the Quiz - - Writing Java code

The focus of this quiz is on writing basic Java code correctly, as well as representing class and sequence structure clearly using UML. The example will not be difficult. Instead, the emphasis will be on correctness -- making sure you have the basics down cold. There will little or nothing asked or even discussed about Design Patterns. But this quiz will be in keeping with the course theme of Object-Oriented Design -- making sure that you can write code that creates and uses objects correctly.

I would strongly urge you to practice for the Quiz by writing various bits of Java code on paper. Then type your code into a machine and make sure it compiles and runs correctly. Keep at it until you can write simple code, including the various things described below, and do it with zero errors, or as close to zero as you can get.

The code you will have to write will be described in English. Make sure that you do the following things correctly, among other things. These suggestions are based on the errors most often made by students in our class.

There are many, many introductions, guides and tutorials on Java on the Web. You should have been studying them, but you might want to review them further. For example, the entire Java Tutorial book from Sun, 2nd edition, is available online here. There are additional Java resource links from our course homepage under Resources -- Java.

What to know for the Quiz - - UML

Again, the code you will be asked to write is simple. So the UML describing it is simple also. Below are some comments and illustrations. The notation is essentially the same as in my Memento example UML, which you can access here.

UML and UML class and interface diagrams

UML may be "unified", but it is certainly not standardized, as it is used by various people. The UML below is a fairly "vanilla" dialect that I have adopted after studying various sources, the standards document, etc. But you should also look at the UML material on the course web page, under Resources.

The basic superclass/subclass relation is represented as follows, where the definition of Subclass here would include
"class Subclass extends Superclass { .... }"
Inheritance from an interface ("implements") typically uses a dotted line rather than a solid one, but with the same open arrowhead.

Within a class, the field variables are given first, followed by the methods. In each case the type of the variable or return type of the method follows the colon following the name, as shown below.

An interface can be marked "<<interface>>" and of course contains no variable fields, only method declarations, as show here.

Often classes are not related by inheritance, but by the fact that a variable in one class refers to an object of another class. Such an association is shown below. Note that a label can be placed on the connecting line to indicate which variable in the referring class references the other class, as shown by the label "myB" below.

UML sequence diagrams

The first thing that typically happens in a running program is to create some instances of various classes. Notation for this is shown below. Note that the class names are underlined, indicating that they are objects, actual class instances at run time.

The drawing below shows a simple method call. Note that the name of the method, bMethod() is a method defined in the class BClass and called by code in AClass. I have omitted the create operation to keep the picture simple (but BClass must come from somewhere!).

If a call to a method in one instance leads to a call to a method in still another, the calls and returns must be nested, as shown below. In the simple analogy I described in class, going to the store and returning from it are analogous to a method call. Picking an object off the shelf while in the store is analogous to still another method call. The important point to note is that the picking operation must be started and finished between the time you go to the store and the time you return. Thus, in the figure below, the call to cMethod() is started and completed after the bMethod() is called and before the bMethod() returns.

A variation on this comes when we want to indicate that a method within an object is run, rather than a method on another object. This is shown below, where aMethod() is a method of AClass called during the execution of the code in AClass.

(I have not been too choosy about using solid or dashed vertical lines to indicate time flow down the page in these sequence diagrams. Both are commonly used.)


Go to com1204 home page.

Return to Prof. Futrelle's home page