:: Enseignements :: ESIPE :: E4INFO :: 2018-2019 :: Java Avancé ::

Projet de Java Avancé INFO2 2018

Exercice 1 - JaimePasADE

Le but du projet JaimePasADE est d'implanter un outil de calendrier électronique partagé.
L'outil ADE de calendrier de la fac n'est pas terrible, on se propose de le ré-implanter pour qu'il soit plus ergonomique et, si possible, pas trop moche.

L’application calend'art doit

permettre de visualiser un calendrier avec sur une même page l'ensemble des événements sur un mois, ainsi que les événements spécifique à une journée en suivant les principes du "responsive design".
fournir un ensemble de services REST permettant une séparation claire entre le front-end et le backend (ce qui rendra les développement de futures applications sur iOS ou Android facile).
avoir un système d'enregistrement d’événements par web socket permettant au frontal web d'être averti en temps réel des modifications à apporter sur le calendrier;
avoir une partie serveur sauvegardant les données dans un Google Calendar (look Ma, no database !)
avoir un service automatique sur le serveur scannant les données sur ADE (à travers l'export iCal) et mettant à jour les données automatiquement.

On ne vous demande pas de supporter tous les événements de calendrier qui peuvent arriver mais uniquement ceux nécessaires pour afficher les informations disponibles sur ADE.

Le projet est composé de deux parties, le client Web écrit en JavaScript 2015 utilisant la librairie vuejs v2 et le serveur Web écrit en Java 11 utilisant le framework Reactive Spring 5.

Calendrier des rendus
7 octobre: Démarrage + client HTTP

Requêtes HTTP en utilisant l'API REST de Google Calendar pour récupérer tous les événements d'un calendrier créé à la main.
Le code doit être sur Gitlab sous forme de plusieurs commits.

14 octobre: export de ADE, import dans Google Calendar.

Analyser la sortie iCalc de ADE (exporter en iCal avec plus que 4 semaines) pour voir les informations que vous allez devoir stocker dans le calendrier.
Binôme 1: Écrire un parseur de iCal créant les événements correspondants.
Binôme 2: Écrire une API masquant l'API REST de Google Calendar permettant de créer les événements dans un calendrier.

21 octobre: mise en place de Spring, premier service Web, et test unitaire de l'API Google Calendar.

Analyser les services Web dont vous allez avoir besoin pour afficher un calendrier dans l'application Web.
Binôme 1: Écrire les tests unitaires utilisant l'API Google Calendar (créée par l'autre binôme, ah astuce) permettant de faire un roundtrip complet (créer un événement dans un calendrier bidon puis relire l’événement avec les bonnes infos).
Binôme 2: Mettre en place de Maven et de Reactive Spring et tester qu'un appel REST sur votre serveur permet d'obtenir les événements d'un calendrier.

28 octobre: vuejs

Analyser les différents 'plugins' de vuejs qui permettent d'afficher un calendrier, et choisir le bon !
Binôme 1: Tester qu'il est possible d'afficher les événements du service REST sur le serveur créé précédemment dans le calendrier.
Binôme 2: Tester qu'il est possible d'afficher les événements d'une journée sous forme de liste avec vuejs avec un appel AJAX.

4 novembre: Première intégration verticale, le projet marche de bout en bout.

Binôme 1: Faire en sorte de pouvoir afficher le calendrier et la liste sur la même page, et vérifier que la sélection d'un jour du calendrier mette bien la liste à jour.
Binôme 2: Faire en sorte d'exporter une liste d’événements d'ADE une fois par minute et ajouter/supprimer uniquement les événements qui ont changé dans Google Calendar.

11 novembre: Signalisation de nouveau événements

Analyser comment marchent les web sockets coté Java et coté JavaScript. Réfléchir à la granularité des événements qui doivent être envoyés pour indiquer un changement (juste un événement disant qu'il y a un truc qui a changé, un événement indiquant ce qui a changé, etc).
Binôme 1: Faire en sorte qu'un message soit émis sur la web socket si un événement est modifié (sur ADE ou directement sur Google Calendar).
Binôme 2: Récupérer les messages sur la web socket et demander la mise à jour du calendrier.

18 novembre: Consolidation.

Binôme 1: Créer plusieurs calendriers de démo et des tests d'intégration qui montrent que lorsque l'on crée un événement sur Google Calendar, l'application se met à jour correctement.
Binôme 2: Utiliser les tests unitaires coté vuejs pour vérifier que les tests d'intégration marchent correctement.

25 novembre: Version bêta.

Écrire la doc utilisateur. Mettre à jour la doc de développement et la javadoc. La bêta peut avoir des bugs mais doit contenir toutes les fonctionnalités.

1er décembre: Version finale.

Corriger les bugs restants.
Préparer la soutenance.

Les événements du calendrier sont rendus visibles par le serveur sous forme de services REST. La création des services Rest se fait en utilisant Spring Reactive Web, que vous configurerez en utilisant Spring Boot 2 (Le site https://start.spring.io/ vous permet d'avoir une base de départ). Spring fonctionne avec les serveurs web Tomcat et Netty. Nous vous imposons Netty.

Pour l'accès à l'API de Google Calendar, vous utiliserez l'API REST v3 que vous encapsulerez dans une API propre écrite en Java.
Pour les appels HTTP, vous utiliserez le module/package java.net.http.

Pour la sérialisation/dé-sérialisation JSON des requêtes, vous utiliserez l'API de parsing JSON utilisé par Spring pour éviter de multiplier les dépendances.

Pour la présentation de l'application Web, on vous demande de n'utiliser que la librairie vuejs en faisant un frontal Web le plus simple possible. Pour l'affichage du calendrier proprement dit, vous pouvez choisir la librairie vuejs d'affichage de calendrier de votre choix.

Le code du projet est hébergé sur gitlab.com. Le projet doit utiliser Maven comme outil de build.

Les test unitaires Java doivent être effectués avec Junit 5, vous pouvez vous référer au guide d'utilisation.
Les test unitaires vuejs doivent être effectués en utilisant vuejs-test.

Pour vous aider, si vous ne respectez pas les indications de "sudden death" suivantes, votre projet ne sera pas noté.
Pour la partie Java, le programme doit être écrit en utilisant correctement les différents concepts vus lors du cours de Java Avancé (sous-typage, polymorphisme, lambda, classes internes, exceptions, types paramétrés, collections, entrées/sorties et réflexion).

Il ne doit pas y avoir de warnings lorsque l'on charge le code dans Eclipse avec tous les warnings activés !
Il ne doit pas y avoir de warnings lorsque l'on compile avec javac -Xlint:all.
Dans un module, les packages d'implantation ne doivent pas être exportés et requires transitive doit être utilisé là où c'est nécessaire.
Il ne doit pas y avoir de raw types, de @SuppressWarning non justifié, de cast non justifié.
Il ne doit pas y avoir de champs ou méthodes protected.
Il ne doit pas y avoir d'instanceof/switch/if...else sur des types là où il est possible d'utiliser le polymorphisme.
Chaque interface devra être nécessaire.
Aucune classe abstraite ne doit être publique ou utilisée comme un type.
Chaque méthode devra être appelée (pas de code mort).
Aucune méthode ne doit pas faire plus de 10 lignes sans une vraie justification.
Il est interdit d'utiliser des champs static typés par un objet (pas de globale), seule les constantes (static final) de type primitif sont autorisées.

Pour la partie JavaScript, les bonnes pratiques vu dans le cours de Programmation Web de l'année précédente devront être respectées.

Le programme devra utiliser la notion de classe et de arrow function.
La page de l'application ne devra pas être générée.
L'utilisation de 'var' est interdite.
Le design de la page devra être responsive, pour smartphone, tablette et desktop.
Les appels AJAX aux services REST devront utiliser les Promises et fetch.