Atm Sym Ot Assnmt

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 9

Object Technology

Assignment

“ATM System”

By,
Kiran kumar (09co38)
Vinayak.T.K (09co101)
Requirements Statement for Example ATM System

The ATM will service one customer at a time. A customer will be required to insert an ATM
card and enter a personal identification number (PIN) - both of which will be sent to the bank for
validation as part of each transaction. The customer will then be able to perform one or more
transactions. The card will be retained in the machine until the customer indicates that he/she
desires no further transactions, at which point it will be returned - except as noted below.

The ATM must be able to provide the following services to the customer:

1. A customer must be able to make a cash withdrawal from any suitable account linked to
the card, in multiples of $20.00. Approval must be obtained from the bank before cash is
dispensed.
2. A customer must be able to make a deposit to any account linked to the card, consisting
of cash and/or checks in an envelope. The customer will enter the amount of the deposit
into the ATM, subject to manual verification when the envelope is removed from the
machine by an operator. Approval must be obtained from the bank before physically
accepting the envelope.
3. A customer must be able to make a transfer of money between any two accounts linked to
the card.
4. A customer must be able to make a balance inquiry of any account linked to the card.

A customer must be able to abort a transaction in progress by pressing the Cancel key instead of
responding to a request from the machine.

The ATM will communicate each transaction to the bank and obtain verification that it was
allowed by the bank. Ordinarily, a transaction will be considered complete by the bank once it
has been approved. In the case of a deposit, a second message will be sent to the bank indicating
that the customer has deposited the envelope. (If the customer fails to deposit the envelope
within the timeout period, or presses cancel instead, no second message will be sent to the bank
and the deposit will not be credited to the customer.)

If the bank determines that the customer's PIN is invalid, the customer will be required to re-
enter the PIN before a transaction can proceed. If the customer is unable to successfully enter the
PIN after three tries, the card will be permanently retained by the machine, and the customer will
have to contact the bank to get it back.
If a transaction fails for any reason other than an invalid PIN, the ATM will display an
explanation of the problem, and will then ask the customer whether he/she wants to do another
transaction.

The ATM will provide the customer with a printed receipt for each successful transaction,
showing the date, time, machine location, type of transaction, account(s), amount, and ending
and available balance(s) of the affected account ("to" account for transfers).

The ATM will have a key-operated switch that will allow an operator to start and stop the
servicing of customers. After turning the switch to the "on" position, the operator will be
required to verify and enter the total cash on hand. The machine can only be turned off when it is
not servicing a customer. When the switch is moved to the "off" position, the machine will shut
down, so that the operator may remove deposit envelopes and reload the machine with cash,
blank receipts, etc.

The ATM will also maintain an internal log of transactions to facilitate resolving ambiguities
arising from a hardware failure in the middle of a transaction. Entries will be made in the log
when the ATM is started up and shut down, for each message sent to the Bank (along with the
response back, if one is expected), for the dispensing of cash, and for the receiving of an
envelope. Log entries may contain card numbers and dollar amounts, but for security will never
contain a PIN.
Class Diagram for Example ATM System
Shown below is the class diagram for the ATM system. The basic structure of the class diagram
arises from the responsibilities and relationships discovered when doing the CRC cards and
Interaction Diagrams. (If a class uses another class as a collaborator, or sends a message to an
object of that class during an Interaction, then there must either be an association linking objects
of those classes, or linking the "sending" class to an object which provides access to an object of
the "receiving" class.)

In the case of the ATM system, one of the responsibilities of the ATM is to provide access to its
component parts for Session and Transaction objects; thus, Session and Transaction have
associations to ATM, which in turn has associations to the classes representing the individual
component parts. (Explicit "uses" links between Session and Transaction, on the one hand, and
the component parts of the ATM, on the other hand, have been omitted from the diagram to
avoid making it excessively cluttered.)

The need for the various classes in the diagram was discovered at various points in the design
process.

 Some classes were discovered when doing analysis 


 Some classes were discovered when doing CRC cards
 
o Message - used to represent a message to the bank.
o Receipt - used to encapsulate information to be printed on a receipt.
o Status - used to represent return value from message to the bank.
o Balances - used to record balance information returned by the bank.

 Some classes were discovered when doing detailed design or writing code
 
o Money - used to represent money amounts, in numerous places.
o Account Information - contains names of various types of accounts customer can choose
from
Class diagram
ATM Simulation Session State Diagram
A state diagram is an analysis tool that can be used when a system (or component of a system) passes
through a series of discrete states during operation. Trivially, the ATM itself goes back and forth
between two states - RUNNING and STOPPED. More interesting, though, is the series of states an
individual Session goes through as it gets the customer's PIN and repeatedly gets transaction choices
and performs them. A state diagram for a Session is given below. It would also be possible (and perhaps
desirable) to construct similar diagrams for transactions.
Sequence diagram
UML defines two types of Interaction Diagram: the Sequence Diagram and the Collaboration Diagram. In
order to illustrate both types, the major use cases are documented using Sequence Diagrams, and the
specific sub cases of transaction (withdrawal, etc.) and the Invalid PIN Extension are documented using
Collaboration Diagrams. (The major reason for using two different types of diagram is pedagogical

You might also like