Concepts:
Events and Signals
Topics
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.
Copyright
© 1987 - 2001 Rational Software Corporation
| 
Disciplines >
Analysis & Design >
Concepts >
