Section 3.8. Sending and Receiving Signals

3.8. Sending and Receiving Signals

Activities may involve interactions with external people, systems, or processes. For example, when authorizing a credit card payment, you need to verify the card by interacting with an approval service provided by the credit card company.

In activity diagrams, signals represent interactions with external participants. Signals are messages that can be sent or received, as in the following examples:

• Your software sends a request to the credit card company to approve a credit card transaction, and your software receives a response from the credit card company (sent and received, from the perspective of your credit card approval activity).

• The receipt of an order prompts an order handling process to begin (received, from the perspective of the order handling activity).

• The click of a button causes code associated with the button to execute (received, from the perspective of the button event handling activity).

• The system notifies a customer that his shipment has been delayed (sent, from the perspective of the order shipping activity).

A receive signal has the effect of waking up an action in your activity diagram. The recipient of the signal knows how to react to the signal and expects that a signal will arrive at some time but doesn't know exactly when. Send signals are signals sent to an external participant. When that external person or system receives the message, it probably does something in response, but that isn't modeled in your activity diagram.

Figure 3-20 refines the steps in Figure 3-19 to show that the credit card approval action requires interaction with external software. The send signal node shows that a signal is sent to an outside participant. In this example, the signal is a credit card approval request. Signals are sent asynchronously, meaning the activity does not wait for the response but moves immediately to the next action after the signal is sent.

Figure 3-20. Send and receive signal nodes show interactions with external participants

The receive signal node shows that a signal is received from an external process. In this case, the system waits for a response from the credit card company. At a receive signal node, the action waits until a signal is received and proceeds only when a signal is received.

Notice that combining send and receive signals results in behavior similar to a synchronous call, or a call that waits for a response. It's common to combine send and receive signals in activity diagrams because you often need a response to the signal you sent.

When you see a receive signal node with no incoming flows, it means that the node is always waiting for a signal when its containing activity is active. In the case of Figure 3-21, the activity is launched every time an account request signal is received.

Figure 3-21. Starting an activity with a receive signal node: the receive signal node replaces the usual initial node

This differs from a receive signal node with an incoming edge, such as the Receive Response node in Figure 3-20; a receive signal node with an incoming edge only starts waiting when the previous action is complete.