Events and Signals

An event is the specifcation of a signifcant occurrence that has a location in time and space.
In the context of state machines, an event is an occurrence of a stimulus that can trigger a state
transition.
A signal is a kind of event that represents the specifcation of an asynchronous stimulus
communicated between 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 that pass among the objects that live inside the system.
An overow exception is an example of an internal event.
In the !"#, you can model four kinds of events$ signals, calls, the passing of time, and a change
in state.
Signals
A signal represents a named object that is dispatched %thrown& asynchronously by one object
and then received %caught& by another.
Exceptions are supported by most contemporary programming languages and are the most
common kind of internal signal that you will need to model.
'ignals may also be involved in generali(ation relationships, permitting you to model hierarchies
of events, some of which are general and some of which are specifc
Also as for classes, signals may have attributes and operations.
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. )he execution of an operation 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.
*e model signals %and exceptions& as stereotyped classes. *e can use a dependency,
stereotyped as send, to indicate that an operation sends a particular signal.
Signals
Call Events
+ust 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
*hereas a signal is an asynchronous event, a call event is synchronous
)his 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.
"odeling 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.
Call Events
Time and Change Events
A time event is an event that represents the passage of time
in the !"# you model a time event by using the keyword after followed by some expression that
evaluates to a period of time.
!nless you specify it explicitly, the starting time of such an expression is the time since entering
the current state.
A change event is an event that represents a change in state or the satisfaction of some
condition
In the !"# you model a change event by using the keyword when followed by some ,oolean
expression
-ou can use such expressions to mark an absolute time %such as when time . //$01& or for the
continuous test of an expression
Time and Change Events
Note$ Although a change event models a condition that is tested continuously, you can typically
analy(e the situation to see when to test the condition at discrete points in time.
Sending and Receiving Events
'ignal events and call events involve at least two objects$
)he object that sends the signal or invokes the operation
)he object to which the event is directed.
Any instance of any class can send a signal to or invoke an operation of a receiving object.
*hen an object sends a signal, the sender dispatches the signal and then continues along its
ow of control, not waiting for any return from the receiver.
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 rende(vous%assignation& for the duration of the
operation.
)his means that the ow of control of the sender is put in lock step with the ow of control of the
receiver until the activity of the operation is carried out.
If this is a signal, then the sender and receiver do not rende(vous$ the sender dispatches the
signal but does not wait for a response from the receiver. In either case, this event may be lost
In the !"#, you model the named signals that an object may receive by naming them in an
extra compartment of the class
Signals and Active Classes
Common Modeling Techniques
Modeling a Family of Signals
In most event2driven systems, signal events are hierarchical.
External and internal signals need not be disjoint, however. Even within these two broad
classifcations, you might fnd speciali(ations
)o model a family of signals
3onsider all the di4erent kinds of signals to which a given set of active objects may
respond.
#ook for the common kinds of signals and place them in a generali(ation5speciali(ation
hierarchy using inheritance. Elevate more general ones and lower more speciali(ed
ones.
#ook for the opportunity for polymorphism in the state machines of these active objects.
*here you fnd polymorphism, adjust the hierarchy as necessary by introducing
intermediate abstract signals.
Modeling Exceptions
An important part of visuali(ing, specifying, and documenting the behavior of a class or an
interface is specifying the exceptions that its operations can raise.
In the !"#, exceptions are kinds of signals, which you model as stereotyped classes. Exceptions
may be attached to specifcation operations.
"odeling exceptions is somewhat the inverse of modeling a general family of signals.
*e model a family of signals primarily to specify the kinds of signals an active object may
receive
*e model exceptions primarily to specify the kinds of exceptions that an object may throw
through its operations
)o model exceptions
o 6or each class and interface, and for each operation of such elements, consider the
exceptional conditions that may be raised.
o Arrange these exceptions in a hierarchy. Elevate general ones, lower speciali(ed ones,
and introduce intermediate exceptions, as necessary.
o 6or each operation, specify the exceptions that it may raise. -ou can do so explicitly %by
showing send dependencies from an operation to its exceptions& or you can put this in
the operation7s specifcation.
Modeling Exceptions
State Machines
A state machine is a behavior that specifes the se8uences of states an object goes through
during its lifetime in response to events, together with its responses to those events
A state is a condition or situation during the life of an object during which it satisfes some
condition, performs some activity, or waits for some event.
An event is the specifcation of a signifcant occurrence that has a location in time and space.
In the context of state machines, an event is an occurrence of a stimulus that can trigger a state
transition
A tansition is a relationship between two states indicating that an object in the frst state will
perform certain actions and enter the second state when a specifed event occurs and specifed
conditions are satisfed.
An activity is ongoing nonatomic execution within a state machine
An action is an executable atomic computation that results in a change in state of the model or
the return of a value
Context
Every object has a lifetime. 9n creation, an object is born: on destruction, an object ceases to
exist.
In between, an object may act on other objects %by sending them messages&, as well as be
acted on %by being the target of a message&.
In other kinds of systems, you7ll encounter objects that must respond to signals, which are
asynchronous stimuli communicated between instances.
)he behavior of objects that must respond to asynchronous stimulus or whose current behavior
depends on their past is best specifed by using a state machine
)his encompasses instances of classes that can receive signals, including many active objects.
In fact, an object that receives a signal but has no state machine will simply ignore that signal.
*e7ll also use state machines to model the behavior of entire systems, especially reactive
systems, which must respond to signals from actors outside the system.
States
A state is a condition or situation during the life of an object during which it satisfes some
condition, performs some activity, or waits for some event.
An object remains in a state for a fnite amount of time.
*hen an object7s state machine is in a given state, the object is said to be in that state. A state
has several parts.
/. ;ame A textual string that distinguishes the state from other states: a state may
be anonymous, meaning that it has no name
<. Entry5exit actions Actions executed on entering and exiting the state, respectively
=. Internal transitions )ransitions that are handled without causing a change in state
>. 'ubstates )he nested structure of a state, involving disjoint %se8uentially active& or
concurrent %concurrently active& substates
0. ?eferred events A list of events that are not handled in that state but, rather, are postponed
and 8ueued for handling by the object in another state
*e represent a state as a rectangle with rounded corners.
States
!nitial and Final States
)here are two special states that may be defned for an object7s state machine.
initial state, which indicates the default starting place for the state machine or substate.
An initial state is represented as a flled black circle
"nal state, which indicates that the execution of the state machine or the enclosing state has
been completed.
A fnal state is represented as a flled black circle surrounded by an unflled circle.
Tansitions
A tansition is a relationship between two states indicating that an object in the frst state will
perform certain actions and enter the second state when a specifed event occurs and specifed
conditions are satisfed.
9n such a change of state, the transition is said to fre. !ntil the transition fres, the object is
said to be in the source state: after it fres, it is said to be in the target state.
A transition has fve parts
/. 'ource state )he state a4ected by the transition: if an object is in the source state, an
outgoing transition may fre when the object receives the trigger event of the
transition and if the guard condition, if any, is satisfed
<. Event trigger )he event whose reception by the object in the source state makes the
transition eligible to fre, providing its guard condition is satisfed
=. @uard
condition
A ,oolean expression that is evaluated when the transition is triggered by the
reception of the event trigger: if the expression evaluates )rue, the transition is
eligible to fre: if the expression evaluates 6alse, the transition does not fre and
if there is no other transition that could be triggered by that same event, the
event is lost
>. Action An executable atomic computation that may directly act on the object that owns
the state machine, and indirectly on other objects that are visible to the object
0. )arget state )he state that is active after the completion of the transition
A transition is rendered as a solid directed line from the source to the target state.
A self2transition is a transition whose source and target states are the same.


Tansitions
Event Tigge
An event is the specifcation of a signifcant occurrence that has a location in time and space.
In the context of state machines, an event is an occurrence of a stimulus that can trigger a state
transition.
A signal or a call may have parameters whose values are available to the transition, including
expressions for the guard condition and action.
It is also possible to have a triggerless transition, represented by a transition with no event
trigger. A triggerless transitionAalso called a completion transitionAis triggered implicitly when
its source state has completed its activity.
#uad
A guard condition is rendered as a ,oolean expression enclosed in s8uare brackets and placed
after the trigger event.
A guard condition is evaluated only after the trigger event for its transition occurs. )herefore, it7s
possible to have multiple transitions from the same source state and with the same event
trigger, as long as those conditions don7t overlap.
A guard condition is evaluated just once for each transition at the time the event occurs, but it
may be evaluated again if the transition is retriggered. *ithin the ,oolean expression, you can
include conditions about the state of an object
Action
An action is an executable atomic computation. Actions may include operation calls &, the
creation or destruction of another object, or the sending of a signal to an object.
An action is atomic, meaning that it cannot be interrupted by an event and therefore runs to
completion.
Advanced States and Tansitions
Bowever, the !"#7s state machines have a number of advanced features that help you to
manage complex behavioral models.
)hese features often reduce the number of states and transitions you7ll need, and they codify a
number of common and somewhat complex idioms you7d otherwise encounter using at state
machines.
'ome of these advanced features include entry and exit actions, internal transitions, activities,
and deferred events
Enty and Exit Actions
In a number of modeling situations, you7ll want to dispatch the same action whenever you enter
a state, no matter which transition led you there. 'imilarly, when you leave a state, you7ll want
to dispatch the same action no matter which transition led you away.
!"# provides a shorthand for this idiom. In the symbol for the state, you can include an entry
action %marked by the keyword event entry& and an exit action %marked by the keyword event
exit&, together with an appropriate action.
*henever you enter the state, its entry action is dispatched: whenever you leave the state, its
exit action is dispatched.
Advanced States and Tansitions
!ntenal Tansitions
9nce inside a state, you7ll encounter events you7ll want to handle without leaving the state.
)hese are called intenal tansitions, and they are subtly di4erent from self2transitions.
In a self2transition an event triggers the transition, you leave the state, an action %if any& is
dispatched, and then you reenter the same state.
!"# provides a shorthand for this idiom, as well %for example, for the event new)arget&. In the
symbol for the state, you can include an internal transition %marked by an event&.
*henever you are in the state and that event is triggered, the corresponding action is
dispatched without leaving and then reentering the state.
)herefore, the event is handled without dispatching the state7s exit and then entry actions.
Activities
*hen an object is in a state, it generally sits idle, waiting for an event to occur.
'ometimes, however, you may wish to model an ongoing activity. *hile in a state, the object
does some work that will continue until it is interrupted by an event.
in the !"#, you use the special do transition to specify the work that7s to be done inside a state
after the entry action is dispatched. )he activity of a do transition might name another state
machine
-ou can also specify a se8uence of actionsAfor example, do 5 op/%a&: op<%b&: op=%c&.
Actions are never interruptible, but se8uences of actions are. In between each action %separated
by the semicolon&, events may be handled by the enclosing state, which results in transitioning
out of the state.
$efeed Events
In every modeling situation, you7ll want to recogni(e some events and ignore others. -ou include
those you want to recogni(e as the event triggers of transitions: those you want to ignore you
just leave out.
Bowever, in some modeling situations, you7ll want to recogni(e some events but postpone a
response to them until later.
In the !"#, you can specify this behavior by using deferred events.
A defeed event is a list of events whose occurrence in the state is postponed until a state in
which the listed events are not deferred becomes active, at which time they occur and may
trigger transitions as if they had just occurred.
Note$ )he implementation of deferred events re8uires the presence of an internal 8ueue of events.
If an event happens but is listed as deferred, it is 8ueued. Events are taken o4 this 8ueue as soon as
the object enters a state that does not defer these events.
Su%states
)here7s one more feature of the !"#7s state machinesAsubstatesAthat does even more to help
you simplify the modeling of complex behaviors
A simple state is a state that has no substructure.
A substate is a state that7s nested inside another one.
A state that has substatesA that is, nested statesAis called a composite state.
A composite state may contain either concurrent %orthogonal& or se8uential %disjoint& substates.
In the !"#, you render a composite state just as you do a simple state, but with an optional
graphic compartment that shows a nested state machine. 'ubstates may be nested to any level
Sequential Su%states
6riends better review text book for this concept.
&istoy States
A state machine describes the dynamic aspects of an object whose current behavior depends on
its past.
A state machine in e4ect specifes the legal ordering of states an object may go through during
its lifetime
*hen a transition enters a composite state, the action of the nested state machine starts over
again at its initial state.
Bowever, there are times you7d like to model an object so that it remembers the last substate
that was active prior to leaving the composite state. !sing at state machines, you can model
this, but it7s messy. 6or each se8uential substate, you7d need to have its exit action post a value
to some variable local to the composite state. )hen the initial state to this composite state
would need a transition to every substate with a guard condition, 8uerying the variable. )hat7s
messy because it re8uires you to remember to touch every substate and to set an appropriate
exit action. It leaves you with a multitude of transitions fanning out from the same initial state to
di4erent target substates with very similar %but di4erent& guard conditions.
In the !"#, a simpler way to model this idiom is by using history states.
A histoy state allows a composite state that contains se8uential substates to remember the
last substate that was active in it prior to the transition from the composite state
As 6igure shows, you represent a shallow history state as a small circle containing the symbol B.
&istoy State
If you want a transition to activate the last substate, you show a transition from outside the
composite state directly to the history state. )he frst time you enter a composite state, it has no
history.
In either case, if a nested state machine reaches a fnal state, it loses its stored history and
behaves as if it had not yet been entered for the frst time.
Concuent Su%states
'e8uential substates are the most common kind of nested state machine you7ll encounter. In
certain modeling situations, however, you7ll want to specify concurrent substates.
)hese substates let you specify two or more state machines that execute in parallel in the
context of the enclosing object.
Concuent Su%states
Execution of these two concurrent substates continues in parallel.
Eventually, each nested state machine reaches its fnal state. If one concurrent substate reaches
its fnal state before the other, control in that substate waits at its fnal state.
*hen both nested state machines reach their fnal state, control from the two concurrent
substates joins back into one ow.
*henever there7s a transition to a composite state decomposed into concurrent substates,
control forks into as many concurrent ows as there are concurrent substates. 'imilarly,
whenever there7s a transition from a composite substate decomposed into concurrent substates,
control joins back into one ow.
)his holds true in all cases. If all concurrent substates reach their fnal state, or if there is an
explicit transition out of the enclosing composite state, control joins back into one ow.
Note' A nested concurrent state machine does not have an initial, fnal, or history state. Bowever,
the se8uential substates that compose a concurrent state may have these features.
Common Modeling Techniques
Modeling the (ifetime of an )%*ect
*hen you model the lifetime of an object, you essentially specify three things$ the events to
which the object can respond, the response to those events, and the impact of the past on
current behavior.
"odeling the lifetime of an object also involves deciding on the order in which the object can
meaningfully respond to events, starting at the time of the object7s creation and continuing until
its destruction
)o model the lifetime of an object,
o 'et the context for the state machine, whether it is a class, a use case, or the system as
a whole.
/. If the context is a class or a use case, collect the neighboring classes, including any
parents of the class and any classes reachable by associations or dependences.
)hese neighbors are candidate targets for actions and are candidates for including
in guard conditions.
2. If the context is the system as a whole, narrow your focus to one behavior of the
system. )heoretically, every object in the system may be a participant in a model of
the system7s lifetime, and except for the most trivial systems, a complete model
would be intractable.
o Establish the initial and fnal states for the object. )o guide the rest of your model,
possibly state the pre2 and postconditions of the initial and fnal states, respectively.
o ?ecide on the events to which this object may respond. If already specifed, you7ll fnd
these in the object7s interfaces: if not already specifed, you7ll have to consider which
objects may interact with the object in your context, and then which events they may
possibly dispatch.
o 'tarting from the initial state to the fnal state, lay out the top2level states the object
may be in. 3onnect these states with transitions triggered by the appropriate events.
3ontinue by adding actions to these transitions.
o Identify any entry or exit actions %especially if you fnd that the idiom they cover is used
in the state machine&.
o Expand these states as necessary by using substates.
o 3heck that all events mentioned in the state machine match events expected by the
interface of the object. 'imilarly, check that all events expected by the interface of the
object are handled by the state machine. 6inally, look to places where you explicitly
want to ignore events.
o 3heck that all actions mentioned in the state machine are sustained by the
relationships, methods, and operations of the enclosing object.
o )race through the state machine, either manually or by using tools, to check it against
expected se8uences of events and their responses. ,e especially diligent in looking for
unreachable states and states in which the machine may get stuck.
o After rearranging your state machine, check it against expected se8uences again to
ensure that you have not changed the object7s semantics.
+ocesses and Theads
An active o%*ect is an object that owns a process or thread and can initiate control activity.
An active class is a class whose instances are active objects
A pocess is a heavyweight ow that can execute concurrently with other processes.
A thead is a lightweight ow that can execute concurrently with other threads within the same
process.
@raphically, an active class is rendered as a rectangle with thick lines.
Crocesses and threads are rendered as stereotyped active classes
Flo, of Contol
In a purely se8uential system, there is one ow of control. )his means that one thing, and one
thing only, can take place at a time. *hen a se8uential program starts, control is rooted at the
beginning of the program and operations are dispatched one after another.
A se8uential program will process only one event at a time, 8ueuing or discarding any
concurrent external events.
In a concurrent system, there is more than one ow of controlAthat is, more than one thing can
take place at a time.
In a concurrent system, there are multiple simultaneous ows of control, each rooted at the
head of an independent process or a thread.
If you take a snapshot of a concurrent system while it7s running, you7ll logically see multiple loci
of execution.
Note' -ou can achieve true concurrency in one of three ways$
,y distributing active objects across multiple nodes
,y placing active objects on nodes with multiple processors
,y a combination of both methods.
Classes and Events
Active classes are just classes, albeit ones with a very special property. An active class
represents an independent ow of control, whereas a plain class embodies no such ow.
-ou use active classes to model common families of processes or threads.
,y modeling concurrent systems with active objects, you give a name to each independent ow
of control.
o *hen an active object is created, the associated ow of control is started:
o *hen the active object is destroyed, the associated ow of control is terminated.
Active classes share the same properties as all other classes.
Active classes may have instances.
Active classes may have attributes and operations.
Active classes may participate in dependency, generali(ation, and association relationships.
Active classes may use any of the !"#7s extensibility mechanisms, including stereotypes,
tagged values, and constraints.
Active classes may be the reali(ation of interfaces.
Active classes may be reali(ed by collaborations, and the behavior of an active class may be
specifed by using state machines
Standad Elements
All of the !"#7s extensibility mechanisms apply to active classes. "ost often, you7ll use tagged
values to extend active class properties.
)he !"# defnes two standard stereotypes that apply to active classes.
/.
process
'pecifes a heavyweight ow that can execute concurrently with other processes
<. thread 'pecifes a lightweight ow that can execute concurrently with other threads within the
same process
A process is heavyweight, Each program runs as a process in its own address space
Crocesses are never nested inside one another. If the node has multiple processors, then true
concurrency on that node is possible.
If the node has only one processor, there is only the illusion of true concurrency, carried out by
the underlying operating system.
A thread is lightweight. the threads that live in the context of a process are peers of one
another, contending for the same resources accessible inside the process.
)hreads are never nested inside one another.
Communication
*hen objects collaborate with one another, they interact by passing messages from one to the
other. In a system with both active and passive objects, there are four possible combinations of
interaction that you must consider
/. A message may be passed from one passive object to another. Assuming there is only
one ow of control passing through these objects at a time, such an interaction is
nothing more than the simple invocation of an operation.
<. A message may be passed from one active object to another. *hen that happens, you
have interprocess communication, and there are two possible styles of communication
/.& 9ne active object might synchronously call an operation of another.
<.& 9ne active object might asynchronously send a signal or call an operation of
another object
)hat kind of communication has mailbox semantics
In the !"#, we render a synchronous message as a full arrow and an asynchronous message as
a half arrow
Communication
=. A message may be passed from an active object to a passive object. A diDculty arises if
more than
one active object at a time passes their ow of control through one passive object. In
that situation,
you have to model the synchroni(ation of these two ows very carefully.
>. A message may be passed from a passive object to an active one. At frst glance, this
may seem illegal, but if you remember that every ow of control is rooted in some
active object, you7ll understand that a passive object passing a message to an active
object has the same semantics as an active object passing a message to an active
object.
Synchoni-ation
)he problem arises when more than one ow of control is in one object at the same time. If you
are not careful, anything more than one ow will interfere with another, corrupting the state of
the object
)his is the classical problem of mutual exclusion. )he key to solving this problem in object2
oriented systems is by treating an object as a critical region.
)here are three alternatives to this approach, each of which involves attaching certain
synchroni(ation properties to the operations defned in a class. In the !"#, you can model all
three approaches.
/. 'e8uential 3allers must coordinate outside the object so that only one ow is in the object at a
time. In the presence of multiple ows of control, the semantics and integrity of the
object cannot be guaranteed.
<. @uarded )he semantics and integrity of the object is guaranteed in the presence of multiple
ows of control by se8uentiali(ing all calls to all of the object7s guarded operations.
In e4ect, exactly one operation at a time can be invoked on the object, reducing this
to se8uential semantics.
=.
3oncurrent
)he semantics and integrity of the object is guaranteed in the presence of multiple
ows of control by treating the operation as atomic

Synchoni-ation
+ocess .ie,s
Active objects play an important role in visuali(ing, specifying, constructing, and documenting a
system7s process view.
)he process view of a system encompasses the threads and processes that form the system7s
concurrency and synchroni(ation mechanisms.
)his view primarily addresses the performance, scalability, and throughput of the system. *ith
the !"#, the static and dynamic aspects of this view are captured in the same kinds of diagrams
as for the design viewAthat is, class diagrams, interaction diagrams, activity diagrams, and
statechart diagrams,
,ut with a focus on the active classes that represent these threads and processes.
www.jntuworld.com