Concepts: Events and Signals
Topics
Introduction
In the real world, things happen, often simultaneously and unpredictably. "Things that happen" are called 'events'.
In the context of state machines, events model the occurrence of a stimulus that may trigger a state transition. Events include signals, calls, the passage of time, or a change in state. Events may be synchronous or asynchronous.
A 'signal' is a kind of event that represents the specification of an asynchronous stimulus between two instances.
Kinds of events
Events may be external or internal. External events are those that pass between the system and its actors. Internal events are those which pass among the objects that live within the system. There are four kinds of events: signals, calls, the passing of time, and a change in state.
Signals
A signal represents an object that is dispatched (thrown) asynchronously by one object and then received (caught) by another. Exceptions are an example of a kind of signal.
Signals may have instances, although these instances are not typically modeled explicitly. Signals may be involved in generalization relationships, enabling the modeling of hierarchies of events.
Signals may have attributes and operations. The attributes of a signal serve as its parameters.
A signal may be sent as the action of a state transition in a state machine or the sending of a message in an interaction. The execution of an operation can also send signals. When modeling a class or an interface, an important part of specifying the behavior of the element is specifying the signals that can be sent by its operations. The relationship between an operation and the events which it can send are modeled using a dependency relationship, stereotyped as <<send>>.
Call events
Just as a signal event represents the occurrence of a signal, a call event represents the dispatch of an operation. In both cases, the event may trigger a state transition in a state machine.
Whereas a signal is an asynchronous event, a call event is, in general, synchronous. This means that when an object invokes an operation on another object, control passes from the sender to the receiver until the operation is completed, whereupon control returns to the sender. Modeling a call event is visualized in the same way as a signal event. In both cases, the event is displayed along with its parameters as the trigger for a state transition.
Although there are no visual cues to distinguish a signal event from a call event, the difference will appear in the receiver class, as it will declare an operation which handles the call event. In the case of a signal, there will be a transition in the state machine which is triggered by the signal.
Time and change events
A time event represents the passage of time. Time events are used to synchronize time-dependent parts of the system using a common clock mechanism. A change event represents a change in the state of the system or the satisfaction of some condition.
Sending and receiving events
Signal and call events involve at least two objects: a sender and a receiver. When the signal is sent, the sender dispatches the signal and ten continues upon its flow of control without waiting for a return from the receiver. This is in contrast with the semantics of the operation call in which the sender waits for the receiver to respond before resuming its flow of control. Because of this, operations are typically used to represent "blocking" behavior (behavior which blocks or prevents other things from happening), while signals are used to represent non-blocking behavior.
The act of one object sending a signal to a set of objects is called 'multi-casting', and is represented by sending a signal to a container which holds a set of receivers. Broadcasting is the act of sending a signal to all objects in a system, and is represented by sending a signal to an object which represents the system as a whole; this 'system object' in turn realizes message distribution mechanism which ensure that the signal is sent to all appropriate objects in the system.
