Escolar Documentos
Profissional Documentos
Cultura Documentos
PROBLEM DEFINITION:
Page 1 of 48
CORE BANKING
SRS Document
Page 2 of 48
CORE BANKING
be developed. SRS should accurately and completely represent the
system requirements.
ARCHITECTURAL PATTERN
Page 3 of 48
CORE BANKING
Model-View-Controller
Page 4 of 48
CORE BANKING
possible, the model objects should be developed so that they
have no knowledge of the environment. This allows us to
more easily reuse them across environments and applications.
What is Model-View-Controller?
Let’s start by looking at how the Model, the View, and the Controller
interact with one another:
Page 5 of 48
CORE BANKING
As you can see from the above diagram, the user interacts with the
Controller components (usually represented by Servlets) by
submitting requests to them. In turn, the Controller components
instantiate Model components (usually represented by JavaBeans or
other similar technology), and manipulate them according to the
logic of the application. Once the Model is constructed, the
Controller decides which View (usually represented by Java Server
Pages) to show to the user next, and this View interacts with the
Model to show the relevant data to the user.
DESIGN PATTERN
DESIGN PATTERN
Page 6 of 48
CORE BANKING
Context
Problem
Such disparate data sources offer challenges to the application and can
potentially create a direct dependency between application code and data
access code. When business components-entity beans, session beans, and
even presentation components like servlets and helper objects for Java
Server Pages (JSP) pages --need to access a data source, they can use the
appropriate API to achieve connectivity and manipulate the data source.
But including the connectivity and data access code within these
components introduces a tight coupling between the components and the
data source implementation. Such code dependencies in components
make it difficult and tedious to migrate the application from one type of
data source to another. When the data source changes, the components
need to be changed to handle the new type of data source.
Forces
Portability of the components is directly affected when specific
access mechanisms and APIs are included in the components.
Page 7 of 48
CORE BANKING
Components need to be transparent to the actual persistent store or
data source implementation to provide easy migration to different
vendor products, different storage types, and different data source
types.
Solution
• Business Object
• DataAccessObject
• Transfer Object
Page 8 of 48
CORE BANKING
This represents a Transfer Object used as a data carrier. The
DataAccessObject may use a Transfer Object to return data to
the client. The DataAccessObject may also receive the data
from the client in a Transfer Object to update the data in the
data source.
Consequences:
Enables Transparency
Business objects can use the data source without knowing the
specific details of the data source's implementation. Access is
transparent because the implementation details are hidden inside
the DAO.
Because all data access operations are now delegated to the DAOs,
the separate data access layer can be viewed as the layer that can
isolate the rest of the application from the data access
implementation. This centralization makes the application easier to
maintain and manage.
Page 9 of 48
CORE BANKING
Purpose
The generated application is the first version upon the system. The
overall system is planned to be in the formal of distributed
architecture with homogeneous database platform. The purpose of
Core banking applications helps integrate the enterprise to existing
in-house applications to offer a single customer view. These
applications provide automation across multiple delivery channels.
Project Synopsis
Page 10 of 48
CORE BANKING
Technical Descriptions
GUI:
Page 11 of 48
CORE BANKING
The managers and non-manager staff (cashier) user
interface helps the respective actors in transacting with
the actual information as per their necessities with
specific to the required services. The GUI’s restrict the
ordinary users from miss manipulating the systems
data, which can make the existing system non-
operational. The information with specific to their
personal standards and strategies can be changed
through proper privileges.
Server:
For Executing any kind of web application in
computer tomcat Server is required.
Technologies :
1) JDBC
2) SERVLET
3) JSP
4) STRUTS
1) JDBC:-
Page 12 of 48
CORE BANKING
Any kind of java program can communicate with any
kind of database from a standard manner using JDBC
As java is mostly used in business applications , it
should be able to communicate with database.
Database (DBMS) can understand only SQL & java
knows only method call. To communicate between
them JDBC approach is required.
Driver:
It is precreated software developed according to the
JDBC specification . Driver implements JDBC API.
Types of Driver
2)SERVLET:
Page 13 of 48
CORE BANKING
It is a web technologies & also a web component . A servlet is
a dynamic web resources in a web application. A servlet produces
dynamic web content. A servlet contain JAVA code & HTML code.
1) Init()
2) Service()
3) Destroy()
4) getSevletConfig()
5) getServletInfo()
instance.
Servlet life-cycle :-
1) Instantiation phase
2) Initialization phase
3) Servicing phase
4) Destruction phase
3) JSP
Page 14 of 48
CORE BANKING
1) Scripting elements
2) Directives
3) Actions
1) Scripting elements:-
These are the Jsp elements embedded java
code into jsp. There are 3 kinds of scripting element.
1) Declaration
2) Expression
3) Scriptlet
2) Directives:-
Page 15 of 48
CORE BANKING
3) Actions:-
Page 16 of 48
CORE BANKING
Admin
Manager
Cashier
Customer
Admin: He is the user who interacts all the modules of the system.
Customer : He interacts only with I-Banking module apart from the login
Modules:
Page 17 of 48
CORE BANKING
integrates itself with the other modules like the Administrator
module and Cashier module that are provided by the organization.
This module acts as a major integrator with customer’s
transactions and the requests for approvals that are raised by the
Cashier.
Administrator
Page 18 of 48
1.2Verify
Login Details Validation Data
CORE BANKING
casheir
1.1Accept UserName,
Password
1.2Verify Details
Validation Data
Page 19 of 48
CORE BANKING
Login
Data Store
Process
View
customerdetails/viewb
alance
Staff
1.1
Page 20 of 48
Login
CORE BANKING
Process
customer
1.2Verify Details
Validation Data
Page 21 of 48
CORE BANKING
Login
Page 22 of 48
CORE BANKING
Joining_Dat Category
ee
Branch
Emp_ Addr
Id Phon
e
Register_Of_Employee
Dept_n
o Re
gis
E- Sal ter
mail s
Message Corporate_Details
To_Add
r
Subject Vie
w&
Messages Sen
d
From_Add
r
Date_Of_Gen Page 23 of 48
CORE BANKING
1) Actor: Admin
The Admin module consists of the following services:
1) Login
2) Create new Account types
3) Adding new Branch
4) Registering a new Employee
5) View Employees information
6) Change profile
7) Change Employee designation
8) Change branch details
9) Change Account Type details
10) Send message
11) View message
12) Block/Remove Employees
13) View account type Details
14) View branch details
15) Logout
Login:
Page 24 of 48
CORE BANKING
In this process, Admin enters his username (i.e. his
empid), password and submitted details are verified at the
server side. If he is authorized, then only he is presented with
his remaining services otherwise his access is denied
Page 25 of 48
CORE BANKING
Page 26 of 48
CORE BANKING
This service of Admin allows him to add a new branch. If any new
branch comes into existence then the relevant information (such as
Branch Id, Branch Name, Location, Address, Pin code and Contact
number) is entered into the system by him.
View Employees:
Using this process, Admin can view employee detail like his
personal profile as well as other details related to organization.
Change profile:
In this process, Admin can edit his own profile like his telephone
number, Email and address.
Page 27 of 48
CORE BANKING
This service enables Admin to change the cadre of an employee
incase of any change in the designation or department. Here, the
Admin is displayed with a list of employee ids available in the
database and by selection of any particular employee, his details
are displayed so that Admin is allowed to change the designation to
the required status. This change is further updated in the
backend by the use of appropriate operations. The output will be
either successor failure of the transaction
Page 28 of 48
CORE BANKING
Page 29 of 48
CORE BANKING
Send messages:
.
View messages:
This privilege lets the Admin to view the messages that are
in his inbox.
Block/Remove employees:
This service helps the Admin to view the branch details based
on requirement. The branch details like branch id, location,
address, phone
Page 30 of 48
CORE BANKING
This service helps the Admin to view the account type details
based on
requirement. The account details like minimum balance,
account name,
interest, period of the account type that is requested are
displayed.
• Logout:
Page 31 of 48
CORE BANKING
2) Actor --Cashier
1) Login
2) Change profile
3) Create account
4) View account details
5) Deposit
6) Withdrawal
7) View balance
8) Transfer amount Details
9) Generate a/c stmt
10) View messages
11) Send messages
12) Logout
• Login:
• Change profile:
Page 32 of 48
CORE BANKING
In this process, Cashier enters all the customer details that are
required to create the account such as account details, personal
details, account options, account nominee details and the account
additional information. Incase he gets any request for opening a
new account by the customer then that will also be collected and
the request is forwarded to Manager for approval. After the
approval of account the account number that is auto generated by
the system is used to identify the customer’s account for any
further transactions.
Page 33 of 48
CORE BANKING
View Account Details:
With this service, the Cashier has the privilege to view the account
details of each customer who has an account and based on these
details other transactions like deposit, withdrawal etc are
processed.
Deposit:
Withdrawal:
Page 34 of 48
CORE BANKING
View Balance:
Page 35 of 48
CORE BANKING
Page 36 of 48
CORE BANKING
• Send messages:
Page 37 of 48
CORE BANKING
View messages:
Logout:
Page 38 of 48
CORE BANKING
3) Actor: Manager
The Manager module consists of the following services:
1) Login
2) Change profile
3) Approve/Reject Account
4) Send Messages
5) View Messages
6) View account type Details
7) View employee Details
8) View branch details
9) View Customer account details
10) Closing an account
11) Logout
• Login:
• Change profile:
In this process, Admin can edit his own profile like his telephone
number , Email and address.
Approve/Reject Account:
Manager is the only one who has the authority to either accept or
reject the customer’s account based on the organization’s terms
and conditions, since he is a decision maker for whole financial
system.
Page 39 of 48
CORE BANKING
Page 40 of 48
CORE BANKING
Send messages:
Page 41 of 48
CORE BANKING
View messages:
This privilege lets the Manager to view the messages that are in his
inbox.
Page 42 of 48
CORE BANKING
Page 43 of 48
CORE BANKING
Closing an account:-
• Logout:
Page 44 of 48
CORE BANKING
4) Actor: Customer
The Customer module consists of the following services:
1) Registration
2) Login
3) View account details
4) Change profile
5) Request to change account type/branch/account options
6) View account statement
7) Transfer amount details
8) Send Messages
9) View Messages
10) Logout
• Registration:
Page 45 of 48
CORE BANKING
• Login:
• View Balance:
• Change Profile:
Page 46 of 48
CORE BANKING
Page 47 of 48
CORE BANKING
• Send messages:
• View messages:
Page 48 of 48