SOFTWARE DESIGN SPECIFICATION

1.0 Introduction

The application is designed using MySQL for database management, Spring Boot for
backend services, and react for frontend user interfaces. It leverages RESTful API
services to facilitate secure and efficient communication between the client and server. I
will be using MVC architecture, and the component level are going to my controller class
which will be getting all the https requests and then sending them to DB class to update
the requests and send back to controller class and then send to render that updating either
success or failure and the controller class update the User Interface.

1.1 Goals and objectives

The goal of this project is to develop a scalable, secure consumer banking

application that allows users to manage their banking profiles, add new profiles,
transactions, and applications for credit cards and loans.

1.2 Statement of scope

The application allows users to manage personal banking accounts, including

checking balances, viewing transaction history, applying for loans and credit
cards, and managing profiles. It provides a modern UI built with React,
communicating with backend services in Spring Boot through RESTful APIs,
while data is stored in a MySQL database.

1.3 Software context

The software is placed in a business line context. The application will be used in a
consumer banking environment where users interact with their banking data in
real-time. It requires high performance for transaction processing and real-time
feedback on applications for loans and credit cards.

1.4 Major constraints

Time Constraint: The application is to be completed within two months.

API Services: Proper design of API contracts is critical to ensure front-end-

backend integration.

Security: The system must securely handle sensitive data through HTTP,
encryption, and authentication.
2.0 Data design

To manage applications and transactions in the banking system, utilize queues; use
linked lists for transaction history; use arrays/lists for user details, account, and
transaction records; and use hash maps for quick lookups. Apply appropriate
foreign key relationships and indexing to MySQL tables for users, accounts,
transactions, applications, and products.

2.1 Data structures

The banking system uses queues for managing applications and transactions,
linked lists for storing transaction history, arrays and lists for storing user
information, account information, and transaction records, and hash maps for fast
lookups.

2.2 Database description

MySQL includes tables with appropriate foreign key associations and indexing for
users, accounts, transactions, applications, and products.

3.0 Architectural and component-level design

The architecture views for banking system using the MVC (Model-View-
Controller) pattern, with queues, linked lists, arrays/lists, and hash maps as the key
data structures. These views focus on different perspectives of architecture:
logical, process, physical, and development.

3.1 Architecture diagrams

Logical View Description: The logical view represents the system’s key
abstractions, such as objects or classes. In our banking system, the entities would
include User, Account, Transaction, Application, Product, etc. The logical view
aligns the requirements with these abstractions, showing relationships such as
inheritance or association between them.

Process View Description: The process view focuses on how the system operates
at runtime, specifically how processes interact with each other. In our banking
system, this includes processes like: Handling user requests via queue. Processing
transactions in real-time or batch mode. Managing loan and credit card
applications asynchronously.

Development View Description: This view breaks down the system into smaller
components for development. In this part each feature (user management, account
management, transactions) is handled by different development teams or
components in the codebase.

Physical View Description: The physical view represents the deployment of

software components across hardware. In our banking system, this would include
how your React frontend and Spring Boot backend are deployed on servers, how
the database is hosted, and how components interact over the network.

3.2 Description for Components

The User Interface (UI), which facilitates user interaction (React frontend), the
Database (MySQL) for storing user, account, transaction, and application data, the
Authentication Module for managing user login and security, and the
Transaction/Queue Engine for processing applications and transactions effectively
are the main software components of the banking system. These components are
part of the architecture and are arranged according to the MVC paradigm. The
View renders user interactions, the Model holds data (lists, arrays, and linked
lists), and the Controllers handle requests between the user interface and the
backend. In addition to using foreign keys and indexing to optimize database
queries, the system makes use of hash maps for fast lookups.

3.2.1 Component n description

3.2.1.1 Interface description

User interface (React Frontend) Input: User actions like login

credentials, account management requests (view balances, make
transactions), and application submissions (loan/credit card applications);

Output: Account details, transaction history, and application statuses

displayed in response to user actions; Backend processing-based error or
success messages.

Exceptions: Invalid user inputs (e.g., incorrect login credentials); failed

transactions; failed data retrieval from the backend; network errors; and
session timeouts.

Transaction/Queue Engine (Backend for Spring Boot) Input: Requests

for transactions (such as money transfers), loan or credit card application
submissions, and account updates.

Output: Verification of completed transactions, updated account balances,

and the approval or rejection of an application.
 Exceptions: include Queue overflows, unsuccessful transactions, invalid
account information, insufficient funds, and backend system errors.

Database (MySQL) Input: SQL queries are used to obtain, change, or

store user, account, transaction, and application data in a database.

Output: User information, account balances, transaction histories (from

linked lists), and application statuses are among the results of inquiries.

Exceptions include failed queries, data integrity errors, database

connection problems, and violations of foreign key constraints.

3.2.3.2 Static models

I have built the Class diagrams as follows

3.2.3.3 Dynamic models

I have created a sequential diagram for dynamic models.

 3.3 External Interface Description

User Interface (React Frontend): Communicates with the backend via RESTful
APIs over HTTP, handling user inputs and displaying responses (e.g, account
details, transactions).

Backend (Spring Boot): Exposes APIs for the frontend and interacts with
external services (e.g, payment gateways, credit checks) via HTTP and third-party
APIs.

Database (MySQL): Accessed by the backend using JDBC or JPA to manage

data (users, accounts, transactions) and return query results or updates.

4.0 User interface design

The banking system's user interface (UI) is made for easy user interaction,
guaranteeing smooth transitions between various services like account
management, transactions, and application submissions. Constructed with React,
the user interface prioritizes clarity, reactivity, and accessibility to give users a
straightforward and safe experience.

4.1 Description of the user interface

//Add pictures here

A description of user interface including screen images or prototype is presented.

4.2 Interface design rules

Login Screen: Allows users to enter credentials and authenticate.

Dashboard: Displays account balances, recent transactions, and navigation to other

services.

Transaction History: Shows a detailed list of past transactions (from a linked list)
with filtering options.

Application Form: Users can submit applications for loans or credit cards using a
simple, step-by-step form.

5.0 Restrictions, limitations, and constraints

Security Requirements: Tight security measures need to be implemented, particularly

for user authentication, transaction processing, and data privacy.
Performance: Using queues to manage large transactions and application volumes may
lead to performance limitations.

Scalability: For the system to handle an increasing volume of users and transactions,
scalable infrastructure is required.

6.0 Appendices

Presents information that supplements the design specification.

6.1 Requirements traceability matrix

A matrix that traces stated components and data structures to software

requirements is developed.

6.2 Implementation issues