10.6. Object Diagrams

When describing how objects can interact, we sometimes find it helpful to sketch out a scenario of specific objects and their linkages, and for that we create an object diagram. An instance, or object, looks much the same as a class in UML notation, the main differences being that the following:

• We typically provide both the name of the object and its type, separated by a colon. We underline the text to emphasize that this is an object, not a class (see Figure 10-27).

  Figure 10.27. Representing an object

  

• The object's name can be omitted if we want to refer to a "generic" object of a given type; such an object is known as an anonymous object. Note that we must precede the class name with a colon (:) in such a situation (see Figure 10-28).

  Figure 10.28. Representing an anonymous object

  

Therefore, if we wanted to indicate that Dr. Brown, a Professor, is the advisor for three Students, we could create the object diagram shown in Figure 10-29.

Figure 10.29. Dr. Brown advises three students.

10.6.1. Associations As Fields

Given Figure 10-30, which shows the association "a Course is offered as a Section," we see that a Course object can be related to many different Section objects, but that any one Section object can only be related to a single Course object.

Figure 10.30. A one-to-many association between the Course and Section classes

By way of review, what does it mean for two objects to be related? It means that they maintain object references on one another so that they can easily find one another to communicate and collaborate, a concept that we talked about with the balloon strings metaphor in Chapter 4. If we were to sketch out the fields of the Course and Section classes based solely on the diagram in Figure 10-30, we'd need to allow for these object references as reference variables, as follows:

public class Section {
  // Fields.
  private Course course;   // A reference to a single Course
						// object
  // etc.
}

public class Course {
  // Fields.
  private Collection sectionsOffered;   // A collection of Section
						// object references.
  // etc.
}

So we see that the presence of an association between two classes A and B in a class diagram implies that class A potentially has a field declared to be either depending on the multiplicity involved, and vice versa:

• A reference to a single instance/object of type B

• A collection of references to many objects of type B

We say potentially because when we get to the point of actually programming this application, we might or might not wish to code this relationship bidirectionally, even though at the analysis stage all associations are presumed to be bidirectional. We'll talk about the pros and cons of using bidirectional relationships in Chapter 14.

Because the presence of an association line implies fields as object references in both related classes, it's inappropriate to additionally list such fields in the field compartment of the respective classes (see Figure 10-31).

Figure 10.31. Redundantly reflecting references as fields is incorrect; the presence of an association implies these.

public class Course {
  Collection sectionsOffered;   // by virtue of an explicit field
							Collection offeredAs;        // by virtue of the association
  // etc.
}