Section 10.3. Messages


10.3. Messages

The focus of interaction diagrams is on the communication between lifelines. This communication can take many different forms: method calls, sending a signal, creating an instance, destroying an object, etc., all of which are collectively called messages. A message specifies the kind of communication, its sender, and its receiver. For example, a PoliceOfficer class instantiating a SpeedingTicket class is represented as a message from an instance of PoliceOfficer to the newly created instance of SpeedingTicket.

The most common use of messages is to represent method calls between two objects. When messages are used to indicate a method call, you can show the parameters passed to the method in the message syntax. The parameters should be one of the following:

  • Attributes of the sending object

  • Constants

  • Symbolic values (expressions showing what the legal values can be)

  • Explicit parameters of the enclosing interaction

  • Attributes of the class owning the enclosing interaction

The syntax for a message is:

          attribute = signal_or_operation_name (arguments) : return_value

where:


attribute

Is an optional part of the syntax that provides a shorthand way of showing that the return value from this message is stored in the specified attribute. The attribute must be an attribute of the lifeline sending the message, a global attribute of the interaction, or an attribute of the class owning the interaction.


signal_or_operation_name

Specifies the name of the operation to invoke or the signal being emitted.


arguments

A comma-separated list of arguments to pass to the operation or signal. The arguments may be values or parameter names. If only argument values are used, arguments are matched against the operation or signal signature, in order. If you want to skip an argument, place a dash (-) where the argument would be. Skipped arguments have unknown values. You can explicitly identify a parameter name by following the text name with a colon (:) and then the value. If you use parameter names, you can omit arguments not relevant to the interaction. As with a dash, skipped arguments have unknown values.

You can prefix an argument with the keyword out or inout to indicate the argument is used to return a value. If the argument is used as an out argument, a value after the colon in the argument specification is interpreted to be the return value.


return_value

Explicitly states what the return value from this message will be.

Message notation varies based on the specific notation you use to show the details of the interaction. Because the most common representation of interactions is with sequence diagrams, you use the notation that's common with such diagrams. See the specifics about other notations in "Alternate Interaction Notations."

When using sequence diagram notation, you show a message as a solid line pointing from the sender's lifeline to the receiver's lifeline. If the message is an asynchronous message (meaning the caller doesn't block waiting for the receiver to process the message), you place an open arrowhead on the receiver's end of the line. Figure 10-5 shows an example of an asynchronous message.

Figure 10-5. An asynchronous message between objects


When returning a book to the library, you typically don't wait around for the librarian to return the book to the shelves. Instead, you drop the book off at the Circulation Desk and continue on your way. The open arrowhead indicates that the caller (AverageJoe) doesn't wait for any response from the CirculationDesk.

Because asynchronous messages don't require the sender to wait for a message to be delivered, depending on the transport mechanism, asynchronous messages can arrive out of order. For example, two network packets can take different routes to the same destination, with the second arriving before the first. You can show out-of-order reception by having the first message point to a spot below the reception point of the second message, as shown in Figure 10-6.

Figure 10-6. Asynchronous messages received out of order


In this example HostMachine sends two ping packets to DestinationMachine. Because of network differences in the routes taken, the response to the second ping arrives before the response to the first ping.

If a message represents synchronous communication (typically a method call), you place a filled arrow head on the receiver's end. You can show return values from a method using a dashed line with an open arrowhead pointing back to the caller. Figure 10-7 shows a method call to order an item and a confirmation number sent back as a return value.

If a message represents object creation, you show a dashed line, with an open arrow pointing to the newly created object's lifeline. By convention, the message is typically labeled with some variation of create. If there are no arguments to the message, you can simply label the message with the keyword «create», as in Figure 10-3. If there are arguments, you show them as parameters to a create( ) message. If there is a particular reason to show the creation message using a different label (such as a factory method), you should use that. Figure 10-8 shows an example that creates an instance of the class UserAccount.

Figure 10-7. A method call and the resulting return value


Figure 10-8. Showing object instantiation


Although this technique isn't mentioned in the specification, some modelers prefer to lower the rectangle representing the object to the end of the message line to clearly indicate the object didn't exist before this creation event. The advantage of this notation is that it clearly shows when the object comes into existence; the disadvantage is that you can't skim the top row and view the participants. Figure 10-9 shows the same diagram but lowers the newly created object.

UML defines two special types of messages: lost messages and found messages. Lost messages are messages that are sent but never reach their destination. Found messages are messages that are received by an object but the sender is unknown. For example, if you want to model an exception-handling mechanism, the sending of the exception is really irrelevant to the mechanism itself, so you can model that as a found message. Understand that unknown senders and receivers are relative concepts. The sender or receiver of a message may be unknown as far as a

Figure 10-9. Object instantiation with the object lined up with the creation message


particular interaction is concerned, meaning it's really outside the scope of what you are trying to show, not that the message necessarily vanishes from existence (though that's permissible too).

You show a found message by starting the message from a black circle rather than the sender's lifeline. Figure 10-10 shows an example of a found message. The CircuitBreaker doesn't care where the power surge came from; it must terminate the power in all conditions.

Figure 10-10. An example of a found message


Similarly, you show a lost message by terminating the message arrow at a black circle rather than a receiver's lifeline. Figure 10-11 shows a Workstation sending out a ping message that for some reason, (network failure) isn't received.

Figure 10-11. An example message being lost





UML 2.0 in a Nutshell
UML 2.0 in a Nutshell (In a Nutshell (OReilly))
ISBN: 0596007957
EAN: 2147483647
Year: 2005
Pages: 132

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net