Java How to Program Fourth Edition - DCC

352 Arrays Chapter 7
Both a FloorDoor and the ElevatorDoor inform a Person that they have
opened or closed, so both objects send doorOpened and doorClosed messages. 2
Finally, the ElevatorModel creates a Person, but the ElevatorModel cannot send
a personCreated message, because that Person does not yet exist. We discover, in
Section 8.6, how to use a special method that creates, or instantiates, new objects. This
method is referred to as an constructor—the ElevatorModel will create a Person by
calling that Person’s constructor (which is similar to sending the personCreated
message).
Lastly, the ElevatorDoor must send openDoor and closeDoor messages to a
FloorDoor to guarantee that these doors open and close together.
Collaboration Diagrams
Now let us consider the objects that must interact so that people in our simulation can enter
and exit the elevator when it arrives on a floor. The UML provides the collaboration diagram
to model such interactions. Collaboration diagrams are a type of interaction diagram;
they model the behavioral aspects of the system by providing information about how objects
interact. Collaboration diagrams emphasize which objects participate in the interactions.
The other type of interaction diagram is the sequence diagram, which we present in
Chapter 15. Figure 7.24 shows a collaboration diagram that models a person who is pressing
a floor button. An object in a collaboration diagram is represented as a rectangle that
encloses the object’s name. We write object names in the collaboration diagram by using
the convention we introduced in the object diagram of Fig. 3.24—objects are written in the
form objectName : ClassName. In this example, we disregard the object name, because
we care only about the object type. Collaborating objects are connected with solid
lines, and messages are passed between objects along these lines in the direction shown by
arrows. The name of the message, which appears next to the arrow, is the name of a method
belonging to the receiving object—think of the name as a “service” that the receiving object
(a “server”) provides for its sending objects (its “clients”).
pressButton( )
: Person : FloorButton
Fig. Fig. 7.24 7.24 Collaboration diagram of a person pressing a floor button
The arrow in Fig. 7.24 represents a message in the UML and a method—or synchronous
call—in Java. This arrow indicates that the flow of control is from the sending object
to the receiving object—the sending object may not send another message until the
receiving object processes the message and returns control to the sending object. For
example, in Fig. 7.24, a Person calls method pressButton of a FloorButton and
2. Note that most of the messages perform some specific action on the receiving object; for example,
the Elevator resets the ElevatorButton. However, other messages inform receiving objects
of events that have already happened; for example, the FloorDoor informs the Person
that the FloorDoor has opened. In Section 10.22, we elaborate on the topic of events—for now,
however, we proceed as if the two types of messages are indistinguishable.
© Copyright 1992–2002 by Deitel & Associates, Inc. All Rights Reserved. 7/3/01