University Of Benghazi faculty of Information Technology

ATM system simulation project ( MY - ATM )

Serag El magabri student no : 288
Abstract

In System Design Life Cycle SDLC, a framework of software production, the documentation is
the output of many system design phases, also the input of the next phase. Software development
stage requirement analysis, design, testing and deployment are known as the most important
phases in SDLC, which have an output for each.This sheet is an instance of the documentation
process, in a technical report, of a Automated Teller Machine ATM case study and include a
system specification for simple ATM simulation .The Unified Modeling Language UML
diagrams used to make system specification and these diagrams iterate in each system design life
phases, more details added in each iteration .

1. Introduction
Recently, Automated Teller Machine ATM software design has become a familiar case study,
which is used as an example for an Object Oriented Programming (OOP) approach. This report
presents a documentation process for a project called MY-ATM which is considered to be a
simulation for an ATM. In this document, Unified Modeling Language (UML) diagrams use case
diagram , class diagram and sequence diagram were used to describe the specification of both of
static and dynamic views of the system, in addition to, communication diagram, which is, in fact,
does not belong to the UML nations diagrams, but they are provide a better understanding to the
communication between classes .

2. System Scenario
In the My- ATM case study scenario , each bank client has a bank card with a card number that
refers to account number , and user password refers to a card PIN, which is stored in the client
account record in the bank database server . The bank client can use his card to make specific
operations withdraw, deposit and make a check on his account balance. In the ATM system, as it
is known, there is a daily withdrawal amount constraint that can not be violated by the client,
and this daily amount is presented to the client by checking balance operation or through the
withdrawal process to let him know how much money he could withdraw. Also the Bank client
can make a deposit process by providing a deposit slot with cash money.For more flexible
services ,the client can choose his favorite language from two types of languages one for an
Arabic Interfaces or an English Interfaces. The last third service provided by My- ATM
system is check-in client balance either the available daily withdrawal amount or the total client
account balance .
3. Use case diagram :
Requirements captured in UML are specified within the Use Case Model, which is a functional
requirement expressed as a set of interrelated use cases. The Use Case Diagram is a high level

1
view of those related use cases. The output for the Use Case Model are the use case diagram and
use case scenario for each of interrelated use cases. In figure 1 a use case diagram that specifies
the project domain. In the use case diagram four major parts included : System/Domain
Boundary, Actors, Use Cases and Communication Associations - interactions between actors and
use cases.

Figure ( 1 ) a use case diagram for MY - ATM project domain

4. Use cases and scenario

The use cases expressed each function in the system and the client can do with the system. Each
bubble in the use case expressed with a structured textual description of the functional steps
Known as use case scenario , for MY - ATM, there are four main scenarios which are :

● Withdrawal
● Deposit
● Check balance
● Change Language

2
For each one of the above functions there is at least one corresponding scenario, but in fact each
one must have two, one for the normal scenario and second for the exemption may occur as the
client enters an incorrect PIN. In this documentation report two normal scenarios included,
which express Withdraw and Deposit functions and one exception scenario for Withdraw if the
user enters an incorrect PIN .

5. Use Case Name: Withdrawal . (Scenario 1)

Summary : Bank card installed, account number and PIN entered correctly, choose cash
available amount and ATM dispenses the cash.
Actors: Bank Client.
Description:
5.1 The user inserts a Bank card.
5.2 ATM requests Bank account number and PIN number .
5.3 The user enters the Bank account number, PIN correctly.(Use case:Find Account ) .
5.4 The ATM displays the Main menu .
5.5 The user chose the Withdrawal option.
5.6 The ATM displays available cash and Withdrawal amount list.
5.7 The user chose the amount correctly.
5.8 ATM check amount is available, dispensing cash and displaying process success .

6. Use Case Name: Withdrawal . (Scenario 2 Exception Scenario)

Summary : Bank card installed, account number and PIN entered incorrectly, ATM display error
message .
Actors: Bank Client.
Description:
6.1 The user inserts a Bank card.
6.2 The ATM requests Bank account number and PIN number .
6.3 The user entered the Bank account number and incorrectly PIN correctly. (Use
case:Find Account ).
6.4 The ATM displays an error message on the ATM screen .

7. Use Case Name: Deposit . (Scenario 1)

Summary : Bank card installed, account number and PIN entered correctly, choose Deposit
option install amount in Deposit slot and ATM count the cash and finish deposit process .
Actors: Bank Client.
Description:
7.1 The user inserts a Bank card.
7.2 The ATM requests Bank account number and PIN number .
7.3 The user enters the Bank account number , PIN correctly.(Use case:Find Account ) .
7.4 The ATM displays the Main menu .

3
 7.5 The user chose the deposit option a.
7.6 The ATM requests cash in the deposit slot list .
7.7 The user inserts the deposit cash amount in the deposit slot .
7.8 The ATM count deposit cash amount , dispensing confirmation message .
7.9 The user confirms the process .
7.10 The ATM finished the deposit process and displayed the process success .

Note : In MY -ATM simulation project, the deposit amount is generated randomly in each
deposit process .

8. Use Case and Actors Table :

From the project scenarios, there is a tow table produced , the first called The requirements list
,which is including use case names, their functional requirements and the second one is for the
Actors that interact with the each use case, in MY - ATM simulation project, there is five use
cases and tow Actors which are in the tables 1,2 .Table ( 1 ) includes use case in project domain

NO. Requirement Use case

1 Withdrawal specific cash amount from bank account Withdrawal

2 Deposit specific cash amount to bank account Deposit

3 Retrieve both of available Withdrawal amount and total bank account Check Account

4 Authenticated user login , return user account to use in ATM Find Account
operations

5 Changing interfaces languages Change language

Table ( 1 ) requirements list for MY - ATM project

The second table, table ( 2 ) includes Actors that interact with use cases in table ( 1 ) ,known as
Actors list .The Actors can be either human , device or other system that communicates with the
system out of its boundary or domain. table two expresses actors that are considered in MY -
ATM simulation project .

NO. Actor Description

1 Bank Clint The bank customer hows won a bank account

2 Bank sever The bank database server which stores all account transactions
and information.

Table ( 2 ) Actors list for MY - ATM project

4
9. Candidate Classes
After the requirement capturing process, that is specified by using use cases diagram and use
case scenarios , extracting system classes by detecting objects takes place. Candidate Classes is
the process which is implemented by seeking for nouns and noun-phrases in the scenarios, also
some functions could be specified in this phase by extracting verbs from use cases scenarios too.
The output for this process is known as the Candidate Classes table , nouns are listed in this table
and analysis to choose the correct Classes. In this phase some mistakes in Candidate Classes may
occur but this is normal and with the iteration of those diagrams in next stages of the system
design the facts must be declared correctly .
Candidate Classes is one of the most important early stages because it will form the basis of the
other models: Class Diagrams, Sequence Diagrams, Collaboration Diagrams and Statecharts.
Some of those models will be presented in this report, the most famous ones .In deciding which
objects may end up as classes, it is useful to categorize and list the nouns and noun-phrases as
probable, possible or unlikely as in table ( 3 ) .

Probable Possible Unlikely

MY-ATM Card Deposit slot

System PIN Message

Account Account number Cash

Bank Client Main menu Money

Screen error message Deposit amount

Languages operations Available amount

Interfaces Authenticated Total balance

Table ( 3 ) the noun and noun phrases in Candidate classes process.

In this stage candidates may move from one column to other one according to changing in
system understanding,also some nouns may change if they correspond to key words in the
implementing environment (e.g., system in java is a keyword or reserved word ). The output of
this process is a first cut class diagram,

10. The first cut Class diagram

The first cut class diagram is derived from use cases, scenarios, use case description, also the
attributes could be extracted too, in the first cut functions, operations and associations are
ignored for the next stage . The first cut class diagram for MY - ATM case study is as shown in
figure ( 2 ).

5
In MY - ATM simulation project, there are seven classes Account, SoftWareStartUp,
InterFaceControler, MyATM, WOnScreen, InterFaceLangauge and Operations, which are stand
on the candidates nouns MY-ATM, System, Account, Screen, Languages and Interface.

figure ( 2 ) First cut class diagram

Some changes are occur to the names of the classes spelling due to two reasons, first reason, that
some of the candidates nouns is similar to reserved words (e.g., Screen, System become
WOnScreen, SoftWareStartUp), and the second reason is to simplify both of discover and
member there roles by the IT profisints when some of the try to understand what the behavior for
each of the system classes, and that was don by adding words to describe the classes nature (e.g.,
Languages become InterFaceLangauge). In some cases the two reasons implemented together
(e.g., Screen became WOnScreen), in this case Screen turned to WOnScreen based on Write On
Screen .

In the real world system designs, the first cut diagram, in usual, expresses the entity classes only,
which will be save in the database system, but in My - ATM case study it is bringing together
either of entity, control, and interface classes, so My - ATM system classes could be grouped
according to classes categories in fact like bellow :
● MY-ATM, SoftWareStartUp class are an Interface class
● Account class is an entity class
● InterFaceControler, WOnScreen,InterFaceLangauge and Operations are control classes .

6
11. Communication diagram
In order to go ahead in extracting system functions and its internal messages, the
communication diagram can lead to a better understanding of the interaction and messages
between objects, in a process called use case realizations. It is a good programming practice to
use the communication diagram to declare the interaction and collaboration between the system
units and objects. In figure ( 3 ) the communication diagram of the part of withdrawal use case
to the client login from step 1 to step 4, and displaying the main screen in MY - AT system .

figure ( 3 ) the communication diagram for withdrawal use case from step 1 to the step 4

7
In figure ( 4 ), the communication diagram for the withdrawal use case from step 5 to step 8
describes the interaction between classes to finish the withdrawal function .

Figure ( 4 ) the communication diagram for the withdrawal use case from step 5 to step 8

12. Classes function and attributes

In object Oriented Programming ( OOP ), the classes diagram is considered to represent the core
of an object-oriented domain.In this diagram, classes functions and attributes are extracted and
expressed by seeking verb phrases in candidate classes table and system analysis textual context
, in this stage, the communication diagram, which is delivered in the previous stage should assist
too in detecting system functions. Class diagrams represent the attributes by assigning them with
either ( + or - ) operators,for public and private declaration, also their names must begin with
small letters in first word and capital letter for the second word and each new word
.However,That is not prevented by many programming languages to ignore that. In addition,
function nouns too should have the same name style .The figure ( 5 ) delivered an entire MY -
ATM system class diagram without including for the associations. The associations will be

8
included in a more advanced stage, after examining the relation between each two classes
individually .

Figure ( 5 ) MY - ATM system class diagram

9
13. The relationship between classes
The relationships or associations between the classes are an important component of the class
diagram. There are three main kinds of association: simple, generalization (inheritance) and
aggregation.In order to enhance class, the generalization is applied to classes and it's also an
important concept in ( OOP ) . Associations act like a pipe or channel connecting a number of
objects of both classes which associate with each other called a multiplicity of associations. It
may occur in 1:1 or 1:M or N:M . The associations always are verbs present the relation between
classes. Figure ( 6 ) shows a set of relationships or associations that bring each two classes
together in MY - ATM .

Figure ( 6 ) associations and multiplicity between MY - ATM classes

Always, the associations are one direction relationships, in many cases, it is possible found two
associations between two classes one on each direction, as in Figure ( 7 ) SoftWareStartUp class

10
could send the keypad input string to the WOnScreen class, also WOnScreen class could set the
text alignment for ATMDisplay screen control .

Figure ( 7 ) two different direction associations between two classes

14. MY - ATM class diagram model

After examining the relationships between classes, it could be expressing the classes in MY -
ATM simulation case study in class diagram model that included advanced ( OOP ) concepts
such as associations, multiplicity, inheritance and aggregation and bring all that together in a
high level diagram model, so below in Figure ( 8 ) , it is presented MY - ATM class diagram
model .

Figure ( 8 ) MY - ATM class diagram model

11
15. Sequence Diagram
In order to deliver the dynamic view of any UML design including MY - ATM project, the use of
Sequence Diagram is the first step to do, the dynamic view of the application domain is
expressing the behavior of it, the interaction of its objects with each other. That is the most
benfest retrieved by using sequence diagrams,although it is so important to go through the static
diagrams but the dynamic could go farther to describe the lifetime of the classes and objects . In
figure ( 9) the system classes interact together to perform the withdrawal process .

Figure ( 9 ) the sequence diagram for the withdrawal process

12
Also, in figure ( 10 ), the system classes of MY - ATM system communicated in interaction
behavior style to perform the process of making cash deposit .

Figure ( 10 ) the sequence diagram for the deposit process .

In the System Design Life Cycle, the sequence diagram may apperded several times either in
analysis phases or in design phases, it is expressed system units in the forms of Objects,
interfaces, Actor involved in the Use Case, time life lines and messages sent between objects. In
some cases some differences may occur in the sequence diagram as it comes in the software
design textbooks but the main general idea is still the same in each. For this report, the sequence
diagram is the last diagram used to specify the project .

13
 ● Summary

In this technical report, Automated Teller Machine ATM is considered as a case study ,and the
report represents documentation processes corresponding to the most important phases in the
system design lifetime. Seven different classes are delivered in this document, which are:
Account, SoftWareStartUp, InterFaceControler, MyATM, WOnScreen,InterFaceLangauge and
Operations class. An Account class is a famous model that has no new ideas to perform, however
, in the other classes, new ideas were expressed in the style of operating the system. MyATM is
the main thread starter in this system which is called the SoftWareStartUp class.After
SoftWareStartUp is called, it constructs the system Interface. SoftWareStartUp establishes a set
of activity listeners that detect user's interactions, After SoftWareStartUp detected an event it is
send a message to the InterFaceControler class which determine the action type based on a
public state variables ( layOutStack, UAction ) which are locate the current layout and the
current user action by using control statements ( IF, Switch). The system displays its
functionalities in menus and the user chooses his desired service by using input control, and
InterFaceControler class sends a message to Operations class to perform the desired services . In
addition send results to the ATM screen is the responsibility of InterFaceControler which is call
the WOnScreen class .When WOnScreen reserved a message to display it is detecte user
preferred language based on language flag variable ( langaugeFlag ), and call for
InterFaceLangauge to run its getter and setter functions to change the text variables for the
system menus.All these functionalities are performed based on OOP programming concepts and
implemented in Java Eclipse IDE.

References

1 Paul, D., & Harvey, D. (2012). Java-How to program.

2 Bennett, S., McRobb, S., & Farmer, R. (2005). Object-oriented systems analysis and design using UML. McGraw
Hill Higher Education.

14