BANK&ATM

SIMULATOR
Page | 1

CHAPTER 3
System Design

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 2
 3.1 Overall System Design Using Designing Tools

 DFD (DATA FLOW DIAGRAM)

 Data-flow diagram is a way of representing a flow of data through a process or a

system (usually an information system). The DFD also provides information about the
outputs and inputs of each entity and the process itself.

 A data-flow diagram has no control flow — there are no decision rules and no loops.
Specific operations based on the data can be represented by a flowchart.

 There are several notations for displaying data-flow diagrams. The notation presented
above was described in 1979 by Tom DeMarco as part of structured analysis.

 For each data flow, at least one of the endpoints (source and / or destination) must exist
in a process. The refined representation of a process can be done in another data-flow
diagram, which subdivides this process into sub-processes.

 The data-flow diagram is a tool that is part of structured analysis and data modelling.
When using UML, the activity diagram typically takes over the role of the data-flow
diagram. A special form of data-flow plan is a site-oriented data-flow plan.

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 3
 Components of DFD

 DFD consists of processes, flows, warehouses, and terminators. There are several
ways to view these DFD components.

 Process

 The process (function, transformation) is part of a system that transforms inputs to

outputs. The symbol of a process is a circle, an oval, a rectangle or a rectangle with
rounded corners (according to the type of notation). The process is named in one word,
a short sentence, or a phrase that is clearly to express its essence.

 Data flow
 Data flow (flow, dataflow) shows the transfer of information (sometimes also material)
from one part of the system to another. The symbol of the flow is the arrow.

 The flow should have a name that determines what information (or what material) is
being moved. Exceptions are flows where it is clear what information is transferred
through the entities that are linked to these flows.

 Material shifts are modelled in systems that are not merely informative. Flow should only
transmit one type of information (material).

 The arrow shows the flow direction (it can also be bi-directional if the information
to/from the entity is logically dependent—e.g. question and answer). Flows link
processes, warehouses and terminators.

 Warehouse
 The warehouse (datastore, data store, file, database) is used to store data for later use.
The symbol of the store is two horizontal lines, the other way of view is shown in the
DFD Notation.

 The name of the warehouse is a plural noun (e.g. orders)—it derives from the input and
output streams of the warehouse. The warehouse does not have to be just a data file but
can also be, for example, a folder with documents, a filing cabinet, or a set of optical discs.
Therefore, viewing the warehouse in a DFD is independent of implementation.

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 4
 The flow from the warehouse usually represents reading of the data stored in the
warehouse, and the flow to the warehouse usually expresses data entry or updating
(sometimes also deleting data).

 The warehouse is represented by two parallel lines between which the memory name is
located (it can be modelled as a UML buffer node).

 Terminator
 The terminator is an external entity that communicates with the system and stands outside
of the system. It can be, for example, various organizations (e.g. a bank), groups of people
(e.g. customers), authorities (e.g. a tax office) or a department (e.g. a human-resources
department) of the same organization, which does not belong to the model system.

 The terminator may be another system with which the modelled system communicates.

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 5

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 6

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 7

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 8

 UML Diagram

 The unified modelling language (UML) is a general-purpose visual modelling

language that is intended to provide a standard way to visualize the design of a
system.
 The creation of UML was originally motivated by the desire to standardize the
disparate notational systems and approaches to software design. It was developed
at Rational Software in 1994–1995, with further development led by them through
1996.
 In 1997, UML was adopted as a standard by the Object Management Group (OMG),
and has been managed by this organization ever since. In 2005, UML was also
published by the International Organization for Standardization (ISO) and
the International Electrotechnical Commission (IEC) as the ISO/IEC
19501 standard.[2] Since then the standard has been periodically revised to cover the
latest revision of UML.
 In software engineering, most practitioners do not use UML, but instead produce
informal hand drawn diagrams; these diagrams, however, often include elements
from UML.

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 9

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 10
 Class Diagram

 In software engineering, a class diagram in the Unified Modelling

Language (UML) is a type of static structure diagram that describes the structure of
a system by showing the system's classes, their attributes, operations (or methods),
and the relationships among objects.

 The class diagram is the main building block of object-oriented modelling. It is

used for general conceptual modelling of the structure of the application, and for
detailed modelling, translating the models into programming code. Class diagrams
can also be used for data modelling. The classes in a class diagram represent both
the main elements, interactions in the application, and the classes to be
programmed.

 In the design of a system, a number of classes are identified and grouped together
in a class diagram that helps to determine the static relations.

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 11

CLASS DIAGRAM OF BANKING SYSTEM

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 12

 Activity Diagram

 Activity diagrams are graphical representations of workflows of stepwise activities and

actions with support for choice, iteration and concurrency.
 In the Unified Modelling Language, activity diagrams are intended to model both
computational and organizational processes (i.e., workflows), as well as the data flows
intersecting with the related activities.
 Although activity diagrams primarily show the overall flow of control, they can also
include elements showing the flow of data between activities through one or more data
stores.
 Activity diagrams can be regarded as a form of a structured flowchart combined with a
traditional data flow diagram. Typical flowchart techniques lack constructs for
expressing concurrency. However, the join and split symbols in activity diagrams only
resolve this for simple cases; the meaning of the model is not clear when they are
arbitrarily combined with decisions or loops.

 Activity diagrams are constructed from a limited number of shapes, connected with
arrows. The most important shape types:

 stadia represent actions

 diamonds represent decision
 bars represent the start (split) or end (join) of concurrent activities
 a black circle represents the start (initial node) of the workflow
 an encircled black circle represents the end (final node).

 Arrows run from the start towards the end and represent the order in which
activities happen.
 UML activity diagrams in version 2.x can be used in various domains, e.g.
in design of embedded systems. It is possible to verify such a specification
using model checking technique.

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 13

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 14

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 15

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 16

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 17
 Use Case Diagram
 A use case diagram is a graphical depiction of a user's possible interactions with
a system.
 A use case diagram shows various use cases and different types of users the
system has and will often be accompanied by other types of diagrams as well.
 The use cases are represented by either circles or ellipses.
 The actors are often shown as stick figures.

 While a use case itself might drill into a lot of detail about every possibility, a
use-case diagram can help provide a higher-level view of the system.

 It has been said before that "Use case diagrams are the blueprints for your
system".[1]

 Due to their simplistic nature, use case diagrams can be a good communication
tool for stakeholders.

 The drawings attempt to mimic the real world and provide a view for
the stakeholder to understand how the system is going to be designed.

 Siau and Lee conducted research to determine if there was a valid situation for
use case diagrams at all or if they were unnecessary.

 What was found was that the use case diagrams conveyed the intent of the system
in a more simplified manner to stakeholders and that they were "interpreted more
completely than class diagrams".

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 18

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 19

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 20
 3.2 Data Dictionary
o The terms data dictionary and data repository indicate a more general software utility
than a catalogue. A catalogue is closely coupled with the DBMS software. It provides
the information stored in it to the user and the DBA, but it is mainly accessed by the
various software modules of the DBMS itself, such as DDL and DML compilers, the
query optimiser, the transaction processor, report generators, and the constraint
enforcer.

o On the other hand, a data dictionary is a data structure that stores metadata, i.e.,
(structured) data about information.

o The software package for a stand-alone data dictionary or data repository may
interact with the software modules of the DBMS, but it is mainly used by the
designers, users and administrators of a computer system for information resource
management.

o These systems maintain information on system hardware and software configuration,

documentation, application and users as well as other information relevant to system
administration.

o If a data dictionary system is used only by the designers, users, and administrators
and not by the DBMS Software, it is called a passive data dictionary. Otherwise, it is
called an active data dictionary or data dictionary.

o When a passive data dictionary is updated, it is done so manually and independently

from any changes to a DBMS (database) structure. With an active data dictionary, the
dictionary is updated first and changes occur in the DBMS automatically as a result.

o Database users and application developers can benefit from an authoritative data
dictionary document that catalogues the organization, contents, and conventions of
one or more databases.

o This typically includes the names and descriptions of

various tables (records or entities) and their contents (fields) plus additional details,
like the type and length of each data element.

o Another important piece of information that a data dictionary can provide is the
relationship between tables. This is sometimes referred to in entity-

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 21
relationship diagrams (ERDs), or if using set descriptors, identifying which sets
database tables participate in.

o In an active data dictionary constraints may be placed upon the underlying data. For
instance, a range may be imposed on the value of numeric data in a data element
(field), or a record in a table may be forced to participate in a set relationship with
another record-type.

o Additionally, a distributed DBMS may have certain location specifics described within
its active data dictionary (e.g. where tables are physically located).

o The data dictionary consists of record types (tables) created in the database by
systems generated command files, tailored for each supported back-end DBMS.
Oracle has a list of specific views for the "sys" user. This allows users to look up the
exact information that is needed.

o Command files contain SQL Statements for CREATE TABLE, CREATE UNIQUE

INDEX, ALTER TABLE (for referential integrity), etc., using the specific statement

required by that type of database.

o There is no universal standard as to the level of detail in such a document.

► ADMIN TABLE

Field Name Data Type Size Constraints

adminuser int 20 NOT NULL,

PRIMARY KEY

adminpassword varchar 45 NOT NULL,

PRIMARY KEY

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 22
► SIGNUP TABLE

Field Name Data Type Size Constraints

Form no varchar 20 NOT NULL,

PRIMARY KEY

name varchar 20 NOT NULL

Father_name varchar 20 NOT NULL

dob varchar 20 NOT NULL

gender varchar 20 NOT NULL

email varchar 30 NOT NULL

Marital_status varchar 20 NOT NULL

address varchar 40 NOT NULL

city varchar 25 NOT NULL

state varchar 20 NOT NULL

pincode varchar 20 NOT NULL

► SIGNUPTWO TABLE

Field Name Data Type Size Constraints

formno Varchar 20 NOT NULL

Religion Varchar 20 NOT NULL

Category Varchar 20 NOT NULL

Income Varchar 20 NOT NULL

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 23
Education Varchar 20 NOT NULL

Occupation Varchar 20 NOT NULL

Pan Varchar 20 NOT NULL

Aadhar Varchar 20 NOT NULL

Seniorcitizen Varchar 20 NOT NULL

existingaccount Varchar 20 NOT NULL

► SIGNUTHREE TABLE

Field Name Data Type Size Constraints

Formno varchar 20 NOT NULL

AccountType Varchar 40 NOT NULL

Cardnumber Varchar 50 NOT NULL

Pinnumber Varchar 20 PRIMARY KEY,

NOT NULL

Facility Varchar 100 NOT NULL

Username Varchar 20 NOT NULL

Security Varchar 40 NOT NULL

answer varchar 40 NOT NULL

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 24

► BANK TABLE

Field Name Data Type Size Constraints

Pinnumber Varchar 20 PRIMARY KEY,

NOT NULL

Date Varchar 50 NOT NULL

Type Varchar 20 NOT NULL

amount varchar 20 NOT NULL

► LOGIN TABLE

Field Name Data Type Size Constraints

Formno Varchar 20 NOT NULL

Cardnumber Varchar 50 NOT NULL

pinnumber Varchar 20 NOT NULL

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 25

 3.3 Input Output Design

ATM LOGIN PAGE

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 26

ATM DASHBOARD

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 27

USER SIDE LOGIN PAGE

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 28

USER SIDE HOME PAGE

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 29

USER SIDE DASHBOARD

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 30

ADMIN LOGIN PAGE

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 31

ADMIN SIDE DASHBOARD PAGE

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24

 BANK&ATM
SIMULATOR
Page | 32

USER DETAILS (ADMIN SIDE)

Developed By Mallick Habib BCA Sem-6 of Batch 2023/24