# FLIP: A New Approach for Easing the Use of Federated Learning
## 3 Design and Implementation  
The first step in designing a software solution is the definition of use cases. Use cases can be interpreted as a set of holistic functional requirements that ignore the actual implementation of the system and focus only on the interactions a potential end user may have with the system. As a FL system that should manage both the node federation itself and the execution of federated tasks, the following use cases are expected:  
* Plan/Schedule federated task: the creation of a new federated task (FL task) relates to the definition of the parameters required for performing a training. The crucial parameters to define are the model, the data source, and the source code of the algorithms for the flower network and strategy (server and client). * Access training results: once training has finished, the updated model and the files related to execution must be available for the user. * Monitor federated task queue: users can track the list of federated tasks that are awaiting execution, as they have been scheduled, but another training is being performed already. * Cancel a federated task: a task that was already scheduled but not finished can be cancelled if the execution is not relevant any more. * Validation of algorithms uploaded for federated task: as the source code is requested to establish the federated training, an inspection of the code must be performed to avoid malignant intentions must be performed. * Manage users and authentication: access to the platform requires identification to track user activity and filter the content for each profile, and the management of these users and their roles is also required. \begin{table}
\begin{tabular}{c c c c c c c c} \hline \hline \multirow{2}{*}{**Frameworks**} & \multirow{2}{*}{\begin{tabular}{c} **Docs:** \\ **1–5** \\ \end{tabular} } & \multirow{2}{*}{\begin{tabular}{c} **Containerized:** \\ **Y/N** \\ \end{tabular} } & \multirow{2}{*}{\begin{tabular}{c} **Extendability:** \\ **1–5** \\ \end{tabular} } & \multirow{2}{*}{\begin{tabular}{c} **Graphical User** \\ **Interface: Y/N** \\ \end{tabular} } & \multicolumn{2}{c}{\begin{tabular}{c} **Encrypted** \\ **Distributed** \\ **Communications:** \\ **Y/N** \\ \end{tabular} } & \multicolumn{2}{c}{\
\begin{tabular}{c} **Production** \\ **Ready: Y/N** \\ \end{tabular} } & \multicolumn{2}{c}{
\begin{tabular}{c} **ML** \\ **Framework** \\ **Agnostic: Y/N** \\ \end{tabular} } \\ \hline Fate & 3 & Y & 4 & Partial & Y & Y & Partial \\ \hline EasyFL & 4 & Y & 4 & N & N & N \\ \hline Fed-BioMed & 4 & Y & 3 & N & Y & Y & Partial \\ \hline Flower & 4 & N & 5 & N & Y & N & Y \\ \hline
**FLIP (ours)** & - & Y & 5 & Y & Y & Y & Y \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Comparison between several near-production-ready frameworks and our solution. * Manage client nodes and addition: configuration and addition of client nodes to the federated network is necessary to dynamically add new data spaces. * Manage environment and setup: initial setup and configuration must be completed previously in order to deploy the platform and being able to work with it. It is also important to note that the main and basic functionality of the platform is to orchestrate FL tasks. To coordinate this, tasks are executed sequentially in the order in which they were stacked in the queue, to avoid the use of shared resources that can disrupt the network. Once the training plan is defined and the federated task is scheduled, the uploaded algorithms must be validated in order to queue the federated task. To setup a federated network in which FL techniques can be applied, several factors must be taken into account. One of the most relevant issues is the need of integrating the data science process to plan the training (define the model and the dataset/datasets used) with the network and system resources administration, as these resources should be distributed correctly.