Report On Restaurant Recommendation

Dissertation on
“Recommendation System”
Submitted in partial fulfillment of the requirements for the award of degree of
Bachelor of Technology
in
Computer Science & Engineering
Submitted by:
Deepika Kovi 01FB15ECS090
Gadamsetty Rohith 01FB15ECS100
Omkar D 01FB15ECS198
Under the guidance of
Internal Guide
Mahesh H B
Associate Professor,
PES University
January – May 2019
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

FACULTY OF ENGINEERING
PES UNIVERSITY
(Established under Karnataka Act No. 16 of 2013)
100ft Ring Road, Bengaluru – 560 085, Karnataka, India

PES UNIVERSITY
(Established under Karnataka Act No. 16 of 2013)
100ft Ring Road, Bengaluru – 560 085, Karnataka, India
FACULTY OF ENGINEERING
CERTIFICATE
This is to certify that the dissertation entitled
‘Recommendation System’
is a bonafide work carried out by
Deepika Kovi 01FB15ECS090

Gadamsetty Rohith 01FB15ECS100
Omkar D 01FB15ECS198
In partial fulfilment for the completion of eighth semester project work in the Program of Study
Bachelor of Technology in Computer Science and Engineering under rules and regulations of
PES University, Bengaluru during the period Jan. 2019 – May. 2019. It is certified that all
corrections / suggestions indicated for internal assessment have been incorporated in the
report. The dissertation has been approved as it satisfies the 8 th semester academic
requirements in respect of project work.
Mahesh H B Dr. Shylaja S S Dr. B K Keshavan

Associate Professor Chairperson Dean of Faculty
External Viva
Name of the Examiners Signature with Date
1. __________________________ __________________________
2. __________________________ __________________________
DECLARATION
We hereby declare that the project entitled “Recommendation System” has been carried out
by us under the guidance of Prof. Mahesh H B, Associate Professor, and submitted in partial
fulfillment of the course requirements for the award of degree of Bachelor of Technology in
Computer Science and Engineering of PES University, Bengaluru during the academic
semester January – May 2019. The matter embodied in this report has not been submitted to
any other university or institution for the award of any degree.
01FB15ECS090 Deepika Kovi

01FB15ECS100 Gadamsetty Rohith
01FB15ECS198 Omkar D
ACKNOWLEDGEMENT
We would like to express my gratitude to Prof. Mahesh H B, Dept. of Computer Science, PES
University, for his continuous guidance, assistance and encouragement throughout the
development of this project.
We are grateful to the project coordinators, Prof. Preet Kanwal and Prof. Sangeeta V I, for
organizing, managing and helping out with the entire process.
We would also like to take this opportunity to thank Dr. Shylaja S S, Chairperson, Department
of Computer Science and Engineering, PES University, for all the knowledge and support we
have received from the department.
We would like to thank Dr. B.K. Keshavan, Dean of Faculty, PES University for his help.
We would like also like to thank Dr K N B Murthy, Vice Chancellor PES Institutions for his
continuous encouragement and motivation.
We would also like to extend our sincerest gratitude to Prof Jawahar Doreswamy, Pro
Chancellor, PES Institutions for his inspirational dedication and support to all activities
associated with PES.
We would like to thank Dr M R Doreswamy, Chancellor, PES Institutions for his enormous
support and motivation.
Finally, this project could not have been completed without the continual support and
encouragement we have received from our parents.
ABSTRACT
The goal of this project is to develop a web application that can be used by the users to get a
recommendation for themselves based on their specification. The users will be given a
recommendation of a few places to visit for a location on their weekend or days they have
planned with a hotel to stay near the location they are visiting and a restaurant to eat according
to their rating near their stay of location. Basically our recommendation system minimizes the
search for three different things like for location, hotel and restaurant to one system which is
ours. The system is designed such a way that it is user-friendly and minimizes the work for the
end user.
TABLE OF CONTENTS
1. INTRODUCTION 1
1.1 Recommendation System 1
1.2 Motivation 1
1.3 Scope 2
2. PROBLEM DEFINITION 4
2.1 Problem Statement 4
3. LITERATURE SURVEY 5
3.1. Credit Risk Modeling: Combining Classification and Regression Algorithms to Predict
Expected Loss 5
3.1.1. Introduction 5
3.1.2. Approach 5
3.1.2. Results & Conclusion 6
3.2. Credit Default Mining Using Combined Machine Learning and Heuristic Approach 6
3.2.1. Introduction 6
3.2.2. Approach 7
3.2.3. Results & Conclusion 7
4. PROJECT REQUIREMENTS SPECIFICATION 8
4.1 Customer Requirements 8
4.2 Dependencies 9
5. SYSTEM REQUIREMENTS SPECIFICATION 10
5.1 Requirements 10
5.1.1 Software Requirements 10
5.1.2 Hardware Requirements 10
5.2 Assumptions 11
6. HIGH LEVEL DESIGN 12
6.1. System Architecture 12
6.1.1. Web Application (the Frontend) 12
6.1.2. Web Server (the Backend) 13
6.1.3. Machine Learning Model 13
6.2. Design Description 14
6.3. Use Case Diagram 14
6.3.1. Use Case Descriptions 15
6.4. Class Diagram 16
6.4.1. Class Description 16
6.5. Sequence Diagram 17
6.6. Activity Diagram 18
6.7. ER Diagram 19
6.7.1. Entity Descriptions 19
6.8. User Interface Diagrams 19
6.8.1. Index Screen 20
6.8.2. Home Screen 20
6.9. External Interfaces 20
6.9.1. User APIs 20
6.9.2. Prediction APIs 21
6.10. Packaging and Deployment Diagram 21
6.11. Help 22
6.12. Alternate Design Considerations 22
6.12.1. Django 22
6.12.2. NodeJS 22
7. LOW LEVEL DESIGN 24
7.1. Design Description 24
7.1.1. User 24
7.1.2. Prediction 24
7.1.3 Front End Organization 25
8. IMPLEMENTATION AND PSEUDOCODE 26
8.1. Frontend 26
8.1.1 Material Design 26
8.1.2 Components 26
8.1.3 Services 27
8.1.4 JSON Web Token 29
8.2. Backend 29
8.2.1. JSON Web Token 30
8.2.2. MongoDB 31
8.2.3. Error Handling 31
8.2.4. Integration Tests 31
8.3. Model 32
8.3.1. Data Preprocessing 32
8.3.2. Gradient Boosted Trees 33
8.3.3. K-Fold Cross-Validation 33
8.3.4. Hyperparameter Optimization 33
8.4 Tools and Technologies 34
8.4.1 Web FrontEnd 34
8.4.2 Web Backend 34
8.4.3 ML Model 34
9. TESTING 35
9.1. Scope 35
9.2. Test Strategies 35
9.3. Performance Criteria 36
9.4. Testing Environment 36
9.4.1. Hardware 36
9.4.2. Software 36
9.5. Risk Identification and Contingency Planning 36
9.6. Roles and Responsibilities 37
9.7. Test Schedule 37
9.8. Test Tools 37
9.9. Acceptance Criteria 37
9.10. Test Case List 38
10. RESULTS AND DISCUSSION 39
11. SNAPSHOTS 40
12. CONCLUSIONS 45
13. FURTHER ENHANCEMENTS 46
14. REFERENCES 47
BIBLIOGRAPHY 48
APPENDIX A 49
APPENDIX B 50
LIST OF FIGURES
# Name Page
6.1. System Architecture 12
6.2. High Level Design 14
6.3. Use Case Diagram 15
6.4. Class Diagram 16
6.5. Sequence Diagram 17
6.6. Activity Diagram 18
6.7. Entity Relationship Diagram 19
6.8. Packaging 22
8.1.1. Component Usage 27
8.1.2. Service Usage 28
8.1.3. Token header 29
8.1.4. Token header field passed in http request 29
8.2.1. Example backend API 30
8.2.1.1. JWT usage 30
8.2.1.2. JWT decoding 30
8.2.1.3. JWT encoding 31
8.2.2.1. MongoDB find command 31
8.2.2.2. MongoDB remove command 31
8.2.3.1. Error code example 31
8.2.4.1. Login test 32
8.3.1.1. Removal of spurious data 32
8.3.1.2. Imputation and scaling of data 32
8.3.2.1. Gradient boosted trees working 33
8.3.3.1. K-fold cross-validation 33
8.3.4.1. Hyperparameter optimization output 34
11.1. Index page 40
11.2. Password length validation 40
11.3. Login input validation 41
11.4. Valid login example 41
11.5. Prediction input screen 42
11.6. Prediction output screen 43
11.7. Past predictions 43
11.8. Delete prediction 44
LIST OF TABLES
# Name Page
4.1. Customer requirements specification 8
6.1. Use case descriptions 15
6.2. Entity descriptions 19
6.3. User APIs 20
6.4. Prediction APIs 21
7.1. User class data members 24
7.2. User class methods 24
7.3. Prediction class data members 25
7.4. Prediction class methods 25
9.1. Test strategies 35
9.2. Testing environment hardware 36
9.3. Testing environment software 36
9.4. Risk Identification 36
9.5. Roles and responsibilities 37
9.6. Test case list 38
CHAPTER-1
INTRODUCTION
1.1 Recommendation System

A Recommendation system is basically a system which takes the end user information or
specifications on a particular product or item or place and predict a rating or preference the end
user would like or would give to a product.
1.2 Why Recommendation System?

As we know this a developing world and nowadays we search for everything online or we get
most of the things online too. The exploding information for questions like “What are good
rated Restaurants?” “What City can I visit?” have many individual answers to them online.
So the consumers and end users have a varied amount of options to choose from which may
make it difficult for them to choose the suitable item or location. So for this it is necessary to
personalize and filter it according to the end user. So the recommendation systems are those
which provide us suggestions based on the end user specifications.
Traditionally there are two recommendation systems

1) Content-based recommendation
2) Collaborative recommendation
Content based recommendation is analyzing the nature of an item or product whereas a

collaborative recommendation is based on user or the item. Our project uses collaborative
filtering as it takes the end users specification without any historical data requirement.
In collaborative filtering a user expresses his or her preferences by rating items (e.g. hotels,
restaurants) of the system. These ratings can be viewed as an approximate representation of
the user's interest in the corresponding domain.
The system matches this user's ratings against other users' and finds the people with most
"similar" tastes.
Dept of CSE Jan - May 2019 1

Recommendation System
There are types of Collaborative Filtering

 Item-based
 User-based
 Memory-based
 Model-based
 Hybrid
1.3 Scope
The report for this project has been organized into thirteen chapters. This chapter gives a brief
introduction to the project. It discusses what a recommendation system is and the motivation
behind the project.
Chapter 2 defines the problem that we are trying to solve.
Chapter 3 gives a brief summary of the work that has been done in the domain so far.
Chapter 4 defines the requirements from the point of view of the customer.
Chapter 5 defines the system requirements, namely the hardware and software requirements.
Chapter 6 describes the design of the project at a high level.
Chapter 7 describes the low level details of the implementation of the project.
Chapter 8 focuses on implementation details and the salient features of the project.
Chapter 9 describes the testing plans and process undertaken for this project.
Chapter 10 lays down the results and outcomes of this project.

Chapter 11 includes a few snapshots of the project.
Chapter 12 deals with the conclusion of the project.
Chapter 13 discusses about the future enhancements that are possible for the project.
Chapter 14 lists the resources we have used while developing the project and preparing the
report.

CHAPTER-2
PROBLEM DEFINITION
A recommendation system for three different features mainly places to visit, Hotels to stay and
restaurants to eat.
As we have already seen in the introduction chapter that an end user has to search for different
places or websites for the main features to go for a travel so for minimizing the work we are
providing a recommender system which allows the end user to search for hotel or restaurant
they want to visit by which the recommendation system will later provide them with the
specifics.
2.1 Problem Statement

The objective is to provide a web application that will enable users to enter a few attributes
related to the place they want visit and their current location. This prediction is based on
Collaborative filtering approach.
This will help the end users to pick a perfect location to visit for their travel with the places
they can visit which are nearby to that location and some good restaurants and hotels to stay
and eat.

CHAPTER-3
LITERATURE SURVEY
3.1. Credit Risk Modeling: Combining Classification and Regression

Algorithms to Predict Expected Loss
3.1.1. Introduction
This paper states that credit scoring, which is the numerical evaluation of the risk of credit
default, is and important first step in the reduction of credit risk and mentions how it has been
proven to be highly effective. The authors go on to state that the main goal of credit scoring is
to predict the expected loss (EL), which is defined as follows:
EL=PD*LGD*EAD
Here, PD is the probability of default, meaning how likely the borrower will not be able to
(fully) pay back the loan; LGD is the loss given default which is defined as the part of the loan
the lender will be unable to recover; and EAD refers to the exposure at default which is simply
the amount of money at risk.
The authors discuss how previous research in this field has mainly focussed on the calculation
of PD, which is arguably of high importance. The authors propose that the second parameter,
LGD, will help in gaining a more nuanced picture of credit risk.
3.1.2. Approach
The paper first compares the dataset being used with others that have been used in previous
research. The dataset in questions contained many more attributes (~750 vs ~30) and a much
larger number of rows (~100000 vs ~1000).
The preprocessing of the data involved first imputing the missing values with column means
since most algorithms are unable to handle missing data, and then scaling the data.
The paper chose to go with the F1 metric for benchmarking purposes.
F1 = (2 * recall * precision) / (recall + precision)
Where

recall = TP / (TP + FN)

precision = TP / (TP + FP)
TP (True Positives) being the number of observations correctly identified as loan defaults.
Similarly FP is the sum of false positives and FN the sum of false negatives.
The paper then goes on to document that feature selection was performed in order to improve
prediction accuracy while reducing computational costs. The method used was L1-based
feature selection.
Finally, the authors discuss which machine learning techniques they used, namely Logistic
Regression, Support Vector Classification and Stochastic Gradient Boosted Tree
Classification.
3.1.2. Results & Conclusion

As a baseline, the authors used a naive strategy of simply guessing that every observation’s
target is 0 (i.e., will not default). From the F1 scores, the authors concluded that the BT
technique seemed to perform the best. They also noticed that, in general, L1 feature selection
resulted in better results. The authors were surprised to find out the performance gap between
the linear models, which were barely able to keep up with the naive strategy, and the non-linear
one.
3.2. Credit Default Mining Using Combined Machine Learning and

Heuristic Approach
3.2.1. Introduction
The paper states that traditional statistical techniques are unable to handle large amounts of
data and are not very successful in modelling the dynamic nature of fraud. The authors also
mention that analyzing millions of transactions and making a prediction based on that is
resource intensive and sometimes error prone.
The authors suggest the combination of OLAP (Online Analytical Processing) which is done
on archived historical data, and OLTP (Online Transaction Processing) which is performed on
current transactions.

The paper mentions that while techniques such as KNN, SVM, etc. are commonly used, the
Extremely Randomized Trees method has often been ignored. In contrast to the regular
Random Forest method, Extremely Random Trees determine the splitting attribute in an
extremely random manner.
3.2.2. Approach
The paper follows two approaches- one being the standard approach of using different machine
learning algorithms on the dataset, and the other, which it calls the Heuristic Approach, that
involves combining the score from the archived data along with a certain heuristic used in real-
time.
The authors opted to go with the “Taiwan” dataset which contains 23 features and 30000
instances (22% of which are default cases).
The metrics used to evaluate the models were the accuracy, recall, F1 score and precision.
Machine learning algorithms used include KNN, Naive Bayes, Random Forest and Extremely
Random Trees.
3.2.3. Results & Conclusion

The authors discovered that the Extremely Random Trees algorithm outperformed all the other
ones used in terms of accuracy, F1 score, recall and precision. The paper attributes this
observation to the fact that tree-based methods usually work well in cases where the number
of features is moderate and the dataset contains very little missing values. They also noticed
that though Naive Bayes was a bit faster, its performance with respect to the aforementioned
metrics was nowhere nearly as good when compared to Extremely Random Trees.
The authors then go on to compare previously achieved results on the same dataset, with their
own in which they used the previously mentioned heuristic approach, and found out that the
results were significantly better (~93% accuracy vs 84%). The recall percentage was also better.

CHAPTER-4
PROJECT REQUIREMENTS SPECIFICATION
This section of the document will explain the system’s salient features, the interfaces of the
system, what the system will do, the constraints that the system can be subjected to during the
normal run of the system
4.1 Customer Requirements
Reqmt
Requirement
#
The user should be able to give inputs based on their

CRS – 1
requirements.
Generate a recommendation. The inputs will be taken from

CRS – 2 the user and the recommended restaurant or hotel will be
shown.
The customer must be able to give a location for suggesting

CRS – 3
the restaurants.
The end user will input for coast they want to visit and the
CRS- 4
ratings they would prefer for the results.
The user will input a place they would like to visit and the
CRS- 5 system will recommend the places they can visit near the
location.
Table. 4.1. Customer requirements specification

4.2 Dependencies
The project is dependent on the Collaborative filtering method which can be called as social
filtering. It predicts or assumes what the user might agree for in the future without any
historical data required.

CHAPTER-5
SYSTEM REQUIREMENTS SPECIFICATION
Since our system is based on the collaborative filtering, the system requirements for the end
user are very minimal.
5.1 Requirements
5.1.1 Software Requirements

Operating System -
● Windows 7 or later
● Anaconda Package installed
5.1.2 Hardware Requirements

● Processor : Intel Pentium 4 processor or later that’s SSE2 capable
● RAM : 4GB or more
● Hard Disk : 250 GB or more
● Network : Wired or wireless

End User
User Location
Search Restaurants
Recommendation System Nearby
Take User
Preferences
Take data Via
API
5.2 Assumptions
● The client has an active internet connection to send requests and receive responses from
the server.
● The client has a working computer machine that satisfies the above mentioned software
and hardware requirements.
● The user knows all the values to be provided as input for the recommendation.

CHAPTER-6
HIGH LEVEL DESIGN
6.1. System Architecture
Fig. 6.1. System Architecture
The application can be divided into three major, independents modules:
6.1.1. Web Application (the Frontend)

This is the interface with which the user interacts. The main focus of this module is simplicity
in order for the user to have an easy time navigating through the site.
A modern, material design is used for a clean yet responsive website. Written in Angular, a
modern Javascript UI framework, it handles the styling, reactivity, and the requesting of
information (via API requests) from the backend.
The pages of the website are split into components that are very similar to templates. Each
component will have a service if it has to communicate with the server either for fetching data
from the server or for sending data to the server and updating data.
The web user interface will make use of the HyperText Transfer Protocol to communicate with
the server.

6.1.2. Web Server (the Backend)

This is the layer that provided the frontend with the necessary information. Designed with a
RESTful architecture in mind, it receives API requests and satisfies them by either performing
some sort of local task, querying the database, or by invoking the trained model as necessary.
Written using Flask, a contemporary Python web server framework, it handles functionality
such as login & registration, generating predictions in conjunction with the machine learning
model, saving and retrieving user predictions, etc.
The Web server consists of RESTful APIs. REST stands for Representational State Transfer.
It is an architectural style. It defines a set of constraints that can be used for creating Web
Services.
REST specifies the following constraints :
1. The architecture must be client-server based.
2. All operations must be stateless.
3. Clients must have an ability to cache server responses.
4. The server must have a layered architecture.
5. All modules must have a uniform interface so that they can evolve independently.
The web backend consists of API endpoints for :
1. User Management - This includes user login and registration. There is also another
resource that will check if the username entered is unique.
2. Prediction Management - This includes generating a prediction, saving a prediction and
deleting a prediction.
The web backend uses MongoDB as the database to store user information and past prediction
information and the predicted values. The backend will directly communicate with the
database.
6.1.3. Machine Learning Model

The model is made trained in advance in order to be ready to satisfy real-time requests from
the frontend. Using modern machine learning algorithms, it has been tuned to give as high
accuracy as possible. Via the middle layer (the server), it receives a set of attribute-value pairs
which it then convert into a prediction of how likely the user will default on the loan he/she has
taken. Written in Python, the model uses a new and upcoming technique known as gradient
boosted trees.

6.2. Design Description
Fig.6.2 High Level Design
The above high level design diagram gives a slightly detailed overview of our application. It
mentions the potential users of our application, their actions, the organization of the system
into layers. The components that make up each layer and their interaction.
6.3. Use Case Diagram

In software and systems engineering, a use case is a list of actions or event steps, typically
defining the interactions between a role and a system, to achieve a goal.

Fig.6.3. Use Case Diagram
The above figure portrays the the behavior and functionality provided by the application, by
depicting the actors (end user and administrator) and use cases (Registration, Train the model,
etc.).
6.3.1. Use Case Descriptions
Use Case Item Description

User Registration A user who wishes to use our web application to
generate prediction will have to first register
themselves by providing details such as username,
password and an email id.
Login A registered user who wishes to generate a prediction
must first login to receive a token that he/she will send
along with future requests to the backend.
Generate Prediction A user will provide input necessary to generate a
prediction and then generate a prediction. The system

will provide as output a prediction whether the person

will default or not on their loan repayment.
Save Prediction A user who has generated a prediction can choose to
save the prediction which can be modified later to
generate another prediction.
Delete Prediction A user who has saved a prediction can choose to delete
it at a later time.
Table. 6.1. Use case descriptions
6.4. Class Diagram
Fig.6.4 Class Diagram
The above figure is a class diagram depicted using the Unified Modeling Language (UML). It
indicates the structure of the system by showing its classes along with their attributes,
operations and relationships.
6.4.1. Class Description

● User Class
○ Represents a user of the application
○ Contains data members to store user details required for authentication such as
username, email address, password
○ Contains methods to create a new user in the system, delete a user and modify
user information
● Prediction Class
○ Represents a prediction instance requested by a user

○ Contains data members to store dataset attributes (e.g. OWN_CAR_AGE) and

a field to store the prediction (whether the user will default or not)
○ Contains methods to create a new prediction, to delete a prediction, and to
modify the fields in the prediction.
There exists a one-to-many relationship between user and prediction. Each user can make n
number of predictions and can save them if he wishes to. Each saved prediction is associated
with a specific user. No prediction can exist without being associated with a user. A user can
exist without saving any prediction and it’s details.
6.5. Sequence Diagram
Fig.6.5. Sequence Diagram
The above diagram shows object interactions in chronological order. It depicts the sequence of
messages exchanged between objects which are needed to carry out the functionality in the
shown scenario. For the use case of generate a prediction, the above diagram shows the
sequence of steps and interaction between the different components of the system.

6.6. Activity Diagram
Fig.6.6 Activity Diagram
The above figure represents the activity diagram depicted using the Unified Modeling
Language (UML). This diagram exhibits the dynamic aspects of the system. It depicts the flow
from one activity to another.
Barring registration, a user will have to be logged in to perform any other activity. Once logged
in, a user can choose to enter values, generate a prediction and save it if they wish, or they can
view past predictions that have been generated by them and can choose to delete one of their
choice.

6.7. ER Diagram
Fig.6.7 Entity Relationship Diagram
The above Entity-Relationship model is composed of entity types (User, Prediction) and
specifies the relationships that can exist between them. It defines the information structure
which is later used during the database implementation. Since the database being used is a
NoSQL one, attributes here is a JSON object with the various fields as its keys.
6.7.1. Entity Descriptions
# Entity Name Definition Type

ENTITIES
1. User User Details of a user
2. Prediction Prediction Details of a
prediction
# Attribute Name Definition Type (size)
DATA ELEMENTS
1. User.username username Unique identifier string
2. eUser.email email E-mail address string
3. User.password password Account password string
4. Prediction.id id Unique identifier number
5. Prediction.attributes attributes JSON containing json
the attribute names
and corresponding
values
7. Prediction.repaid repaid Prediction boolean
Table 6.2. Entity descriptions
6.8. User Interface Diagrams

The screens present in the application are described below:

6.8.1. Index Screen

This page has a logo that identifies our web application. It includes a tab based menu that
provides options for registering themselves as a user or for logging in. The username for each
user is a unique field. An asynchronous request will be made as soon as the user enters the
username to verify that the username is available and not taken by a different user. Dynamic
validation of the fields of the form are made to ensure wrong data is not sent to the server. Eg
- The password should be of a minimum of 8 characters in length. The email field is verified
to match the pattern of an email address. The password length validation is done for both the
login and registration tabs.
This screen satisfies the customer requirement CRS-1: User Login and Registration
6.8.2. Home Screen

This page will provide the interface for the user to provide as input the necessary information
required to generate a prediction. The input will be taken from a modal that will pop up on the
click of a button. The page will also display the user’s past predictions with a few attributes
shown and the predicted target variable. A side nav bar will also be present to provide the user
option to logout. After the prediction is generated, it will provide an option to save the
prediction to the user.
This screen satisfies the customer requirements CRS-2 and CRS-3 that specified generating a
prediction and saving a prediction.
6.9. External Interfaces

The backend, which follows the RESTful design principles, is composed of the following APIs:
6.9.1. User APIs

Name Type Description
/api/users/usernameExi GET Takes a string as a path parameter (username). Queries

sts/{username} the database to check for documents that have the same
username. Returns http status code 200 if no such
document is found. Returns http status code 409 if such a
document exists in the collection to denote conflict.
/api/users/register POST Takes as input a user object with the fields - username,
email id and password, all of which are string fields.
This API will query the database to check if the email-id
is already associated with another account. If such a
document is found, a http status code of 409 is sent to
denote conflict. If no such document is found, a new

document is created with the provided input fields and a

http status code of 200 is sent back as response.
/api/users/login POST Takes as input an object with fields - username and

password both of which are string fields. This API will
query the database using the username and checks if the
password entered matches. If true, a status code of 200 is
sent along with a JSON Web Token that will
authenticate further requests made by the user. Else, a
http status code of 403 is sent that denotes Forbidden.
Table 6.3. User APIs
6.9.2. Prediction APIs
Name Type Description
/api/predictions/generate POST This API will take an object with input fields that
are necessary to generate a prediction. This will in
turn be fed to the machine learning model to
generate a prediction. The output of this API will
be the request body along with the predicted target
variable with a status code of 200 or appropriate
http status codes in case of failure or error.
/api/predictions/{pid} DELETE Takes the ID of a past prediction as a path

parameter and deletes the prediction with that ID.
/api/predictions/save POST Saves a generated prediction in the database for

future viewing
/api/predictions/ GET Lists all the predictions a user has made in the past
Table 6.4. Prediction APIs
All the above APIs except for the registration and usernameExists API will require a JSON
web token to be sent in the header field. The APIs will first authenticate the request and only
then proceed with the operation.
6.10. Packaging and Deployment Diagram

The frontend of the application is downloaded on demand from the server over HTTP, after
which it is parsed and rendered by a web browser.

Applic
Clie ation Data
nt Server base
Bro
Fig. 6.8. Packaging
6.11. Help
The simple and intuitive user interface makes sure the user does not have any trouble using or
navigating through the site. When needed, additional instructions will be provided. For
example, the input fields are all equipped with tooltips to inform the user what exactly he/she
is expected to enter.
6.12. Alternate Design Considerations

When designing the application, there were many instances where we had multiple alternatives
and had to dig deeper into each of them to decide which one met our needs better. Some of the
notable ones are as follows:
6.12.1. Django
When deciding which backend framework to use, in addition to Flask, we also considered
Django which is another web server written in Python. Some of the advantages and
disadvantages it has over Flask are listed below:
Advantages:
● Includes a built-in admin panel
● Comes with an ORM (Object-relational mapping) which greatly simplifies database
usage
● A pre-made directory structure
● Several ready-to-use database interfaces
Disadvantages:
● Complex in nature
● Does not provide as fine-grained control
● Is opinionated (has a set way of doing this)
6.12.2. NodeJS
Another backend framework we considered was NodeJS. The pros and cons with respect to
Flask are as below:

Advantages:
● Highly performant in terms of I/O; great for real-time applications
● Single language for both the backend and frontend (Javascript)
Disadvantages:
● Slower development (initially)
● Python arguably easier to use than Javascript
● Not as efficient with CPU-intensive applications
● Since the machine learning model uses Python and it’s libraries, generating a prediction
would require spawning a new process and formatting the input to pass as command
line argument to the spawned process which would significantly affect the time required
to generate the prediction. This would have also lead us to get dangerously close to the
time limit of 5 seconds for generating a prediction as was agreed initially.

CHAPTER-7
LOW LEVEL DESIGN
7.1. Design Description
7.1.1. User
This class represents a user of the application. It contains the data members needed for
authentication (logging in) and has methods to create, delete and update user information.
Data Members
Data Type Name Access Modifiers Description
String username Public Unique identifier for

a user
String email Public Email address of the

user
String password Public Needed to verify

user’s identity
Table 7.1. User class data members
Methods
Name Purpose Input Output
registerUser To create a new user username, email, success/failure

in the database password
loginUser Generate a new JWT username, password success/failure

token
Table 7.2. User class methods
7.1.2. Prediction
This class represents a prediction that is requested by a user. It stores all the attributes needed
to make a prediction and an additional field to store the outcome of the prediction itself.
Data Members

Data Type Name Access Modifiers Description
String id Public Unique identifier for

a prediction
JSON attributes Public Contains attribute-

value pairs
Boolean repaid Public Outcome of the

prediction
Table 7.3. Prediction class data members
Methods
Name Purpose Input Output
generatePrediction To create a new prediction attributes prediction

instance
savePrediction To save a generated attributes + success/failure

prediction for future use prediction
deletePrediction To delete a previously id success/failure

saved prediction instance
Table. 7.4. Prediction class methods
7.1.3 Front End Organization

The web front end has been organized and divided into components and services. Each
component is a template that has its own model and attributes while services are classes that
are written to enable communication with the server or other components. A component is like
a class that has its own attributes and methods. It also has its own HTML definition and CSS
classes that are defined for it.

CHAPTER-8
IMPLEMENTATION AND PSEUDOCODE
8.1. Frontend
The web front end for the application was built using Angular 6, a contemporary and popular
JavaScript framework. It adopts a MVVM architecture. It is a platform for developing desktop
and mobile web applications. It is scalable and easy to build. Angular uses TypeScript. Angular
also supports two way binding of data with the view and the model.
Important features of the implementation are listed below:
8.1.1 Material Design

The web front end of our application follows a material design which makes the front end
appear neater, intuitive and beautiful. Using this framework makes entire front end uniform
throughout, thereby giving the user a pleasant experience. It also speeds up development and
is lightweight making the website appear faster and smooth.
We have used the node package module materialize-css in the front end. This consists of the
compiled CSS and JS files.
We have made extensive use of the following components:

● Cards
● Expansion Panels
● Snackbars
● Modals
● Navbar
● Material Icons
● Tooltips
● Progress Spinner
● Sidenav
8.1.2 Components
Angular consists of components that are similar to templates. Each component has its own
HTML content, CSS, and model attributes. The components in Angular define views. These

components implement a custom html tag that can be embedded in the html definitions of other
components making them highly reusable.
A code snippet of the html definition of a component:
Fig.8.1.1 Component Usage
In the above code sample, the html tag <app-pred-exp-panel> is a custom tag that is constructed
from a component that is defined in our project. This makes developing the project extremely
easy and encourages reuse.
The CSS classes used above are part of the material design framework. The *ngFor directive
enables us to display a list. So, the <app-pred-exp-panel> is appended as many times as the
number of objects in the details array.
(deleteId) denotes an input that this component will receive from it’s child component.
Whenever there is a change, this parent component will be notified and the appropriate action
will be performed by the component.
8.1.3 Services
Angular services are used for communication between components and for communication
with the server backend. Each component that needs to communicate with the server has a
service defined for itself. This makes the code organized, modular and easy to maintain and
read.
In this project, services are present mainly to communicate with the server. These service
classes have functions defined to make http requests to the backend server. The services are
injected into the components that will make use of this service. We have made use of the
HttpClient module defined in @angular/common/http. It provides an easy to use API and is
based on the XMLHttpRequest interface provided by most popular web browsers. This module
provides easy ways to make different http requests such as GET, PUT, POST and DELETE. It
also takes as input a callback function that is invoked when it receives the response. All http
requests made using this module are asynchronous. All requests are RESTful. All request
bodies are in JSON format.

An example code snippet:
Fig.8.1.2 Service Usage
The above code snippet displays a service class part of our project. HttpClient is injected as a
dependency into the service. The endpoint is defined globally in a separate script file that is
also imported globally. Endpoint is a string containing the protocol, IP address and port of the
server. The above example consists of functions that make http requests to the server. The
HttpClient module functions takes the URI path and the request body in case of a POST request.
Since Angular is based on TypeScript and JavaScript, the objects passed are manipulated as
JSON objects. Therefore, converting the objects to JSON format in the requests is not
necessary. In the validateUsername function, the username is embedded as a path parameter in
the URI of the request.
These requests are subscribed to in the components, i.e it registers this request and when a
response arrives the appropriate callback function is called.

Those requests that require authentication, a json web token is passed in the headers of the
request which will be decoded by the server to authorize the requests.
8.1.4 JSON Web Token

For authorization and authentication purposes, our application uses JSON Web Token
authentication which is a simple and easy to use authentication method.
Fig.8.1.3 Token header
When the user logs in successfully, the server sends a response with a JSON Web Token. The
client receives it and it is stored in the local storage. For all further requests that require
authentication, the token is fetched from local storage and a header field ‘token’ is created
populated with the value fetched from local storage. It is appended to the header of the http
request sent to the server.
Fig.8.1.4 Token header field passed in http request
In the above code snippet, the headers constructed as shown in Fig.8.1.3 is passed as an
argument to the post function of the HttpClient module. It appends the header field to the
headers of the http request body.
8.2. Backend
Flask is a Python based web framework written by Armin Ronacher. It is often considered as
a microframework since it does not require any libraries to work. It doesn’t come with features
such as form validation, database abstraction, etc. The backend is composed of RESTful API
endpoints, as described in previous section.

Fig. 8.2.1. Example backend API
The above code sample is an example of an API in the backend. It uses the HTTP GET method.
The @token_required decorator is used to check the request headers and verify that the user
has been authenticated. The jsonify function is used to convert a Python dictionary into JSON
which can be interpreted by the frontend.
The standout features of the backend implementation are listed below:
8.2.1. JSON Web Token

JWT, or JSON Web Token, is a standard that defines a compact way for securely send data
between two entities, encoded in JSON. Here, JWT is used for authentication. When the
frontend makes a login request, on success, a token is generated using a pre-defined secret key
and an expiry time. The client receives receives this token and holds onto it. The token is then
sent along with all future requests to protected API endpoints. The backend verifies the
authenticity of the token and then decides how to proceed.
Fig. 8.2.1.1. JWT usage
Fig. 8.2.1.2. JWT decoding

Fig. 8.2.1.3. JWT encoding
8.2.2. MongoDB
MongoDB is a document-oriented database program. In contrast to more common relational
database programs, MongoDB does not organize data in the form of tables, but rather in a
JSON-like format called BSON.
Fig. 8.2.2.1. MongoDB find command
Fig. 8.2.2.2. MongoDB remove command
8.2.3. Error Handling

Error handling is done through the use of HTTP status code. Common codes include 200 for a
successful request, 400 for a bad request, 401 for an unauthorized request and 403 for a
forbidden request.
Fig. 8.2.3.1. Error code example
8.2.4. Integration Tests

Integration testing is a form of software testing wherein individual modules are combined and
tested together. It is done in order to determine the compliance of a component with the
specified functional requirements. These types of tests to ensure that the entire module, as a
whole, works as expected. It verifies the smooth integration of different components.

Fig. 8.2.4.1. Login test
8.3. Model
The model is arguably the most important module in the application. It is responsible for
determining whether an individual is likely to default on his/her loan. In order to make the most
accurate model possible, we took the following into consideration:
8.3.1. Data Preprocessing

In the given condition, the dataset is full of issues that would result in a non-performant model.
Some of these include sparse columns, spurious attribute values, attributes with very wide
ranges of values, etc. By preprocessing the data, we reduce the chance of the model gaining
false interpretations of the system.
Fig. 8.3.1.1. Removal of spurious data
Fig. 8.3.1.2. Imputation and scaling of data

8.3.2. Gradient Boosted Trees

Boosting is a technique by which a weak learner (one whose performance is marginally better
than random) is modified to be better. Gradient boosting can be simplified as a numerical
optimization problem where the aim is to minimize the loss of the model incrementally adding
weak models in a gradient descent like manner.
Fig. 8.3.2.1. Gradient boosted trees working
8.3.3. K-Fold Cross-Validation

K-fold cross validation is a well studied procedure which is used to estimate how well a model
will perform on new data. The technique involves dividing the dataset into k parts, and then for
each part, using the rest of the dataset for training and the current part for testing.
Fig. 8.3.3.1. K-fold cross-validation
8.3.4. Hyperparameter Optimization

The goal of hyperparameter optimization is to find a set of hyperparameters for a given machine
learning model that cause it give optimal performance. An example of a hyperparameter is the
number of trees in a random forest classifier. For our model, we chose to go with the Bayesian
hyperparameter optimization method which works by building a probability model of the
objective function and then using it to get the best hyperparameters for the actual objective
function.

Fig. 8.3.4.1. Hyperparameter optimization output
8.4 Tools and Technologies

Our application uses the following modules, libraries and dependencies:
8.4.1 Web FrontEnd

● HttpClient
● Angular Material
● MaterializeCSS Framework
● App Routing Module for Angular
● Browser Module
● Forms Module
● Browser Animations Module
8.4.2 Web Backend

● PyMongo
● Flask Framework
● PyJWT
● PyTest
8.4.3 ML Model
● Scikit Learn
● Pandas & Numpy
● LightGBM

CHAPTER-9
TESTING
9.1. Scope
The testing performed includes the unit, integration, system, and regression testing approaches.
The following things fall under the scope of this project:
● Testing of all functional, application performance, security and use cases requirements
listed in the LLD and CRS documents.
● Quality requirements and fit metrics defined in CRS document.
● End-to-end testing and testing of interfaces of all systems that interact with the system.
9.2. Test Strategies

Effort has been made to adequately test the application thoroughly to ensure optimal end user
experience. The following are the core strategies we followed while testing:
Test Strategy Brief method to follow
User friendliness Ensure that the UI is :

A. Intuitive
B. Easy to understand
C. Has meaningful error messages and handling
D. Directs user’s interaction flow in perceptive
manner
E. Easy to navigate
Error Handling Front end : Handling status codes and error messages
and displaying the to user in a meaningful format.
Back End : From Flask server point of view, handling

the database exceptions and model errors
appropriately
Boundary Value Front End : Ensuring appropriate form handling to

Testing avoid any unusual inputs.
Back End : Validating inputs received from the front

end and conversions to be made to suit the model.
Table 9.1. Test strategies

9.3. Performance Criteria

The prediction will be generated and displayed within 5 seconds from the time of request as
was agreed upon in the Customer Requirement Specification.
9.4. Testing Environment
9.4.1. Hardware
Component Metric Value
CPU Intel Core 2 Duo or better
RAM Greater than or equal to 2GB
Storage Around 500MB
Graphics/Display Integrated graphics with basic 256 color monitor

sufficient
Table 9.2. Testing environment hardware
9.4.2. Software
Name Details
OS Ubuntu/Debian-based distro
Server Flask Server
Database MongoDB
Table 9.3. Testing environment software
9.5. Risk Identification and Contingency Planning
Risk # Risk Impact Contingency Plan
1 Changes to the original Moderate Rewrite affected test

requirements or designs cases
2 Complexities involved in testing Moderate The number of

the application acceptable defects
will be increased
3 Lack of availability of required High Acquire needed

hardware, software, data or tools resources
Table 9.4. Risk Identification

9.6. Roles and Responsibilities
Member Responsibilities
Nitish J Makam 1. Develop primary test plans for the front end UI.
2. Develop primary test plan for backend database.
3. Manually test the User Interface
Rahul N Pujari 1. Develop primary test plans for the back end API
2. Add test cases for the APIs
Rahul Thakur 1. Develop test plan to validate username

2. Develop test plan to determine strength of the
password
Table 9.5. Roles and responsibilities
9.7. Test Schedule

The following approach has been followed while testing the backend:
1. The functionality needed from the backend is decided
2. The name of the API and arguments taken/returned are finalized
3. A test case is written, ensuring that behavior will be as expected
4. The API is implemented
5. The test suite is run multiple times
9.8. Test Tools

The tools and libraries relied upon for testing include:
● PyTest: Used for integration testing of the backend
● Restlet Client: Used to make sure that APIs accept and provide the correct data
9.9. Acceptance Criteria

The main criteria used to determine whether the application is ready for release, from a testing
point of view, is the passing of all test cases.

9.10. Test Case List
Test # Test Case Required Output
1 test_username_exists: Generate a unique 200 returned the first time,

username and verify that the usernameExists then 409
API returns status code 200. Then register
the same username and make another
usernameExists API call
2 test_login: Generate a unique username and 403 the first time, then 200
register it in the database. Verify that the
login API returns an error code with the
incorrect password and that a success code
with the correct one.
3 test_prediction_db: Generate a unique Status code 200 on each call

username and register it in the database. to the save API and 1 for the
Generate some fake JSON data, and send it prediction count
with the save prediction API request. Repeat
once more, and then call the get predictions
(for a user) API and verify the prediction
count.
Table 9.6. Test case list

CHAPTER-10
RESULTS AND DISCUSSION
We were able to successfully implement an application which satisfies the customer

requirements we had planned initially.
From the model perspective, we were able to achieve an accuracy of 92% on the labeled part
of the dataset, measured on the accumulated out of fold predictions while using K-Fold cross-
validation with k=5.
Overall, this project was an excellent learning experience for all of us. We familiarized
ourselves with technologies such as Flask and MongoDB. We also discovered new machine
learning algorithms like Gradient Boosted Trees and Extremely Random Forests.
Building this project also gave all of us a first hand experience of how a problem is identified,
approaches that can be taken to solve the problem, etc. It also introduced us to standards
followed in documentation and how requirements are identified and specified, the constraints,
the system requirements, how to decide on designs keeping the tradeoffs in mind while
attempting to keep it simple. It also enabled us to learn about estimating effort and planning
and adhering to a schedule. It also made us familiar with the phases involved in the
development lifecycle of a project.

CHAPTER-11
SNAPSHOTS
Fig. 11.1. Index page

The index page of our web application. LDeP is the name of our application, short for Loan
Default Predictor.
Fig. 11.2. Password length validation

The SIGN IN button is disabled if the inputs are incorrect. Dynamic validation of length of
password is shown in the figure above. Since the length of the password is less than the
minimum of 8 characters specified, an error message is shown in red. There is also an option
to view password.

Fig. 11.3. Login input validation
Error messages on incorrect inputs for user registration. Since the username is a unique field,
an asynchronous request is made to the server to check for availability of the username. Also,
the SIGN UP button is disabled as inputs are invalid.
Fig. 11.4. Valid login example

No error messages on correct inputs and valid username. SIGN UP button is also enabled.

Fig. 11.5. Prediction input screen
Partial screenshot of the home screen that takes inputs and provides option to make a prediction.

11.6. Prediction output screen
On clicking predict, the output of different models and the overall probability is displayed as
as shown above.
Fig. 11.7. Past predictions
This above picture shows the profile page. This page lists all of the user’s previously saved
predictions. On clicking the desired prediction, more details are shown as in the following
figure.

Fig. 11.8. Delete prediction
On clicking on the desired previously saved prediction, the details are shown as above with an
option to delete the saved prediction.

CHAPTER-12
CONCLUSIONS
The outcome of this project, LDeP, is a web application that can be used to determine whether
a potential customer will default on his/her loan or not. Predicting nonpayment using traditional
methods is an arduous task and often results in poor accuracy, potentially causing losses and
missed opportunities for profit. Therefore, a delicate balance between being cautious and
seizing opportunities must be found.
Our application aims to do just that by using modern web technologies such as Angular and
Flask with a state-of-the-art machine learning model powering it in the background. At the
same time, the application greatly focuses on simplicity and ease of use.
Our potential clients such as banks and credit card companies should have no problem in using
and adapting the application into their respective workflows.

CHAPTER-13
FURTHER ENHANCEMENTS
The current version of the project is at a very basic level.

At present, we are limited by the attributes present in the dataset. We would like to slowly and
gradually introduce attributes that are not dependent on external sources and that can be easily
obtained. Also, this dataset is more suited to United States of America. We would like to make
this more suited to our country, with attributes more relevant to us.
We also think we can provide more machine learning models with higher and better accuracies
and better recall and precision scores. We would like to transition this application into a
chargeable software as a service.
In the future, our customers can be segmented and make the models with better performance
be available only to our premium customers. Each prediction that is generated can be charged.
The product can also be split into a premium and free-for-all versions once there are enough
revenues generated making it financially viable and enabling growth in the long term.

CHAPTER-14
REFERENCES
[1] Kreienkamp T, Credit Risk Modeling: Combining Classification and Regression

Algorithms to Predict Expected Loss, 2014
[2] Sheikh Rabiul Islam, William Eberle, Sheikh Khaled Ghafoor, Credit Default Mining Using
Combined Machine Learning and Heuristic Approach, 2018

BIBLIOGRAPHY
1. Banks sources of income -

https://economictimes.indiatimes.com/wealth/save/smart-things-to-know-about-sources-of-
income-for-a-bank/articleshow/54377370.cms

APPENDIX A
DEFINITIONS, ACRONYMS AND ABBREVIATIONS
The list below defined the keywords used in this report. All usages of the keywords are
unambiguous and the meanings remain as defined unless explicitly specified otherwise:
Python - A high level programming language. It is an interpreted language.

Server - A remote computer that caters to requests by clients.
Client - A system that requests the server to perform actions.
MVVM - Model View View Model. In the context of a web application architecture, it is a
type of architecture where changes to data in the view is propagated to the model and vice
versa. It ensures consistency of data all across.
HTTP - HyperText Transfer Protocol
REST - Representational State Transfer
Credit worthiness - It represents a consumer’s ability to repay a debt.
NPL - Non Profitable Loan. When it is believed that the debtors have lost the ability to repay
a loan, the loan is termed as a Non Profitable Loan.
UML - Unified Modeling Language. It is a standard and universally accepted language to
specify, visualize, construct and document the components of a software system.

APPENDIX B
USER MANUAL
We have taken utmost care and precaution to ensure that the user interface is intuitive, simple,
pleasing to the eye and easy to navigate for all kinds of users.
The end user will have to first open a web browser and navigate to the URL of our web
application. If the user is unregistered, the user will have to provide details such as username,
email id and password satisfying the requirements and format expected and click SIGN UP.
Any deviations from this are displayed with the help of appropriate error messages that are
straight forward and can be easily understood by the user.
For an existing user, the user will have to enter his login credentials, and click SIGN IN. On
successful login, the user will be taken to a home page where the user can enter the required
details and click GENERATE. If the user is unclear about what the input requires, hovering the
pointer over the label of the input will display a tooltip that describes the input field. Input
validations are performed and appropriate error messages are displayed that can be understood
by the user and perform necessary corrections. On a successful generation of prediction, it is
displayed to the user in the same page. An option to save is provided as well, which the user
can use to save it.
The user can also choose to view his past predictions in which case, the user will have to click
the menu button on the top left corner of the screen, which will display a side navigation bar
from which the user will have to click My Profile. Once clicked, the user is routed to the profile
section where the user’s past saved predictions are displayed as a list of panels. Clicking on a
single item, will show more details about the prediction. If a user wishes to delete a previously
saved prediction, they can choose to delete it by clicking the DELETE button.
After the user has completed all the activities he intended to perform, the user should click the
menu button on the top left corner of the screen and click Logout. The user will be logged out
and taken to the index screen.

Report On Restaurant Recommendation

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Report On Restaurant Recommendation

Caricato da

Copyright:

Formati disponibili

Dissertation on

Submitted in partial fulfillment of the requirements for the award of degree of

Under the guidance of

January – May 2019

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

(Established under Karnataka Act No. 16 of 2013)

100ft Ring Road, Bengaluru – 560 085, Karnataka, India

is a bonafide work carried out by

Deepika Kovi 01FB15ECS090

Mahesh H B Dr. Shylaja S S Dr. B K Keshavan

Name of the Examiners Signature with Date

01FB15ECS090 Deepika Kovi

1.1 Recommendation System

1.2 Why Recommendation System?

Traditionally there are two recommendation systems

Content based recommendation is analyzing the nature of an item or product whereas a

Dept of CSE Jan - May 2019 1

There are types of Collaborative Filtering

Chapter 2 defines the problem that we are trying to solve.

Chapter 6 describes the design of the project at a high level.

Chapter 10 lays down the results and outcomes of this project.

Dept of CSE Jan - May 2019 2

Chapter 11 includes a few snapshots of the project.

Chapter 12 deals with the conclusion of the project.

Dept of CSE Jan - May 2019 3

2.1 Problem Statement

Dept of CSE Jan - May 2019 4

3.1. Credit Risk Modeling: Combining Classification and Regression

Dept of CSE Jan - May 2019 5

recall = TP / (TP + FN)

3.1.2. Results & Conclusion

3.2. Credit Default Mining Using Combined Machine Learning and

Dept of CSE Jan - May 2019 6

3.2.3. Results & Conclusion

Dept of CSE Jan - May 2019 7

PROJECT REQUIREMENTS SPECIFICATION

4.1 Customer Requirements

The user should be able to give inputs based on their

Generate a recommendation. The inputs will be taken from

The customer must be able to give a location for suggesting

Table. 4.1. Customer requirements specification

Dept of CSE Jan - May 2019 8

Dept of CSE Jan - May 2019 9

SYSTEM REQUIREMENTS SPECIFICATION

5.1.1 Software Requirements

5.1.2 Hardware Requirements

Dept of CSE Jan - May 2019 10

Dept of CSE Jan - May 2019 11

HIGH LEVEL DESIGN

6.1. System Architecture

Fig. 6.1. System Architecture

The application can be divided into three major, independents modules:

6.1.1. Web Application (the Frontend)

Dept of CSE Jan - May 2019 12

6.1.2. Web Server (the Backend)

6.1.3. Machine Learning Model

Dept of CSE Jan - May 2019 13

6.2. Design Description

Fig.6.2 High Level Design

6.3. Use Case Diagram

Dept of CSE Jan - May 2019 14

Fig.6.3. Use Case Diagram