Messages in UML diagrams

A message is an element in a Unified Modeling Language (UML) diagram that defines a specific kind of communication between instances in an interaction. A message conveys information from one instance, which is represented by a lifeline, to another instance in an interaction.

Types of messages

A message specifies a sender and receiver, and defines the kind of communication that occurs between lifelines. For example, a communication can invoke, or call, an operation by using a synchronous call message or asynchronous call message, can raise a signal using an asynchronous signal, and can create or destroy a participant.

You can use the five types of messages that are listed in the following table to show the communication between lifelines in an interaction.

Message type	Description	Example
Create	A create message represents the creation of an instance in an interaction. The create message is represented by the keyword «create». The target lifeline begins at the point of the create message.	In a banking scenario, a bank manager might start a credit check on a client by sending a create message to the server.
Destroy	A destroy message represents the destruction of an instance in an interaction. The destroy message is represented by the keyword «destroy». The target lifeline ends at the point of the destroy message, and is denoted by an X.	A bank manager, after starting a credit check, might close or destroy the credit program application for a customer.
Synchronous call	Synchronous calls, which are associated with an operation, have a send and a receive message. A message is sent from the source lifeline to the target lifeline. The source lifeline is blocked from other operations until it receives a response from the target lifeline.	A bank teller might send a credit request to the bank manager for approval and must wait for a response before further serving the customer.
Asynchronous call	Asynchronous calls, which are associated with operations, typically have only a send message, but can also have a reply message. In contrast to a synchronous message, the source lifeline is not blocked from receiving or sending other messages. You can also move the send and receive points individually to delay the time between the send and receive events. You might choose to do this if a response is not time sensitive or order sensitive.	A bank customer could apply for credit but can receive banking information over the phone or request money from an ATM, while waiting to hear about the credit application.
Asynchronous signal	Asynchronous signal messages are associated with signals. A signal differs from a message because no operation is associated with the signal. A signal can represent an interrupt condition or error condition. To specify a signal, you create an asynchronous call message and change the type in the message properties view.	A credit agency could send an error signal message to the bank manager that states a failure to connect to the credit bureau.
Lost and found	A lost message is a message that has a known sender but the receiver is not known. A found message is a message that does not have a known sender but has a receiver.	An outside actor sends a message to a bank manager. The actor is outside the scope of the sequence diagram and is therefore a found message. A lost message can occur when a message is sent to an element outside the scope of the UML diagram.

An asynchronous message is the only message type for which you can individually move the sending and receiving points. You can move the points of an asynchronous message to manipulate the time delay between the sending event and the receiving event; the result is called a skewed message. You can create an asynchronous message with or without a behavior execution specification.

A self-directed message is a message that is sent from the source lifeline to itself. A self-directed message could be a recursive call or a call to another operation or signal that belongs to the same object.

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 shows the graphics that represent messages in UML diagrams.

Message type	Description	Representation
Asynchronous	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.
Synchronous	A line with a solid arrowhead that points toward the receiving lifeline	This graphic represents a synchronous call operation in which the source object sends a message and waits for a return message from the target before the source can continue.
Synchronous return	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.
Lost and found	A line with an open arrowhead and that contains a dot at either end.	This graphic represents a lost or found message. A lost message contains a dot at the end of the arrowhead to indicate the destination is unknown. A dot at the source of the message indicates a found message with an unknown sender.

A message represents either an operation call or the sending and receiving of a signal. When the message represents an operation, the operation name identifies the message. The arguments of the message are passed to the target source. The return message contains the arguments of the resulting operation call. When a message represents a signal, the arguments of the message are the signal itself. If the message is a synchronous call, a return message occurs from the called lifeline to the calling lifeline before the calling lifeline can proceed.

You can identify messages by using a name or an operation signature. A name identifies only the name of the message that is not associated with an operation. When an operation is associated with a message, the operation name replaces the name. An operation signature is displayed to identify the name of the operation. You can use signatures in diagrams during the design phase to provide details to the developers who code the design.

As the following figure illustrates, messages are displayed 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 following example shows how messages are displayed in a sequence diagram that represents a banking scenario in which a bank customer applies for a loan by following this process.

A customer gives an application for the loan to a bank teller.
The bank teller sends the application to the bank manager to processed and waits for the manager to finish.
The bank manager starts the credit check program, enters the data, and waits for the credit agency to send the results.
The bank manager receives a response from the credit agency and sends a message to the bank teller that states the decision.
The bank teller sends a message to the customer that states whether the loan was approved.
The bank manager closes the credit agency program and the customer completes the transaction.

An example of a bank transaction that shows messages passing between different bank lifelines.

Feedback