Unified Modeling Language

(UML) Fundamentals

By, Jalpa Ashara

Rational Vs. Creative enterprises

Aspects of the
development of a
commercial product

Creative Rational
• Intuitive • Logical
• Vague • Well defined
• Personalized • Impersonal
UML : Motivation

To evolve a method which provides

support for the creative design of
software products, and also provides
an approach for making software
development a rational industrial
process.
Characteristics of a Rational enterprise

1. The process must yield a foreseeable result, irrespective

of which individual performed the job.
2. The volume of output does not affect the process.
3. It must be possible to allocate parts of the process to
several manufacturers / subcontractors.
4. It must be possible to make use of predefined building
blocks and components.
5. It must be possible to plan and calculate the process
with great precision.
6. Each person trained for an operation must perform it in a
similar manner.
 Unified Modeling Language (UML)

The UML is a language for

• visualizing
• specifying
• constructing
• documenting
The artifacts of a software-intensive process.
It is the standard language for software blueprint.

The UML is a graphical language that

enables us to write down on paper the
work that we produce in the course of
building a software system.
 Why do we call it graphical ?

A Language
Some UML Notations

Notations Grammar

Two aspects of a Language

Process loan
Loan officer

UML symbols joined together

To form an UML diagram
 The three Amigos
1989-1994 : more than 50 modeling
languages – Method wars.

Gr on
(Rat ady Bo aco
b s
io n a o J
l So ch Ive r
ftwa ss on)
k
re) UML (Eri
(Mid 90s)

James Rambaugh
(General Electric)
 Building Blocks of UML

THINGS RELATIONSHIPS DIAGRAMS

1. Structural 1. Dependency 1. Class diagram
2. Behavioural 2. Association 2. Object diagram
3. Grouping 3. Generalization 3. Use-case diagram
4. Annotational 4. Realization 4. Sequence diagram
5. Collaboration diagram
6. Statechart diagram
7. Activity diagram
8. Component diagram
9. Deployment diagram
What are the UML ‘Things’ ?
THINGS
1. Structural
2. Behavioural
3. Grouping
4. Annotational

Things are mostly the static parts

of a model, representing elements that are
either conceptual or physical. These are
the nouns of the UML model.
There are seven kinds of structural
things.
Seven Structural
UML ‘Things’

1 Class
2 Interface
3 Collaboration
4 Use Case
5 Active Class
6 Component
7 Node
Structural Thing 1 : Class

A Class is a user defined

data type consisting of data
as well as behaviour.

window
origin
size
open()
close()
move()
display()
 Structural Thing 2 : Interface

An interface is a collection of operations that

specify a service of a class or component. It
describes the externally visible behaviour of an
element. Typically, an interface is attached to the
class or component that realizes the interface.

IUnknown
Spelling.dll

ISpelling
 Structural Thing 3 : Collaboration

An interaction and is a society of

roles and other elements that work
together to provide some
cooperative behaviour.

Chain of
responsibility
Structural Thing 4 : Use Case

Is a description of set of sequence of actions

that a system performs that yields an observable
result of values to a particular actor. It is used to
structure the behavioural things in a model.
A use case describes a set of interactions
with the system that supports a particular business
goal. They are almost always described using a
simple, clear, and concise verb/noun combination.

actor
Withdraw Money

Customer
Use case

An actor is someone (or something)

who can triggar a use case.
Structural Thing 5 : Active class

A class whose objects own one or more

processes or threads and therefore can
initiate control activity. An active class is
just like a class except that its objects
represent elements whose behaviour is
concurrent with other elements.

Event Manager

Suspend()
Flush()
Structural Thing 6 : Component

Is a physical and replaceable part

of a system that conforms to and
provides the realization of a set of
interfaces.

Orderform.java
 Structural Thing 7 : Node

A node is a physical element that

exists at run time and represents a
computational resource, generally
having at least some memory and,
often, processing capability.

Server
Behavioural ‘Things’
THINGS
1. Structural
2. Behavioural
3. Grouping
Behavioural things are the
4. Annotational
dynamic parts of the UML
model, representing behaviour
over time and space.

Two kinds of interaction things :

• Interaction
• State machine
Behavioral Thing 1 : Interaction

An interaction is a behaviour that

comprise a set of messages
exchanged among a set of objects
within a particular context to
accomplish a specific purpose.

display
Behavioral Thing 2 : State
machine
A state machine is a behaviour
that specifies the sequence of
states an object or an interaction
goes through during its lifetime in
response to events, together with
its response to those events.

waiting
Grouping ‘Things’

THINGS
1. Structural
Grouping things are the
2. Behavioural organizational parts of the UML.
3. Grouping These are shown as packages.
4. Annotational Unlike components (which
exist at runtime) a package is
purely conceptual, meaning,
it only exits at development time.

Business rules
Annotational ‘Things’

THINGS
1. Structural Explanatory parts of
2. Behavioural UML models. These are
3. Grouping comments one may
4. Annotational apply to describe,
illuminate and remark
about any element in a
model.
Return copy of self
 Building Blocks of UML

THINGS RELATIONSHIPS DIAGRAMS

1. Structural 1. Dependency 1. Class diagram
2. Behavioural 2. Association 2. Object diagram
3. Grouping 3. Generalization 3. Use-case diagram
4. Annotational 4. Realization 4. Sequence diagram
5. Collaboration diagram
6. Statechart diagram
7. Activity diagram
8. Component diagram
9. Deployment diagram
RELATIONSHIPS
1. Dependency
2. Association A dependency is a semantic
3. Generalization relationship between two
4. Realization things in which a change to
one thing (the independent
thing) may affect the
semantics of the other thing
(the dependent thing).

Bank Bank
Transaction Account
RELATIONSHIPS
1. Dependency
2. Association
3. Generalization
An association is a structural
4. Realization relationship that describes a set of
links, a link being a connection among
objects. Aggregation is a special kind
of association, representing a
structural relationship between a
whole and its parts.

Employer 0..1 Employee

RELATIONSHIPS
1. Dependency
2. Association
3. Generalization A Specialization / generalization
4. Realization relationship is one in which the
objects of the specialized
element (the child) are
substitutable for objects of the
generalized elements (parent).

Child Parent
RELATIONSHIPS
1. Dependency
2. Association Realization is a semantic relationship
3. Generalization between classifiers, wherein one
classifier specifies a contract that another
4. Realization classifier guarantees to carry out.

Realization relationship exists in two

places: one, between interfaces and the
classes/components that realize them,
and two, between use cases and the
collaborations that realize them.
 Building Blocks of UML

THINGS RELATIONSHIPS DIAGRAMS

1. Structural 1. Dependency 1. Class diagram
2. Behavioural 2. Association 2. Object diagram
3. Grouping 3. Generalization 3. Use-case diagram
4. Annotational 4. Realization 4. Sequence diagram
5. Collaboration diagram
6. Statechart diagram
7. Activity diagram
8. Component diagram
9. Deployment diagram
 Use Case Diagram

A Use Case diagram shows a

set of Use-cases and Actors
and their relationships.
These are important in
organizing and modeling the Withdraw Money
behaviour of a system.

Customer Check Balance

Refill Machine

Banker Shutdown
Why Use Cases ?
Use Case diagram is considered to be the
cornerstone of the UML. Because …

Use Cases define the scope of the system – the ‘sum’ of

the use cases is the whole system. Hence, they can take
the place of functional requirement.

They allow for communication between the customer,

analyst, and developers.

Use Cases guide the development teams through the

development process.

Use Cases help with the creation of user guides.

Who is an actor ?

An actor is anyone / anything that can

trigger a Use Case. Therefore an actor
could be …

A human being

Another computer system

A mechanical object

Some kind of time-based event, e.g. “end of month”

Use Case granularity : How big a Use Case should be ?

Read card

Read PIN

Read amount
required

To handle the Dispense card

Customer
complexities of very
large systems we Eject Card
need to keep the
Use Cases at a fairly Print receipt
high level.

A useful Use Case diagram for ATM ?

 Use Case granularity : Rule of Thumb ?

A Use Case should

satisfy a goal for the
actor.

Withdraw Money

Customer

A more focused Use Case diagram for ATM

 Primary actor and secondary actor

A secondary actor is an
A primary actor is the actor that plays a part
actor that receives the in, or supports in some
benefit of the use case. way, the Use Case.

Withdraw Money

Customer Credit reference agency

A common practice (not a rule) is to place

primary actors on the left and secondary
actors on the right.
 Use Case Diagram : Credit Card System

Perform
Card Transaction
Report
Account Status
Customer Retail
Process Institution
Customer Bill

Reconcile
Transactions
Detect
Individual Corporate Card Fraud
Customer Customer
Sponsoring
Manage
Financial
Customer Account Institution
 Generalization, Include, Extend

<<extend>>
Place Order Set Priorities
Place
Extension Point
Rush Order
Set Priority

<<include>>

Include
Relationship Validate
User Check

Trash <<include>>
Generalization
Order

Retinal Scam
Project Management Issue : How to Find Use Cases ?

1. Take interview of the stakeholders.

2. Conduct a workshop with the stakeholders.

Critical point

The use-case diagram must be so simple that all

stakeholders, even the non-computer literate
stakeholders, should be able to grasp the concept of
the diagram with ease.
Finding Use Cases through interview

Problem:

People are likely to give two completely different

views on what the system should do, even if they
work for the same company.
Finding Use Cases through Workshop

1 Brainstorm all of the possible actors first.

2 Next, brainstorm all of the possible Use Cases.
3 Once the brainstorming is complete, prune the
proposed list of actors and Use Cases through
concensus.
4 Create the Use Case diagram.
How to Brainstorm ?

1 Document all ideas, no matter how outrageous or

nonsensical they seem. Stupid ideas might turn out
to be very sensible ideas after all.
2 Silly ideas may trigger off more sensible ideas in
other people’s mind. This is called leapfrogging
ideas.
3 Never evaluate or criticize ideas. This is a very hard
rule to observe – we are trying to break human
nature here.
Activity Diagram

An activity diagram shows the flow

from activity to activity within a
system.

Activity diagrams are especially

important in modeling the function
of a system and emphasizes the
flow of control among the objects.
Action / Activity States

Bid Plan

Index := lookup(e)+7

Process Bill
Action States

Do Construction

Activity States
 Transitions
Start
State

Select Site

Action
State

Commission Architect

Triggerless
Transition

Stop
State
Branching

Release work order

Guard expression

[materials not ready]

Reschedule

[materials ready]

Commission Architect
Branch
Forking & Joining

Prepare for speech Fork

Decompress

Gestures()

Join Synch mouth() Stream audio()

Clearup
Activities performed by a petty
manager on his way to work
Swimlanes Sales
Customer Warehouse

Request product

Process order
Pull materials

Ship order

Receive order Bill customer

Pay bill
Close order
Object flow Customer Sales Warehouse

Request product Object flow

Process order

Pull materials
o:Order
Ship order
[in progress]

o:Order
Receive order Bill customer
[filled]

b:Bill
Pay bill [unpaid] Object
State

Close order
b:Bill
[paid]
Statechart Diagram

Shows a state machine,

consisting of states, transitions,
events, and activities – is
especially useful in modeling
reactive systems.
State diagram : Summary of basic notations
Traffic light state
diagram : first attempt
Adding Turn Off
event to Traffic
light state diagram
 Traffic light state
diagram : using super
and sub states to tidy
up the diagram

Traffic light state

diagram : final version
with reset event
State Machine for an air-conditioner
Initial Final
State State
Shut Down
Event parameter
Idle

p)
m
Te
Too Cold (desired Temp)

d
rei
es
(d

At
p Event
ot

em

te
H

m
T
o

p
To

A
Initial State

Too Hot (desired Temp)

Cooling Heating

Activating
Ready/turnOn()
Too Cool (desired Temp)
State
Active
transitions

Nested states
State Machine
for the
controller Initializing
in a home After (IO seconds)/ Self Test
security
system
Idle
Alarm(s)

Clear

Command Active
Checking
attention
Waiting

Calling
Entry/ setAlarm Entry 1
Exit / clearAlarm callCentre(s)
 State diagram of a FAX machine

Idle ringing

Receiving

Hang Up Connected header OK

End Fax

Process

Error / Cleaning up Check Sum OK

Cleaning up Print Report
Entry / Pick Up
Exit / Disconnect
 Interaction Modeling : Sequence diagram &
Collaboration diagram
Both sequence diagram and
collaboration diagrams are kinds of
interaction diagrams. They show the
interaction, consisting of a set of objects
and their relationships, including the
messages that may be dispatched
between them.
They address dynamic view of the
system.
A sequence diagram emphasizes the
time-ordering of the messages.

A collaboration diagram emphasizes the

structural organization of the objects that
send and receive messages.
 Responsibility & Collaboration

Responsibility : What each object should

be able to do ?

Collaboration : How the objects should

“work together” to make use cases
happen ?

Borrow named book

member

A real world Use Case to borrow a book

from the library
 Realization of Use Case through collaboration

Second
collaboration

First
collaboration
Realization of Use Case through collaboration

Third
collaboration
Realization of Use Case through collaboration

Fourth
collaboration
Realization of Use Case through collaboration

Final
collaboration
diagram
Collaboration Diagram : example

c: Client

link 1: << create >>

2: set Actions (a,d,0)
3: << destroy >> Path stereo type

<< local >> message

<< global >>

: Transaction p: ODBC Proxy
{ transient } 2.1 : set Values (d,3.4)
2.2 : set Values (a,”co”)
Example Sequence Diagram

c: Client p: ODBC Proxy

{ transient }
<< create >>
: Transaction
set Actions (a,d,0)
set Values (d,3.4)
time

set Values (a, “co”)

Focus
Life
of control
line
 s: Caller : Switch r: Caller

Lift Receiver

setDialTone()
{ dialing execution Time<30 sec}
*dialDigit(d) routeCall(s,n)
Dialing

<< create >>

c: Conversation
Ring()
liftReceiver()
Connect(r, s)
Connect(s)
Sequence
Connect(r)
Diagram :
Initiating
a simple,
two-party
phone Callers s and r may exchange
call information after both are connected
Class diagram

Shows a set of classes, interfaces,

and collaborations and their
relationships.

Class diagram address the static

design view of an object oriented
system.
Class diagram : Example

Statement
A company consists of one or more departments as
well as one or more offices. One of the office is
designated to be the headquarter. Departments are
located at the offices. Moreover, a department may
further consist of zero or more departments.
Persons are attached to departments. Each
department has a manager, who of course, is a
person attached to the department. There should be
provisions to get the photo of a person, his/her
voice recording, contact information and other
personal records. An authorized user may obtain
information regarding a person from personal
record.
 class Company

aggregation
Name

* 1…* 1…*
Department multiplicity Office

Name: Name Address: String

* Location *
0…1
* * Constraint Generalization/
{ subset } specialization
Role
Association
Headqiarters

Employee 1 … * 1 Manager
Person
ContactInformation
Name: Name attributes
EmployeeID: Integer operations Address: String
Title: String Interface
getPhoto(p: photo)
getSandBite() PersonnelRecord
getContactInformation()
taxID
getPersonalRecords()
employmentHistory
salary
dependency I Secure Information
Object Diagram
Objects diagrams show a set of
objects and their relationships. They
represent static snapshots of
instances of the things found in class
diagrams.

Object diagrams show a static design

view, but from the perspective of real
or prototypical cases.
Object Diagram :
example c: Company

d1 : Department d2 : Department
name = “Sales” name = “R&D”
link

d3 : Department
Object Attribute value
name = “US Sales”

Anonymous object

Manager : Communication
p : Person address = “1472 Miller St.”
name = “Erin”
employeeID = 4362
title = “VP of Sales”
Component Diagram

A component diagram shows the

organization and dependencies
among a set of components.

It addresses the static

implementation view of the system.
Component Diagram : Modeling source code

Signal.h Signal.h Signal.h

{version = 3.5} {version = 4.0} {version = 4.1}

------ ------ ------

------ ------ ------
------ ------ ------
------ ------ ------

Interp.cpp Signal.cpp

------ ------
------ ------
------ ------
------ ------

Irq.h Device.cpp

------ ------
------ ------
------ ------
------ ------
Modelling an executable release:
Executable release of an autonomous robot

path.dll collision.dll

driver.dll
{ version = 8.1.2.3 }

IDrive

IselfTest
Component Diagram :
Modeling of Physical Database

School.db

Course Department Instructor School Student

 Modeling Adaptable Systems

The school database on

Server B
Replicates the database
On Server A

School.db School.db
{ location = Server A } { location = Server B }

<<copy>>
Deployment
Diagram

Deployment diagrams show the

configuration of run-time
processing nodes and the
components that live on them.
 A typical
Modem bank deployment
Internet diagram

<<processor>> <<processor>>
Caching Caching
Server Server

<<processor>>
<<processor>> <<processor>> <<processor>>
Printing
Server Server Server
Server
Deployment diagram :
Modeling a client / server
system

Server

Client << processor >>

<< processor >>
Server
Caching Server
------------------------
------------------------
Deploys
Deploys
Dbadmin.exe
http.exe
console Tktmstr.exe
rting.exe
kiosk Logexe.exe
 Note: country servers are reachable
: console : console : console
to one another via the company
private network

: regional
server

: Internet
: country
server

: regional
server
: regional
server
: logging
Deployment diagram of a fully server
distributed system
 Deployment Diagram :
example
Network
server
server

local
server

Database
client

Client
program

Data access Data file

How to link everything together ?

No specific rule,
but here is a
typical case.
A few rules-of-thumb

1. Give a name to a diagram that communicates its

purpose.
2. Lay out the elements such that the line that cross are
minimized.
3. Use notes and colours as visual aids to draw attention
to important features of your diagram.
4. Use branching sparingly.
5. Use a sequence diagram if you want to emphasize the
time ordering of message.
6. Use a collaboration diagram if you want to emphasize
the organization of objects involved in the interaction.
7. A use case should satisfy a goal to an actor.
Thanks