Hoang Huu Hanh, PhD
hhhanh@hueuni.edu.vn
UML
UNIFIED MODELING LANGUAGE
based on online courses and presentations
DEFINITION
Unified Modeling Language is the
successor to the wave of ObjectOriented Analysis and Design methods
that appear in the late `80s and early `90s.
 Most directly unifies the methods of
Booch, Rumbaugh (OMT), and Jacobson,
but its reach is wider than that.
 UML went through a standardization
process with the OMG (Object
Management Group) and is now an OMG
standard.

Introduction to UML
2
UML History
UML 2.0
Publication circa ´05
Industrialization
UML 1.4
Publication ´01
Publication of UML 1.1 September ´97
UML 1.1
Publication of
UML 1.0, Jan ´97
Standardization
UML 1.0
public
feedback
June ´96 & Oct ´96
OOPSLA ´95 Unified Method 0.8
Booch ´93
Other methods Booch ´91
Unification
UML 0.9 & 0.91
UML Partners’
Expertise
OMT - 2
OMT - 1
OOSE
Fragmentation
Introduction to UML
3
WHAT IT IS





UML is a modeling language, not a method
Most methods consist, at least in principle, of
both a modeling language and a process.
Modelling Language is the (mainly graphical)
notation that methods use to express
designs.
Process is their advice on what steps to take
in doing a design.
Modeling Language is the most important
part of the method, which is the key part of
communication.
Introduction to UML
4
WHY USE UML




Helps Analysis and Design
Used for communication
Use the advantages of OO
Documentation
As stated in The Unified Modeling Language User Guide;
UML is a language for:
• Visualizing
• Specifying
• Constructing
• Documenting
Introduction to UML
5
Visualizing
It makes it easier to understand and work
through problem
 Since it is a formal language, it enables
other developers familiar with the
language to more easily interpret our
drawings.

Introduction to UML
6
Specifying
We must communicate our software
system using some common, precise, and
unambiguous communication mechanism.
 Again the formal nature of the UML
facilitates this specification quite nicely.

Introduction to UML
7
Constructing




We know that the UML is a formal language with
its own set of syntactical rules.
Because of this formality, we can create tools that
interpret our models.
They can map the elements to a programming
language, such as Java, C++.
Many tools such as Rational Rose, supports this
forward engineering. In fact this is one of the
advantages of using a formal modeling tool.
Introduction to UML
8
Documenting
The models we create are just one of the
articats produced throughout the
development lifecycle.
 Using the UML in a consistent fashion
produces a set of documentation that can
serve as a blueprint of our system.

Introduction to UML
9
USAGES

Define the boundaries of a system & its major
functions
◦ use cases and actors

Illustrate use cases
◦ interaction diagrams

Define the static structure of a system
◦ class diagrams

Model the behavior of objects
◦ state transition diagrams

Document the physical implementation architecture
◦ component & deployment diagrams

Provide for growth
◦ stereotypes
Introduction to UML
10
FUNDAMENTAL UML
Models and Views
 Core Diagrams
 Fundamental Elements

Introduction to UML
11
Model
Views
Class Diagrams
Sequence Diagrams
Class Diagrams
(Packages)
Individual Diagrams
«utility»
utility1
«interface»
Interface3
UseCase1
Class3
UseCase2
Actor1
Fundamental Elements
«uses»
Interface2
*
-End1
*
-End2
Actor2
UseCase3
{}
Introduction to UML
12
Models and Views
UML is more than disjointed diagrams
 Turn attention to an illustration of the
UML from three different perspectives
 Further insight into these divisions
enables us to realize one of the greatest
benefits of modeling, which is creating
different views of our software system.

Introduction to UML
13
Core Elements
Construct Description
Syntax
a description of a set of objects
that share the same attributes,
operations, methods, relationships
and semantics.
a named set of operations that
interface
characterize the behavior of an
element.
component a modular, replaceable and
significant part of a system that
packages implementation and
exposes a set of interfaces.
a run-time physical object that
node
represents a computational
resource.
class
Introduction to UML
«interface»
14
Core Elements (cont’d)
Construct Description
constraint¹
Syntax
a semantic condition or restriction.
{constraint}
¹ An extension mechanism useful for specifying structural elements.
Introduction to UML
15
DIAGRAMS




Individual diagrams contribute more to the
specification of a software system.
They are composition of many of the fundamental
elements.
Are mechanism that developers use to
communicate and solve problems in the complex
aspects of the system.
The most common diagram is the Class Diagram,
which describe the structural relationships that
exist among the classes, can guide developers in
understanding our software system’s class
structure.
Introduction to UML
17
VIEWS





As we become more proficient in modeling, we
begin to realize that using a combination of
diagrams to communicate is most effective.
We may need to combine class diagram with a
diagram whose intent is to give systems dynamics.
By combining these called views.
View is a depiction of our system from a particular
perspective.
By making different views, we can represent our
system from different perspectives.
Introduction to UML
18
VIEWS (cont’d)

There are five main views,
◦
◦
◦
◦
◦


Use case
Design
Development
Process
Physical
They must be consistent with each other,
because all of them are representing the
same system.
Can be used to validate each other.
Introduction to UML
19
USE CASE VIEW





This view documents the system from the
customer’s perspective.
Terminology used in this view should be domain
specific.
Depending on the technical nature of our audience,
we should avoid obscure technical terms.
Diagrams most common in this view are the use
case diagrams and, less common, activity diagrams.
Organizations transitioning to the UML may wish
to work only with use case diagrams early and
experiment with activity diagrams over time.
Introduction to UML
20
Design VIEW
This view documents the system from
designer’s and architect’s perspective.
 Diagrams most common in this view are
class and interaction diagrams (either
sequence or collaboration), as well as
package diagrams illustrating the package
structure of our Java application.

Introduction to UML
21
Development VIEW
This view documents the components
that the system is composed of.
 This view typically contains component
diagrams.
 Except for the most complex Java
applications, this view is optional.

Introduction to UML
22
Process VIEW
This view documents the processes and
threads that compose our application.
 These processes and threads typically are
captured on class diagrams using an active
class.
 Because of the advanced nature of active
classes, coupled with the volume of use,
active classes are beyond the scope of
this discussion.

Introduction to UML
23
Physical VIEW
This view documents the system
topology.
 Deployment diagrams that compose this
view illustrate the physical nodes and
devices that make up the application, as
well as the connections that exist
between them.

Introduction to UML
24
VIEWS (cont.)
We are not limited with the listed views.
 If there is something that architecturally
important, for example security, then we
may create a new view (ex: security view)
into the system from that perspective.

Introduction to UML
25
Modeling Elements

Structural elements
◦ class, interface, collaboration, use case, active
class, component, node

Behavioral elements
◦ interaction, state machine

Grouping elements
◦ package, subsystem

Other elements
◦ note
Introduction to UML
26
Diagrams - The foundation of UML

Use Case Diagrams
◦ Requirements

Activity Diagrams
◦ Generally what, not who - good to detect parallelism

Interaction Diagrams
◦ Collaboration/Communication Diagrams (object centered)
◦ Sequence Diagrams (timeline)

Static Structure Diagrams
◦ Objects/Classes/Packages

Statechart Diagrams
◦ States of objects with interesting lifecycles

Implementation Diagrams
◦ Component Diagrams
◦ Deployment Diagrams
Introduction to UML
27
DIAGRAMS




As we’ve seen, we can
combine diagrams that form
models and that can serve
as views into our system.
If an advantage in modeling
is to combine diagrams to
form views into our system,
then it only makes sense
that each diagram has a
different focus on what it
communicates.
Each falls into one of two
categories: behavioral, and
structural.
Most commonly used are
use case, sequence, and class
diagrams.
Introduction to UML
28
Behavioral diagrams






Behavioral diagrams depict the dynamic aspects of our
system.They are most useful for specifying the collaborations
among elements that satisfy the behavior of our system’s
requirements.
Five diagrams that fall into this category are;
◦ Use case
◦ Activity
◦ State
◦ Sequence
◦ Collaboration (Communication)
Mostly used are use case, sequence, and collaboration.
Activity and state diagrams are used on an as-needed basis.
Activity diagrams visually represent behaviors captured by use
cases.
State diagrams, on the other hand, are used to illustrate
complex transitions in behavior for a single class.
Introduction to UML
29
Core Relationships
Construct
Description
Syntax
a relationship between two or more
classifiers that involves connections
among their instances.
A special form of association that
aggregation
specifies a whole-part relationship
between the aggregate (whole) and
the component part.
generalization a taxonomic relationship between a
more general and a more specific
element.
a relationship between two modeling
dependency
elements, in which a change to one
modeling element (the independent
element) will affect the other modeling
element (the dependent element).
association
Introduction to UML
30
Core Relationships (cont’d)
Construct
Description
Syntax
realization
a relationship between a specification
and its implementation.
Introduction to UML
31
Relationships
ScheduleAlgorithm
RegistrationForm
RegistrationManager
addStudent(Course, StudentInfo)
Course
name
numberCredits
Student
open()
addStudent(StudentInfo)
name
major
Professor
name
tenureStatus
CourseOffering
location
open()
addStudent(StudentInfo)
Introduction to UML
35
Associations
Job


Company
employer employee
Job
salary
Person
boss
worker 
0..1
Manages
Person
Account
{X or}
Corporation
Introduction to UML
36
Association Ends
1
Polygon
+vertex
3..
Contains
{ordered}
Point
1
1
-bundle
GraphicsBundle
color
texture
density
Introduction to UML
37
Relationship Notation
1 - one and only one
 4 - four and only 4
 0..1 - zero or 1
 5..10 - five to and including 10
 0..* - zero or more
 4..* - four or more

Introduction to UML
38
Composition
Window
scrollbar [2]: Slider
title: Header
body: Panel
Window
1
scrollbar
Slider
2
1
1
title
1
Header
body
1
Panel
Introduction to UML
40
Generalization
Shape
Separate Target Style
Polygon
Ellipse
Spline
. ..
Shape
Polygon
Ellipse
Shared Target Style
Spline
...
Introduction to UML
42
Generalization
Vehicle
venue
power
power
{overlapping}
WindPowered
Vehicle
Truck
venue
MotorPowered
Vehicle
{overlapping}
Land
Vehicle
Water
Vehicle
Sailboat
Introduction to UML
43
Dependencies
ClassA
ClassD
ClassB
«friend»
«friend»
operationZ()
«instantiate»
«call»
ClassC
«refine»
ClassD
ClassC combines
two logical classes
ClassE
Introduction to UML
44
Dependencies
Controller
«access»
«access»
«access»
Diagram
Elements
«access»
«access»
Domain
Elements
Graphics
Core
Introduction to UML
45
Derived Attributes and Associations
Person
birthdate
/age
{age = currentDate - birthdate}
1
Company
1
 Department
employer
1
employer


department
WorksForDepartment
Person
/WorksForCompany
{ Person.employer=Person.department.employer }
Introduction to UML
46
Links
officer
Jill:Person
treasurer
downhillSkiClub:Club
president
member
member
Joe:Person
member
Chris:Person
officer
Introduction to UML
47
Constraints and Comments
 Member-of 
Person
Committee
{subset}
1

Person
0..1
boss
Chair-of
Represents
an incorporated entity.

employee

employer
0..1
Company
{Person.employer =
Person.boss.employer}
Introduction to UML
48
Actors
An actor is someone or some thing that
interacts with the system
 External Forces

◦ Human interaction
◦ Automated System
Driver
User
Keyboard
Operator
Traffic Control
System
<<Backup System>>
<<toll booth>>
Introduction to UML
49
Use Cases

A use case is a pattern of behavior the system exhibits

A flow of events document is created for each use case
◦ Each use case is a sequence of related transactions performed by
an actor and the system in a dialogue
◦ Details what the system must provide to the actor when the use
cases is executed
◦ Written from an actor point of view
◦ Actors are examined to determine their how they interact with
the system
 Break down into the most atomic actions possible

Typical contents
◦
◦
◦
◦
How the use case starts and ends
Normal flow of events
Alternate flow of events
Exceptional flow of events
Introduction to UML
50
Use Case Diagram
Captures system functionality as seen by
users
 Built in early stages of development
 Purpose

◦
◦
◦
◦

Specify the context of a system
Capture the requirements of a system
Validate a system’s architecture
Drive implementation and generate test cases
Developed by analysts and domain
experts
Introduction to UML
52
Use Case Diagram

Use case diagrams are created to
visualize the relationships between actors
and use cases
Pay toll
Driver
Passager
Lost Luggage
Customer Service Agent
Ramp Maintenance
Mechanic
Introduction to UML
53
Use Case Diagram

Captures system functionality as seen by
users
Introduction to UML
54
Collaboration Diagrams
A type of interaction diagram that
describes the organizational layout of the
objects that send and receive messages.
 Semantically equivalent to a sequence
diagram.
 It uses class diagrams layout, and can be
used to make more cohesive and less
coupled classes.

Introduction to UML
55
Collaboration Diagram

A collaboration diagram displays object
interactions organized around objects and
their links to one another
1: set course info
2: process
course form :
CourseForm
3: add course
: Registrar
theManager :
CurriculumManager
aCourse :
Course
4: new course
Introduction to UML
56
Sequence Diagrams
Semantically equivalent to a collaboration
diagram.
 sequence diagram is a type of interaction
diagram that describes time ordering of
messages sent between objects.
 Almost in all software development
activity, this diagram is used.

Introduction to UML
57
Sequence Diagram

A sequence diagram displays object
interactions arranged in a time sequence
Passenger
Counter
Agent
Ticket
Gate
Agent
Plane
1: Give Info
2: Questions
3: Answer
5: Safeguard
4: Print
6:Present
7: Board
8: Overbook
9: Return
Introduction to UML
58
The State of an Object

A state transition diagram shows
◦ The life history of a given class
◦ The events that cause a transition from one
state to another
◦ The actions that result from a state change

State transition diagrams are created for
objects with significant dynamic behavior
Introduction to UML
59
State Transition Diagrams
Illustrates internal state-related behavior
of an object.
 Transitions between states help identify,
and validate, complex behavior.
 A class can have at most a single state
diagram.

Introduction to UML
60
State Transition Diagram
Add student[ count < 10 ]
Initialization
Add Student /
Set count = 0
do: Initialize course
Open
entry: Register student
exit: Increment count
Cancel
Cancel
[ count = 10 ]
Canceled
do: Notify registered students
Cancel
Closed
do: Finalize course
Introduction to UML
61
Activity Diagrams
Models the flow of activity between
processes.
 These diagrams are most useful in
detailing use case behavior.
 An activity diagram doesn’t show
collaboration among objects.

Introduction to UML
62
STRUCTURAL DIAGRAMS







Diagrams in this category are focused on specifying the static
aspects of our system.
Of these four diagrams, the class diagram is most often used.
when transitioning to the UML, most organizations tend to use
class diagrams first because they are excellent mechanisms for
communication among developers, as well as tools that can be
used for problem solving.
There are two forms of class diagrams.
The first is the most commonly understood and consists of the
classes that compose our system and of the structure among
these classes.
Unfortunately, the second is not often used but is of equal
importance and can be most effective in helping developers
understand our system from a high level.
A type of class diagram, called a package diagram, often
represents the Java packages and the dependencies between
them that our application consists of.
Introduction to UML
63
Class Diagrams
Illustrates a set of classes, packages, and
relationships detailing a particular aspect
of a system.
 This diagram is likely the most common
one used in modeling.

Introduction to UML
64
Class Diagrams


A class diagram shows the existence of classes and their
relationships in the logical view of a system
UML modeling elements in class diagrams
◦
◦
◦
◦

Classes and their structure and behavior
Association, aggregation, dependency, and inheritance relationships
Multiplicity and navigation indicators
Role names
Attributes
◦ The structure of a class is represented by its attributes
◦ Attributes may be found by examining class definitions, the problem
requirements, and by applying domain knowledge

Operations
◦ The behavior of a class is represented by its operations
◦ Operations may be found by examining interaction diagrams
Introduction to UML
65
Class Diagram

Captures the vocabulary of a system
Introduction to UML
66
Multiplicity and Navigation

Multiplicity defines how many objects
participate in a relationships
◦ Multiplicity is the number of instances of one class
related to ONE instance of the other class
◦ For each association and aggregation, there are two
multiplicity decisions to make: one for each end of
the relationship
Although associations and aggregations are bidirectional by default, it is often desirable to
restrict navigation to one direction
 If navigation is restricted, an arrowhead is added
to indicate the direction of the navigation

Introduction to UML
69
Multiplicity and Navigation
ScheduleAlgorithm
RegistrationForm
0..*
1 RegistrationManager
addStudent(Course, StudentInfo)
Course
1
0..*
Student
name
numberCredits
open()
addStudent(StudentInfo)
major
1
3..10
Professor
4
tenureStatus
1
1..*
CourseOffering
location
0..4
open()
addStudent(StudentInfo)
Introduction to UML
70
Inheritance
Inheritance is a relationships between a
superclass and its subclasses
 There are two ways to find inheritance:

◦ Generalization
◦ Specialization

Common attributes, operations, and/or
relationships are shown at the highest
applicable level in the hierarchy
Introduction to UML
71
Inheritance
ScheduleAlgorithm
RegistrationForm
RegistrationManager
addStudent(Course, StudentInfo)
Course
name
numberCredits
RegistrationUser
name
Student
open()
addStudent(StudentInfo)
major
Professor
tenureStatus
CourseOffering
location
open()
addStudent(StudentInfo)
Introduction to UML
72
The Physical World
Component diagrams illustrate the
organizations and dependencies among
software components
 A component may be

◦ A source code component
◦ A run time components or
◦ An executable component
Introduction to UML
73
Component Diagrams
Addresses the static relationships existing
between the deployable software
components.
 Examples of components may be .exe, .dll,
.ocx, jar files, and/or Enterprise JavaBeans.
 Component diagrams might be used to
show the software components within
our application.
 Components aren’t equivalent to classes.

Introduction to UML
74
Component Diagram

Captures the physical structure of the
implementation
Introduction to UML
75
Deploying the System
The deployment diagram shows the
configuration of run-time processing
elements and the software processes
living on them
 The deployment diagram visualizes the
distribution of components across the
enterprise.

Introduction to UML
76
Deployment Diagram

Captures the topology of a system’s hardware
Introduction to UML
77
Extensibility Mechanisms
Stereotype
 Tagged value
 Constraint

Introduction to UML
78
Extending the UML
Stereotypes can be used to extend the
UML notational elements
 Stereotypes may be used to classify and
extend associations, inheritance
relationships, classes, and components
 Examples:

◦ Class stereotypes: boundary, control, entity,
utility, exception
◦ Inheritance stereotypes: uses and extends
◦ Component stereotypes: subsystem
Introduction to UML
79
Deployment Diagrams




Describes the physical topology of a system.
Typically includes various processing nodes, realized
in the form of a device (for example, a printer or
modem) or a processor (for example, a server).
Deployment diagrams are most useful when we
have a complex configuration environment.
If our application is to be deployed to multiple
servers, across locations, a deployment diagram
might be useful.
Introduction to UML
80
Q &A
… time to ask questions
Introduction to UML
81
Thank you!
… take a break
Introduction to UML
82