Département TIC

Filière Informatique

Orientation Logiciel

Travail de Bachelor

MyWorkoutPlan - Application de planification d'entrainements pour les sportifs

Non confidentiel

Étudiant : Alexandre Simik

Travail proposé par : Alexandre Simik

Enseignant responsable : Jürgen Ehrensberger

Année académique : 2020-2021

Yverdon-les-Bains, le 30 juillet 2021

Page 1 sur 59

Département TIC

Filière Informatique

Orientation Logiciel

Étudiant Alexandre Simik

Enseignant responsable Jürgen Ehrensberger

Travail de Bachelor 2020-2021

MyWorkoutPlan - Application de planification d'entrainements pour les sportifs

Résumé publiable

MyWorkoutPlan est un carnet d’entrainement informatisé pour les sportifs. Il est conçu sous la forme d’une application multi-tiers, avec un front-end PWA (Progressive Web Application), construit avec Nuxt (Vue) et un back-end Spring Boot.

Actuellement, la majorité des programmes de musculation que l’on trouve sur le Web sont sous la forme d’un fichier Excel et cela qu’ils soient payants ou gratuits. De plus, les solutions proposées sur le marché n’offrent pas la possibilité de structurer les entrainements avec une liberté suffisante ou ne sont pas multiplateformes.

Ce travail de Bachelor répond à ces besoins en offrant une solution simple, où l’utilisateur est libre de structurer et planifier son entrainement comme il l'entend, puis de visualiser ses résultats à l’aide de diverses statistiques.

Étudiant :

Simik Alexandre

Date et lieu :

30 juillet 2021, Grandvaux

Signature :

……………………………………

Enseignant responsable :

Ehrensberger Jürgen

Date et lieu :

……………………………………

Signature :

……………………………………

Page 2 sur 59

Préambule

Ce travail de Bachelor (ci-après TB) est réalisé en fin de cursus d’études, en vue de l’obtention du titre de Bachelor of Science HES-SO en Ingénierie.

En tant que travail académique, son contenu, sans préjuger de sa valeur, n'engage ni la responsabilité de l'auteur, ni celles du jury du travail de Bachelor et de l'Ecole.

Toute utilisation, même partielle, de ce TB doit être faite dans le respect du droit d’auteur.

HEIG-VD

Le Chef du Département

Yverdon-les-Bains, le

Page 3 sur 59

1 Cahier des charges

1.1 Énoncé

Le but de ce travail de bachelor est de réaliser une plateforme pour sportifs qui permet de planifier ses entrainements, ainsi que de relever ses résultats, pour pouvoir optimiser la progression à long terme. Il s'agit d'une version informatisée d'un carnet d'entrainement.

Dans un premier temps, la plateforme serait orientée pour les sports liés à l'haltérophile (Bodybuilding, Powerlifting, Strongman, Fitness, Crossfit, ...). L'infrastructure logicielle derrière sera une application multi-tiers). Le back-end sera le coeur de l'application et implémente la majorité des fonctionnalités. Plusieurs front-ends sont possibles, notamment une application mobile ainsi qu'une application Web pour pouvoir bien s'intégrer dans le monde actuel.

À long terme on peut très facilement imaginer étendre cette plateforme avec des fonctionnalités de coaching. Il y aurait des utilisateurs de type "coach" et d'autres de type "client" ou "athlète". Ainsi le coach aurait un retour exact des performances de l'athlète et une influence directe sur la structure de l'entrainement à venir.

1.2 Cahier des charges (Original de GAPS)

Les étapes principales du projet sont:

- Analyse et conception générales - Conception détaillée des composants

- Front-end mobile - Back-end (API REST) - Stockage des données

- Choix des technologies à utiliser - Développement d'un MVP et test. - Implémentation itérative de l'ensemble des fonctionnalités définies. - Déploiement du système, tests et documentation.

Page 4 sur 59

2 Table des matières

Table des matières 1 Cahier des charges ................................................................................................................................................ 3

1.1 Énoncé .......................................................................................................................................................... 3

1.2 Cahier des charges (Original de GAPS) ......................................................................................................... 3

2 Table des matières ................................................................................................................................................ 4

3 Introduction .......................................................................................................................................................... 6

3.1 Contexte ....................................................................................................................................................... 6

3.2 Disciplines touchées ..................................................................................................................................... 6

3.3 Entrainement de musculation ...................................................................................................................... 7

4 Analyse et Conception .......................................................................................................................................... 8

4.1 Besoin des utilisateurs .................................................................................................................................. 8

4.2 Objectifs ........................................................................................................................................................ 9

4.2.1 Objectifs fonctionnels ........................................................................................................................... 9

4.2.2 Objectifs non fonctionnels .................................................................................................................... 9

4.2.3 Objectifs bonus (Nice to have) ............................................................................................................. 9

4.2.4 Non objectifs ......................................................................................................................................... 9

4.3 Conception générale simplifiée .................................................................................................................. 10

4.4 Technologies choisies ................................................................................................................................. 10

4.4.1 Stockage des données et modèle ....................................................................................................... 10

4.4.2 Back End .............................................................................................................................................. 10

4.4.2.1 Spring Boot ..................................................................................................................................... 11

4.4.2.2 Spring Security ................................................................................................................................ 11

4.4.2.3 Spring Data JPA ............................................................................................................................... 12

4.4.3 Front End ............................................................................................................................................ 12

4.4.3.1 PWA ................................................................................................................................................ 13

4.4.3.2 Vue .................................................................................................................................................. 14

4.4.3.3 Nuxt ................................................................................................................................................ 15

4.4.3.4 Vuex ................................................................................................................................................ 17

4.4.3.5 TypeScript ....................................................................................................................................... 18

4.4.4 Communication End to End ................................................................................................................ 20

4.4.4.1 OpenApi .......................................................................................................................................... 20

4.5 Conception générale complète .................................................................................................................. 21

4.5.1 Schéma global détaillé ........................................................................................................................ 21

4.5.2 Schéma UML des entités JPA .............................................................................................................. 22

4.6 Risques ........................................................................................................................................................ 24

Page 5 sur 59

5 Réalisation ........................................................................................................................................................... 24

5.1 Outils de développement ........................................................................................................................... 24

5.1.1 Maven avec Spring Boot DevTools ..................................................................................................... 24

5.1.2 Visual Studio Code .............................................................................................................................. 24

5.1.3 Firefox Developper Edition ................................................................................................................. 25

5.1.4 Vue Devtools ....................................................................................................................................... 25

5.1.5 Postman .............................................................................................................................................. 25

5.1.6 MySQL Workbench ............................................................................................................................. 26

5.2 Approche de développement ..................................................................................................................... 26

5.3 Produit minimum viable ............................................................................................................................. 26

5.3.1 Fonctionnalités ................................................................................................................................... 27

5.3.2 Pile technologique .............................................................................................................................. 27

5.3.2.1 Squelette du code ........................................................................................................................... 27

5.3.2.2 Authentification .............................................................................................................................. 31

5.3.3 Exemple d’implémentation bout à bout ............................................................................................ 33

5.3.3.1 Spécification OpenAPI .................................................................................................................... 33

5.3.3.2 Back-End ......................................................................................................................................... 34

5.3.3.3 Front-End ........................................................................................................................................ 39

5.3.4 Difficultés ............................................................................................................................................ 45

5.3.5 Analyse du résultat ............................................................................................................................. 45

5.3.6 Conclusion .......................................................................................................................................... 45

5.4 Produit complet .......................................................................................................................................... 46

5.4.1 Fonctionnalités ................................................................................................................................... 46

5.4.2 Approche itérative .............................................................................................................................. 47

5.4.2.1 Planification et Réalisation des entrainements .............................................................................. 47

5.4.2.2 Reste de l’application ..................................................................................................................... 50

5.4.3 Difficultés et alternatives .................................................................................................................... 51

5.4.4 Conclusion .......................................................................................................................................... 51

5.5 Tests finaux ................................................................................................................................................. 52

6 Conclusion ........................................................................................................................................................... 53

6.1 Perspectives ................................................................................................................................................ 53

7 Bibliographie ....................................................................................................................................................... 54

8 Authentification .................................................................................................................................................. 55

9 Liste des figures .................................................................................................................................................. 56

10 Journal de travail................................................................................................................................................. 57

Page 6 sur 59

3 Introduction Dans cette introduction, nous allons décrire les objectifs de ce TB et fournir les explications nécessaires à la compréhension du lecteur. Il faut par exemple avoir une brève introduction au domaine métier pour comprendre comment fonctionne un entrainement de musculation.

3.1 Contexte

Ce Travail de Bachelor est un sujet libre que j’ai moi-même proposé. En effet, le sport et les entrainements de musculation font partie intégrante de ma vie. Cela fait maintenant 6 ans que j’en pratique et je peux dire que je suis passionné. Durant cette période, j’ai compris qu’en plus de la rigueur et la discipline, le suivi des entrainements est une tâche difficile.

Actuellement, la plus grande partie des entrainements gratuits ou payants, que l’on trouve sur le Web, proposent de suivre la progression sous la forme d’un fichier Excel. Malheureusement, cela manque de clarté et n’est pas du tout « user-friendly ». Il existe des plateformes pour structurer son entrainement de musculation, mais la plupart sont payants ou n’offrent pas la capacité de structurer l’entrainement comme on voudrait. C’est pourquoi j’ai décidé de faire moi-même un outil, pour pouvoir structurer et assurer le suivi des entrainements avec plus de facilité et plus de flexibilité.

3.2 Disciplines touchées

Cette application est utilisable dans plusieurs disciplines dérivées de la force athlétique. Voici une liste non exhaustive :

- Fitness - Musculation - Powerlifting - Strongman - Bodybuilding - Force athlétique - Crossfit

Par la suite, nous allons utiliser simplement le terme « musculation » pour désigner l’ensemble de ces disciplines.

Page 7 sur 59

3.3 Entrainement de musculation

Il est nécessaire d’introduire le domaine métier et d’expliquer comment fonctionne un entrainement de musculation dans les grandes lignes, avant de fixer les objectifs à proprement parler.

Généralement, un programme (routine) d’entrainement se compose de plusieurs jours (séances) d’entrainement (généralement on planifie sur 7 jours avec des jours de repos).

Chaque séance est composée de plusieurs séries d’un exercice.

Une série d’un exercice est composée de répétitions à un certain poids. Entre chaque série on prend généralement un temps de pause. On peut mesurer l’intensité d’une série au ressenti de l’athlète, on parle alors de RPE (rate of perceived exertion) ou de RIR (repetitions in reserve).

Généralement le RPE se mesure entre 0 et 10, 10 étant l’échec. On peut convertir RPE en RIR de la manière suivante : un RPE 10 correspond à 0 RIR, RPE 9 = 1 RIR, RPE 8 = 2 RIR et ainsi de suite. On ne descend jamais au-delà de RPE 0 et RIR 10. Pour simplifier ces notions, je vais seulement utiliser la notion de RPE.

Prenons un exemple :

On un un programme qui est constitué de 5 jours d’entrainement et 2 jours de repos. Le jour 1 (lundi) est une séance focalisée sur les jambes qui est composée de 5 exercices. Le premier exercice du lundi est le squat en 5x3, c’est-à-dire 3 séries de 5 répétitions à 180kg. On prendra une pause de 3min entre chaque série.

Figure 1 - Structure simplifiée d'une routine d'entrainement

Page 8 sur 59

4 Analyse et Conception Dans cette partie nous allons faire l’analyse, c’est-à-dire les besoins fonctionnels et non fonctionnels.

4.1 Besoin des utilisateurs

Un utilisateur doit pouvoir faire les tâches décrites ci-dessous :

- Créer un compte sur l’application - Modifier ses informations de base, son profil - Créer, modifier, et utiliser un planning d’entrainements - Pouvoir ajouter un entrainement qui n’est pas planifié - Personnaliser ses exercices, et les mettre dans des catégories - Avoir une liberté dans la structure d’un entrainement - Avoir des statistiques sur ses séances à long terme

Figure 2 - Diagramme Use Case de conception

Page 9 sur 59

4.2 Objectifs

4.2.1 Objectifs fonctionnels

- Créer un compte utilisateur - Modifications du profil - Créer exercices de musculation - Créer un plan d’entrainement - Réaliser un entrainement planifié - Réaliser un entrainement non planifié - Créer des exercices par catégorie - Statistiques des séances

4.2.2 Objectifs non fonctionnels

- Multiplateforme Ordinateur et smartphones (Android et iOS) - Assurer une bonne unicité du code (ne pas écrire deux versions en parallèle pour deux clients)

4.2.3 Objectifs bonus (Nice to have)

- Disponible hors connexion - Possibilité de consulter / partager les entrainements entre les utilisateurs.

4.2.4 Non objectifs

- Stockage sécurisé des données utilisateurs - Guide de la théorie des entrainements (pas un système qui guide l’utilisateur) - Ce n’est pas un réseau social - Application optimisée pour le cloud computing à large échelle - Interface UX / UI irréprochable.

Page 10 sur 59

4.3 Conception générale simplifiée

Le projet dans son ensemble doit pouvoir répondre aux besoins des utilisateurs et les objectifs définis. L’architecture qui en découle doit donc pouvoir satisfaire cela au mieux de la manière la plus efficace possible. À ce stade on sait que ce sera une architecture multi-tiers.

La question qui se pose est au niveau du tiers présentation : Thin Web Client ou Rich Web Client ? On y répondra dans la partie dédiée au front-end.

Figure 3 - Schéma global similifié

4.4 Technologies choisies

4.4.1 Stockage des données et modèle

Les données doivent être stockées de manière robuste et l’on doit éviter la duplication d’informations. Il faut avoir l’atomicité pour avoir des données cohérentes. Il faut donc choisir un SGBD qui offre cela, tout en ayant une facilité pour pouvoir faire des statistiques. De plus le format des données va de pair avec le modèle relationnel.

Le temps imparti pour ce TB ne permettant pas d’apprendre une nouvelle technologie de SGBD, mon choix se porte naturellement sur MySQL. C’est un outil bien maitrisé, que l’on a étudié de long en large dans le cours de BDR (bases de données relationnelles). C’est un outil standard qui a toutes les fonctionnalités dont on a besoin.

À noter qu’on peut tout à fait aussi utiliser MariaDB qui est un équivalent open source de MySql.

4.4.2 Back End

Il faut un serveur pour pouvoir servir les données aux différents clients potentiels de cette architecture multi-tiers. Ici il est nécessaire d’assurer la plus grande simplicité et vitesse de développement ainsi qu’une grande robustesse. C’est le coeur de l’application. Il faut que la principale partie de la sécurité (vérification de la connexion, vérification des entrées utilisateur ...) se fasse ici.

Il existe de nombreuses manières de créer un serveur qui offre un service REST via HTTP.

Le temps imparti ne nous laisse pas une grande marge de manoeuvre pour apprendre de nouvelles technologies. C’est pourquoi mon choix se porte sur un stack technologique, qui offre tout ce dont on a besoin. Je pense à l’écosystème Spring.

Plus précisément Spring Boot avec Spring Web pour les endpoints REST, et Spring Security pour la gestion de l’authentification des utilisateurs. Pour faciliter la création du modèle relationnel et pouvoir le mapper en objet, je vais utiliser Spring Data JPA.

Page 11 sur 59

En effet, c’est une technologie bien connue et maitrisée, après le cours AMT et mon travail en entreprise, c’est un outil que je connais de long en large. Cela m’offrira un développement rapide et efficace pour le coeur de l’application et pour gérer le modèle de données.

4.4.2.1 Spring Boot

Spring est un Framework aux multiples facettes, initialement conçu pour l’inversion de contrôle et l’injection de dépendances, il est aujourd’hui populaire pour faire des applications Web avec des standards de robustesse de niveau entreprise et bien plus.

Spring Boot est un outil qui permet d’accélérer le développement d’applications basées sur Spring, en appliquant le principe suivant convention over configuration, cela permet de gagner du temps dans envirion 90% des cas, lors du choix des paramètres de configuration. Spring Web

Spring Web va nous permettre de créer un service REST et de servir du JSON sur différents endpoints.

4.4.2.2 Spring Security

Spring Security est un outil qui permet de sécuriser des applications et intervient dans l’interaction entre un utilisateur et un programme. Orchestré par le Dispatcher Servlet de Spring qui permet d’adresser les requêtes aux différents contrôleurs de l’application, il ne fait en réalité qu’ajouter des traitements par le biais de Servlet Filters. (Ouidou, 2021)

Les filtres sont centrés autour de 2 concepts fondamentaux :

- Les autorisations : dans une application, tous les utilisateurs n’ont pas forcément le même statut et ainsi les mêmes accès. Par exemple, un administrateur pourrait avoir accès à un panneau d’administration, alors qu’un simple utilisateur non.

- L’authentification : une application nécessite la création d’un compte et donc que l’utilisateur s’authentifie à l’aide d’un pseudo et d’un mot de passe.

1

1 Source : https://spring.io/guides/topicals/spring-security-architecture

L’utilisation de Spring Security n’est pas aussi simple que certains frameworks front-end, mais reste néanmoins très abordable. Finalement, il ne s’agit que d’une succession de filtre et de création de statuts pour les différents utilisateurs.

Page 12 sur 59

4.4.2.3 Spring Data JPA

Spring Data JPA est un ORM (Object Relational Mapper) qui permet de gagner du temps pour créer le modèle relationnel à partir du modèle orienté objet, et cela sans avoir à écrire du code SQL dans la majorité des cas. Il peut s’agir d’une base de données relationnelle, d’une base de données NoSQL, d’un système Big Data ou même d’une API Web. (Gayerie, 2021)

Le principe réside dans une convention de nommage des méthodes d’accès pour exprimer la requête à réaliser. Elle s’organise ainsi autour d’un repository qui fournit une interface pour gérer le type manipulé.

4 : Exemple d'un repository gérant les utilisateurs

User correspond au type géré par le repository, et ID correspond au type qui représente la clé d’un objet. L’interface JpaRepository fournit un ensemble de méthode pour interagir avec la base de données.

4.4.3 Front End

Dans cette partie il est intéressant de se poser plusieurs questions pour pouvoir optimiser le travail. Comment toucher à la fois les plateformes mobiles et les ordinateurs en évitant d’avoir à développer plusieurs clients en parallèle.

Naïvement on a donc besoin d’une application mobile (avec ce que cela implique, iOS et Android, c’est-à-dire une autre duplication potentielle...) et d’un Site Web pour les ordinateurs. On pourrait partir sur une solution qui nous permet d’économiser du code grâce à React Native (ou NativeScript un équivalent), qui permet faire du code iOS et Andoid à partir de JavaScript, puis d’utiliser un outil fourni avec cette technologie pour exporter un code Web réutilisable pour le site internet.

La solution présentée au-dessus est ce à quoi j’aurais pensé avec mes connaissances actuelles. Mais elle me semble délicate et difficile, car on reste face à une duplication de code : site Web et application native. Même si on peut convertir une partie du code, cela reste une contrainte et un potentiel problème pour la maintenance.

Le problème c’est qu’un simple site internet n’offre généralement pas le bon feeling et la bonne expérience aux utilisateurs sur mobile. De plus la solution du site internet reste pertinente, car on n’a pas besoin d’avoir accès à des APIs des systèmes mobiles en particulier.

Page 13 sur 59

4.4.3.1 PWA

Il existe une technologie assez nouvelle qui s’appelle PWA (Progressive Web Application. Si on regarde ce que cela offre :

- Feeling d’une application native sur mobile - Site internet pour les ordinateurs - Possibilité d’être disponible en partie offline - Accès à des APIs du mobile en cas de besoin, par exemples notification, etc.

Cette technologie est en quelques sortes un mélange entre un site Web et une application native. C’est un site Web qui a la particularité d’être très adapté au mobile, en restant parfaitement utilisable sur les ordinateurs.

2

Les PWAs sont d’autant plus impressionnantes qu’il est possible qu’elles reçoivent des notifications push, ou même quelles utilisent des services de géolocalisation.

Comme MyWorkoutPlan est une application qui n’a pas besoin d’être connectée à internet pour fonctionner, mais qu’il est possible de faire évoluer les fonctionnalités en ce sens, il est très intéressant d’en faire une PWA ; les utilisateurs pourraient utiliser correctement l’application, qu’ils soient connectés à internet ou non.

Ainsi, il sera possible de la télécharger sur le téléphone et d’y accéder via l’icône générée.

On n’a pas besoin de toutes les fonctionnalités d’une application mobile native et l’on s’économise beaucoup de travail. Une PWA qui permet de faire mobile et ordinateur en même temps est donc l’idéal. Ce choix est retenu, car il offre tout ce dont on a besoin et il permet d’unifier le code en un seul projet front-end. C’est simplement la meilleure solution.

2 Source : https://web.dev/what-are-pwas/

Les PWAs sont connues pour leur richesse et leur fiabilité ; on les retrouve souvent sur les écrans d’accueil, les docks et les barres de tâches et elles ont la particularité de fonctionner, quelle que soit la connexion réseau. (Web.dev, 2021)

Se lançant dans leur propre expérience autonome, elles peuvent lire et écrire des fichiers à partir du système de fichiers local, ou même accéder à du matériel connecté via port USB.

Accessibles depuis une icône ou un raccourci, elles donnent l’impression de faire partie de l’appareil sur lequel elles sont

é é

Page 14 sur 59

4.4.3.2 Vue

Généralement on utilise un framework ou un langage en particulier pour faire le front-end. De nos jours les front-ends Single Page Application sont de plus en plus à la mode. Les plus grands actuellement sont Angular, React et Vue. Mon choix se portera sur le dernier, car je l’ai déjà utilisé à de nombreuses reprises et je l’apprécie énormément. Il offre tout ce dont j’ai besoin sans compromis.

Vue est un framework JavaScript pour le front-end. Il est similaire à ses deux grands concurrents qui sont Angular et React. De mon point de vue, Vue a été fait par les passionnés du Web et est de loin mon préféré. Il offre une facilité d’apprentissage et d’utilisation qui n’est pas là avec les deux autres.

La conception d’une application Vue est très intuitive. Son système permet de faire le rendu des données de manière déclarative dans le DOM, via la syntaxe suivante :

Chaque composant sera ensuite accessible via un routeur, implémenté dans la composante racine : App.vue

Un composant Vue dispose de 3 parties :

- La partie template, qui contient toutes les balises HTML et permettra d’afficher concrètement les données.

- La partie script, qui contient toute la logique liée au composant. Généralement écrite en JavaScript, on peut également employer TypeScript pour la réaliser.

- La partie style, non obligatoire, qui sert de fiche CSS liée au composant. On peut cependant choisir d’étendre la portée à toute l’application.

Page 15 sur 59

4.4.3.3 Nuxt

Nuxt.js est un framework basé sur Vue.js permettant de développer de manière plus simple avec Vue. (Nuxt, 2021)

Il repose sur une architecture modulaire, permet d’avoir des messages d’erreur plus explicites, dispose d’une documentation détaillée et rend le routing très efficace.

Figure 5 - Composition d'une vue dans Nuxt.js3

Nuxt n’a besoin que des informations contenues dans la section des vues pour configurer une route spécifique. Comme décrit dans un chapitre précédent, les vues se composent d’un template, d’un layout et de la page actuelle. Il est également possible de personnaliser des métatags dans la section head de chaque page, qui sont importants pour le référencement.

Il y a de nombreux avantages à utiliser Nuxt, car il fait beaucoup de choses pour nous, et il apporte une grande robustesse aux projets Vue, car il amène un standard dans la manière de faire des applications avec Vue (structure des dossiers, gestion de l’état, middlewares ...)

Les vrais avantages de Nuxtpour moi sont les suivants :

- Routage automatique en fonction de la hiérarchie fichiers et dossiers dans le dossier pages. - Standard au niveau de la structure des dossiers pour bien organiser son code. - Déploiement simple et plusieurs options au niveau du déploiement (voir sections suivantes) - Import automatique des composants Vue dans les pages.

3 Source : https://develop365.gitlab.io/nuxtjs-1.4.0-doc/fr/guide/views/

Page 16 sur 59

4.4.3.3.1 Rendu côté serveur

Une application a la capacité à générer une page Web sur le serveur au lieu de la générer dans le navigateur. Le rendu côté serveur renvoie ainsi une page complète au client ; le JavaScript côté client prend ensuite le relais et permet à Vue.js d’hydrater notre application.

- Le navigateur commence par envoyer la requête initiale qui sera réceptionnée par le serveur Node.js. Nuxt.js générera alors les HTML et le renverra au navigateur en prenant en compte le résultat de plusieurs fonctions (asyncData, nuxtServerInit, fetch, …) qui seront exécutées.

- Lorsque le navigateur reçoit la page avec le HTML générée depuis le serveur, le contenu est affiché et l’hydratation de Vue.js est réalisée. Cela permet de rendre la page interactive.

- La navigation client ne requiert pas de requête au serveur, sauf si on l’actualise. Cela est possible grâce à <NuxtLink>.

4.4.3.3.2 Génération de site statique

La génération statique permet de générer l’application durant le build et de déployer le site sur n’importe quel hébergeur, que cela soit Github Pages, Infomaniak, etc. En d’autres termes, cela signifie qu’il n’y a pas besoin de serveur pour déployer l’application.

Les pages qui utilisent la propriété « generate.exclude » seront exclues de la génération. Elles profiteront de la version SPA et n’existeront pas sur le CDN. Elles seront régénérées dans le navigateur à chaque fois qu’un utilisateur naviguera sur ces pages.

4.4.3.3.3 SPAs

Nuxt peut cibler plusieurs types de déploiement, dont les Single Page Applications.

Comme expliqué précédemment, les Single Page Applications sont des pages uniquement générées du côté client, sans quelconques besoins du serveur. Déployer une SPA avec Nuxt ne nécessite que de simples configurations :

- Changer le mode à ‘spa’. - Utiliser la commande build pour générer l’application.

Page 17 sur 59

4.4.3.4 Vuex

Vuex est un modèle de gestion d’état utile pour les applications Vue.js. Il sert de « store » centralisé pour tous les composants de l’application et comporte des règles structurant les modifications de l’état.

On peut généraliser la structure d’une application Vue en 3 entités pour expliquer le fonctionnement de l’état :

- L’état, considéré comme la source de « vérité » qui conduit notre application. - La vue, considérée comme le mapping déclaratif de l’état. - Les actions, permettant la modification de l’état (mutations) selon des règles choisies par le développeur.

Figure 6 – Schéma Vuex global4

Le schéma ci-dessus illustre la gestion de l’état selon les interactions des différentes entités de l’application.

Vuex sépare les concepts impliqués dans la gestion de l’état en appliquant des règles qui maintiennent l’indépendance entre les vues et ledit état. Vuex est également une implémentation de bibliothèque conçue spécifiquement pour Vue.js lui permettant d’être plus réactif et de réaliser des mises à jour efficaces.

Lorsque note application grandit, on se retrouve forcément confronté à la gestion de l’état. Voilà pourquoi il est très intéressant de prendre de l’avance et de directement utiliser les bonnes pratiques. Cela justifie l’utilisation de Vuex dans notre projet.

4 Source : https://vuex.vuejs.org/

Page 18 sur 59

4.4.3.4.1 Single State Tree et modules

Vuex n’utilise qu’un seul arbre pour l’état, qui contient tout l’état de l’application. Cela implique qu’il suffit qu’un seul store pour gérer l’application. Cela permet une meilleure maintenance des composants.

Bien entendu il est possible de séparer cet arbre en plusieurs parties (modules) pour simplifier la gestion de l’état. Ainsi chaque module est lié à un aspect bien précis de l’application.

4.4.3.4.2 Mutations

La seule manière de modifier l’état du store est de réaliser une mutation. Les mutations Vuex sont assimilables à des événements ; chacune d’entre elles a un type string et une fonction handler. Cette fonction est l’endroit où l’on réaliser les modifications d’état et vont d’ailleurs recevoir l’état comme premier argument.

4.4.3.4.3 Actions

Très similaires aux mutations, les actions disposent cependant de quelques particularités :

- Au lieu de gérer directement l’état, les actions le transfèrent aux mutations. - Les actions ne peuvent contenir que des opérations asynchrones, telles que des appels à une API. Cela

permet de modifier l’état au moment où de nouvelles données arrivent.

4.4.3.5 TypeScript

TypeScript est un langage de programmation développé par Microsoft en 2012, dont l’ambition est d’améliorer la productivité de développement. (Cellenza.org, 2021)

Open source, il est développé comme une surcouche de JavaScript. Ce qui signifie que tout code valide en JavaScript l’est également en TypeScript. Il introduit des composantes essentielles, comme la programmation orientée objet et le typage.

Ci-dessus, l’on trouve la syntaxe d’une variable string. TypeScript offre un système typé qui ne demande pas de typer explicitement le code. Le langage définira automatiquement le type selon la valeur de la variable.

Les avantages principaux sont le côté prévisible du code. Cela fait gagner du temps , notamment grâce à une meilleure prise en charge de la complétion de code dans les IDEs et une détection des erreurs en avance.

Page 19 sur 59

4.4.3.5.1 Nuxt Property Decorator

Nuxt Property Decorator est un projet open source qui permet de changer de style, lors de l’écriture de Vue et de Vuex. (Github, 2021) Cela permet d’utiliser une syntaxe orientée objet et de manipuler des classes, plutôt que des objets JavaScript. C’est un choix personnel, mais je trouve que l’on gagne grandement en lisibilité et donc en productivité.

Voici la différence entre les deux approches :

Figure 7 - Composant Vue (Syntaxe classique JavaScript)

Figure 8 - Composant Vue (Syntaxe avec Nuxt Property Decorator en TypeScript)

Je trouve que la différence parle d’elle-même. Nuxt Property Decorator apporte un réel avantage.

Page 20 sur 59

4.4.4 Communication End to End

La communication entre le front-end et le back-end est un point crucial dans la conception. En effet on doit pouvoir maintenir une certaine robustesse et ne pas devoir récrire du code inutile si possible.

Pour le choix du langage pour le transfert de données on va utiliser du JSON, car il permet d’être directement utilisé par le client front-end, vu que c’est du JavaScript à la base.

Pour pouvoir garantir l’unicité de l'API, je propose de faire une approche top-down à partir d’une spécification OpenAPI. Ainsi le client et le serveur seront générés avec un outil appelé OpenApi Generator. Cela nous économise beaucoup de temps et surtout évite des erreurs difficiles à trouver à cause d’incohérences dans les API du client et du serveur.

4.4.4.1 OpenApi

La spécification OpenAPI définit un standard, indépendant de n’importe quelle interface d’API RESTful, qui permet à chaque partie de comprendre les capacités du service sans avoir accès au code source ou documentation. Ainsi, le développeur peut comprendre et interagir avec le service en ayant qu’une utilisation minimale de la logique d’implémentation.

4.4.4.1.1 Swagger

Bien connu dès 2010, Swagger était une spécification open source qui permettait de construire des API REST. Petit à petit, plusieurs outils vinrent se greffer à la base pour aider à implémenter et visualiser les API (ex : Swagger Editor, Swagger UI, Swagger Codegen). (Swagger, 2021)

Quelques années plus tard, Swagger est récupéré par Smartbear Software et est renommé OpenAPI. On le définit toujours comme un ensemble d’outils facilitant aux développeurs la conception, le build et la documentation d’API.

Lors de ce travail, l’interface user-friendly de Swagger a surtout été utile pour visualiser toutes les fonctionnalités implémentées de l’API.

4.4.4.1.2 OpenApi Typescript Codegen

OpenAPI Typescript Codegen est une librairie qui génère du code client TypeScript, basé sur une spécification d’API (à partir d’un fichier api.yaml bien formé par exemple).

L’idée d’OTC est de ne pas utiliser de générateur Java dans les builds, pour les développeurs plus axés sur des langages Web comme JavaScript ou TypeScript. En ce sens, il est rapide, léger, robuste et indépendant de n’importe quel framework. (npmjs, 2021)

En plus de supporter la génération de client TypeScript, il supporte également la génération de clients fetch et XHR HTTP. Il suffit de fournir un fichier YAML ou JSON comme entrée, et la commande « generate » s’occupe de générer les différents fichiers nécessaires à la création de l’API.

En regardant son fonctionnement de façon plus détaillée, ce générateur n’exporte que les interfaces des modèles. Elles aideront au développement, mais ne seront pas disponibles en JavaScript pendant le runtime. Cependant, Swagger permet de définir des propriétés qui seront utiles durant le runtime, par exemple : « maxLength » pour un string.

Page 21 sur 59

4.5 Conception générale complète

4.5.1 Schéma global détaillé

Voici la représentation détaillée de l’application dans sa globalité. On y retrouve les différentes entités de l’application.

Figure 9 - Schéma global détaillé de l’application

Page 22 sur 59

4.5.2 Schéma UML des entités JPA

Le schéma UML qui suit représente la modélisation du stockage des données. C’est un schéma UML des entités JPA qui se situe dans la partie model du back-end.

Le schéma se divise en deux parties distinctes qui interagissent ensemble :

- La partie planification - Un Plan (routine) est composé de Weeks, qui est composé de Days (un jour est un entrainement

planifié). - Chaque jour a des séries planifiées avec des paramètres qui représentent l’objectif l’idéal à

atteindre. - La partie réalisation

- Un Workout est un entrainement concret, il est composé de séries concrètes. Cela représente ce qui a été fait.

- Un Workout n’est pas obligé d’être lié à un Day. Cela fait de lui un entrainement non planifié. - Il y a un lien entre Workout et Day et entre PlannedSet et ConcreteSet pour pouvoir lier la

planification à sa réalisation et ainsi voir si les objectifs planifiés sont atteints.

Page 23 sur 59

Figure 10 - UML des entités JPA dans le model du back-end

Page 24 sur 59

4.6 Risques

Risques pour le projet :

- Les PWAs sont un sujet inconnu pour moi, donc apprentissage nécessaire. - Aspect Visual Design (même si c’est un non objectif, il n’est pas facile de faire un travail de design en si peu

de temps) - Question du mode hors connexion. Est-ce que l’app est utile sans ce mode. Comment gérer la

synchronisation des modifications concurrentes sur autre appareil online et sur un autre qui est offline ? - Est-ce qu’on répond bien aux besoins des utilisateurs ? Tests dans le monde réel, avec un utilisateur non-

développeur.

5 Réalisation

5.1 Outils de développement

Nous allons présenter ici les outils principaux qui ont été utilisés dans le développement de toute l’application. Le choix de la plupart de ces outils est à grâce leur popularité ou au fait qu’ils soient open source.

5.1.1 Maven avec Spring Boot DevTools

Spring Boot met à disposition un set d’outils qui rend l’expérience de développement plus efficace. Son utilisation permet d’éviter de relancer le serveur à chaque changement. Toutes les modifications apportées à des fichiers déclencheront des mécanismes liés à Spring DevTools qui redémarrera l’application automatiquement.

L’intérêt principal d’utiliser DevTools est sa parfaite intégration à l’écosystème Spring Boot en plus de sa fonction principale. En outre, il ne nécessite pas l’installation de plug-ins pour les IDE et il est gratuit.

5.1.2 Visual Studio Code

Créé en 2015, Visual Studio Code est un éditeur de code extensible développé par Microsoft pour les trois grands OS : Windows, Linux et macOS. Il ne s’est cependant réellement fait connaitre qu’en 2017.

Muni d’un système d’extensions, il peut être utilisé pour développer avec une multitude de langages de programmation, notamment JavaScript/TypeScript, Java, Node.js, C++ et Go qui sont inclus par défaut. Les autres peuvent être téléchargés gratuitement depuis le Marketplace.

Gratuit et open source, il a également l’avantage d’être très léger et rapide, ce qui le rend très concurrentiel vis-à-vis d’autres grands IDE, comme ceux de la suite JetBrains, qui sont généralement un peu plus lents lorsqu’on les utilise avec de gros projets.

Notre choix s’est porté sur cet éditeur pour plusieurs raisons ; en plus des qualités précitées, c’est un éditeur que nous avons souvent employé par le passé et qui nous a permis de développer de manière très efficace.

Page 25 sur 59

5.1.3 Firefox Developper Edition

Firefox, bien connu du grand public, cache une version réservée aux développeurs nommée en ce sens : Firefox Developer Edition.

Il dispose de tous les derniers outils de développement en version bêta, et de fonctionnalités non présentes sur l’édition normale :

- WebID : outil qui permet de développer, déployer et déboguer des applications Web. Il permet de créer de nouvelles applications Firefox OS à partir d’un modèle ou d’ouvrir son code pour éditer ses fichiers.

- Valence : outil qui permet de développer et de déboguer une application sur plusieurs navigateurs et appareils.

- Feuille de style supplémentaire : une feuille de style supplémentaire est chargée et appliquée. Elle permet un meilleur contrôle des variables CSS et d’autres styles.

- Interface de développement : son interface de développement dispose d’une palette d’outils plus conséquente qui permet notamment de vérifier les données envoyées dans le réseau.

5.1.4 Vue Devtools

Vue DevTools est une extension pour navigateurs Web qui facilite le débogage des applications Vue.js. Elle permet d’inspecter les composants et d’afficher la liste d’événements qui ont été émis par ceux-ci. Ainsi, certaines informations qui étaient difficilement percevables sont visibles en quelques clics.

5.1.5 Postman

Bien connu des développeurs full-stack, Postman est une plateforme d’aide aux tests et développements d’API. Ses fonctions principales sont d’envoyer des requêtes et de recevoir des réponses du back-end.

Son interface claire et efficace permet d’enregistrer et importer une multitude de requêtes et de définir les différents champs nécessaires dans chacune des parties d’une requête, ce qui le différencie grandement de Swagger dont l’interface de test reste très incertaine.

Il dispose également d’une interface de tests préétablis, qui couvre un large spectre du testing.

Page 26 sur 59

5.1.6 MySQL Workbench

MySQL Workbench est un logiciel de gestion et d’administration de bases de données MySQL. Très intuitif, il permet non seulement de créer, modifier et supprimer des tables, mais également d’effectuer toutes sortes d’opérations liées à la gestion de bases de données.

Créé en 2004, MySQL Workbench a une place bien établie sur le podium des gestionnaires de BDD. Constamment mise à jour, il est très fiable et dispose d’une large palette de possibilités pour les développeurs back-end ou full-stack.

5.2 Approche de développement

Chaque développeur a son approche pour réaliser un projet. Nous allons voir le flux de développement utilisé dans la réalisation de ce TB. Les points suivants résument mon procédé:

- Choix d’une fonctionnalité - Modélisation et stockage des données (back end) - Mise à jour de la spécification OpenAPI - Logique des données et gestion de l’état (front end)

Je commence par me concentrer sur une fonctionnalité. Une fois la fonctionnalité bien définie, je regarde comment modéliser les données. Il faut bien réfléchir, pour optimiser le stockage, c’est-à-dire éviter de stocker de choses qui sont calculables, redondantes, etc.

Il faut faire un lien entre le front-end et le back-end, pour ce faire j’utilise la spécification OpenAPI. Cela permet de définir un contrat entre le serveur et le client pour l’échange de données. En plus de cet outil, j’utilise OpenAPI Codegen, qui permet de générer du code client et/ou serveur à partir de la spécification. Dans notre cas, on génère le client en TypeScript et une partie du Serveur en Java (Spring). Au niveau du serveur back-end seules des interfaces sont générées, ainsi il suffit de les implémenter pour y ajouter toute la logique de stockage et de sécurité.

Une fois la partie stockage et modèle de données établie, je complète donc la spécification OpenAPI pour établir une base de communication. Je travaille ensuite à partir de cette base pour mettre en place la logique des données au niveau du front-end (par exemple gestion du state dans Vuex). Pour finir, je crée la partie présentation des données. Pour ce faire, j’ai à disposition Vuetify qui me donne une base de composants visuels qui sont responsive et prêts à l’emploi.

5.3 Produit minimum viable

Dans cette partie, nous allons parler du produit minimum viable ou MVP (pour Minimum Vivable Product en anglais). En d’autres mots c’est une version très simple de l’application avec certaines fonctionnalités bien définies. Le but ici est de pouvoir se rendre compte vite des éventuelles faiblesses du projet à travers une implémentation bout à bout de ces fonctionnalités.

Page 27 sur 59

5.3.1 Fonctionnalités

Les fonctionnalités du MVP sont les suivantes :

- Une personne peut accéder au site et voir les pages publiques. - Cette personne peut créer un compte et devenir un utilisateur. - Un utilisateur peut se connecter et accéder aux fonctionnalités privées - Les fonctionnalités privées sont de pouvoir créer, afficher, modifier et supprimer des exercices - Les exercices ont une catégorie. - On peut créer, afficher, modifier et supprimer les catégories.

Figure 11 - Diagramme Use Case du Produit Complet

5.3.2 Pile technologique

Cette section va détailler les choix technologiques et comment ils sont utilisés. Le but étant de mieux comprendre le fonctionnement autant bien dans son ensemble que dans ses détails

5.3.2.1 Squelette du code

Le squelette du code est une partie cruciale de la réalisation. Il est difficile de tout bien mettre en place la première fois, car le reste du développement sera basé sur les choix faits dans cette étape.

Page 28 sur 59

5.3.2.1.1 Organisation des dossiers

Figure 12 - Hiérarchie des dossiers et fichiers

Le code est structuré de la manière suivante. Il y a un dossier backend pour le contenu du serveur et un dossier frontend pour le contenu du client.

Regardons le contenu du dossier backend. C’est une configuration classique d’un projet Spring Boot. On retrouve le fichier pom.xml qui est utilisé par Maven pour build l’application. Ensuite nous avons le dossier src qui contient les fichiers sources Java et les fichiers de configuration. Le dossier resources contient un des fichiers principaux, c’est-à-dire api.yaml, qui est le fichier qui définit la spécification OpenApi. Il constitue le coeur de la communication de l’application. Le fichier application.properties, quant à lui est un simple fichier de configuration pour Spring Boot.

Parlons maintenant de commet je structure mon application au niveau des packages ch/heigvd/myworkoutplan/ (on parle de package, car on est dans un projet java, mais en réalité les packages correspondent à des dossiers). J’applique les bonnes pratiques apprises au cours AMT (Applications Multi-Tiers). Ce sont des concepts qui viennent du DDD (Domain-driven design). J’aimerais surtout mettre en avant les deux-points les plus importants c’est-à-dire le principe de « single responsibility » et « separation of concerns ». Le but étant d’assurer une grande modularité et réutilisabilité du code.

Ainsi j’ai séparé le mon code dans las packages suivants :

- config contient toutes les configurations via annotations Java. Le sous-package security contient les classes qui définissent comment est gérée l’authentification des utilisateurs. (Plus de détails à ce sujet dans la

Page 29 sur 59

section dédiée.) Un autre sous dossier est schedule qui contient des tâches à exécuter périodiquement ou une fois au lancement du serveur.

- controller contient les classes qui font office de contrôleurs. Ce sont des endpoints HTTP qui implémentent les interfaces générées dans la spécification OpenAPI.

- mapper ce sont des entités qui s’occupent de faire le mapping Entity -> DTO ou inversement. - model ce dossier contient les entités JPA qui représentent la modélisation qui sera utilisée pour le stockage. - repository ce dossier contient les interfaces Spring Data JPA, qui permettent d’accéder aux entités stockées

dans la BDD. (C’est notamment les méthodes CRUD) - service les services sont le coeur de la logique de mon application. C’est le seul moyen de manipuler les

entités. En d’autres termes un service va s’occuper de faire le lien entre le Controller et le Repository au moyen des entités du modèle, tout en respectant la logique voulue. J’ai fait le choix de placer toute la logique dans les services, cela fait un modèle anémique (sans aucune logique et sans méthodes à l’intérieur).

Le dossier front-end contient un projet Nuxt. C’est un projet qui utilise Node.js d’où la présence du fichier package.json. Le dossier api contient les fichiers générés par OpenAPI Codegen qui constituent le client pour la communication avec le back-end. Le dossier components contient les composants Vue qui ne sont pas liés au state.

middleware contient des outils internes qui aident Nuxt à faire des tâches répétitives.

Pages contient les pages du site Web généré par Nuxt. Il faut savoir que le nom des dossiers et des fichiers inclus dans ce répertoire a de l’importance, car Nuxt utilise des conventions pour le routage par exemple.

Le dossier store est un point crucial dans le projet front-end, car il contient la gestion du state avec Vuex. En d’autres termes, c’est ici que se passent toute la logique et l’organisation des données, ainsi que les requêtes faites au back-end.

Le dossier utils contient des fichiers utilitaires qui aident à faire des tâches variées. Cela offre une bonne modularité au code et simplifie la vie au développeur.

Page 30 sur 59

5.3.2.1.2 Schéma de séquence bout à bout

Le schéma suivant illustre l’interaction entre les différentes couches de l’application. On voit comment se passe le flux lors d’une interaction de l’utilisateur. Il s’agit d’un schéma simplifié pour mieux comprendre de quoi en parle. Par exemple Spring Security a été omis, car il s’intègre de manière transparente. Il se manifeste seulement lorsqu’une requête non autorisée survient.

Figure 13 - Interaction entre les différentes couches bout à bout

Page 31 sur 59

Par la suite nous allons voir, pour chaque couche de l’application, comment cela se passe au niveau du code, à travers un exemple lié à une entité bien définie. (Exemple d’implémentation bout à bout)

5.3.2.2 Authentification

L’authentification est une étape nécessaire pour tout site détenant des données propres à l’utilisateur. Il est donc généralement nécessaire de créer un espace protégé, accessible uniquement par l’utilisateur et/ou les administrateurs. (Mozilla, 2021)

Le protocole HTTP fournit la structure nécessaire au contrôle d’accès ainsi qu’à l’authentification. Il fonctionne selon les étapes suivantes :

1. Le serveur répond à un client avec un statut 401 (signifiant « Unauthorized »), et fournit l’information permettant l’autorisation via un header.

2. Le client souhaitant s’authentifier peut ensuite le faire en incluant un header « Authorization » contenant les identifiants.

3. Le mot de passe est envoyé au serveur en l’incluant dans le header « Authorization ».

Figure 14 - Schéma d'authentification5

Pour cela, plusieurs schémas de protection HTTP sont abordables :

- Basic, qui est la plus commune, où les identifiants sont encodés en base64. - Bearer, qui utilise un jeton « bearer » pour accéder à des ressources protégées par OAuth 2.0. - HOBA, HTTP Origin-Bound Authentication, qui est basé sur une signature digitale. - Et bien d’autres

Nous nous intéresserons cependant au schéma « Bearer » qui est l’une des façons les plus simples de réaliser des requêtes API, car cela ne nécessite pas de signer de manière cryptographique chaque requête. La méthode Bearer

5 https://www.devopsschool.com/blog/what-is-bearer-token-and-how-it-works/

Page 32 sur 59

est basée sur un jeton JWT permettant d’échanger des informations de manière sécurisée. Composé de trois parties, il est souvent utilisé pour offrir une authentification stateless.

5.3.2.2.1 Qu’est-ce qu’un JWT ?

JSON Web Token est une méthode sécurisée d’échange d’information, où l’information est échangée sous la forme d’un jeton signé. Cela permet de vérifier ensuite son authenticité.

Un JWT est composé de trois informations : (ippon, 2021)

- Un header

- Un payload

- Une signature HMAC-SHA256(key, header + '.' + payload)

Dernière partie du token, la signature est créée à partir du header, du payload et d’un secret. Si invalide, elle implique systématiquement le rejet du token.

Ces 3 informations, assemblées, donnent le token JWT.

Exemple :

Figure 15 - exemple de token JWT

5.3.2.2.2 Spring Security et JWT

Malheureusement Spring Security ne supporte pas JWT out of the box. Mais j’ai suivi un tutoriel 6 très simple, qui explique très bien comment l’implémenter.

L’idée principale est d’utiliser une librairie que gère les JWTs « io.jsonwebtoken jjwt », puis de faire un simple filtre qui vérifie les headers des requêtes HTTP dans Spring Security.

6 Source du Tutoriel : https://www.toptal.com/spring/spring-security-tutorial

{

"alg": "HS256",

"typ": "JWT"

}

Le header indique que l’utilisation d’HMAC-SHA256 pour encrypter le token.

{

"sub": "John Doe",

"exp": "1485968105",

"admin": “true”

}

Le payload contient les informations que l’on souhaite transmettre.

Page 33 sur 59

5.3.3 Exemple d’implémentation bout à bout

Nous allons maintenant voir un exemple concret de comment est implémentée l’application bout à bout.

Pour cet Exemple nous allons utiliser « l’entité Exercice », pour voir tout ce qui se passe derrière une interaction de l’utilisateur. Cela va permettre d’illustrer plus simplement et de manière concrète le reste de la pile technologique utilisée

5.3.3.1 Spécification OpenAPI

Pour commencer, regardons brièvement les endpoints et le DTO qui sont dans la spécification OpenAPI, pour manipuler les exercices. Ces endpoints permettent d’effectuer les 4 tâches généralement utilisées pour manipuler des entités (CRUD). Il faut noter ici que cela offre une couche d’abstraction au front-end, puisque la majeure partie de la logique est faite au niveau du back-end (par exemple la génération d’un identifiant unique pour chaque entité.).

Figure 16 - Endpoints HTTP de la spécification OpenAPI visualisés dans Swagger.

Figure 17 – Définition d’un DTO dans la spécification OpenAPI

Page 34 sur 59

5.3.3.2 Back-End

Commençons par regarder la partie back-end. Elle est essentiellement composée de l’écosystème Spring.

Étant donné que nous utilisons Spring Data JPA, la partie MySQL est gérée automatiquement, ainsi on n’a pas à écrire de SQL, ce qui est un énorme gain en temps et en productivité.

Figure 18 - Interaction entre les couches dans le back-end

Page 35 sur 59

5.3.3.2.1 Couche Controller (Spring Web)

Le rôle des Controllers est de répondre aux requêtes en les satisfaisant du mieux possible. Un contrôleur doit contacter les autres couches pour faire les opérations demandées par le client et pour pouvoir lui fournir une réponse.

Reprenons notre exemple avec les Exercices :

Figure 19 - Controller REST Exercise (Spring Web)

On peut voir que le Controller implémente une interface ExercisesApi. Cette interface a été générée par OpenAPI Generator lors du build avec Maven. Cela nous fait gagner du temps de procéder ainsi, car il suffit de se focaliser sur la satisfaction de la requête.

Il faut noter ici que le Controller va interagir avec la couche « service » pour réaliser ce qu’il doit. Une fois une entité ou une réponse obtenue de la part du service, il va demander à la couche « mapper » de faire la transformation de l’entité en DTO pour répondre au client.

Page 36 sur 59

5.3.3.2.2 Couche Service (Spring)

Nous voici maintenant dans la couche « service ». C’est ici que se passe toute la logique de l’application. Il est préférable de faire une telle couche, car tout faire directement depuis le Controller n’est pas une bonne idée, par exemple si on devait changer de protocole de communication et donc la couche « Controller »,on devrait tout récrire. Les services ajoutent une grande modularité au code.

Comme évoquée précédemment toute la logique est faite dans les services. C’est un choix que j’ai fait, car je le trouve confortable pour développer.

Reprenons notre exemple avec les Exercices :

Figure 20 – Service Exercise (Spring)

On peut voir que le service offre toutes les méthodes pour manipuler les entités exercices. Il va interagir avec la couche repository pour faire les opérations CRUD avec la base de données. On peut noter les « coherence checks » qui assurent la cohérence des données selon la logique voulue.

Page 37 sur 59

5.3.3.2.3 Couche Model (JPA Entity)

Dans la couche model, on modélise le stockage des données. Ces données forment en quelque sorte l’aspect métier du problème.

Reprenons notre exemple avec les Exercices :

Figure 21 - Model Exercise (JPA Entity)

Il faut noter ici que je laisse les valeurs par défaut, qui répondent parfaitement aux besoins.

On peut aussi remarque l’utilisation de Lombok, qui évite d’écrire des « getters » et « setters » redondants.

Page 38 sur 59

5.3.3.2.4 Couche Repository (Spring Data JPA)

La couche repository est une couche d’abstraction supplémentaire entre les services et la BDD. Cela permet d’être protégés derrière une interface en cas de changement de SGBD.

Spring Data JPA permet d’éviter de devoir écrire des méthodes concrètes. Il va les implémenter tout seul au runtime grâce à la Reflexion API, pour autant qu’une certaine syntaxe avec des mots clefs soit bel et bien respectée.

Si l’on continue notre exemple :

Figure 22 - Repository Exercise (Spring Data JPA)

On peut voir que seules les méthodes utiles aux services sont déclarées ici.

5.3.3.2.5 Couche Mapper (MapStruct)

La couche « mapper » sert à faire la transformation des entités en DTOs. Faire des DTOs permet de choisir quels champs sont envoyés au client et ainsi garantir une API robuste, efficace et sécurisée.

Pour éviter de devoir faire le travail à la main, j’utilise MapStruct, un outil de mapping très largement utilisé dans les projets Spring.

Figure 23 - Mapper Exercise (MapStruct)

Page 39 sur 59

5.3.3.3 Front-End

Dans cette partie nous allons parler du front-end. Celui-ci est principalement composé de Nuxt, Vuex pour la gestion du state et Vuetify (libraire de composants Vue qui sont responsive out of the box) pour la mise en page.

Figure 24 - Interaction entre les couches dans le front-end

Page 40 sur 59

5.3.3.3.1 Couche présentation (Composant Vue avec éléments de Vuetify)

Dans la suite de notre exemple avec les Exercices, voici un extrait de la partie template de la page Nuxt qui correspond à la liste des exercices. On peut y voir des éléments de vuetify (ce sont ceux qui commentent par « v-» par exemple v-btn.)

Il s’agit de la couche présentation. On y affiche les données pour qu’elles soient utilisables par l’utilisateur final.

Cet exemple illustre bien les boucles et les conditions qui sont disponibles dans le template des composants Vue.

Figure 25 - partie template de la page de Nuxt « exercises » (avec éléments de Vuetify)

Page 41 sur 59

La figura suivante illustre la partie script du composant Vue. C’est ici qu’on déclare les méthodes et les données locales (data).

On peut voir l’interaction entre la couche présentation nommée « Vuetify » dans le schéma et la couche Vuex. À la 4ème ligne, on voit un appel au store des exercices. En effet on lance une action qui va récupérer les exercices et les catégories depuis le back-end. Il y a aussi d’autres actions plus bas.

(Plus de détails là-dessus viendront dans la section dédiée.)

Figure 26 - partie script de la page de Nuxt « exercises » (avec éléments de Vuetify)

Page 42 sur 59

5.3.3.3.2 Couche State Managment (Vuex)

5.3.3.3.2.1 Ma manière de faire

Le state management est une matière à part entière. Il est très important de bien le faire. Car le state a un impact direct sur l’expérience utilisateur. Par exemple que faut-il afficher pendant un chargement ? Comment gérer les erreurs ? Je vais répondre à ces questions et présenter ma manière de gérer le state de l’application.

Dans mon application il y a les états suivants :

Figure 27 - Énumération des états possibles de l'application

Voici une brève définition des états et de ce qui est affiché :

- INIT : état initial - On affiche un « placehoder »

- WAITING : état pendant un chargement ou envoi de données - On affiche un « spinner » pour indiquer l’attente

- SUCCESS : lorsque le chargement ou envoi s’est correctement terminé - On affiche les données ou un message de succès

- WARNING : lorsque la requête envoyée possède une erreur de la part de l’utilisateur (valeur aberrante ou opération non possible à cause des règles internes)

- On affiche un message d’erreur avec sa description, sans bloquer l’interface, pour laisser l’utilisateur corriger

- ERROR : Losqu’une requête aboutit à une erreur non récupérable (généralement de la part du développeur)

- On bloque l’interface et l’on met un bouton pour relance l’application en partant avec un state initial (pur)

Page 43 sur 59

Le diagramme suivant montre les règles de changement d’état (on doit suivre les flèches pour changer d’état) :

Figure 28 - Diagramme d'états

5.3.3.3.2.2 Retour à l’exemple

Revenons à l’exemple sur les exercices :

La figure suivante monte comment est géré l’état dans le module des exercices.

Il est intéressant de relever les points suivants. On maintient un currentState pour tenir à jour l’interface de la couche présentation. Les actions servent à faire les opérations CRUD au niveau de l’API et du back-end. EN effet on voit qu’une action consiste à mettre le currentState en WAITING (à travers une mutation). Puis de faire un appel à l’API au travers du code généré par OpenAPI TypeScript Codegen. Puis de mettre le currentState en SUCCESS, WARNING ou ERROR en fonction du résultat de l’appel à l’API. (Remarque pour récupérer l’état WARNING ou ERROR j’ai mis le code commun dans StateUtils, pour modulariser au maximum le code).

Page 44 sur 59

Figure 29 - Module "Exercises" du store (Vuex)

Page 45 sur 59

5.3.4 Difficultés

Heureusement, je n’ai pas rencontré de grandes difficultés durant cette première phase.

Comprendre le fonctionnement des nouvelles technologies était un défi de taille, j’en ai beaucoup appris.

La principale difficulté était de mettre en place le code, pour la première fois. D’avoir un stack qui soit fonctionnel de bout à bout, tout en assurant une bonne modularité et robustesse. Tout cela dans le but de pouvoir continuer le projet sur une base bien solide.

Les difficultés mineures sont les suivantes :

- Nuxt Property Decorator : tout n’était pas parfaitement documenté. Ainsi j’ai eu de la peine à mettre en place Vuex à cause de la hiérarchie par défaut des dossiers de Nuxt.

- Bug dans l’extension Vue de Visual Studio Code, indiquant une erreur, alors que le code était parfaitement OK et fonctionnel.

5.3.5 Analyse du résultat

Le résultat est tout à fait concluant. Le stack marche comme il devrait et on peut conclure que le MVP est stable pour être étendu au produit final.

Il y a cependant une chose qui mérite d’être soulignée. Vu la conception de l’application dans son ensemble elle ne pourra pas fonctionner offline (ce qui est un objectif bonus.).

En effet, placer la logique des données dans le back-end, rend le front-end fortement dépendant de ce dernier. Pour pallier à ce problème, il faudrait une tout autre approche où le back-end serait un simple relai de synchronisation, et avec d’autres complications qui dépassent largement le cadre de ce TB. Cela n’est malheureusement pas possible dans les délais impartis.

5.3.6 Conclusion

Les résultats de MVP montrent que les choix de conception ont bien abouti. Ainsi on peut passer au produit final, sans avoir à faire de grands changements.

Page 46 sur 59

5.4 Produit complet

Nous voici dans la phase de développement itératif de toutes les fonctionnalités pour avoir un produit complet qui répond aux besoins des utilisateurs.

5.4.1 Fonctionnalités

Les fonctionnalités du produit complet sont les suivantes :

- Une personne peut accéder au site et voir les pages publiques. - Cette personne peut créer un compte et devenir un utilisateur. - Un utilisateur peut se connecter et accéder aux fonctionnalités privées - Les fonctionnalités privées sont de pouvoir créer, afficher, modifier et supprimer des exercices - Les exercices ont une catégorie. - On peut créer, afficher, modifier et supprimer les catégories. - On peut modifier les informations du profil - On peut créer un plan d’entrainement organisé par Semaines Jours et séries planifiées - On peut faire une réalisation d’un plan « planned workout » et voir si on a atteint les objectifs fixés - On peut modifier / supprimer un plan d’entrainement s’il n’a pas de réalisations. - On peut faire un entrainement qui n’est pas planifié « do a workout » - On peut consulter la partie statistique de l’application pour voir des statistiques globales, par exercices, et

un calendrier des entrainements pour voir quand et pendant combien de temps on s’est entrainé.

Figure 30 - Use Case de MyWorkoutPlan

Page 47 sur 59

5.4.2 Approche itérative

Comme évoque précédemment dans mon approche de développement (6.2), je procède de manière itérative en gardant le même flux pour chaque fonctionnalité.

Le reste de l’application s’est déroulé sans complications de manière très similaire (sauf pour les données, la logique et la mise en page). Mais je trouve que cela ne vaut pas la peine d’être revu en détail comme pour l’exemple sur les exercices, car ce serait répétitif sans apporter grand-chose.

Je vais plutôt présenter la logique qui se cache derrière en illustrant avec des schémas.

5.4.2.1 Planification et Réalisation des entrainements

Cette partie concerne la création de plans d’entrainement et leur réalisation. Il est intéressant de voir comment j’ai fait pour pouvoir réaliser un entrainement planifié. Puis regrouper les informations pour voir si l’on a atteint les objectifs voulus. On peut aussi souligner la question de comment laisser la liberté à l’utilisateur de faire un entrainement non planifié.

Le schéma qui va suivre illustre la solution que j’ai utilisée. Il s’agit d’utiliser le lien entre Workout et Day et le lien entre PlannedSet et ConcreteSet. Ce lien est visible sur les figures suivantes :

- Figure 31 - UML du graphe de DTOs renvoyé par le back-end - Figure 10 - UML des entités JPA dans le model du back-end

Vu qu’une grande partie de la logique se situe dans le back-end, il faut en profiter. Lorsque l’on accède à un plan, une seule requête est effectuée au serveur. Cette requête va récupérer un PlanDTO, lequel est en réalité un graphe de DTOs comme l’illustre la figure qui suit :

Page 48 sur 59

Figure 31 - UML du graphe de DTOs renvoyé par le back-end

À chaque modification d’une entité imbriquée, tout le graphe est rechargé. Cela facilite énormément la gestion du state au niveau de Vuex. Pour modifier les objets enfants (Week, Day, etc.) il y a des endpoints définis dans la spécification OpenAPI suivante :

Page 49 sur 59

Figure 32 - Endpoints dans la spécification OpenAPI pour manipuler les plans d'entrainement (Swagger UI)

La même approche a été utilisée pour les Workouts.

Page 50 sur 59

5.4.2.2 Reste de l’application

Tout ce qui concerne le reste de l’application reste totalement similaire à l’exemple sur les exercices.

Le seul point que l’on peut montrer en plus est les DTOs restants. Leur logique est très simple et se situe au niveau de back-end.

Figure 33 - DTOs restants

Page 51 sur 59

5.4.3 Difficultés et alternatives

Comme pour la partie MVP, il n’y a pas eu de difficultés qui m’ont gêné. Le seul point qui mérite d’être soulevé est la difficulté à intégrer Chart.js dans le projet Nuxt.

Ce qui est vraiment difficile dans ce genre de projet c’est de réussir à modéliser ce qu’on veut de la manière la plus optimale qui soit. Parfois, prendre plus de temps sur la modélisation peut nous faire gagner beaucoup de temps par la suite lors de l’implémentation.

Il y a aussi le côté visuel design et UI qui pourraient être améliorés, car dans l’état actuel ce n’est pas parfaitement user-friendly, surtout au niveau des infos bulles, etc.

5.4.4 Conclusion

Je suis satisfait de ce travail, car les objectifs sont atteints. L’application est stable et utilisable. De plus elle est ouverte à de nombreuses extensions, comme ajouter un système de suivi et de coaching. Permettre d’ajouter des amis et de voir leurs résultats... Les possibilités sont infinies et ouvrent de bonnes perspectives pour l’avenir de cette application.

Page 52 sur 59

5.5 Tests finaux

Les tests ont été faits à la fin du développement à la main. Idéalement il faudrait mettre en place un système de tests automatisé avec un outil comme Nightwatch.js.

Voici les fonctionnalités testées et fonctionnelles :

- Navigation - Je peux naviguer dans les pages publiques - Je peux naviguer dans les pages privées après login

- Register - Je peux créer un compte - Si username ou email déjà utilisé, message warning est affiché

- Login - Je peux me login - Si erreur dans username, email ou mot de passe, il y a un message d’avertissement

- Home - Après login on voit notre pseudo avec un message de bienvenue

- Calendar - Je peux voir les « statistiques temporelles » de mes séances - Je peux accéder aux détails d’un workout depuis le calendar - Je peux changer le mode de vue du calendrier en mois, semaine, 4 jours, 1 jour.

- Statistics - Je peux voir quelques statistiques globales de mes séances - Je peux voir l’évolution de ma 1RM (répétition maximale) estimée en fonction du temps

- Workouts - Je peux créer un workout - Je peux lancer un workout - Je peux ajouter un set à un workout - Je peux finir un workout - Je peux modifier un workout - Je peux supprimer un workout

- Plans - Je peux créer un plan d’entrainement et le modifier - Je peux ajouter une week et la modifier - Je peux ajouter un day et le modifier - Je peux ajouter un set à un day et le modifier - Je peux lancer une réalisation d’un workout lié - Je peux voir les réalisations d’un workout lié - La suppression fonctionne et envoie un message d’erreur s’il y a déjà une réalisation pour un set,

pour un day, pour une week et pour un plan - Exercices

- Je peux créer des exercices par catégorie - Je peux les modifier par catégorie - Je peux les supprimer avec un message d’erreur s’il est déjà utilisé ailleurs

- Profile - Je peux mettre à joue les informations de mon profil

- Settings - Je peux me log out

Page 53 sur 59

6 Conclusion MyWorkoutPlan a été une expérience plus qu’enrichissante, où j’ai pu découvrir ce qu’impliquait l’implémentation full-stack d’une solution. Bien que les objectifs bonus n’aient pas tous été implémentés, le résultat reste néanmoins très complet et répond aux problématiques abordées au début de ce travail.

La courbe de difficulté d’apprentissage des technologies choisies me conforte dans l’idée que de prendre du temps pour évaluer la sélection des meilleures technologies dès le début est réellement nécessaire. Comme évoqué plus tôt, je n’ai pas eu de problème majeur à comprendre les subtilités que pouvaient apporter chacune d’entre elles, car leur utilisation ne nécessitait pas d’adaptation majeure.

Je regrette toutefois de ne pas avoir pu implémenter l’objectif bonus concernant l’utilisation d’une PWA hors connexion. J’ai cependant pu établir la manière de procéder pour implémenter cette fonctionnalité et l’ai incluse dans le cahier des charges de la version 2.0 de l’application.

J’ai été agréablement surpris par la richesse des éléments fournis par Vuetify, qui répondait à chacun des besoins des composants que j’ai eus à implémenter. Les propriétés CSS n’étaient toutefois pas très poussées et il fallait s’adapter continuellement pour un changement bien précis.

Finalement, j’aimerais mettre en avant que les riches documentations de Vue et Nuxt ont particulièrement été appréciées. Chacune des technologies met à disposition un guide d’installation et des explications détaillées. Sans cela, je n’aurais probablement pas eu une expérience de développement aussi constante et efficace. Cela démontre l’importance de choisir des technologies avec une communauté bien développée.

6.1 Perspectives

Il y a plusieurs points que je souhaiterais développer pour les prochaines versions.

Pour commencer, bien que l’expérience utilisateur eût été largement considérée, j’ai eu de la peine à développer une interface attractive et j’ai préféré rester dans la sobriété. Il est néanmoins appréciable d’avoir une jolie interface lorsqu’on utilise l’application.

Je souhaiterais également déployer l’application et la tester dans un cercle restreint pour établir si les fonctionnalités implémentées répondent aux problématiques énoncées au début de ce rapport.

Finalement, les perspectives imaginées à plus long terme sont de faire évoluer l’application en plateforme de coaching. Le produit réalisé jusqu’à présent s’intégrerait donc dans une application plus grande, mettant à disposition d’autres services liés au domaine du sport.

Page 54 sur 59

7 Bibliographie (2021, Mars). Récupéré sur Cellenza.org: https://blog.cellenza.com/developpement-specifique/web-

developpement-specifique/introduction-a-typescript/

(2021, Mars). Récupéré sur Nuxt: https://fr.nuxtjs.org/

(2021, Mars). Récupéré sur Ouidou: https://blog.ouidou.fr/spring-security-pour-les-nuls-1930fce60089

(2021, Mars). Récupéré sur Gayerie: gayerie.dev

(2021, mars). Récupéré sur Mozilla: https://developer.mozilla.org/fr/docs/Web/HTTP/Authentication

(2021, mars). Récupéré sur ippon: https://blog.ippon.fr/2017/10/12/preuve-dauthentification-avec-jwt/

(2021, avril). Récupéré sur Github: https://github.com/nuxt-community/nuxt-property-decorator

npmjs. (2021, Mai). Récupéré sur https://www.npmjs.com/package/openapi-typescript-codegen.

Swagger. (2021, Juin). Récupéré sur Swagger.io

Web.dev. (2021, Mars). Récupéré sur https://web.dev/progressive-web-apps/

Page 55 sur 59

8 Authentification

Le soussigné, Alexandre Simik, atteste par la présente avoir réalisé seul ce travail et n’avoir utilisé aucune autre source que celles expressément mentionnées.

Grandvaux, le 30 juillet 2021

Alexandre Simik

Page 56 sur 59

9 Liste des figures Figure 1 - Structure simplifiée d'une routine d'entrainement ..................................................................................... 7 Figure 2 - Diagramme Use Case de conception ............................................................................................................ 8 Figure 3 - Schéma global similifié ............................................................................................................................... 10 4 : Exemple d'un repository gérant les utilisateurs .................................................................................................... 12 Figure 5 - Composition d'une vue dans Nuxt.js .......................................................................................................... 15 Figure 6 – Schéma Vuex global ................................................................................................................................... 17 Figure 7 - Composant Vue (Syntaxe classique JavaScript) .......................................................................................... 19 Figure 8 - Composant Vue (Syntaxe avec Nuxt Property Decorator en TypeScript) .................................................. 19 Figure 9 - Schéma global détaillé de l’application ...................................................................................................... 21 Figure 10 - UML des entités JPA dans le model du back-end ..................................................................................... 23 Figure 11 - Diagramme Use Case du Produit Complet ............................................................................................... 27 Figure 12 - Hiérarchie des dossiers et fichiers ............................................................................................................ 28 Figure 13 - Interaction entre les différentes couches bout à bout ............................................................................ 30 Figure 14 - Schéma d'authentification........................................................................................................................ 31 Figure 15 - exemple de token JWT ............................................................................................................................. 32 Figure 16 - Endpoints HTTP de la spécification OpenAPI visualisés dans Swagger. ................................................... 33 Figure 17 – Définition d’un DTO dans la spécification OpenAPI ................................................................................ 33 Figure 18 - Interaction entre les couches dans le back-end ....................................................................................... 34 Figure 19 - Controller REST Exercise (Spring Web) ..................................................................................................... 35 Figure 20 – Service Exercise (Spring) .......................................................................................................................... 36 Figure 21 - Model Exercise (JPA Entity) ...................................................................................................................... 37 Figure 22 - Repository Exercise (Spring Data JPA) ...................................................................................................... 38 Figure 23 - Mapper Exercise (MapStruct) ................................................................................................................... 38 Figure 24 - Interaction entre les couches dans le front-end ...................................................................................... 39 Figure 25 - partie template de la page de Nuxt « exercises » (avec éléments de Vuetify) ........................................ 40 Figure 26 - partie script de la page de Nuxt « exercises » (avec éléments de Vuetify) .............................................. 41 Figure 27 - Énumération des états possibles de l'application .................................................................................... 42 Figure 28 - Diagramme d'états ................................................................................................................................... 43 Figure 29 - Module "Exercises" du store (Vuex) ......................................................................................................... 44 Figure 30 - Use Case de MyWorkoutPlan ................................................................................................................... 46 Figure 31 - UML du graphe de DTOs renvoyé par le back-end ................................................................................... 48 Figure 32 - Endpoints dans la spécification OpenAPI pour manipuler les plans d'entrainement (Swagger UI) ......... 49 Figure 33 - DTOs restants ........................................................................................................................................... 50 Figure 34 - Planification du travail .............................................................................................................................. 58 Figure 35 - Planification détaillée du développement itératif.................................................................................... 58

Page 57 sur 59

10 Journal de travail - 05.03.2021

- Finir Gant Diagramme Gantt - Mise en place template Rapport - Mettre les objectifs - Commencer l'analyse (c'est plus technique.)

- 15.03.2021 - Structure du rapport d'après documentation officielle - Avoir effectué l'analyse, donc avoir les objectifs détaillés

- 30.03.2021 - Mieux argumenter et développer les choix dans conception et analyse - Ajouter des Schémas dans conception et analyse - Commencer le squelette du code.

- 16.04.2021 - Faire une section sur l'apprentissage de Nuxt et PWA - Bien me documenter sur le state Vuex et PWA - Directement et expérimenter - Faire les Schémas - Faire le MVP avec le login / Register - Modèle UML de BDD

- 01.05.2020 - Avancer MVP - Mieux documenter - Login - Mise en page du front-end - CRUD Exercices

- 01.06.2020 - Faire l'analyse MVP

- 04.06.2021 - Détailler une liste des fonctionnalités avec priorités et estimation de la durée.

- 04.06.2021 - Envoyer la MAJ du Gantt avec les nouvelles étapes

- 01.07.2021 - Terminer planification des entrainements - Réalisation des entrainements

- 09.07.2021 - Terminer la réalisation - Profil utilisateur - Documenter

- 16.07.2021 - Voir fiche et résumé regarder dans le règlement

- 23.07.2021 - Tester sur mobile

Page 58 sur 59

Figure 34 - Planification du travail

Figure 35 - Planification détaillée du développement itératif