Events may be external or internal. External events are those that pass between the system and its actors. For example, the pushing of a button and an interrupt from a collision sensor are both examples of external events. Internal events are those that pass among the objects that live inside the system. An overflow exception is an example of an internal event.

In the UML, you can model four kinds of events: signals, calls, the passing of time, and a change in state.

A message is a named object that is sent asynchronously by one object and then received by another. A signal is a classifier for messages; it is a message type.

Signals have a lot in common with plain classes. For example, signals may have instances, although you don't generally need to model them explicitly. Signals may also be involved in generalization relationships, permitting you to model hierarchies of events, some of which are general (for example, the signal NetworkFailure) and some of which are specific (for example, a specialization of NetworkFailure called WarehouseServerFailure). Also as for classes, signals may have attributes and operations. Before it has been sent by one object or after it is received by another, a signal is just an ordinary data object.

A signal may be sent by the action of a transition in a state machine. It may be modeled as a message between two roles in an interaction. The execution of a method can also send signals. In fact, when you model a class or an interface, an important part of specifying the behavior of that element is specifying the signals that its operations can send.

In the UML, as Figure 21-2 shows, you model signals as stereotyped classes. You can use a dependency, stereotyped as send, to indicate that an operation sends a particular signal.

Figure 21-2. Signals

Just as a signal event represents the occurrence of a signal, a call event represents the receipt by an object of a call request for an operation on the object. A call event may trigger a state transition in a state machine or it may invoke a method on the target object. The choice is specified in the class definition for the operation.

Whereas a signal is an asynchronous event, a call event is usually synchronous. This means that when an object invokes an operation on another object that has a state machine, control passes from the sender to the receiver, the transition is triggered by the event, the operation is completed, the receiver transitions to a new state, and control returns to the sender. In those cases where the caller does not need to wait for a response, a call can be specified as asynchronous.

As Figure 21-3 shows, modeling a call event is indistinguishable from modeling a signal event. In both cases, you show the event, along with its parameters, as the trigger for a state transition.

Figure 21-3. Call Events

A time event is an event that represents the passage of time. As Figure 21-4 shows, in the UML you model a time event by using the keyword after followed by some expression that evaluates to a period of time. Such expressions can be simple (for example, after 2 seconds) or complex (for example, after 1 ms since exiting Idle). Unless you specify it explicitly, the starting time of such an expression is the time since entering the current state. To indicate a time event that occurs at an absolute time, use the keyword at. For example, the time event at (1 Jan 2005, 1200 UT) specifies an event that occurs on noon Universal Time on New Year's Day 2005.

Figure 21-4. Time and Change Events

A change event is an event that represents a change in state or the satisfaction of some condition. As Figure 21-4 shows, in the UML you model a change event by using the keyword when followed by some Boolean expression. You can use such expressions for the continuous test of an expression (for example, when altitude < 1000).

A change event occurs once when the value of the condition changes from false to true. It does not occur when the value of the condition changes from true to false. The event does not recur while the event remains true.

Signal events and call events involve at least two objects: the object that sends the signal or invokes the operation and the object to which the event is directed. Because signals are asynchronous, and because asynchronous calls are themselves signals, the semantics of events interact with the semantics of active objects and passive objects.

Any instance of any class can send a signal to or invoke an operation of a receiving object. When an object sends a signal, the sender dispatches the signal and then continues along its flow of control, not waiting for any return from the receiver. For example, if an actor interacting with an ATM system sends the signal pushButton, the actor may continue along its way independent of the system to which the signal was sent. In contrast, when an object calls an operation, the sender dispatches the operation and then waits for the receiver to reply. For example, in a trading system, an instance of the class Trader might invoke the operation confirmTransaction on some instance of the class Trade, thereby affecting the state of the Trade object. If this is a synchronous call, the Trader object will wait until the operation is finished.

Any instance of any class can receive a call event or a signal. If this is a synchronous call event, then the sender and the receiver are in a rendezvous for the duration of the operation. This means that the flow of control of the sender suspends until the execution of the operation completes. If this is a signal, then the sender and receiver do not rendezvous: The sender dispatches the signal but does not wait for a response from the receiver. In either case, this event may be lost (if no response to the event is specified), it may trigger the receiver's state machine (if there is one), or it may just invoke a normal method call.

In the UML, you model the call events that an object may receive as operations on the class of the object. In the UML, you model the named signals that an object may receive by naming them in an extra compartment of the class, as shown in Figure 21-5.

Figure 21-5. Signals and Active Classes

In most event-driven systems, signal events are hierarchical. For example, an autonomous robot might distinguish between external signals, such as a Collision, and internal ones, such as a HardwareFault. External and internal signals need not be disjoint, however. Even within these two broad classifications, you might find specializations. For example, HardwareFault signals might be further specialized as BatteryFault and MovementFault. Even these might be further specialized, such as MotorStall, a kind of MovementFault.

By modeling hierarchies of signals in this manner, you can specify polymorphic events. For example, consider a state machine with a transition triggered only by the receipt of a MotorStall. As a leaf signal in this hierarchy, the transition can be triggered only by that signal, so it is not polymorphic. In contrast, suppose you modeled the state machine with a transition triggered by the receipt of a HardwareFault. In this case, the transition is polymorphic and can be triggered by a HardwareFault or any of its specializations, including BatteryFault, MovementFault, and MotorStall.

To model a family of signals,

Figure 21-6 models a family of signals that may be handled by an autonomous robot. Note that the root signal (RobotSignal) is abstract, which means that there may be no direct instances. This signal has two immediate concrete specializations (Collision and HardwareFault), one of which (HardwareFault) is further specialized. Note that the Collision signal has one parameter.

Figure 21-6. Modeling Families of Signals

An important part of visualizing, specifying, and documenting the behavior of a class or an interface is specifying the abnormal occurrences that its operations can produce. If you are handed a class or an interface, the operations you can invoke will be clear, but the abnormal occurrences that each operation may raise will not be clear unless you model them explicitly.

In the UML, abnormal occurrences are just additional kinds of events that can be modeled as signals. Error events may be attached to specification operations. Modeling exceptions is somewhat the inverse of modeling a general family of signals. You model a family of signals primarily to specify the kinds of signals an active object may receive; you model abnormal occurrences primarily to specify the kinds of abnormal occurrences that an object may produce.

To model abnormal occurrences

Figure 21-7 models a hierarchy of abnormal occurrences that may be produced by a standard library of container classes, such as the template class Set. This hierarchy is headed by the abstract signal Error and includes three specialized kinds of errors: Duplicate, Overflow, and Underflow. As shown, the add operation may produce Duplicate and Overflow signals, and the remove operation produces only the Underflow signal. Alternatively, you could have put these dependencies in the background by naming them in each operation's specification. Either way, by knowing which signals each operation may send, you can create clients that use the Set class correctly.

Figure 21-7. Modeling Error Conditions