ATM Management System Class Diagram

A class diagram is used to represent, explain, and document the parts (classes) of an ATM machine management system. It can also be a reference or way to create executable software code.

Class diagrams provide an overview of the system’s classes, functions, and relationships.

Project Overview

What is an ATM System?

The ATM system is specialized software that aids in managing a bank account or holder’s funds simply. Users can check account balances, make cash withdrawals or deposits, print a record of account activities or transactions, and even purchase stamps via the system.

Customers can utilize the system to conduct self-service transactions such as deposits, cash withdrawals, bill payments, and account transfers. The bank where the account is stored, the ATM operator, or both, frequently levy cash withdrawal fees

What is a Class Diagram?

A UML class diagram for ATM machine system is crucial and useful for system development. This is because the class diagrams are very effective in showing the system’s structure in detail, including the structures of each class. This works best with other ATM Management System UML Diagrams.

Additionally, the class diagram blueprints show how things in the system work and are related. It also offers the system’s activities and the services it provides. Therefore, a class diagram defines the physical components of a system and can directly relate to object-oriented languages.

ATM Management System Class Diagram

This simple class diagram gives you the exact details about the system’s class characteristics and methods. It also clarifies the connections of classes in the system.

Here, I will be showing you the sample constructed class diagram provided with its attributes and methods. This is from the simple idea of the ATM machine system’s common function.

The illustration shows a simple idea of how the class diagram works. It resembles a flowchart in which classes are present in boxes with three rectangles in each. The top rectangle has the class’s name; the middle holds the class’s properties, and the bottom contains the class’s methods.

The classes identified for ATM Management System were credit, withdrawal, bank member, ATM machine, transaction, loan, and savings. Their roles are in the middle part and called their attributes. The function of each class is in its’ methods.

You can edit this diagram and it is up to you how will you create your class diagram. However, you need to be precise with your information and consider the decisions included.

Downloadable Pdf File

Atm System Class Diagram in Java (2026 Code Example)

Below is a complete Java implementation following the Class Diagram structure. You can copy these classes directly into your capstone project as a starting point:

The Account class

public class Account {
    private String accountNumber;
    private String accountName;
    private String email;
    private String accountType;
    private double balance;
    private List<Transaction> transactions;

    public Account(String accountNumber, String accountName, String email,
                   String accountType, double balance) {
        this.accountNumber = accountNumber;
        this.accountName = accountName;
        this.email = email;
        this.accountType = accountType;
        this.balance = balance;
        this.transactions = new ArrayList<>();
    }

    public void addTransaction(Card card, double amount) {
        Transaction transaction = new Transaction(this, card, new Date(), amount);
        transactions.add(transaction);
    }

    public List<Transaction> getTransactions() {
        return transactions;
    }

    // Getters and setters
}

The Card class

public class Card {
    private String cardNumber;
    private String cardType;
    private Date expiryDate;
    private String status;
    private Account account;

    public Card(String cardNumber, String cardType,
                Date expiryDate, Account account) {
        this.cardNumber = cardNumber;
        this.cardType = cardType;
        this.expiryDate = expiryDate;
        this.account = account;
    }

    public void assignAccount(Account account) {
        this.account = account;
    }

    // Getters and setters
}

The Transaction class (association class)

public class Transaction {
    private Account account;
    private Card card;
    private Date transactionDate;
    private double amount;

    public Transaction(Account account, Card card,
                       Date transactionDate, double amount) {
        this.account = account;
        this.card = card;
        this.transactionDate = transactionDate;
        this.amount = amount;
    }

    public void recordAmount(double amount) {
        this.amount = amount;
    }

    // Getters and setters
}

This implementation directly mirrors the Class Diagram structure — the Account → Transaction ← Card relationship is a classic association class pattern used in real-world atm systems.

Atm System Class Diagram in PHP (2026 Code Example)

Here’s the same Class Diagram implemented in modern PHP 8.x. This pattern works well for Laravel and CodeIgniter capstones:

Account.php

<?php

class Account {
    private string $accountNumber;
    private string $name;
    private string $email;
    private string $accountType;
    private float $balance;
    private array $transactions = [];

    public function __construct(
        string $accountNumber,
        string $name,
        string $email,
        string $accountType,
        float $balance = 0.0
    ) {
        $this->accountNumber = $accountNumber;
        $this->name = $name;
        $this->email = $email;
        $this->accountType = $accountType;
        $this->balance = $balance;
    }

    public function transact(Card $card, float $amount): void {
        $this->transactions[] = new Transaction($this, $card, new DateTime(), $amount);
    }

    public function getTransactions(): array {
        return $this->transactions;
    }

    // Getters and setters
}

Card.php

<?php

class Card {
    private string $cardNumber;
    private string $cardType;
    private DateTime $expiryDate;
    private ?Account $account;

    public function __construct(
        string $cardNumber,
        string $cardType,
        DateTime $expiryDate,
        ?Account $account = null
    ) {
        $this->cardNumber = $cardNumber;
        $this->cardType = $cardType;
        $this->expiryDate = $expiryDate;
        $this->account = $account;
    }

    public function assignAccount(Account $account): void {
        $this->account = $account;
    }

    // Getters and setters
}

Transaction.php

<?php

class Transaction {
    private Account $account;
    private Card $card;
    private DateTime $transactionDate;
    private float $amount;

    public function __construct(Account $account, Card $card, DateTime $date, float $amount) {
        $this->account = $account;
        $this->card = $card;
        $this->transactionDate = $date;
        $this->amount = $amount;
    }

    public function recordAmount(float $amount): void {
        $this->amount = $amount;
    }

    // Getters and setters
}

For a Laravel implementation, these classes become Eloquent models with belongsTo() and hasMany() relationships. The Class Diagram’s multiplicity (1..* between Account and Transaction) maps directly to hasMany('App\Models\Transaction').

UML Class Diagram Symbols — Complete Reference Table

Use this reference table to read or draw any UML Class Diagram correctly. These symbols are standard across all UML modeling tools:

Quick rule: If you’re unsure between aggregation and composition, ask: “If I destroy the whole, does the part still exist?” Yes = aggregation. No = composition.

How to Draw the ATM System Class Diagram — Step by Step

Follow these 6 steps to draw this Class Diagram from scratch using draw.io (the recommended free tool for BSIT capstones):

Step 1 — Open draw.io and set up the canvas

Go to app.diagrams.net → create a blank diagram → in the left shape panel, search “UML” and enable the UML shape library. You’ll now see Class, Interface, and Enumeration shapes.

Step 2 — Draw the Account class

Drag a Class shape onto the canvas. The shape has 3 compartments by default. Set:

• Top compartment: Class name “Account”
• Middle compartment: Attributes — – accountNumber: String, – name: String, – email: String, – accountType: String, – balance: double
• Bottom compartment: Methods — + transact(card: Card, amount: double): void, + getTransactions(): List

The minus sign (-) indicates private; plus sign (+) indicates public.

Step 3 — Draw the Card and Bank classes

Repeat the process for Card (with attributes: cardNumber, cardType, expiryDate, status) and Bank (with attributes: bankId, bankName, branch, address).

Step 4 — Draw the Transaction association class

Create a Transaction class with attributes: – transactionDate: Date and – amount: double. This is a special “association class” — it represents data that exists only because two other classes are related.

Step 5 — Draw the relationships

From draw.io’s left panel, drag relationship lines between the classes:

• Account → Transaction — Solid line with hollow diamond on the Account side (aggregation, 1..*)
• Card → Transaction — Solid line with hollow diamond on the Card side (aggregation, 1..*)
• Card → Bank — Solid line (association, many-to-one)

Step 6 — Add multiplicity labels

Click each relationship line and add multiplicity at both ends: e.g., “1” near Account, “0..*” near Transaction. This tells the reader how many instances of each class participate in the relationship.

Export: File → Export As → PNG (for embedding in your capstone documentation) and PDF (for the printed manual). The PNG should be at least 1200px wide for readability in your defense slides.

💡 Pro tip: draw.io is completely free and our top pick. If you need more advanced features (auto-layout, version history, team collaboration), Lucidchart has a powerful UML tool with a free tier that’s sufficient for most capstone projects.

Common Mistakes Students Make with Class Diagrams

Avoid these mistakes that capstone defense panels frequently catch:

Mistake #1 — Confusing aggregation with composition

Don’t default to composition (filled diamond) for everything. Ask: “Does the contained class continue to exist if I delete the container?” If yes (like a Card that can still exist independently of a specific Transaction), use aggregation. Composition should only be used when the contained object cannot logically exist without the parent.

Mistake #2 — Missing multiplicity

Every relationship MUST have multiplicity labels at both ends. A line without multiplicity is incomplete and may result in deductions during the defense. For example:

• Account → Transaction: 1 to 0..*
• Card → Transaction: 1 to 0..*
• Bank → Card: 1 to 0..*

These labels clearly indicate how many objects participate in each relationship.

Mistake #3 — Mixing database fields with class attributes

Class attributes are PROGRAMMING-LEVEL representations. Use object references rather than foreign key IDs whenever possible. For example, write:

• account: Account

instead of:

• accountId: int

Similarly, use:

• bank: Bank

instead of:

• bankId: int

A Class Diagram should model object relationships, not database table structures.

Mistake #4 — Putting “Database,” “ATM Machine,” or “User Interface” as a class

Class Diagrams model the DOMAIN of the system — business concepts such as Account, Card, Transaction, and Bank. Infrastructure components such as Database, ATM Interface, API, or Server do not belong in a Class Diagram. Use a Component Diagram or Deployment Diagram to model those elements.

Mistake #5 — Empty method compartments

If a class has no methods, you’ve probably forgotten to model its behavior. Most ATM domain classes should contain meaningful operations. Examples include:

Account

• transact()
• getTransactions()

Card

• assignAccount()
• validateCard()

Transaction

• recordAmount()
• generateReceipt()

Defense panel question: “What does this class actually do?” Make sure each class has a clear responsibility.

Mistake #6 — Drawing in low resolution

Export Class Diagrams at a minimum width of 1200px when using PNG format. Blurry diagrams make attributes, methods, and multiplicities difficult to read and can negatively affect presentation quality. PDF export is recommended for documentation because it preserves diagram clarity regardless of zoom level.

Related UML Diagrams

• Sequence Diagram For ATM System UML
• DFD Diagram For ATM System
• ATM System UML Diagrams
• ATM System Use Case Diagram
• Component Diagram For ATM System
• Deployment Diagram For ATM System UML

Inquiries:

If you have inquiries or suggestions about the Class Diagram discussion, leave us your comments below. We would be glad to hear to concerns and be part of your learning.

Mary Grace G. Patulada

Programmer & Technical Writer at PIES IT Solution

Mary Grace G. Patulada (pen name ‘Nym’) is a programmer and writer at PIES IT Solution with a BSIT background from Carlos Hilado Memorial State College, Binalbagan Campus. Authored 370+ UML diagram tutorials and capstone documentation guides at itsourcecode.com. Specializes in UML (class, use case, activity, sequence, component, deployment), DFD, and ER diagrams for BSIT capstone projects.

Expertise: UML Diagrams · DFD · ER Diagrams · Use Case Diagrams · Activity Diagrams · Capstone Documentation · PHP  · View all posts by Mary Grace G. Patulada →