OOSE - CASE STDUY – UML Modeling Exercise

An experiment submitted for the partial fulfillment of the degree

of

Bachelor of Technology

in

Computer Science & Engineering

(Session 2023-2024)

Submitted by:

Ajit (01411507221)
Rahul Kumar Jha (35111507221)
Bhaskar Pal (35211507221)
Utkarsh Sharma (01311507221)
Satnam Singh (01211507221)

Department of Computer Science & Engineering

BHARATI VIDYAPEETH’S COLLEGE OF ENGINEERING
PASCHIM VIHAR, NEW DELHI
Problem Statement:

Design an Automated Teller Machine (ATM) system that allows bank customers to perform various
banking transactions, such as withdrawing cash, depositing funds, transferring money between
accounts, checking account balances, and updating account information. The system should ensure
security and privacy for all transactions while providing a user-friendly interface for customers.

Introduction

Now we begin the optional portion of our object-oriented design and implementation case study. In
this chapter and, you’ll design and implement an object-oriented automated teller machine (ATM)
software system. The case study provides you with a concise, carefully paced, complete design and
implementation experience. You’ll perform the steps of an object-oriented design (OOD) process
using the UML while relating them to the object-oriented concepts discussed in. In this chapter, you’ll
work with six popular types of UML diagrams to graphically represent the design, you’ll tune the
design with inheritance and polymorphism, then fully implement the ATM in an 850-line C++
application (Section 26.4). This is not an exercise; rather, it’s an end-to-end learning experience that
concludes with a detailed walkthrough of the complete C++ code that implements our design. It will
acquaint you with the kinds of substantial problems encountered in industry. These chapters can be
studied as a continuous unit after you’ve completed the introduction to object-oriented programming
in. Or, you can pace the sections after. Each section of the case study begins with a note telling you
the chapter after which it can be covered.

Introduction to Object-Oriented Analysis and Design

What if you were asked to create a software system to control thousands of automated teller machines
for a major bank? Or suppose you were asked to work on a team of 1000 software developers building
the next U.S. air traffic control system. For projects so large and complex, you cannot simply sit down
and start writing programs. To create the best solutions, you should follow a process for analyzing
your project’s requirements (i.e., determining what the system should do) and developing a design
that satisfies them (i.e., deciding how the system should do it). Ideally, you’d go through this process
and carefully review the design (or have your design reviewed by other software professionals) before
writing any code. If this process involves analyzing and designing your system from an object-
oriented point of view, it’s called an object-oriented analysis and design (OOAD) process. Analysis
and design can save many hours by helping you to avoid an ill-planned system-development approach
that has to be abandoned part of the way through its implementation, possibly wasting considerable
time, money and effort. Small problems do not require an exhaustive OOAD process. It may be
sufficient to write pseudocode before you begin writing C++ code. As problems and the groups of
people solving them increase in size, the methods of OOAD become more appropriate than
pseudocode. Ideally, members of a group should 25.1 Introduction 25.2 Introduction to Object-
Oriented Analysis and Design 25.3 Examining the ATM Requirements Document 25.4 Identifying the
Classes in the ATM Requirements Document 25.5 Identifying Class Attributes 25.6 Identifying
Objects’ States and Activities 25.7 Identifying Class Operations 25.8 Indicating Collaboration Among
Objects 25.9 Wrap-Up 25.3 Examining the ATM Requirements Document 25_3 agree on a strictly
defined process for solving their problem and a uniform way of communicating the results of that
process to one another. Although many different OOAD processes exist, a single graphical language
for communicating the results of any OOAD process has come into wide use. This language, known
as the Unified Modeling Language (UML), was developed in the mid-1990s under the initial direction
of three software methodologists—Grady Booch, James Rumbaugh and Ivar Jacobson.

Examining the ATM Requirements Document

Requirements Document A local bank intends to install a new automated teller machine (ATM) to
allow users (i.e., bank customers) to perform basic financial transactions (Fig. 25.1). Each user can
have only one account at the bank. ATM users should be able to view their account balance, withdraw
cash (i.e., take money out of an account) and deposit funds (i.e., place money into an account).

The user interface of the automated teller machine contains the following hardware
components:
• a screen that displays messages to the user
• a keypad that receives numeric input from the user
• a cash dispenser that dispenses cash to the user and
• a deposit slot that receives deposit envelopes from the user.
The cash dispenser begins each day loaded with 500 $20 bills. [Note: Owing to the limited
scope of this case study, certain elements of the ATM described here do not accurately mimic those of
a real ATM. For example, a real ATM typically contains a device that reads a user’s account number
from an ATM card, whereas this ATM asks the user to type an account number using the keypad. A
real ATM also usually prints a receipt at the end of a session, but all output from this ATM appears on
the screen.] The bank wants you to develop software to perform the financial transactions initiated by
bank customers through the ATM. The bank will integrate the software with the ATM’s hardware at a
later time. The software should encapsulate the functionality of the hardware devices (e.g., cash
dispenser, deposit slot) within software components, but it need not concern itself with how these
devices perform their duties. The ATM hardware has not been developed yet, so instead of writing
your software to run on the ATM, you should develop a first version of the software to run on a
personal computer. This version should use the computer’s monitor to simulate the ATM’s screen,
and the computer’s keyboard to simulate the ATM’s keypad. An ATM session consists of
authenticating a user (i.e., proving the user’s identity) based on an account number and personal
identification number (PIN), followed by creating and executing financial transactions. To
authenticate a user and perform transactions, the ATM must interact with the bank’s account
information database. [Note: A database is an organized collection of data stored on a computer.] For
each bank account, the database stores an account number, a PIN and a balance indicating the amount
of money in the account. [Note: For simplicity, we assume that the bank plans to build only one
ATM, so we do not need to worry about multiple ATMs accessing this database at the same time.
Furthermore, we assume that the bank does not make any changes to the information in the database
while a user is accessing the ATM. Also, any business system like an ATM faces reasonably
complicated security issues that go well beyond the scope of a first- or secondsemester computer
science course. We make the simplifying assumption, however, that the bank trusts the ATM to
access and manipulate the information in the database without significant security measures.] Upon
first approaching the ATM, the user should experience the following sequence of events (shown in
Fig. 25.1): 1. The screen displays a welcome message and prompts the user to enter an account
number. 2. The user enters a five-digit account number, using the keypad. 3. The screen prompts the
user to enter the PIN (personal identification number) associated with the specified account number.
4. The user enters a five-digit PIN, using the keypad. 5. If the user enters a valid account number and
the correct PIN for that account, the screen displays the main menu (Fig. 25.2). If the user enters an
invalid account number or an incorrect PIN, the screen displays an appropriate message, then the
ATM returns to Step 1 to restart the authentication process.
Class Diagram:

Sequence Diagram: