UNIT - II

Basic Behavioral Modeling

In UML, the dynamic aspects of a system can be modeled using interactions.

Interactions contain messages that are exchanged between objects. A message
can be an invocation of an operation or a signal. The messages may also include
creation and destruction of other objects.

Graphically a message is rendered as a directed line with the name of its

operation as show below:
An interaction is a behavior that contains a set of messages exchanged among a
set of objects within a context to accomplish a purpose.

Objects and Roles

The objects that participate in an interaction are either concrete things or

prototypical things. As a concrete thing, an object represents something in the real
world. For example, p an instance of the class Person, might denote a particular
human. Alternately, as a prototypical thing, p might represent any instance of
Person.

Links

A link is a semantic connection among objects. In general, a link is an instance of

association. Wherever, a class has an association with another class, there may be a
link between the instances of the two classes.
Messages

A message is the specification of communication among objects that conveys

information with the expectation that activity will succeed. The receipt of a
message instance may be considered an instance of an event
Sequencing

When an object passes a message to another object, the receiving object might
in turn send a message to another object, which might send a message to yet a
different object and so on.

This stream of messages forms a sequence. So, we can define a sequence as a

stream of messages. Any sequence must have a beginning. The start of every
sequence is associated with some process or thread.
Representation

When we model an interaction, we typically include both objects and messages. We

can visualize those objects and messages involved in an interaction in two ways: by
emphasizing the time ordering of messages and by emphasizing the structural
organization of the objects that send and receive messages.

In UML, the first kind of representation is called a sequence diagram and the second
kind of representation is called a collaboration diagram. Both sequence and
collaboration diagrams are known as interaction diagrams.
Interaction Diagrams

Terms and Concepts

An interaction diagram shows an interaction, consisting of a set of objects and their

relationships, including the messages that may be dispatched among them. A
sequence diagram is an interaction diagram that emphasizes the time ordering of
messages. Graphically, a sequence diagram is a table that shows objects arranged
along the X axis and messages, ordered in increasing time, along the Y axis. A
collaboration diagram is an interaction diagram that emphasizes the structural
organization of the objects that send and receive messages.

Interaction diagrams commonly contain

· Objects
· Links
· Messages
Sequence Diagrams
A sequence diagram emphasizes the time ordering of messages. As Figure 18-2
shows, you form a sequence diagram by first placing the objects that participate in
the interaction at the top of your diagram, across the X axis. Typically, you place the
object that initiates the interaction at the left, and increasingly more subordinate
objects to the right. Next, you place the messages that these objects send and
receive along the Y axis, in order of increasing time from top to bottom.
This gives the reader a clear visual cue to the flow of control over time.

Sequence diagrams have two features that distinguish them from collaboration
diagrams.
First, there is the object lifeline. An object lifeline is the vertical dashed line that
represents the existence of an object over a period of time. Most objects that
appear in an interaction diagram will be in existence for the duration of the
interaction, so these objects are all aligned at the top of the diagram, with their
lifelines drawn from the top of the diagram to the bottom.

Second, there is the focus of control. The focus of control is a tall, thin rectangle that
shows the period of time during which an object is performing an action, either
directly or through a subordinate procedure. The top of the rectangle is aligned with
the start of the action; the bottom is aligned with its completion (and can be marked
by a return message).
Collaboration Diagrams

A collaboration diagram emphasizes the organization of the objects that

participate in an interaction

you form a collaboration diagram by first placing the objects

that participate in the interaction as the vertices in a graph. Next, you render the
links that connect these objects as the arcs of this graph. Finally, you adorn these
links with the messages that objects send and receive. This gives the reader a
clear visual cue to the flow of control in the context of the structural organization
of objects that collaborate.
First, there is the path. To indicate how one object is linked to another, you can attach a
path stereotype to the far end of a link (such as <<local>> indicating that the designated
object is local to the sender).

Second, there is the sequence number. To indicate the time order of a message, you
prefix the message with a number (starting with the message numbered 1), increasing
monotonically for each new message in the flow of control (2, 3, and so on). To show
nesting, you use Dewey decimal numbering (1 is the first message; 1.1 is the first
message nested in message 1; 1.2 the second message nested in message 1; and so on).
 Use Cases

No system exists in isolation. Every interesting system interacts with human or

automated actors that use that system for some purpose, and those actors expect
that system to behave in predictable ways. A use case specifies the behavior of a
system or a part of a system and is a description of a set of sequences of actions,
including variants, that a system performs to yield an observable result of value to
an actor.

Use cases provide a way for your developers to come to a common understanding
with your system's end users and domain experts.

For example, you can specify how an ATM system should behave by stating in use
cases how users interact with the system; you don't need to know anything about the
inside of the ATM at all. Use cases specify desired behavior, they do not dictate how
that behavior will be carried out.
Use Cases and Actors
Typically, an actor represents a role that a human, a hardware device, or even
another system plays with a system. For example, if you work for a bank, you might
be a LoanOfficer. If you do your personal banking there, as well, you'll also play the
role of Customer. An instance of an actor, therefore, represents an individual
interacting with the system in a specific way.
You can define general kinds of actors (such as Customer) and specialize them (such
as CommercialCustomer) using generalization relationships.
Actors may be connected to use cases only by association. An association between
an actor and a use case indicates that the actor and the use case communicate
with one another, each one possibly sending and receiving messages.

Main flow of events:

The use case starts when the system prompts the Customer for a PIN number.
The Customer can now enter a PIN number via the keypad. The Customer
commits the entry by pressing the Enter button. The system then checks this PIN
number to see if it is valid. If the PIN number is valid, the system acknowledges
the entry, thus ending the use case.
Exceptional flow of events:
The Customer can cancel a transaction at any time by pressing the Cancel
button, thus restarting the use case. No changes are made to the Customer's
account.
Exceptional flow of events:
The Customer can clear a PIN number anytime before committing it and reenter
a new PIN number.
 Use Case Diagrams

Use case diagrams are one of the five diagrams in the UML for modeling the
dynamic aspects of systems (activity diagrams, statechart diagrams, sequence
diagrams, and collaboration diagrams are four other kinds of diagrams in the UML
for modeling the dynamic aspects of systems).

Each one shows a set of use cases and actors and their relationships.

Use case diagrams commonly contain

· Use cases
· Actors
· Dependency, generalization, and association relationships
 Activity Diagrams

Activity diagrams are one of the five diagrams in the UML for modeling the
dynamic aspects of systems. An activity diagram is essentially a flowchart,
showing flow of control from activity to activity.

Interaction diagrams emphasize the flow of control from object to object, activity
diagrams emphasize the flow of control from activity to activity.

Activities ultimately result in some action, which is made up of executable

atomic computations that results in a change in state of the system or the return
of a value.
Activity diagrams commonly contain
· Activity states and action states
· Transitions
· Objects

Alternately, you might call an operation on an object, send a signal to an object, or

even create or destroy an object.
These executable, atomic computations are called action states because they are
states of the system, each representing the execution of an action.
Activity state as a composite, whose flow of control is made up of other activity
states and action states.

There's no notational distinction between action and activity states, except that
an activity state may have additional parts, such as entry and exit actions (actions
which are involved on entering and leaving the state, respectively) and
submachine specifications.
When the action or activity of a state completes, flow of control passes immediately
to the next action or activity state. You specify this flow by using transitions to show
the path from one action or activity state to the next action or activity state. In the
UML, you represent a transition as a simple directed line
Indeed, a flow of control has to start and end someplace (unless, of course, it's an
infinite flow, in which case it will have a beginning but no end). Therefore, as the
figure shows, you may specify this initial state (a solid ball) and stop state (a solid
ball inside a circle).
Advanced Behavioral Modeling

In state machines (sequence of states), we use events to model the

occurrence of a stimulus that can trigger an object to move from one state to
another state. Events may include signals, calls, the passage of time or a
change in state.

In UML, each thing that happens is modeled as an event. An event is the

specification of a significant occurrence that has a location in time and space. A
signal, passing of time and change in state are asynchronous events. Calls are
generally synchronous events, representing invocation of an operation.

UML allows us to represent events graphically as shown. Signals may be

represented as stereotyped classes and other events are represented as
messages associated with transitions which cause an object to move from one
state to another.
Types of Events

Events may be external or internal. Events passed between the system and
its actors are external events. For example, in an ATM system, pushing a
button or inserting a card are external events. Internal events are those that
are passed among objects living inside the system. For example, a overflow
exception generated by an object is an internal event.

In the UML, you can model four kinds of events:

signals,
calls,
the passing of time,
and a change in state
Signals

A signal is a named object that is sent asynchronously by one object and then
received by another. Exceptions are the famous examples for signals. A signal
may be sent as the action of a state in a state machine or as a message in an
interaction. The execution of an operation can also send signals.

In UML, we model the relationship between an operation and the events

using a dependency stereotyped with “send”, which indicates that an
operation sends a particular signal.
Call Events

A call event represents the dispatch of an operation from one object to another.
A call event may trigger a state change in a state machine. A call event, in
general, is synchronous.

This means that the sender object must wait until it gets an acknowledgment
from the receiver object which receives the call event. For example, consider
the states of a customer in an ATM application:
Time and Change Events

A time event represents the passage of time. In UML, we model the time event
using the “after” keyword followed by an expression that evaluates a period of
time.

A change event represents an event that represents a change in state or the

satisfaction of some condition. In UML, change event is modeled using the
keyword “when” followed by some Boolean expression.
State Machines

Using an interaction, you can model the behavior of a society of objects that
work together. Using a state machine, you can model the behavior of an
individual object. 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 machine models the lifetime of a single object, whether it is an instance

of a class, a use case, or even an entire system
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.

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. For example, a Heater in a
home might be in any of four states: Idle (waiting for a command to start heating
the house), Activating (its gas is on, but it's waiting to come up to temperature),
Active (its gas and blower are both on), and ShuttingDown (its gas is off but
its blower is on, flushing residual heat from the system).
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
Transitions that are handled without causing a change in state

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

active) or concurrent (concurrently active) substates
Initial and Final States
As the figure shows, there are two special states that may be defined for an
object's state machine. First, there's the initial state, which indicates the default
starting place for the state machine or substate. An initial state is represented as
a filled black circle. Second, there's the 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 unfilledcircle.
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. For
example, a Heater might transition from the Idle to the Activating state when an
event such as tooCold (with the parameter desiredTemp) occurs.
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 condition
A Boolean expression that is evaluated when the transition is triggered by 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
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
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.
In a concurrent system, there is multiple simultaneous flow of control i.e, more than one
thing can take place at a time.

Classes and Events

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
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
Communication
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. First,
one active object might synchronously call an operation of another. Second, 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
Synchronization
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:

Sequential – Callers must coordinate outside the object so that only one flow is in the
object at a time
Guarded – multiple flow of control is sequentialized with the help of object’s guarded
operations. in effect it becomes sequential.
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
 A Statechart diagram describes a state machine. State machine can be
defined as a machine which defines different states of an object and these
states are controlled by external or internal events.
Activity diagram explained in the next chapter, is a special kind of a
Statechart diagram. As Statechart diagram defines the states, it is used to
model the lifetime of an object.

Statechart diagram is one of the five UML diagrams used to model the dynamic
nature of a system. They define different states of an object during its lifetime and
these states are changed by events. Statechart diagrams are useful to model the
reactive systems. Reactive systems can be defined as a system that responds to
external or internal events.
Statechart diagram describes the flow of control from one state to another state.
States are defined as a condition in which an object exists and it changes when
some event is triggered. The most important purpose of Statechart diagram is to
model lifetime of an object from creation to termination.
Following is an example of a Statechart diagram where the state of Order
object is analyzed
The first state is an idle state from where the process starts. The next states are
arrived for events like send request, confirm request, and dispatch order. These
events are responsible for the state changes of order object.
During the life cycle of an object (here order object) it goes through the
following states and there may be some abnormal exits. This abnormal exit
may occur due to some problem in the system. When the entire life cycle is
complete, it is considered as a complete transaction as shown in the following
figure. The initial and final state of an object is also shown in the following
figure.