Hoang Huu Hanh, PhD

hhhanh@hueuni.edu.vn

UML
UNIFIED MODELING LANGUAGE

Hue University

ue University

b a se d o n o n lin e co u rse s a n d p re se n ta tio n s

 DEFINITION
Unified Modeling Language is
the successor to the wave of
Object-Oriented 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
ue University
the OMG (Object Management
Group) and is now an OMG
Introduction to UML 2
 UML History

ue University

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
ue University 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
ue University
• Documenting


Introduction to UML 5
 Visualizing
Itmakes 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.

ue University

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.
ue University

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
ue University
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.
ue University

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
ue University
◦ stereotypes
Introduction to UML 10
 FUNDAMENTAL UML
Models and Views
Core Diagrams
Fundamental Elements

ue University

Introduction to UML 11
 Model

Views

Class Diagrams Class Diagrams

Sequence Diagrams (Packages)

Individual Diagrams

«utility»
«interface» utility1
UseCase1
Interface3

Class3
UseCase2
Actor1

Fundamental Elements
Interface2 «uses»

* -End1
* -End2

Actor2
UseCase3 {}

ue University

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
ue University
different views of our software
system. Introduction to UML 13
 Core Elements
Construct Description Syntax
class a description of a set of objects
that share the same attributes,
operations, methods, relationships
and semantics.
interface a named set of operations that
characterize the behavior of an
element.

« in
component a modular, replaceable and
significant part of a system that
packages implementation and
exposes a set of interfaces.
node a run-time physical object that
represents a computational
ue University resource.

Introduction to UML 14
 Core Elements (cont’d)
Construct Description Syntax
constraint ¹ a semantic condition or restriction.
{ c o n s t r a i n t }

¹ An extension mechanism useful for specifying structural elements.

ue University

Introduction to UML 15
 Fundamental Elements
These are the elements of which
diagrams are composed
Understanding the intent of each
element enables us to create
precise diagrams, because each
of them has unambiguous
meaning.

ue University

Introduction to UML 16
 DIAGRAMS
 Individualdiagrams 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
ue University 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
ue University
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
ue University 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
ue University
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
ue University
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.

ue University

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
ue University
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.

ue University

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.
ue University

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
ue University
◦ 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
ue University ◦ 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:
ue University behavioral, and
structural.
 Most commonly used 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.
ue University  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
association a relationship between two or more
classifiers that involves connections
among their instances.
aggregation A special form of association that
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.
dependency a relationship between two modeling
elements, in which a change to one
modeling element (the independent
element) will affect th e other modeling
ue University element (the dependent element).

Introduction to UML 30
 Core Relationships (cont’d)
Construct Description Syntax
realization a relationship between a specification
and its implementation.

ue University

Introduction to UML 31
 Relationships
 An association is a bi-directional connection
between classes
◦ An association is shown as a line connecting the
related classes
 An aggregation is a stronger form of
relationship where the relationship is
between a whole and its parts
◦ An aggregation is shown as a line connecting the
related classes with a diamond next to the
class representing the whole
A dependency relationship is a weaker form
of relationship showing a relationship
between a client and a supplier where the
ue University
client does not have semantic knowledge
of the supplier
 A dependency is shown as a dashed line
Introduction to UML 32
 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

ue University

Introduction to UML 33
 Finding Relationships
Relationships are discovered by
examining interaction diagrams
◦ If two objects must “talk” there
must be a pathway for
communication
RegistrationManager
Registration Math 101:
Manager Course

3: add student(joe)

Course

ue University

Introduction to UML 34
 Relationships
ScheduleAlgorithm
RegistrationForm

RegistrationManager

addStudent(Course, StudentInfo)
Course
name
numberCredits
Student open()
name addStudent(StudentInfo)
major

Professor
name CourseOffering
tenureStatus
location

open()
addStudent(StudentInfo)
ue University

Introduction to UML 35
 Associations
Job 1..∗
Company ∗
employer employee Person

Job boss
salary
0..1
worker ∗

Manages

Person

{X or}
Account
Corporation
ue University

Introduction to UML 36
 Association Ends

+vertex
1 3..∗
Contains
Polygon Point
{ordered}
1
GraphicsBundle
1
-bundle color
texture
density

ue University

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

ue University

Introduction to UML 38
 Ternary Associations
Year

season ∗

∗ ∗
Team Player
team goalkeeper

Record
goals for
goals against
wins
losses
ties
ue University

Introduction to UML 39
 Composition
Window

scrollbar [2]: Slider

title: Header
body: Panel

Window
1
1 1

scrollbar 2 title 1 body 1

Slider Header Panel

ue University

Introduction to UML 40
 Composition (cont’d)

Window

2
scrollbar:Slider

1
title:Header

1
body:Panel

ue University

Introduction to UML 41
 Generalization
Shape

Separate Target Style

Polygon Ellipse Spline . ..

Shape
Shared Target Style

...
Polygon Ellipse Spline
ue University

Introduction to UML 42
 Generalization
Vehicle

power venue
power venue
{overlapping} {overlapping}

WindPowered MotorPowered Land Water

Vehicle Vehicle Vehicle Vehicle

Truck Sailboat

ue University

Introduction to UML 43
 Dependencies

ClassA ClassB ClassD

«friend»
«friend»
operationZ()
«instantiate»

«call» ClassC

«refine»
ClassC combines
two logical classes

ClassD ClassE

ue University

Introduction to UML 44
 Dependencies
Controller
«access»
«access»
«access» Diagram
Elements
«access»
«access»

Domain Graphics
Elements Core

ue University

Introduction to UML 45
 Derived Attributes and Associations
Person
birthdate
{age = currentDate - birthdate} /age

1
Company ∗ Department
employer
1 1 department
employer
WorksForDepartment
∗
∗ Person
/WorksForCompany
{ Person.employer=Person.department.employer }

ue University

Introduction to UML 46
 Links
officer
Jill:Person

member
treasurer
member
downhillSkiClub:Club Joe:Person

president member
Chris:Person
officer

ue University

Introduction to UML 47
 Constraints and Comments
M em b e r - of
∗ ∗
P e rs o n C o m m itt e e R ep r e s en ts
{ s ub s e t}
a n in c o r po r a te d e n ti ty .
1 C h ai r -o f
∗

e m p lo y e e em p l o y e r

∗ P e r so n ∗ 0 .. 1 C om pa ny
0 .. 1
b os s

{ P e r s o n. em p l oy e r =
P e rs o n. bo s s .e m p lo y e r }

ue University

Introduction to UML 48
 Actors
An actor is someone or some
thing that interacts with the
system
External Forces
◦ Human interaction
◦ Automated System
Traffic Control
Driver System
Keyboard
User Operator

ue University <<Backup System>>

<<toll booth>>
Introduction to UML 49
 Use Cases
A use case is a pattern of behavior the system
exhibits
◦ 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
A flow of events document is created for each
use case
◦ 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
ue University ◦ Exceptional flow of events

Introduction to UML 50
 Use case diagrams
Use case diagrams are centered around
the business processes that our
application must support.
Most simply, use case diagrams enable
us to structure our entire application
around the core processes that it must
support.
Doing so enables us to use these use
cases to drive the remainder of the
modeling and development effort.
Shows a set of actors and use cases,
and the relationships between them.
Use case diagrams contribute to
effective model organization, as well as
modeling the core behaviors of a
ue University system.
Introduction to UML 51
 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
ue University
generate test cases
Developed by analysts and
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
ue University

Introduction to UML 53
 Use Case Diagram
Captures system functionality as
seen by users

ue University

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
ue University
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 course form :
1: set course info CourseForm
2: process

: Registrar 3: add course

ue University theManager :
aCourse : CurriculumManager
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
ue University
diagram is used.
Introduction to UML 57
 Sequence Diagram
A sequence diagram displays
object interactions arranged in
a time sequence
Passenger Counter Ticket Gate Plane
Agent Agent
1: Give Info

2: Questions

3: Answer
4: Print
5: Safeguard
6:Present
7: Board
8: Overbook
9: Return
ue University

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
ue University

Introduction to UML 59
 State Transition Diagrams
Illustratesinternal 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.


ue University

Introduction to UML 60
 State Transition Diagram
Add student[ count < 10 ]
Add Student /
Initialization Set count = 0
Open
do: Initialize course
entry: Register student
exit: Increment count

Cancel

Cancel [ count = 10 ]

Canceled
do: Notify registered students
Closed
Cancel do: Finalize course

ue University

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

ue University

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,
ue University often represents the Java packages and the
dependencies between them that our
application consists of.
Introduction to UML 63
 Class Diagrams
Illustratesa set of classes,
packages, and relationships
detailing a particular aspect of
a system.
This diagram is likely the most
common one used in modeling.


ue University

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
ue University ◦ The behavior of a class is represented by its
operations
◦ Operations may be found by examining interaction
Introduction to UML 65
 Class Diagram
 Captures the vocabulary of a system

ue University

Introduction to UML 66
 Object Diagrams
 Provides a snapshot of the system
illustrating the static relationships that
exist between objects.
 Object diagrams depict the structural
relationship that exists among the objects
within our running application at a given
point in time.
 When we think of the runtime version of our
system, we typically think of behavior.
 Many people have found that object
diagrams are most useful in fleshing out
the instance relationships among objects,
which in turn can help verify our class
diagrams.
ue University  Beyond this, object diagrams are not often
used.
Introduction to UML 67
 Relationships
Relationships provide a pathway
for communication between
objects
Sequence and/or collaboration
diagrams are examined to
determine what links between
objects need to exist to
accomplish the behavior -- if two
objects need to “talk” there must
be a link between them
Three types of relationships are:
ue University
◦ Association
◦ Aggregation
◦ Dependency Introduction to UML 68
 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 bi-directional by
default, it is often desirable to
ue University restrict navigation to one direction
If navigation is restricted, an
Introduction to UML 69
 Multiplicity and Navigation
ScheduleAlgorithm
RegistrationForm

0..*
1 RegistrationManager
addStudent(Course, StudentInfo)
1 Course
name
0..* numberCredits
Student open()
addStudent(StudentInfo)
major

1
3..10
Professor 1..*
4 CourseOffering
tenureStatus location
1
0..4 open()
addStudent(StudentInfo)

ue University

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
ue University
at the highest applicable level
in the hierarchy Introduction to UML 71
 Inheritance
ScheduleAlgorithm
RegistrationForm

RegistrationManager
addStudent(Course, StudentInfo)
Course
name
RegistrationUser numberCredits
name Student open()
addStudent(StudentInfo)
major

Professor
CourseOffering
tenureStatus location

open()
addStudent(StudentInfo)

ue University

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

ue University

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
ue University
application.
Components aren’t equivalent to
Introduction to UML 74
 Component Diagram
Captures the physical structure
of the implementation

ue University

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.
ue University

Introduction to UML 76
 Deployment Diagram
Capturesthe topology of a system’s
hardware

ue University

Introduction to UML 77
 Extensibility Mechanisms
Stereotype
Tagged value
Constraint

ue University

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:
ue University
◦ Class stereotypes: boundary,
control, entity, utility, exception
◦ Inheritance stereotypes: uses
Introduction to UML and 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
ue University
deployment diagram might be useful.
 Introduction to UML 80
 Q&A
… time to ask questions

ue University

Introduction to UML 81
 Thank you!
… take a break

ue University

Introduction to UML 82