A message specifies the sender and receiver, and defines the kind of communication that occurs between lifelines. For example, a communication can invoke, or call, an operation using a synchCall or asynchCall, raise a signal using an asynchSignal, and create or destroy a participant.
A message represents either an operation call or the sending and receiving of a signal. When a message represents an operation, the arguments of the message are the arguments of the CallAction on the sending lifeline and the arguments of the CallEvent on the receiving lifeline. When a message represents a signal, the arguments of the message are the arguments of the SendAction on the sending lifeline and the arguments are available in the SignalEvent on the receiving lifeline. If the message is a synchronous call, a return message typically occurs from the called lifeline to the calling lifeline before the calling lifeline can proceed.
As the following figure illustrates, a message is displayed in an interaction frame as a line with an arrow that points in the direction in which the message is sent; that is, from the sending message end to the receiving message end.
The message that the source lifeline sends to the target lifeline represents an operation or a signal that the target lifeline implements. You can name and order messages. The appearance of the line or arrowhead reflects the properties of the message. The following table illustrates the graphics that represent messages in sequence diagrams.
| Graphic | Description | Representation |
|---|---|---|
 |
A line with a solid arrowhead that points toward the receiving lifeline | This graphic represents a synchronous call operation in which the system waits for the flow of control to complete before continuing with the outer flow. |
 |
A line with an open arrowhead | This graphic represents an asynchronous signal or an asynchronous call in which the source object sends the message and immediately continues with the next step. |
 |
A dashed line with a solid arrowhead that points toward the originating lifeline | This graphic represents a return message from a call to a procedure. When you create a synchronous message, a return message is created by default. You can change this default in the Preferences window. |
You can identify messages by using a name or an operation signature.
| Type | Example | Description |
|---|---|---|
| Name | \Get the Password\ | A name identifies only the name of the message. One convention places the name in slashes (\\) to indicate that the message name is not associated with an operation. When an operation is associated with a message, the operation name replaces the name. |
| Signature | getPassword | When an operation is assigned to a message, you can display the operation signature to identify the name of the operation. Signatures are often used in diagrams during the design phase because they provide the detail that developers need when they code the design. |
Manipulation of asynchronous messages
An asynchronous message is the only message type in which you can individually move its sending point and receiving point. You can move the points of an asynchronous message between lifelines to manipulate the time delay between the sending event and the receiving event; the result is called a skewed message.
As the following figure illustrates, a skewed message is displayed as a line with an open arrowhead that has multiple interactions that occur between the sending and receiving lifelines.
The send event is not blocked and interactions can occur between the point on the sending lifeline and the point on the receiving lifeline.