Classification of UML Diagrams
Behavioral and Structural
Perspectives
of
Unified Modeling Language
UML
Any software system can have two aspects, static
and dynamic.
So a model is considered as complete when both
the aspects are covered fully.
Structural Diagrams
The structural diagrams represent the static
aspect of the system.
These static aspects represent those parts of a
diagram which forms the main structure and
therefore stable.
Class Diagrams,
Object Diagrams,
Package Diagrams,
Component Diagrams
Deployment Diagrams
Behavioral Diagrams
Behavioral diagrams basically capture the dynamic
aspect of a system.
Dynamic aspect can be described as the
changing/moving parts of a system.
Use case diagram
Sequence diagram
Collaboration diagram
State chart diagram
Activity diagram
Behavioral Diagram I
Use case diagram
Use case Diagrams
Use cases help with some of the most difficult
aspects of a development process:
model sequences of actions that are carried out by
the system and that provide an observable result
to someone or something outside the system;
 provide the basis for determining the interfaces to
the system;
 model alternative scenarios for specific use cases
that may result in different sequences of actions;
Use Case Diagrams
Use case diagrams are a set of use cases,
actors and their relationships.
They represent the use case view of a system.
A use case represents a particular
functionality of a system.
Use case diagram is used to describe the
relationships among the functionalities and their
internal/external controllers.
These controllers are known as actors.
Use cases
Define a piece of behavior of an “entity” without
revealing the internal structure of the entity.
The specification of sequences of actions, including
variant sequences and error sequences, that a
system or a class can perform by interacting with an
external entity.
Graphically, a use case is only given by
Actors
Actor represents a coherent
set of roles that users of use
cases play when interacting
with these use cases
An actor represents a role
that a human, a hardware
device, or even another
system plays with a system
Associations between Actors and Use
Cases
Denote the participation of an actor in a use case, i.e.
instances of the actor and instances of the use case
communicate with each other.
Are the only relationships between actors and use
cases.
May have adornments (such as multiplicity and
names).
Use Case Diagram
A use case diagram is a diagram that shows a
set of use cases and actors and their
relationship.
Use case diagrams commonly contain Use
cases, Actors, Dependency, Generalization,
and Association relationships
Use case diagrams are applied to model the
static use case view of a system
 by modeling the context of a system and
 by modeling the requirements of a system
Communication between Actors and
Use Cases
One actor may communicate with several use
cases of an entity, i.e. the actor may request
several services of the entity.
One use case communicates with one or
several actors when providing its service.
Two use cases specifying the same entity
cannot communicate with each other since
each of them individually describes a
complete usage of the entity.
Modeling the Requirements of a System
Establish the context of the system by identifying
the actors that surround it
For each actor, consider the behavior that each
expects or requires the system to provide
Name these common behaviors as use cases
Factor common behavior into new use cases that are
used by others
 Factor variant behavior into new use cases that
extend more main line flows
Model these use cases, actors, and their
relationships in a use case diagram
Modeling the Requirements of a
System
Identifying Use Cases
Identify potential services by answering the
following questions from the point of view of
each actor:
 What is the actor trying to accomplish?
What does the actor need to be able to do?
What are the main tasks of the actor?
What information does the actor require from the
system?
What information does the actor provide to the
system?
Modeling the Context of a System
Identify the actors that surround the system by
considering which groups
require help from the system to perform their tasks;
are needed to execute the system’s functions;
interact with external hardware or other software
systems;
perform secondary functions for administration and
maintenance
Organize actors that are similar to one another in
a generalization / specialization hierarchy
Populate a use case diagram with these actors
and specify the paths of communication from
each actor to the system’s use cases
Modeling the Context of a System
Modeling the Behavior of an Element
EXAMPLE
Organizing Use cases
Generalization between Actors
Organizing Use Cases
by adding <<include>>, <<extend>> and
generalization relationships between use cases.
 by grouping them into packages to define
functional blocks of higher level.
Generalization between Use Cases
<<include>> relationships between use
cases
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.
<<include>> relationships between
use cases
The behavior of the include use case is common to two or
more use cases
The result of the behavior that the include use case
specifies is important to the base use case
An include relationship points from the
CheckorderStatus use case to the Login use case to
indicate that the CheckOrderStatus use case always
includes the behaviors in the Login use case.
<<extend>> relationships between use
cases
The extend relationship contains a condition and
references a sequence of extension points in the target
use case.
The condition must be satisfied if the extension is to
take place, and the references to the extension points
define the locations in the base use case where the
additions are to be made.
Extension Points
Details of the point or points in the use case at which
the extension takes place can be shown in a extension
point in the use case ellipse in the diagram.
placeOnlineOrder
Extension point: conditions
specifyShippingInstuctions
<<extend>>
For example: The base use case is called placeOnlineOrder that has
an extending use case called specifyShippingInstuctions.
An extended relationship points from the specifyShippingInstuctions
use case to the placeOnlineOrder use case to indicate that the
behaviors in the specifyShippingInstuctions use case are optional
and only occur in certain circumstances.
Include & Extend Relationships
between Use Cases
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.
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
An extend relationship can be rendered as a
dependency, stereotyped as extend.
extension points are just labels that may appear in the flow
of the base use case
Generalization- Include –Extend
relationships between Use Cases
EXAMPLE
Key differences between «include»
and «extend» relationships
Included use case
Extending use case
Is this use case optional?
No
Yes
Is the base use case complete
without this use case?
No
Yes
Is the execution of this use case conditional?
No
Yes
Does this use case change the
behavior of the base use case?
No
Yes
[ Source: Robert Maksimchuk & Eric Naiburg: UML for Mere Mortals, Addison-Wesley, 2005. ]
The nature
of the
«include»
relationship
extending
the primary
Use Case
The Nature of the Generalization
Relationship
Simple Use Case Example
Online Bookshop Use Case Diagram
Simple Use Case Example
Buy Goods
Example: Login Use Case?
BAD:
GOOD:
Login
AddUser
AddUser
Login
Landlord
SetDevicePrefs
Landlord
SetDevicePrefs
Another Exercise
I am the manager of a theatre.
I want to create an automated movie ticket machine.
You are analysts who need to describe what the customer
wants as a set of use cases
Simplifying assumptions:
One movie showing at a time
Movie time is same every day, only one time, same
price
Only manager can change/add movie
Customer can only buy tickets
Who or what are the actors?
What are the use cases (goals of actors)?
Use case diagram
for Movie Ticket Machine
Why are there three Actors?
Why three use cases for Customer?
Which use cases look easy to write
Use cases for Manager
Use case: Set title
Actors: Manager, Machine
1. Manager requests a change of movie
title
2. Machine asks manager for new
movie title
3. Manager enters movie title
Use case: Set price
Actors: Manager, Machine
1. Manager requests a change of ticket
price
2. Machine asks manager for new price
for movie title
3. Manager enters ticket price
Alternatives: Invalid price
If manager enters price below $1 or
greater than $10
3a. Machine asks manager to reenter
price
Use case: Set seats
Actors: Manager, Machine
1. Manager requests a change in
number of seats
2. Machine asks manager for
number of seats in theatre
3. Manager enters number of
seats
Alternatives: Invalid number
of seats
If manager enters number less
than 20 or greater than 999
3a. Machine asks manager to
reenter number of seats
Use cases for Customer
Use case: Buy tickets
Actors: Customer, Machine
1. Customer requests tickets
2. Machine tells customer to put balance due in money slot
3. Customer enters money in money slot
4. Machine updates customer balance
5. Customer requests tickets
6. Machine prints tickets
7. Machine updates number of seats
Alternative: Insufficient seats
At step 1, if number of tickets requested is less than available seats,
1a. Display message and end use case
Alternative: Insufficient funds
At step 5, if money entered < total cost,
• 5a. Display insufficient amount entered
• 5b. Go to step 3
Behavioral Diagram II
Sequence Diagram
Interaction Diagrams
One of the subsets of Behavioral diagrams
wherein Interaction diagrams graphically depicts
the way objects interact with each other to give
different behaviors.
Interaction diagrams are sub classified into
Sequence diagrams and Collaboration diagrams
Sequence Diagrams are special type of Interaction
Diagram which apart from graphically showing the
object interaction specially focuses on the sequence
and timing of interaction between the objects.
Collaboration Diagrams are special type of Interaction
diagrams which apart from graphically showing the
object interaction focuses on the spatial distribution
of the objects.
The Purposes of Interaction Diagrams
The interactive behavior of the system is
visualized .
Visualizing interaction is a difficult task.
So the solution is to use different types of models
to capture the different aspects of the interaction.
The purposes of interaction diagram
To capture dynamic behavior of a system.
To describe the message flow in the system.
To describe structural organization of the objects.
To describe interaction among objects.
Sequence Diagram
 A sequence diagram is an interaction diagram.
The diagram deals with some sequences, which are the
sequence of messages flowing from one object to another.
 Interaction among the components of a system is very
important from implementation and execution
perspective.
 Sequence diagram is used to visualize the sequence of
calls in a system to perform a specific functionality.
Behavioral Diagram III
Collaboration Diagram
Collaboration Diagram
Collaboration diagram is another form of
interaction diagram.
 It represents the structural organization of a
system and the messages sent/received.
Structural organization consists of objects and
links.
The purpose of collaboration diagram is
similar to sequence diagram.
 But the specific purpose of collaboration diagram
is to visualize the organization of objects and their
interaction.
Structural Diagrams
Class Diagrams,
Object Diagrams,
Package Diagrams,
Component Diagrams
Deployment Diagrams
Structural Diagram I -II
Class Diagram
Object Diagram
Class Diagram
Class diagrams are the most common used in UML
and most widely used diagrams at the time of
system construction.
Class diagram consists of classes, interfaces,
associations and collaboration.
Class diagrams basically represent the object
oriented view of a system which is static in nature.
Active class is used in a class diagram to represent
the concurrency of the system.
Class diagram represents the object orientation of
a system.
it is generally used for development purpose.
Object Diagram
Object diagrams can be described as an instance
of class diagram.
These diagrams are more close to real life scenarios
where we implement a system.
Object diagrams are a set of objects and their
relationships just like class diagrams and also
represent the static view of the system.
The usage of object diagrams is similar to class
diagrams but they are used to build prototype of
a system from practical perspective.
Object & Class Design Concepts
 Objects represent “things” in real world
– Provide understanding of real world
– Form basis for a computer solution
 An Object (object instance) is a single “thing”
– for example: an account, an employee
 A Class (object class) is a collection of objects with the
same characteristics
– for example: account, employee
 Attribute
– Data value held by object in class
– for example: account number, balance
UML notation for objects & classes
Example of classes and objects
Example of class with attributes
Associations Between Classes
 Define structural relationships between classes
– Depict classes and their relationships on class diagrams
 Relationships between classes
– Associations
– Composition / Aggregation
– Generalization / Specialization
 Static Modeling during Analysis
 System Context Class Diagram
– Depict external classes and system boundary
 Static Modeling of Entity classes
– Persistent classes that store data
UML notation on class diagrams
Associations
 Association is static, structural relationship
between classes
– for example: Employee works in Department
Multiplicity of Associations
– Specifies how many instances of one class
may relate to a single instance of another class
Association Classes
 Class to model association between two or more classes
– Usually for many- to- many associations
– Attributes of Association Class
 Many-to-many association between Project and Employee
classes
Project has Employee
Employee works on project
Association Class - Hours
Attribute - Hours Worked
Association : UML Notation
Employer
employs
is employed by
class Employer
{
Employee[ ] employees;
.....
}
class Employee
{
Employer[ ] employers;
.....
}
Employee
Multiplicity of Associations
 1-to-1 association
– Company has President
 1-to-many association
– Bank manages Account
 Numerically specified association
– Car has 2,4 Door
 Optional association (0 or 1)
– Customer owns Debit Card
 Optional association (0, 1, or many)
– Customer owns Credit Card
 Many-to-Many association
– Course has Student
– Student attends Course
one-to-one Association
one-to-many Association
optional (zero-or-one) Association
optional (zero,one, or many) Association
many-to-many Association
Composition/Aggregation Hierarchy
Whole/Part Relationships
– Show parts of more complex class
– Composition is stronger relationship than
aggregation
 IS PART OF Relationship
– Between part classes and whole (composite or
aggregate) class
 Composition is stronger relationship than
aggregation
 Aggregation is stronger than association
Composition Hierarchy
 Composition Hierarchy
– Whole and part objects are created, live, die together
– Often also has a physical association
– Association between instances
 for example: Composite class - ATM
– Part classes




ATM customer Keypad Display
Car reader
Cash Dispencer
ReceiptPrinter
Composition: UML Notation
Company
att: int
myFunction()
composition
emp
*
Employee
*
composition
emp
class Company
{
class Employee emp;
{...}
.....
}
class EmployeeDirectory
{
class Employee emp;
{...}
.....
}
EmployeeDirectory
att: int
myFunction()
Composition/Aggregation Hierarchy
Aggregation Hierarchy
– Part objects of aggregate object may be
created and deleted independently of
aggregate object
 for example: Aggregate class - College
– Part classes
 Admin Office IS PART OF College
Department College
 Research Center IS PART OF College
Aggregation Hierarchy
Aggregation : UML Notation
Company
att: int
myFunction()
aggregation
emp
*
Employee
*
aggregation
class Company
{
Employee emp;
int att;
.....
}
class
EmployeeDirectory
{
Employee emp;
int att;
.....
}
emp
EmployeeDirectory
att: int
myFunction()
Generalization / Specialization Hierarchy
 Some classes are similar but not identical
– Have some attributes in common, others different
 Common attributes abstracted into generalized class
(superclass)
– for example:. Account (Account number, Balance)
 Different attributes are properties of specialized class
(subclass)
 IS A relationship between subclass and superclass
– Savings Account IS A Account
Generalization / Specialization Hierarchy
Inheritance : UML Notation
MyPackage
abstract class
MyAbstractClass
inheritance
MyDerivedClass
att: int
myFunction()
package MyPackage;
abstract class MyAbstractClass . . . .
package MyPackage;
class MyDerivedClass extends MyAbstractClass
{
int att;
.....
void myFunction( ReferencedClass r )
{ . .. }
}
attribute
operation
Interfaces: UML Notation
interface
MyInterface
myMethod()
realization
MyClass
myMethod()
interface MyAbstractClass . . . .
class MyClass implements MyInterface
{
.....
}
Dependence : UML Notation
MyDependentClass
att: int
myFunction()
MyReferencedClass
dependence
(reference to a class)
class MyDependentClass
{
.....
void myFunction1( MyReferencedClass r )
{ . .. }
MyReferencedClass myFunction2( … )
{ . .. }
void myFunction3( … )
{
MyReferencedClass m …
}
}
parameter
or return type
or local variable type
Structural Diagram III
Component Diagram
Component Diagram
Component diagrams represent a set of
components and their relationships.
These components consist of classes, interfaces or
collaborations.
 Component diagrams represent the
implementation view of a system.
During design phase software artifacts (classes,
interfaces ,… ) of a system are arranged in different
groups depending upon their relationship.
these groups are known as components.
Component diagrams are used to visualize the
implementation.
Component Diagrams
 Component diagrams are used in modeling the physical
aspects of object-oriented systems.
 A component diagram shows the organization and
dependencies among a set of components.
 Component diagrams are used to model the static
implementation view of a system.
 Component diagrams are essentially class diagrams
that focus on a system’s components.
 Component diagrams are used for visualizing,
specifying, and documenting component-based
systems and also for constructing executable systems
through forward and reverse engineering.
Structural Diagram IV
Deployment Diagram
Deployment Diagrams
 Shows the configuration of run time processing nodes and
the components that live on them.
 Deployment diagrams are one of the two kinds of diagrams
 used in modeling the physical aspects of an object-oriented
system.
 used to model the static deployment view of a system (topology of
the hardware)
 A deployment diagram is just a special kind of class diagram,
which focuses on a system’s nodes.
 Deployment diagrams are important for
 visualizing,
 specifying,
 documenting embedded,
 client/server,
 distributed systems
 managing executable systems through forward and reverse
engineering.
Common Uses of Component
Diagrams
Component diagrams are
used in one of four ways
To model source code
To model executable
releases
To model physical
databases
To model adaptable
systems
Modeling Source Code
 Either by forward or reverse
engineering, identify the set of
source code files of interest and
model them as components
stereotyped as files.
 For larger systems, use packages
to show groups of source code
files.
 Consider exposing a tagged
value indicating such
information as the version
number of the source code file,
its author, and the date it was
last changed. Use tools to
manage the value of this tag.
 Model the compilation
dependencies among these files
using dependencies
Modeling an Embedded System
Identify the devices and nodes that are unique
to the system.
distinguish processors (contain software
components) and devices (at that level of
abstraction, don’t directly contain software).
Model the relationships among these
processors and devices in a deployment
diagram.
Specify the relationship between the
components in system’s implementation view
and the nodes in system’s deployment view.
Modeling an Embedded System
(the hardware for a simple
autonomous robot)
Modeling a Client/Server System
 Identify the nodes that represent system’s client and
server processors.
 For example, a special device is modeled , such as credit
card readers, badge readers, and display devices other
than monitors, because their placement in the system’s
hardware topology are likely to be architecturally
significant.
 Provide visual cues for these processors and devices via
stereotyping.
 Model the topology of these nodes in a deployment
diagram.
Specify the relationship between the components in system’s
implementation view and the nodes in system’s deployment view.
Modeling a Client/ Server System
the topology of a human resources system.
The system follows a classical client/server architecture
The Difference between Component
and Deployment Diagrams
Component diagrams are dependent upon the
classes, interfaces ,…..which are part of
class/object diagram.
 The deployment diagram is dependent upon
the components which are used to make a
component diagrams.
Modeling a Fully Distributed System
Suppose that the system’s devices and
processors as for simpler client/server systems
are identified
If the performance of the system’s network or the
impact of changes to the network is important , it
is required to model these communication devices
in detail that is sufficient to make these
assessments.
It is required more attention to logical groupings of
nodes, which can be specified by using packages.
These devices and processors are model by using
deployment diagrams.
Modeling a Fully Distributed System
Case Study
MSG Foundation Information
System
The Initial Functional Model: MSG
Foundation
l
Recall the seventh iteration of the use-case diagram
Use Case Manage a Mortgage
One possible extended scenario
Use Case Manage
a Mortgage
• A second extended scenario
Use Case Estimate Funds
Available for Week
One possible scenario
Use Case Produce
One possible scenario
a Report
Use Case Produce
Another possible scenario
a Report
The Initial Class Diagram: MSG Foundation
The aim of entity modeling step is to extract
the entity classes, determine their
interrelationships, and find their attributes
Usually, the best way to begin this step is to
use the two-stage noun extraction method
Noun Extraction: MSG Foundation
Stage 1: Describe the information system in a
single paragraph
– Weekly reports are to be printed showing how
much money is available for mortgages. In
addition, lists of investments and mortgages must
be printed on demand.
Noun Extraction: MSG Foundation
Nouns report and list are not long lived, so they
are unlikely to be entity classes (report will
surely turn out to be a boundary class)
 money is an
abstract noun
This leaves two candidate entity classes
– Mortgage Class and Investment Class
Noun Extraction: MSG Foundation
(contd)
Stage 2: Identify the nouns in this paragraph
– Weekly reports are to be printed showing how
much money is available for mortgages. In
addition, lists of investments and mortgages must
be printed on demand.
The nouns are report, money, mortgage, list, and
investment
First Iteration of the Initial Class
Diagram
Second Iteration of the Initial Class
Diagram
Operations performed on the two entity
classes are likely to be very similar
– Insertions, deletions, and modifications
– All members of both entity classes have to be
printed on demand
Mortgage Class and Investment Class should
be subclasses of a superclass called Asset
Class
Second Iteration of Initial Class
Diagram
Back to the Requirements Workflow
The current five use cases include Manage
Mortgage and Manage an Investment
a
These two can now be combined into a single
use case, Manage an Asset
Eighth Iteration of the Use-Case Diagram
The new use case is shaded
Initial Class Diagram: MSG Foundation
Finally, we add the attributes of each class to the
class diagram
– For the MSG Foundation case study, the result is
shown on the next slide
The empty rectangle at the bottom of each box
will later be filled with the operations of that
class
Second Iteration of Initial Class
Diagram (contd)
Estimate Funds Available for Week Use Case
Estimate Funds Available for Week Use Case
Description
of use case
Estimate Funds Available for Week Use Case
 The six classes that enter into this use case are:
– User Interface Class
• This class models the user interface
– Estimate Funds for Week Class
• This control class models the computation of the estimate of the funds
that are available to fund mortgages during that week
– Mortgage Class
• This class models the estimated grants and payments for the week
– Investment Class
• This class models the estimated return on investments for the week
– MSG Application Class
• This class models the estimated return on investments for the week
– Estimated Funds Report Class
• This class models the printing of the report
Estimate Funds Available for
Week Use Case
Scenario (one possible instance of the use case)
EstimateFunds Availableforweek Use Case
 Sequence
diagram
equivalent to the
collaboration
diagram (of the
realization of the
scenario of the
use case)
Manage an Asset
Use case
Use Case
Manage an Asset Use Case
One scenario of the use case
Manage an Asset Use Case
Sequence diagram equivalent to the collaboration diagram
(of the realization of the scenario of the use case)
Manage an Asset Use Case
A different scenario of the use case
Manage an Asset Use Case
Boundary class User Interface Class appears in
all the realizations
– The same screen will be used for all commands of
the information system
The following link helps you to learn UML
http://www.tutorialspoint.com/uml/index.ht