Introduction to UML

Overview

• What is UML?
• A brief history of UML and its origins.
• Understanding the basics of UML.
• UML diagrams
• UML Modeling tools
 What is
UML?
UML: Unified Modeling Language
• An industry-standard graphical
language for specifying, visualizing,
constructing, and documenting the
artifacts of software systems, as well
as for business modeling.

• The UML uses mostly graphical

notations to express the OO analysis
and design of software projects. 

• Simplifies the complex process of

software design
 Why UML for Modeling?
• A diagram/picture = thousands words
• Uses graphical notation to communicate more
clearly than natural language (imprecise) and
code(too detailed).
• Makes it easier for programmers and software
architects to communicate.
• Helps acquire an overall view of a system.
• UML is not dependent on any one language or
technology.
• UML moves us from fragmentation to
standardization.
 History

Tim
Year Version
e 2003: UML 2.0
2001: UML 1.4
1999: UML 1.3
1997: UML 1.0, 1.1
1996: UML 0.9 & 0.91
1995: Unified Method 0.8

Booch OMT -
Other ‘93 2
methods

Booch ‘91
OMT -
1
 Types of UML Diagrams

Use Case Diagram: capture requirements. Clarify exactly

what the system is supposed to do
Displays the relationship among actors and use cases.
Different from traditional flow chart.

Class Diagram: static relationships between classes.

Describe the types of objects in the system and various kinds
of static relationship that exist among them.

Sequence Diagram:
Displays the time sequence of the objects participating in the
interaction.
 Types of UML Diagrams
(Cont.)
Collaboration Diagram
Displays an interaction organized around the objects
and their links to one another.
State Diagram
Displays the sequences of states that an object of an
interaction goes through during its life in response to
received stimuli, together with its responses and
actions.

Component Diagram
Illustrate the organizations and dependencies of
the physical components in a system. A higher level
than class diagrams.
 Use Case Diagrams

Boundar Use Case

Actor y
Library System

Borro
w
Employe
Clien e
t

Order Title

Fine Remittance

Superviso
r

•  A generalized description of how a system will be used. 

•  Provides an overview of the intended functionality of the
system
 Use Case Diagram(core
components)

Actors: A role that a user plays with respect to

the system,including human users and other
systems. e.g.,inanimate physical objects (e.g. robot);
an external system that needs some information
from the current system.

Use case: A set of scenarios that describing an

interaction between a user and a system.
 Use Case Diagram (core
components)

• A use case is a single unit of meaningful work. E.

g. login, register, place an order, etc.
• Each Use Case has a description which
describes the functionality that will be built in
the proposed system.
E.g. for use case “order title” , a brief description:
This use case receives orders from employee or
supervisor, then return the ordered title.
System boundary: a rectangle diagram
representing the boundary between the actors
and the system.
 Use Case Diagram(core relationship)

Association: communication between an actor

and a use case; represented by a solid line.

Generalization: relationship between one

general use case and one specific use case.
Represented by a line with a triangular arrow
head toward the parent use case, the more
general modeling element.

employee
waitress
 Use Case Diagram(core relationship)

Include: a dotted line labeled <<include>>

beginning at base use case and ending with an
arrows pointing to the include use case. An
“Include” relationship is used to indicate that a
particular Use Case must include another use case
to perform its function. 
<<include>>

A
orUse Case
in MS may be included by one or more Use
Visio
Cases, so it reduces duplication of functionality.
Example: the <list orders> Use Case may be
included
every time when the <modify order> Use Case is
run.
 Use Case Diagram (core
relationship)

• Extend: a dotted line labeled <<extend>> with an arrow

toward the base case. The extending use case may add
behavior to the base use case. The base class declares
“extension points”.
<<extend>>

Used when exceptional circumstances are encountered. For

example, the <get approval> Use Case may optionally extend
the regular <modify order> Use Case.

Note: other expressions. For example, in MS Visio

Use Case Diagrams(cont.)

(TogetherSoft, Inc)
 Use Case Diagrams(cont.)
• Pay Bill is a parent use case and Bill
Insurance is the child use case. (generalization)

• Both Make Appointment and Request

Medication include Check Patient Record as a
subtask.(include)

• The extension point is written inside the base

case
Pay bill; the extending class Defer payment
adds the behavior of this extension point.
(extend)
 Class Diagram
• Each class is represented by a rectangle subdivided
into three compartments
– Name
– Attributes
– Operations
• Modifiers are used to indicate visibility of attributes
and operations.
– ‘+’ is used to denote Public visibility (everyone)
– ‘#’ is used to denote Protected visibility (friends
and derived)
– ‘-’ is used to denote Private visibility (no one)
• By default, attributes are hidden and operations are
visible.
• The last two compartments may be omitted to simplify
the class diagrams
 An example of Class

Name
Account_Name
- Custom_Name
Attributes
- Balance
+AddFunds( ) Operations
+WithDraw( )
+Transfer( )
C++ Class Example

class Checking {
private:
char Customer_name[20];
float Balance;
public:
AddFunds(float);
WithDraw(float);
Transfer(float);
set_name(string);
get_name();
set_balance(float);
get_balance();
};
 Notation of Class Diagram: association
Associations represent relationships between
instances
of classes .
An association is a link connecting two classes.
• Bi-directional association
Associations are assumed to be bi-directional
e.g. Flight and plane
notation:

• Uni-directional association
e.g. Order and item
notation:
Association: Multiplicity and Roles

student
1 *

Universit Perso
y n

0.. *
1
employe teache
r r
Multiplicity
Symbol Meaning Role
Rol
1 One and only one e groups many
“A given university
0..1 Zero or one people; some act as students,
M..N From M to N (natural language) others as teachers. A given student
* From zero to any positive integer
belongs to a single university; a
given teacher may or may not be
0..* From zero to any positive integer working for the university at a
1..* From one to any positive integer particular time.”
 Notation of Class Diagram:
Generalization

Supertype Customer
Example:

Regular Loyalty
Customer Customer
Subtype
Subtype
2
1 or: Customer
Generalization
expresses a relationship
among related classes.
It is a class that includes
Regular Loyalty
its subclasses. Customer Customer
 Notation of Class Diagram: Composition
COMPOSITIO Composition: expresses a relationship among
N Whole instances
Class of related classes. It is a specific kind of Whole-Part
Class W
relationship.

It expresses a relationship where an instance of the

Whole-class has the responsibility to create and
initialize
Class P 1 Class P 2 instances of each Part-class.

It may also be used to express a relationship where

instances
Part of the Part-classes have privileged access or
Classes visibility to
certain attributes and/or behaviors defined by the
Examp
Whole-class.
le
Automobi
le Composition should also be used to express
relationship where
instances of the Whole-class have exclusive access
to and
control of instances of the Part-classes.
Transmiss
Engine
ion Composition should be used to express a
relationship where
[Fromthe behavior
Dr.David A.of Part instances is undefined without
being
Workman]
related to an instance of the Whole. And,
 Notation of Class Diagram: Aggregation
Container
Class
Class C Aggregation: expresses a relationship among
instances
AGGREGATIO of related classes. It is a specific kind of
N Container-Containee relationship.

It expresses a relationship where an instance

Class E1 Class E2 of the
Container-class has the responsibility to hold
and maintain instances of each Containee-class
that have been created
Containee
outside the auspices of the Container-class.
Classes
Aggregation should be used to express a more
informal
Examp relationship than composition expresses. That
Bag is, it is an
le
appropriate relationship where the Container
and its
Containees can be manipulated independently.

Apples Milk Aggregation is appropriate

whenA.Container and
[From Dr.David
Containees have no special
Workman]
 Aggregation vs.
Composition
Composition is really a strong form of aggregation
• components have only one owner
• components cannot exist independent of their owner;
both have coincident lifetimes
• components live or die with their owner
e.g. (1)Each car has an engine that can not be shared
with other cars.  
(2) If the polygon is destroyed, so are the points.

Aggregations may form "part of" the aggregate, but

may not be essential to it. They may also exist
independent of the aggregate. Less rigorous than a
composition.
e.g. (1)Apples may exist independent of the bag.
(2)An order is made up of several products, but the
products are still there even if an order is
cancelled.
 Sequence Diagram: Object
interaction

A B

Self-Call: A message that an Synchronou

s
Object sends to itself.
Asynchronou
Condition: indicates when a s
message is sent. The Transmission
delayed
message is sent only if the
condition is true.
[condition]
Condition remove()
*[for each]
remove()
Iteration
Self-
Call
 Sequence Diagrams – Object Life
Spans
• Lifelines
The dotted line that extends down
the vertical axis from the base of
each object.
A
• Messages
Labeled as arrows, with the
arrowhead indicating the direction of Creat
the call. e B

• Activation bar
The long, thin boxes on the lifelines
are method-invocation boxes
indicting that indicate processing is
being performed by the target
object/class to fulfill a message.
Activation
bar X
• Rectangle also denotes when object Retur
is deactivated. n Deletio
n
Lifelin
• Deletion e
– Placing an ‘X’ on lifeline
– Object’s life ends at that point
 Sequence Diagram
Message

• Sequence diagrams demonstrate the behavior of objects in a use case

by describing the objects and the messages they pass.
• The horizontal dimension shows the objects participating in the interaction.
• The vertical arrangement of messages indicates their order.
• The labels may contain the seq. # to indicate concurrency.
 Interaction Diagrams: Collaboration
diagrams

• Shows the relationship between objects and the order of

messages passed between them. 

• The objects are listed as rectangles and arrows indicate

the messages being passed.

• The numbers next to the messages are called sequence

numbers. They show the sequence of the messages as they
are passed between the objects. 

• Convey the same information as sequence diagrams, but

focus on object roles instead of the time sequence.
 Interaction Diagrams: Collaboration
diagrams (cont.)
start

6: remove
reservation
3 : [not available] reserve
title
User Reservation
s
5: title
6 : borrow
available
title 1: look
2: title up
data

4 : title
returned
Catalo
g
5 : hold
title
 State Diagrams
(Billing Example)

State Diagrams show the sequences

of states an object goes through
during its life cycle in response to
stimuli, together with its responses
and actions; an abstraction of all
possible behaviors.
Start En
Unpai d
d Paid
Invoice payi Invoice
created ng destroying
 Basic rules for State Diagrams
• Draw only one object's chart at a time.

• A state is drawn as a box with rounded corners.

• From each state draw an arrow to another state

if the object can change from one to the other in
one step.

• Label the arrow with the event that causes it.

• Show the initial state by drawing an arrow from

a black filled circle to the initial state.

• Show the end state by drawing an arrow to a

circle with a filled circle inside it.
 State Diagrams
(Traffic light example)

Traffic Light Sta

Stat rt

Transition e Re
d
Yellow

Green

Event
 Component Diagram
• Illustrate the organizations and dependencies of
the physical components in a system.
• Has a higher level of abstraction than a Class
diagram - usually implemented by one or more
classes.
Symbols and Notations

Components
a large rectangle with two smaller rectangles on the side.
 Component Diagram (cont.)
Interface
An interface describes a group of operations
used or created by components. It represents a
declaration of a set of coherent public features
and obligations, similar to a contract.

Dependencies

dashed arrows.
 Component Diagram (cont.)

order

custo
mer

accou
nt

Order provides a component interface, which is a collection of

one or more methods with or without attributes.

Account and customer components are dependent upon the

interface of the order.
 UML Modeling Tools
• Rational Rose (www.rational.com) by IBM
• UML Studio 7.1 ( http://www.pragsoft.com/) by
Pragsoft Corporation
Capable of handling very large models (tens of
thousands of classes). Educational License US$
125.00; Freeware version.
• Microsoft Visio
• Dia: open source, much like visio. (http://www.gnome.
org/projects/dia/)
• ArgoUML (Open Source; written in java ) (http://www.
apple.com/downloads/macosx/development_tools/
argouml.html )
• Others (http://www.objectsbydesign.com/tools/
umltools_byCompany.html )
Microsoft Visio
UML studio 7.1
Poor Design, need more heuristics!

(Radu
Marinescu[5])
A cleaner design

(Radu
Marinescu[5])
 Reference

1. UML Distilled: A Brief Guide to the Standard Object Modeling Language

Martin Fowler, Kendall Scott

2. Practical UML --- A Hands-On Introduction for Developers

http://www.togethersoft.com/services/practical_guides/umlonlinecourse/

3. OO Concepts in UML. Dr. David A. Workman, School of EE and CS.

UCF.

4. Software Engineering Principles and Practice. Second Edition;

Hans van Vliet.

5. http://labs.cs.utt.ro/labs/acs/html/lectures/4/lecture4.pdf