Class diagram
• One of the most used UML diagrams.
• Provide a static view of a system.
• A UML class diagram is made up of:
- A set of classes and
- A set of relationships between classes
• Describes the structure of a system by showing the
system's classes, their attributes, methods, and the
relationships among objects.
2
Class diagram : example ATM BANK
3
Contents
• Part1: Introduction to Object Oriented
concepts
• Part 2: Class Diagram
4
Introduction to Object Oriented
concepts
5
Real world and software objects analogy (1/2)
• Real-world objects share two characteristics: state and behavior.
Examples
• Person
• state : has age, weight, height, eye color, name, etc.
• behavior : reading, writing, communicating, etc.
• Desktop radio
• state : on, off, current volume, current station.
• behavior : turn on, turn off, increase volume, decrease
volume, seek, scan, and tune.
6
Real world and software objects analogy (2/2)
• Software objects are similar to real-world objects:
they also consist of state and related behavior.
• An object stores its state in attributes (fields or variables in
some programming languages) and exposes its behavior
through methods (operations or functions in some
programming languages).
• Methods operate on an object's internal state (Attributes)
and serve as the primary mechanism
for object-to-object communication.
7
What Is an Object?
• An object
• is a software bundle of related state and behavior.
• is often used to model the real-world objects that you find
in everyday life.
Books
8
University
What Is a Class?
• A class
• A description of a group of objects with common properties
(attributes), behavior (operations), relationships, and
semantics.
• Models the state and behavior of a real-world object.
• An object is an instance of a class.
• Example:
• When I hire a new employee “Joan” (object), he is an
instantiation of the class “employee”.
9
What is a Class?
Example2
Example 1
Class
Objects
Objects are instances of a class
10
Class Diagram : core elements
11
Class
Description: a class has three parts
• name at the top
• attributes in the middle
• methods (or operations) at the bottom.
Syntax:
Class
Attributes
Methods
12
Class attributes
• An attribute is a named property of a class that describes the
object being modeled.
• Attributes are usually listed as attribute name : data type
• In the class diagram, attributes appear in the second
compartment just below the name-compartment.
Person
ssn
: number
name
: string
address : string
birthdate : date
13
Class Methods
• describe the class behavior
• appear in the third compartment of the class.
Person
ssn
: number
name : string
address : string
birthdate : date
getName() : string
setName(name) : void
Isbirthday() : boolean
14
Drawing Classes
•
When drawing a class, you don’t need to show attributes and methods in
every diagram.
Person
Person
ssn
: number
name : string
address : string
birthdate : date
Person
ssn
name
address
birthdate
Person
Person
getName() : string
setName(name) : void
Isbirthday() : boolean
getName() : string
setName(name) : void
Isbirthday() : boolean
15
Class Diagram relationships
16
Relationships: Association (1/2)
• When modeling a system, certain objects will be related to
each other
• These relationships need to be modeled for clarity using
association relationships
• There are several types of associations
17
Relationships: Association (2/2)
• If two classes in a model need to communicate with each
other, there must be link between them.
• An association denotes that link.
• Syntax
a solid line between the two classes
Student
Instructor
18
Relationships: Multiplicity (1/2)
Multiplicity
• is the active logical association where the cardinality of a
class in relation to another is being depicted.
Example:
one campany may include multiple persons,
while one person may work at one company .
19
Relationships: Multiplicity (2/2)
• Multiplicity
is
a
definition
of cardinality - i.e. number of
elements - of some collection of
elements
• It provides an inclusive interval of
non-negative integers to specify the
allowable number of instances of
described element
• Multiplicity interval has some lower
bound and (possibly infinite) upper
bound
Potential Multiplicity Values
Indicator
Meaning
0..1
Zero or one
1
One only
0..*
Zero or more
*
Zero or more
1..*
One or more
3
Three only
0..5
Zero to Five
5..15
Five to Fifteen
20
Relationships:
Multiplicity+association (1/2)
• We can indicate the multiplicity of an association by adding
multiplicity bounds to the line denoting the association.
1..*
Student
Instructor
a Student has one or more Instructors
Student
Instructor
1..*
every Instructor has one or more Students
• We can also indicate the behavior of an object in an association
(i.e., the role of an object) using role names.
teaches
Student
1..*
21
learns from
1..*
Instructor
Relationships:
Multiplicity+association (2/2)
• We can also name the association.
membership
Student
1..*
1..*
Team
• We can specify dual associations.
member of
1..*
1..*
Student
Team
1
president of
1..*
22
Relationships: Association class
• The association between two classes may have attributes and
operations in its own  represented by a class icon in the
same way as other entities: association class.
• An association class can have an association with another class,
Syntax
• The association class has its own icon, connected to the
association to which it belongs via a dashed line.
23
Relationships: Reflexive association
• Reflexive (self) association
• A class can be associated with itself
• Does not mean that a class's instance is related to itself,
• But means that an instance of the class is related to another
instance of the class.
• Example
An Employee class could be related to itself through the
manager/manages role.
24
Relationships: N-ary association
• n-ary association: It links more than two classes,
• Syntax
• a large diamond with a path starting at each participating
class. The name of the association, if any, appears near the
diamond.
25
Relationships: Aggregation
• Aggregation is used to model objects that contain other objects
• Specifies a whole-part relationship between an aggregate
(a whole) and a constituent part
• The part can exist independently from the aggregate.
Syntax
• Aggregations are denoted by a hollow-diamond adornment
on the association.
26
Relationships: Composition
• Composition (or composite aggregation)
• Indicates a strong ownership and coincident lifetime of parts
by the whole (i.e., they live and die as a whole).
Syntax
• a filled-diamond adornment on the association.
1
Window
1
1
1
1
1 .. *
Scrollbar
Titlebar
Menu
27
Relationships: Generalization (1/2)
• Generalization is
• the ability of one class (child class) to inherit the identical
functionality of another class (super class), and then add
new functionality of its own.
• also known as the inheritance or "is a" relationship.
Syntax
a solid line drawn from the child class with a closed, unfilled
arrowhead (or triangle) pointing to the super class.
28
Abstract class
• An Abstract class is a class that cannot have its own (direct)
instances.
• Abstract classes exist purely to generalize common behavior that
would otherwise be duplicated across (sub)classes.
• In UML, the name of an abstract class is written in an italic font
• Example
29
DataType
• Represent value types from business domain, primitive
types or structured types of a programming language.
• example: date/time, gender, currency, address.
• A data type is shown using rectangle symbol with
keyword «dataType».
• A data type may contain attributes and operations to support
the modeling of structured data types.
30
DataType : Example
Person
ssn
: number
name : string
address : Address
birthdate : date
getName() : string
setName(name) : void
Isbirthday() : boolean
31
Stereotype: Enumeration
An enumeration is a user-defined data type that consists of
a name and an ordered list of enumeration literals.
Example:
<<enumeration>>
Status
On
Off
<<enumeration>>
Color
Blue
Red
Green
Car
Color: Color
EngineStatus: Status
Status and Color are two enumeration
stereotypes used as types for the attributes
of the car
32
Class diagram rules
• The name of the class diagram should be meaningful to describe
the aspect of the system.
• Attributes and methods of each class should be clearly identified.
• For each class, a minimum number of properties should be
specified. Unnecessary properties will make the diagram
complicated.
• Use notes whenever required to describe some aspect of the
diagram. At the end of the drawing it should be understandable
to the developer/coder.
• Finally, before making the final version, the diagram should be
drawn on plain paper and reworked as many times as possible to
make it correct.
33