10.1 Signals

Objects communicate as a result of state machine instances sending signals. To synchronize the behavior of objects, actions in state machine instances generate signals to establish the dynamics of a domain.

Definition: A signal is a message that may carry data used by the actions in a procedure of the recipient's state machine instance.

The signaling is asynchronous. Once the signal is sent, the sender goes on about its business. Separately, once the event is detected by the receiver, a transition is made and the receiver executes a procedure. The receiver does not "return" to the sender, though it may choose to send another signal.

10.1.1 Sending Signals

Signal actions send signals to objects. In Figure 10.1, a signal is sent by the shipment and detected as an event by a related order.

Figure 10.1. Shipment State Procedure Sends orderDelivered signal to Order

An action in the procedure for the shipment generates a signal to the order, where order is the object reference of the receiver found by traversing the association R1 from the shipment.

10.1.2 Event Parameters

Definition: An event parameter is a data item passed along with an event.

The collection of event parameters on an event can be viewed as an object in its own right created dynamically by the sender.

The actions of the procedure use the values of the event parameters. The parameter values are accessed in the actions conventionally via rcvd_evt, which denotes the object that carries the parameters.

Figure 10.2 shows an event and its parameters. In this example, the customer provides information sufficient to check out: the charge card expiration date, the card holder name and credit card number, as well the customer's name, phone number and address. These event parameters are received with the event and accessed in the procedure. Figure 10.2 also shows how parameters are provided to a send (generate) a signal.

Figure 10.2. Event Parameters Provided to a Procedure in the Order State Machine

All events that cause a transition into a particular state must carry exactly the same event parameters. This rule guarantees that the procedure will have the same parameters regardless of which event caused the transition. This is the same as the general rule in a programming language that requires invocation of a function to have the same signature, regardless of the caller.

UML uses signal to signify an explicit send of an asynchronous message detected as an event by the receiver.

UML uses event to signify anything that can be detected by a state machine, regardless of cause. There are several kinds of events defined, including signal events, time events, and change events.

A signal event is an event resulting from the receipt of a signal.

Hence, a signal and a (signal) event are really the same thing, but with different names from the perspective of the sender and receiver, respectively.

10.1.3 Signals with Parameters

When a signal carries parameters, the actual parameters are assembled as name/value pairs.

generate addSelection (
 productID: rcvd_evt.productID,
 quantity: rcvd_evt.quantity) to order;

The parameter name on the left of the colon is the formal parameter, and the value specified on right of the colon is the actual parameter. By using name-value pairs, the order of the actual parameters is unimportant.

Executable UML requires every parameter to be supplied: If a signal specification is defined to have a certain set of parameters, each time the signal is sent it must carry values for those parameters.

The signal and its parameters are interpreted as a signal event and its parameters by the receiver.

Because signals are received as events, event parameters are exactly the same as the signal parameters. All kinds of events on state machines can have parameters, not just signal events, so we shall use "event parameter" preferentially.

10.1.4 Signals to Self

Figure 10.3 shows how a state machine can generate a signal to itself.

Figure 10.3. Signal to self

UML has the notion of a completion event that serves the same purpose as a signal to self. Completion events are always handled first, just like signals to self. Completion events in UML are shown as an unlabeled transition.

With one exception the transition to a final pseudostate (see Section 9.4.2: Final Pseudostates) Executable UML labels all transitions. By requiring all transitions to be labeled with events, an omitted event does not cause an unwanted completion event, thereby making Executable UML notationally less error-prone.

This technique can be used to simplify state machines when a single (logical) state needs to be broken into several states, perhaps as the result of some conditional logic.

These signals are syntactically just like any other. However, signals to self are always treated first by the receiver, even if other events are outstanding.

10.1.5 Signals to External Entities

Procedures may need to signal outside the domain to request a particular task to be performed or to provide a notification. Signals can be defined for external entities representing actors, and signal actions can be written in the procedures using these signals:

generate requestChargeApproval (…)
       to EE_creditCardCompany;
       // Process a credit card charge
generate chargeApproved (…) to EE_OnlineCustomer;
       // Notify customer

These signals to external entities constitute requirements on the domains that communicate with the external entities. It is the responsibility of these domains to satisfy the requirements, not of the domain that generates the signals.

To distinguish external entities from domain classes with similar names, we will (by our own convention) precede all external entities with the letters EE_:

EE_OnlineCustomer

EE_CreditCardCompany

EE_ShippingClerk