AUTOMATIC TELLER MACHINE

Name of the project: ATM

Project Statement: The given project is to model automatic teller machine in which a customer uses his/her ATM card to draw money from
ATM.

Funtional Requirements: The ATM machine provides facilities like withdraw amount,check balance ,change password,mini-statement and
transfer of amount etc to customers.

Problem Statement-
To develop an ATM System for Bank

The system developed should contain the following features:

1. The Customer has to login into the system using Credit Card or Debit Card number and Pin Number. The system should check for validation.
2. The System queries the customer for the type of account either Savings Account or Current Account. After getting the type of account, the
system shows the amount left.
3. The System then queries the customer for the required amount. The user enters the amount and gets the money.

a) Develop High level Sequence diagrams for each use case

High Level Sequence Diagram for ATM:
Sequence diagrams Typically show the flow of Functionality through a use case and consists of the following Components:
i)ACTORS: involved in the functionality on ATM, are Customers
ii)OBJECTS: that a system needs to provide the functionality in ATM are ATM,Bank/DataBase,Withdrawal,Check Balance etc.,
iii) Messages: which represents Communication between objects
 Insert card( )
 Request PIN( )
 Pin Entered( )
 Verify Pin( )
 Pin Accepted( )
  Request Option( )
 Options Selected( ) etc.,

(Draw sequence diagram on left side )

b)Identify MVC classes/objects for each use case

Model‐View‐Controller (MVC)

 Isolates business or domain logic from the input and presentation

 Model: data underlying the application

o Changes in state require notifying the view

o Model abstracts the data storage (DB, POJOs, etc.)

 View: UI

 A model may have many views

 Controller: receives input and initiates response by calling model

MVC in Web Apps

 View: HTML or XHTML

 Controller: GET or POST input

Gives the GET or POST information to the objects

 Model: underlying domain logic

(Draw mvc Class diagrams from observation on left side)

c) Develop Detailed Sequence Diagrams/ Communication Diagrams for each use case
showing interactions among all three-layer objects
d)Develop detailed design class model (use GRASP patterns for responsibility)
GRASP
● stands for General Responsibility Assignment Software Patterns

● guides in assigning responsibilities to collaborating objects.

● 9 GRASP patterns

Creator Information
Expert Low Coupling
Controller
High Cohesion Indirection
Polymorphism Protected
Variations Pure Fabrication

Responsibility:
● Responsibility can be:

– accomplished by a single object.

– or a group of object collaboratively accomplish a responsibility.

● GRASP helps us in deciding which responsibility should be assigned to which object/class.
● Identify the objects and responsibilities from the problem domain, and also identify how objects interact with
each other.
● Define blue print for those objects – i.e. class with methods implementing those responsibilities.
 Creator
● Who creates an Object? Or who should create a new instance of some class?

● “Container” object creates “contained” objects.

● Decide who can be creator based on the objects association and their interaction.
Example for creator:

Expert
● Given an object o, which responsibilities can be assigned to o?

● Expert principle says – assign those responsibilities to o for which o has the information to fulfill
that responsibility.

● They have all the information needed to perform operations, or in some cases they collaborate with others
to fulfill their responsibilities.

Example for Expert

 Low Coupling
● How strongly the objects are connected to each other?

● Coupling – object depending on other object.

● When depended upon element changes, it affects the dependant also.

● Low Coupling – How can we reduce the impact of change in depended upon elements on dependant
elements.

● Prefer low coupling – assign responsibilities so that coupling remain low.

● Minimizes the dependency hence making system maintainable, efficient and code reusable

● Two elements are coupled, if

– One element has aggregation/composition association with another element.

– One element implements/extends other element.

Example for poor coupling:

Example for low coupling:
 Controller
● Deals with how to delegate the request from the UI layer objects to domain layer objects.

● when a request comes from UI layer object, Controller pattern helps us in determining what is that first object that
receive the message from the UI layer objects.

● This object is called controller object which receives request from UI layer object and then controls/coordinates
with other object of the domain layer to fulfill the request.

● It delegates the work to other class and coordinates the overall activity.

● We can make an object as Controller, if

– Object represents the overall system (facade controller)

– Object represent a use case, handling a sequence of operations (session controller).

● Benefits

– can reuse this controller class.

– Can use to maintain the state of the use case.

– Can control the sequence of the activities

Example for Controller:

 Bloated Controllers
● Controller class is called bloated, if

– The class is overloaded with too many responsibilities.

Solution – Add more controllers

– Controller class also performing many tasks instead of delegating to other class.
Solution – controller class has to delegate things to others.

High Cohesion
● How are the operations of any element are functionally related?

● Related responsibilities in to one manageable unit.

● Prefer high cohesion

● Clearly defines the purpose of the element

● Benefits
– Easily understandable and maintainable.

– Code reuse

– Low coupling
Example for low cohesion:
Example for High Cohesion:
 Polymorphism
● How to handle related but varying elements based on element type?

● Polymorphism guides us in deciding which object is responsible for handling those varying elements.

● Benefits: handling new variations will become easy.

Example for Polymorphism:

Pure Fabrication
● Fabricated class/ artificial class – assign set of related responsibilities that doesn't represent any domain object.

● Provides a highly cohesive set of activities.

● Behavioral decomposed – implements some algorithm.

● Examples: Adapter, Strategy

Benefits: High cohesion, low coupling and can reuse this class
 Indirection
● How can we avoid a direct coupling between two or more elements.

● Indirection introduces an intermediate unit to communicate between the other units, so that the other units are not
directly coupled.

● Benefits: low coupling

● Example: Adapter, Facade, Obserever

Example for Indirection:

● Here polymorphism illustrates indirection

Protected Variation
● How to avoid impact of variations of some elements on the other elements.

● It provides a well defined interface so that the there will be no affect on other units.

● Provides flexibility and protection from variations.

● Provides more structured design.

● Example: polymorphism, data encapsulation, interfaces

e)Develop three-layer package diagrams for each case study

Three Layer Package Diagram for ATM System

The package diagram shows how the various classes are grouped into packages. There are two "top-level" classes - ATMMain and ATMApplet -
which allow the system to be run (respectively) as an application or as an Applet. (Only one of the two would be instantiated in any particular use
of the system.)

Each of these classes, in turn, depends on the package atm which contains the class ATM that represents the system as a whole, and the class
Session that represents one session. ATM depends on Session, and vice versa - since the ATM creates Sessions, and each Session, in turn, uses
the ATM to interact with the customer.

The subpackage transaction contains the classes used to represent individual transactions that a customer initiates. The class Session depends on
the transaction package because it creates individual transaction objects. These, in turn, again depend on the ATM to interact with the customer.

The subpackage physical contains the classes that represent the various physical components of the ATM. For the purposes of this simulation,
these are simulated by a GUI. A real ATM would have quite different classes in this package - classes that actually control its physical
components. The class ATM makes use of these components, and Session and the various kinds of transaction gain access to them through ATM
to actually perform the needed operations.

Finally, the package banking contains classes that represent the banking enterprise itself and the information communicated back and forth
between the ATM and the bank - i.e. classes which might be the same in a totally different implementation of an ATM that interacts with the
same bank.

This is, of course, a simulation. However, most of the code that is specific to the simulation resides in the package physical, plus the two top-
level classes. Presumably, the other classes and packages might be similar in a real system.
THREE LAYER PACKAGE DIAGRAM FOR Online Banking System:

login fund transfer recharge pay bills

customer clerk manager

recharge TPA biller TPA

fund transfer
TPA