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.
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.
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>>.
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.
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
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.