WhereIsMyPet-Final Thesis

Where is my pet?
A global solution for locating lost pets
A Degree Thesis
Submitted to the Faculty of the
Escola Tècnica d'Enginyeria de Telecomunicació de
Barcelona
Universitat Politècnica de Catalunya
by
Montserrat Bassas Cordoba
In partial fulfilment
of the requirements for the degree in
Telecommunications Technologies and Services
ENGINEERING
Advisor: Israel Martín Escalona
Barcelona, June 2020

Abstract
Right now, a lot of pets go missing and their owners have a lot of trouble to locate them.
Where is my pet? is a proposal for a software system to help recover these missing animals,
using image recognition and geolocation technologies to help in the process.
In this thesis we will analyse the available technologies that we have to build such a system:
from native apps to web applications to REST and GraphQL APIs, and Image Recognition
services. After making a technology choice, it will walk through all the design and
implementation decisions made through the development.
The final solution will be implemented as a web application (React), a REST API (NodeJS)
and a relational database (PostgreSQL) running on cloud technology (Heroku). It leverages
the image processing capabilities of Google Cloud Vision.
1
Resum
Actualment, moltes mascotes desapareixen i els seus propietaris tenen molts problemes
per localitzar-les. Where is my pet? és una proposta d'un sistema de programari per ajudar
a recuperar aquests animals desapareguts, utilitzant tecnologies de reconeixement
d'imatges i geolocalització per ajudar en el procés.
En aquesta tesi, analitzarem les tecnologies disponibles que tenim per construir aquest
sistema: des d'aplicacions natives fins a aplicacions web, API REST i GraphQL, i serveis
de reconeixement d'imatges. Després d'escollir una tecnologia, s'analitzaran totes les
decisions de disseny i implementació preses durant el desenvolupament.
La solució final s'implementarà com una aplicació web (React), una API REST (NodeJS) i
una base de dades relacional (PostgreSQL) que s'executa en un servidor en el núvol
(Heroku). Utilitzarem els serveis de processament d'imatges de Google Cloud Vision.
2
Resumen
Actualmente, muchas mascotas desaparecen y sus dueños tienen muchos problemas
para localizarlas. Where is my pet? es una propuesta de un sistema de software para
ayudar a recuperar estos animales desaparecidos, utilizando tecnologías de
reconocimiento de imágenes y geolocalización para ayudar en el proceso.
En esta tesis, analizaremos las tecnologías disponibles que tenemos para construir dicho
sistema: desde aplicaciones nativas hasta aplicaciones web, API REST y GraphQL, y
servicios de reconocimiento de imágenes. Después de escoger una tecnología, se
analizarán todas las decisiones de diseño e implementación tomadas durante el desarrollo.
La solución final se implementará como una aplicación web (React), una API REST
(NodeJS) y una base de datos relacional (PostgreSQL) que se ejecuta en un servidor en
la nube (Heroku). Utilizaremos los servicios de procesamiento de imágenes de Google
Cloud Vision.
3
Dedicated to my cat, Croqueta,
who passed away during the realisation of this thesis.
4
Acknowledgements
I would like to thank Israel Martín Escalona for accepting the proposal, and for the support
and the guidance. When I first asked him about this project, I had some doubts about it
being adequate as a thesis. He helped me clear them and encouraged me to go ahead
with it.
5
Revision history and approval record
Revision Date Purpose
0 22/03/2020 Document creation
1 09/04/2020 Document revision
4 11/10/2020 Final document
DOCUMENT DISTRIBUTION LIST
Name e-mail
Montserrat Bassas Cordoba montsebassas.mb@gmail.com
Israel Martín Escalona israel.martin@upc.edu
Written by: Reviewed and approved by:
Date 22/03/2020 Date 11/10/2020
Name Montserrat Bassas Cordoba Name Israel Martín Escalona
Position Project Author Position Project Supervisor
6
Table of contents
Abstract ............................................................................................................................ 1
Resum .............................................................................................................................. 2
Resumen .......................................................................................................................... 3
Acknowledgements .......................................................................................................... 5
Revision history and approval record ................................................................................ 6
Table of contents .............................................................................................................. 7
List of Figures ................................................................................................................. 11
List of Tables .................................................................................................................. 13
1. Introduction.............................................................................................................. 15
1.1. Project Purpose ................................................................................................ 15
1.2. Project Background .......................................................................................... 15
1.3. Requirements and specifications ...................................................................... 15
1.4. Work plan ......................................................................................................... 16
1.4.1. Work packages.......................................................................................... 16
1.4.2. Milestones ................................................................................................. 20
1.4.3. Gantt diagram............................................................................................ 21
1.5. Deviations and incidences ................................................................................ 22
2. State of the art of the project.................................................................................... 23
3. Methodology / project development: ........................................................................ 23
3.1. WP1 – Infrastructure......................................................................................... 23
3.1.1. Frontend .................................................................................................... 24
3.1.1.1. State of the art......................................................................................... 24
3.1.1.2. Technology choices................................................................................. 26
3.1.1.3. Design ..................................................................................................... 27
3.1.2. Backend .................................................................................................... 28
3.1.2.1. State of the art: Backend ......................................................................... 28
3.1.2.2. State of the art: Database systems .......................................................... 30
3.1.2.3. Technology choices................................................................................. 31
3.1.2.4. Design ..................................................................................................... 31
3.2. WP2 – User Management ................................................................................ 33
3.2.1. Functional Analysis.................................................................................... 33
3.2.2. Specification .............................................................................................. 35
7
3.2.2.1. Mockups.................................................................................................. 35
3.2.2.2. Endpoints ................................................................................................ 37
3.2.3. Design ....................................................................................................... 38
3.2.4. Data model ................................................................................................ 41
3.2.4.1. Queries ................................................................................................... 41
3.3. WP3 – Upload an animal .................................................................................. 42
3.3.2. Specification .............................................................................................. 42
3.3.2.1. Mockups.................................................................................................. 42
3.3.2.2. Endpoints ................................................................................................ 44
3.3.3. Design ....................................................................................................... 45
3.3.3.1. Uploading animals ................................................................................... 45
3.3.3.2. Images .................................................................................................... 45
3.3.4. Data model ................................................................................................ 46
3.3.4.1. Queries ................................................................................................... 47
3.4. WP4 – View animals......................................................................................... 47
3.4.2. Specification .............................................................................................. 48
3.4.2.1. Mockups.................................................................................................. 48
3.4.2.2. Endpoints ................................................................................................ 50
3.4.3. Design ....................................................................................................... 51
3.4.4. Data model ................................................................................................ 52
3.4.4.1. Queries ................................................................................................... 52
3.5. WP5 – Image Recognition ................................................................................ 53
3.5.1. State of the art of image recognition .......................................................... 53
3.5.3. Specification .............................................................................................. 56
3.5.3.1. Mockups.................................................................................................. 56
3.5.3.2. Endpoints ................................................................................................ 57
3.5.4. Design ....................................................................................................... 57
3.5.5. Data model ................................................................................................ 57
3.5.5.1. Queries ................................................................................................... 58
3.6. WP6 – Animal Status........................................................................................ 58
8
3.6.2. Specification .............................................................................................. 59
3.6.2.1. Mockups.................................................................................................. 59
3.6.2.2. Endpoints ................................................................................................ 59
3.6.3. Design ....................................................................................................... 60
3.6.4. Data model ................................................................................................ 60
3.6.4.1. Queries ................................................................................................... 60
3.7. WP7-Real time alerts........................................................................................ 61
3.8. WP9- User roles ............................................................................................... 61
3.8.2. Specification .............................................................................................. 61
3.8.2.1. Mockups.................................................................................................. 61
3.8.2.2. Endpoints ................................................................................................ 61
3.8.3. Design ....................................................................................................... 62
3.8.4. Data model ................................................................................................ 62
3.8.4.1. Queries ................................................................................................... 63
3.9. WP8 – Advanced User Management ................................................................ 63
3.9.2. Specification .............................................................................................. 63
3.9.2.1. Mockups.................................................................................................. 63
3.9.2.2. Endpoints ................................................................................................ 64
3.9.3. Design ....................................................................................................... 65
3.9.4. Data model ................................................................................................ 67
3.9.4.1. Queries ................................................................................................... 68
3.10. WP10 – User experience .............................................................................. 68
3.10.1. Functional Analysis ................................................................................ 68
3.10.2. Specification .......................................................................................... 71
3.10.2.1. Mockups ................................................................................................ 71
3.10.2.2. Endpoints .............................................................................................. 73
3.10.3. Design ................................................................................................... 77
3.10.4. Data model ............................................................................................ 78
3.10.4.1. Queries ................................................................................................. 79
4. Results .................................................................................................................... 79
4.1. Frontend ........................................................................................................... 80
4.2. Backend ........................................................................................................... 85
9
4.3. Database .......................................................................................................... 85
5. Budget ..................................................................................................................... 86
5.1. Infrastructure Pricing Estimates ........................................................................ 86
5.2. Salary ............................................................................................................... 87
5.3. Total cost .......................................................................................................... 87
6. Conclusions and future development: ...................................................................... 88
6.1. Summary .......................................................................................................... 88
6.2. Recommendations and improvements.............................................................. 88
6.3. Personal experience ......................................................................................... 89
6.4. Future work ...................................................................................................... 89
Bibliography .................................................................................................................... 91
Appendices..................................................................................................................... 93
Glossary ......................................................................................................................... 97
10
List of Figures
Figure 1. Gantt diagram: WP1 and WP2 ......................................................................... 21
Figure 2. Gantt diagram: WP3 and WP4 ......................................................................... 21
Figure 3. Gantt diagram: WP5, WP6 and WP9 ............................................................... 21
Figure 4. Gantt diagram: WP8 and WP10 ....................................................................... 22
Figure 5. Infrastructure: Client-server system propose.................................................... 23
Figure 6. Frontend: Current operating system distribution across mobile devices plot .... 24
Figure 7. Frontend: source code design.......................................................................... 27
Figure 8. Backend: API design ....................................................................................... 31
Figure 9. Backend: migration example ............................................................................ 32
Figure 10. Use case diagram: User Management ........................................................... 33
Figure 11. Mockups: Sign Up.......................................................................................... 35
Figure 12. Mockups: Sign In ........................................................................................... 35
Figure 13. Mockups: Recover password ......................................................................... 36
Figure 14. Mockups: Reset your password ..................................................................... 36
Figure 15. Design: controller method implementation ..................................................... 38
Figure 16. Design: Crypto cipher and decipher example ................................................. 39
Figure 17. Design: JWT and express middleware example............................................. 40
Figure 18. Design: Send emails example........................................................................ 40
Figure 19. Data model: User data model ........................................................................ 41
Figure 20. Use case diagram: Upload animal ................................................................. 42
Figure 21. Mockups: Upload a lost animal ...................................................................... 43
Figure 22. Design: insert animal into the Database pseudo-code ................................... 45
Figure 23. Data model: Animal data model ..................................................................... 46
Figure 24. Use case diagram: View animals ................................................................... 47
Figure 25. Mockups: View animals page......................................................................... 49
Figure 26. Mockups: view animal details page ................................................................ 49
Figure 27. Data model: calculate distance between animal locations SQL function ........ 52
Figure 28. Image Recognition: Benchmarking ................................................................ 54
Figure 29. Use case diagram: Image Recognition .......................................................... 54
Figure 30. Mockups: Search by image ............................................................................ 56
Figure 31. Mockups: Upload an animal page .................................................................. 56
Figure 32. Use case diagram: Animal Status .................................................................. 58
11
Figure 33. Mockups: Animal details page ....................................................................... 59
Figure 34. Data model: Animal data model update ......................................................... 60
Figure 35. Data model: roles data model ........................................................................ 62
Figure 36. Use case diagram: Advanced User Management .......................................... 63
Figure 37. Mockups: Admin page ................................................................................... 64
Figure 38. Design: Upload animal behaviour .................................................................. 66
Figure 39. Data model: Animal data model update ......................................................... 67
Figure 40. Data model: User data model update............................................................. 67
Figure 41. Use case diagram: User Experience .............................................................. 68
Figure 42. Mockups: Sidebar .......................................................................................... 71
Figure 43. Mockups: My profile page .............................................................................. 72
Figure 44. Mockups: Animal details page ....................................................................... 72
Figure 45. Mockups: Notifications page .......................................................................... 73
Figure 46. Data model: Bookmarks and Notifications data models ................................. 78
12
List of Tables
Table 1. Work package: Infrastructure ............................................................................ 16
Table 2. Work package: User Management .................................................................... 17
Table 3. Work package: Upload an animal ..................................................................... 17
Table 4. Work package: View animals ............................................................................ 17
Table 5. Work package: Image Recognition ................................................................... 18
Table 6. Work package: Animal Status ........................................................................... 18
Table 7. Work package: Real time alerts ........................................................................ 19
Table 8. Work package: Advanced User Management ................................................... 19
Table 9. Work package: User roles ................................................................................. 19
Table 10. Work package: User Experience ..................................................................... 20
Table 11. Work package: Milestones .............................................................................. 20
Table 12. Backend: URL set example ............................................................................. 28
Table 13. Backend: Interactions with animal entity example ........................................... 29
Table 14. Use case description: Create new account ..................................................... 33
Table 15. Use case description: Login with existing account........................................... 34
Table 16. Use case description: Recover password ....................................................... 34
Table 17. Endpoints: Create a new user ......................................................................... 37
Table 18. Endpoints: Get access token to identify a user ................................................ 37
Table 19. Endpoints: Request a reset password email ................................................... 38
Table 20. Endpoints: Set a new password to a user ....................................................... 38
Table 21. Endpoints: Returns current logged in user info................................................ 38
Table 22. Use case description: Register an animal ....................................................... 42
Table 23. Endpoints: Create a new animal ..................................................................... 44
Table 24. Endpoints: Get all species............................................................................... 44
Table 25. Endpoints: Get all breeds of a specific species ............................................... 44
Table 26. Use case description: View animals page ....................................................... 48
Table 27. Use case description: View animal details page .............................................. 48
Table 28. Endpoints: Search animals using filters........................................................... 50
Table 29. Endpoints: Return a specific animal ................................................................ 51
Table 30. Endpoints: Get an animal image ..................................................................... 51
Table 31. Use case description: Search by image .......................................................... 55
Table 32. Use case description: Register an animal ....................................................... 56
13
Table 33. Endpoints: Get animal info by image recognition............................................. 57
Table 34. Use case description: Mark an animal as recovered ....................................... 58
Table 35. Endpoints: Update an animal .......................................................................... 59
Table 36. Endpoints: Return current logged in user info update...................................... 61
Table 37. Use case description: Ban suspicious users ................................................... 63
Table 38. Endpoints: Update a user................................................................................ 64
Table 39. Endpoints: Return users by status .................................................................. 65
Table 40. Endpoints: Return current logged in user info update ...................................... 65
Table 41. Use case description: Contact another User ................................................... 69
Table 42. Use case description: See notifications ........................................................... 69
Table 43. Use case description: View own animals ........................................................ 70
Table 44. Use case description: Bookmark animals ........................................................ 70
Table 45. Use case description: Sidebar......................................................................... 71
Table 46. Endpoints: Create a bookmark ........................................................................ 73
Table 47. Endpoints: Delete a bookmark ........................................................................ 73
Table 48. Endpoints: Get all bookmarked animals for the current user ........................... 74
Table 49. Endpoints: Return all notifications of a specific user........................................ 74
Table 50. Endpoints: Update a notification...................................................................... 75
Table 51. Endpoints: Return all animals uploaded by the authenticated user ................. 75
Table 52. Endpoints: Send email to a user ..................................................................... 76
Table 53. Endpoints: Return a specific animal update .................................................... 76
Table 54. Budget: Virtual server ..................................................................................... 86
Table 55. Budget: Database ........................................................................................... 86
Table 56. Bugdet: Salary ................................................................................................ 87
Table 57. Appendices: Google Cloud Vision ................................................................... 94
Table 58. Appendices: Amazon Rekognition .................................................................. 95
Table 59. Appendices: Computer Vision ......................................................................... 96
14
1. Introduction
1.1. Project Purpose

The project Where is my pet? A global solution for locating lost pets consists in the design
and implementation of a software system that unifies and aggregates information about
lost, found and stray animals. It will be carried out independently by the author.
The main purpose of this project is to help owners locating lost pets. Right now, there are
many announcements of lost animals in veterinary clinics or around the streets, asking for
collaboration. There is also a lot of information about lost animals in animal rescue’s social
media accounts (mainly Facebook and Instagram), but it lacks any kind of organization or
search mechanisms, making it difficult to find anything useful.
The solution proposed with this project will try to address many of the shortcomings of the
actual systems:
- Aggregate the information in a single system.
- Remove the social media accounts entry barrier, allowing anonymous user to
consult our data.
- Provide search and filtering mechanisms to navigate through the data.
By tackling these issues, we expect a higher rate of found animals and to lower the time
needed to recover a lost pet.
1.2. Project Background

Where is my pet? Is a project that starts from scratch and will be developed independently
by the author using original ideas.
The project starts from a necessity that has been observed in local animal rescue centres,
where lost animals pile up without being able to contact their owners. The existing systems
lack in effectivity in the case where the animal is not registered with the mandatory tag
(only dogs), and the owners are only left with announcements asking for collaboration.
Trying to find a lost pet using announcements is exhausting, frustrating and ineffective. In
most social networks, these announcements get lost after 24h. Physical announcements
get easily dismissed by people, and they become outdated quickly as no one removes
them after they are no longer necessary.
The system proposed in this project will try to mitigate these shortcomings, by creating a
unified information system that aggregates all this data into a single place. It will also help
find animals using image recognition techniques to search through all the animals known
to the system. It will also help keeping information updated, as animals will be marked as
found when they are recovered.
1.3. Requirements and specifications

Project requirements:
- The system must be usable with a mobile device.
- Users will not be required to have any social media account to use the system. (No
Single Sign On)
- It must be easy and fast to upload an animal. Avoid text inputs or tedious forms.
15
- Users will only be required an account to upload animals, to increase project
adoption.
Project specifications:
- The application will work in Android and iOS.
- The user will be able to create an account directly from the app.
- To upload an animal, either lost or found, the user must be logged in.
- When uploading an animal, it will be possible to attach an image from the device’s
camera, or an existing one.
- The system will try to extract as much info as possible from the image using Image
Recognition techniques.
- It will be possible to search for animals using an image as input.
1.4. Work plan
1.4.1. Work packages

Project: Infrastructure WP ref: 1
Major constituent: Software Sheet 1 of 10
Short description: Planned start date: 09/03/2020
Research and implementation of a boilerplate Planned end date: 22/03/2020
project structure. Start event: 09/03/2020
End event: 24/03/2020
Internal task T1: State of the art on Backend Deliverables: Dates:
technologies. BBDD, API, 24/03/2020
Internal task T2: State of the art on Frontend Frontend Hello
technologies. World App
Internal task T3: State of the art on BBDD systems.
Internal task T4: Design of the API according to the
selected Backend solution.
Internal task T5: Design of the Frontend App
according to the chosen Frontend technology.
Internal task T6: Configuration of a database and a
migration system.
Table 1. Work package: Infrastructure
Project: User Management WP ref: 2

Research of available user authentication and Planned end date: 05/04/2020
management system, in order to reuse some
Start event: 25/03/2020
existing system if possible. This includes from
End event: 07/04/2020
storing user information in the database, to
implementing all authentication endpoints, to create
the frontend screens to create accounts and log in.
16
Internal task T1: State of the art in User Deliverables: Dates:
Management systems. User 07/04/2020
Internal task T2: Implementation of User database management
models. functionality.
Internal task T3: Create “sign in” and “sign up”
endpoints.
Internal task T4: Create “login” and “create
account” screens.
Internal task T5: Create “recover password”
endpoints and use an SMTP server to send emails.
Internal task T6: Develop “recover password” form.
Table 2. Work package: User Management
Project: Upload an animal WP ref: 3

Implementation of all the required software to upload Planned end date: 19/04/2020
an animal onto the system. This includes designing
and implementing a database model, specifying the
End event: 23/04/2020
API endpoints and creating the frontend screens.
Internal task T1: Design and implementation of the Deliverables: Dates:
Animal model in the BBDD. Upload animal 23/04/2020
Internal task T2: Definition and implementation of feature running in
the Upload Animal API endpoint. production.
Internal task T3: Design and implementation of the
frontend “Upload Animal” form.
Table 3. Work package: Upload an animal
Project: View animals WP ref: 4

Implementation of all the required software to view Planned end date: 26/04/2020
an existing animal into the system. This includes
designing and implementing a database model,
End event: 12/05/2020
specifying the API endpoints and creating the
frontend screens. In addition, implement the animal
list screen to show all of them.
Internal task T1: Design and implementation of the Deliverables: Dates:
“get animal” endpoint. System to view 12/05/2020
Internal task T2: Design and implementation of the animal detail and
“animal detail” screen. animals list.
“get animals” endpoint.
“animal list” screen.
Table 4. Work package: View animals
17
Project: Image Recognition WP ref: 5
Research of available image recognition technology Planned end date: 17/05/2020
and use them to extract information of the images. Start event: 10/08/2020
Use it to implement a search algorithm using an End event: 23/08/2020
image as input.
Internal task T1: State of the art on image diffing Deliverables: Dates:
algorithm. Search by photo 23/08/2020
Internal task T2: Design and implementation of an feature.
image diffing algorithm.
Internal task T3: Get animals sorted by
resemblance using the diffing algorithm.
“search by photo” screen.
Table 5. Work package: Image Recognition
Project: Animal Status WP ref: 6

To measure the efficiency of the system, and to keep Planned end date: 24/05/2020
information up to date, it must be possible to mark
an animal as “found” when it is recovered by its
End event: 28/08/2020
owner. Implement a status field in the animal entity
and make it editable from the frontend.
Internal task T1: Update “animal” database model. Deliverables: Dates:
Internal task T2: Create an “update animal” "Found” animal 28/08/2020
endpoint. feature.
Internal task T3: Add a “found” button on the “view
animal” screen.
Table 6. Work package: Animal Status
Project: Real time alerts WP ref: 7

Implement a real time alerts system, so a user can Planned end date: 07/06/2020
be notified when an animal that matches his criteria Start event: Not implemented
is uploaded into the system. End event: Not implemented
Internal task T1: Create an “alerts” database Deliverables: Dates:
model. Alerts system Not
Internal task T2: Implement “create” and “delete” feature. implemented
alerts API endpoints.
Internal task T3: Create “alerts” screens: create
form, alerts list.
18
Internal task T4: Send push messages on an alert
match.
Internal task T5: Receive and display push
messages in frontend app.
Table 7. Work package: Real time alerts
Project: Advanced User Management WP ref: 8

Improve the system to be able to ban users if Planned end date: 14/06/2020
needed. Start event: 05/09/2020
End event: 11/09/2020
Internal task T1: Update the User model to be able Deliverables: Dates:
to ban users. Ban users feature. 11/09/2020
“Block untrusted users” endpoint.
“Block untrusted users” screen.
Internal task T4: Block users with suspicious
content.
Table 8. Work package: Advanced User Management
Project: User roles WP ref: 9

Short description: Planned start date: -
Add a Role-Based Access Control system. Planned end date: -
End event: 04/09/2020
Internal task T1: Research on RBACs. Deliverables: Dates:
Internal task T2: Create Roles data model. Role-Based Access 04/09/2020
Internal task T3: Add a middleware to control Control system.
access to endpoints.
Table 9. Work package: User roles
Project: User Experience WP ref: 10

Short description: Planned start date: -
Improve navigation with a sidebar. Implement some Planned end date: -
missing features in the system. Start event: 19/09/2020
End event: 04/10/2020
Internal task T1: Add a sidebar to improve Deliverables: Dates:
navigation. Sidebar, 04/10/2020
Internal task T2: Add a contact user functionality. bookmarks
functionality,
19
Internal task T3: Add notifications page about user profile page and
activity. contact user
Internal task T4: Add a profile page to display user functionality.
uploaded animals.
Internal task T5: Add bookmarks.
Table 10. Work package: User Experience
1.4.2. Milestones
WP Task Short title Milestone / deliverable Date (week)

1 6 Infrastructure Project and system up and running. Week 3
2 6 User User management functionality. Week 5

management
3 3 Upload an animal Upload animal feature running in Week 7
production.
4 4 View animals System to view animal detail and Week 10
animals list.
5 4 Image Search by photo feature. Week 24
Recognition
6 3 Animal Status "Found” animal feature. Week 25
9 3 User roles Role-Based Access Control system. Week 26
8 4 Advanced User Ban users feature. Week 27
Management
10 5 User experience Sidebar, bookmarks functionality, Week 30
profile page and contact user
functionality.
Table 11. Work package: Milestones
20
1.4.3. Gantt diagram
Figure 1. Gantt diagram: WP1 and WP2
Figure 3. Gantt diagram: WP5, WP6 and WP9
21
1.5. Deviations and incidences

The project was expected to end by the 14th of June. Due to the workload of other subjects,
the final exams and other circumstances, we decided to postpone the project until October.
That is the reason why the work stopped between the 12th of May and the 10th of August.
It is not a deviation in the duration of the project as the duration of the tasks were not
affected by this, they were just postponed for a while.
Developing an application from scratch means having to plan all the packages, durations,
and the Gantt diagram in advance, without any prior experience or reference. This caused
some variations in the final dates, with some packages being put forward and some of them
being delayed compared to the original plan.
WP4 had a planned duration of one week but took two weeks instead. The reason is that
we put a lot of work in the filters feature, that was not entirely defined in our original plan.
On the other hand, WP5 took one week less than expected, in part thanks to the work we
put on the filters, as a lot of the code could be reused.
Lastly, there has been some non-planned changes introduced to the system that were not
considered in the initial plan. The reason is that while working on the project, we identified
some critical features that considered more important to the project than some of the initially
planned ones. That means that some work has been postponed for future work.
22
2. State of the art of the project
Right now, there are a few options when trying to find a lost pet, with different success
ratios and effort.
The first option would be using the mandatory public animal register. If the lost pet is
equipped with an identifier microchip and properly registered, it is likely that the authorities
will contact the owner when it is found. These microchips can be scanned by a veterinary,
and the owner contact details will appear. Main problems with this are that the animal must
be found and captured, which could be difficult and take time. Also, if the animal is for
example a cat that gets lost in an area with stray cats, it may not catch the attention of the
local animal shelter.
Another option for the owner is to publish announcements, either physical (in the local
veterinary clinic, or the local pet store) or digital (via social networks). This option can be
exhausting, frustrating and ineffective. In most social networks, this information will barely
have any visibility in less than 24h. Physical announcements get easily dismissed, as they
are usually never removed after a pet is found.
A third option would be using apps or websites to locate lost pets. There are a few ones in
the market (Missing Pets, Lost Pet, DOTT pets, …), but they never reached the Spanish
market. Most of them also require the user to create an account to see lost animals, usually
using a social network account, which does not encourage the users to try the app.
Another handicap for these existing applications is that they require a lot of information
about the animal before letting the user submit the information. Having in mind our
requirements of mobile devices usability, asking a user for too much manual input will
probably impact its adoption rate.
3. Methodology / project development:

We will use an iterative development methodology. The idea is to develop a system through
multiple iterations that constitute a subset of features to achieve the entire functionality.
3.1. WP1 – Infrastructure

We propose building a client-server system as detailed in the following figure.
Figure 5. Infrastructure: Client-server system propose
23
According to w3cschools, a client-server architecture is a “computing model, where the
server hosts, distributes and controls the majority of the resources as well as services to
be used by the client.” [1]. Our server will consist in a central data storage with all the data,
that also provides an API to clients (the frontend) for data access and manipulation.
3.1.1. Frontend
3.1.1.1. State of the art

As stated in the requirements, our system needs to work on mobile devices, while working
on desktop devices is not essentially required.
Current operating system distribution across mobile devices is ~73% for Android and ~26%
for iOS worldwide, according to gs.statscounter.com. If we focus on Spain, as it will be our
first target market, Android goes up to ~80% [29].
Figure 6. Frontend: Current operating system distribution across mobile devices plot
There are a number of different technologies and approaches that can be used and must
be considered for the project. In this section we will be going over three main approaches
to build the Frontend component of the system.
Our main goals will be to identify: available technologies, device support, performance,
implementation time and costs.
Native Applications
According to Wikipedia, a native application is “targeted toward a particular mobile platform.
[...] The main purpose for creating such apps is to ensure best performance for a specific
mobile operating system” [2].
24
All devices are supported when working with native applications. Frameworks and
technologies vary between platforms, which means that all functionality must be
implemented for each supported platform. While this gives you the best performance, it
duplicates both the implementation time and costs as code reuse is non-existent.
In terms of cost, it must be taken into account the distribution fees that both Apple and
Google charge for the application marketplace usage. Apple is currently charging an annual
fee of 99$, and Google is charging a one time 25$ fee. Having an apple computer is also
required to develop for iOS, as all required software is only available on macOS.
iOS applications are typically written using Swift (a programming language made by Apple).
All required software, including the IDE and compiler, are included in the developer fee.
Android applications can be written both in Java and in Kotlin. Google provides all the tools
for free, with Android Studio being the most popular IDE for Android development.
To wrap up, native applications provide the best performance at the expense of higher
development time. We could lower this development by dropping iOS support, which would
greatly reduce time and costs at the expense of ~26% of device support.
Hybrid Applications
When talking about hybrid applications, we are referring to a “mix of native and web-based
apps. Apps developed using Apache Cordova, […] React Native […] and other similar
technology fall into this category.” [2]. Apache Cordova [26] creates a bundled web
application, not a native one. On the other hand, React Native [27] generates a native
application. The approach is having a higher abstraction framework, allowing a single
codebase to be compiled to different targets.
Hybrid app device support is really good, as they support all existing platforms. Moreover,
as they are built as an abstraction of the existing platform, they could potentially support
any new platform that appears in the future.
Performance is usually worse than in native applications, and they also often fail to imitate
the look-and-feel of each platform. While this is mostly true for all hybrid technologies, some
technologies are better than others in some areas.
Implementation times and costs in hybrid apps are usually lower than in native
developments, thanks to code reuse between platforms. All developer fees still apply, as
seen in “Native applications”.
Essentially, hybrid technologies try to address the biggest native application pitfall: multiple
codebases. By achieving this, you greatly reduce implementation time and costs keeping
the same device support, at the expense of some performance and worse visual
consistency with the platform.
Web Applications
A web application is built using HTML, CSS and Javascript. They are typically served by a
web server and can usually be accessed through a URL using a Web Browser.
Web application device support is as wide as it can be, as they are supported in every
device that has a web browser. This means that desktop devices also get support. As they
25
can be accessed through the web, there is no need to install the application, providing
greater user reach than native apps.
Performance-wise, they tend to be slower than native due to the fact that they run on top
of a web browser. It very much depends on the kind of experience we try to get with web
technologies, as some functionalities suffer from the browser overhead.
Web applications usually need an internet connection to work, and there is no way to have
them installed into a device. There are two ways around these limitations: by making your
application a Progressive Web Application, or by using a hybrid application framework such
as Apache Cordova which takes web applications and wraps them as a hybrid one.
Progressive Web Applications use modern web standards such as Service Workers and
Web Manifests to make web applications work offline and make them installable into the
device home screen. This makes it possible to use a Web Application as if it were native,
providing functionalities such as push notifications and working offline. Support for PWA
varies, with the main handicap that they are not really well supported in iOS.
Implementation times and cost are the lowest, as we share the same codebase for all
devices and avoid all developer fees and proprietary software. There is a need to have a
web server running, but it is also possible to reuse an existing backend server.
We can distinguish between two types of web applications.
o Multiple Page Applications
It is the traditional way to build web applications. The web server renders data to
HTML that gets sent to the browser. Every interaction ends in a new HTML
document served to the client, that makes a full-page navigation.
These types of web applications are usually pretty simple to build. The main
downsides are that you need a fairly powerful web server, as all the work is done
server-side; and that constantly refreshing the whole page results in slow page
transitions and high data usage.
o Single Page Applications
A single-page application (SPA) [3] is a web application or website that interacts
with the web browser by dynamically rewriting the current web page with new data
from the web server, instead of the default method of the browser loading entire
new pages. In some cases, the first document can be made static (it never changes),
so you can use a Content Delivery Network to serve it and drastically reduce the
requirements of your web server.
This approach gives better interactions and faster transitions, as they feel more like
a native app. The downside is that they are more complex than traditional multiple
page applications.
3.1.1.2. Technology choices

The frontend will be built as a Single Page Application using web technologies. This
technology choice gives us the best user reach, the fastest development time and the
lowest cost among all the other candidates.
We will be using the following technologies:
26
React
An open source library to build interactive UIs in a painless way. It uses a declarative
approach where you define your views as a function of your data, and the library updates
the view for you.
It is component based, meaning you can wrap up your code in small “components” that
can then be composed into a full application. React has one of the biggest communities
and adoption of all web technologies, making resources such as documentation and
examples easily available.
To create the base of our application, we will use a tool called create-react-app, that
creates a fully functional application with a single command, ready to be deployed.
Material UI
Web technologies use CSS to add styling into the application. Styling an application is
extremely time-consuming, and not the main focus of this project. That is why we will be
using a visual component library to build our screens.
The component library that has been chosen is called material-ui, and it uses the Material
Design specification by Google. It is one of the biggest and most widely used component
libraries in the React ecosystem and has tons of components to build layouts and forms.
It also gives us the benefit that the application will look similar to a native android application.
React-Router
One of the trickiest parts of a Single Page Application is getting navigation right. We will
use a third-party routing library called react-router. It has a nice declarative API and is
widely used in the React ecosystem. With this package, we make sure that navigations are
handled correctly.
3.1.1.3. Design
Source Code
We will use create-react-app as a starting point for our app. The application will be
organized in pages, which will have components. All logic (connecting to database, URL
generation…) will be organized in services. The index file will contain route definitions.
Figure 7. Frontend: source code design
27
We will be writing the application using TypeScript, a typed superset of Javascript. When
compiling the app, it enables a type checking system that will help catch bugs and improve
the editor support. To compile the app, we will use the yarn build script, that will compile
all our src directory into a build folder.
Deployment
We will deploy the frontend using Github Pages, which is a static web server that github
provides for free with the repository. It also includes a domain that will make our application
instantly available.
To do so, we will use a third-party tool named gh-pages [4]. The process to deploy is quite
simple: we will create a script that will deploy our compiled app using the mentioned tool.
The script looks as follows: gh-pages -d build.
3.1.2. Backend
3.1.2.1. State of the art: Backend

As seen in the overview, our system will implement an HTTP API to serve data to the
frontend. In this section we will explore two of the main technologies / architectures that
have been identified: RESTful APIs, and GraphQL.
RESTFul API
REST (standing for REpresentational State Transfer) is an architectural style first
presented by Roy Fielding in 2000. It uses the concept of resources and collections, plus
a few constraints on naming [5], to define a set of URLs to expose data and functionality.
“The key abstraction of information in REST is a resource. Any information that can be
named can be a resource. [...] In other words, any concept that might be the target of an
author’s hypertext reference must fit within the definition of a resource” [6]- Roy Fielding
As an example, in our system, a resource could be an animal. After identifying a resource,
we would define a set of URL to expose functionality:
GET /animals Get information about all animals in the system.
GET /animals/{animalId} Get information about a single animal.
POST /animals Create a new animal in the system.
PUT /animals/{animalId} Update an existing animal
DELETE /animal/{animalId} Delete an existing animal from the system.

Table 12. Backend: URL set example
It must be noted that, when working with REST, the data that is being exposed is decided
by the server. In case we need information about multiple resources, we also need to make
several requests to the API.
28
GraphQL
“GraphQL is a query language for APIs and a runtime for fulfilling those queries with your
existing data. GraphQL provides a complete and understandable description of the data in
your API, gives clients the power to ask for exactly what they need and nothing more.” [7]
GraphQL is a new approach to build HTTP APIs started by Facebook in 2012, and open
sourced in 2015. It is currently being maintained by the Linux Foundation.
The approach taken by GraphQL is completely opposite to REST: it uses a single URL that
accepts only POST requests, and a query must be specified in the body. These queries
use a proprietary language (called GraphQL). It tries to give back control on the data being
requested to the consumers.
In order to perform actions on the system, the GQL language provides three mechanisms:
query, mutation and subscription.
Following the same example as REST, we will show how to interact with our animal entity.
query { Fetches the property name of all animals in the

animals { system.
name
}
}
query { Fetches the name property of a single animal

animal(id: $animalId) {
name
}
}
mutation { Creates a new animal in the system, and fetches

createAnimal(animal: this newly created animal “id” field.
$animal) {
id
}
}
mutation { Updates an existing animal and fetches the field

updateAnimal( “name” as a result.
id: $id,
animal: $animal
) {
name
}
}
Table 13. Backend: Interactions with animal entity example
Any manipulation in the system (creating, updating or deleting) is done via mutations, there
is no further distinction between each type of manipulation.
29
The main advantages are the flexibility that allows the frontend, making it possible to ask
only for the required information, and fetching multiple unrelated data in a single network
request.
On the other hand, it is much less mature than REST, so tools, frameworks and
documentation are less polished and more prone to bugs, and developers are less
experienced.
3.1.2.2. State of the art: Database systems

Our system will be working with data that will be created and updated over time. There is
a need to store this data in an ordered and reliable way, and to query and aggregate it
using arbitrary parameters.
In this section we will present the two primary technologies that exist in the market to fulfil
these needs: Relational Databases (SQL) and Non-Relational Databases (NoSQL).
Relational Databases
According to Oracle [8], one of the biggest database providers, a relational database is “a
type of database that stores and provides access to data points that are related to one
another”.
It was first introduced by Edgar F. Codd in his 1970 paper “A Relational Model of Data for
Large Shared Data Banks” [9], in a time where most of the software projects developed
their own custom data storage solutions.
They became ubiquitous in the market, to the point where they still dominate the market 50
years later (as seen in rankings such as db-engines.com [10], where the top 4 technologies
still use the relational model).
Relational databases use SQL (Structured Query Language) [11] as their primary
language. It is a formal, declarative and standard (ISO and ANSI adopted it as a standard
in 1987 and 1986 respectively) language compatible with any relational database system.
Even with SQL being a standard, code is mostly not portable from one system to another
without some modifications [12].
Non-Relational Databases
A non-relational database (also known as NoSQL) is “any database that does not follow
the relational model” [13]. They do not follow any standard, so they may vary in approach,
technology and query languages between them.
In the early days of Big Data1, it became clear that the relational model would not be able
to handle new kinds of requirements that were now considered basic.
According to Amazon, “these types of databases are optimized specifically for applications
that require large data volume, low latency, and flexible data models, which are achieved
by relaxing some of the data consistency restrictions of other databases” [15].
1 According to Wikipedia [14], Big data is a field that treats ways to analyse, systematically extract
information from, or otherwise deal with data sets that are too large or complex to be dealt with by
traditional data-processing application software.
30
This new database technology tries to maximize scalability and performance, at the
expense of formal structure and data consistency mechanisms. They are a great fit for
some of the modern web applications: ad tech, online gaming, social networking… that
works with non-structured data.
All these advantages come at the expense of standardisation, as every NoSQL database
has its own query language and structure, so code and knowledge cannot easily be ported
over to another system.
3.1.2.3. Technology choices

The backend of the system will consist of a Restful API, built on top of NodeJS and using
the express web server, using Typescript as our programming language. The main driver
for this decision has been: to use the same language in frontend and backend, and to use
established and tested software and patterns.
For storing data, we will use a relational database. Among all the available relational
database systems, we have chosen to use PostgreSQL. There are a few reasons behind
this choice: it is open source, has been tested over time by the industry, and it was pre-
configured in the service provider we chose.
3.1.2.4. Design
API
The API will be our main backend component, and as such will have a lot of functionality
and responsibilities. We will use the MVC pattern to organize files and functionalities. This
pattern defines three main software pieces: models, views and controllers.
Controllers will be used for interacting with the outer world: handling requests, parsing data
and sending responses. URL definition will also be made here. Models are our core logic.
All business logic, data encryption, search algorithms or email sending will be inside a
model. Our system, being an API, will have no views.
We will additionally define a db directory, with all database connection logic and queries. It
will help us to keep all database-related functionality together.
Figure 8. Backend: API design
Database
Rolling out changes to the database works differently than with software. With software,
the only requirement is to upload a new version of the software and restart the server. With
databases, you need to alter the structure of the database but keep all existing data.
31
The strategy we will be using is called database migrations. A database migration is the
“management of incremental, reversible changes to relational database schemas” [16].
These migrations are performed (if necessary) when a new version is deployed.
The database migration tool we will use is called db-migrate [17]. All of these tools work
quite similarly, you only need to create a migrations folder in your project, configure your
database, and run the tool. A migration is composed of two files: the up (to deploy a
change) and the down (to revert a change). Let’s see an example of a migration:
Figure 9. Backend: migration example
These migrations will be in the same repository as the API, as both backend and database
should evolve together over time. We will keep them outside of the src directory, inside a
migrations directory.
Deployment and platform
The system will run in a cloud provider called Heroku. This provider gives us a dynamic
web server that can run NodeJS applications, and a PostgreSQL database already
configured. To deploy, Heroku provides an integration with GitHub to deploy directly from
the repository. We will automate this process, so every push to master will trigger a new
deployment automatically.
Every time a deploy is triggered, the deploy pipeline will run. It consists of three main steps:
- Build: Installs dependencies and compiles Typescript to Javascript.
- Release: Runs database migrations.
- Start: Starts the application server
If all three steps run successfully, the new deployment is released. Otherwise, it will keep
the old one running automatically.
32
3.2. WP2 – User Management
3.2.1. Functional Analysis

Use case diagram:
Figure 10. Use case diagram: User Management
Use case description: Create new account

Summary Creating a new user account in the system
Actors User
Preconditions -
Triggers User navigates to sign up page
Main Flow 1. User navigates to sign up page
2. User fills all required fields
3. The system validates and stores the data
4. The user is redirected to the main page
Alternate flows 3. Some data is not valid
a. The system presents an error message to the user
b. Go back to step 2 of main flow
Validation US1 A user navigates to the sign-up page. He fills all required data
Scenarios and clicks on the submit button. After showing a loading
indicator, the system redirects to the application.
Table 14. Use case description: Create new account
Use case description: Login with existing account

Summary Log in into the system with an existing account
Actors User
Preconditions The account must exist in the system
Triggers User navigates to login page
Main Flow 1. User navigates to login page
2. User fills username and password
3. The system validates the data
33
4. A new session is created for the user
5. The user is redirected to the main page
Alternate flows 4. Username or password are not valid
Validation US1 A user navigates to the login page, fills the username and
Scenarios password fields and clicks on the submit button. After showing
a loading indicator, it gets redirected to the application.
Table 15. Use case description: Login with existing account
Use case description: Recover password

Summary Reset the password for an existing account
Actors User
Preconditions -
Triggers User navigates to recover password page
Main Flow 1. User navigates to recover password page
2. User fills username or email
3. The system validates the data
4. An email with a recovery link is sent to the user’s email.
5. The user clicks on the link, navigates to recover password
page with special credentials.
6. User provides new password twice
7. The system validates and updates the password.
8. Success message is shown to the user
Alternate flows 3. Username or email are not valid
7. Passwords do not match
a. An error message is shown to the user
Validation US1 A user navigates to the recover password page and enters a
Scenarios valid username or email. The system shows a success
message asking the user to check the email. The user checks
its inbox, finds an email with a recovery link and clicks on it.
The system presents a screen with two password inputs, and
the user enters the same password twice. After showing a
loading indicator, the system shows a success message. The
user navigates back to the login page, and successfully logs
in using the new credentials.
Table 16. Use case description: Recover password
34
3.2.2. Specification
3.2.2.1. Mockups
To accomplish the use cases described before, the system will need some screens to let
the user interact with the application. In this section we will provide mockups for these
pages and user journeys between screens.
Sign Up
Figure 11. Mockups: Sign Up
Sign In
Figure 12. Mockups: Sign In
35
Recover Password
Figure 13. Mockups: Recover password
Figure 14. Mockups: Reset your password
36
3.2.2.2. Endpoints
To exchange data from the client to the API and vice versa we will use the following
endpoints:
POST /users/sign-up
Summary Creates a new user
Content-Type: application/json
Body:
{
“name”: string,
Request “surname”: string,
Parameters “email”: string,
“phone”: string,
“username”: string,
“password”: string
}
{
200 Ok “token”: string
Response }
409 Conflict Email or username already in use

Table 17. Endpoints: Create a new user
POST /users/sign-in
Summary Gets an access token to identify a user
Body:
Request {
Parameters “username”: string,
“password”: string
}
{
200 Ok “token”: string
Response }
401 Unauthorized Bad credentials
Table 18. Endpoints: Get access token to identify a user
POST /users/reset-password-email
Summary Requests a reset password email

Request Body:
{
Parameters
“usernameOrEmail”: string
}
Response 200 Ok
37
401 Unauthorized Username or Email not found
Table 19. Endpoints: Request a reset password email
POST /users/reset-password
Summary Sets a new password to a user
Body:
Request {
Parameters “token”: string,
“newPassword”: string
}
200 Ok
Response
401 Unauthorized Invalid token
Table 20. Endpoints: Set a new password to a user
GET /users
Summary Returns current logged in user info
Request
-
Parameters
{
“name”: string,
“surname”: string,
200 Ok “username”: string,
Response
“id” number
}
204 No content User not logged in
Table 21. Endpoints: Returns current logged in user info
3.2.3. Design
We start creating a controller and a model for our user management endpoints. The
controller will register all the endpoints mentioned in the previous section. A controller
method is implemented like in the line below:
Figure 15. Design: controller method implementation
38
Note that we are using an express router that will then be imported in the index file of the
application with the prefix /users, so we omit this path.
We will also create a model to keep all our business logic. The main functionality for this
package is: creating, updating and deleting data from our database, and sending emails to
the user.
We need to ensure all the data that is sent to the API is correct. Validating data is a difficult
task that needs to be handled correctly. We will be using a library called Joi [28]. This library
lets us define a set of constraints using the Joi.object() function, and validates the data for
us using a custom middleware (validator.body).
Database and Cryptography

To ensure data protection, we will use cryptographic technology to keep all user data safe.
There are multiple algorithm and technology choices we could use to achieve this
encryption, and we chose to use the native crypto module from NodeJS, and the bcrypt
module to calculate password hashes.
We will be using a crypto cipher and decipher to encrypt and decrypt data. We can see
some sample code below. Concrete choice of algorithms, and which fields are encrypted
can be found in section 3.2.4.
Figure 16. Design: Crypto cipher and decipher example
Data will be encrypted and decrypted by the API just before inserting to the database and
just after retrieving from the database. This means that data is encrypted when stored but
unencrypted in memory and when travelling through the network (between frontend and
API). However, communication between the API and the application is done over HTTPS,
which is encrypted by default. Passwords can not be decrypted, as we are using a hashing
algorithm and not an encryption one. Password match is done by comparing hashes, and
not by decrypting the stored password.
39
Session management
After some research, we chose to use Json Web Tokens to keep track of logged in users.
JWT are “compact, URL-safe means of representing claims to be transferred between two
parties” [18]. We will transfer the logged user id field inside a JWT placed in the headers of
the requests, and then use an express middleware to retrieve this data and make it
available to the request object. Code samples can be found below.
Figure 17. Design: JWT and express middleware example
Emails
The system needs to be able to send email notifications to the user. After some research,
we have decided to use the nodemailer package. Nodemailer is a library that allows you
to send emails from NodeJS, with a lot of support and functionalities such as HTML
templates and unicode characters. We will use the gmail smtp server with a gmail account
as the sender account.
Sample code to send emails can be found below.
Figure 18. Design: Send emails example
40
3.2.4. Data model
For the WP2 (User management) we implement a User database model as the one below:
Figure 19. Data model: User data model
To comply with all security standards and regulations, we need to encrypt all user data
(except the password) before storing it into the database. To do so, we will be using an
AES-256-CBC cipher with a random IV vector to transform the data and will store both the
serialized IV and the encrypted data into the database. In order to decrypt the data, we will
need the secret key and the IV to be able to obtain the clear text data.
Having all the data encrypted brings us a problem: we cannot query it. In our case, we will
need to query for a user using either the username or the email (to check for duplicate
users when creating accounts or recovering the password). To do so, we will add two
additional columns named username_hash and email_hash, storing a SHA256
representation of the clear text value. When searching by any of those fields, we will
generate the hash representation and query using the hash column instead of the
encrypted one.
For the password, we will be using the bcrypt hashing algorithm. The bcrypt algorithm,
unlike the SHA type of algorithms, is designed to be slow. This is what makes it so useful
for password hashing, as it renders dictionary and brute-force attacks nearly useless. [30]
While modern hardware can calculate millions of SHA-256 hashes per second, a properly
configured bcrypt with an adequate work factor can bring this down to 3 hashes per second
[19].
3.2.4.1. Queries
Get user by id
Allows searching the database for the user by their unique id. Used to retrieve the user
data with the ID that comes in the bearer token.
Get user by username or email

Let you search the database for the user using their username or email address (using the
email hash or username hash). Used in the recover password flow.
41
Insert user
Allows you to insert in the database a new user. Used in the sign-up flow.
Reset password
Allows you to reset a user's password using their unique id.
3.3. WP3 – Upload an animal

Use case diagram:
Figure 20. Use case diagram: Upload animal
Use case description: Register an animal

Summary Uploading a new animal in the system
Actors User
Preconditions 1. The user must be logged in
Triggers User navigates to upload animal page
Main Flow 1. User navigates to upload animal page
2. User fills all required fields
4. The animal is registered for the user
Validation US1 A logged user navigates to upload animal page. He fills all
Scenarios required data and clicks on the submit button.
Table 22. Use case description: Register an animal
3.3.2.1. Mockups
In this package we add a new screen.
42
Upload a lost animal
Figure 21. Mockups: Upload a lost animal
Fields marked with an asterisk do not appear if the selected status is found.
43
3.3.2.2. Endpoints
endpoints:
POST /animals
Summary Creates a new animal
Content-Type: multipart/form-data
Body:
{
“status”: string,
“species”: string,
“breed”: string,
“size”: string,
Request “color”: string,
Parameters “name”: string,
“gender”: string,
“age”: string,
“lat”: number,
“lng”: number,
“location”: string,
“images”: File
}
{
201 Created “id”: number
}
Response 400 Bad Request “Images is required”

401 Unauthorized
403 Forbidden
Table 23. Endpoints: Create a new animal
GET /species
Summary Gets all species
Request
-
Parameters
Response 200 Ok [string]
Table 24. Endpoints: Get all species
GET /breeds/{species}
Summary Gets all breeds of a specific species

Request
-
Parameters
Response 200 Ok [string]
Table 25. Endpoints: Get all breeds of a specific species
44
3.3.3. Design
3.3.3.1. Uploading animals

The backend exposes an endpoint to upload animals. This endpoint receives the animal
information in the body of a POST request using a form-data type. It uses form-data instead
of JSON to allow sending images within the request.
The backend validates the input using Joi, processes the images and inserts the data into
the database. To insert the animal into the database we define a SQL function that fills all
the tables in the data model. If the insertion or the image processing fails, a delete function
is triggered to clean up all the data. We can see this implementation in the following
pseudo-code.
Figure 22. Design: insert animal into the Database pseudo-code
As for the Frontend, we use Formik as helper library to implement the form and material-ui
input components to style the screen. All the mandatory data inputs required in the form
are set as selects and radio buttons to help users and to restrict inputs to valid values. The
image input is a native HTML file input, allowing users to choose from the device or open
the camera.
3.3.3.2. Images
We design the system so animals can have multiple images attached, but we will only be
uploading one for now. These images are uploaded through the API using form-data POST
requests. We added a middleware called multer that takes care of extracting the image
from the request and store it in the uploads directory.
45
Right now, there is no size limit when uploading an image. This can cause performance
issues, so we downsize images to 1000x1000 px before storing them. To resize images,
we use a dependency called sharp.
We store images on the database as binary objects. Another option would be to store them
in the cloud using a service such Amazon s3 or Google Cloud Storage. At this point in the
project we do not want to add a dependency to another provider so opted for the first one.
We are aware that this option is not optimal and can cause performance issues in the future
as the number of users increases.
To retrieve those images an endpoint is created in the API that queries the database and
returns them. This endpoint adds a Cache-Control header, so clients do not ask for the
same image twice.
3.3.4. Data model

For this package we implement an Animal database model as the one below:
Figure 23. Data model: Animal data model
We define an animals table containing the base animal information. For the gender, breed,
species, status and size parameters we create separate tables containing all possible
values. Animal images and animal locations are kept in separate tables to allow multiple
values per animal. All these tables are related using foreign keys, as it can be seen in the
diagram.
We use an SQL function called insert_animal that inserts all animal data and creates all
relationships in a single transaction. In case an animal is deleted, animal locations and
animal images are also deleted automatically because the foreign key has an on delete
cascade property.
46
Animal images are stored using PostgreSQL Large Objects. This type of data allows storing
big binary files and gives you an oid (object identifier). We assign the oid to the animal
images table. Creating and reading large objects requires using a specific PostgreSQL API,
so we insert them into the database after inserting the animal.
To read images, PostgreSQL allows reading large objects as buffers to stream them to the
API.
3.3.4.1. Queries
Insert animal
Allows you to insert in the database a new animal. Used in the upload animal flow.
Insert animal image

Allows you to insert in the database the image of the animal that you are creating in the
upload animal screen.
Get breeds by species

Returns you the breeds once selected one species. Used to enter data while uploading an
animal.
Get all species

Returns species on the upload animal screen. Used to enter data while uploading an
animal.
Delete animal by id
Allows you to delete an animal from the database in case the insertion of the associated
image fails after creating the animal in the database. All related tables are also deleted
using “on delete cascade” in the foreign keys. Used in the upload animal flow.
3.4. WP4 – View animals

Use case diagram:
Figure 24. Use case diagram: View animals
47
Use case description: View animals page
Summary See all registered animals on the website
Actors User
Preconditions -
Triggers User navigates to the view animals page
Main Flow 1. User navigates to the search page
2. The user can see animals sorted by distance
Alternate flows 3. The user clicks on the filter icon in the lower right corner of the
view animals page
a. User fills the filters fields that he wants
b. The user is redirected to the view animals page with
the filters applied
4. The system does not find any results
a. A not found page is showed
Validation US1 A user navigates to the view animals page and the animals are
Scenarios sorted by distance. The user can use filters by clicking on the
filter icon in the lower right corner and filling the filters fields
that he wants. After that, the user is redirected to the view
animals page with the filters applied.
Table 26. Use case description: View animals page
Use case description: View animal details page

Summary See animal details
Actors User
Preconditions -
Triggers User clicks on one of the images of the view animals page
Main Flow 1. User navigates to view animals page
2. User selects one image by clicking on it
3. The user is redirected to the animal details page
Validation US1 A user navigates to the view animals page. He selects an
Scenarios image by clicking on it. The system redirects to that animal
details page.
Table 27. Use case description: View animal details page
3.4.2.1. Mockups
In this package we add two new screens, view animals page and view animal details. We
also modify the upload animal screen, adding a redirection to the animal details page upon
completion.
48
View animals page
Figure 25. Mockups: View animals page
View animal details
Figure 26. Mockups: view animal details page
49
3.4.2.2. Endpoints
endpoints:
GET /animals
Summary Search animals using filters
Query params:
{
“start”: integer,
“count”: integer,
Request “species”: string,
Parameters “breed”: string,
“status”: string,
“lat”: number,
“lng”: number
}
[
{
“id”: number,
“user_id”: number,
"status": string,
"species": string,
"breed": string,
"size": string,
"color": string,
"name": string,
Response 200 Ok "gender": string,
“publication_date”: string,
"age": number,
"lat": number,
"lng": number,
"location_id": string,
"image_name": string
}
]
Table 28. Endpoints: Search animals using filters
GET /animals/{id}
Summary Returns a specific animal
Request
-
Parameters
50
{
“id”: number,
"status": string,
"species": string,
"breed": string,
"size": string,
"color": string,
"name": string,
200 Ok "gender": string,
Response
“publication_date”: string,
"age": number,
"lat": number,
"lng": number,
"image_name": string
}
404 Not Found

Table 29. Endpoints: Return a specific animal
GET /animals/{id}/{imageName}.png
Summary Gets an animal image
Request
-
Parameters
200 Ok Base64 image string
Response
404 Not Found
Table 30. Endpoints: Get an animal image
3.4.3. Design
The view animals page works querying an endpoint that returns all animals in the database.
This endpoint accepts parameters (as query params) that allow filtering and ordering the
results. Filters can be applied by species, breed and status. The result can be ordered by
distance if you provide a location (express as latitude and longitude). As the result set can
be large, the endpoint allows pagination using the start and count parameters.
The filters are applied directly in the database, modifying the query according to the
parameters. The current filters can be applied in a simple WHERE statement. To sort by
distance, we implement an SQL function that takes two locations as parameters and
returns the distance in kilometres. By applying the filters on the database instead of filtering
in JavaScript we ensure good performance and save bandwidth between API and the
database.
As for the Frontend, by default we show the animal page without filters. Automatically we
ask for location permission and, if the user accepts, we apply the order by distance feature.
All the other filters can be applied using a form that is hidden by default. If the user clicks
in the filter button the form appears inside a modal. Every time a filter is applied, we show
it as a Chip material-ui component. These chips allow the users to easily see which filters
51
are applied and can be deleted by clicking them. Deleting a chip also deletes the applied
filter.
The Frontend URL also accepts query parameters to specify the filters. By doing this, users
can share filtered lists of animals. Changing filters in the UI automatically updates the URL.
If a user clicks in an animal, it navigates to the animal details page. This page shows all
the information about the animal, an interactive map of the animal location, and allows to
preview and enlarge the image. This page has a unique URL per animal allowing the user
to share it. Clicking in the map opens google maps. We chose to open google maps
because most mobile devices will open the native app, providing a better user experience
than our embedded map.
3.4.4. Data model

The SQL function used to calculate the distance between animal locations has been
inspired by the piece of code provided by geodatasource.com [20], which has been further
modified to fulfil the specific requirements of the application.
The modified function can be seen in the following figure:
Figure 27. Data model: calculate distance between animal locations SQL function
3.4.4.1. Queries
Get animal by id
Allows searching the database for the animal by using their unique id. Used to retrieve the
animal data with the id that comes in the URL parameter.
52
Get animal image
Returns the animal image.
Get animals
Allows searching the database for animals to show them to the user in the view animals
page. It can be filtered by species, breed and status. It can be paginated. It sorts the results
by distance if latitude and longitude is provided.
3.5. WP5 – Image Recognition

In order to analyse and extract information from the images that our users upload into the
system, we need to integrate some image recognition software into our platform. The
primary goal of this software is to identify as many parameters from the image as possible,
so the user does not need to fill all the information. It will make it easier and quicker to
upload an animal.
At this stage, we will try to identify the species, the breed, the color and the size of the
animals automatically. These parameters are the common ones between “lost” and “found”
animals when uploading an animal. They also enable us to filter the animals in the View
Animals page.
3.5.1. State of the art of image recognition

An image recognition system is a software that takes an image as input and provides
information about the objects that appear in the scene. They are based in machine learning
models and can deal with a wide range of inputs.
There are a few services in the market that provide easy access to such systems. In this
section we analyse three of these services: Google Cloud Vision, Amazon Rekognition and
Microsoft Azure Computer Vision. All of them provide general use case image recognition
models that should fit our needs.
To choose between them, we designed a test using a set of 60 images. These images
have been analysed with each system, and the results have been ranked based on the
extracted parameters.
The ranking is calculated as follows. We prioritize the species and breed detection over
size and color.
• Species: 5 points if detected correctly. 0 if not detected. -1 if detected incorrectly.
• Breed: 5 points if detected as first option, 4 points if detected as second option, 3
points if detected as third option, etc. If no breed is detected, we assign 0 points. In
case only wrong breeds appear, -1 points. To determine the order of options, we
consider the score of each option, which is provided by the image recognition
service.
• Size: 1 point if correct, 0 if no information provided, -1 if incorrect.
• Color: Same criteria as size.
53
The results for this test2 are represented in the following figure.
Figure 28. Image Recognition: Benchmarking
Our key findings and conclusions:

• All systems provide similar accuracy when finding species.
• Color and size do not give accurate enough information.
• Google Cloud Vision provides significantly better breed detection, with Microsoft
and Amazon giving similar results.
Taking the results into account, we conclude that Google Cloud Vision works best for our
use case, however only species and breed information will be considered for now as color
and size are not reliable enough.

Use case diagram:
Figure 29. Use case diagram: Image Recognition
2 See the comparative tables (Table 57, Table 58 and Table 59) in Appendices.
54
Use case description: Search by image
Summary Search animals by uploading an image
Actors User
Preconditions -
Triggers User navigates to the view animals page
Main Flow 1. User navigates to view animals page
2. The user clicks on the filter icon in the lower right corner of the
view animals page
3. The user clicks on search by photo
4. The user selects an image
5. The system obtains species and/or breed from the image
6. The user is redirected to the view animals page filtered by
species and/or breed
Alternate flows 6. Applying the filters, the system does not find any results
a. A not found page is showed
b. Go back to step 3 of the main flow
Validation US1 A user navigates to the view animals page. He clicks on the
Scenarios filter icon in the lower right corner and after that clicks on “filter
by photo” button. Finally, the user is redirected to the view
animals page with the filters applied.
Table 31. Use case description: Search by image
Use case description: Register an animal

Summary Uploading a new animal in the system
Actors User
Preconditions The user must be logged in
Triggers User navigates to the upload animal page
Main Flow 1. User navigates to upload animal page
2. User uploads an image
3. The system obtains species and/or breed from the image
4. User is redirected to the upload animal form
5. User fills remaining required fields
7. The animal is registered for the user
4. The system finds similar animals in the system. The system
presents these animals to the user.
5. The user does not recognize the animal in the list and clicks
on the dismiss button.
a. Go back to step 5 of the main flow
Validation US1 A logged user navigates to upload animal page. He uploads an
Scenarios image and using image recognition the system obtains species
and/or breed. He is redirected to the upload animal form and
55
fills remaining required fields and clicks on submit. The system
creates the animal, and the user is redirected to the animal
details page.
Table 32. Use case description: Register an animal
3.5.3.1. Mockups
In this package we modify the view animals screen to add an image filter. We also modify
the upload animal page to add image recognition autocompletion.
Search by image
Figure 30. Mockups: Search by image
Upload an animal
Figure 31. Mockups: Upload an animal page
56
3.5.3.2. Endpoints
endpoints:
POST /image-recognition
Summary Gets animal info by image recognition
Content-Type: multipart/form-data
Request Body:
{
Parameters
“image”: File,
}
{
"species": string,
200 Ok "breed": string
Response
}
400 Bad Request “Image is required”

Table 33. Endpoints: Get animal info by image recognition
3.5.4. Design
Our image recognition functionality is based in a single endpoint that takes an image and
returns the animal species and/or the animal breed. This endpoint uses label detection
from Google Cloud Vision to annotate the image. We process these annotations by
comparing them against our database using the string-similarity dependency. If we find a
match, we return them.
To consume the Google Cloud Vision service, we use their official NodeJS client. This
client needs to be configured using environment variables to provide a service account.
Right now, we only detect species and breeds, but we design the endpoint to be able to
return any parameter in an animal. The Frontend is also prepared to consume any
parameter in an animal. By doing so, we can improve the image recognition algorithm in
the future without refactoring other parts of the system.
The rationale behind this decision is to be able to swap the Google Cloud Vision model
with a custom one in the future as the current one has several limitations (such as only
detecting species and breeds).
From the Frontend, we call this endpoint in the upload animal page to fill the fields of the
form and help the user. We also call the endpoint from the filters modal to apply filters
based on an image.
3.5.5. Data model

No new data model added.
57
3.5.5.1. Queries
No new queries added.
3.6. WP6 – Animal Status

The purpose of this package was to implement a Status field in the animal model and use
it to indicate when an animal was reunited with its owner. In WP2, we ended up using the
“status” field for an entirely different concept, so we needed another way to achieve our
initial purpose. For this reason, we use the term recovered when talking about animals
that have been reunited with the owner.

Use case diagram:
Figure 32. Use case diagram: Animal Status
Use case description: Mark an animal as recovered

Summary Mark an animal as recovered
Actors User
2. The user must be the owner of the animal
Triggers User clicks the button “Mark as recovered” in the animal details page
Main Flow 1. User navigates to animal details page
2. User clicks the button “Mark as recovered” in the animal
details page
3. The animal is marked as recovered
Validation US1 A logged user navigates to animal details page. He clicks the
Scenarios button “Mark as recovered” and the animal is finally marked.
US2 A user navigates to an animal details page that is published by
another user. There is no “Mark as recovered” button.
Table 34. Use case description: Mark an animal as recovered
58
3.6.2.1. Mockups
In this package we add a button on the animal details page to mark an animal as recovered.
Animal details page
Figure 33. Mockups: Animal details page
3.6.2.2. Endpoints
endpoints:
PATCH /animals/{id}
Summary Updates an animal
Request Body:
{
Parameters
"recovered": boolean
}
200 Ok
401 Unauthorized
Response
403 Forbidden
404 Not Found

Table 35. Endpoints: Update an animal
59
3.6.3. Design
We update the animal model to add a new property in order to mark an animal as recovered.
This functionality allows the user to set his animals as recovered. For this reason, the user
must be logged in.
The backend side has an endpoint to update animal values. It gets the animal by id and
checks if the user_id associated to this animal corresponds to the user that is updating the
animal. If they match, the update animal function replaces the current animal values by the
new ones, updating them in the database. This endpoint is the one used by the system to
set the animal as recovered.
In the Frontend, a logged user can mark his animals as recovered in the animal details
page. He can do it by clicking the “Mark as recovered” button, which will only be visible in
his own animals. After this action, a recovered Chip appears next to the others.
3.6.4. Data model

In this package we change the Animal database model adding a recovered column to mark
the animal as recovered. By setting it as false by default, we do not have to change the
insert_animal SQL function, being backwards compatible. When the user marks the animal
as recovered, a query updates the value (setting it as true). The model has changed as the
one below:
Figure 34. Data model: Animal data model update
3.6.4.1. Queries
For this package we modify the Get animals and Get animal by id queries to return the
recovered value. Also, we create an update animal query.
60
Update animal
Allows you to update an animal parameter.
3.7. WP7-Real time alerts

After some research on the technologies involved in this package, we conclude that the
necessary effort to implement these features was underestimated.
Also, while implementing the previous work packages we identified some features that
were not considered, but that we consider essential to the project. More details about these
features can be found in WP10.
With these considerations in mind, we decided to not implement the features described in
this Work Package and leave them for future work. The time and effort will be dedicated to
WP10 instead.
3.8. WP9- User roles

To implement WP8, a way to give more permissions to a user was needed. We define a
new user type called Admin that will have access to more functionality than a regular user.
This work package has been added to provide a solution to this problem.

This work package does not have any new use cases.
3.8.2.1. Mockups
This work package does not contain any changes to the UI.
3.8.2.2. Endpoints
In this package we modify this existent endpoint in order to retrieve the user roles:
GET /users
Request
-
Parameters
{
“name”: string,
200 Ok “username”: string,
Response “id” number,
“roles”: string[]
}

Table 36. Endpoints: Return current logged in user info update
61
3.8.3. Design
To identify a user as an Admin, we will build a simplified Role-based access control system.
Role-based access control (RBAC) is a method for controlling what users are able to do
within a company's IT systems. RBAC accomplishes this by assigning one or more "roles"
to each user, and giving each role different permissions [21].
The implementation will define different roles that can be applied to users. Every user will
have a base “User” role and can have multiple other roles. We will not be implementing a
permissions system; features will be unlocked by role.
To achieve that, the user model has been improved to add user roles. A getRoles function
has been created in the user model, which selects the roles of a user. The
GetUserFromToken function has been updated too, in order to retrieve the user roles.
Initially, we create two roles in the system: User and Admin.
For now, there is no way to modify roles from the website. The change must be done
directly in the database. In the future, this feature can be expanded with a management UI.
The system needs some way to block access to features based on the role of the
authenticated user. To achieve it, we create a new middleware in the API called
forceAdminMiddleware. This middleware checks if the current user has the admin role
assigned and aborts the request returning a 403 Forbidden otherwise. By implementing it
as a middleware, we will be able to add it to all the endpoints that need role protection in
an easy and modular way.
The middleware will not be used anywhere for now. We just leave it prepared for the next
work packages.
3.8.4. Data model

We create a roles table that contains all the possible roles, and another table that
associates them to users.
Figure 35. Data model: roles data model
62
3.8.4.1. Queries
Get user roles

Allows searching the database for user roles by using their unique id. Used to retrieve an
array of roles with the current user id.
3.9. WP8 – Advanced User Management

We will provide functionalities to Admin users to be able to restrict access to the system to
fraudulent users.

Use case diagram:
Figure 36. Use case diagram: Advanced User Management
Use case description: Ban suspicious users

Summary Mark a user as Banned or Trusted
Actors Admin
2. The user must have an Admin role
Triggers User clicks the happy/bad face icon in the admin page
Main Flow 1. User navigates to admin page
2. User clicks the happy/bad face icon in the admin page
3. The data is sent, and the user is deleted from the table
Validation US1 A user with Admin role navigates to admin page. He clicks the
Scenarios happy/bad face icon. After that, the user is deleted from the
table.
Table 37. Use case description: Ban suspicious users
3.9.2.1. Mockups
In this package we add an admin page to view the suspicious users and mark them as
banned/trusted.
63
Admin page
Figure 37. Mockups: Admin page
3.9.2.2. Endpoints
endpoints:
PATCH /users/{id}
Summary Updates a user
Request Body:
{
Parameters
"status": string
}
200 Ok
401 Unauthorized
Response
403 Forbidden
404 Not Found

Table 38. Endpoints: Update a user
64
GET /users/by-status
Summary Returns users by status

Query params:
Request {
Parameters "status": string | string[]
}
[
{
200 Ok “id” number,
“status”: string
Response }
]
401 Unauthorized User not logged in
403 Forbidden
Table 39. Endpoints: Return users by status
In this package we modify this existent endpoint in order to retrieve the user status:
GET /users

Request
-
Parameters
{
“name”: string,
200 Ok “id” number,
Response
“roles”: string[],
“status”: string
}
Table 40. Endpoints: Return current logged in user info update
3.9.3. Design
Detecting suspicious users
When uploading an animal, an image is provided by the user. In this package we add a
hasInappropriateContent function in the image recognition model to check if this image
contains inappropriate content. In case the image contains it, the user is marked as
suspicious in the database and informed by email. We keep the content in the database to
be reviewed by an Admin, but it does not get published.
65
The behaviour of the upload animal content can be seen in the following flowchart.
Figure 38. Design: Upload animal behaviour
The hasInappropriateContent function uses the SafeSearch Detection function from

Google Cloud Vision, which detects explicit content such as adult content or violent content
within an image. This feature uses five categories (adult, spoof, medical, violence,
and racy) and returns the likelihood that each is present in a given image [22]. After some
test, we decided to use adult, medical, violence and racy categories with likelihood set as
“LIKELY” and “VERY_LIKELY”. We also decide to discard spoof category as it was giving
us too many false positives.
Ban suspicious users

We need to provide a way to ban suspicious users. This feature should only be visible for
Admin users. We will use the getUserByStatus endpoint to retrieve all suspicious users
and display them in a list. We will use the updateUser endpoint to update the status
accordingly.
66
These endpoints will expose sensible information about users, and will allow to block their
accounts if necessary. We need some protection so only Admin user can use them. We
will add the forceAdminMiddleware implemented in WP9, to ensure that only admin users
will be able to use these endpoints.
In the Frontend side, we design a new screen to show a table with the suspicious users.
This page is only visible for the Admin users, which will mark the user as Banned or Trusted.
After setting a new status for a user, it will be removed from the table.
3.9.4. Data model

We create a new table in the database containing all possible status for user. Initially, it will
contain three values: trusted, suspicious and banned. All users will be trusted by default.
To associate a user with a status, we need to modify the users table adding a status_id.
To be able to have content in the database that is not visible, we need to modify the animals
table adding a published field. We also need to update the create animal SQL function to
accept the published field.
The schemas are shown below:
Figure 39. Data model: Animal data model update
Figure 40. Data model: User data model update
67
3.9.4.1. Queries
We modify get user by id, get user by username or email, get animals, insert animal and
update user queries. Also, we create a get user by status query:
Get user by status

Allows searching the database for users using their status. Used to retrieve an array of
users with the status that comes in the URL parameter.
3.10. WP10 – User experience

This package includes some features that were not considered in the initial proposal. They
were identified while working on the project, and we consider them essential enough to
modify the proposal. To be able to fit these features into the work schedule, we needed to
postpone WP7.
Right now, there is no way for a user to contact another user in case we recognize an
animal. The purpose of Where is my pet is to be able to recover missing pets, and that
cannot be accomplished without this feature. It is also not possible to see your own animals
after uploading them, or to save an animal in case you want to see it later.
This package will solve all these problems.

Use case diagram:
Figure 41. Use case diagram: User Experience
68
Use case description: Contact another User
Summary Send a message to a user that has an animal uploaded
Actors User
2. The user must be trusted
3. The user must not be the owner of the animal
Triggers The user clicks on the “Contact user” button
Main Flow 1. The user navigates to an animal details page
2. The user clicks on the “Contact user” button
3. A modal is displayed to input the message
4. The user fills the message and clicks the send button
5. The message is sent
Validation US1 A user navigates to an animal details page. He clicks on the
Scenarios “Contact user” button. A modal is displayed, and the user
writes a text in the text box. Finally, the user clicks on send
button and the message is sent.
Table 41. Use case description: Contact another User
Use case description: See notifications

Summary Users can see notifications about their activity in the system
Actors User
Preconditions The user must be logged in
Triggers User navigates to Notifications page
Main Flow 1. The user navigates to the notifications page
2. The user sees his notifications
Alternate flows 2. The user does not have notifications yet
a. A “no notifications yet” message is displayed on the
screen
3. The user clicks on a notification that has a link
a. The user is redirected to the link
Validation US1 A user navigates to Notifications page. The user can see his
Scenarios notifications.
Table 42. Use case description: See notifications
Use case description: View own animals

Summary See all registered animals by the current user
Actors User
Triggers User navigates to “My profile” page
Main Flow 1. User navigates to “My profile” page
2. The user can see his animals
Alternate flows 2. The user did not upload any animal yet
a. A “no animals yet” message and “Upload an animal”
button are displayed
69
b. The user clicks the button and is redirected to upload
animal page
Validation US1 A user that has registered animals navigates to “My profile”
Scenarios page. The user sees his registered animals.
US2 A user that has not registered animals navigates to “My profile”
page. A message suggesting him to upload one animal by
clicking the “Upload an animal” button is displayed. After
clicking it, the user is redirected to the upload animal page.
Table 43. Use case description: View own animals
Use case description: Bookmark animals

Summary Bookmark animals that are not uploaded by the current user
Actors User
2. The user must be trusted
3. The user must not be the owner of the animal
Triggers User navigates to “My profile” page and clicks on the bookmarks tab
Main Flow 1. User navigates to “My profile” page and clicks on the
bookmarks tab
2. The user can see his bookmarked animals
Alternate flows 2. The user did not bookmark animals yet
a. A “no bookmarked animals yet” message and “Search
Animals” button are displayed
b. The user clicks the button and is redirected to view
animals page
Validation US1 A user navigates to “My profile” page. The user sees his
Scenarios bookmarked animals.
US2 A user navigates to “My profile” page. A message suggesting
him to bookmark some animal by clicking the “Search Animals”
button is displayed. After clicking it, the user is redirected to the
view animals page.
Table 44. Use case description: Bookmark animals
Use case description: Sidebar

Summary Create a sidebar to improve navigation between pages
Actors User
Preconditions -
Triggers User clicks on the sidebar button
Main Flow 1. User clicks on the sidebar button
2. Sidebar appears
3. User clicks on a sidebar link
Alternate Flow 3. User do not want to click on a link
a) User clicks outside the sidebar
b) The sidebar disappears
70
Validation US1 A user wants to navigate to a page and clicks in the sidebar
Scenarios button. The sidebar appears in the screen. The user clicks on
the desired link and is redirected to another page.
US2 A user wants to navigate to a page and clicks in the sidebar
button. The sidebar appears in the screen. The user do not find
the desired link and clicks outside the sidebar. The sidebar
disappears.
Table 45. Use case description: Sidebar
3.10.2.1. Mockups
In this package we add 3 new UI features:
• A button to contact a user on the Animal Details page. It allows a user to send a
message to another user.
• A notifications page that allows a user to see information about his activity in the
system.
• A sidebar with links to the different screens of the application to make navigation
easier.
• A user profile page, which has two tabs: registered animals and bookmarks.
o Registered animals tab shows the uploaded animals by the current user.
o Bookmarks shows animals that have been bookmarked by the current user.
Sidebar
Figure 42. Mockups: Sidebar
71
My profile page
Figure 43. Mockups: My profile page
Animal details page
Figure 44. Mockups: Animal details page
72
Notifications page
Figure 45. Mockups: Notifications page
3.10.2.2. Endpoints
endpoints:
POST /bookmarks/{animalId}
Summary Creates a bookmark
Request
-
Parameters
200 Ok
Response 401 Unauthorized
403 Forbidden
Table 46. Endpoints: Create a bookmark
DELETE /bookmarks/{animalId}
Summary Deletes a bookmark
Request
-
Parameters
200 Ok
403 Forbidden
Table 47. Endpoints: Delete a bookmark
73
GET /bookmarks
Summary Gets all bookmarked animals for the current user
Request
-
Parameters
[
{
“id”: number,
"status": string,
"species": string,
"breed": string,
"size": string,
"color": string,
"name": string,
"gender": string,
200 Ok “publication_date”: string,
Response "age": number,
"lat": number,
"lng": number,
"image_name": string,
“recovered”: boolean,
“published”: boolean,
“bookmark”: boolean
}
]
401 Unauthorized
Table 48. Endpoints: Get all bookmarked animals for the current user
GET /notifications
Summary Returns all notifications of a specific user
Request
-
Parameters
[
{
"id": number,
"user_id": number,
"message": string,
200 Ok "link": string,
Response
"read": boolean,
"publication_date": string
}
]
401 Unauthorized
Table 49. Endpoints: Return all notifications of a specific user
74
PATCH /notifications/{id}
Summary Updates a notification
Request Body:
{
Parameters
“read”: boolean
}
200 Ok
404 Not Found

Table 50. Endpoints: Update a notification
GET /animals/uploaded
Summary Returns all animals uploaded by the authenticated user
Request
-
Parameters
[
{
“id”: number,
"status": string,
"species": string,
"breed": string,
"size": string,
"color": string,
"name": string,
"gender": string,
"lat": number,
"lng": number,
}
]
401 Unauthorized
Table 51. Endpoints: Return all animals uploaded by the authenticated user
75
POST /users/{id}/contact
Summary Send email to a user
Body:
{
Request
“phone”: boolean,
Parameters
“email”: boolean,
“message”: string
}
200 Ok
401 Unauthorized
Response
403 Forbidden
404 Not Found

Table 52. Endpoints: Send email to a user
In this package we modify this existent endpoint in order to retrieve the animal bookmark:
GET /animals/{id}
Summary Returns a specific animal
Request
-
Parameters
{
“id”: number,
"status": string,
"species": string,
"breed": string,
"size": string,
"color": string,
"name": string,
"gender": string,
"lat": number,
"lng": number,
}
404 Not Found

Table 53. Endpoints: Return a specific animal update
76
3.10.3. Design
Contact User
For the contact user feature, we add a new button in the Animal Details page. This button
will appear to all users, logged in or not, in any animal except the ones that the current user
has uploaded.
This button toggles a modal with a simple form, where the user can write the text. If the
user is not logged in, we display the login modal first. We allow the user to include his/her
phone number in the email, so the other user can answer.
When this form is submitted to the API, an email is sent to the user. No data about this
interaction is stored in the database.
Notifications
Every time an action is taken in the system, that potentially affects a user, a notification will
be created and displayed to him. This feature includes a new data model (see next section),
two new endpoints and a new screen.
Notifications will have a message to explain the user what happened. They can also contain
a link, so the user can click on it and navigate to another page.
To make sure the user sees the notifications, they will be highlighted in the sidebar when
they are new. We consider that a notification is new by default, and it loses the “new” status
after the user reads it. When this happens, we use the update notification endpoint to
update the read flag.
We consider a notification has been read if:
• The user clicks on it if it has a link.
• The user stays more than 5 seconds in the notifications screen.
The application will fetch notifications when the user first enters the website (if it is already
logged in), when he logs in, and every 15 minutes if the user keeps using the app.
Here is a list of all the actions that trigger a notification:
• Uploading an animal
• Contacting a user
• Being banned or flagged as suspicious by the image recognition system
• Marking an animal as recovered
• Receiving an email from another user
Bookmarks
This feature will allow a user to easily find animals that he previously found in the system,
without the need of searching for them again. We add a new button in the animal card,
which allows the user to “bookmark” the animal.
77
Bookmarked animals will appear in the new Profile page. To implement this, we create 2
new endpoints, and a new table in the database.
To display the animals, we will be reusing the animal list and animal card components.
View uploaded animals

Until now, there was no way to see the animals that the user uploaded onto the system. To
solve this, we create a new endpoint to recover this information. No changes to the
database are needed, as we already have the relation between user an animal.
This information will be displayed in the profile page. We will be reusing the animal list and
animal card components.
3.10.4. Data model

We define two new tables in the database. The first one, Notifications, stores information
about user notifications (message, link, timestamp and read / unread) and links it to the
user.
The second table, Bookmarks, creates a relation between a user and animals. The user
can add animals to this table by “bookmarking” them.
Figure 46. Data model: Bookmarks and Notifications data models
78
3.10.4.1. Queries
Get animals by user id

Allows searching the database for animals by using the user id.
Get notification by id
Allows searching the database for a notification by using their unique id.
Get notifications by user id

Allows searching the database for notifications by using the user id.
Insert notification
Allows you to insert in the database a new notification.
Update notification
Allows you to update a notification parameter. Used to mark a notification as read.
Delete bookmark
Allows you to delete a bookmark from the database.
Insert bookmark
Allows you to insert in the database a new bookmark.
4. Results
It has been implemented a final solution that includes:
• An API written in NodeJS.
• A web application build in React.
• A PostgreSQL database.
For image recognition we use Google Cloud Vision. We use Typescript as the programming
language, SQL for querying the database, and HTML and CSS to build the frontend
screens.
We implemented all the essential features that were set as our goals. These are:
• Upload animals
• Creating an account
• Set animals as “recovered”
• Notifications
• Search and view animals
• Block users
Halfway through the development, we identified some features that were not initially
considered. These are:
• Contacting other users
• Users with more permissions (user roles)
79
We also decided to implement some extra features to improve user experience, such as:
• Bookmarks
• User profile page
• Sidebar
All the code for this project is open sourced and can be found in the following links:
Backend: https://github.com/mbassas/where-is-my-pet-backend
Frontend: https://github.com/mbassas/where-is-my-pet-frontend
In both repositories a v1.0 tag is created with this final thesis code.
4.1. Frontend
Here we present screenshots of the final version of the web application.
Home
Search animals page
80
Animal Details Page
Upload Animal page
81
Sidebar
82
Ban users
Sign In
83
Reset password
Notifications
84
4.2. Backend
The full API documentation can be found here:
https://where-is-my-pet.herokuapp.com/api-docs/
4.3. Database
This is the full database model:
Figur. Full data model
85
5. Budget
In this section, we analyse all the costs incurred in the development of this project. These
costs can be classified in two main categories: infrastructure (servers and providers) and
personal (salaries).
The costs outlined in the infrastructure section are estimates. Until now, there has not been
any costs associated to this category. All these providers offer a free tier that worked good
enough for the development process. In case we wanted to start using the project with real
users, the infrastructure costs would start applying.
Right now, we use free tiers for Google Cloud Vision and Heroku hosting. To be able to put
the project in production, we need to set up the professional tiers of these services.
The pricing for these services is explained below. For now, we will keep the free tier as the
project is not going to production.
5.1. Infrastructure Pricing Estimates
• Heroku
We need to set up two servers for the API. It will ensure availability, as the system can still
work with only one server. Heroku itself is recommending this approach in their pricing
page [23]. To distribute the work between the two servers, Heroku automatically adds a
load balancer.
We will also need a PostgreSQL database. For now, the base tier with 64gb storage will
be enough. These are monthly rates. This means that these costs apply each month that
the service is running.
2 Web Dynos | Standard | 512mb RAM for the API

2 x 25$= 50$
Table 54. Budget: Virtual server
1 PostgreSQL | Standard | 4gb RAM / 64gb Storage

1 x 50$= 50$
Table 55. Budget: Database
• Google Cloud Vision
The image recognition APIs we use provide 1000 requests for free each month. After that,
the cost is 1.50$ per 1000 requests. Uploading an animal uses two requests to the service.
Searching by photo uses one.
Cost will vary depending on the user activity in the system and will increase with our user
base. We can expect the cost to be zero, or close to zero, at least for the first year. The
pricing can be found at Google Cloud Vision pricing page [24].
86
• Domain Name
Right now, we are using the default domain provided by github pages (github.io). Using a
custom domain would help making the product look more professional and have better
score in search engines results.
There are many options to register the domain, and prices will vary depending on the
provider and the chosen domain. For example, using the provider Nominalia.com [25],
whereismypet.es would cost 37,40€ to register, while whereismypet.com would cost more
than 2000€. The renovation of the domain costs 37,40€ plus taxes per year.
5.2. Salary
The biggest cost factor of this project is the salary of a developer. We calculate an average
of 4,5 hours for each day of the duration of the project at a rate of 10€/hour.
1 Software engineer
10€/hour x 4,5hours x 122 days = 5490€
Table 56. Bugdet: Salary
5.3. Total cost
As we mentioned above, we are still using the free tiers for the infrastructure. This means
that there has been no cost for the servers or the database during the development process.
Also, we are still using the free domains, so no cost has been made on the domain either.
The total cost of the project has been 5490€, corresponding to the developer salary.
87
6. Conclusions and future development:
6.1. Summary
The purpose of the project was to build a system that unified information about lost pets,
was accessible to people without social networks, worked in all mobile devices and used
technology to automate the recognition of animals using images. We researched about
available technologies and implemented a software system to fulfil all the requirements and
specifications.
We achieved most of the requirements and specifications:
- The system works on any mobile device that has a network connection and a web
browser.
- Users do not need a social network account to use the system. In fact, they do not
need an account at all except for uploading animals or sending messages to other
users.
- The system uses image recognition technology and geolocation to extract
information about the animals, so the users usually do not need to fill most of the
data.
On the other hand, there are a few things that we expected that have not been achieved:
- Our image recognition implementation is not as good as we would like. Right now,
it identifies the species with high accuracy. It also detects dog breeds pretty good
but gives us low accuracy for cats. Our expectations were that it could also identify
the color and the size of the animals.
- In the initial proposal, we defined a real time alerts system where users were notified
if a matching animal was uploaded. This feature was dropped from the final version
due to time constraints, and some non-planned features.
6.2. Recommendations and improvements

We believe that this project serves as a solid foundation, and that could be extended to be
a really useful software. However, as the project was reaching the final state, we identified
areas that could have been better.
For example, from the beginning we assumed that our users should not need social media
accounts. After showing the prototype to some people, there were some bad reactions to
it: they argued that the sign-up form was too long, and that they would probably not fill all
the information.
We extracted some conclusions from this feedback:
- It should be possible to use a social media account to sign in, but also keep the
existing account creation feature without social media. That means that the user
can choose how he wants to access the system.
- The sign-up form could be simplified. The phone number is only being used to
contact other users, so it could be removed from the sign-up and ask it when
needed. Also, we could merge the fields Name and Surname into a single field. This
would reduce the number of fields from 6 to 4, also removing the scroll on smaller
devices, making the form less intimidating.
88
Also, we think that with the current prototype, we could benefit from feedback from animal
shelters. We believe that their feedback would help us improve the functionalities that are
most needed and make us understand better the necessities and requirements to deal with
large numbers of missing pets. Until now, getting this feedback was difficult as the system
was not developed enough.
6.3. Personal experience

Personally, working in the project has helped me understand a full software system. I had
some prior experience in web development, as I had been working as Front-End Intern
while studying the degree, but I never worked with backend technologies or databases.
Designing and implementing this system has proved to be challenging, and taught me a lot
about software design, databases, and web technologies in general. It has also allowed
me to put in practice some cryptography knowledge that I learned in class and see how it
is used in a real-world situation.
It has also helped me improve my research skills and improve my writing. Until now, I was
not used to write about the state of the art, or to research about all the possible technologies
to use. I think it made me improve my critical thinking, and my synthetisation skills.
I value the project very positively, and I am proud of the result.
6.4. Future work

The project can be further extended in many ways. The scope of this project provides a
solid foundation that can be built upon, and we can identity a lot of potential areas of
improvement.
In this section, we explain a few different areas where the system can be improved.
• Real time alerts
• Custom image recognition models
• Features for animal shelters
• Interactive maps
• Better storage for the animal images
Real time alerts

This work was initially planned to be in the scope of the project, as detailed in WP7. It was
dropped due to timings, and other features that were not initially planned. The features
defined in the package were really useful, especially for people that has lost a pet.
Custom image recognition models

In the analysis and benchmark of the image recognition systems, we observed that the
evaluated models were not as accurate as we would like. They provide good capabilities
when identifying species (cats and dogs) and breeds (only dogs) but did not provide any
more information.
89
This can be because the models used are very generic: they can identify lots of different
objects and scenes. We believe that results can be greatly improved by training a custom
model using only animal data.
To be able to train a model like this, a huge amount of training data is needed. We would
need images, and the information about the image: the species, breed, age and color of
the animals. If the system acquires enough users, this data can be collected over time just
by using the system.
Our idea is that, using the same data that the system is storing in the database, a new
image recognition model could be trained once we have a big enough data set.
Support for animals to adopt

Right now, the system is only focused on missing pets. It could be expanded to allow users
to put animals for adoption, and to search an animal to adopt. It could help animals find a
new home and make it easier for people to search for a new pet. It should be evaluated if
this feature is allowed by local legislation.
Features for animal shelters

Animal shelters would make big contributors to our system. Unfortunately, the system does
not provide a lot of tools to make it easy to manage a large number of animals.
The current feature set of the application is more focused to single users, who are looking
for a missing pet, or have found a single animal. Working with lots of animals would need
to rethink some of the screens and provide better tools for communication.
Interactive maps
The current search screen allows the user to search by location, but only presents results
in a list. While the system provides an estimation of how far each animal is, presenting
them in a map would improve the visualisation.
Better storage for animal images

In WP3, we decided to store the images inside the database. This solution allowed us to
keep the data centralized, and to not have to worry about other storages during the
development.
However, it puts the database under a lot of stress, especially as the number of users
increase. The images could be moved to another storage solution, such as Amazon S3 or
Google Cloud Storage, and serve them from a Content Delivery Network.
90
Bibliography
[1] "What is Client-Server Architecture?", W3schools.in, 2020. [Online]. Available:
https://www.w3schools.in/what-is-client-server-architecture/. [Accessed: 11- Mar- 2020].
[2] Mobile app", En.wikipedia.org, 2020. [Online]. Available:
https://en.wikipedia.org/wiki/Mobile_app#Native_app. [Accessed: 12- Mar- 2020].
[3] "Single-page application", En.wikipedia.org, 2020. [Online]. Available:
https://en.wikipedia.org/wiki/Single-page_application. [Accessed: 12- Mar- 2020].
[4] “gh-pages", npm, 2020. [Online]. Available: https://www.npmjs.com/package/gh-pages. [Accessed:
12- Mar- 2020].
[5] "REST Resource Naming Guide - REST API Tutorial", Restfulapi.net, 2017. [Online]. Available:
https://restfulapi.net/resource-naming/. [Accessed: 09- Mar- 2020].
[6] R. Fielding, "Architectural Styles and the Design of Network-Based Software Architectures", Doctoral
dissertation, University of California, Irvine, 2000.
[7] "GraphQL: A query language for APIs.", Graphql.org, 2020. [Online]. Available: https://graphql.org/.
[Accessed: 10- Mar- 2020].
[8] "What is a relational database?", Oracle.com, 2020. [Online]. Available:
https://www.oracle.com/database/what-is-a-relational-database/. [Accessed: 13- Mar- 2020].
[9] E. Codd, "A Relational Model of Data for Large Shared Data Banks", Communication of the ACM,
vol. 13, no. 6, pp. 377-387, 1970. [Accessed 13 March 2020].
[10] "DB-Engines Ranking", DB-Engines, 2020. [Online]. Available: https://db-engines.com/en/ranking.
[11] "SQL", En.wikipedia.org, 2020. [Online]. Available: https://en.wikipedia.org/wiki/SQL. [Accessed: 13-
Mar- 2020].
[12] "SQL", En.wikipedia.org, 2020. [Online]. Available:
https://en.wikipedia.org/wiki/SQL#Interoperability_and_standardization. [Accessed: 13- Mar- 2020].
[13] "What Is A Non-Relational Database?", MongoDB, 2020. [Online]. Available:
https://www.mongodb.com/non-relational-database. [Accessed: 14- Mar- 2020].
[14] "Big data", En.wikipedia.org, 2020. [Online]. Available: https://en.wikipedia.org/wiki/Big_data.
[15] "Bases de datos no relacionales | Bases de datos de gráficos | AWS", Amazon Web Services, Inc.,
2020. [Online]. Available: https://aws.amazon.com/es/nosql/. [Accessed: 14- Mar- 2020].
[16] "Schema migration", En.wikipedia.org, 2020. [Online]. Available:
https://en.wikipedia.org/wiki/Schema_migration. [Accessed: 14- Mar- 2020].
[17] "db-migrate", npm, 2020. [Online]. Available: https://www.npmjs.com/package/db-migrate.
[18] M. Jones, J. Bradley and N. Sakimura, "RFC 7519 - JSON Web Token (JWT)", Tools.ietf.org, 2015.
[Online]. Available: https://tools.ietf.org/html/rfc7519. [Accessed: 25- Mar- 2020].
[19] D. Arias, "Hashing in Action: Understanding bcrypt", Auth0 - Blog, 2018. [Online]. Available:
https://auth0.com/blog/hashing-in-action-understanding-bcrypt/#L-code-bcrypt--code--Best-
Practices. [Accessed: 25- Mar- 2020].
[20] "Calculate Distance by Latitude and Longitude using PostgreSQL", GeoDataSource. [Online].
Available: https://www.geodatasource.com/developers/postgresql. [Accessed: 12- May- 2020].
[21] "What is role-based access control (RBAC)?", https://www.cloudflare.com, 2020. [Online]. Available:
https://www.cloudflare.com/learning/access-management/role-based-access-control-rbac/.
[Accessed: 04- Sep- 2020].
[22] "Detect explicit content (SafeSearch) | Cloud Vision API | Google Cloud", Google Cloud, 2020.
[Online]. Available: https://cloud.google.com/vision/docs/detecting-safe-search. [Accessed: 11- Sep-
2020].
[23] "Pricing | Heroku", Heroku.com, 2020. [Online]. Available: https://www.heroku.com/pricing.
[Accessed: 07- Oct- 2020].
[24] "Pricing | Cloud Vision API | Google Cloud", Google Cloud, 2020. [Online]. Available:
https://cloud.google.com/vision/pricing. [Accessed: 07- Oct- 2020].
91
[25] "Los precios de Nominalia", www.nominalia.com, 2020. [Online]. Available:
https://www.nominalia.com/quienes-somos/precios/. [Accessed: 07- Oct- 2020].
[26] "Apache Cordova", En.wikipedia.org, 2020. [Online]. Available:
https://en.wikipedia.org/wiki/Apache_Cordova. [Accessed: 06- Oct- 2020].
[27] "React Native · A framework for building native apps using React", Reactnative.dev, 2020. [Online].
Available: https://reactnative.dev/. [Accessed: 07- Oct- 2020].
[28] "@hapi/joi", npm, 2020. [Online]. Available: https://www.npmjs.com/package/@hapi/joi. [Accessed:
07- Oct- 2020].
[29] "StatCounter Global Stats - Browser, OS, Search Engine including Mobile Usage
Share", StatCounter Global Stats, 2020. [Online]. Available: https://gs.statcounter.com/. [Accessed:
06- Oct- 2020].
[30] "How To Safely Store A Password", codahale.com, 2020. [Online]. Available:
https://codahale.com/how-to-safely-store-a-password/. [Accessed: 13- Mar- 2020].
[31] "pg-large-object", npm, 2020. [Online]. Available: https://www.npmjs.com/package/pg-large-object.
[Accessed: 16- Apr- 2020].
[32] "Material-UI: A popular React UI framework", Material-ui.com, 2020. [Online]. Available:
https://material-ui.com/. [Accessed: 08- Oct- 2020].
[33] "Material Icons", Material Design, 2020. [Online]. Available:
https://material.io/resources/icons/?style=baseline. [Accessed: 05- Oct- 2020].
[34] Typescriptlang.org, 2020. [Online]. Available:
https://www.typescriptlang.org/docs/handbook/tsconfig-json.html. [Accessed: 06- Oct- 2020].
[35] "express-jsdoc-swagger", Brikev.github.io, 2020. [Online]. Available: https://brikev.github.io/express-
jsdoc-swagger-docs/#/. [Accessed: 05- Oct- 2020].
[36] "React Router: Declarative Routing for React", ReactRouterWebsite, 2020. [Online]. Available:
https://reactrouter.com/. [Accessed: 04- Oct- 2020].
[37] "Cross-origin resource sharing", En.wikipedia.org, 2020. [Online]. Available:
https://en.wikipedia.org/wiki/Cross-origin_resource_sharing. [Accessed: 04- Oct- 2020].
[38] A. Reinman, "Nodemailer :: Nodemailer", Nodemailer.com, 2020. [Online]. Available:
https://nodemailer.com/about/. [Accessed: 02- Oct- 2020].
[39] "multer", npm, 2020. [Online]. Available: https://www.npmjs.com/package/multer. [Accessed: 05-
Oct- 2020].
[40] "Nominatim", Nominatim.org, 2020. [Online]. Available: https://nominatim.org/. [Accessed: 04- Oct-
2020].
92
Appendices
Comparison between image recognition systems:
Google Cloud Vision:
Image name: Animal species Animal breed Animal color Animal size Expected result Obtained result
Image1 5 5 0 1 12 11
Image2 5 4 0 0 12 9
Image3 5 5 0 0 12 10
Image4 5 5 0 0 12 10
Image5 5 5 0 0 12 10
Image6 5 0 0 0 12 5
Image7 5 5 0 0 12 10
Image8 5 3 0 0 12 8
Image9 5 5 0 0 12 10
Image10 5 5 0 0 12 10
Image11 5 0 0 0 12 5
Image12 5 5 0 0 12 10
Image13 5 3 0 1 12 9
Image14 5 4 0 0 12 9
Image15 5 5 0 -1 12 9
Image16 5 4 0 1 12 10
Image17 5 0 0 1 12 6
Image18 5 5 0 0 12 10
Image19 5 5 0 0 12 10
Image20 5 5 0 1 12 11
Image21 5 4 0 0 12 9
Image22 5 5 0 1 12 11
Image23 5 5 0 1 12 11
Image24 5 5 0 0 12 10
Image25 5 5 0 0 12 10
Image26 5 5 0 0 12 10
Image27 5 5 0 1 12 11
Image28 5 5 0 0 12 10
Image29 5 5 0 0 12 10
Image30 5 2 0 0 12 7
Image31 5 4 0 1 12 10
Image32 5 2 0 1 12 8
Image33 -1 0 0 0 12 -1
Image34 5 5 0 1 12 11
Image35 5 4 0 1 12 10
Image36 5 5 0 1 12 11
Image37 5 2 0 1 12 8
Image38 5 2 0 1 12 8
Image39 5 0 0 0 12 5
Image40 5 5 0 1 12 11
Image41 5 5 0 1 12 11
Image42 5 3 0 1 12 9
Image43 5 5 0 1 12 11
Image44 5 0 0 1 12 6
Image45 5 5 0 0 12 10
93
Image46 5 5 0 1 12 11
Image47 5 5 0 0 12 10
Image48 5 5 0 0 12 10
Image49 5 4 0 1 12 10
Image50 5 5 0 0 12 10
Image51 5 3 0 0 12 8
Image52 5 5 0 0 12 10
Image53 5 2 0 0 12 7
Image54 5 0 0 0 12 5
Image55 5 5 0 1 12 11
Image56 5 5 0 1 12 11
Image57 5 5 0 1 12 11
Image58 5 0 0 1 12 6
Image59 5 5 0 0 12 10
Image60 5 5 0 0 12 10
720 549
Table 57. Appendices: Google Cloud Vision
Amazon Rekognition:
Image1 5 0 0 0 12 5
Image2 5 3 0 0 12 8
Image3 5 3 0 0 12 8
Image4 5 0 0 0 12 5
Image5 5 5 0 -1 12 9
Image6 5 0 0 0 12 5
Image7 5 4 0 -1 12 8
Image8 5 5 0 0 12 10
Image9 5 5 0 0 12 10
Image10 5 2 0 0 12 7
Image11 5 5 0 0 12 10
Image12 5 5 0 0 12 10
Image13 5 0 0 0 12 5
Image14 5 5 0 0 12 10
Image15 5 5 0 0 12 10
Image16 5 0 0 1 12 6
Image17 5 0 0 1 12 6
Image18 5 5 0 0 12 10
Image19 5 0 0 0 12 5
Image20 5 5 0 0 12 10
Image21 5 4 0 0 12 9
Image22 5 0 0 0 12 5
Image23 5 0 0 0 12 5
Image24 5 5 0 0 12 10
Image25 5 5 0 -1 12 9
Image26 5 5 0 0 12 10
Image27 5 0 0 0 12 5
Image28 5 4 0 0 12 9
Image29 5 0 0 0 12 5
Image30 5 0 0 -1 12 4
Image31 5 0 0 0 12 5
94
Image32 5 0 0 -1 12 4
Image33 -1 0 0 0 12 -1
Image34 5 0 0 0 12 5
Image35 5 0 0 0 12 5
Image36 5 0 0 0 12 5
Image37 5 0 0 -1 12 4
Image38 5 0 0 0 12 5
Image39 5 0 0 0 12 5
Image40 5 0 0 0 12 5
Image41 5 0 0 -1 12 4
Image42 5 0 0 0 12 5
Image43 5 0 0 0 12 5
Image44 5 0 0 1 12 6
Image45 5 0 0 -1 12 4
Image46 5 0 0 0 12 5
Image47 5 0 0 0 12 5
Image48 5 4 0 0 12 9
Image49 0 0 0 0 12 0
Image50 5 2 0 0 12 7
Image51 5 2 0 0 12 7
Image52 5 0 0 0 12 5
Image53 5 5 0 0 12 10
Image54 5 0 0 0 12 5
Image55 5 0 0 0 12 5
Image56 5 0 0 -1 12 4
Image57 5 0 0 0 12 5
Image58 5 0 0 0 12 5
Image59 5 0 0 0 12 5
Image60 5 0 0 -1 12 4
720 375
Table 58. Appendices: Amazon Rekognition
Computer Vision:
Image1 5 0 1 1 12 7
Image2 5 0 0 -1 12 4
Image3 5 2 1 -1 12 7
Image4 5 5 1 -1 12 10
Image5 5 0 1 -1 12 5
Image6 5 0 0 -1 12 4
Image7 5 2 1 -1 12 7
Image8 5 0 1 0 12 6
Image9 5 0 1 -1 12 5
Image10 5 2 1 0 12 8
Image11 5 5 1 0 12 11
Image12 5 5 1 0 12 11
Image13 5 0 1 -1 12 5
Image14 5 0 0 0 12 5
Image15 5 0 1 0 12 6
Image16 5 0 1 1 12 7
Image17 5 0 1 1 12 7
95
Image18 5 4 1 0 12 10
Image19 Size limit exceeded 12 0
Image20 5 0 -1 0 12 4
Image21 5 0 0 0 12 5
Image22 5 5 0 -1 12 9
Image23 5 5 0 -1 12 9
Image24 5 5 1 0 12 11
Image25 5 5 1 -1 12 10
Image26 5 0 1 -1 12 5
Image27 5 4 0 -1 12 8
Image28 5 0 1 0 12 6
Image29 5 5 -1 0 12 9
Image30 5 5 1 0 12 11
Image31 5 4 0 -1 12 8
Image32 5 0 0 -1 12 4
Image33 -1 0 1 -1 12 -1
Image34 5 4 0 -1 12 8
Image35 5 0 0 1 12 6
Image36 5 0 0 -1 12 4
Image37 5 0 0 -1 12 4
Image38 5 0 0 -1 12 4
Image39 5 0 0 0 12 5
Image40 5 0 0 -1 12 4
Image41 5 0 0 -1 12 4
Image42 5 0 0 -1 12 4
Image43 5 0 0 -1 12 4
Image44 5 0 1 1 12 7
Image45 5 5 1 -1 12 10
Image46 5 0 1 -1 12 5
Image47 5 0 0 -1 12 4
Image48 5 -1 1 -1 12 4
Image49 5 0 0 0 12 5
Image50 5 0 0 0 12 5
Image51 5 4 0 0 12 9
Image52 5 0 1 0 12 6
Image53 5 0 1 -1 12 5
Image54 5 0 0 0 12 5
Image55 5 0 1 1 12 7
Image56 5 0 0 -1 12 4
Image57 5 0 0 1 12 6
Image58 5 0 1 -1 12 5
Image59 5 -1 0 0 12 4
Image60 5 0 1 -1 12 5
720 366
Table 59. Appendices: Computer Vision
96
Glossary
SMTP: Simple Mail Transfer Protocol
RBAC: Role-Based Access Control
IDE: Integrated Development Environment
HTML: Hypertext Markup Language
CSS: Cascading Style Sheets
PWA: Progressive Web Application
SPA: Single Page Application
HTTP: Hypertext Transfer Protocol
API: Application Programming Interface
REST: Representational State Transfer
SQL: Structured Query Language
ISO: International Standardization Organization
ANSI: American National Standards Institute
MVC: Model View Controller
URL: Uniform Resource Locator
JWT: JSON Web Token
JSON: Javascript Object Notation
OID: Object Identifier
97

WhereIsMyPet-Final Thesis

Uploaded by

Copyright:

Available Formats

You might also like

WhereIsMyPet-Final Thesis

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

WhereIsMyPet-Final Thesis

Uploaded by

Copyright:

Available Formats

Where is my pet?

A global solution for locating lost pets

Advisor: Israel Martín Escalona

Barcelona, June 2020

Revision Date Purpose

0 22/03/2020 Document creation

1 09/04/2020 Document revision

2 28/09/2020 Document revision

3 10/10/2020 Document revision

4 11/10/2020 Final document

DOCUMENT DISTRIBUTION LIST

Montserrat Bassas Cordoba montsebassas.mb@gmail.com

Israel Martín Escalona israel.martin@upc.edu

Written by: Reviewed and approved by:

Date 22/03/2020 Date 11/10/2020

Name Montserrat Bassas Cordoba Name Israel Martín Escalona

Position Project Author Position Project Supervisor

1.1. Project Purpose

1.2. Project Background

1.3. Requirements and specifications

1.4. Work plan

1.4.1. Work packages

Project: User Management WP ref: 2

Project: Upload an animal WP ref: 3

Project: View animals WP ref: 4

Project: Animal Status WP ref: 6

Project: Real time alerts WP ref: 7

Project: Advanced User Management WP ref: 8

Project: User roles WP ref: 9

Project: User Experience WP ref: 10

WP Task Short title Milestone / deliverable Date (week)

2 6 User User management functionality. Week 5

Figure 1. Gantt diagram: WP1 and WP2

Figure 2. Gantt diagram: WP3 and WP4

Figure 3. Gantt diagram: WP5, WP6 and WP9

1.5. Deviations and incidences

3. Methodology / project development:

3.1. WP1 – Infrastructure

Figure 5. Infrastructure: Client-server system propose

3.1.1.1. State of the art

3.1.1.2. Technology choices

Figure 7. Frontend: source code design

3.1.2.1. State of the art: Backend

GET /animals Get information about all animals in the system.

GET /animals/{animalId} Get information about a single animal.

POST /animals Create a new animal in the system.

PUT /animals/{animalId} Update an existing animal

DELETE /animal/{animalId} Delete an existing animal from the system.

query { Fetches the property name of all animals in the

query { Fetches the name property of a single animal

mutation { Creates a new animal in the system, and fetches

mutation { Updates an existing animal and fetches the field

3.1.2.2. State of the art: Database systems

3.1.2.3. Technology choices

Figure 8. Backend: API design

Figure 9. Backend: migration example

3.2.1. Functional Analysis

Figure 10. Use case diagram: User Management