Introduction to UML

• UML is an abbreviation of Unified Modelling Language

• UML is a language

L (A ,R ) C o m m u n ic a t io n

la n g u a g e a lp h a b e ts g ra m m a r

– It has a set of vocabulary (like rectangles, lines, ellipses

etc.) and the rules for combining words in that vocabulary
for the purpose of communication

– UML is a graphical language

 Introduction to UML
• UML is a modeling language

– UML is a language to create models (software blue prints)

of software intensive systems

– UML focuses on conceptual and physical representation of

a system
 Applications of UML
• The UML is appropriate for modeling systems
ranging from enterprise systems to distributed web
based applications and even to hardcore real time
embedded systems

• UML follows object oriented approach and hence the

best deals with object oriented analysis and design
(OOA&D) of systems
 Definition of UML
• The UML is a language for

– Visualizing

– Specifying

– Constructing

– Documenting

the artifacts of a software-intensive system

 Definition of UML : Visualizing
• Visualizing
UML models a system to facilitate communication for all range
of people
• Specifying
UML builds models that are precise, unambiguous and complete.
In particular UML addresses the specification of all the important
analysis, design and implementation decision that must be made
in developing and deploying a software system
 Definition of UML : Constructing
• Constructing
– UML models can be directly mapped to
• An object oriented programming language such as C++,
Java or Visual Basic
• Tables in relational database
• Persistent store of an object-oriented database

– This permits forward engineering: the generation

of a code from a UML model into a programming
language
Definition of UML : Constructing
– It also permits reverse engineering: One can reconstruct a
model from an implementation back into the UML
• Reverse engineering requires tools support with human
intervention

– Roundtrip engineering: combining the two paths of forward

code generation and reverse engineering
• Meaning the ability to work in either a graphical or technical view
• UML keeps two views consistent
 Definition of UML : Documenting
• Documenting
– UML facilitates all sorts of system artifacts like
requirements, design, project planning, coding, testing,
prototyping, maintenance, release etc.

– These artifacts not only the deliverables of a project, they

also in controlling, measuring and communicating about a
system during its development and after its deployment
 Learning UML
• There are three major elements in UML

1. Basic building blocks (vocabulary of the language)

2. The rules how these building blocks can be put together

3. Some common mechanism that can be applied throughout the

UML
 Basic Building Blocks in UML
• Vocabulary of the UML encompasses three kinds of
building blocks

– Things
• Things are abstractions in a model

– Relationships
• Relationships tie the things together

– Diagrams
• Diagrams group relevant collection of things
 Basic Building Blocks: Things
• There are four kinds of things in the UML

1. Structural things

2. Behavioral things

3. Grouping things

4. Annotational things
 Structural Things in UML
• Relevant things that are either conceptual or physical
Examples: class, object, etc.

• Structural things are nouns in the UML model

• There are seven structural things in UML

1. Class
2. Active class
3. Component
4. Interface
5. Use case
6. Collaboration
7. Node
 Structural Things: Class
• Class
– A class is a description of a set of objects ( or an
abstraction of object)
– Graphically a class is represented as a rectangle ,
including its name, attributes, and operations

N am e

A t t r ib u t e s

O p e r a t io n s
 Structural Things: Active Class
•Active Class
– An active class is just like a class
expect that its object represent
element whose behavior is
concurrent with other elements E vent M anger

A t t r ib u te s
– An object of an active class owns one
or more processes or threads and re s u m e ()
therefore initiate control activity s ta rt()
s u s p e n d ()
k ill( )
– Graphically, an active class is f lu s h ( )
denoted just like a class, but with a
heavy line, usually including its
name, attributes, and operations
 Structural Things: Component
• Component
– Component of a system is to
conform with the realization of a set
of interfaces
m y P a c k a g e .h tm
– Example: An applet, com+
component, Java bean or ASP file.
In fact, a component is typically
represents a physical package of
otherwise logical elements such as
classes, interfaces and collaborations

– Graphically a component denoted as

a rectangle with tabs, usually
including only its name
 Structural Things: Interface
• Interface
– An interface is a collection of
operators that specify a service of a
class or a component iS p e ll
iT h e s a
u ru s

– In UML, Interfaces are used to

model the seams (layers) in a system

–
iS y n o n
C om ponent
Graphically, an interface rendered as
iC o u n t
ym s

a circle together with its name

Note: An interface rarely stands alone,

rather it is attached to a class or iU n k n o
wn
component
 Structural Things: Use case
• Use case
• Use case represents a
functional components in a
model G e t O rd e r

• Graphically a use case is

represented by an ellipse
including only its name P ro c e s s O rd e r
 Structural Things: Collaboration
• Collaboration
– A collaboration names a society of
classes, interfaces, and other components
that work together to provide cooperative
behavior that is bigger than the sum of its
individual parts

Example:
W o r ld T r a d e C e n te r
A big building (world trade center) is a
collaboration of some structural
construction, electrical wiring system,
telephone connectivity, internet
connectivity, water supply system, etc.

– Graphically a collaboration is rendered as

an ellipse with dashed line
 Structural Things: Node
• Node
• Node is a physical element and
represent a computational
resource, generally having same
memory and processing
compatibility S e rv e r

• Graphically, a node is denoted by

a cube, usually includes its name
 Behavioral Things in UML
• Unlike structural things, behavioral things are to represent
dynamic parts of UML models. Structural things are the
mostly static parts of the model and are the nouns of the UML
model

• In the contrary, behavioral things are the verbs of UML

models

• There are two primary kind of behavioral things in the UML

1. Interaction
2. State machine
 Behavioral Things: Interaction
• Interaction
– An interaction is a behavior that comprises a set of
messages exchanged among set of objects within a
context to accomplish a purpose

– Basically interaction used to link two instances of

classes (objects), and through which one object
can send a message to the other object
 Behavioral Things: Interaction
– Graphically, an interaction is represented as a directed line,
usually including the name of its operation
1 ..* W o rk s fo r
P e rs o n * Com pany
e m p lo y e e e m p lo y e r
:
:
a s s ig n (p :P r o je c t)

a s s ig n ( t e s tin g )
e : P e rs o n c : Com pany
 Behavioral Things: State Machine
• State machine
– Using an interaction one can model the behavior of
a society of objects that work together

– On the other hand, using a state machine one can

model the behavior of an individual object

– A state machine is a behavior that specifies the

sequence of states of an object goes through during
its life time in response to a message
 Behavioral Things: State Machine
– Graphically a state is denoted by a rounded rectangle,
including its name and its states, if any
on shut dow n
f in is h e d

w a it r u n n in g

k e y p re s s

A s ta te m a c h in e fo r a n o b je c t
B u tto n

• Note: These two behavioral things are usually connected

though various structural elements like classes, collaborations,
objects etc.
 Grouping Things in UML
• Visualizing, specifying, constructing and documenting large
systems involves manipulating potentially large members of
classes, interfaces, components, nodes, diagrams, and other
elements

• It is therefore necessary to organize these things into larger

chunks

• In UML, grouping things have been planned for this purpose

• In all, there is one primary kind of grouping things, namely,

package
 Grouping Things: Package
• Package
– A package is a general purpose mechanism for organizing
elements into groups
– Graphically, package is rendered as a tabbed folder, usually
including only the name, sometimes references to its
contents

G r a p h ic s
 Annotational Things in UML
• Annotational things are the explanation parts of UML
models

• Designers follows these to describe, illuminate, and

remark about any elements in a model

• There is one primary kind of Annotational things

called note

• A note is simply a symbol for rendering a comment. It

has no semantic impact, i.e. its contents has no effect
on models.
 Annotational Things: Note
• Graphically a note is rendered as a rectangle with a “dog
earned ” corner, together with a textual or graphical comment

S im p le T e x t
U R L + T ext
IS D IT 6 0 1 0 5 # 2 0

C o m m e n ts
w it h im a g e s
 Relationships in UML
• A relationship is a concern among things

• There are four relationships in the UML

1. Dependency
2. Association
3. Generalization
4. Realization
 Relationships: Dependency
• Dependency
– A dependency is a semantic relation between two things in
which a change to one thing (the independent thing) may
affect another thing that use it , but not necessarily the
reverse
D ependency

V id e o C lip

p la y ( c : C lip )
s ta rt() I n d e p e n d e n t c la s s
s to p ()
r e s iz e ( )
re s e t()]
: H e re , if th e re is a c h a n g e in th e
c la s s C lip , th e o p e ra tio n p la y () in
D e p e n d e n t c la s s th e c la s s V id e o w ill b e e ffe c te d
 Relationships: Association
• Association

– An association is a structural relationship that describe a

set of links, a link being a connection among objects

– Aggregation is a special kind of association, representing a

structural relationship between a whole and its parts
 Relationships: Association
– Graphically, association/aggregation is denoted with
solid/diamond-edged line with label and multiplicities at
both ends of line

1 ..* W o rk s fo r
P e rs o n * C om pany
e m p lo y e e e m p lo y e r

A s s o c ia tio n

1 Has
U n iv e r s ity * D e p a rtm e n t

A g g r e g a tio n
 Relationships: Generalization
• Generalization
– A generalization is a generalized/specialized relationship in
which objects of the specialized elements (the child), are
suitable for objects of the generalized elements (the parent)

P a re n t

C h ild
 Relationships: Realization
• Realization
– A realization is a semantic connection
• between two things: interface, class, component
• between use-case and collaboration
etc.
IE E E M e m b e r S tu d e n t

: :
b io d a ta ( ) b io d a ta ( )
: :
 Diagrams in UML
• Any system can be viewed with five interrelated views

S tr u c tu r a l v ie w B e h a v io r a l v ie w

U s e r 's v ie w

Im p le m e n ta tio n v ie w E n v ir o n m e n ta l v ie w
 Diagrams in UML
• To represent each view, UML provides nine diagrams,
popularly termed as UML diagrams or UML artifacts
S tru c tu ra l v ie w B e h a v io ra l v ie w
 C la s s d a ig r a m s  A c t iv it y d a ig r a m s
 O b je c t d ia g r a m s  I n t e r a c t io n o v e r v ie w d ia g r a m s
 P a c k a g e d ia g r a m s  S e q u e n c e d ia g r a m s
 C o m p o s it e s t r u c t u r e d ia g r a m s  C o lla b o r a t io n d ia g r a m s
 S t a t e c h a r t d ia g r a m s
 T im in g d ia g r a m s
U s e r 's v i e w
 U s e c a s e d a ig r a m s

Im p le m e n ta tio n v ie w E n v iro n m e n ta l v ie w
 C o m p o n e n t d a ig r a m s  D e p lo y m e n t d a ig r a m s
 What is a Use Case Diagram?
• The use case diagram is a diagram to model the use case view
of a system. The behavior of the system under development
(i.e. what functionality must be provided by the system) is
documented in a use case diagram

• Use case diagram illustrates the systems intended functions, its

surroundings and relationship between the functions and
surroundings

• Example:
– On-line purchase (OLP) system
 On-Line Purchase (OLP) System
• Intended functions • Its surroundings
– Search items – Customer
– Place order – Manager
– Process order – Payment processor
– Control inventory
– Help on-line
Use Case Diagram of OLP System

S e a rc h ite m s

P la c e o rd e r

C u s to m e r
< < S y s te m > >
P ro c e ss o rd e r
P a y m e n t p ro c e s s o r

In v e n to ry c o n tro l

O n -lin e h e lp M anager
 Usage of Use Case Diagrams
1. Use case diagram depicts the
desirable functionalities (dynamic
aspects) of an information system
S e a rc h ite m s

2. Use case diagram very much P la c e o rd e r

resembles with the function C u s to m e r

< < S y s te m > >
oriented concepts (functional P ro c e ss o rd e r
P a ym e n t p ro c e s s o r

decomposition) of a system
In v e n to ry c o n tro l

3. Use case diagram is considered as O n -lin e h e lp M anager

the central part of the system model
and provides vehicle used by the
customer (or end users) and the
developer discuss the system’s
functionality and the behavior
 Different Components in the
Use Case Diagram

• Basic components in a use case diagram are

– Use cases
– Actors
– Associations
– System boundary boxes (optional)
– Packages (optional)
 Use Case in Use Case Diagram
• Use case
– A use case describes a functionality provided by the system. The
collection of use-cases for a system constitute all the defined ways the
system may be used

• Formal definition
• A use case is a sequence of transactions performed by the system
that yields a measurable result of values for a particular user (actor)

Notation: A use case is represented by an oval

P la c e o rd e r
 Actor in Use Case Diagram
• Actor
– An actor is a person, organization, or external system that plays a role
in one or more interaction with the system

• Note: Actors are not part of the system; they represent any one or any thing
that interact with the system

Notation: Actor can be represented as a stick man

 Association in Use Case Diagram
• Association
– Associations between actors and use cases are indicated in use
case diagrams by solid lines. An association exists whenever actor
involved with an interaction described by the use case
– Associations are modeled as lines connecting use cases and actor
to one another, with optional arrowhead on one end of the line.
The arrowhead is used to indicating the direction of the
relationship or to indicate the primary actor within the use case

Notation
P la c e o rd e r

C u s to m e r < < S y s te m > >

P a ym e n t p ro c e s s o r
 System Boundary Box in
Use Case Diagram
• System boundary
boxes
S e a rc h ite m s
– It is an optional thing
in a use case diagram
P la c e o rd e r
to draw a rectangle
around the use cases C u s to m e r
< < S y s te m > >
P ro c e ss o rd e r
and to indicate the P a y m e n t p ro c e s s o r

scope of the system R e le a s e 1

In v e n to ry c o n tro l

Notation R e le a s e 2
M anager
T a x c a lc u la tio n

R e le a s e 3

O n -lin e h e lp

R e le a s e 4
 Packages in Use Case Diagram
• Packages
– Packages enable to organize model elements into groups
Notation
Packages are depicted as a file folders and can be used on any
of the UML diagrams, including both use case diagrams, class
diagrams etc.

R e g is tr a tio n

Note: Usually package can be used when a UML diagram is quite large and
can not be accommodated on a single page, or organize a large diagram
into smaller ones
 Packages in Use Case Diagram
• Example

S tu d e n t R e g is tr a t io n
S y s te m

C o u rs e
R e g is tr a t io n B illin g
a llo t m e n t
 Scenario and Use Case
• Scenario
– A scenario is a sequence of steps describing an
interaction between a user and system

– Corresponding to a use case, there is a number of

scenarios. All scenario are described by means of a
textual description or other artifacts
 Example: Scenario and Use Case
Example: In OLP system
Some scenarios are
1. Customer browses though a catalog and select the items
2. Customer options for check out
3. Customer fills shipping information ( address, date of delivery,
email, etc.)
4. System present full pricing information, date of delivery, etc.
5. Customer fills credit card information
6. System authorizes purchase
7. System confirms sales immediately
8. System confirm sale by sending email by customer

Note: From one scenario, another scenario can arise. For example: at 3 incomplete
information, at 6 authorization fails etc.
How to Create a Use Case Diagram?
• Three steps
1. Identify all actors
2. Identify all use cases
3. All associations between actors and use cases

• Study carefully the requirement analysis and specification

(SRS) to identify all these
 Identifying all Actors
• The following questions may be used to help identify the actors for a
system
– Who will use the system?

– Where in the organization in the system used?

– Who will supply, use, update the information in the system?
– Who will support and maintain the system?
– Does the system use external resource?
– Does one person play several roles?
– Does several persons play several roles ?

….. etc.
 Identifying all Use Cases
• The following questions may be used to help identify the actors for a
system
– What are the functional requirements?

– What are the tasks of each actor?

– Will any actor create, change, store, remove, or read information in the
system?

– What use case will accomplish the actors requirements?

….etc.
 Identifying all Associations
• There will be an association between an actor and a use
case, if there is

– any correspondence/communication between the two

– information storing/updating

….etc.
 Use Case Relationships
• In addition to association relationship ( which may exist
between an actor and use-case) to represents a communication
between an actor and a use-case, there are other three types of
relationships may exist between use-cases

– Include

– Extend

– Generalization
 Include Relationship
• A use case in UML is same as the function in
structured design

• Like structured design a use case can be

decomposed into sub use cases

– Include
• To represent that a use case is composed of (reuse)
 Include Relationship
• Further
– Multiple use cases may share a piece of some
common functionality. This functionality is placed
in a separate use case rather than documenting it in
every use case that needs it

– Include relationships are created between the new

use case and any other use case that “uses” its
functionality
Example: Include Relationship

< < in c lu d e > >

B illin g C ash paym ent

e>> S e a rc h B o o k
clud
<<in
Is s u e B o o k

< < in c lu d e > >

U p d a te B o o k
 Extend Relationship
– The extended relationship is used to describe a variation on
normal behavior and one wish to use the more controlled
form. Usually extended relationship is considered to depict
the following situations

• Optional behavior

• Behavior that run only under certain consideration

• Several control flows may be run based on actor selection

Example: Extend Relationship

> C ash paym ent

i n cl ude>
<<
B illin g
<<ex
te nd>>
O th e r p a y m e n ts

de>> C ash paym ent

<<inclu

B illin g <<ex
tend> > C heque paym ent
>
c lu de>
<<in
O th e r p a y m e n ts <<in
c lude
>>
C r e d it c a r d p a y m e n t
 Example: Extend Relationship
G e t R e g is tr a t io n

< < e x te n d > >

S e c u r it y C h e c k

P ro c e s s O rd e r
I f a s t u d e n t is
w ith f o r ie g n v is a
< < e x te n d > > < < e x te n d > >

C r e d it C a r d V a lid a t io n P a y R e b a te

If th e c u s to m e r
T o a s p e c ia l t y p e
is n o t a r e g u la r
o f c u s to m e r
c u s to m e r
 Generalization Relationship
• Generalization relationship is very similar to the inheritance
relationship as in classes

• Inheritance relationship is used to model generalization/

specialization of use case or actors

Pay Fees

C r e d it C a r d D e m a n d D ra ft e B a n k in g
 Generalization Relationship
• The generalization relationship can also be extended to actor

S tu d e n t
S tu d e n t

In t e r n a tio n
s tu d e n t
UG PG R e s e ra c h
 Use Case Packaging
• Packaging is the mechanism in UML to manage complexity

• When there are too many use cases in the use case diagram, it
is better to package the related use cases so that it can be better
documented
Example: Use Case Packaging

U se case 1 U se case 2

U se case 3

U s e c a s e 3 .1 U s e c a s e 3 .2

U s e c a s e 3 .3

U s e c a s e 3 .3 .1 U s e c a s e 3 .3 .2

U s e c a s e 3 .3 .3
 What is a Class Diagram?
• A class is a structural component of any object oriented system. The class
diagram used to model the structural view of the underlying system

• A class diagram is a collection of all possible classes in a system and

relationships among them

• The different relations may occur in a class diagram are

– Association/Aggregation
– Generalization/Specialization

• Class diagrams also show the attributes and operations of a class. Also it
can depict the navigability (direction of trace ability) and the constraints
that apply to the way objects are connected
 Detail Class Diagram
• Class diagram also shows the attributes and operations of classes

B ook
Nam e
b o o k N a m e : S t r in g

Attributes
A u t h o r s : S t r in g
A ttr ib u te s A c c n N o :S t r in g
d a te O fIs u u e : D a te
is s u e T o :P e r s o n
d a te O fR e tu rn : D a te

Operations
O p e r a tio n s
is s u e ( b o r r o w e r I d : P e r s o n I D )
r e t u r n ( ) :flo a t
r e s e r v e ( b o r r o w e r I D :P e r s o n ,p r io r it y : in t )
e d it B o o k ( )
rem o v eB o o k ()

• Think: For the class Server, what are the attributes? operations?
 Visibility
• The notation that precedes the attribute or operation name indicates the
visibility of the element, if the + symbol is used the attribute or operation has
a public level of visibility, if a - symbol is used the attribute or operation is
private. In addition the # symbol allows an operation or attribute to be defined
as protected and the ~ symbol indicates package visibility.
 Relation Association
• An association implies two model elements have a relationship - usually
implemented as an instance variable in one class. This connector may include
named roles at each end, cardinality, direction and constraints. Association is the
general relationship type between elements. For more than two elements, a diagonal
representation toolbox element can be used as well. When code is generated for
class diagrams, associations become instance variables in the target class.

A s s o c ia tio n n a m e
C la s s A C la s s B
R o le A R o le B
Aggregation and Composition

A g g r e g a tio n n a m e
C la s s A C la s s B

C o m p o s itio n n a m e
C la s s A C la s s B
 Association Class

A s s o c ia tio n n a m e
C la s s A C la s s B

A ssocN am e

W o rk s fo r
C la s s A C la s s B
E m p lo y e e D e p a rtm e n t

A ssocN am e
W o rk s
 Multiplicity
cc

1
C la s s E x a c tly o n e

*
C la s s M a n y (z ero o r m o re }

0 ..1
C la s s O p tio n a l(z e ro o r o n e )

1 ..*
C la s s O n e o r m o re
Multiplicity & Association
 Example of a Class Diagram

has
IIT D e p a rtm e n t
1 ..*
1
1 ..* 1 ..* 1 ..*

chairs
offers

works in
enrolled in

* 1 ..* 0 ..1 H O D
a tte n d s te a c h e s *
S tu d e n t C o u rs e F a c u lty
* * * 1 ..*
Another Example
 Example: Internet
• ? Internet
– Network of networks (is a collection of servers)
– A collection of web pages

• This internet can be thought of an object-oriented system

– ? Use case diagram
– ? Activity diagrams
– ? State-chart diagrams
etc…..

• Let’s consider the class diagram of the system Internet

 Example: Internet

* lin k s 1
W eb page S erv er
*

has
1
N e tw o rk

• This class diagram shows a collection of all possible classes in the system
namely, the Internet and relationships among them

• This simple class diagram shows the association and aggregation

relationship
Interface: Generalization & Specialization

C la s s S

C la s s A C la s s B C la s s C

C la s s X C la s s Y
 Another view of Internet Class Diagram
IIS A pache

* lin k s 1
W eb page S e rv e r
*

has
1
S ta tic D y a n m ic N e tw o rk

.a s p .js p .p h p LA N M A N W A N

• This class diagram shows the generalization/specialization relationship

Example: Class Diagram in OLP System

* 1
O rd e r C u s to m e r
1

P e rso n C o rp o ra te
*
1 0 ..1
1 *
Ite m L is t P ro d u ct E m p lo y e e
 What is an Object Diagram
• An object is an instance of a class

• An object diagram is a collection of object and its

relationships among them, just like class diagrams

• More precisely, an object diagram is a snapshot of the objects

in a system at a particular point of time

• Since object diagram shows instances rather than classes, an

object diagram is often called an instance diagram

• Usually, an object diagram is used to provide an example

configuration of objects
 Example: Object Diagram
• Let us consider a composition of a class in OLP system

p u rc h a s e 1
O rd e r * C u s to m e r
1

P e rso n C o rp o ra te
*
0 ..1
* 1
Ite m L is t * P ro d u ct E m p lo y e e

• From the application point of views, the customer class signifies that a customer is
either a person or an organization or an employee of an organization
 Example: Object Diagram
• Further consider a particular snapshot at an instance

ram: Person C u s to m e r
sita: Person
bhim: Employee
arjun: Employee P e rso n C o rp o ra te
oldIndia: Corporate [r a m , s it a ] [o ld I n d ia , n e w In d ia ]
newIndia: Corporate
E m p lo y e e

[b h im , a r ju n ]

Further assume that bhim and arjun are the employees of oldIndia
 Example: Object Diagram
• The object diagram for the above snapshot will look like this

o ld In d ia : C o rp o ra te n e w In d ia : C o rp o ra te

b h im : E m p lo y e e a rju n : E m p lo y e e

s ita : P e rs o n
ra m : P e rso n
 More Example: Object Diagram
• Let’s consider a small modification in the class diagram

p u rc h a s e fo r
C u s to m e r *

1
P erso n C o rp o ra te

E m p lo y e e

• This signifies that a customer being a corporate can purchase for others,
say person, organizations
 More Example: Object Diagram
• A snapshot under this modified situation is

ram: Person
C u s to m e r
sita: Person
bhim: Employee
arjun: Employee 1
P e rso n C o rp o ra te
oldIndia: Corporate
[r a m , s ita ] [in d ia , o ld In d ia , n e w In d ia ]
newIndia: Corporate
india: Corporate E m p lo y e e

[b h im , a r ju n ]

Here, suppose india purchase for oldIndia and newIndia

More Example: Object Diagram
in d ia : C o rp o ra te

O ld In d ia : C o rp o ra te N e w In d ia : C o rp o ra te

b h im : E m p lo y e e a rju n : E m p lo y e e

s ita : P e rs o n
ra m : P erso n
 Interaction Diagrams
• Interaction diagrams model how groups of objects collaborate
in some behavior

• There are two types of interaction diagrams

– Sequence diagrams

– Collaboration diagrams
 What is a Sequence Diagram?
• A sequence diagram shows object interactions arranged in
time sequence

• It depicts the object and classes involved in the scenario and

the sequence of messages exchanged between the objects
needed to carry out the functionality of the scenario

• Typically, a sequence diagram captures the behavior of a

single activity or a use case
 Basic of a Sequence Diagram
• A sequence diagram is a two dimensional chart

• The chart is read from top to bottom

• The objects participating in the interaction are shown at the top of the chart
as boxes attached to a vertical-dashed line

• Inside the box the name of the object is written with a colon separating it
form the name of the class and both the name of the class and object are
underlined

• Some times an anonymous object (only class name and underlined) is also
used
 Life Line in a Sequence Diagram
• A lifeline represents an individual participant in a sequence diagram. A
lifeline will usually have a rectangle containing its object name. If its name
is self then that indicates that the lifeline represents the classifier which
owns the sequence diagram
 Life Line in a Sequence Diagram
• Sometimes a sequence diagram will have a lifeline with an actor element
symbol at its head. This will usually be the case if the sequence diagram is
owned by a use case. Boundary, control and entity elements form
robustness diagrams can also own lifelines
 Example: Objects and Life Line

m ih ir: S tu d e n t a u tu m n 0 6 : C o u rs e M g r : C o u rse

c la s s n a m e
a n o n y m o u s o b je c t
o b je c t n a m e

v e r t i c a l - d a s h e d l i n e s a t t a c h e d t o o b je c t s
 Objects and Life Time
• The objects appearing at the top signifying that the object already existed
when the use case execution was executed.

• However, if some object is created during the execution of the use case
and participates in the interaction, then that object should be shown at the
appropriate place on the diagram where it was created

• The vertical dashed line in the sequence diagram is called the object’s life
time. The life time indicates the existence of the object at any particular
point of time

• A rectangle is used on the life time to indicate the activation symbol and
implies that the object is active as long as the rectangle exists
 Example: Object’s Life Time
m ih ir: S tu d e n t

o b je c t s t a r t s a n
a c tiv ity h e r e

a n o b je c t a p p e a r s
h e re

o b je c t f i n i s h e s a n
a c tiv ity h e r e
L ife tim e

a u tu m n 0 6 : C o u rs e M g r

o b je c t e x p i r e s h e r e
 Start and End of Life Line
• A lifeline may be created or destroyed during the timescale represented by
a sequence diagram. In the latter case, the lifeline is terminated by a stop
symbol, represented as a cross. In the former case, the symbol at the head
of the lifeline is shown at a lower level down the page than the symbol of
the object that caused the creation. The following diagram shows an object
being created and destroyed
 Messages in Sequence Diagrams
• Two objects in a sequence diagram interacts with passing
messages between them

• Each message is indicated as an arrow between the lifelines of

two objects

• The order of message is very important in the sequence

diagram. They should appear in chronological order from top
to the bottom. That is, reading the diagram from the top of the
bottom would show the sequence in which the message occurs

• Each message is labeled with the message name

Example: Message in a Sequence Diagram

m ih ir: S tu d e n t a u tu m n 0 6 : C o u rs e M g r

1
r e q u e s tE n r o ll( )
2

s e a rc h ()
c o n fir m E n r o ll( )
T h r e e m e s s a g e s a re in
3 c h r o n o lg ic a l s e q u e n c e

T w o o b je c t a r e c o m m u n i c a t i n g
b y p a s s in g m e s s a g e s
 More on Messages
• Messages can be synchronous or asynchronous; call or signal. In the
following diagram, the first message is a synchronous message (denoted by
the solid arrowhead) complete with an implicit return message; the second
message is asynchronous (denoted by line arrowhead) and the third is the
asynchronous return message (denoted by the dashed line)
 More on Messages
• Messages can be lost or found. Lost messages are those that are either sent
but do not arrive at the intended recipient, or which go to a recipient not
shown on the current diagram. Found messages are those that arrive from
an unknown sender, or from a sender not shown on the current diagram.
They are denoted going to or coming from an endpoint element
 Self or Recursive Messages
• A self message can represent a recursive call of an operation, or one
method calling another method belonging to the same object. It is shown as
creating a nested focus of control in the lifeline’s execution occurrence
 Controlled Messages

• Some control information can also be included

• Two types of control information are particularly known:

1. A condition (e.g. [vacant = true]) indicates that a message is sent, only

if the condition is true

2. An iteration marker (*) is used to indicate that the message is to be

repeated many times to multiple receiver objects (e.g. when it is
required to iterate over a collection or an array of elements)
 Example: Controlled Message

m ih ir: S tu d e n t a u tu m n 0 6 : C o u rs e M g r : C o u rse

r e q u e s tE n r o ll( )

s e a rc h ()
[v a c a n t] c o n fir m E n r o ll( )

g e tC o u rs e ()
* g e tC o u rs e ()

s e n d th is m e s s a g e if th is
c o n d itio n is tr u e s e n d m e s s a g e s to a ll c o u r s e
o b je c t s
Duration and Timing Constraints
• By default, a message is shown as a horizontal line. Since the lifeline
represents the passage of time down the screen, when modeling a real-time
system, or even a time-bound business process, it can be important to
consider the length of time it takes to perform actions. By setting a
duration constraint for a message, the message will be shown as a sloping
line
 ATM PIN Validation
a : c a rd R e a d e r b : s e s s io n M g r c : d is p la y M g r d : keyR eader e : aBank

c a rd In fo ()
b e g in
s e s s io n
[ ! v a lid A T M c a r d ]
e je c t ( )
ch e c k C a rd ()

sta tu s
[ s t a t u s .is S t o le n ]
r e t a in ( )

[ s t a t u s .c lo s e A c c o u n t ]
e je c t ( )
[ ! v a lid P I N & & t r y < 4 ]
re q u e stP IN ()

re a d P IN ()
v a lu e P I N

v e r ify P I N ( )
[ ! v a lid P I N ]
e je c t ( ) x x
d is p la y H e llo ( )

x x

x
Use Case Registration of OLP
Use case: Registration

Scenario 1: Customer is a staff member

Select customer type as staff.
Get data for a customer as staff.
Check the validity of the staff customer.
Alternative 1.1: Disqualify the validity of a staff
Message “Registration fail”.
Alternative 1.2: Qualify the validity of a staff
Check for already registered customer.
Alternative 1.2.1: Registration exist
Message “Registration fail”.
Alternative 1.2.1: Registration does not exist
Message “Registration successful”.
Create a new customer c.
Update record with c.
Scenario 2: Customer is other than staff
Select customer type as other.
Get data for a customer as other.
Check for already registered customer.
Alternative 2.1: Registration exist
Message “Registration fail”.
Alternative 2.2: Registration does not exist
Message “Registration successful”.
Create a new customer c.
Update record with c.
Sequence Diagram of Registration
a : C u s to m e r b : In te rfa c e M g r c: R egnM gr d : S y s te m M g r

b e g in s e s s io n re g n R e q u e st()

g e tC u sto m e rT y p e ()
in p u t T y p e ( )
C u sto m e rT y p e = re a d D a ta ()

[C u s to m e r T y p e = s ta ff]
g e tS ta ffD a ta ()
in p u t S t a ffD a t a ( )
c d = s ta ffC u s to m e rD a ta ()
s ta tu s 1 = c h e c k S ta ff(c d )
[ s t a t u s 1 = in v a lid ]
d is p la y M s g ( R e g n . fa il)
[ s t a t u s 1 = v a lid ]
[ s t a t u s 2 = e x is t ] s t a t u s 2 = c h e c k E x is t ( c d )
d is p la y M s g ( R e g n . f a il)
[ s t a t u s 2 = n o t E x is t ]
d is p la y M s g ( R e g n . s u c c e s s ) c 1 = c re a te C u sto m e r(c d )
u p d a te R e c o rd (c 1 )
[C u sto m e rT y p e = o th e r]
in p u t O t h e r D a t a ( ) g e tO th e rD a ta ()
c d = o th e rC u sto m e rD a ta ()
s t a t u s 2 = c h e c k E x is t ( c d )
[ s t a t u s 2 = e x is t ]
d is p la y M s g ( R e g n . f a il) [ s t a t u s 2 = n o t E x is t ]
c 2 = c re a te C u sto m e r(c d )
d is p la y M s g ( R e g n . s u c c e s s )
u p d a te R e c o rd (c 2 )
Use Case Place Order in OLP
Use case: Order Items

Scenario 1: Option is new

Prompt for “Registration”
Call “Registration”
Display registration status
Exit

Scenario 2:Option is login

Call “Check In”
Alternative 2.1: Login is valid
Prompt for “Item Details”
Call “Create Order”
Display order status
Exit
Alternative 2.2: Login is invalid
Display login fail
Exit
 Process Order in OLP System

• To illustrate the drawing of a sequence diagram, let us consider the use

case “Process Order ” in the OLP system

• The “Process Order” use case is proposed to have a following behavior (or
scenario)

• orderEntry: Window
– this object will get an order from a customer

• anOrder: Order
– receives an order from a customer (via orderEntry object)

• orderSet: ItemList
– an object is a list of items is to be processed
 Sequence Diagram in OLP System

• stockist: InventoryManage
– object responsible for checking stock, supply stock, request for
inventory etc.

• :OrderInfo
– containing the orders information in a queue

• confirmMessage: Message
– message objects for sending confirmation message

• The sequence diagram for Process Order use case can be drawn as follows.
Sequence Diagram of Process Order use case
in OLP System
o rd e rE n try : C u s to m e r a n O rd e r: O rd e r o rd e rS e t: Ite m L is t s to c k is t: In v e n to ry M a n a g e r : O rd e rIn fo

c re a te () * s e tO rd e r()

s ta tu s = in v e n to r y C h e c k ()
[s ta tu s = F A L S E ]
e n q u e u e O rd e r()

a v a ila b le =
c h e c k S u p p ly ( )

[a v a ila b le = T R U E ] d e Q u e u e ()
r e p ly E s tim a te ( )
re p ly E s tim a te ( ) e s tim a te O rd e r()

a c c e p t()

c o n firm O rd e r:M e s s a g e
a c c e p t()

c o n fir m ( )
c o n firm ()
 Use of Sequence Diagram
• From the sequence diagram of “Process Order” use case, it is evident that
the diagram is easy to understand and has immediate appeal. This is the
great advantage of the sequence diagram

• However, in some situation, there may be a lot of small methods in

different classes, and at times it can be very tricky to figure out the overall
sequence of behaviors. in fact, so many details can be resolved during
coding only

• The development of sequence diagram would help a designer in

determining the responsibilities of the different classes. i.e. what methods
should be supported by each class, sequence of message passing etc.
What is a Collaboration Diagram
• The second form of the interaction diagram is the
collaboration diagram

• A collaboration diagram shows both the structural and

behavioral aspects, explicitly.
– The structural aspect of a collaboration diagram consists of object and
the links existing between them

– The behavioral aspect is described by a set of messages exchanged

among the different collaborations

• In the collaboration diagram, an object is also called

collaborator
 Basic of Collaboration Diagram
• A collaboration diagram contains the following things:

– Objects drawn as rectangles

– Links between the objects shown as lines the linked objects

– Messages shown as text and an arrow that points from a client object to
a respondent object

• Let us consider an example of a collaboration diagram in

Process Order use case of the OLP system
Example: Collaboration Diagram
1 : c re a te ()
o rd e rE n try :C u s to m e r

a n O rd e r:O rd e r
2 : * [fo r a ll ite m in O r d e r ]

s e tO rd e r()
3 : s ta tu s = in v e n to r y C h e c k ( )
o rd e rS e t:Ite m L is t 4 : a v a ila b le = c h e c k S u p p ly ( )

:In v e n to ry M a n a g e r
[s ta tu s ]
new [a v a ila b le ]
new

:C o n firm O rd e r :O rd e rIn fo
 Note: Collaboration Diagram
• In collaboration diagram, the sequence indicated by
numbering the messages

• Here, we have used the simple numbering scheme. The UML

also allows decimal scheme [as in DFD] to document the
hierarchical messaging
 Sequence Diagram vs. Collaboration Diagrams

• There are two basic features by which Sequence

diagram differs from the Collaboration diagram
– Object life time
• In sequence diagram, there is a object line represent the existence
of an object over a period of time. There is no object life time in
collaboration diagram

– Focus of control
• In sequence diagram, there is the focus of control to show the
period of time during which object is performing an action. There
is no focus of control in collaboration diagram
 Sequence Diagram vs. Collaboration Diagrams

• Sequence diagram provides a way to look at scenario in a time

based order – what happen after what etc. Customer easily can
read and understand this type of diagram. Hence, they are very
useful in the early analysis phases as well as in coding phase

• Collaboration diagram tend to provide the big picture for a

scenario since the collaborations are organized around the
object links to one another. These diagrams seem to be used
more in the design phase of development
 What is an Activity Diagram?
• Activity diagrams represent the dynamic (behavioral) view of a system

• Activity diagrams are typically used for business (transaction) process

modeling and modeling the logic captured by a single use-case or usage
scenario

• Activity diagram is used to represent the flow across use cases or to

represent flow within a particular use case

• UML activity diagrams are the object oriented equivalent of flow chart and
data flow diagrams in function-oriented design approach

• Activity diagram contains activities, transitions between activities, decision

points, synchronization bars, swim lanes and many more…
Student Enrollment in IIT (SEIIT)

S y s te m

IIT
E n ro llm e n t
S tu d e n t R e g is t r a r
< < in c lu d e > >

C o u rs e re g is tra tio n
 SEIIT System
• Here different activities are:
– Received enrollment form filled by the student
• Registrar checks the form
• Input data to the system
• System authenticate the environment
– Pay fees by the student
• Registrar checks the amount to be remitted and prepare a bill
• System acknowledge fee receipts and print receipt
– Hostel allotment
• Allot hostel
• Receive hostel charge
• Allot room
– Medical check up
• Create hostel record
• Conduct medical bill
• Enter record
– Issue library card
– Issue identity card
Activity Diagram for the Use Case in
SEIIT
R e c e iv e d f o r m

H o s te l
P a y m e n t fe e s M e d ic a l c h e c k
a llo t m e n t

Is s u e id e n tit y I s s u e lib r a r y
c a rd c a rd
 Basic Components in an Activity Diagram

• Initial node
– The filled circle is the starting point
of the diagram
R e c e iv e d f o r m
• Final node
– The filled circle with a boarder is the
ending point. An activity diagram
can have zero or more activity final P a y m e n t f e e s H o s te l
M e d ic a l c h e c k
state. a llo t m e n t

• Activity
– The rounded circle represents
activities that occur. An activity is I s s u e id e n t it y I s s u e lib r a r y
not necessarily a program, it may be c a rd c a rd

a manual thing also

• Flow/ edge
– The arrows in the diagram. No label
is necessary
 Basic Components in an Activity Diagram
R e c e iv e d f o r m
• Fork
– A black bar ( horizontal/vertical )
with one flow going into it and
H o s te l
several leaving it. This denotes the P a y m e n t fe e s
a llo t m e n t
M e d ic a l c h e c k

beginning of parallel activities

• Join
– A block bar with several flows I s s u e id e n t it y Is s u e lib r a r y
c a rd c a rd
entering it and one leaving it. this
denotes the end of parallel activities
• Merge
– A diamond with several flows
entering and one leaving. The
implication is that all incoming flow
to reach this point until processing
continues
 Basic Components in an Activity Diagram

• Difference between Join and Merge

– A join is different from a merge in that the join synchronizes two

inflows and produces a single outflow. The outflow from a join cannot
execute until all inflows have been received

– A merge passes any control flows straight through it. If two or more
inflows are received by a merge symbol, the action pointed to by its
outflow is executed two or more times
 Basic Components in an Activity Diagram

• Decision
– A diamond with one flow
entering and several leaving. The
flow leaving includes conditions
as yes/ no state
• Flow final
– The circle with X though it. This
indicates that Process stop at this
point
• Swim lane R e c e iv e d f o r m

– A partition in activity diagram P a y m e n t fe e s

H o s te l
a llo t m e n t
M e d ic a l c h e c k

by means of dashed line, called

swim lane. This swim lane may I s s u e id e n t it y I s s u e lib r a r y
c a rd c a rd

be horizontal or vertical
Detailed Activity Diagram of SEIIT

1
R e c e iv e d f o r m

H o s te l
P a y m e n t fe e s M e d ic a l c h e c k
a llo tm e n t

2
I s s u e id e n t it y Is s u e lib r a r y
c a rd c a rd
 Detailed Activity Diagram of SEIIT

F ill-in C heck
fo rm fo rm

[In c o r re c t]
R e g re t m e ssa g e
[C o rre c t]

D is p la y s tu d e n t [N o t F o u n d ]
sc re e n
V e rify th e [F o u n d ]

In p u t s tu d e n t a p p lic a tio n s
in fo rm a tio n
C re a te re c o rd 1
S e a rc h fo r S tu d e n t [M a tc h ]
s e le c tio n lis t [N o M a tc h ]

R e g re t
re g is tra tio n
 Detailed Activity Diagram of SEIIT

D is p la y C a lc u la te
1 e n ro llm e n t f o rm re g is tra tio n fe e s

D is p a ly fe e s
p a y a b le s c re e n
P ro c e ss
paym ent
P a y fee 2
P rin t re c e ip t
 Activity Diagram of SEIIT with Swim Lane
Student

F ill- in
fo rm
V e rify th e [F o u n d ]

[In c o r re c t]
a p p lic a tio n s
[N o t F o u n d ]

C heck
R e g ret m e ssa g e
Registrar

fo rm
[C o rr e c t]

D is p la y s tu d e n t
sc ree n

C re a te re c o rd
System

In p u t s tu d e n t
in fo rm a tio n
[M a tc h ]
1
S e a rc h fo r S tu d e n t
s e le c tio n lis t [N o M a tc h ]

R e g ret
re g is tra tio n
 Object and Object Flow
• An object flow is a path along which objects can pass. An
object is shown as a rectangle
• An object flow is shown as a connector with an arrowhead
denoting the direction the object is being passed.
 Input and Output Pin
• An object flow must have an object on at least one of its ends.
A shorthand notation for the above diagram would be to use
input and output pins
 Data Store
• A data store is shown as an object with the «datastore»
keyword
 Expansion Region
• An expansion region is a structured activity region that executes multiple
times. Input and output expansion nodes are drawn as a group of three
boxes representing a multiple selection of items. The keyword iterative,
parallel or stream is shown in the top left corner of the region
 Exception Handling
• Exception Handlers can be modeled on activity diagrams as in
the example below
 Interruptible Activity Region
• An interruptible activity region surrounds a group of actions that can be
interrupted. In the very simple example below, the Process Order action
will execute until completion, when it will pass control to the Close Order
action, unless a Cancel Request interrupt is received which will pass
control to the Cancel Order action
 An Example
• Identify the business logic in the activity diagram shown below
 Importance of Activity Diagram
• An activity diagram can depict a model in several ways

• It can also depicts “Basic course of action” as well as “detailed courses”

• Activity diagram can also be drawn that cross several use cases, or that address just
a small portion of use case

• Activity diagrams are normally employed in business process modeling. This is

carried out during the initial stages of requirement analysis and specification

• Activity diagrams can be very useful to understand the complex processing

activities involving many components

• The activity diagram can be used to develop interaction diagrams which help to
allocate activities to classes
 What is a Statechart Diagram?
• A state-chart diagram is used to model the dynamic aspects of the system.
The basic idea is same as the state machine in Finite Automata

• We can draw state diagrams for each object involved in the system

• An object may be in several states of its life time. When a message arrives to
an object (event) it undergoes certain operations (action) or changes its state

• A state diagram shows how an object will react to the arrival of an event

– Each reaction may be a sequence of actions, possibly accompanied by a transition

from one named state to another

– An event represents the receipt of a signal, or the effect of an operation call

– An action represents the sending of a signal, or the call of an operation

 General Structure of a Statechart Diagram
• A statechart diagram typically look like this

s im p le s t a t e

S ta te 1 S ta te 2
E v e n t1 /A c tio n A

in it ia l s t a t e

E v e n t 2 [g u a r d ] / A c t io n B
E v e n t3

S ta te 3

c o m p o s ite s ta te
f in a l s t a te
 Basic Components in a Statechart Diagram
• Two basic elements are there
– Rounded rectangle box representing the state
Nam e

– Labeled arrow indicating the transitions

E v e n t [g u a r d c o n d itio n ] [/A c tio n ]

• Here, event is the message that is sent

• guard condition is the Boolean expression of attribute values that allows a
state transition only if the condition is true
• An action is the behavior that occurs when the state transition occurs
 Detail State in a State-Chart Diagram
• Detail of state is shown below E vent /A c tio n B

N am e S ta te 1
E n try /A c tio n A E x it /A c tio n C
S ta te V a r ia b le s
E n tr y /A c tio n A
in t e r n a l a c t iv it ie s E v e n t /A c tio n B
E x it /A c tio n C

• Entry actions: that are common to every incoming transition

• Exit actions: that are common to every outgoing transition
• Self-transition: action within the state itself

• If there is no guard or if the guard is true, then for the event the actions will
be followed and it can enter [exit] to [from] a state or remain in the same
state
 Statechart Diagram: Example
• Suppose, a COURSE is an object in a usual “Course Registration” use case
(consider the SEIIT). Following is a state diagram to model the behavioral
view of the object COURSE
W ith in
d e a d lin e
P ro p o s e
C o u rs e o ffe r

C o u rs e o p e n
S c h e d u le
fo r
r e g is tr a tio n
D is p a ly
C o u rs e L a s t d a te
a s s ig n e d E n r o ll W ith d r a w

F u ll C lo s e c o u r s e
C o u r s e f u ll
r e g is tr a tio n

S tu d e n t d ro p p e d
V a c c a n c y e x is t

S e s s io n s ta r te d
C o u r s e b e in g
ta u g h t

E v a lu a tio n /S e s s io n e n d

D is p la y Feedback
m a rk s
 Advantages of Statechart Diagram
• A statechart diagram is used to model how the state of an
object changes in its life time

• Statechart diagrams are good describing how the behavior of

an object change across several use case executions

• However, if we are interested in modeling some behavior that

involves the several objects collaborating with each other, the
statechart diagram is not appropriate
 Choice Pseudo-State
• A choice pseudo-state is shown as a diamond with one transition arriving
and two or more transitions leaving. The following diagram shows that
whichever state is arrived at after the choice pseudo-state is dependent on
the message format selected during execution of the previous state
 Choice Junction-State
• Junction pseudo-states are used to chain together multiple transitions. A
single junction can have one or more incoming and one or more outgoing
transitions and a guard can be applied to each transition. Junctions are
semantic-free; a junction which splits an incoming transition into multiple
outgoing transitions realizes a static conditional branch as opposed to a
choice pseudo-state which realizes a dynamic conditional branch
 History State
• A History State is used to remember the previous state of a state machine
when it was interrupted. The following diagram illustrates the use of
history states. The example is a state machine belonging to a washing
machine
 Concurrent State
• A state may be divided into regions containing sub-states that exist and
execute concurrently. The example below shows that within the state
"Applying Brakes", the front and rear brakes will be operating
simultaneously and independently. Notice the use of fork and join pseudo-
states rather than choice and merge pseudo-states. These symbols are used
to synchronize the concurrent threads