Introduction to

Unified Modeling Language

(UML)
 Introduction
The heart of object-oriented problem
solving is the construction of a model. The
model abstracts the essential details of the
underlying problem from its usually
complicated real world. Several modeling
tools are wrapped under the heading of
the UML™, which stands for Unified
Modeling Language™.
 Why is UML important?
Use case diagrams are helpful in three areas.

• determining features (requirements). New use cases often

generate new requirements as the system is analyzed and
the design takes shape.

• communicating with clients. Their notational simplicity

makes use case diagrams a good way for developers to
communicate with clients.

• generating test cases. The collection of scenarios for a use

case may suggest a suite of test cases for those scenarios.
 Why is UML important?
• Describe OO architecture of the System
• Describe system behavior
• Describe system interaction with user or other
systems
• Describe System activities
• Describe System components
• Describe System states
• Describe System operability
 UML Diagrams
• Use case diagrams
• Class diagrams
• Object diagrams
• Sequence diagrams
• Collaboration diagrams
• State chart diagrams
• Activity diagrams
• Component diagrams
• Deployment diagrams
 Use case Diagram
• Use case diagrams describe what a system
does from the standpoint of an external
observer. The emphasis is on what a system
does rather than how.

• Use case diagrams are closely connected to

scenarios. A scenario is an example of what
happens when someone interacts with the
system. Here is a scenario for a medical clinic.
 Use Case Scenario
"A patient calls the clinic to make an appointment for a yearly checkup.
The receptionist finds the nearest empty time slot in the appointment
book and schedules the appointment for that time slot. "

Actors are stick figures. Use cases are ovals.

Communications are lines that link actors to use
cases.

A use case is a summary of scenarios for a single task or goal. An actor is

who or what initiates the events involved in that task. Actors are simply roles
that people or objects play. The picture below is a Make Appointment use
case for the medical clinic. The actor is a Patient. The connection between
actor and use case is a communication association (or communication
for short).
 Extending the scenario
Use case diagrams give an outsider's view of a system. Every
use case diagram has actors, use cases, and
communications. A simple use case diagram can be
expanded with additional features to display more
information.

This section covers the following UML™ use case features.

• system boundaries
• generalizations
• includes
• extensions
 Medical clinic diagram, expanded
The following use case diagram expands the original medical clinic diagram with additional features.

A system boundary rectangle

separates the clinic system from the
external actors.

A use case generalization shows that one use

case is simply a special kind of another. Pay Bill
is a parent use case and Bill Insurance is the
child. A child can be substituted for its parent
whenever necessary. Generalization appears as
a line with a triangular arrow head toward the
parent use case.
Include relationships factor use cases into
additional ones. Includes are especially helpful
when the same use case can be factored out of
The extending use case may add behavior to
two different use cases. Both Make
the base case but the base case must declare
Appointment and Request Medication include
certain “extension points”. The extension
Check Patient Record as a subtask. In the
point, which determines when the extended
diagram, include notation is a dotted line
case is appropriate, is written inside the base
beginning at base use case ending with an
case.Extend notation is a dotted line, labeled
arrows pointing to the include use case. The
<<extend>>, and with an arrow toward the base
 Apply the Following Rules for
Use Cases
• Use include when you are repeating yourself
in two or more repeatable use cases and
you want to avoid repetition.
• Use generalization when you have one use
case that is similar to another use case but
does a bit more.
• Use extend when you are describing a
variation on normal behavior and you wish
to use the more controlled form.
 Class Diagram
A Class diagram gives an overview of a system by showing its classes and
the relationships among them. Class diagrams are static -- they display
what interacts but not what happens when they do interact.

UML class notation is a rectangle divided into three parts: class name,
attributes, and operations.

Names of abstract classes, such as Payment, are in italics. Relationships

between classes are the connecting links.
aggregation -- an association in which one
class belongs to a collection. An aggregation
has a diamond end pointing to the part
containing the whole.
A navigability arrow on an association shows
which direction the association can be traversed
or queried. An OrderDetail can be queried about
its Item, but not the other way around. The arrow
also lets you know who "owns" the association's
implementation; in this case, OrderDetail has an
Item.
Associations with only one navigability arrows is
called unidirectional.
Associations with no navigability arrow is called
bi-directional.

association -- In a diagram, an association is a

link connecting two classes. Association is a
relationship between instances of the two classes
(The diagram indicates that an Order has to
come from a single Customer and that a
Customer may make several Orders over time).
An association has two ends. An end may have a
role name to clarify the nature of the association.
For example, the Order Line end of the
association from Order line item is the role
name. If there is no label, you name an end after
the target class. For example the Customer end
of the association from Order would be called
customer.
The multiplicity of an association end is the
number of possible instances of the class generalization -- an inheritance link indicating
associated with a single instance of the other one class is a superclass of the other. A
end. Multiplicities are single numbers or ranges of generalization has a triangle pointing to the
numbers. In our example, there can be only one superclass.
Customer for each Order, but a Customer can
 Composition and aggregation
Every class diagram has classes, associations, and multiplicities. Navigability and roles are optional
items placed in a diagram to provide clarity

• Associations in which an object is part of a whole are aggregations. Composition is a strong

association in which the part can belong to only one whole -- the part cannot exist without the
whole. Composition is denoted by a filled diamond at the whole end.

This diagram shows that a BoxOffice belongs to exactly one MovieTheater. Destroy the
MovieTheater and the BoxOffice goes away! The collection of Movies is not so closely bound to
the MovieTheater.
 Class information: visibility and scope
The class notation is a 3-piece rectangle with the class name, attributes, and operations. Attributes and
operations can be labeled according to access and scope. Here is a new, expanded Order class.

The class notation is a 3-piece rectangle with the class name, attributes, and operations. Attributes and
operations can be labeled according to access and scope. Here is a new, expanded Order class.

Symbol Access
+ public
- private
# protected
 A Hotel Management System
Superb Hotels Group plc.
There are many hotels in the Superb Hotels group.
Each hotel has a distinct name eg Superb Kensington, Superb
Harrogate, Superb Cleckheaton.
Each hotel handles its own room reservations, arrivals, departures and cancellations.
Each hotel is built to a standard design and has 40 bedrooms and 5 function rooms.
Every room (whether it be a bedroom or a function room) has a room number and may be currently occupied
or unoccupied.
All rooms can be booked by customers.
A booking may involve a number of guests and more than one room but will be associated with exactly one
customer's name.
A function room may be occupied by a large number of guests.
Each bedroom can accommodate 1 or 2 people.
The tariff (charge) per night for a bedroom depends on its
type - there is a single bedroom rate and a double bedroom rate.
The hotel reception staff will sometimes need to check on :
the number of beds in a specified bed
whether a bedroom or function room is currently occupied
The hotel keeps a number of Overhead Projectors (OHPs) for use in function rooms.
It is sometimes necessary to place an OHP in a function room or to remove it.
The hotel will wish to keep track of whether a function room currently has an OHP in it or not.
 Use Case Diagram
• Actors & Use Cases
• A Customer
– Make a booking (check the booking details to work out the
invoice total)
– Cancel a booking (but must still pay if it’s a late cancellation)
• A Guest
– Arrive and check in (check the booking to make sure the
guest is booked in)
– Depart and check out ( and pay for any damages)
• A Manager
– Check if a room is currently occupied
– Check whether a function room has an OHP located in it
– Install an OHP
– Remove the OHP from a room
As check booking details is confirming different information,
depending on whether the customer

is paying (i.e how much) or whether a guest is checking in (i.e is

this guest on the booking)

this suggest that 2 separate use cases may be better.

 Make Booking
Check If Room Occupied
Customer

Can cel Booking

<<Extends>>
Check for OHP

Man ager
Pay for Boo kin g
<<Include/Uses>>
Install OHP

Check Booking Detail

Remove OHP
<<Include/Uses>>

Check In

Guest

<<Extends>>

Check Out
Pay for Damages
 Classes
• Hotel
• Hotel Name
• Operation1, Operation2, Handle Arrival, Handle Departure, Handle Reservation,
Handle Cancellation, check No: of Beds, Check If Occupied
• Tariff
• Functional Room
• Capacity, Has OHP
• Check Fore OHP, Remove OHP, install OHP
• Room
• Room No:, is Occupied
• Check If Occupied
• Bedrooms
• No: of Beds
• Check No: of Beds, vacate, occupy
• Guest
• Guest Name
• OHP
• OHP No:
• Booking
• Start Date, No: of Days
• Customer
• Customer Name
• Party
 The hotel keeps a number of Overhead
There are many hotels in the Superb Hotels group. FuntionRoom Projectors (OHPs) for use in function
Each hotel has a Hotel
distinct name eg Superb Kensington,capacity
Superb: int OHP
1 rooms. 0..1
Harrogate, Superb Cleckheaton.
hotelN am e : string
hasOHP : Boolean OHPN o : Intege
It is sometimes necessary r
to place an
Each hotel handles its own room reservations, arrivals, departures and cancellations
OHP in a function room or to remove
checkForOHP : boolean()
opera ti on1:voi d() removeOHP : void() it.
opera ti on2: void () installOHP : void()
handel Arrival :voi d() The hotel will wish to keep track of
handleDeparture : voi d() whether a function room currently has
handleReservation : voidEach() hotel is built to a standard design and has 40 bedrooms
an OHPandin 5it or not.
handleCancel la ti on : function
void() rooms.
checkNo OfBeds : void() Room
Every room (whether it be a bedroom
chcekIfOccupi ed : vo id()
or a function room) has a room Booking
roomNo : int
number and may be currently occupied or unoccupied.
isOccupied : int startDate : Date
noOfDays : Integer

checkIfOccupied : boolean() 1..* 0..*

1 1..*
All rooms can be booked by customers.

Bedroom
The tariff (charge) per night 0..1
for a 1
t ariff noOfBeds
bedroom depends on its customer
type - chargePerNi ght : in t
there is a single bedroom rate checkNoOfBeds() customerName : String
vacat()
and a double bedroom rate. occupy()

0..1
occupies
A booking may involve0..2
a number of 1
Guest
guests and more than one room but will party
guestName : Stri ng A function room may be occupied by a
be associated with exactly one
customer's name. large number of guests.
 Sequence diagrams
Interaction diagrams are dynamic. They describe how
objects collaborate.

• A sequence diagram is an interaction diagram that

details how operations are carried out -- what messages
are sent and when. Sequence diagrams are organized
according to time. The time progresses as you go down
the page. The objects involved in the operation are listed
from left to right according to when they take part in the
message sequence.

• Below is a sequence diagram for making a hotel

reservation. The object initiating the sequence of
messages is a Reservation window.
 Each vertical dotted line is a lifeline,
representing the time that an object
exists. Each arrow is a message call.
An arrow goes from the sender to the
top of the activation bar of the
message on the receiver's lifeline. The
activation bar represents the duration
of execution of the message.

The diagram has a clarifying

In our diagram, the Hotel note, which is text inside a
issues a self call to dog-eared rectangle. Notes
determine if a room is can be put into any kind of
available. If so, then the UML diagram.
Hotel creates a
Reservation and a
Confirmation. The asterisk
on the self call means
iteration (to make sure
there is available room for
each
Theday of the stay in window
Reservation the sends a makeReservation() message to a HotelChain.
hotel).
TheThe expressionthen
HotelChain in sends a makeReservation() message to a Hotel. If the Hotel
square brackets, [ rooms,
has available ], is a then it makes a Reservation and a Confirmation.
condition.
 A message is
asynchronous if it allows its
sender to send additional
messages while the original
is being processed. The
timing of an asynchronous
message is independent of
the timing of the intervening
messages.

The UML™ uses the following message conventions.

Symbol Meaning

simple message which may be synchronous or asynchronous

The above sequence diagram illustrates the action of a nurse requesting a diagnostic test at a
medical lab. There are twomessage
simple asynchronous messages from the Nurse: 1) ask the MedicalLab to
return (optional)
reserve a date for the test and 2) ask the InsuranceCompany to approve the test. The order in
a synchronous message
which these messages are sent or completed is irrelevant. If the InsuranceCompany approves
the test, then the Nurse will schedule the test on the date supplied by the MedicalLab.
an asynchronous message
Sequence Ali Card Reader ATM Screen Ali's Account Cash
Dispenser
Diagram 1: Accept
2: Read Card

3: Initialize

4: Pompt for PIN

5: Enter PIN(1234)
6: Verify PIN

7: Open Account
8: Propmt for Transaction
9: Select Transaction (Withdraw)

10: Prompt for Amount

11: Enter Amount ($30) 12: Withdraw Fund($30)

13: Verify Funds($30)

14: Deduct Funds($30)

15: Provide Cash($30)

16: Provide Receipt

17: Eject Card
 Collaboration diagrams
Collaboration diagrams are also interaction diagrams. They convey the
same information as sequence diagrams, but they focus on object roles
instead of the times that messages are sent. In a sequence diagram, object
roles are the vertices and messages are the connecting links.

The object-role rectangles are labeled with either class or object

names (or both). Class names are preceded by colons ( : ).
Each message in a collaboration diagram has a
sequence number. The top-level message is
numbered 1. Messages at the same level (sent
during the same call) have the same decimal
prefix but suffixes of 1, 2, etc. according to
when they occur.
 5: Enter PIN(1234)
9: Select Transaction (Withdraw)
11: Enter Amount ($30)
Ali ATM
Screen
4: Pompt for PIN
8: Propmt for Transaction
1: Accept Card 10: Prompt for Amount

2: Read Card No:

3: Initialize Screen

Collaboration Diagram
Card
Reader
6: Verify PIN
7: Open Account
17: Eject Card 12: Withdraw Fund($30)
13: Verify Funds($30)
14: Deduct Funds($30)

15: Provide Cash($30)

16: Provide Rec eipt
Ali's Cash
Account Dispenser
 State chart diagrams
States are rounded
The action rectangles.
that occurs Transitions
as a result of an event areor
arrows fromisone
condition state to in
expressed another.
the
Our Objects
Logging in
example
Events have
can bebehaviors
factored
diagram
or conditions modelsand
into fourstate.
the The state
non-overlapping
login part of of
an an
states:object
online depends
Getting
bankingSSN,
form /action. While inthat trigger transitions
its Validating are object
state, the writtendoes
beside
notthe arrows.
wait for an Our
outside
on its
Getting
system. current
PIN, activity
Validating, or
and condition.
Rejecting. A statechart
From each diagram
state comes shows
a the
complete
event toLogging
diagram has intransition.
consistsInstead,
twoaself-transition,
trigger ofone
entering
on a valid
Getting
it performs ansocial
SSN security
and another
activity. number
on Getting
The result of that PIN.
setpossible
and of states
transitions
personal of the
that
id number, object
determine andsubsequent
the
then submitting the transitions
state.that cause a change
activity determines its subsequent state. the information for validation.
in state.

The initial state (black circle)

is a dummy to start the action.
Final states are also dummy
states that terminate the
action.
Concurrency and asynchronization in state chart diagrams
TheStates
Entering theinAuction
following statechart
statechart diagrams
requires a fork
diagram can
at the
models bestart
an nested. Related
into with
auction two states
separate can be
threads.
two concurrent
grouped
Unless
threads there together
is
leading an twointo
intoabnormal aexit
single
substates composite
(Cancelled
of the state.
or Rejected),
composite Nesting states
the exit from
state Auction: theis
Bidding
andnecessary
Auction
Authorizing when
composite an Bidding
state
Credit. activitywhen
occurs involves
itselfboth concurrent
is a substates
composite or asynchronous
have
stateexited.
with three
subactivities.
substates. Authorizing Credit has two substates.
 Activity diagrams
An activity diagram is essentially a fancy flowchart. Activity diagrams
and statechart diagrams are related. While a statechart diagram focuses
attention on an object undergoing a process (or on a process as an
object), an activity diagram focuses on the flow of activities involved in a
single process. The activity diagram shows the how those activities
depend on one another.

For our example, we used the following process.

"Withdraw money from a bank account through an ATM."

AAtransition
transitionmay may
fork into
branch into twotwo or
ormoreThe
Activity
more three
parallel
mutuallydiagrams
involved
can be The
activities.
exclusive divided
classes
fork
andinto
(people,
theobject
transitions. etc.) of
subsequent
joinswimlanes
Guard the
of activity
the threads are
that
Customer,
determine
coming
expressions out of which
ATM,
the
forkobject
and
(inside [ ])Bank.
appear is in The
label the
process
responsible
diagram
the transitions as begins for at
solid
the out
which
bars.
coming blackactivity.
of start
a A
circle
single
branch. attransition
A branch the top
and ends
comes
and its outatofthe
concentric
each
subsequent activity,
merge white/black
connecting
marking itstop to
circles
the
the end next
of atactivity.
the the
branchbottom.
appear The in
activitiesasare
the diagram
hollowrounded
diamonds.
rectangles.
 Packages diagram
To simplifyappear
Packages complex asclass diagrams,
rectangles with you
smallcan group
tabs classes
at the intopackage
top. The packages.
nameA is on
package
the tab orisinside
a collection of logically
the rectangle. Therelated
dotted UML elements.
arrows The diagramOne
are dependencies. below is a
package
business
depends on model in which
another the classes
if changes in theare grouped
other into packages.
could possibly force changes in the first.
 Object diagram
• Object diagrams show instances instead of classes. They are
useful for explaining small pieces with complicated relationships,
especially recursive relationships.
The object diagram below instantiates the class diagram, replacing it by a
concrete example.

This small class diagram shows that a

university Department can contain
lots of other Departments.

Each rectangle in the object diagram corresponds to a single instance. Instance

names are underlined in UML diagrams. Class or instance names may be omitted
from object diagrams as long as the diagram meaning is still clear.
 Component and deployment diagrams
A component is a code module. Component diagrams are physical
analogs of class diagram. Deployment diagrams show the physical
configurations of software and hardware.
The following deployment diagram shows the relationships among software and
hardware components involved in real estate transactions.

The physical hardware is made up of nodes. Each component belongs on a

node. Components are shown as rectangles with two tabs at the upper left.