OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

UNIT-IV
Behavioral Modelling
Interactions: An interaction is a behavior that comprises a set of messages exchanged among a
set of objects within a context to accomplish a purpose.
A message is a specification of a communication between objects that conveys information with
the expectation that activity will ensue.
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
 As a prototypical thing, p might represent any instance of Person.
 Although abstract classes and interfaces, by definition, may not have any direct instances,
you may find instances of these things in an interaction
Links
 A link is a semantic connection among objects. In general, a link is an instance of an
association
 Wherever a class has an association to 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 a message to the other object
 A link specifies a path along which one object can dispatch a message to another (or the
same) 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 because it is the
dispatcher of the operation
global Specifies that the corresponding object is visible because it is in an
enclosing scope
local Specifies that the corresponding object is visible because it is in a local
scope
parameter Specifies that the corresponding object is visible because it is a
parameter

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 1

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

Messages
 A message is the specification of a communication among objects that conveys information
with the expectation that activity will ensue.
 The receipt of a message instance may be considered an instance of an event.
 When you pass a message, the action that results is an executable statement that forms an
abstraction of a computational procedure. An action may result in a change in state.
 In the UML, you can model several kinds of actions

Call Invokes an operation on an object; an object may send a message to itself,

resulting in the local invocation of an operation
Return Returns a value to the caller
Send Sends a signal to an object
Create Creates an object
Destroy Destroys an object; an object may commit suicide by destroying itself

 The UML provides a visual distinction among these kinds of messages, as follows

 When an object calls an operation or sends a signal to another object, you can provide actual
parameters to the message.
 Similarly, when an object returns control to another object, you can model the return value.

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

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 2

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

 Messages are ordered in sequence by time. To better visualize the sequence of a message,
you can explicitly model 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, you can specify a procedural or nested flow of control, rendered
using a filled solid arrowhead

 We can specify a flat flow of control, rendered using a stick arrowhead, to model the
nonprocedural progression of control from step to step.

Creation, Modification, and Destruction

 Most of the time, the objects you show participating in an interaction exist for the entire
duration of the interaction. However, in some interactions, objects may be created (specified
by a create message) and destroyed (specified by a destroy message).
 The same is true of links: the relationships among objects may come and go. To specify if an
object or link enters and/or leaves during an interaction, you can attach one of the following
constraints to the element:

New Specifies that the instance or link is created during execution of the enclosing
interaction
destroyed Specifies that the instance or link is destroyed prior to completion of execution
of the enclosing interaction
transient Specifies that the instance or link is created during execution of the enclosing
interaction but is destroyed before completion of execution

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 3

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

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. Graphically, a collaboration diagram
is a collection of vertices and arcs.
Common Properties
An interaction diagram is just a special kind of diagram and shares the same common
properties as do all other diagrams• a name and graphical contents that are a projection into a
model. What distinguishes an interaction diagram from all other kinds of diagrams is its
particular content.

Contents
Interaction diagrams commonly contain
· Objects
· Links
· Messages

Like all other diagrams, interaction diagrams may contain notes and constraints.
Sequence Diagrams
A sequence diagram emphasizes the time ordering of messages.

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 4

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

Sequence diagrams have two features that distinguish them from collaboration diagrams.

1.Object lifeline: An object lifeline is the vertical dashed line that represents the existence of an
object over a period of time.
Objects may be created during the interaction. Their lifelines start with the receipt of the
message stereotyped as <<create>>. Objects may be destroyed during the interaction. Their
lifelines end with the receipt of the message stereotyped as <<destroy >>

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

Collaboration Diagrams
A collaboration diagram emphasizes the organization of the objects that participate in an
interaction.
As Figure shows, 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.
.

Collaboration diagrams have two features that distinguish them from sequence diagrams.

First, there is the path. To indicate how one object is linked to another, you can attach a path.
Typically, you will only need to render the path of the link explicitly for local,
parameter, global, and self (but not association) paths.

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 is the
second message nested in message 1; and so on).

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 5

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

Semantic Equivalence

Because they both derive from the same information in the UML's meta model, sequence
diagrams and collaboration diagrams are semantically equivalent. As a result, you can take a
diagram in one form and convert it to the other without any loss of information.

Common Uses
You use interaction diagrams to model the dynamic aspects of a system. These dynamic aspects
may involve the interaction of any kind of instance in any view of a system's architecture,
including instances of classes (including active classes), interfaces, components, and nodes.

When you model the dynamic aspects of a system, you typically use interaction diagrams in two
ways.
1. To model flows of control by time ordering

Here you'll use sequence diagrams. Modeling a flow of control by time ordering emphasizes the
passing of messages as they unfold over time, which is a particularly useful way to visualize
dynamic behavior in the context of a use case scenario.

2. To model flows of control by organization

Here you'll use collaboration diagrams. Modeling a flow of control by organization
emphasizes the structural relationships among the instances in the interaction, along which
messages may be passed.

Common Modeling Techniques

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.Set the stage for the interaction by identifying which objects play a role in the interaction.
Lay them out on the sequence diagram from left to right, placing the more important
objects to the left and their neighboring objects to the right.
3.Set the lifeline for each object. In most cases, objects will persist through the entire
interaction. For those objects that are created and destroyed during the interaction, set
their lifelines, as appropriate, and explicitly indicate their birth and death with
appropriately stereotyped messages.
4.Starting with the message that initiates this interaction, lay out each subsequent message
from top to bottom between the lifelines, showing each message's properties (such as its
parameters), as necessary to explain the semantics of the interaction.
5.If you need to visualize the nesting of messages or the points in time when actual
computation is taking place, adorn each object's lifeline with its focus of control.
6.If you need to specify time or space constraints, adorn each message with a timing mark
and attach suitable time or space constraints.
7.If you need to specify this flow of control more formally, attach pre- and postconditions to
each message

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 6

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

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.Set the stage for the interaction by identifying which objects play a role in the interaction.
Lay them out on the collaboration diagram as vertices in a graph, placing the more
important objects in the center of the diagram and their neighboring objects to the
outside.
3.Set the initial properties of each of these objects. If the attribute values, tagged values,
state, or role of any object changes in significant ways over the duration of the
interaction, place a duplicate object on the diagram, update it with these new values, and
connect them by a message stereotyped as become or copy (with a suitable sequence
number).
4.Specify the links among these objects, along which messages may pass.
1. Lay out the association links first; these are the most important ones, because
they represent structural connections.
2. Lay out other links next, and adorn them with suitable path stereotypes (such as
global and local) to explicitly specify how these objects are related to one another.
3.Starting with the message that initiates this interaction, attach each subsequent message
to the appropriate link, setting its sequence number, as appropriate. Show nesting by
using Dewey decimal numbering.
4.If you need to specify time or space constraints, adorn each message with a timing mark
and attach suitable time or space constraints.

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 7

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

5.If you need to specify this flow of control more formally, attach pre- and postconditions to
each message.

Use Cases

 A use case 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.
 Graphically, a use case is rendered as an ellipse.

Names

 Every use case must have a name that distinguishes it from other use cases. A name is a
textual string.
 That name alone is known as a simple name; a path name is the use case name prefixed by
the name of the package in which that use case lives.
 A use case is typically drawn showing only its name

Use Cases and Actors

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 8

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

 An actor represents a coherent set of roles that users of use cases play when interacting with
these use cases.
 Typically, an actor represents a role that a human, a hardware device, or another system plays
with a system.
 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.

Use Cases and Flow of Events

 A use case describes what a system does but it does not specify how it does it.
 You can specify the behavior of a use case by describing a flow of events in text clearly
enough for an outsider to understand it easily
 When you write this flow of events, you should include how and when the use case starts and
ends
 When the use case interacts with the actors and what objects are exchanged, and the basic
flow and alternative flows of the behavior.

For example, in the context of an ATM system, you might describe the use case ValidateUser 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 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:

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 9

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

The Customer can clear a PIN number anytime before committing it and reenter a new PIN
number.

 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 entire transaction, preventing the Customer from interacting with
the ATM for 60 seconds

Use Cases and Scenarios

 Typically, we'll first describe the flow of events for a use case in text.
 Typically, we'll use one sequence diagram to specify a use case's main flow, and variations of
that diagram to specify a use case's exceptional flows.
 Use case describes a set of sequences, not just a single sequence, and it would be impossible
to express all the details of an interesting use case in just one sequence.
 Each sequence is called a scenario. A scenario is a specific sequence of actions that
illustrates behavior. Scenarios are to use cases as instances are to classes, meaning that a
scenario is basically one instance of a use case.

Use Cases and Collaborations

 A use case captures the intended behavior of the system you are developing, without having
to specify how that behavior is implemented.
 however, you have to implement your use cases, and you do so by creating a society of
classes and other elements that work together to implement the behavior of this use case
 This society of elements, including both its static and dynamic structure, is modeled in the
UML as a collaboration.
 you can explicitly specify the realization of a use case by a collaboration

Organizing Use Cases

 We can organize use cases by grouping them in packages in the same manner in which you
can organize classes.
 You can also organize use cases by specifying generalization, include, and extend
relationships among them.
 generalization among use cases is rendered as a solid directed line with a large open
arrowhead, just like generalization among classes.

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 10

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

 An include relationship between use cases means that the base use case explicitly
incorporates the behavior of another use case at a location specified in the base.

 You render an include relationship as a dependency, stereotyped as include.

 An extend relationship between use cases means that the base use case implicitly
incorporates the behavior of another use case at a location specified indirectly by the
extending use case.
 This base use case may be extended only at certain points called, not surprisingly, its
extension points
 We render an extend relationship as a dependency, stereotyped as extend.

Other Features
 Use cases are classifiers, so they may have attributes and operations that you may render just
as for classes.
 You can think of these attributes as the objects inside the use case that you need to describe
its outside behavior. Similarly, you can think of these operations as the actions of the system
you need to describe a flow of events.
 These objects and operations may be used in your interaction diagrams to specify the
behavior of the use case
 As classifiers, you can also attach state machines to use cases
 We can use state machines as yet another way to describe the behavior represented by a use
case.

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 11

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

Common Modeling Techniques

To model the behavior of an element,

1.Identify the actors that interact with the element. Candidate actors include groups that
require certain behavior to perform their tasks or that are needed directly or indirectly to
perform the element's functions.
2.Organize actors by identifying general and more specialized roles.
3.For each actor, consider the primary ways in which that actor interacts with the element.
Consider also interactions that change the state of the element or its environment or that
involve a response to some event.
4.Consider also the exceptional ways in which each 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 Diagram

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 12

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

 A use case diagram is a diagram that shows a set of use cases and actors and their
relationships.

Contents
 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.
 Use case diagrams may also contain packages

Common Uses
 We apply use case diagrams to model the static use case view of a system. This view
primarily supports the behavior of a system
 When you model the static use case view of a system, you'll typically apply use case
diagrams in one of two ways.

o To model the context of a system

o To model the requirements of a system

Modeling the context of a system involves drawing a line around the whole system and
asserting which actors lie outside the system and interact with it.Here, you'll apply use case
diagrams to specify the actors and the meaning of their roles.

Modeling the requirements of a system involves specifying what that system should do (from a
point of view of outside the system), independent of how that system should do it. Here, you'll
apply use case diagrams to specify the desired behavior of the system.

Common Modeling Techniques

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 13

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

Modeling the Context of a System

1.Identify the actors that surround the
2.Organize actors that are similar to one another in a generalization/specialization
hierarchy.
3.Provide a stereotype for each such actor.
4.Populate a use case diagram with these actors and specify the paths of communication
from each actor to the system's use cases.

To model the requirements of a system,

1.Establish the context of the system by identifying the actors that surround it.
2.For each actor, consider the behavior that each expects or requires the system to
provide.
3.Name these common behaviors as use cases.
4.Model these use cases, actors, and their relationships in a use case diagram.

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 14

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

Activity Diagrams

o An activity diagram shows the flow from activity to activity. And is an ongoing nonatomic
execution within a state machine.
o Activities ultimately result in some action,which is made up of executable atomic
computations that result in a change in state of the system or the return of a value.
o Actions encompass calling another operation, sending a signal, creating or destroying an
object, or some pure computation, such as evaluating an expression.
o Graphically, an activity diagram is a collection of vertices and arcs.

Contents
o Activity diagrams commonly contain
o Activity states and action states
o Transitions
o Objects
o Like all other diagrams, activity diagrams may contain notes and constraints.
Action States

o Executable, atomic computations are called action states because they are states of the
system, each representing the execution of an action.
o We represent an action state using a lozenge shape (a symbol with horizontal top and bottom
and convex sides). Inside that shape, you may write any expression.
o Action states can't be decomposed. Furthermore, action states are atomic, meaning that
events may occur, but the work of the action state is not interrupted.

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 15

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

o Finally, the work of an action state is generally considered to take insignificant execution
time.

activity states can be further decomposed, their activity being represented by other activity
diagrams
o Furthermore,activity states are not atomic, meaning that they may be interrupted and, in
general, are considered to take some duration to complete.
o An action state is an activity state that cannot be further decomposed.

Transitions

o When the action or activity of a state completes, flow of control passes immediately to the
next action or activity state.
o We specify this flow by using transitions to show the path from one action or activity state to
the next action or activity state.
o In the UML, you represent a transition as a simple directed line

Branching
o As in a flowchart, you can include a branch, which specifies alternate paths taken based on
some Boolean expression.
o We represent a branch as a diamond. A branch may have one incoming transition and two or
more outgoing ones.
o On each outgoing transition, you place a Boolean expression, which is evaluated only once
on entering the branch. Across all these outgoing transitions, guards should not overlap

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 16

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

(otherwise, the flow of control would be ambiguous), but they should cover all possibilities
(otherwise, the flow of control would freeze).
o As a convenience, you can use the keyword else to mark one outgoing transition,
representing the path taken if no other guard expression evaluates to true.

Forking and Joining

o When we are modeling workflows of business processes—we might encounter flows that are
concurrent.
o In the UML, you use a synchronization bar to specify the forking and joining of these parallel
flows of control. A synchronization bar is rendered as a thick horizontal or vertical line.

o Fork represents the splitting of a single flow of control into two or more concurrent flows of
control
o A fork may have one incoming transition and two or more outgoing transitions, each of
which represents an independent flow of control.
o Below the fork, the activities associated with each of these paths continues in parallel.

o A Join represents the synchronization of two or more concurrent flows of control.

o A join may have two or more incoming transitions and one outgoing transition.

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 17

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

Swimlanes

o We'll find it useful, especially when you are modeling workflows of business processes, to
partition the activity states on an activity diagram into groups, each group representing the
business organization responsible for those activities.
o In the UML, each group is called a swimlane because, visually, each group is divided from
its neighbor by a vertical solid line
o A swimlane specifies a locus of activities
o Each swimlane has a name unique within its diagram.
o Each swimlane represents a high-level responsibility for part of the overall activity of an
activity diagram, and each swimlane may eventually be implemented by one or more classes.
o In an activity diagram partitioned into swimlanes, every activity belongs to exactly one
swimlane, but transitions may cross lanes.

Object Flow

o Objects may be involved in the flow of control associated with an activity diagram.
o We can specify the things that are involved in an activity diagram by placing these objects in
the diagram, connected using a dependency to the activity or transition that creates, destroys,
or modifies them.
o This use of dependency relationships and objects is called an object flow because it
represents the participation of an object in a flow of control.

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 18

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

o We can also show how its role, state and attribute values change.
o We represent the state of an object by naming its state in brackets below the object's name.
o Similarly, We can represent the value of an object's attributes by rendering them in a
compartment below the object's name.

Common Uses
 We use activity diagrams to model the dynamic aspects of a system
 These dynamic aspects may involve the activity of any kind of abstraction in any view of a
system's architecture, including classes, interfaces, components, and nodes.
 When you model the dynamic aspects of a system, we'll typically use activity diagrams in
two ways.
 To model a workflow
 To model an operation

Common Modelling Tech

To model a workflow,
1.Establish a focus for the workflow. For nontrivial systems, it's impossible to show all
interesting workflows in one diagram.
2.Select the business objects that have the high-level responsibilities for parts of the overall
workflow. These may be real things from the vocabulary of the system, or they may be
more abstract. In either case, create a swimlane for each important business object.

3.Identify the preconditions of the workflow's initial state and the postconditions of the
workflow's final state. This is important in helping you model the boundaries of the
workflow.
4.Beginning at the workflow's initial state, specify the activities and actions that take place
over time and render them in the activity diagram as either activity states or action states.

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 19

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

5.Render the transitions that connect these activity and action states. Start with the sequential
flows in the workflow first, next consider branching, and only then consider
forking and joining.
6.If there are important objects that are involved in the workflow, render them in the activity
diagram, as well. Show their changing values and state as necessary to communicate the
intent of the object flow.

To model an operation,
1.Collect the abstractions that are involved in this operation. This includes the operation's
parameters (including its return type, if any), the attributes of the enclosing class, and
certain neighboring classes.
2.Identify the preconditions at the operation's initial state and the postconditions at the
operation's final state. Also identify any invariants of the enclosing class that must hold
during the execution of the operation.
3.Beginning at the operation's initial state, specify the activities and actions that take place
over time and render them in the activity diagram as either activity states or action states.
4.Use branching as necessary to specify conditional paths and iteration.
5.Only if this operation is owned by an active class, use forking and joining as necessary to
specify parallel flows of control.

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 20

 OBJECT ORIENTED ANALYSIS AND DESIGN USING UML

Prepared by T Siva Ramakrishna,Assoc. Professor,CSEPage 21