Class Diagram Object Oriented Programming

Pemrograman OOP | Agus Seputra
Class Diagram
Unified Modeling Language
(UML)

Class
diagrams
Jurusan Teknik Informatika
Universitas Pendidikan Ganesha

What are class
Diagrams?
• In these diagrams, classes are depicted as boxes, each
containing three compartments for the class name,
attributes, and methods. Lines connecting classes
illustrate associations, showing relationships such as
one-to-one or one-to-many.
• Class diagrams provide a high-level overview of a
system’s design, helping to communicate and
document the structure of the software.
• They are a fundamental tool in object-oriented design
and play a crucial role in the software development
lifecycle.
• In object-oriented programming (OOP), a class is a
blueprint or template for creating objects.

UML Class Notation
class notation is a graphical representation used to
depict classes and their relationships in object-
oriented modeling
• Class Name: The name of the class is typically
written in the top compartment of the class box
and is centered and bold.
• Attributes also known as properties or fields,
represent the data members of the class.
• Methods, also known as functions or operations,
represent the behavior or functionality of the class.

UML Class Notation
Packages or groups contain elements such as diagrams, classes,
documents, or other packages that are similar or related to each
other. It can be said, this package is the same as a folder.
Attributes and methods in class diagrams can have one of the
following properties. These properties indicate the visibility or
access ability of the class, and are described with symbols written
before the attribute or method:
• Private (-): Can only be viewed and accessed from within the
class, cannot be used or modified by outside the class.
• Public (+): Can be seen on the entire system, which means it can
be used by anyone who needs it.
• Protected (#): Can be seen from inside the class and sub class,
cannot be accessed from outside the class.
• Package (~): Classes that are members of the same group can
access each other's attributes or methods between classes.

Parameter Directionality
In class diagrams, parameter directionality refers to the indication of the flow of
information between classes through method parameters. It helps to specify whether
a parameter is an input, an output, or both. This information is crucial for
understanding how data is passed between objects during method calls.
There are three main parameter directionality notations used in class diagrams:
• In (Input):
• An input parameter is a parameter passed from the calling object (client)
to the called object (server) during a method invocation.
• It is represented by an arrow pointing towards the receiving class (the
class that owns the method).
• Out (Output):
• An output parameter is a parameter passed from the called object
(server) back to the calling object (client) after the method execution.
• It is represented by an arrow pointing away from the receiving class.
• InOut (Input and Output):
• An InOut parameter serves as both input and output. It carries
information from the calling object to the called object and vice versa.
• It is represented by an arrow pointing towards and away from the
receiving class.

Example of Class Diagram
• Class diagram can not only visualize the
structure of the developed software system,
but also for the system in a business.
• ATMs are deceptively simple: although
customers only need to press a few buttons
to receive cash, there are many layers of
security that a safe and effective ATM must
pass through to prevent fraud and provide
value for banking customers.
• The various human and inanimate parts of
an ATM system are illustrated by this easy-
to-read diagram—every class has its title,
and the attributes are listed beneath.
Class diagram for an ATM system

Relationships
between
classes
In class diagrams, relationships between classes describe
how classes are connected or interact with each other within
a system. There are several types of relationships in object-
oriented modeling, each serving a specific purpose.

Association
An association represents a bi-directional relationship
between two classes. It indicates that instances of one
class are connected to instances of another class.
Let’s consider a simple system for managing a library. In
this system, we have two main entities: Book and Library.
Each Library contains multiple Books, and each Book
belongs to a specific Library. This relationship between
Library and Book represents an association.
The “Library” class can be considered the source class
because it contains a reference to multiple instances of
the “Book” class. The “Book” class would be
considered the target class because it belongs to a
specific library.

Directed Association
A directed association in a UML class
diagram represents a relationship
between two classes where the
association has a direction, indicating
that one class is associated with another
in a specific way.
Directed associations are used when the
association has a specific flow or
directionality, such as indicating which
class is responsible for initiating the
association or which class has a
dependency on another.
Consider a scenario where a “Teacher” class is associated with a
“Course” class in a university system. The directed association arrow
may point from the “Teacher” class to the “Course” class, indicating
that a teacher is associated with or teaches a specific course.

Aggregation
Aggregation is a specialized form of
association that represents a “whole-
part” relationship. It denotes a stronger
relationship where one class (the whole)
contains or is composed of another class
(the part). Aggregation is represented by a
diamond shape on the side of the whole
class. In this kind of relationship, the
child class can exist independently of its
parent class. The company can be considered as the whole, while the employees are
the parts. Employees belong to the company, and the company can
have multiple employees. However, if the company ceases to exist, the
employees can still exist independently.

Composition
Composition is a stronger form of aggregation,
indicating a more significant ownership or
dependency relationship. In composition, the part
class cannot exist independently of the whole
class. Composition is represented by a filled
diamond shape on the side of the whole class.
Imagine a digital contact book application. The
contact book is the whole, and each contact
entry is a part. Each contact entry is fully
owned and managed by the contact book. If the
contact book is deleted or destroyed, all
associated contact entries are also removed.
This illustrates composition because the existence of the
contact entries depends entirely on the presence of the
contact book. Without the contact book, the individual
contact entries lose their meaning and cannot exist on their
own.

Generalization(Inheritance)
Inheritance represents an “is-a”
relationship between classes, where one
class (the subclass or child) inherits the
properties and behaviors of another class
(the superclass or parent). Inheritance is
depicted by a solid line with a closed,
hollow arrowhead pointing from the
subclass to the superclass.
In the example of bank accounts, we can
use generalization to represent different
types of accounts such as current
accounts, savings accounts, and credit
accounts.
The Bank Account class serves as the generalized representation of
all types of bank accounts, while the subclasses (Current Account,
Savings Account, Credit Account) represent specialized versions that
inherit and extend the functionality of the base class.

Realization
(Interface
Implementation)
Realization indicates that a class implements the features of an interface. It is
often used in cases where a class realizes the operations defined by an interface.
Realization is depicted by a dashed line with an open arrowhead pointing from the
implementing class to the interface.
Let’s consider the scenario where a “Person”
and a “Corporation” both realizing an“Owner”
interface.

Realization (Interface
Implementation)
Let’s consider the scenario where a “Person” and a “Corporation”
both realizing an “Owner” interface.
• Owner Interface: This interface now includes methods such
as “acquire(property)” and “dispose(property)” to represent
actions related to acquiring and disposing of property.
• Person Class (Realization): The Person class implements the
Owner interface, providing concrete implementations for the
“acquire(property)” and “dispose(property)” methods. For
instance, a person can acquire ownership of a house or
dispose of a car.
• Corporation Class (Realization): Similarly, the Corporation
class also implements the Owner interface, offering specific
implementations for the “acquire(property)” and
“dispose(property)” methods. For example, a corporation can
acquire ownership of real estate properties or dispose of
company vehicles.
Both the Person and Corporation classes realize the Owner
interface, meaning they provide concrete implementations for the
“acquire(property)” and “dispose(property)” methods defined in the
interface.

Dependency
Relationship
A dependency exists between two classes when one class
relies on another, but the relationship is notas strongas
association or inheritance. It represents a more loosely
coupled connection between classes. Dependencies are
often depicted as a dashed arrow.
Let’s consider a scenario where a Person depends on a
Book.
• Person Class: Representsan individual who reads a
book. The Person classdepends on the Book class to
accessand read the content.
• Book Class: Representsa book that containscontent to
be read by a person. The Book classis independent and
can exist without the Person class.
The Person class depends on the Book class because it requires
access to a book to read its content. However, the Book class does
not depend on the Person class; it can exist independently and does
not rely on the Person class for its functionality.

Usage(Dependency)
Relationship
A usage dependency relationship in a UML class diagram
indicates that one class (the client) utilizes or depends on
another class (the supplier) to perform certain tasks or access
certain functionality. The client class relies on the services
provided by the supplier class but does not own or create
instances of it.
• Usage dependencies represent a form of dependency
where one class depends on another class to fulfill a
specific need or requirement.
• The client class requires access to specific features or
services provided by the supplier class.
• In UML class diagrams, usage dependencies are typically
represented by a dashed arrowed line pointing from the
client class to the supplier class.
• The arrow indicates the direction of the dependency,
showing that the client class depends on the services
provided by the supplier class.

Usage(Dependency)
Relationship
Consider a scenario where a “Car” class depends on a
“FuelTank” class to manage fuel consumption.
• The “Car” class may need to access methods or
attributes of the “FuelTank” class to check the fuel level,
refill fuel, or monitor fuel consumption.
• In this case, the “Car” class has a usage dependency on
the “FuelTank” class because it utilizes its services to
perform certain tasks related to fuel management.

Purpose of Class Diagrams

Benefits of
Class
Diagrams
Modeling Class
Structure:
Class diagrams help in modeling the structure of asystemby representing classes and
their attributes, methods, and relationships.
This provides a clear and organized viewof the system’s architecture.
Understanding
Relationships:
Class diagrams depict relationships between classes, such as associations,
aggregations, compositions, inheritance, and dependencies.
This helps stakeholders, including developers, designers, and business analysts,
understand how different components of the system are connected.
Communication: Class diagrams serve as a communication tool among teammembers and stakeholders.
They provide a visual and standardized representation that can be easily understood by
both technical and non-technical audiences.
Blueprint for
Implementation:
They guide developers in writing code by illustrating the classes, their attributes,
methods, and therelationships between them.
This can help ensure consistency between the design and the actual implementation.
Code
Generation:
Some software developmenttools and frameworks support code generation fromclass
diagrams.
Developers can generatea significant portion of thecode from the visual representation,
reducing the chances of manual errors and saving developmenttime.
Identifying
Abstractions and
Encapsulation:
Class diagrams encouragethe identification of abstractions and theencapsulation of
data and behavior within classes.
This supports the principles of object-oriented design, such as modularityand
information hiding.

Example

Thanks
REFERENSI:
Class Diagram | Unified Modeling Language (UML)
https://www.geeksforgeeks.org
Bank AccountManagement https://www.w3resource.com

Class Diagram Object Oriented Programming

Recommended

More Related Content

Similar to Class Diagram Object Oriented Programming (20)

Recently uploaded (20)

Class Diagram Object Oriented Programming