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