more work on report
All checks were successful
continuous-integration/drone/push Build is passing

This commit is contained in:
Andre Henriques 2024-03-13 22:26:48 +00:00
parent e59cdd33e6
commit 80012a14cd
3 changed files with 103 additions and 53 deletions

View File

@ -1,27 +0,0 @@
direction: right
User: "Authenticated User" {
shape: Person
}
User->Login: "User Signs In"
User->Register: "User Registers"
App: "Web APP"
Login->App: "User uses the App"
Register->App: "User uses the App"
Token: "Generate API Token"
Login->Token
Register->Token
Server: "User' Servers" {
shape: Cloud
}
Token->Server: "User Provides Token"
User->Server: "User controls Server"
Server->API: "Users' Servers Interact with API"

23
diagrams/models_flow.d2 Normal file
View File

@ -0,0 +1,23 @@
direction: right
User: "Authenticated User" {
shape: Person
}
ModelCreation: "Model Creation"
ImageUpload: "Image Upload"
TrainModel: "Train Model"
EvaluateModel: "Image Upload"
User->ModelCreation: "User creates the model"
ModelCreation->ImageUpload
User->ImageUpload: "User uploads Images"
ImageUpload->TrainModel
User->TrainModel: "Requests the training of the model"
TrainModel->TrainModel: Failed to train
TrainModel->EvaluateModel
User->EvaluateModel: "Request class for an image"

View File

@ -336,7 +336,7 @@
This section will discuss the design of the service.
This section will discuss the design decissions for the web aplication, API.
This section will discuss the design decisions for the web application, API.
\subsection{Structure of the Service}
@ -370,65 +370,119 @@
The web application (WEB App) is the chosen GUI to control the service.
This subsection discusses details of the workdflows and implementation of the application.
This subsection discusses details of the workflows and implementation of the application.
\subsubsection*{Implementation Details}
The web application uses the API to controll the functiononality of the service, this design is advanatagues because it allows users of the application do everything that the application does with the API, which is ideal in a SaaS project.
The Web APP is a single-page application (SPA).
The SPA architecure is one of the most prevelant architetures that exists nowadays.
It allows for the fast transistions between pages without having a full reload of the browser happening.
The SPA architecture is one of the most prevalent architectures that exists nowadays.
It allows for the fast transitions between pages without having a full reload of the browser happening.
Since this in project the API and the Web APP are seperated it makes the use of server side rendering more complex and less eficient as the server would have to first request the API for information build the web page and then send it to the users' device.
Therefore the system will use client side rendering only, allowing for the users' device to request the API directly for more information.
Since this in this project the API and the Web APP are separated, it makes the use of server-side rendering more complex and less efficient.
As the server would have to first request the API for information to build the web page and then send it to the users' device.
Therefore, the system will use client-side rendering only, allowing for the users' device to request the API directly for more information.
There exist currelnty many frameworks to create SPAs.
There exist currently many frameworks to create SPAs.
I selected Svelte \cite{svelte} for this project.
I sellected Svelte because it's been one of the most liked frameworks to work with in the last years, acordiningly to the State of JS survey \cite{state-of-js-2022}.
It's also one of the best performant frameworks that is surrently available that has extermiy good performance \cite{js-frontend-frameworks-performance}.
I selected Svelte because it's been one of the most liked frameworks to work with in the last years, accordingly to the State of JS survey \cite{state-of-js-2022}.
It's also one of the best performant frameworks that is currently available that has extremity good performance \cite{js-frontend-frameworks-performance}.
I also already have experience with Svelte.
I will be using Svelte with the SvelteKit framework \cite{svelte-kit} which gratelly improves the devloper expirience.
Svelkit allows for the easly creating for SPA with a good default web router.
I will be using Svelte with the SvelteKit framework \cite{svelte-kit} which greatly improves the developer experience.
The staic adapter will be used to generate a static HTML and javascrip files and they will be hosted by an NGINX proxy \cite{nginx}.
\subsubsection*{Service authetication}
SvelteKit allows for the early creating for SPA with a good default web router.
The static adapter will be used to generate a static HTML and JavaScript files, and they will be hosted by an NGINX proxy \cite{nginx}.
The web application uses the API to control the functionality of the service, this design is advantages.
It allows users of the application to do everything that the application does with the API, which is ideal in a SaaS project.
\subsubsection*{Service authentication}
\begin{figure}[h!]
\centering
\includegraphics[width=\textwidth]{service_authentication}
\caption{Simpleified Diagram of User Authenticationm}
\caption{Simplified Diagram of User Authentication}
\label{fig:simplified_auth_diagram}
\end{figure}
The user uses an email and password to Sign In or Register with the application.
This is send to the server and stored in a user account.
This is sent to the server and stored in a user account.
The Password is stored hashed using bcrypt \cite{bycrpt}.
In the future other methods of authentication might be provided; like using Googles' OAuth.
Once logged In the user will be able to use the application and manage tokens that where emited for this application.
Once logged In, the user will be able to use the application and manage tokens that were emitted for this application.
This allows the user to manage what services have access to the account and the usage that those services have used.
The User can emit new tokens that can be used in the users services to request the calssification of images.
The User can emit new tokens that can be used in the users services to request the classification of images.
\subsubsection*{Model Management}
\begin{figure}[h!]
\centering
\includegraphics[width=\textwidth]{service_authentication}
\caption{Simpleified Diagram of Model management}
\includegraphics[width=\textwidth]{models_flow}
\caption{Simplified Diagram of Model management}
\label{fig:simplified_model_diagram}
\end{figure}
\subsection{Application Programming Interface}
As the diagram, \ref{fig:simplified_model_diagram} shows the steps that the user takes to use a model.
First, the user creates the model.
In this step, theImplementation Details user uploads a sample image of what the model will be handling.
This image is used to define what the kinds of images the model will be able to intake.
Currently, the system does not support resizing of images that are different from the one uploaded at this step during evaluation.
This was done to guarantee that the image that the user want to classify is unmodified.
Moving the responsibility of cropping and resizing to the user.
In the future, systems could be implemented that allow the user to select how an image can be cropped.
The second step is uploading the rest of the dataset.
The user uploads a zip file that contains a set of classes and images corresponding to that class.
That zip file is processed and images and classes are created.
Alternatively, the user can use the API to create new classes and upload.
After all the images that are required for training are uploaded, the user can go to the training step.
During this step, the system automatically trains the model.
After the system trains a model that meets the specifications set by the user, the system will make the model available for the user to use.
When the model is finished training, the user can use the model to run inference tasks on images.
\subsection{API}
As a software as a service, one of the main requirements is to be able to communicate with other services.
The API provides the simplest way for other services to interact with this service.
The current main way that servers communicate over the internet is using https and a rest JSON API\cite{json-api-usage-stats}.
The API provides a various HTTPS REST JSON endpoints that will allow any user of the service to fully control their model using only the API.
\subsubsection*{Implementation Details}
\subsection{Generation Models}
The API will run a go \cite{go} http server.
This server will take JSON and multipart form data requests, those requests will be processed, and they will respond with JSON.
The multipart requests are required due to JSON's inability to transmit binary data, which will make the uploading of images extremely inefficient.
Those images would have to be transformed into binary data and then uploaded as a byte array or encoded as base64 and uploaded.
Either of those options is extremely inefficient.
Therefore, there is a need to use multipart form requests are required to allow the early uploading of binary files.
Go was selected as the langunage to implement the backend due various of its' advantages.
Go has extermily fsat compilations which allows for rapid development, and iteration.
Go has a very mininal runtime which allows it to be faster, than hevy runtime languages such as javascript.
It is also a very simple language which helps maintain the codebase.
The Go languange integrates well with C libraries which allows it access to machine learning libraries like TensorFlow.
\subsubsection*{Authentication}
For an user to be authenticated with the server it must first login.
During the login process the service checks to see if the user is regsitered and if the password provided during the login matches the stored hash.
Upon veryifying the user a token is emmited.
That token can be used on the header ``token'' as proff that the user is authenticated.
\subsection{Generation of Models}
The system requires the generation of models \ref{fig:expandable_models_generator}. Generating all models based on one single model would decrease the complexity of the system, but it would not guarantee success.
The system needs to generate successful models, to achieve this, the system will be performing two approaches:
@ -506,7 +560,7 @@
\begin{center}
\includegraphics[height=0.8\textheight]{expandable_models_generator}
\end{center}
\caption{Contains an overall view of the model genration system}\label{fig:expandable_models_generator}
\caption{Contains an overall view of the model generation system}\label{fig:expandable_models_generator}
\end{figure}