ATM SIMULATOR PROJECT

weaverchurchSoftware and s/w Development

Aug 15, 2012 (5 years and 3 months ago)

665 views



Redtea

2009

ATM SIMULATOR
PROJECT

This is the report that is produced by “Redtea Team” in which reflects our work
from analysis step to shippable product step. Also, in this document, the reader
can easily see all the design patterns that had been applied to thi
s project along
with its descriptions.

RMIT International University Vietnam


Redtea

Page
2

CONFIDENTIAL
3/15/2013



ISYS2
102

Assessment A
0
2


Ad
vanced Technology Holdings, Inc

ATM Simulator and Server


Submission

Document

REDTEA


Phuc, Tran Huu

(s3160751
)

Trieu, Truong Hong

(
s3183180
)

Cuong, Le Duy


(
s3183412
)



Date:

September

2
nd

2009


Redtea

Page
3

CONFIDENTIAL
3/15/2013


1.

Requirements and Business Flow

................................
................................
................................
................................
...........................

4

1.1.

Requirements

................................
................................
................................
................................
................................
...................

5

1.1.1.

Functional Redtea

................................
................................
................................
................................
................................
.....

6

1.1.2.

Non
-
Functional Redtea

................................
................................
................................
................................
.............................

7

1.1.3.

Diagram

................................
................................
................................
................................
................................
.....................

8

2.

Design

................................
................................
................................
................................
................................
................................
....

11

2.1.

Class Diagrams (Individual)

................................
................................
................................
................................
............................

11

2.1.1.

Class Diagram by Team Member

................................
................................
................................
................................
............

11

2.
1.2.

Class Diagrams (Team)

................................
................................
................................
................................
............................

15

3.

Management and Project Planning

................................
................................
................................
................................
......................

27

3.1.

Management Approach

................................
................................
................................
................................
................................
.

27

3.2.

Sprint Retrospective Meeting

................................
................................
................................
................................
........................

27

3.3.

Product Backlog

................................
................................
................................
................................
................................
.............

28

3.4.

Sprint Backlog
................................
................................
................................
................................
................................
.................

30

3.5.

Sprint Review Meeting

................................
................................
................................
................................
................................
...

31

3.5.1.

Sprint Review Meeting (Sprint 1)

................................
................................
................................
................................
............

31

3.5
.2.

Sprint Review Meeting (Sprint 2)

................................
................................
................................
................................
............

32

4.

Attachment 1

................................
................................
................................
................................
................................
........................

32

Redtea

Page
4

CONFIDENTIAL
3/15/2013


1.

Requirements and Business Flow

We have to implement both “ATM client” and “server”
and simulate the basic transaction
s of the “Automated teller machine”
.


-

NetBeans IDE 6.5.1 will be the development environment and using scrum to manage the project.


-

“ATM simulator and server” project will be divide into two phases. First phase will conce
ntrate on develop the back
-
end
server, the centralization of all of the transactions. Second phase will be developed the front
-
end ATM. In addition, we have
to simulate both the interface and hardware of an ATM.


-

Bank account can contain any kind of curren
cy such as USD, VND, AUD, and so on. However, once it was created, it has to
have maintained that currency for the life time of that account and each of bank account can only be opened by one
customer and each of the bank account has different behavior. Fo
r example, saving account would behave differently to
money market account.


-

“ATM card” is used to access to a bank account through ATM. ATM card can be linked to more than one account, however,
that ATM card will have a default account and the default acc
ount will be browse at the beginning. An ATM card is a
combination of 16 digits ID and 3 special digits as PIN. One account can have more than 1 ATM card with the same 16 digits
ID; however, the 3 special digits must be different.


-


To use ATM, customer p
lace their card into card reader and the customer only need to input the PIN number. The session is
started when customer place their cart into card reader and finish when customer press reject button on ATM to get the
ATM card back.


-

ATM Client should be
able to support both console and graphical interface. In order work, the project should have the
reusability, follow the OO principal and keep in mind: “close for modification but open for extension”.


-

Some of the basic required transaction:

Redtea

Page
5

CONFIDENTIAL
3/15/2013


o

Transfer mone
y

o

Deposit money

o

Withdraw money

o

Exchange money

o

Check account balance

-

The deadline of the project will be 02/09/2009; this project started from 22/06/2009 and was given by Mr. Eric.


1.1.

Requirements

-

Deposit Money



A customer can deposit money t
o a specific account. If the customer owns multiple accounts, the customer
is able to choose which account to deposit to. You need to be able to simulate the process of a deposit. That includes any
hardware that may be used to accept a deposit. Note: depos
its are usually placed in a standard envelope which is given to
the machine.


-

Withdraw Cash



A customer can withdraw cash from an account. An exchange is required if the currency withdrawn isn’t
the same as the account being withdrawn from. If the custome
r has multiple accounts, the customer is able to choose which
account to withdraw from. Remember to consider the hardware aspects of the ABT. Think about what happens in the ATM
machine when it doesn’t have enough money. What happens if the hardware breaks
? Can they withdraw any kind of
currency denomination?


-

Check Balance



Get the balance of an account. The user can also get a balance of all accounts linked to the card


-

Support Multiple Linked Accounts



An ATM card, as mentioned above, can be linked to
multiple accounts.


-

Currency



An account can have difference currency but once created must maintain that type of currency.


-

Notification



After a transaction, if an account has reached a pre
-
determined level, a notification is automatically sent to the
account holders email address.

Redtea

Page
6

CONFIDENTIAL
3/15/2013


-

Balance Notification



After a transaction, if an account has reached a pre
-
determined level, a notification is automatically
sent to the account holders email address.


-

Stat Session


To start using an ATM, the customer ins
erts their card. They only need to enter a Personal Identification
Number (PIN) for verification.


-

Finish Session



When the customer is finished using the ATM, they can choose to finish their session. The ATM will return
their card.


-

ATM User
-
Interfaces



We have two types of ATMs. One type of ATM is GUI based and the other type is text based. We need
to easily support both of them and still re
-
use source code specific to the ATM process.


-

Communication



We need to easily communicate with our server; howe
ver, we want this complete hidden from the objects
you create. For example, when a user enters their PIN, we can simply code “Pin.Validate”. However, that command is really
being executed on the server in some mystical way.


-

Server:

o

Reporting Requirements

-

We have strict reporting requirements.

As such, in the case of a user error or computer
error, we need to be able to hand
le these situations dynamically.


o

Redo/Undo and Logging



Every time a user takes an action within the ATM it has to be logged and ti
me stamped
within the central system. If someone, for example, enters their pin incorrectly, that will be logged. If they withdraw
money, it will be logged, etc. There is a great pattern for this.

1.1.1.

Functional

Redtea

-

Transfer money from one a
ccount to another

-

Deposit money into specific account

-

Withdraw money from an account

Redtea

Page
7

CONFIDENTIAL
3/15/2013

-

Exchange money as an extra step to deal with foreign currency.

-

Check account balance

1.1.2.

Non
-
Functional

Redtea

-

Graphic user interface friendly

-

Database system
management


Redtea

Page
8

CONFIDENTIAL
3/15/2013

1.1.3.

Diagram



ATM Client state diagram

Redtea

Page
9

CONFIDENTIAL
3/15/2013


Redtea

Page
10

CONFIDENTIAL
3/15/2013


Database relationship diagram

Redtea

Page
11

CONFIDENTIAL
3/15/2013

2.

Design

2.1.

Class Diagram
s (Individual)

2.1.1.

Class Diagram by Team Member


ATM Client class design (Draft only
, by Trieu
)


Redtea

Page
12

CONFIDENTIAL
3/15/2013


ATM Server class design (
Draft o
nly
, by Cuong
)


Redtea

Page
13

CONFIDENTIAL
3/15/2013

Account
-balance: double
RegularCheckingAccount
-earnInterest = false: boolean
-writeChecks = true: boolean
-withdrawalLimitations = false: boolean
-payFees = true: boolean
InterestCheckingAccount
-earnInterest = true: boolean
-writeChecks = true: boolean
-withdrawalLimitations = false: boolean
-payFees = true: boolean
MoneyMarketAccount
-earnInterest = true: boolean
-writeChecks = true: boolean
-withdrawalLimitations = true: boolean
-payFees = true: boolean
-amountOfChecks = 3: Integer
-amountOfWithdrawals = 6: Integer
SavingAccount
-earnInterest = true: boolean
-writeChecks = false: boolean
-withdrawalLimitations = true: boolean
-payFees = true: boolean
-amountOfWithdrawals = 6: Integer
CertificateDepositAccount
-earnInterest = true: boolean
-writeChecks = false: boolean
-withdrawalLimitations = false: boolean
-payFees = false: boolean
-rolloverDate: Date
Extra
PayFees
-amount = ?: double
-account: Account
-payFees: ITransactionBehavior
Interest
-amount = ?: double
-account: Account
-earnInterest: ITransactionBehavior

Bank account type (Draft only, by Phuc)


Redtea

Page
14

CONFIDENTIAL
3/15/2013

ITransactionBehavior
+process(amount: double): abstract void
EarnInterest
+isEarnInterest(): boolean
+getInterestAmount(): double
+process(amount: double): void
WriteCheck
+canWriteCheck(): boolean
+process(amount: double): void
Withdrawal
+canWithdrawal(): boolean
+process(amount: double): void
PayFee
+havetoPayFee(): boolean
+process(amount: double): void
ATMCard
+isCanUseCard(): boolean
+process(amount: double): void
Transfer
+isCanTransfer(): boolean
+process(amount: double): void

Account
behavior (
Draft only, by Phuc)

Redtea

Page
15

CONFIDENTIAL
3/15/2013

2.1.2.

Class Diagram
s (Team)


Adapter Pattern:



Adapter pattern has been used in this project because it hel
p
s

us achieve some goals
, but the most two important things are
:


-

Split the whole project into smaller project without dependencies in each other. For example, the client and server
communicate with each other through proxy object, a person who develop cli
ent can introduce new function with number of
parameters and leave a description
how that method will be used, the purpose of each parameter and the expected result
from that method on the “IATMServer”, after that, that programmer can move on and suppose t
hat the method working
already. Then when the person who develops the actual server come to that point, that developer will finish the rest to
produce the expected result. In this scenario, the person who develop client does not care what happen at the ser
ver side
and vice versa. Thus, the work will twice faster than normal because we do not spend time to wait for one to another to
finish the job in order to move on.

-

With this pattern, our server can easily support other ATM client from other companies with
out modify a single line of code
from either our server or their client. All they have to do is produce an adapter class to convert their current data into ou
rs.


Redtea

Page
16

CONFIDENTIAL
3/15/2013









Redtea

Page
17

CONFIDENTIAL
3/15/2013

Command Pattern:




This pattern will helps us encapsulate each of transaction into
a single object. Thus whenever we want to modify an object to
adapt to new type of transaction, we only modify that single object, and it will not affect other class in the system. Also,
if we
want to introduce new kind of action, we just have to create ne
w command object to act as the new type of action. In addition,
this pattern support the undo function, thus, we can use it to undo an action that might have error on the system.


Redtea

Page
18

CONFIDENTIAL
3/15/2013













Redtea

Page
19

CONFIDENTIAL
3/15/2013

Decorator Pattern:




All the account will have the same basic
attribute such as current balance, currency, and account type and so on. However, each
type of account will behave differently, and each of account from each bank will be different as well. In order to implement
those different, we would have implement a t
housand of thousand of class of account type. However, with this pattern, we only
need to create
the new wrapper type of new bank account, then encapsulate new behavior of that bank account as a single
object (strategy pattern would be the best choice here
) then put it inside the wrapper class and the problem will be solve.


Redtea

Page
20

CONFIDENTIAL
3/15/2013

Abstract Factory Method Pattern:




This pattern will help us control the creating new instance object of a class because if we use the “new” key work all over t
he place,
it is not a g
ood practice.

Redtea

Page
21

CONFIDENTIAL
3/15/2013

MVC Pattern:



For this pattern from the book, it actually is
a

MVC Compound pattern
. A set of different patterns applied.

By separating the roles into three parts, the View of the program is using the
Composite pattern
, because it has a lo
t of buttons
and panels to display.

Redtea

Page
22

CONFIDENTIAL
3/15/2013

The Controller class is using
Strategy pattern

to interact between the View and Model. When there is an event from the View,
the controller will take process to the Model and notify the View to change. It implements th
e IController interface, and uses
these methods to control actions from View to Model.

Model class is the ATMClient, used to connect to the server and handle all logic executions.

However, the Observer pattern was not applied to this client, because in AT
M systems, we only have a unique card to put in at a
time. We do not have different screens for an account to see changes by the Obser
v
ab
l
e interface.

The second reason is that we do not need to accomplish the ATM System Monitor. So that it is not really
necessary to use
Observer on client.


Redtea

Page
23

CONFIDENTIAL
3/15/2013

Observer Pattern:




The actions that interact between user and computer
are

easily
handled

because every time user click button or press a key, it
will trigger an event. But what if there is a change in the internal

of the program and we want to

notify the change to the user,
how can we do it? We can use a thread to fulfill the job, however, the thread will run continuously and it cost a lot of reso
urce.
We can then reduce the priority of the thread and reduce the re
fresh rate by putting the thread in sleeping state. However, if
there are 2 events occur in the sleeping period, then the user will not know. Here is where the observer pattern comes in; it

will
notify the observer immediately whenever there is a change fr
om internal. Also, it take less memory to process compare to using
thread method.


Redtea

Page
24

CONFIDENTIAL
3/15/2013

Proxy Pattern:




Proxy pattern will help us completely hide the actual class from client and still, it makes the client believe that they are
process
locally.


Redtea

Page
25

CONFIDENTIAL
3/15/2013

Singleton P
attern:




When we create an object, that object will only available
within the class that creates that instance. However, we want that
object is available for every class that can access and still, decoupled between that object and other classes. The sin
gleton will do
the job for us. In this particular problem, we use the command pattern to encapsulate each of the action and still, we do wan
t to
write a log to a file for that action in such the time of the action occurs, the result of the action, and we d
o not want to see so
many relationships all over the place. Thus, we singleton the controller class, this is the class that handle all the interna
l activity,
and through observer pattern, we can write the new log to the log file.

Redtea

Page
26

CONFIDENTIAL
3/15/2013

State Pattern:


This is a
n important factor to maintain states when the user using the ATM. There are 5 states: Balance

State, Withdraw

State,
Deposit

State, Transfer

State and normal. If the user is at Withdraw

State, he cannot grant access to method deposit (). The
states imple
ment State interface.

When user selects an action, it will move to the desired state and run its duty. The others
methods it will ignore and move to the next state. State pattern provides flexibility to change exact step to step in the
application.


Redtea

Page
27

CONFIDENTIAL
3/15/2013

3.

Management
and Project Planning

3.1.

Management Approach

-

Our Group decided to use Scrum system to develop our software because of several advantages of this method. The first
advantage is that it is simple and easy to follow. In campus
, every member of our group meets the others almost every day, so
we can have a lot of scrum meeting and discussion about the problems and solutions of our system.


-

The second advantage is with scrum process, we can break the work down to many parts. Hence
, we can balance the work of
everyone, and our system was finished step by step.


3.2.

Sprint Retrospective Meeting

-

We have 1 meetings in class each week

-

Each meeting in class is a time boxed to 5 minutes

-

The scrum meeting in class is the place
where each member showed the result of the work part then discusses what problem
they face and how to improve it.


Redtea

Page
28

CONFIDENTIAL
3/15/2013

3.3.

Product Backlog


Backlog Description





























TITLE

Sprint

01

02

03

04

05

06

07

08

09

10



ATM Simulator

Total

4

5

7

14

14

17

12

11

16

0

Title Import

Initial
Estimate
(Days)

Adjust
Factor

Adjusted
Estimate





















01

Analyse requirement

1.0

0.2

1.2

0.3

0.3

0.3

0.3

0.0

0.0

0.0

0.0

0.0

0.0

01

Write Document

2.0

0.0

2.0

1.0

0.0

0.5

0.0

0.0

0.5

0.
0

0.0

0.0

0.0

01

Write class diagrams

2.0

0.0

2.0

0.0

0.5

0.0

0.0

0.0

0.5

0.0

0.0

1.0

0.0

01

Graphic user interface

2.0

0.2

2.4

0.1

0.4

0

1.0

0.7

0.0

0.0

0.0

0.0

0.0

01

Basic classes (account, client,
server)

2.0

0.2

2.4

0.0

0.6

0.0

0.0

0.6

0.0

0.4

0.6

0.0

0.0

01

Withdraw method

2.0

0.2

2.4

0.4

0.0

0.0

0.6

0.0

0.0

0.8

0.6

0.0

0.0

01

Deposit method

2.0

0.2

2.4

0.0

0.6

0.0

0.0

0.0

0.6

0.4

0.6

0.6

0.0

Sprint
-

1 (Totals)

13.0

1.0

14.8

1.8

2.4

0.8

1.9

1.3

1.6

1.6

1.8

1.6

0.0

02

Text based interface

3.0

0
.0

3.0

0.0

0.0

0.0

0.8

1.5

0.3

0.4

0.0

0.0

0.0

02

Advanced
functions(Notification,exchange
currency)

3.0

0.2

3.6

0.0

0.0

1.1

1.2

0.5

0.0

0.0

0.0

1.8

0.0

02

Security(Login/log out)

3.0

0.5

4.5

0.0

0.0

0.0

0.0

0.0

2.0

0.5

0.0

0.0

0.0

02

Additional functio
n

2.0

0.0

2.0

0.0

0.0

0.0

0.0

0.5

0.2

0.5

1.0

0.8

0.0

Sprint
-

2 (Totals)

11.0

0.7

13.1

0.0

0.0

1.1

2.0

2.5

2.5

1.4

1.0

2.6

0.0

Redtea

Page
29

CONFIDENTIAL
3/15/2013

03

Testing ATM simulator system

4.0

0.0

4.0

0.0

0.0

0.2

0.0

0.6

0.0

1.5

0.0

1.5

0.0

03

Formatting, comment

3.0

0.0

3.0

0.0

0.
0

0.4

1.5

0.6

0.7

0.0

0.0

0.0

0.0

03

Complete report

3.0

0.0

3.0

0.0

0.0

0.0

0.0

0.0

1.5

0.0

1.5

0.0

0.0

Sprint
-

3 (Totals)

10.0

0.0

10.0

0.0

0.0

0.6

1.5

1.2

2.2

1.5

1.5

1.5

0.0

Release
-

1

34.0



37.9

1.8

2.4

2.5

5.4

5.0

6.3

4.5

4.3

5.7

0.0


Redtea

Page
30

CONFIDENTIAL
3/15/2013

3.4.

Sprint Backlog




Redtea

Page
31

CONFIDENTIAL
3/15/2013

3.5.

Sprint Review Meeting

3.5.1.

Sprint Review Meeting (Sprint 1)


Present
: Cuong, Phuc, Trieu

Scrum Master
: Phuc

Time:

7/8/2009

Duration
: 30 minutes


What

Description

Who

Duration

Confirm that the team
has
delivered on its
commitments

Confirm the basic
function of the project
is already complete(
log in, log out,
withdraw, deposit) as
well as the
development of base
classes (server side,
client side)

Phuc

5 m

Confirm that the
project is on track

The projec
t is on track,
it can be submitted in
time

Phuc

5 m

Examine the
functionality which
has been delivered

Every functions is
working fine

Phuc, Trieu,
Cuong

15m

Discuss functionality
which was committed
but not finished

Nothing

Phuc, Trieu,
Cuong

5m



Redtea

Page
32

CONFIDENTIAL
3/15/2013

3.5.2.

Sprint Review Meeting (Sprint 2)

Present
: Cuong, Phuc, Trieu

Scrum Master
: Phuc

Time:

2/9/2009

Duration
: 30 minutes


What

Description

Who

Duration

Confirm that the team
has delivered on its
commitments

Confirm the advance
functions of the pr
oject
is already completed
(implement patterns to
project, using ejb
techniques)

Phuc

5 m

Confirm that the
project is on track

The project is on track,
it can be submitted in
time

Phuc

5 m

Examine the
functionality which
has been delivered

Every function
s is
working fine

Phuc, Trieu,
Cuong

15m

Discuss functionality
which was committed
but not finished

Nothing

Phuc, Trieu,
Cuong

5m


4.

Attachment 1

Don’
t want comments on source code.