Graphic by Keith Ohlfs

CS111, Wellesley College, Spring 1998 How to Draw Execution Diagrams

In class, we described the rules for drawing Execution Diagrams. Recall that an Execution Diagram has two areas: (1) an Execution Land in which execution frames are drawn and (2) an Object Land in which objects (i.e., instances of classes) are drawn. The objects in Object Land are often the values of expressions and the contents of variables that appear in Execution Land.

References from Execution Land to the objects in Object Land are often drawn as pointers that connect the Execution Land expressions or variables to the desired Object Land objects. However, even in simple Execution Diagrams, a proliferation of references can lead to pointer spaghetti that is difficult to decipher. Below we introduce conventions for simplifying the structure of Execution Diagrams by replacing pointers by reference labels. You should follow these conventions when drawing Execution Diagrams in this course.

How to Draw Objects

Every instance object that is created during the execution of a program by a constructor method invocation (e.g. new classname (parameters)) should be drawn as a blob in Object Land. The blob should have the following parts:

1. A class label that indicates the class to which the instance belongs. The class label should be drawn outside the blob, at its top.
2. A reference label that uniquely identifies the object. We will represent reference labels as short names that appear within ovals. E.g.:

The reference label should be drawn outside the blob, at its left. When refering to reference labels in a discussion, we will write them in bold teletype font: B1, C5, D4, P3.

1. State variables that indicate the state of the object represented by the blob. For example:
   • The state variables of a Point instance are its x and y coordinates (each an integer).
   • The state variables of a Color instance are its red, green, and blue components (each an integer in the range 0--255).
   • The state variable is a Direction instance is a direction tag. There are four such tags, which we shall write as north, east, south, and west.
   • The state variables of a Buggle instance include:
     • its position, which is a Point instance.
     • its heading, which is a Direction instance.
     • its color, which is a Color instance.
     • its brush state, which is a boolean value (i.e., true or false). True indicates that the brush is down; false indicates that the brush is up.

   The state variables of an instance should be drawn inside the blob. Each variable should have a name and a value.

Below are depictions of sample instances that conform to the above conventions:

Note how objects may have state variables that refr to other instances.

For certainly commonly used objects like instances of the Color and Direction class, we will adopt the convention that the object can be referenced via an informative reference label. For example, we will use reference labels like RED and BLUE to stand for appropriate instance of the Color class, and NORTH and EAST to stand for appropriate instance of the Direction class.

It is often the case that we do not know exactly what the state variables of a black-box object are. For example, even though we have used instances of the BuggleWorld, PictureWorld, and Picture classes, we are not privy to the details of their state variables. In such cases, the inside of the instance blob should contain whatever information helps to identify it and distinguish it from other blobs from the same class. For example, an instance of the Picture class might be drawn as a blob containing a sketch of the picture. An instance of BuggleWorld might be drawn as a blob containing a picture of the BuggleWorld's grid. Even the Direction class described above is really of this form; we don't know precisely how Direction instances are represented, but we know that they contain enough information to distinguish north, east, south, and west. When we know very little about an object, we can just draw it as a black box. We will typically use the black-box representation for instances of BuggleWorld and PictureWorld, because depictions of these objects are difficult to draw.

Note: When we learn more about the structure of objects later in the semester, we will revise the rules for drawing objects.

How to Draw Execution Frames

An execution frame represents the state of the execution of a method invocation. Every execution frame has two parts: (1) the set of variables used by the method body and (2) a sequence of statements that is the body of the method. Such a frame is drawn as emanating from the method invocation statement that spawned it. For example:

The execution of the statements in the frame proceeds statement by statement from the top to the bottom. For each statement, any expressions appearing in the statement are first evaluated to values. For instance, evaluating the variable reference this in the first statement of the above execution diagram yields a reference to Buggle B1. This evaluation is represented in the execution frame by replacing this by B1.

The next expression to be evaulated is the variable reference steps, whose value is 5:

Now that all the subexpressions of the method invocation statement have been evaluated, the method is invoked. This creates a new frame:

Execution proceeds as above in the new frame until all statements in the body of the side method have been executed. At that point control returrns to the execution frame for corner and executes its second statement. When control returns to the corner frame, any space required by the side frame is reclaimed. However, in our execution diagrams, we will continue to show the side frame to indicate the history of the computation.

Because it is tedious to show the step-by-step execution of a computation as a sequence of execution diagrams, we will typically ask you to show only the final execution diagram for a computation.

Example Execution Diagrams

As a complete example, consider the following code for the CornerWorld and CornerBuggle classes:

public class CornerWorld extends BuggleWorld {
	
	public void run () {
		CornerBuggle cora = new CornerBuggle(); 
		CornerBuggle colby = new CornerBuggle();
		colby.setPosition(new Point(4,2));
		cora.corner(5);
		colby.corner(3);
	}
	
}
 
class CornerBuggle extends Buggle {
	
	
	public void corner (int steps) {
		this.side(steps);
		this.side(steps);
	}
	
	public void side (int n) {
		this.forward(n);
		this.left();
	}
	
}

Suppose that reference label W1 names an instance of the CornerWorld class. The final execution diagram for the execution of the statement W1.run() is shown below. Note how the state of the CornerBuggle objects reflects the result of performing the executed methods on the buggles. There are several Point objects that are created by the invocations of the forward method; only those referenced in the final diagram are shown.

We emphasize that the frames in the final execution diagram represent the history of the computation but do not accurately show the amount of space required by the computation. Whenever control leaves an execution frame, any space required by the execution frame is reclaimed.