UML Class Diagram

UML
UML is a language used for object-oriented analysis and
design.
UML includes a set of graphical notation techniques to create
visual models of software systems.
Three developers of UML are Grady Booch, Ivar Jacobson
and James Rumbaugh.
UML is a language for visualizing, specifying, constructing,
documenting.
UML is not a development method. It is designed to be
compatible with the object-oriented software development
methods.

UML
UML can be used to construct nine different types of
diagrams to capture five different views of a system.
Just as a building can be modeled from several views (or
perspectives) such as ventilation perspective, electrical
perspective, lighting perspective, heating perspective, etc.;
the different UML diagrams provide different perspectives
of the software system to be developed and facilitate a
comprehensive understanding of the system.
Such models can be refined to get the actual
implementation of the system.

UML

Views in UML
1. Functional View:
This view describes functional requirements of the system.
Use case diagrams give static functional view for functions
and static relationships.
Activity diagrams give dynamic functional view.

2. Static Structural View:

The class and object diagrams give the structural view of
system.

Views in UML
3. Behavioral (dynamic structural) view:
Interaction diagrams- collaboration diagrams and sequence
diagrams describe sequences of interactions between objects.
State transition diagrams show state-based behavior of
objects.

4. Architectural View:
This view describes logical and physical structure.
Component diagrams and deployment diagrams are used in
this view.

Views in UML

What is a Class Diagram?

A Class Diagram is a diagram describing
the structure of a system
shows the system's

classes
Attributes
operations (or methods),
Relationships among the classes.

Essential Elements of a
UML Class Diagram

Class
Attributes
Operations
Relationships

Associations
Generalization
Realization
Dependency

Constraint Rules and Notes

Class
Describes a set of objects having similar:
Attributes (status)
Operations (behavior)
Relationships with other classes

Attributes and operations may

have their visibility marked:

"+" for public
"#" for protected
"" for private
"~" for package

Class
Name

Window

Attributes

size: Size
visibility: boolean

Operations

display()
hide()

Associations
An association between two classes indicates that
objects at one end of an association recognize
objects at the other end and may send messages to
them.
Example: An Employee works for a Company
Employee

Company

Associations (cont.)
Role
name

StaffMember

instructor
1..*

Multiplicity

Association
name
instructs

Navigable
(uni-directional)
association

Student
Role
*

Courses
Reflexive
association

pre requisites
0..3

Associations (cont.)
To clarify its meaning, an association may be named.
The name is represented as a label placed midway along
the association line.
Usually a verb or a verb phrase.

A role is an end of an association where it connects

to a class.
May be named to indicate the role played by the class
attached to the end of the association path.
Usually a noun or noun phrase
Mandatory for reflexive associations

Associations (cont.)
Multiplicity
the number of objects that participate in the association.
Indicates whether or not an association is mandatory.
Multiplicity Indicators

Exactly one
Zero or more (unlimited)

1
* (0..*)

One or more

1..*

Zero or one (optional association)

0..1

Specified range

2..4

Multiple, disjoint ranges

2, 4..6, 8

Aggregation
A special form of association that models a
whole-part relationship between an
aggregate (the whole) and its parts.
Models a is a part-part of relationship.
2..*

Car

Whole

Door
Part

1..*

House

Aggregation (cont.)
Aggregation tests:
Is the phrase part of used to describe the relationship?
A door is part of a car

Are some operations on the whole automatically applied to its

parts?
Move the car, move the door.

Are some attribute values propagated from the whole to all or

some of its parts?
The car is blue, therefore the door is blue.

Is there an intrinsic asymmetry to the relationship where one class

is subordinate to the other?
A door is part of a car. A car is not part of a door.

Composition
A strong form of aggregation
The whole is the sole owner of its part.
The part object may belong to only one whole

Multiplicity on the whole side must be zero or one.

The life time of the part is dependent upon the whole.
The composite must manage the creation and destruction of its
parts.

Circle
Polygon

Point
3..*

Circle

Point

Generalization

Indicates that objects of the specialized

class (subclass) are substitutable for objects
of the generalized class (super-class).
is kind of relationship.
{abstract} is a

tagged value that

indicates that the
class is abstract.
The name of an
abstract class should
be italicized

An abstract
class

Shape
{abstract}

Generalization
relationship
Circle

Super
Class

Sub
Class

Generalization
A sub-class inherits from its super-class
Attributes
Operations
Relationships

A sub-class may
Add attributes and operations
Add relationships
Refine (override) inherited operations

A generalization relationship may not be used to

model interface implementation.

Realization
A realization relationship indicates that one
class implements a behavior specified by
another class (an interface or protocol).
An interface can be realized by many
classes.
A class may realize many interfaces.
LinkedList

<<interface>>

List

ArrayList

Dependency
Dependency is a weaker form of relationship which
indicates that one class depends on another because it uses
it at some point in time.
One class depends on another if the independent class is a
parameter variable or local variable of a method of the
dependent class.
This is different from an association, where an attribute of
the dependent class is an instance of the independent class.
Iterator

<<friend>>

Vector

Constraint Rules and Notes

Constraints and notes annotate among other
things associations, attributes, operations and
classes.
Constraints are semantic restrictions noted as
Boolean expressions.
UML offers many pre-defined constraints.
Customer

id: long { value > 0 }

*
{ total < $50 }

Constraint

Order

may be
canceled

Note

STANDARD CLASS STEREOTYPES

Standard class stereotypes include:
1.
2.
3.
4.

focus
auxiliary
type
utility

 focus
Focus is class that defines the core logic or control flow
for one or more supporting classes.
The supporting classes may be defined either explicitly
using auxiliary classes or implicitly by dependency
relationships.
Focus classes are typically used for specifying the core
business logic or control flow of components during
design phase.

 auxiliary
Auxiliary is class that supports another more central or
fundamental class, typically by implementing
secondary logic or control flow.
The class that the auxiliary supports may be defined
either explicitly using a focus class or implicitly by a
dependency relationship.
Auxiliary classes are typically used for specifying the
secondary business logic or control flow of components
during design phase.

 type
Type is class that specifies a domain of objects together
with the operations applicable to the objects, without
defining the physical implementation of those objects.
Type may have attributes and associations.
Behavioral specifications for type operations may be
expressed using, for example, activity diagrams.
An object may have at most one implementation class,
however it may conform to multiple different types.

 utility
Utility is class that has only class
scoped static attributes and
operations.
As such, utility class usually has
no instances.
Math is utility class - having
static attributes and operations
(underlined)

E
X
A
M
P
L
E

Creating a Class Diagram

Identify Classes
These are the abstract or physical things in our
system which we wish to describe.
Find all the nouns and noun phrases in the domain
descriptions you have obtained through your analysis.
Consider these class candidates.

Creating a Class Diagram

Find Associations
Now find the verbs that join the nouns. e.g., The
professor (noun) teaches (verb) students (noun).
The verb in this case, defines an association between
the two nouns.
Identify the type of association. Use a matrix to define
the associations between classes.

Creating a Class Diagram

Draw Rough Class Diagram
Put classes in rectangles and draw the associations
connecting the classes.

Fill in Multiplicity
Determine the number of occurrences of one class for a
single occurrence of the associated class.

Creating a Class Diagram

Identify Attributes
Name the information details (fields) which are
relevant to the application domain for each class.

Identify Behaviors Specify the operations that are required for each class.
(assume getter and setter methods for each attribute.)

Creating a Class Diagram

Review your diagram and fine tune it.
Look for inconsistencies and errors.
Fix them.
Make sure you have captured everything required from
the domain you are studying - that your diagram is
complete.

The University has several departments. Each department

is managed by a chair, and at least one professor.
Professors must be assigned to one, but possibly more
departments. At least one professor teaches each course,
but a professor may be on sabbatical and not teach any
course. Each course may be taught more than once by
different professors. We know of the department name, the
professor name, the professor employee id, the course
names, the course schedule, the term/year that the course is
taught, the departments the professor is assigned to, the
department that offers the course.

 Identify Classes
These are the abstract or physical things in our system
which we wish to describe.
Find all the nouns and noun phrases in the domain
descriptions you have obtained through your analysis.
Consider these class candidates.
The class candidates are departments, chair, professor,
course, and course section.
Since there is only one instance of the University, we
exclude it from our consideration.

 Find Associations
Now find the verbs that join the nouns. e.g., The
professor (noun) teaches (verb) students (noun).
The verb in this case, defines an association between
the two nouns.
Identify the type of association.
Use a matrix to define the associations between classes.

 Draw Rough Class Diagram

Put classes in rectangles and draw the associations
connecting the classes.

 Fill in Multiplicity
Determine the number of occurrences of one class for a
single occurrence of the associated class.

 Identify Attributes
Name the information
details (fields) which are
relevant
to
the
application domain for
each class. Add these
attributes.
We have the department name, the professor name,
the professor employee id, the course names, the
course schedule, the term/year that the course is
taught, the departments the professor is assigned to,
the department that offers the course.

 Identify Behaviors
Specify the operations that are
required for each class.
(assume getter and setter methods
for each attribute.)
In this example - we are not given
any behaviors, so we will have to
make them up.
What are some behaviors of these
classes?

Class Diagram - Example

Draw a class diagram for a information modeling

system for a school.

School has one or more Departments.

Department offers one or more Subjects.
A particular subject will be offered by only one department.
Department has instructors and instructors can work for
one or more departments.
Student can enrol in upto 5 subjects in a School.
Instructors can teach upto 3 subjects.
The same subject can be taught by different instructors.
Students can be enrolled in more than one school.

41

Class Diagram - Example

School has one or more Departments.

School

has

1..*

Department

Department offers one or more Subjects.

A particular subject will be offered by only one
department.

Department
1

offers

1..*

Subject
42

Class Diagram - Example

Department has Instructors and

instructors can work for one or more
departments.

Instructor
1..*

assigned to

1..*

Department

Student can enrol in upto 5 Subjects.

Student
*

takes

0..5

Subject
43

Class Diagram - Example

Instructors can teach up to 3 subjects.

The same subject can be taught by
different instructors.

Instructor

1..*
teaches

1..3

Subjects

44

Class Diagram - Example

Students can be enrolled in more than

one school.

Student

*
member

1..*

School

45

Class Diagram Example

has

School

Department

1..*

1..*

1*
offeres

assignedTo
member

Student

1..*

1..*

attends
*

Subject
1..5

teaches

Instructor

1..3 1..*
46

Example: Problem Report Tool

A CASE tool for storing and tracking

problem reports

Each report contains a problem description

and a status
Each problem can be assigned to someone
Problem reports are made on one of the
artifacts of a project
Employees are assigned to a project
A manager may add new artifacts and
assign problem reports to team members

Class Diagram for Prob. Rep.

Tool
0..*

Employee

1..*

Assigned To

Project

+name : string

Artifact

1
0..*

+name : string

+name : string
+status : enum

1
1
Responsible For
0..n
Manager

About

Developer

Problem Report

0..n

1
1

0..*
Managed By

History Log
0..n
History Entry
-when : Date
-whatDone : string

Code Bug Report

Lab Assignments

Class Diagram

Traffic Violation Report System

Traffic police is responsible to maintain and control the
traffic and need to submit whole day report.
TP can raise a complaint against Person who is violating
rules and can issue a violation report.
Identify the classes

Traffic Violation Report System Example

TrafficPoliceman 1 issues *

TrafficReport
id : long
description : String
occuredAt : Date
reports of
1..*

Policeman
id : long
name : String
rank : int
<<abstract>>

Violation
id : long
description : String

Offender
1..*

name : String
id : long

 The class diagram below models a customer order from a

retail catalog. The central class is the Order. Associated
with it are the Customer making the purchase and the
Payment. A Payment is one of three kinds: Cash, Check,
or Credit. The order contains OrderDetails (line items),
each with its associated Item.

 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.

 Association
a relationship between instances of the two classes. There is an
association between two classes if an instance of one class must
know about the other in order to perform its work.
In a diagram, an association is a link connecting two classes.

 Aggregation
an association in which one class belongs to a collection.
An aggregation has a diamond end pointing to the part containing the
whole.
In our diagram, Order has a collection of OrderDetails.

 Generalization
an inheritance link indicating one class is a superclass of the
other.
A generalization has a triangle pointing to the superclass.
Payment is a superclass of Cash, Check, and Credit.

 An association has two ends.

An end may have a role name to clarify the nature of the
association.
For example, an OrderDetail is a line item of each Order.

 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 no navigability arrows are bidirectional.

 The multiplicity of an association:

In our example, there can be only one Customer for each Order, but a
Customer can have any number of Orders.

Order Processing System

Customer wants some item so he will place an
order. A quotation of ordered items should be
generated by sales staff and same should be given
to customer. After placing order successfully
invoice copy should be given to the customer

ORDER
order no.
status
customer id
date
accept order()
edit order()
re order()

PRODUCT
product id
Order id
name
description
customer id
getCustomer()

CUSTOMER
customer id
Name
address
phone No.

QUOTATION
product id
quote no
price
date
Quantity

addCustomer()
save()
delete()
edit()

save()
delete()

SALES
STAFF
staff id
name
position
address
dept
addStaff()
delete()
save()

INVOICE
product id
invoice no
quantity
customer id
amount
vat
edit()
print()
save()
delete()
update ledger()

Class Diagram
Using
Java

Car.java

Representing Static variable or static operation

Unidirectional Association

Bidirectional Association

In the bidirectional association each of the class in this relationship refers to each other by calling each others method.
In the above Java example it is depicted as instance variable of Car class in called inside the Customer class and vice
versa.
In the above example the car and owner refers to the roles and is depicted by the name of instance variable in the
code.

Multiplicity in association

The above diagram explains a unidirectional association with a

one to may relationship.
Both use of ArrayList and Array is for illustration purposes only.

Multiplicity in association

Multiplicity in association

Generalization

Realization
This is related to the relationship
between the class and the interface.
The realization is equivalent to the
implements keyword in Java.
This is very straight forward
implementation so hopefully there
will ne no code provided.
Unlike Generalization in this case
the arrow is dashed.

Dependency

shows that a class is dependent on another class for its

existence or implementation.
Dependency relationship is shown as a dotted line with
an arrow from source class to the dependent class.

Dependency

In Java we can consider the dependency relationship

if the source class has a reference to the dependent
class directly or source class has methods through
which the dependent objects are passed as a
parameter or refers to the static operations of the
dependent class or source class has a local variable
referring to the dependent class etc.

 The above diagram satisfies dependency relationship as

the source class Order passes the PaymentSystem
reference through the processPayment().

Aggregation

This shows has a relationship. It is a form of association

relationship. This relationship highlights that a whole is made of its
parts.
So if a whole is destroyed the part still remains.
In UML this is represented through a hollow diamond with the
diamond symbol pointing towards the whole.
In case of Java the aggregation follows the same structure as
association. It is represented through the instance variables of a class.

Aggregation

In this case a student is a part of the School.

However during design it is preferred to use association instead of aggregation as it is not a
recommended option.

Composition
This is again a whole or part relationship where if the whole
is destroyed then the part cannot exist independently.
Another important point about Composition is that the part
at any point in time can have only one owner.
E.g. A person can be an employee of one company at any
point in time due to contractual obligations. That person
cannot hold dual work authorization. If the Company goes
bankrupt the employee of this company does not exist and
will be fired.

Composition
The composition is
represented as a filled
diamond
with
data
flowing
in
single
direction from the whole
to the part.
The composition in Java
is represented in the
same
form
as
aggregation with help of
instance variables.