Design Patterns : Elements of Reusable Object-Oriented Software

Object Diagram 
An object diagram shows instances exclusively. It provides asnapshot of the objects 
in a design pattern. The objects are named"a
Something
", where 
Something
is the 
class ofthe object. Our symbol for an object (modified slightly fromstandard OMT) 
is a rounded box with a line separating the objectname from any object references. 
Arrows indicate the objectreferenced. Figure B.2 shows an example. 

---

Design Patterns: Elements of Reusable Object-Oriented Software 
407 
Figure B.2: Object diagram notation 
Interaction Diagram 
An interaction diagram shows the order in which requests between objectsget 
executed. Figure B.3 is aninteraction diagram that shows how a shape gets added 
to a drawing. 
Figure B.3: Interaction diagram notation 
Time flows from top to bottom in an interaction diagram. A solidvertical line 
indicates the lifetime of a particular object. Thenaming convention for objects 
is the same as for object diagrams
—
theclass name prefixed by the letter "a" (e.g., 
aShape). If the objectdoesn't get instantiated until after the beginning of time 
as recordedin the diagram, then its vertical line appears dashed until the pointof 
creation. 

---

Design Patterns: Elements of Reusable Object-Oriented Software 
408 
A vertical rectangle shows that an object is active; that is, it ishandling a 
request. The operation can send requests to other objects;these are indicated 
with a horizontal arrow pointing to the receivingobject. The name of the request 
is shown above the arrow. A requestto create an object is shown with a dashed 
arrowheaded line. Arequest to the sending object itself points back to the sender. 
Figure B.3 shows that the first request is from aCreationTool tocreate 
aLineShape. Later, aLineShape is Added to aDrawing, whichprompts aDrawing to send 
a Refresh request to itself. Note thataDrawing sends a Draw request to aLineShape 
as part of the Refreshoperation. 
1
OMT uses the term "object diagram" torefer to class diagrams. We use "object 
diagram" exclusively torefer to diagrams of object structures. 
2
OMT also defines 
associations
between classes, which appear as plain lines between 
class boxes.Associations are bidirectional. Although associations are 
appropriateduring analysis, we feel they're too high-level for expressing 
therelationships in design patterns, simply because associations mustbe mapped 
down to object references or pointers during design.Object references are 
intrinsically directed and are thereforebetter suited to the relationships that 
concern us. For example,Drawing knows about Shapes, but the Shapes don't know 
about theDrawing they're in. You can't express this relationship withassociations 
alone. 

---