fyp-report/report/design.tex

\section{Service Design} \label{sec:sd}
	This chapter presents an idealised design, such design is open-ended to allow for multiple possible implementations that still meet the project requirements.
	This idealised design is also envisioned to not be limited by time or engineering constraints.
	The chapter \ref{sec:si} will discuss in more details how this design was further scoped to be able to be implemented in the timeframe available.
	This chapter will transform the requirements discussed in the previous chapter into a more specialized technical design that can be used as a guide to implement such a service.

	\subsection{Structure of the Service}

		The service is designed to be a 4 tier structure:
		\begin{itemize}
			\item{Presentation Layer}
			\item{API Layer}
			\item{Worker Layer}
			\item{Data Layer}
		\end{itemize}

		This structure was selected because it allows separation of concerns.
		The layers were separated based on what resources are required by that layer.

		The presentation layer requires interactivity of the user, and therefore it needs to be accessible from the outside, and be simple to use.
		The presentation layer was limited from being any interaction method to be a web page.
		The web page can a separate server, or as part of the main API application, if it is in the same.
		The API layer, is one of the most important parts of the service.
		As it will be the most used way to interact with the service.
		The user can use the API to control their entire model process from importing, to classification of images. 
		The Worker layer, consists of a set of servers available to perform GPU loads.
		The Data layer, consists of stored images, models, and user data.

	
	\subsection{Interacting with the service}
		As a software platform, this project requires a way for users to interact with the service.
		This interface is mainly intended to be as a control and monitoring interface.
		The user would use the interface to set up and manage the models, then most of the interactions would happen via the API.

		While there were no specific restrictions on what the interface can be, it makes most sense for it to be a web page.
		This is because most software as a service applications are controlled with web pages, and the API is already a web-based application.

		Independently of the kind of the application is, it needs to allow users to fully control their data in an easy to use and understand way.
		The application should allow users to:
		%TODO add more
		\begin{multicols}{2}
			\begin{itemize}
			    \item Manage access tokens.
			    \item Upload images for training.
			    \item Delete images.
			    \item Request training model.
			    \item Delete models.
				\item Classify Images.
				\item See previous classification results
				\item Keep track of model accuracy
			\end{itemize}
		\end{multicols}

		Aside from being able to perform the above tasks, there are no restrictions on how the application needs to be architected.

	\subsection{API}
		As a SaaS, 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 API needs to be able to perform all the tasks that the application can do, which include:
		% TODO maybe remove
		\begin{multicols}{2}
			\begin{itemize}
			    \item Manage access tokens.
			    \item Upload images for training.
			    \item Delete images.
			    \item Request training model.
			    \item Delete models.
				\item Classify Images.
				\item See previous classification results
				\item Keep track of model accuracy
			\end{itemize}
		\end{multicols}

		While implementing all the features that mentioned above, the API has to handle multiple simultaneous requests.
		Ideally, those requests should be handled as fast as possible.
		The API should be implemented such that it can be easily expandable and maintainable, so that future improvements can happen.
		It should be consistent and easy to use, information on how to use the API should also be available to possible users.
		The API should be structured as a REST JSON API, per the requirements.
		The API should only accept inputs via the URL parameters of GET requests or via JSON on POST requests.
		Binary formats can also be used to handle file upload and downloads, as transferring files via JSON extremely inefficient.

	\subsection{Generation of Models}
		The service should use any means available to generate models, such means can be:
		\begin{multicols}{2}
			\begin{itemize}
			    \item Templating.
			    \item Transfer Learning.
				\item Database Search.
				\item Pretrained Models with classification heads.
			\end{itemize}
		\end{multicols}


	\subsection{Models Training}
		% The Training process follows  % TODO have a flow diagram

		Model Training should be independent of image classification. A model training should not affect any current classification. The system could use multiple ways to achieve this, such as:
		\begin{multicols}{2} % TODO think of more ways
			\begin{itemize}
			    \item Separating the training to different machines.
			    \item Control the number of resources that training machine can utilise
				\item Control the time when the shared training and inference machine can be used for training.
				\item Allow users to have their own ``Runners'' where the training tasks can happen.
			\end{itemize}
		\end{multicols}


	\subsection{Summary}
		This chapter introduced multiple possible designs options for a service, that intends to achieve automated image classification, can follow to implement a robust system.  The next chapter will be discussing how the system was implemented and which of the possible design options were chosen when implementing the system.

\pagebreak