OOAD

UNIT-5

Events and Signals

 An event is the specification of a significant 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 specification 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.
Example: Pushing button

 Internal events are those that pass among the objects that live inside the system.
Example: An overflow exception.

 In the UML, 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..
 Signals may also be involved in generalization relationships, permitting you to model hierarchies
of events, some of which are general and some of which are specific
 Also as for classes, signals may have attributes and operations.

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 synchronous
 This 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.

Prepared by T. SIVA RAMA KRISHNA, M TECH 1

 OOAD

Time and Change Events

 A time event is an event that represents the passage of time

 in the UML you model a time event by using the keyword after followed by some expression that
evaluates to a period of time.
 A change event is an event that represents a change in state or the satisfaction of some
condition
 In the UML you model a change event by using the keyword when followed by some Boolean
expression

Sending and Receiving Events

 Signal events and call events involve at least two objects:

 The object that sends the signal or invokes the operation
 The 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.
 When an object sends a signal, the sender dispatches the signal and then continues along its
flow 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 rendezvous(assignation) for the duration of the
operation.
 This means that the flow of control of the sender is put in lock step with the flow 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 rendezvous: 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 UML, you model the named signals that an object may receive by naming them in an extra
compartment of the class
Common Modeling Techniques

To model a family of signals,

 Consider all the different kinds of signals to which a given set of active objects may respond.
 Look for the common kinds of signals and place them in a generalization/specialization
hierarchy using inheritance. Elevate more general ones and lower more specialized ones.

Prepared by T. SIVA RAMA KRISHNA, M TECH 2

 OOAD
 Look for the opportunity for polymorphism in the state machines of these active objects.
Where you find polymorphism, adjust the hierarchy as necessary by introducing
intermediate abstract signals.

To model exceptions,

 For each class and interface, and for each operation of such elements, consider the
exceptional conditions that may be raised.
 Arrange these exceptions in a hierarchy. Elevate general ones, lower specialized ones,
and introduce intermediate exceptions, as necessary.
 For each operation, specify the exceptions that it may raise. You can do so explicitly (by
showing send dependencies from an operation to its exceptions) or you can put this in
the operation's specification.

Prepared by T. SIVA RAMA KRISHNA, M TECH 3

 OOAD

State Machines
 A state machine is a behavior that specifies the sequences 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 satisfies some
condition, performs some activity, or waits for some event.
 An event is the specification of a significant 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 transition is a relationship between two states indicating that an object in the first state will
perform certain actions and enter the second state when a specified event occurs and specified
conditions are satisfied.
 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. On 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, you'll encounter objects that must respond to signals, which are
asynchronous stimuli communicated between instances.
 The behavior of objects that must respond to asynchronous stimulus or whose current behavior
depends on their past is best specified by using a state machine
 This 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.
 We'll 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 satisfies some
condition, performs some activity, or waits for some event.
 An object remains in a state for a finite amount of time.
 When an object's state machine is in a given state, the object is said to be in that state.
A state has several parts.

1. Name A textual string that distinguishes the state from other states; a state
may be anonymous, meaning that it has no name

2. Entry/exit actions Actions executed on entering and exiting the state, respectively

3. Internal Transitions that are handled without causing a change in state

transitions

4. Substates The nested structure of a state, involving disjoint (sequentially active) or

concurrent (concurrently active) substates

Prepared by T. SIVA RAMA KRISHNA, M TECH 4

 OOAD
5. Deferred events A list of events that are not handled in that state but, rather, are
postponed and queued for handling by the object in another state

We represent a state as a rectangle with rounded corners.

Initial and Final States

There are two special states that may be defined for an object's state machine.

 initial state, which indicates the default starting place for the state machine or substate.
 An initial state is represented as a filled black circle
 final state, which indicates that the execution of the state machine or the enclosing state has
been completed.
 A final state is represented as a filled black circle surrounded by an unfilled circle.
Transitions
 A transition is a relationship between two states indicating that an object in the first state will
perform certain actions and enter the second state when a specified event occurs and specified
conditions are satisfied.
 On such a change of state, the transition is said to fire. Until the transition fires, the object is said
to be in the source state; after it fires, it is said to be in the target state.
 A transition has five parts
1. Source state The state affected by the transition; if an object is in the source state, an
outgoing transition may fire when the object receives the trigger event of the
transition and if the guard condition, if any, is satisfied

2. Event trigger The event whose reception by the object in the source state makes the
transition eligible to fire, providing its guard condition is satisfied

3. Guard A Boolean expression that is evaluated when the transition is triggered by

condition the reception of the event trigger; if the expression evaluates True, the
transition is eligible to fire; if the expression evaluates False, the transition
does not fire and if there is no other transition that could be triggered by
that same event, the event is lost

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

5. Target state The state that is active after the completion of the transition

Prepared by T. SIVA RAMA KRISHNA, M TECH 5

 OOAD

 A transition is rendered as a solid directed line from the source to the target state.
 A self-transition is a transition whose source and target states are the same.

Event Trigger

 An event is the specification of a significant 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.
Guard

 A guard condition is rendered as a Boolean expression enclosed in square brackets and placed
after the trigger event.
 A guard condition is evaluated only after the trigger event for its transition occurs. Therefore, it's
possible to have multiple transitions from the same source state and with the same event
trigger, as long as those conditions don't 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. Within the Boolean 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 Transitions
 However, the UML's state machines have a number of advanced features that help you to
manage complex behavioral models.
 These features often reduce the number of states and transitions you'll need, and they codify a
number of common and somewhat complex idioms you'd otherwise encounter using flat state
machines.
 Some of these advanced features include entry and exit actions, internal transitions, activities,
and deferred events

Prepared by T. SIVA RAMA KRISHNA, M TECH 6

 OOAD

Entry and Exit Actions

 UML provides an entry action (marked by the keyword event entry) and an exit action (marked
by the keyword event exit), together with an appropriate action.
 Whenever you enter the state, its entry action is dispatched; whenever you leave the state, its
exit action is dispatched.

Internal Transitions

 Once inside a state, you'll encounter events you'll want to handle without leaving the state.
These are called internal transitions, and they are subtly different from self-transitions.
 UML provides a shorthand for this idiom, as well (for example, for the event newTarget). In the
symbol for the state, you can include an internal transition (marked by an event).
 Whenever you are in the state and that event is triggered, the corresponding action is
dispatched without leaving and then reentering the state.
 Therefore, the event is handled without dispatching the state's exit and then entry actions.
Activities

 When an object is in a state, it generally sits idle, waiting for an event to occur.
 Sometimes, however, you may wish to model an ongoing activity. While in a state, the object
does some work that will continue until it is interrupted by an event.
 in the UML, you use the special do transition to specify the work that's to be done inside a state
after the entry action is dispatched. The activity of a do transition might name another state
machine
Deferred Events

 A deferred 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.
Substates
 There's one more feature of the UML's state machines—substates—that 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 that's nested inside another one.
 A state that has substates— that is, nested states—is called a composite state.
 A composite state may contain either concurrent (orthogonal) or sequential (disjoint) substates.

Prepared by T. SIVA RAMA KRISHNA, M TECH 7

 OOAD

Sequential Substates

States are executed in sequential manner

History States

 A state machine describes the dynamic aspects of an object whose current behavior depends on
its past.
 A history state allows a composite state that contains sequential substates to remember the last
substate that was active in it prior to the transition from the composite state
 As Figure shows, you represent a shallow history state as a small circle containing the symbol H.

Concurrent Substates

 Sequential substates are the most common kind of nested state machine you'll encounter. In
certain modeling situations, however, you'll want to specify concurrent substates.
 These substates let you specify two or more state machines that execute in parallel in the
context of the enclosing object.

Prepared by T. SIVA RAMA KRISHNA, M TECH 8

 OOAD

 Execution of these two concurrent substates continues in parallel.

 Eventually, each nested state machine reaches its final state. If one concurrent substate reaches
its final state before the other, control in that substate waits at its final state.
 When both nested state machines reach their final state, control from the two concurrent
substates joins back into one flow.
 Whenever there's a transition to a composite state decomposed into concurrent substates,
control forks into as many concurrent flows as there are concurrent substates. Similarly,
whenever there's a transition from a composite substate decomposed into concurrent
substates, control joins back into one flow.
 This holds true in all cases. If all concurrent substates reach their final state, or if there is an
explicit transition out of the enclosing composite state, control joins back into one flow.
Common Modeling Techniques
Modeling the Lifetime of an Object

Set the context for the state machine, whether it is a class, a use case, or the system as a whole.

1. 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. These 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.
Theoretically, every object in the system may be a participant in a model of the system's lifetime,
and except for the most trivial systems, a complete model would be intractable.

3. Establish the initial and final states for the object. To guide the rest of your model,possibly state
the pre- and postconditions of the initial and final states, respectively.

4. Decide on the events to which this object may respond. If already specified, you'll find these in
the object's interfaces; if not already specified, you'll have to consider which objects may interact
with the object in your context, and then which events they may possibly dispatch.

Prepared by T. SIVA RAMA KRISHNA, M TECH 9

 OOAD
5. Starting from the initial state to the final state, lay out the top-level states the object may be in.
Connect these states with transitions triggered by the appropriate events. Continue by adding
actions to these transitions.

6. Identify any entry or exit actions (especially if you find that the idiom they cover is used in the
state machine).

7. Expand these states as necessary by using substates.

8. Check that all events mentioned in the state machine match events expected by the interface of
the object. Similarly, check that all events expected by the interface of the object are handled by the
state machine. Finally, look to places where you explicitly want to ignore events.

9. Check that all actions mentioned in the state machine are sustained by the relationships,
methods, and operations of the enclosing object.

10. Trace through the state machine, either manually or by using tools, to check it against expected
sequences of events and their responses. Be especially diligent in looking for unreachable states and
states in which the machine may get stuck.

11. After rearranging your state machine, check it against expected sequences again to ensure that
you have not changed the object's semantics.

Prepared by T. SIVA RAMA KRISHNA, M TECH 10

 OOAD

Processes and Threads

A process is a heavyweight flow that can execute concurrently with other processes.

A thread is a lightweight flow that can execute concurrently with other threads within the same
process.

An active object 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.

Graphically, an active class is rendered as a rectangle with thick lines. Processes and threads are
rendered as stereotyped active classes.

Flow of Control
There are two flows of controls that are Sequential and Concurrent.

In a sequential system, there is a single flow of control. i.e, one thing, and one thing only, can take
place at a time.

When a sequential program starts, control is rooted at the beginning of the program and operations
are dispatched one after another. Even if there are concurrent things happening among the actors
outside the system, a sequential program will process only one event at a time, queuing or
discarding any concurrent external events.

In a concurrent system, there is multiple simultaneous flow of control i.e, more than one thing can
take place at a time, each rooted at the head of an independent process or a thread. If you take a
snapshot of a concurrent system while it's running, you'll logically see multiple loci of execution. In
the UML, you use an active class to represent a process or thread that is the root of an independent
flow of control and that is concurrent with all peer flows of control.

Classes and Events

Prepared by T. SIVA RAMA KRISHNA, M TECH 11

 OOAD
Active classes are just classes which represents an independent flow of control. Active classes share
the same properties as all other classes.

When an active object is created, the associated flow of control is started; when the active object is
destroyed, the associated flow 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, generalization, and association (including aggregation) relationships. Active classes may
use any of the UML's extensibility mechanisms, including stereotypes, tagged values, and
constraints. Active classes may be the realization of interfaces. Active classes may be realized by
collaborations, and the behavior of an active class may be specified by using state machines.

Standard Elements:
Two standard stereotypes that apply to active classes are,

<<process>> -- Specifies a heavyweight flow that can execute concurrently with other

processes. (heavyweight means, a thing known to the OS itself and runs in an independent address
space)

<<thread>> – Specifies a lightweight flow that can execute concurrently with other threads within
the same process (lightweight means, known to the OS itself.)

All the threads that live in the context of a process are peers of one another.

A process is heavyweight, which means that it is a thing known to the operating system itself and
runs in an independent address space. Under most operating systems, such as Windows and Unix,
each program runs as a process in its own address space. In general, all processes on a node are
peers of one another, contending for all the same resources accessible on the node.

Processes 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. It may be known to the operating system itself. More often, it is hidden
inside a heavier-weight process and runs inside the address space of the enclosing process. In Java,
for example, a thread is a child of the class Thread. All the threads that live in the context of a
process are peers of one another, contending for the same resources accessible inside the process.
Threads are never nested inside one another. In general, there is only the illusion of true
concurrency among threads because it is processes, not threads, that are scheduled by a node's
operating system.

Communication

Prepared by T. SIVA RAMA KRISHNA, M TECH 12

 OOAD
When 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

First, a message may be passed from one passive object to another

Second, a message may be passed from one active object to another

In inter-process communication there are two possible styles of communication.

1)one active object might synchronously call an operation of another.

2)one active object might asynchronously send a signal or call an operation of another

object a synchronous message is rendered as a full arrow and an asynchronous message is rendered
as a half arrow.

Third, a message may be passed from an active object to a passive object

Fourth, a message may be passed from a passive object to an active one

Synchroniz
ation
Synchronization means arranging the flow of controls of objects so that mutual exclusion will be
guaranteed.

In object-oriented systems these objects are treated as a critical region.

Three approaches are there to handle synchronization:

1. Sequential – Callers must coordinate outside the object so that only one flow is in the object at a
time

2. Guarded – multiple flow of control is sequentialized with the help of object’s guarded operations.
in effect it becomes sequential.

Prepared by T. SIVA RAMA KRISHNA, M TECH 13

 OOAD
3. Concurrent – multiple flow of control is guaranteed by treating each operation as atomic.
synchronization are rendered in the operations of active classes with the help of constraints .

Process
Views
The process view of a system encompasses the threads and processes that form the system’s
concurrency and synchronization mechanisms.

This view primarily addresses the performance, scalability, and throughput of the system.

Common modeling Techniques

1.Modeling Multiple Flows of Control

2.Modeling Interprocess Communication

Statechart diagram
Terms and Concepts

A statechart diagram shows a state machine, emphasizing the flow of control from state to state.

A state machine is a behavior that specifies the sequences 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 in the life of an object during which it satisfies some condition,
performs some activity, or waits for some event.

An event is the specification of a significant 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 transition is a relationship between two states indicating that an object in the first state will
perform certain actions and enter the second state when a specified event occurs and specified
conditions are satisfied.

An activity is ongoing non atomic execution within a state machine.

Prepared by T. SIVA RAMA KRISHNA, M TECH 14

 OOAD
An action is an executable atomic computation that results in a change in state of the model or the
return of a value.

Graphically, a statechart diagram is a collection of vertices and arcs.

Common Properties
A statechart diagram is just a special kind of diagram and shares the same common properties as do
all other diagrams• that is, a name and graphical contents that are a projection into a model. What
distinguishes a statechart diagram from all other kinds of diagrams is its content.

Contents
Statechart diagrams commonly contain

· Simple states and composite states

· Transitions, including events and actions

Like all other diagrams, statechart diagrams may contain notes and constraints.

Common Uses

You use statechart diagrams to model the dynamic aspects of a system. These dynamic aspects may
involve the event-ordered behavior of any kind of object in any view of a system's architecture,
including classes (which includes active classes), interfaces, components, and nodes.

When you model the dynamic aspects of a system, a class, or a use case, you'll typically use
statechart diagrams in one way.

Prepared by T. SIVA RAMA KRISHNA, M TECH 15

 OOAD

To model reactive objects

A reactive — or event-driven — object is one whose behavior is best characterized by its response to
events dispatched from outside its context. A reactive object is typically idle until it receives an
event. When it receives an event, its response usually depends on previous events. After the object
responds to an event, it becomes idle again, waiting for the next event. For these kinds of objects,
you'll focus on the stable states of that object, the events that trigger a transition from state to state,
and the actions that occur on each state change.

To model a reactive object,

1. Choose the context for the state machine, whether it is a class, a use case, or the system as a

whole.
2. Choose the initial and final states for the object. possibly state the pre- and post conditions of
the initial and final states, respectively.

3. Decide on the stable states of the object

4 .Decide on the meaningful partial ordering of stable states over the lifetime of the object.

5. Decide on the events that may trigger a transition from state to state. Model these

events as triggers to transitions that move from one legal ordering of states to another.

6. Attach actions to these transitions

7. Consider ways to simplify your machine by using substates, branches, forks, joins,
and history states.

8. Check that all states are reachable under some combination of events.

9 . Trace through the state machine, either manually or by using tools, to check it against

expected sequences of events and their responses.

Prepared by T. SIVA RAMA KRISHNA, M TECH 16

 OOAD

Prepared by T. SIVA RAMA KRISHNA, M TECH 17