Object Modelling for ATM System - Requirements, Use Case Model, UML Domain Model Class, SDLC

This article discusses the object modelling for an ATM system including its core functional and non-functional requirements, use case model, UML domain model class, and SDLC. It also includes a bibliography of relevant sources.

Running head: OBJECT MODELLING
OBJECT MODELLING
Name of the Student
Name of the University
Author Note

1OBJECT MODELLING
Table of Contents
Identifying & describing the core functional & non-functional requirements of the ATM.......2
Use Case Model for the IS (Information System)......................................................................5
UML Domain Model Class:.......................................................................................................9
SDLC........................................................................................................................................10
Bibliography:............................................................................................................................12

2OBJECT MODELLING
Identifying & describing the core functional & non-functional requirements of the ATM
The core functional & non-functional requirements of the Collin’s ATM based on the
provided details are listed as follows under the following two categories:
FUNCTIONAL REQUIREMENTS:
The core functional requirements of the system as per the demand has been listed as
follows:
Non-active Condition: Under, the scenario an invalid card is inserted, the screen should flash
the message in initial display.
System requirement: The core requirement of the system is installation of protocols for
information storage and execution process.
Authentication Procedure: In the scenario, when the card is inserted, the ATM card pin
should be inserted to validate the card and in the process enter the cash card mode.
Acceptance of card: The system requirement quotes the condition that the card will only be
accepted if the serial number & the code of bank are readable in the card. Contrary, if the
card is not readable and takes over 5 seconds than the process should be cancelled with an
error message flashing on the screen.
Accepting the serial number: The serial number on the card should be identified by the
system that it should be stored in core system’s memory.
Pin request: Successful recognition of the card will generate a screen requesting for the
card’s pin and only after its validation can the process.

3OBJECT MODELLING
Pin processing: In case, wrong pin is entered by the user they will be offered a total of three
opportunities to correct their mistake after which the card will be captured by the system. On
positive response, the process will proceed.
Transactional queries: After validation of the pin, the user must be enquired about the type of
process they wish to proceed with be it withdrawal, deposit or any other.
After transaction: After the desired process of the user is completed, the system will flash a
message enquiring about the next step that will ask “whether the user wishes to continue or
exit the system”. Finally, whether the user wishes to get a physical receipt will be enquired
before completing the process
NON_FUNCTIONAL REQUIREMENTS:
The non-functional requirements of the system will enquiry about the scalability,
durability and other factors that has been listed as follows:
Adaptability: The system should show adaptability that is in dire circumstances (that would
not compromise with the security of the system), the system should show adaptability and
adopt the change.
Compatibility: The system should be compatible with the already existing infrastructure to
avoid any discomfort for the end-user while keeping the purpose understandable. The
information collected during the account opening should be compatible with the devised
system.
Efficiency: One of the most notable requirement of any system is efficiency and the devised
system also demands the same. The system should be capable of fulfilling the end-user
demand with suitable output by allowing them to use the available options with ease.

4OBJECT MODELLING
Flexibility: The discussed system should not limit itself to only the transactional operations
but also offer other features such as viewing last transactions, mobile accessing, change of
pin and others while offering flexibility in the process.
Scalability: The discussed system cannot be changed readily and hence should be capable of
standing overloads while fulfilling its purpose. In other words, the system should be capable
of delivering its services (such as withdrawal, deposit and others) even, when the traffic for
the system is too much to handle.
Security: One of the core requirements of the system is a strong security because, if the
system fails in the discussed area it will not only have a short-term side-effect but will also
affect the sustainability of the organisation in long-run. Hence, the system should offer
reliability and only offer its services when the card is validated through proper authentication.
User interface: The system should offer understandable interface options that is the dialogue
boxes & the options should be understandable to the user for execution of the needed
command to execute necessary option. The appearance on the screen should also gain the
attention of the user instantly so, that they can access the desired option without any hassle.
Usability: As discussed in the section above, the system should offer easy user interface,
however that would not be enough as the user would need an easy usability too. The system
should be accessible for the users and the outputs must be effective and efficient. The
acceptance of card should also be an easy and secure process. A tutorial option should be
available for the new users to understand the system.

5OBJECT MODELLING
Use Case Model for the IS (Information System)

6OBJECT MODELLING
Figure 1: UML CASE MODEL
(Source: Created by Author)
The following table offers a descriptive detail about the use cases of the proposed
system:
USE CASE DESCRIPTION
ATM Card inserted The deemed use case refers the authorisation offered by the
system to insert the card.
Recognition of the card Here, the system should show its capability of providing the card
details to the bank to validate the user data.
Re-insertion of the card If, under certain scenario, the card is deemed unreadable by the
system then the system should offer the user another opportunity
to insert the card and proceed.
Insert Pin After validating the card detail, the deemed use case offers the
option of inserting the pin of the card to proceed further.
Verification The pin inserted by the user should be sent to the bank by the
system for validating the pin after which the system would offer
access to the user.
Re-entering of the pin The system should offer the option of re-entering the pin, in case
the pin entered during the first time was invalid or was
unaccepted by the bank.
Validate process After, the correct pin is entered in the system, the ATM should
notify the bank to authorise the user so that they can proceed
with their objective associated with the system.
Options The options will enable the user to view different options made

7OBJECT MODELLING
available by the system.
Selection of Account After viewing the options the user must select the type of
account they want to proceed with be it savings, current or other
type of account.
Main Menu The main menu is made visible to the user for selection of
further process.
Deposit The system will offer the option of depositing the money in the
account of the user or the one user wishes to deposit their
money.
Withdraw The system will even flash withdrawal option from where the
user can proceed with withdrawal of their money.
Transfer The system will offer the option of transferring their money to
someone else’s account.
Other The screen will also host the deemed option which will take the
user to another section where they can use other services such as
pin change, mobile banking, last transaction and similar options.
Mobile Banking The system will enable the user to proceed with the task in hand
by using their mobile to further ensure security of the system.
Change Pin The system will allow the user to change the pin.
Last Transaction The system will offer the user to visit their last transaction
(limited to last 10 transaction).
Develop Report The system in association with the bank will publish the report
of the account of the user.
Table 1: USE CASE DESCRIPTION

8OBJECT MODELLING
(Source: Created by Author)
Name of the Use Case Main Menu
Initiating incident The user enters the system and views the main menu to proceed
with their objective.
Description Post authorisation the system authorises the user to view and
access the main menu.
Participants System, user and bank
Sub-categorised use
case
The user can view different use cases such as deposit, transfer,
withdrawal and others. Others will further offer sub-use cases
such as the pin change, last transactions and mobile banking.
Pre-condition The precondition for the use case model is the selection of
account after which the user moves ahead with other processes.
Post-condition It will differ according to the option selected by the user which
may be deposit, transfer, pin change and other available options.
Activity flow The activity flows between the user and the system.
1st: The user enters the card and is verified by the system.
2nd: The user enters the pin which is again verified by the
system.
3rd: The user selects the main menu option after which the
available options are made visible by the system.
Adverse condition The card inserted by the user have no association with any valid
account.
The pin entered by the user in invalid.
Table 2: FULLY DEVELOPED CASE USE

9OBJECT MODELLING
(Source: Created by Author)
UML Domain Model Class:
Figure 2: UML DOMAIN MODEL CLASS
(Source: Created by Author)
REALISTIC ASSUMPTIONS:
The provided diagram is made by making different assumptions. The reason for
making assumptions during the development of the class diagram lays on the fact that the
offered environment was not sufficient enough. Hence, to proceed with the task in hand

10OBJECT MODELLING
assumptions were made which greatly assisted in the creation of the discussed diagram which
can be further used to create class diagram of the subject that is the ATM system.
The most prominent assumption that was made was regarding to the connection
between the ATM and the bank along with the assumption that the bank has the user’s details
maintained in their database. The reason for making the discussed assumption lays on the fact
that the ATM cannot proceed with its task until and unless it has received the bank details of
the user to ensure the validity of the transaction. Hence, to validate the data of the user the
discussed assumption about the user data and database along with an electronic connection
between the ATM and bank were made.
SDLC
The following six phases are included in the SDLC (Software development Life
Cycle):
1. COLLECTING AND ANALYSING THE REQUIREMENTS: The discussed phase
includes identification and collection of the requirements followed by analysing them to
reach a suitable conclusion.
2. DESIGNING: The discussed phase involves identification of the design that satisfies
the requirements and is also compatible with the system it is to be installed in.
3. IMPLEMENTATION: The discussed phase involves actualisation of the proposed
design that needs to be installed in the subject system and proceed accordingly with the
implementation of the design.
4. TESTING: In the deemed phase the testing of the designed tool is done to ensure its
suitability with the subject system. The testing can be done in a prototype or even in a
simulation tool rather than using an actual system for testing.

11OBJECT MODELLING
5. DEPLOYMENT: After successful testing of the proposed tool, it is installed in the
system in the discussed phase.
6. MAINTENANCE: After the tool is installed in the system, periodical maintenance
should be done to ensure proper operation of the system and even avoid lagging or faults in
the system during overload or any other dire situation.
Description of the environment
ATMs (Automated teller machine also goes by the name of alternative delivery
channel because it offers alternative of banking process while delivering a pre-designated set
of services and acting as a channel for the user and the banking services offered by the bank.
Designing of application component
The proposed application would contain a front end that would be connected to the
internet for collecting data of the user from the internet because the ATMs does not contain
any database to store the information of the user rather it collects it from bank when needed.
User Interface
It is one of the crucial factors as UI (user interface) decides the comfortability that the
user will enjoy while using the system. Hence, the UI should be designed appropriately so
that the user can perform system operations efficiently and in the process receive effective
response from the system.
Database
As stated above, the system does not contain any database and collects data from the
bank via internet when needed.
Software method

12OBJECT MODELLING
The software method should be easy and secure to offer comfortability and security at
the same instance.
Bibliography:
Bahill, A. T., & Madni, A. M. (2017). Discovering system requirements. In Tradeoff
Decisions in System Design (pp. 373-457). Springer, Cham.
Bernardi, S., Flammini, F., Marrone, S., Mazzocca, N., Merseguer, J., Nardone, R., &
Vittorini, V. (2013). Enabling the usage of UML in the verification of railway
systems: the DAM-rail approach. Reliability Engineering & System Safety, 120, 112-
126.
Cabot, J., Clarisó, R., & Riera, D. (2014). On the verification of UML/OCL class diagrams
using constraint programming. Journal of Systems and Software, 93, 1-23.
Cunha, A., Garis, A., & Riesco, D. (2015). Translating between Alloy specifications and
UML class diagrams annotated with OCL. Software & Systems Modeling, 14(1), 5-25.
De Gramatica, M., Labunets, K., Massacci, F., Paci, F., & Tedeschi, A. (2015, March). The
role of catalogues of threats and security controls in security risk assessment: an
empirical study with ATM professionals. In International Working Conference on
Requirements Engineering: Foundation for Software Quality (pp. 98-114). Springer,
Cham.
Dennis, A., Wixom, B. H., & Tegarden, D. (2015). Systems analysis and design: An object-
oriented approach with UML. John wiley & sons.
Halim, A. (2013, November). Predict fault-prone classes using the complexity of UML class
diagram. In Computer, Control, Informatics and Its Applications (IC3INA), 2013
International Conference on (pp. 289-294). IEEE.

13OBJECT MODELLING
Johnston, S. K., & Nally, M. P. (2015). U.S. Patent No. 9,122,422. Washington, DC: U.S.
Patent and Trademark Office.
Karasneh, B., & Chaudron, M. R. (2013, October). Online Img2UML Repository: An Online
Repository for UML Models. In EESSMOD@ MoDELS (pp. 61-66).
Khan, P. M., & Beg, M. M. (2014). Measuring Cost of Quality (CoQ) on SDLC Projects is
indispensible for effective software quality assurance. arXiv preprint
arXiv:1405.4824.
Kumar, N., Zadgaonkar, A. S., & Shukla, A. (2013). Evolving a new software development
life cycle model SDLC-2013 with client satisfaction. International Journal of Soft
Computing and Engineering (IJSCE), 3(1), 2231-2307.
Mahalakshmi, M., & Sundararajan, M. (2013). Traditional SDLC Vs Scrum Methodology–A
Comparative Study. International Journal of Emerging Technology and Advanced
Engineering, 3(6), 192-196.
Montefusco, P., Casar, R., Stelkens-Kobsch, T. H., & Koelle, R. (2016). Addressing security
in the ATM environment.
Sagar, V. B. R. V., & Abirami, S. (2014). Conceptual modeling of natural language
functional requirements. Journal of Systems and Software, 88, 25-41.
Stikkolorum, D. R., Ho-Quang, T., & Chaudron, M. R. (2015, August). Revealing Students'
UML Class Diagram Modelling Strategies with WebUML and LogViz. In Software
Engineering and Advanced Applications (SEAA), 2015 41st Euromicro Conference
on (pp. 275-279). IEEE.
Störrle, H. (2013). Towards clone detection in UML domain models. Software & Systems
Modeling, 12(2), 307-329.