Epic: Evolve CPP ATM Simulator into a Robust Banking Terminal

[Aaqibhafeezkhan]

Epic Overview

Evolve the CPP ATM Simulator from its original single-user console demonstration into a more robust, maintainable, portable, and testable ATM application while preserving its educational focus on C++ and object-oriented design.

Goals

• Strengthen the ATM domain model and encapsulation.
• Improve authentication and sensitive-data handling.
• Support multiple accounts and persistent data.
• Make transactions safer and more realistic.
• Improve input validation and error handling.
• Reduce platform-specific dependencies where practical.
• Introduce automated tests for core banking behavior.
• Keep the project approachable as a C++ learning/reference project.

Phase Status

• Phase 1 — Authentication session hardening — Issue Phase 1: Harden authentication and login session handling #9 / PR feat: harden authentication session handling #10
• Phase 2 — Authentication security and PIN handling — Issue Phase 2: Improve authentication security and PIN handling #11 / PR feat: harden authentication and PIN handling #12
• Phase 3 — Multi-account support — Issue Phase 3: Add multi-account support #13 / PR feat: add multi-account support #14
• Phase 4 — Deposit and transfer operations — Issue Phase 4: Deposit and transfer operations #15 / PR feat: implement Phase 4 deposit and transfer operations #16
• Phase 5 — Transaction history — Issue Phase 5 — Transaction history #17 / PR feat: implement Phase 5 transaction history #18
• Phase 6 — Persistent account and transaction storage — Issue Phase 6 — Persistent account and transaction storage #19 / PR feat: Phase 6 persistent account and transaction storage #20
• Phase 7 — Input/transaction validation hardening — Issue Phase 7 — Harden input and transaction validation #21 / PR Phase 7 — Harden input and transaction validation #21
• Phase 8 — Automated business-logic tests — Issue Phase 8 — Automated business-logic tests #22 / PR test: add automated ATM business-logic coverage #23
• Phase 9 — Documentation refinement — Issue Phase 9 — Documentation refinement #24 / PR docs: refine atm simulator documentation #25

Planned Workstreams

1. Domain & Architecture

• Refactor the monolithic atm class into focused components where appropriate.
• Separate account data, authentication, transactions, and user interaction.
• Introduce clear interfaces between the presentation and business layers.

2. Authentication & Security

• Mask PIN input.
• Avoid exposing PINs through public getters.
• Add failed-login limits and session handling.
• Replace hardcoded credentials with safer account storage.

3. Account & Transaction Management

• Support multiple accounts.
• Add deposits and transfers.
• Add transaction history.
• Validate withdrawal amounts and ATM/account constraints.
• Prevent invalid or negative monetary operations.

4. Persistence

• Persist account and transaction data between sessions.
• Define a simple storage format before considering a database.
• Handle corrupted or missing data gracefully.

5. Portability

• Remove or isolate Windows-specific conio.h / _getch() usage.
• Support modern C++ compilers on Windows, Linux, and macOS where practical.

6. Testing & Quality

• Add unit tests for authentication, balance updates, withdrawals, deposits, and mobile-number changes.
• Cover invalid input and insufficient-funds scenarios.
• Add build instructions for the supported toolchains.

7. Documentation

• Keep the README aligned with the actual implementation.
• Document architecture, supported features, build/run instructions, and limitations.
• Add examples for representative ATM workflows.

Definition of Done

• Core ATM behavior is separated from console interaction.
• Sensitive authentication data is not unnecessarily exposed.
• Multiple accounts and persistent state are supported, or the remaining limitation is explicitly documented.
• Monetary operations have comprehensive validation.
• Core business logic has automated test coverage.
• The application builds using a documented modern C++ toolchain.
• README documentation accurately reflects the implementation.

Collaboration

This epic is assigned to aaqib-hafeez-khan-in and shruticparmar for shared ownership and implementation.

Workflow

Phase → Issue → implementation PR against main → request shruticparmar → self-review as a normal COMMENT → merge → update Epic.

Scope Principle

Implement these improvements incrementally. Each child issue should remain independently reviewable and should avoid unnecessary changes outside its stated scope.