Class Diagram

Introduction
• A class diagram describes the types of objects
in the system and the various kinds of static
relationships that exist among them.
• Class diagrams also show the properties and
operations of a class and the constraints that
apply to the way objects are connected.
• Feature that covers properties and operations
of a class.
 Classes

A class is a description of a set of

ClassName objects that share the same
attributes,
attributes operations, relationships, and
semantics.
operations
Graphically, a class is rendered as a
rectangle, usually including its name,
attributes, and operations in
separate,
designated compartments.
 Class Names

ClassName The name of the class is the

only required tag in the
attributes graphical representation of a
class. It always appears in the
operations top-most compartment.
 Class Attributes

An attribute is a named property

Person of a class that describes the
name : String object being modeled.
address : Address In the class diagram, attributes
birthdate : Date
ssn : Id
appear in the second
compartment just below the
name-compartment.
 Class Attributes (Cont’d)

Attributes are usually listed in the form:

Person attributeName : Type

name : String A derived attribute is one that can be

address : Address computed from other attributes, but
birthdate : Date doesn’t actually exist. For example,
/ age : Date a Person’s age can be computed from
ssn : Id his birth date. A derived attribute is
designated by a preceding ‘/’ as in:

/ age : Date
 Class Operations

Person

name : String
address : Address
birthdate : Date
ssn : Id
eat Operations describe the class behavior
sleep and appear in the third compartment.
work
play
 Class Operations (Cont’d)

PhoneBook

newEntry (n : Name, a : Address, p : PhoneNumber, d : Description)

getPhone ( n : Name, a : Address) : PhoneNumber

You can specify an operation by stating its

signature: listing the name, type, and default
value of all parameters, and, in the case of
functions, a return type.
Essential Elements of a UML Class Diagram
• Class
• Properties or Attributes
• Operations
• Relationships
– Associations
– Generalization
– Realization
– Dependency
• Constraint Rules and Notes
 When to Use Class Diagrams?
• Class diagrams are the backbone of the UML.
• The trouble with class diagrams is that they are so rich,
they can be overwhelming to use.
Tips
• Don't try to use all the notations available. Start with the
simple stuff like associations, attributes, generalization,
and constraints.
• Conceptual class diagrams very useful in exploring the
language of a business. For this keeping the notation very
simple.
• Don't draw models for everything; instead, concentrate on
the key areas.
• It is better to have a few diagrams that you use and keep
up to date than to have many forgotten, obsolete models.
 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 Class Name
Window
– "#" for protected size: Size
– "−" for private Attributes visibility: boolean

– “/" for derived display()

Operations hide()
– "~" for package
 Properties
• Properties represent structural features of a
class.
• Properties are a single concept, but they
appear in two quite distinct notations.
– Attributes
– Associations.
• Use Attributes for small things, such as dates or
Boolean type
• Use Associations for more significant classes,
such as customers and orders.
 Attributes
• The attribute notation describes a property as a line
of text within the class box itself.
• The full form of an attribute is:
visibility name: type multiplicity = default {property-string}
This visibility marker indicates whether the attribute is
public (+) or private (-);
The default - value for a newly created object if isn't
specified
The {property-string} allows you to indicate additional
properties for the attribute.
An example of this is: - name: String [1] = "Untitled" {readOnly}
 Associations
• An association is a solid line between two
classes, directed from the source class to the
target class.
• The name of the property goes at the target
end of the association, together with its
multiplicity.
• The target end of the association links to the
class that is the type of the property.
• Associations can show multiplicities at both
ends of the line compare to Attributes.
 Multiplicity
• The multiplicity of a property is an indication of how many objects may fill
the property.
– 1 (An order must have exactly one customer.)
– 0..1 (A corporate customer may or may not have a single sales rep.)
– * (A customer need not place an Order and there is no upper limit to
the number of Orders, a Customer may place—zero or more orders.)
• Multiplicities are defined with a lower bound and an upper bound, such as
2..4
• The lower bound may be any positive number or zero; the upper is any
positive number or * (for unlimited).
• If the lower and upper bounds are the same-use one number; hence, 1 is
equivalent to 1..1 &* is short for 0..*
• Default multiplicity of attribute is [1]. Although this is true in the meta-
model, explicitly state a [1] multiplicity if it's important.
 Terms refer to the multiplicity
– Optional implies a lower bound of 0.
– Mandatory implies a lower bound of 1 or possibly more.
– Single-valued implies an upper bound of 1.
– Multivalued implies an upper bound of more than 1:
usually *.
• Multivalued property, use a plural form for its
name.
• If the ordering of the orders in association has
meaning, add {ordered} to the association end.
• If allow duplicates, add {nonunique}. (If you want to
explicitly show the default, you can use {unordered}
and {unique}.)
 Bidirectional Associations
• A bidirectional association is a pair of properties
that are linked together as inverses.
• The Car class has property owner:Person[1],
and the Person class has a property cars:Car[*].
Note: cars property in the plural form of the
property's type, a common but non-normative
convention
 Operations
• Operations are the actions that a class knows to
carry out. It correspond to the methods on a class.
visibility name (parameter-list) : return-type {property-string}
• This visibility marker is public (+) or private (-);
• The name is a string.
• The parameter-list is the list of parameters for the
operation.
• The return-type is the type of the returned value, if
there is one.
• The property-string indicates property values that
apply to the given operation.
 Operations Cond..
• The parameters in the parameter list are notated in a
similar way to attributes.
• The form is:
direction name: type = default value
• The name, type, and default value are the same as for
attributes.
• The direction indicates whether the parameter is input
(in), output (out) or both (inout).
• If no direction is shown, it's assumed to be in.
• An example operation on account might be:
+ balanceOn (date: Date) : Money
 Query & Modifiers
• UML defines a query as an operation that gets a value
from a class without changing the system state. Mark
such an operation with the property string {query}.
• Operations that do change in system state called
modifiers, also called commands.
• Difference between query and modifiers is whether
they change the observable state.
• The observable state is what can be perceived from
the outside.
• Eg: An operation that updates a cache would alter the
internal state but would have no effect that's
observable from the outside.
 Getting and Setting methods
• A getting method returns a value from a field
(and does nothing else).
• A setting method puts a value into a field (and
does nothing else).
• From the outside, a client should not be able to
tell whether a query is a getting method or a
modifier is a setting method.
• Knowledge of getting and setting methods is
entirely internal to the class.
 Operation Vs Methods
• An operation is something that is invoked on
an object—the procedure declaration—
whereas a method is the body of a procedure.
• The two are different when you have
polymorphism.
• If you have a supertype with three subtypes,
each of which overrides the supertype's
operation, So you have one operation and four
methods that implement it.
 Notes and Comments
• Notes are comments in the diagrams. Notes
can stand on their own, or they can be linked
with a dashed line to the elements they are
commenting.
• They can appear in any kind of diagram.
 Dependency Relationships
•A dependency indicates a semantic relationship between two
or more elements. 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.
•The dependency from CourseSchedule to Course exists because
Course is used in both the add and remove operations of
CourseSchedule. CourseSchedule

Course
add(c : Course)
remove(c : Course)
 Generalization Relationships
Person A generalization connects a
subclass to its superclass.
It denotes an inheritance of
attributes and behavior
from the superclass to the
Student subclass and indicates a
specialization in the subclass
of the more general superclass.
An abstract Shape Super
class {abstract} Class

Generalization
relationship
Circle Sub Class
 Generalization Relationships (Cont’d)

UML permits a class to inherit from multiple superclasses,

although some programming languages (e.g., Java) do not
permit multiple inheritance.

Student Employee

TeachingAssistant
 Association Relationships

If two classes in a model need to communicate with

each other, there must be link between them. An
association denotes that link.

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.
Student Instructor
 Association Relationships (Cont’d)

We can indicate the multiplicity of an association by adding

multiplicity adornments to the line denoting the association.

The example indicates that a Student has one or more

Instructors:

Student Instructor
1..*
 Association Relationships (Cont’d)

The example indicates that every Instructor has one or

more Students:

Student Instructor
1..*
 Association Relationships (Cont’d)

We can also indicate the behavior of an object

in an association (i.e., the role of an object)
using rolenames.

teaches learns from

Student Instructor
1..* 1..*
 Association Relationships (Cont’d)

We can also name the association.

membership
Student Team
1..* 1..*
 Association Relationships (Cont’d)

We can specify dual associations.

member of

1..* 1..*
Student Team

1 president of 1..*
 Association Relationships (Cont’d)

We can constrain the association relationship by

defining the navigability of the association. Here, a
Router object requests services from a DNS object by
sending messages to (invoking the operations of) the
server. The direction of the association indicates that
the server has no knowledge of the Router.

Router DomainNameServer
 Association Relationships (Cont’d)

Associations can also be objects themselves, called link

classes or an association classes.
Registration

modelNumber
serialNumber
warrentyCode

Product Warranty
 Association Relationships (Cont’d)

A class can have a self association.

next

LinkedListNode
previous
 Associations (cont.)

Role
name
Association
name
instructor
StaffMember Student
1..* instructs *
Role
Navigable
Multiplicity (uni-directional)
association * pre -
requisites
Courses
0..3
Reflexive
association
 Association Relationships (Cont’d)

We can model objects that contain other objects by way of

special associations called aggregations and compositions.

An aggregation specifies a whole-part relationship between

an aggregate (a whole) and a constituent part, where the part
can exist independently from the aggregate. Aggregations are
denoted by a hollow-diamond adornment on the association.

2..* 1..*
Car Door House

Whole Part
 Association Relationships (Cont’d)

A composition indicates a strong ownership and

coincident lifetime of parts by the whole (i.e., they
live and die as a whole). Compositions are denoted
by a filled-diamond adornment on the association.

Scrollbar
1 1

Window Titlebar
1 1

Menu
1 1 .. *
 Interfaces

An interface is a named set of

operations that specifies the
<<interface>> behavior of objects without
ControlPanel showing their inner structure. It
can be rendered in the model by
a one- or two-compartment
rectangle, with the stereotype
<<interface>> above the
interface name.
 Interface Services

<<interface>> Interfaces do not get

ControlPanel instantiated. They have no
getChoices : Choice[]
attributes or state. Rather,
makeChoice (c : Choice) they specify the services
getSelection : Selection offered by a related class.
 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.

<<interface>>
LinkedList List ArrayList
 Interface Realization Relationship

<<interface>>
A realization relationship
ControlPanel connects a class with an
specifier
interface that supplies its
behavioral specification. It
is rendered by a dashed
line with a hollow
implementation
triangle towards the
VendingMachine
specifier.
 Interfaces

inputStream

FileWriter
{file must not be locked}

A class’ interface can

File also be rendered by a
circle connected to a
class by a solid line.

FileReader
{file must exist}
outputStream
 Parameterized Class

T A parameterized class or
LinkedList template defines a family of
potential elements.
To use it, the parameter must be
T bound.
1 .. *
A template is rendered by a small
dashed rectangle superimposed
on the upper-right corner of the
class rectangle. The dashed
rectangle contains a list of formal
parameters for the class.
 Parameterized Class (Cont’d)

T
LinkedList
Binding is done with the
<<bind>> stereotype and a
T parameter to supply to the
1..* template. These are
adornments to the dashed
arrow denoting the
<<bind>>(Name)
realization relationship.

DeansList Here we create a linked-list of

names for the Dean’s List.
 Enumeration

<<enumeration>> An enumeration is a user-

Boolean
defined data type that consists
false
true
of a name and an ordered list
of enumeration literals.
 Exceptions

Exceptions can be
<<exception>>
Exception modeled just like any
other class.
getMessage()
printStackTrace() Notice the
<<exception>>
stereotype in the name
compartment.
<<exception>> <<exception>>
KeyException SQLException
 Packages

A package is a container-like
element for organizing other
elements into groups.
Compiler A package can contain classes
and other packages and
diagrams.
Packages can be used to provide
controlled access between
classes in different packages.
 Packages (Cont’d)

Classes in the FrontEnd package and classes in the

BackEnd package cannot access each other in this
diagram.

Compiler

FrontEnd BackEnd
 Packages (Cont’d)

Classes in the BackEnd package now have access to

the classes in the FrontEnd package.

Compiler

FrontEnd BackEnd
 Packages (Cont’d)

We can model generalizations

Compiler
and dependencies between
packages.

JavaCompiler Java
 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 1 * may be
Order
{ total < $50 } canceled
id: long { value > 0 }

Constraint Note