13.4 Polymorphic Events and Polymorphic Signals

When a supervisor tells a clerk to go off-duty, the supervisor does not care whether the clerk is a shipping clerk or a stock clerk. Similarly, when an action sends a signal to an object in a class hierarchy, the sender should not need to know the subclass of the object. Rather, the signal is polymorphic.

Definition: A polymorphic signal is a signal delivered at run time to a specific state machine for a class in a generalization hierarchy.

In keeping with the distinction between events and signals in UML, we define also a polymorphic event.

Definition: A polymorphic event is an event that has many potential receiving state machines in a generalization hierarchy

Rules about Polymorphic Signals

1. A polymorphic event specification is declared for an abstract superclass, and the corresponding event may be received by any of the superclass's subclasses.

2. A polymorphic signal cannot be received by the superclass in which the event is specified, only in the subclasses.

3. The polymorphic signal must be able to be received in every branch in the superclass's hierarchy, so that the polymorphic signal occurrence always has a receiving state machine instance.

4. At run time, the polymorphic signal occurrence is received as an event by exactly one state machine instance in a given hierarchy.

5. If a superclass has repeated specializations, each class in the specialization hierarchy must be able to receive an occurrence of the event.

6. If a superclass has multiple specializations, the polymorphic signal occurrence is received by at most one state machine instance in each specialization hierarchy.

A polymorphic event is abstracted and so given a name and a signature at the superclass level. The signal is then received by the subclass state machine depending on the type at run time. Figure 13.12 illustrates the events received by the different warehouse clerk subclasses and the polymorphic event that can be received by any warehouse clerk, adding the events to the operations compartment for illustrative purposes only.

Figure 13.12. Polymorphic Events in a Generalization Hierarchy

Each subclass's state machine may respond differently to the same signals, so that, for example, a shipping clerk may be required to complete a shipment first while a stock clerk can knock off immediately.

The sender doesn't have to know the subclass of the clerk. The following action language is perfectly valid because the goOffDuty signal can be sent to any instance of a Clerk:

select any luckyClerk from instances of WarehouseClerk;
luckyClerk.goOffDutyAtEndOfJob = true;
generate goOffDuty to luckyClerk;

The following is not valid, because shipmentReady can be sent only to a shipping clerk, and one cannot determine whether the assignedClerk refers to a stock clerk or a shipping clerk:

select any assignedClerk from instances of ShippingClerk;
generate shipmentReady to assignedClerk;

Signals defined at a subclass level can be sent only to instances of that subclass, while polymorphic signals can be sent to any instance of the superclass.

The rules for polymorphic signals mirror those for polymorphic operations in UML or an object-oriented program. We declare the event in an abstract superclass, and each subclass has to be able to interpret the signal should it arrive at run time.