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.

Kinds 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 using a synchronous call message or asynchronous call message, raise a signal using an asynchronous signal, and create or destroy a participant.

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

Message Description Example
Create message 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 message 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 message Synchronous calls, which are associated with an operation, have a send and 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 message Asynchronous calls, which are associated with an operation, 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 message Asynchronous signal messages, are associated with a signal. A signal differs from a message in that there is no operation associated with the signal. A signal can represent an interrupt 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.

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 a behavior execution specification 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.

Type Graphic Description Representation
Asynchronous A line with an open arrowhead that points to the right. 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 to the right. 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 to the left. 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.

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 the application for the loan to the bank teller.
  • The bank teller sends the application to be processed by the bank manager 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 and sends a message to the bank teller that states the decision.
  • The bank teller sends a message to the customer about 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