RAGHU ENGINEERING COLLEGE(Autonomous)

Dakamarri, Visakhapatnam – 531162

Approved by AICTE
Accredited by NBA
Accredited by NAAC with 'A' Grade
Affiliated to JNTU-Kakinada

COMPUTER SCIENCE & ENGINEERING

IV B.Tech - I Semester
UNIFIED MODELLING LANGUAGE(UNIT-4)
V.TATARAO
Asst.Professor
CSE DEPT
UNIFIED MODELLING LANGUAGE UNIT-4
UNIT-IV
Syllabus:UNIT-IV
UNIT-IV: Basic Behavioral Modeling: Interactions, Interaction diagrams, Use cases, Use case Dia-
grams, Activity Diagrams.

Behavioral Modeling
Interactions
Introduction:
In UML, the dynamic aspects of a system can bemodeledusing interactions. Interactions contain
messages that are exchangedbetweenobjects. A message can be an invocation of an operation or a
signal. The messages mayalsoincludecreation and destruction of otherobjects.
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 behaviorthatcontains a set of messages exchangedamong a set of objectswithin a
context to accomplish a purpose. A message isspecification of a communication
betweenobjectsthatconveys information with the expectation that the activitywillsucceed.
Objects and Roles:
The objectsthatparticipate in an interaction are eitherconcretethings or prototypicalthings. As a
concretething, an objectrepresentssomething in the real world. For example, p an instance of the
class Person, mightdenote a particularhuman. Alternately, as a prototypicalthing, p
mightrepresentany 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 Specifiesthat the correspondingobjectis visible by association

Self Specifiesthat the correspondingobjectis visible as itis the dispatcher of the operation
Global Specifiesthat the correspondingobjectis visible as itis in an enclosing scope
Local Specifiesthat the correspondingobjectis visible as itis in local scope
parameter Specifiesthat the correspondingobjectis visible as itis a parameter

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

Messages
A message is the specification of communication amongobjectsthatconveys information with the
expectation thatactivitywillsucceed. The receipt of a message instance maybeconsidered 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
UNIFIED MODELLING LANGUAGE UNIT-4
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.

To model the sequence of a message, we can explicitlyrepresent the order of the message relative to
the start of the sequence by prefixing the message with a sequencenumber 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.

Representation:
Whenwe model an interaction, wetypicallyincludebothobjects and messages. We can
visualizethoseobjects and messages involved in an interaction in twoways: by emphasizing the time
ordering of messages and by emphasizing the structural organization of the objectsthatsend and
receive messages. In UML, the first kind of representationiscalled a sequencediagram and the
second kind of representationiscalled a collaboration diagram. Bothsequence 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.

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

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.

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

Interaction Diagrams
Introduction:
An interaction diagramrepresents an interaction, whichcontains a set of objects and the
relationshipsbetweenthemincluding the messages exchangedbetween the objects. A
sequencediagramis an interaction diagram in which the focus is on time ordering of messages.
Collaboration diagramisanother interaction diagram in which the focus is on the structural
UNIFIED MODELLING LANGUAGE UNIT-4
organization of the objects. Bothsequencediagrams and collaboration diagrams are
isomorphicdiagrams.

Common Properties:
Interaction diagramsshare the propertieswhich are common to all the diagrams in UML. They are: a
namewhich identifies the diagram and the graphical contents which are a projection into the model.
Contents:
Interaction diagramscommonlycontain:
1. Objects
2. Links
3. Messages
Like all otherdiagrams, interaction diagramsmaycontain notes and constraints.

SequenceDiagrams:
A sequencediagramis one of the two interaction diagrams. The sequencediagramemphasizes on the
time ordering of messages. In a sequencediagram, the objectsthatparticipate in the interaction are
arranged at the top along the x-axis. Generally, the objectwhichinitiates the interaction isplaced on
the left and the next important object to its right and so on. The messages dispatched by the objects
are arrangedfrom top to bottomalong the y-axis. This gives the user the detail about the flow of
control over time.
Sequencediagram has twofeaturesthatdistinguishthemfrom collaboration diagrams. First, thereis the
objectlifeline, whichis a vertical dashed line thatrepresents the existence of an object over a period
of time. Most of the objects are alive throughout the interaction. Objectsmayalsobecreatedduring
the interaction with the receipt of the message stereotypedwithcreate.
Objectsmayalsobedestroyedduring the interaction with the receipt of the message stereotypedwith
destroy.
Second, thereis focus of control whichisrepresented as a thin rectangle over the life line of the
object. The focus of control represents the points in time at which the objectisperforming an action.
We can alsorepresentrecursion by using a self message.

Collaboration Diagrams:
A collaboration diagramis one of the two interaction diagrams. The collaboration
diagramemphasizes on the structural organization of the objects in the interaction. A collaboration
diagramis made up of objectswhich 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 objectsthatcollaborate.
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.

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

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

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, whetheritis a system, subsystem, operation or class or one
scenario of a use case or collaboration.
2. Identify the objectsthattake part in the interaction and laythem out at the top along the x-axis in a
sequencediagram.
3. Set the life line for eachobject.
4. Layout the messages betweenobjectsfrom the top along the y-axis.
5. To visualize the points at which the objectisperforming an action, use the focus of control.
6. To specify time constraints, adorneach message with the time and spaceconstraints.
7. To specify the flow of control in a more formalmanner, attachpre 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, whetheritis a system, subsystem, operation or class or one
scenario of a use case or collaboration.
2. Identify the objectsthattake part in the interaction and laythem out in a collaboration diagram as
the vertices in a graph.
3. Set the initial properties of each of theseobjects.
4. Specify the links amongtheseobjects.
5. Startingwith the messages thatinitiate the interaction, attacheachsubsequent message to the
appropriatelink, setting itssequencenumber, as appropriate. Use Dewey numbering system to
specifynested flow of control.
6. To specify time constraints, adorneach message with the time and spaceconstraints.
7. To specify the flow of control in a more formalmanner, attachpre and post conditions to each
message.

Use Cases
Introduction:
Use case modeling describeswhat a system does or whatis the functionalityprovided by the system
to benefit the users. Use case modeling wascreated by Ivar Jacobson. More thananyotherdiagrams
in UML, use case diagramsallow us to quicklygather the requirements of the software system. The
primary components of a use case model are use cases, actors or roles and the system
beingmodeledalsoknown as the subject.
The primarypurpose of use cases are:
1. To describe the functionalrequirements of the system, resulting in an agreement between the
stakeholders and the software developerswho 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 verifywhether the system worksappropriately or
not.
4. To provide the ability to transformfunctionalrequirementsinto classes and operations in the
system.

Use Case:
A use case represents the functionalityprovided by the system to the user. A use case isdefined as “a
set of actions performed by the system, whichproduces an observable resultthatis, typically, of some
value to one or more actors or other stakeholders of the system”. The actions can
UNIFIED MODELLING LANGUAGE UNIT-4
includecommunicatingwithotheractors or systems as well as performingcalculationsinside the
system. The characteristics of a use case are:
1. A use case isalwaysinitiated by an actor.
2. A use case provides value to an actor.
3. A use case iscomplete.
Use cases are connected to actorsthrough associations, which are sometimesreferred to as
communication associations. Associations representwhichactors the use case iscommunicatingwith.
The association shouldalwaysbebinary, implying a dialogbetween the actor and system.
A use case is a classifier, not an instance. A use case represents the functionality as a wholewith
possible alternatives, errors and exceptions that can occurduring the execution of the use case. An
instance of the use case isknown as a scenario, whichrepresents a specificexecutionpaththrough the
system.
Example: Consider a online shopping system,
Use case: Purchase Product
Scenario: A user namedsuryapurchases a product, gaming console by usingdebitcardpayment
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:

Actors:
An actoris one whichinteracts or uses the system (subject). An actorsends or receives messages
from the system. Actor can beeither a person or another system (computer or application). An
actoris a classifier, not an instance. An actorrepresents a role, not an individual user of the system.
For example, in an online shopping system, if rameshwants to purchase a product,
hisrolewillbebuyer.
An actor has a name, and the nameshouldreflect the actor’srole. The nameshould not represent an
instance of the actor or the functionality of an actor. A use case isalwaysinitiated by an
actorthatsends a message to it. This message isalsoknown as stimulus. Actors maybe of two types:
active actors and passive actors. Active actors or thosewhichinitiates a use case and passive actors
are thosewhichparticipate in a use case but neverinitiateit.
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:

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

A use case describeswhat a system does but itdoes not specify how itdoesthat. We can specify the
behavior of a use case by describing the flow of events in textclearlyenough for an outsider to
understanditeasily. Whenwewrite the flow of events, we must specifywhen the use case starts and
ends, whatobjects are exchangedbetween 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 followingway:
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 customercommits the entry by pressing the Enter
button. The system then checks this PIN number to see if itsvalid or not. If the PIN isvalid, the
system acknowledges the entry, thusending the use case.
Exceptional flow of events:
Customer can cancel the transaction at any point by pressing the Cancel buttontherebyrestarting 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.

Exceptional flow of events:

If the Customer enters an invalid PIN number, the use case restarts. If thishappens, three times in a
row, the system cancels the transaction, preventing the Customer frominteractingwith the ATM for
60 seconds.
Scenarios:
A scenario is a specificsequence of actions thatillustratesbehavior. Scenario is an instance of an 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 Rameshpurchases a laptop.
Another scenario can be user Maheshpurchases 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 groupingthem in packages in the samemanner in whichwe can
organize classes. We can alsoorganize use cases by specifyinggeneralization, include and
extendrelationships. Weapplytheserelationships in order to factor commonbehavior and in order to
factor variants (alternatives).
Generalizationamong use case representsthat the child use case inherits the behaviorfrom 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 implementthis, system mightask for a PIN number or
mightask for a retinal scan of the eye or mayask for finger scan. All thesethree, PIN validation,
Retinal scan and Finger scan are specializedways of checking the validity of a user and can
beapplied 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
UNIFIED MODELLING LANGUAGE UNIT-4
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.

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.
RAGHU ENGINEERING COLLEGE DEPT. OF CSE
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.

Use Case Diagrams

Use case diagrams are one of the five behavioraldiagrams for modeling the dynamic aspects of the
system. A use case diagramspecifieswhat the system does (behavior) for the actors. Use case
diagramplays a key role in modeling the behavior of a system or subsystem or a class. Each use
case diagramconsists of a set of use cases, actors and theirrelationships.

Common Properties:
Use case diagramssharessomecommonpropertieswith the rest of the UML diagrams like a
namewhich identifies a use case diagram and the graphical content whichis a projection into a
model.

Content:
Use case diagramscommonlycontain:
 Use cases
 Actors
 Dependency, generalization and association relationships
Like all otherdiagrams, use case diagramsmaycontain notes and constraints. Theymayalsocontain
packages or subsystems, which are used to group elements of your model intolargerchunks.

Common Uses:
Whenwe model the static use case view of a system, weapply use case diagrams in one of the
twoways:
 To model the context of a system
UNIFIED MODELLING LANGUAGE UNIT-4
 To model the requirements of a system

Common Modeling Techniques

Modeling the context of a system:
All the things (actors) that live outside the system and interactwith the system constitute the
system’scontext. This contextdefines the environment in which the system lives.
To model the context of a system:
1. Identify the actorsthatsurround the system.
2. Organizeactorsthat are similar to one another in a generalization-specializationhierarchy.
3. For bettersemantics, provide a stereotype for eachactor.
4. Create a use case diagramwiththeseactors and specify the paths of communication for eachactor
to the system’s uses cases using association relationships.

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

Modeling the requirements of a system:
A system’sfunctionalrequirements can beexpressed as use cases, and the UML’s use case diagrams
are essential for managingtheserequirements.
To model the requirements of a system:
1. Establish the context of the system by identifying the actorsthatsurround (use) the system.
2. For eachactor, identify the behaviorthat the actorexpectsfrom the system or requires the system to
provide.
3. Name thesecommonbehaviors as use cases.
4. Use include and extendrelationships to factor commonbehavior and optionalbehavior.
5. Model these use cases, actors and theirrelationships in a use case diagram.
6. Use notes to providedetails about the use cases and other non-functionalrequirements.
UNIFIED MODELLING LANGUAGE UNIT-4

Forward and reverse engineering:

To forwardengineer a use case diagram:

1. For each use case, identify the flow of events and itsexceptional flow of events.
2. Generate a test script for each flow, using the flow’spreconditions as the test’s initial state and its
post conditions as itssuccesscriteria.
3. As necessary, simulate test runs to representeachactorthatinteractswith the use case.
4. Use tools to run these tests each time you release the element to which the use case
diagramapplies.

To reverse engineer a use case diagram:

1. Identifyeachactorthatinteractswith the system.
2. For eachactor, consider how the actorinteractswith the system.
3. Trace the flow of events in the executable system relative to eachactor.
4. Cluster (group) related flows by declaring a corresponding use case. Use include and
extendrelationships as necessary.
5. Model theseactors and use cases in a use case diagram, and establishtheirrelationships.

Activity Diagrams
Introduction:
An activitydiagramis like a flowchart, representing flow of control fromactivity to activity, whereas,
the interaction diagrams focus on the flow of control fromobject to object. Activitiesresult in some
action, whichis made up of executableatomic computations thatresult in a change of state of the
system or the return of a value. Actions involvecallinganotheroperation, sending a signal, creating
or destroying an object or some pure computation, such as evaluating an expression.
Common Properties:
An activitydiagramshares the samecommonproperties as do all other UML diagrams like a
namewhichisused to uniquelyidentify the diagram and the graphical content whichis a projection
into the model.

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

Content:
Activity diagramsmainlycontain:
 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:

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 (solidball) and stop state (asolidballinside a hollowcircle).
Branching:
UNIFIED MODELLING LANGUAGE UNIT-4
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.

Forking and Joining:

While modeling flow of control, itiscommon to encounter flows that are concurrent or parallel. In
UML, a synchronization bar isused to specify the forking and joining of theseparallel flows of
control. A synchronization bar isrepresented as a thick vertical or horizontal line.
A fork may have one incoming transition and two or more outgoing transitions, each of
whichrepresents 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.

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

Common Uses:
When modeling the dynamic aspects of a system, you’ll use activitydiagrams in two of the
followingways:
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 objectsthat have the high-levelresponsibilities for parts of the overall workflow. Create
a swimlane for each of theseobjects.
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 activitiesthattake place and
renderthem as actions states or activity states.
5. For complex actions, or for sets of actions thatappear multiple times, collapse themintoactivity
states and provide a separateactivitydiagram for them.
6. Connect the action and activity states by transitions. Considerbranching and thenconsiderforking
and joining.
7. If there are important objectsthat are involved in the workflow, renderthem in the activitydiagram
as well.
UNIFIED MODELLING LANGUAGE UNIT-4

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 renderthem as
action states and activity states respectively.
4. Use branching as necessary to specifyconditionalpaths and iteration.
5. If thisoperationisowned by an active class, use forking and joining as necessary to specifyparallel
flows of control.

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

UNIFIED MODELLING LANGUAGE UNIT-4

UNIT-4 UML QUESTION BANK

1. Describe about the Basic Behavioral Modeling with an example?
2. Explain in detail about the Interaction diagrams with an example?
3. Explain in detail about the Use case Diagrams with an example?
4. What are the Common Modeling Techniques for Use case diagram with an example?
5. Explain in detail about the Activity Diagrams with an example?
6. What are the Common Modeling Techniques for Activity diagram with an example?
7. Explain in detail about the Sequence Diagram with example?
8. What are the Common Modeling Techniques for Sequence Diagram with an example?
9. Explain in detail about the Collaboration Diagram with an example?
10. What are the Common Modeling Techniques for Collaboration Diagram with an example?
11. How to Draw an Interaction Diagram and Where to Use Interaction Diagrams explain with
an example?
12. How to Draw a Use Case Diagram and what is the main purpose of USE CASE Diagramex-
plain with an example?
13. Draw Interaction Diagram for Railway Reservation system?
14. Draw Activity Diagram for Library Management System?
15. Draw Use Case Diagram for ATM?

RAGHU ENGINEERING COLLEGE DEPT. OF CSE