OOAD Using UML – Unit 4

4.0 Basic Behavioral Modeling: 4.1 Interactions, 4.2 Interaction diagrams, 4.3 Use cases, 4.4 Use
case Diagrams, 4.5 Activity Diagrams.

4.1 Interactions

Introduction:
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.

We can use interactions to model the flow of control within an operation, a class, a
component, a use case or the system as a whole. Using interaction diagrams, we can model these
flows in two ways: one is by focusing on how the messages are dispatched across time and the
second is by focusing on the structural relationships between objects and then consider how the
messages are passed between the objects. Graphically a message is rendered as a directed line with
the name of its operation as show below:

Interaction (Definition):
An interaction is a behavior that contains a set of messages exchanged among a set of
objects within a context to accomplish a purpose. A message is specification of a communication
between objects that conveys information with the expectation that the activity will succeed.

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. Wherever there is a link between two objects, one object can send messages to
another object. We can adorn the appropriate end of the link with any of the following standard
stereotypes:

association Specifies that the corresponding object is visible by association

Self Specifies that the corresponding object is visible as it is the dispatcher of the
operation
Global Specifies that the corresponding object is visible as it is in an enclosing scope
Local Specifies that the corresponding object is visible as it is in local scope
parameter Specifies that the corresponding object is visible as it is a parameter

1
OOAD Using UML – Unit 4

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.

When a message is passed, the action that results is an executable statement that forms an
abstraction of a computational procedure. An action may result in a change of state. In UML, we can
model several kinds of actions like:

Call Invokes an operation on an object

Return Returns a value to the caller
Send Sends a signal to the object
Create Creates an object
Destroy Destroys an object

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.

2
OOAD Using UML – Unit 4

To model the sequence of a message, we can explicitly represent the order of the message
relative to the start of the sequence by prefixing the message with a sequence number set apart by a
colon separator.

Most commonly, we can specify a procedural or nested flow of control, rendering using a
filled solid arrowhead. Less common but also possible, you can specify a flat flow of control,
rendered using a stick arrowhead. We will use flat sequences only when modeling interactions in the
context of use cases that involve the system as a whole, together with actors outside the system. In
all other cases, we will use procedural sequences, because they represent ordinary, nested
operation calls of the type we find in most programming languages.

(a) Procedural Sequence

(b) Flat Sequence

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.
Sequence diagrams and collaboration diagrams are isomorphic, meaning that we can take
one and transform it into the other without loss of information. Sequence diagram lets us to model
the lifeline of an object. An object’s lifeline represents the existence of the object at a particular
time. A collaboration diagram lets us to model the structural links that may exist among the objects
in the interaction.
Common Modeling Techniques

Modeling a flow of control:

To model a flow of control,

1. Set the context for the interaction, whether it is the system as a whole, a class or an
individual operation.
2. Identify the objects and their initial properties which participate in the interaction.
3. Identify the links between objects for communication through messages.
4. In time order, specify the messages that pass from object to object. Use parameters and
return values as necessary.
5. To add semantics, adorn each object at every moment in time with its state and role.

3
OOAD Using UML – Unit 4

Consider the following example of railway reservation system’s sequence and collaboration
diagrams:

4
OOAD Using UML – Unit 4

4.2 Interaction Diagrams

Introduction:
An interaction diagram represents an interaction, which contains a set of objects and the
relationships between them including the messages exchanged between the objects. A sequence
diagram is an interaction diagram in which the focus is on time ordering of messages. Collaboration
diagram is another interaction diagram in which the focus is on the structural organization of the
objects. Both sequence diagrams and collaboration diagrams are isomorphic diagrams.

Common Properties:
Interaction diagrams share the properties which are common to all the diagrams in UML.
They are: a name which identifies the diagram and the graphical contents which are a projection into
the model.

Contents:
Interaction diagrams commonly contain:
1. Objects
2. Links
3. Messages

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

Sequence Diagrams:
A sequence diagram is one of the two interaction diagrams. The sequence diagram
emphasizes on the time ordering of messages. In a sequence diagram, the objects that participate in
the interaction are arranged at the top along the x-axis. Generally, the object which initiates the
interaction is placed on the left and the next important object to its right and so on. The messages
dispatched by the objects are arranged from top to bottom along the y-axis. This gives the user the
detail about the flow of control over time.

Sequence diagram has two features that distinguish them from collaboration diagrams. First,
there is the object lifeline, which is a vertical dashed line that represents the existence of an object
over a period of time. Most of the objects are alive throughout the interaction. Objects may also be
created during the interaction with the receipt of the message stereotyped with create. Objects may
also be destroyed during the interaction with the receipt of the message stereotyped with destroy.

Second, there is focus of control which is represented as a thin rectangle over the life line of
the object. The focus of control represents the points in time at which the object is performing an
action. We can also represent recursion by using a self message.

Collaboration Diagrams:
A collaboration diagram is one of the two interaction diagrams. The collaboration diagram
emphasizes on the structural organization of the objects in the interaction. A collaboration diagram
is made up of objects which are the vertices and these are connected by links. Finally, the messages
are represented over the links between the objects. This gives the user the detail about the flow of
control in the context of structural organization of objects that collaborate.

Collaboration diagram has two features that distinguish them from the sequence diagrams.
First, there is a path which indicates one object is linked to another. Second, there is a sequence
number to indicate the time ordering of a message by prefixing the message with a number. We can
use Dewey decimal numbering system for the sequence numbers. For example a message can be
numbered as 1 and the next messages in the nested sequence can be numbered 1.1 and so on.

5
OOAD Using UML – Unit 4

Common Uses:
We use interaction diagrams to model the dynamic aspects (interactions) of the system.
When we use an interaction diagram to model some dynamic aspect of a system, we do so in the
context of the system as a whole, a subsystem, an operation or a class. We typically use the
interaction diagrams in two ways:
1. To model flows of control by time ordering
2. To model flows of control by organization

Common Modeling Techniques

Modeling flow of control by time ordering:

To model a flow of control by time ordering,

1. Set the context for the interaction, whether it is a system, subsystem, operation or class or
one scenario of a use case or collaboration.
2. Identify the objects that take part in the interaction and lay them out at the top along the x-
axis in a sequence diagram.
3. Set the life line for each object.
4. Layout the messages between objects from the top along the y-axis.
5. To visualize the points at which the object is performing an action, use the focus of control.
6. To specify time constraints, adorn each message with the time and space constraints.
7. To specify the flow of control in a more formal manner, attach pre and post conditions to
each message.

Modeling flow of control by organization:

To model a flow of control by organization,

1. Set the context for the interaction, whether it is a system, subsystem, operation or class or
one scenario of a use case or collaboration.
2. Identify the objects that take part in the interaction and lay them out in a collaboration
diagram as the vertices in a graph.
3. Set the initial properties of each of these objects.
4. Specify the links among these objects.
5. Starting with the messages that initiate the interaction, attach each subsequent message to
the appropriate link, setting its sequence number, as appropriate. Use Dewey numbering
system to specify nested flow of control.
6. To specify time constraints, adorn each message with the time and space constraints.
7. To specify the flow of control in a more formal manner, attach pre and post conditions to
each message.

6
OOAD Using UML – Unit 4

4.3 Use Cases

Introduction:
Use case modeling describes what a system does or what is the functionality provided by the
system to benefit the users. Use case modeling was created by Ivar Jacobson. More than any other
diagrams in UML, use case diagrams allow us to quickly gather the requirements of the software
system. The primary components of a use case model are use cases, actors or roles and the system
being modeled also known as the subject.

The primary purpose of use cases are:

1. To describe the functional requirements of the system, resulting in an agreement between
the stakeholders and the software developers who are developing the system.
2. To give a clear and consistent description of what the system should do.
3. To provide a basis for conducting system tests to verify whether the system works
appropriately or not.
4. To provide the ability to transform functional requirements into classes and operations in
the system.

Use Case:
A use case represents the functionality provided by the system to the user. A use case is
defined as “a set of actions performed by the system, which produces an observable result that is,
typically, of some value to one or more actors or other stakeholders of the system”. The actions can
include communicating with other actors or systems as well as performing calculations inside the
system. The characteristics of a use case are:
1. A use case is always initiated by an actor.
2. A use case provides value to an actor.
3. A use case is complete.

Use cases are connected to actors through associations, which are sometimes referred to as
communication associations. Associations represent which actors the use case is communicating
with. The association should always be binary, implying a dialog between the actor and system.
A use case is a classifier, not an instance. A use case represents the functionality as a whole
with possible alternatives, errors and exceptions that can occur during the execution of the use case.
An instance of the use case is known as a scenario, which represents a specific execution path
through the system.

Example: Consider a online shopping system,

Use case: Purchase Product
Scenario: A user named surya purchases a product, gaming console by using debit card payment
option.

The graphical representation of a use case is a solid ellipse with the use case name specified
inside the ellipse. A use case generally placed inside the system boundary and is always connected to
an actor using an association relationship. The name of the use case is generally a phrase rather a
one word label. The name can be a simple name or a path name as shown in the below example:

7
OOAD Using UML – Unit 4

Actors:
An actor is one which interacts or uses the system (subject). An actor sends or receives
messages from the system. Actor can be either a person or another system (computer or
application). An actor is a classifier, not an instance. An actor represents a role, not an individual
user of the system. For example, in an online shopping system, if ramesh wants to purchase a
product, his role will be buyer.
An actor has a name, and the name should reflect the actor’s role. The name should not
represent an instance of the actor or the functionality of an actor. A use case is always initiated by
an actor that sends a message to it. This message is also known as stimulus. Actors may be of two
types: active actors and passive actors. Active actors or those which initiates a use case and passive
actors are those which participate in a use case but never initiate it.
Actor can be represented with a class symbol stereotyped as <<actor>>. Actor has a
standard stereotype icon known as the “stickman”. An actor can have both attributes and behavior.

Flow of Events:
A use case describes what a system does but it does not specify how it does that. We can
specify the behavior of a use case by describing the flow of events in text clearly enough for an
outsider to understand it easily. When we write the flow of events, we must specify when the use
case starts and ends, what objects are exchanged between the system and the actor, the basic/main
flow and alternate flows of events. For example in an ATM system, we can describe the use case
“Validate User” in the following way:

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 its valid or not. If the PIN is valid, the
system acknowledges the entry, thus ending the use case.

Exceptional flow of events:

Customer can cancel the transaction at any point by pressing the Cancel button thereby
restarting the use case. No changes are made to the customer’s state.

Exceptional flow of events:

Customer can clear the PIN number anytime before confirming it and reenter a new PIN
number again.

8
OOAD Using UML – Unit 4

Exceptional flow of events:

If the Customer enters an invalid PIN number, the use case restarts. If this happens, three
times in a row, the system cancels the transaction, preventing the Customer from interacting with
the ATM for 60 seconds.

Scenarios:
A scenario is a specific sequence of actions that illustrates behavior. Scenario is an instance
of a use case like objects are instances of classes. For example, in an online shopping system
consider the use case “Purchase Product”. For this use case, a scenario can be: user Ramesh
purchases a laptop. Another scenario can be user Mahesh purchases a washing machine etc..

Collaborations:
A use case specifies what the system does but does not specify how it is implemented. A use
case is implemented by creating a collection of classes and other elements that work together to
achieve the behavior of the use case. This collection of elements, including both its static and
dynamic structure, is modeled in UML as collaboration.

Organizing Use Cases:

We can organize the use cases by grouping them in packages in the same manner in which
we can organize classes. We can also organize use cases by specifying generalization, include and
extend relationships. We apply these relationships in order to factor common behavior and in order
to factor variants (alternatives).
Generalization among use case represents that the child use case inherits the behavior from
the parent use case. For example in an ATM system, the behavior of the use case “Validate User” is
to check whether the user is a valid user or not. To implement this, system might ask for a PIN
number or might ask for a retinal scan of the eye or may ask for finger scan. All these three, PIN
validation, Retinal scan and Finger scan are specialized ways of checking the validity of a user and
can be applied at any place where the “Validate User” use case appears.
An include relationship between use cases means that the base use case explicitly
incorporates the behavior of the included use case. Such relationship is represented as a
dependency stereotyped with include. In an include relationship, the base use case cannot exist
without the included use case. The include relationship is used to separate the common behavior.

An extend relationship between use cases means that the extending use case extends the
behavior of the base use case. Such relationship is graphically represented as dependency
stereotyped with exclude. In a extend relationship, the base use case may exist on its own but at
certain points its behavior may be extended by the behavior of another use case. The extend
relationship is used to separate the optional behavior.

9
OOAD Using UML – Unit 4

Consider the following which illustrates the use of generalization, include and extend relationships
between use cases:

Common Modeling Techniques:

Modeling the behavior of an element:
To model the behavior of an element:
1. Identify the actors that interact with the element.
2. Organize the actors by identifying the general and more specialized roles.
3. For each actor, consider the primary ways in which the actor interacts with the element.
4. Consider also the alternative ways in which the actor interacts with the element.
5. Organize these behaviors as use cases, applying include and extend relationships to factor
common behavior and distinguish exceptional behavior.

10
OOAD Using UML – Unit 4

4.4 Use Case Diagrams

Use case diagrams are one of the five behavioral diagrams for modeling the dynamic aspects
of the system. A use case diagram specifies what the system does (behavior) for the actors. Use case
diagram plays a key role in modeling the behavior of a system or subsystem or a class. Each use case
diagram consists of a set of use cases, actors and their relationships.

Common Properties:

Use case diagrams shares some common properties with the rest of the UML diagrams like a
name which identifies a use case diagram and the graphical content which is a projection into a
model.

Content:
Use case diagrams commonly contain:
• Use cases
• Actors
• Dependency, generalization and association relationships

Like all other diagrams, use case diagrams may contain notes and constraints. They may also
contain packages or subsystems, which are used to group elements of your model into larger
chunks.

Common Uses:

When we model the static use case view of a system, we apply use case diagrams in one of
the two ways:
• To model the context of a system
• To model the requirements of a system

11
OOAD Using UML – Unit 4

Common Modeling Techniques

Modeling the context of a system:

All the things (actors) that live outside the system and interact with the system constitute
the system’s context. This context defines the environment in which the system lives.

To model the context of a system:

1. Identify the actors that surround the system.
2. Organize actors that are similar to one another in a generalization-specialization hierarchy.
3. For better semantics, provide a stereotype for each actor.
4. Create a use case diagram with these actors and specify the paths of communication for
each actor to the system’s uses cases using association relationships.

Modeling the requirements of a system:

A system’s functional requirements can be expressed as use cases, and the UML’s use case
diagrams are essential for managing these requirements.

To model the requirements of a system:

1. Establish the context of the system by identifying the actors that surround (use) the system.
2. For each actor, identify the behavior that the actor expects from the system or requires the
system to provide.
3. Name these common behaviors as use cases.
4. Use include and extend relationships to factor common behavior and optional behavior.
5. Model these use cases, actors and their relationships in a use case diagram.
6. Use notes to provide details about the use cases and other non-functional requirements.

12
OOAD Using UML – Unit 4

Forward and reverse engineering:

To forward engineer a use case diagram:

1. For each use case, identify the flow of events and its exceptional flow of events.
2. Generate a test script for each flow, using the flow’s preconditions as the test’s initial state
and its post conditions as its success criteria.
3. As necessary, simulate test runs to represent each actor that interacts with the use case.
4. Use tools to run these tests each time you release the element to which the use case
diagram applies.

To reverse engineer a use case diagram:

1. Identify each actor that interacts with the system.
2. For each actor, consider how the actor interacts with the system.
3. Trace the flow of events in the executable system relative to each actor.
4. Cluster (group) related flows by declaring a corresponding use case. Use include and extend
relationships as necessary.
5. Model these actors and use cases in a use case diagram, and establish their relationships.

13
OOAD Using UML – Unit 4

4.5 Activity Diagrams

Introduction:
An activity diagram is like a flowchart, representing flow of control from activity to activity,
whereas, the interaction diagrams focus on the flow of control from object to object. Activities result
in some action, which is made up of executable atomic computations that result in a change of state
of the system or the return of a value. Actions involve calling another operation, sending a signal,
creating or destroying an object or some pure computation, such as evaluating an expression.

Common Properties:
An activity diagram shares the same common properties as do all other UML diagrams like a
name which is used to uniquely identify the diagram and the graphical content which is a projection
into the model.

Content:
Activity diagrams mainly contain:
• Activity states and action states
• Transitions
• Objects

Action States and Activity States:

Activity diagram may represent actions which are atomic computations. These atomic
computations are called action states because they are states of the system, each representing the
execution of an action. In UML, an action states is represented using a lozenge symbol (rounded
rectangle) as shown below:

In contrast, activity states can be further decomposed, their activity being represented by
other activity diagrams. Activity states are non-atomic and can be interrupted, considered to take
some duration to complete. There is no difference in the notation of activity states and action states
except that the activity states may have additional information like entry and exit actions as shown
below:

14
OOAD Using UML – Unit 4

Transitions:
When the action or activity completes, the flow of control passes immediately to the next
action or activity state. This flow is represented as transitions to show the path from one action or
activity state to the next action or activity state. In UML, a transition is represented as a simple
directed line.

A flow of control has to start and end someplace. Therefore, as shown in the above figure,
we can specify the initial state (solid ball) and stop state (a solid ball inside a hollow circle).

Branching:
Like in flowcharts, we can include a branch, which specifies alternate paths taken based on
some Boolean expression which is also known as a guard condition. In UML, a branch is represented
as a diamond. A branch may have one incoming transition and two or more outgoing transitions.
Across all these outgoing transitions, guards should not overlap, but they should cover all
possibilities.

15
OOAD Using UML – Unit 4

Forking and Joining:

While modeling flow of control, it is common to encounter flows that are concurrent or
parallel. In UML, a synchronization bar is used to specify the forking and joining of these parallel
flows of control. A synchronization bar is represented as a thick vertical or horizontal line.

A fork may have one incoming transition and two or more outgoing transitions, each of
which represents an independent flow of control. Below the fork, the activities in each flow carry out
in parallel.

A join represents the synchronization of two or more concurrent flows of control. A join may
have two or more incoming transitions and one outgoing transition. At the join, all the concurrent
flows synchronize, meaning that each flow waits for the other to join and continues on below the
join.

Swimlanes:
In activity diagrams, the activity states can be divided into logical groups, each group
representing the object responsible for the activities. In UML, each group is known as a swimlane
because, visually, each group is divided from its neighbor by a vertical solid line as shown in the
below figure. Each swimlane has its own name. In an activity diagram partitioned into swimlanes,
every activity belongs to exactly one swimlane, but transitions may cross lanes.

16
OOAD Using UML – Unit 4

Common Uses:
When modeling the dynamic aspects of a system, you’ll use activity diagrams in two of the
following ways:
1. To model a workflow
2. To model an operation

Common Modeling Techniques

Modeling a Workflow:

To model a workflow:
1. Establish a focus for the workflow.
2. Select the objects that have the high-level responsibilities for parts of the overall workflow.
Create a swimlane for each of these objects.
3. Identify the pre-conditions of the workflow’s initial state and the post-conditions of the
workflow’s final state.
4. Starting at the workflow’s initial state layout the actions and activities that take place and
render them as actions states or activity states.
5. For complex actions, or for sets of actions that appear multiple times, collapse them into
activity states and provide a separate activity diagram for them.
6. Connect the action and activity states by transitions. Consider branching and then consider
forking and joining.

17
OOAD Using UML – Unit 4

7. If there are important objects that are involved in the workflow, render them in the activity
diagram as well.

Modeling an operation:

To model an operation:
1. Collect the abstractions involved in an operation like: parameters, attributes of the enclosing
class and the neighboring class.
2. Identify the operation’s pre-conditions and the operation’s post-conditions.
3. Beginning at the operation’s initial state, define the actions and activities and render them
as action states and activity states respectively.
4. Use branching as necessary to specify conditional paths and iteration.
5. If this operation is owned by an active class, use forking and joining as necessary to specify
parallel flows of control.

18