:: Enseignements :: ESIPE :: E4INFO :: 2021-2022 :: Java Avancé ::
[LOGO]

Projet de Java Avancé INFO 2 - 2021


Exercice 1 - Friday

Le but du projet Friday est d'écrire un assistant gérant un agenda capable aider un utilisateur à ne pas être en retard à ses RDVs
LK'application Friday est composée :
  • d'une application friday-back écrite en Java proposant divers services REST pour manipuler les données d'un agenda
  • d'une application friday-front écrite en JavaScript affichant visuellement les informations de l'agenda

L’application doit permettre de :
  • Créer, Modifier, Supprimer des évènements dans l'agenda.
    Un évènement peut être ponctuel, avec une date de début, une date de fin (ou "all day"), une location, etc. Un évèneemnt peut aussi avoir une récurrence, tous les jours, les 5 prochaines semaines, etc.
    Les évènements sont stockées en base de données (vous êtes complètement libre sur le schéma de la BDD).
  • De se mettre à jour en utilisant des données au format ical/iCalendar. Soit en idiquant une URL pour aller chercher le données soit en uploadant un fichier.
    Note: c'est un des formats supportés par edt.univ-eiffel.fr
  • Extraire les infos d'un calendrier Google Calendar et synchronizer les infos avec l'agenda.
  • Indiquer le temps avant le prochain RDV, les conditions de traffic (voiture/transport) et tout autre information utiles permettant de ne pas être en retard au RDV.

L'interface graphique est composé de 3 panneaux qui prennent toutes la largeur de l'application Web. Voici une belle représentation en ASCII art de celle-ci.
     +-------------------------------------------------------+
     | Information intélligente au sujet du prochain RDV     |
     +-------------------------------------------------------+
     | liste des RDVs de la journée par ordre chronologique  |
     | avec les informations principale (heure, lieu, etc)   |
     +-------------------------------------------------------+
     | Un calendirer du mois avec par jour, une petite barre |
     | horizontale indiquant la présence d'un RDV            |
     +-------------------------------------------------------+
   
L'interface graphique doit être dynamique, les changements doivent être affiché en temps réel.

Technologie à utiliser
  • Vous devez utiliser Maven comme outil de build et IntelliJ comme IDE, et la version 17 de Java.
  • Le code est hébergé sur gitlab.com.
    Pour vous authentifier, vous utiliserez le mécanisme de clé SSH publique/privée
    Il est vivement encouragé d'utiliser le mécanisme de merge request entre les deux membres d'un binôme pour augmenter la qualité du code et la connaissance du code par chaque binome.
    Tout commit trop gros (qui introduit plusieurs features d'un coup) sera revert.
  • Pour tester vos services REST, vous pouvez utiliser Postman ou tout autres clients capables de faire des requètes REST.
  • Les test unitaires Java doivent être effectués avec JUnit 5.8.1, vous pouvez vous référer au guide d'utilisation.
    Chaque classe classe Java doit avoir une classe de test correspondanet (pour au moins 80%) du projet.
  • Pour la sérialisation/dé-sérialisation JSON des requêtes, vous utiliserez une API de parsing JSON Jackson 2.11.4
  • Pour la gestion du format ical/icalendar, vous avez le choix entre la librarie ical4j 3.1.0 (sur Maven, org.mnode.ical4j:ical4j:3.1.0) ou la librairie biweekly 0.6.6
  • Pour accéder au calendrier Google, vous utiliserez Google Calendar v3 API.

Pour implanter les différents services REST, votre application doit utiliser
Pour la mapping Object / Relational, c-a-d voir une ligne d'une table de BDD comme un objet Java. Il y a deux implantations, une à base d'Hibernate qui peut être utilisé directement soit par l'intermédiaire de la spécification JPA (Java Persistance API). Et une à base de JDBI.
Pour le front-end web, vous avez besoin d'un framework graphique
Note: le front-end doit être buildé aussi en utilisant Maven (un seul POM pour front et le back).
Note2: vous avez besoin de npm pour la partie build mais pas à l'exécution ! Vous pouvez de plus, utiliser une librarie spéciale pour la gestion de l'agenda pourvu quelle soit adaptée à votre framework (pas de react-calendar si vous devez utiliser svelte).
Pour vous aidez à avoir de belle pages, vous allez aussi utiliser une bibilothèque qui vous aide pour la partie CSS
L'application a besoin d'une base de donnée mais vu le volume de données, pas forcément d'une "vrai" base de données, nous utiliserons donc des bases de données embedded.
L'intérêt d'une BDD embedded est qu'elle est prète à l'emploie directement à partir d'un jar.
Il y a deux façon d'accéder à une BDD en Java, en utilisant le Driver JDBC ou le DataSource JDBC. On vous demande d'utiliser le DataSource car la gestion des connections TCP est automatique.

Sécurité :
  • Pas de HTTPS pour ce projet (c'est mal) mais c'est pour vous aider à débugger !
  • Les entrées des services web au niveau de l'URL ou de la partie JSON doivent être validées et les sorties doivent être escapées pour éviter les injections de code.
  • Il n'y a aucune raison que le login/mdp de la BDD soit en dur dans votre code !

Binomes avec les technos qui doivet être utiliser
  • DUMERAT - RODRIGUEZ
    Micronaut - Jdbi - Svelte - TailwindCSS - H2
  • ALEXANDRE- VALADE
    Micronaut - JPA - Svelte - TailwindCSS - SQLite
  • BARBE - DAO
    Jersey - JPA - Vuejs - Bootstrap - SQLite
  • BARROUX - LAGINHA
    Quarkus - Hibernate with Panache - Svelte - Bootstrap - Derby
  • BUZELIN - KHENISSI
    Quarkus - Jdbi - Reactjs - Bootstrap - HyperSQL
  • DOMART - MIKEMBO
    WildFly - JPA - Reactjs - TailwindCSS - H2
  • CIROU - DULYMBOIS-LOUISON
    Quarkus - JPA - Angular - TailwindCSS - Derby
  • CONDE - LI
    WildFly - JPA - Angular - Bootstrap - SQLite
  • RICARD - RIEUTORD
    Spring - JPA - Vuesjs - TailwindCSS - H2
  • Binome 9
  • APELBAUM - YASSINE
    Spring - JPA - Vuesjs - Bootstrap - Derby

Calendrier des rendus.
Jeudi 4 novembre 2021 à 14h :
Soutenance béta, la BDD doit marcher, la partie APIs REST + JPA doivent être en place, la partie frontend avec le calendrier doit marcher, l'intégration avec Google Calendar peut marchoter (on est plus indulgent sur cette partie).
Voilà les tests simples que vous devrez montrer
  • si on ajoute à la main un élement dans la BDD, on peut le voir sur la partie calendrier de l'interface graphique
  • si on modifie à la main un élement dans la BDD, on peut le voir modifié sur la partie calendrier de l'interface graphique
  • si on retire à la main un élement dans la BDD, il n'est plus visible sur l'interface graphique
  • l'interface graphique permet d'ajouter/modifier/supprimer un évènement
  • si on ajoute un élement avec Google Calendar, on peut le voir sur la partie calendrier de l'interface graphique
  • si on modifie un élement avec Google Calendar, on peut le voir modifieé sur la partie calendrier de l'interface graphique
  • si on supprime un élement avec Google Calendar, il n'est plus visible sur l'interface graphique

Lundi 6 décembre 2021 à 14h :
Soutenance finale: tout doit marcher !

Pour vous aider, si vous ne respectez pas les indications de "sudden death" suivantes, votre projet sera considéré comme mort et noté 0.
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, lambdas, classes internes, exceptions, types paramétrés, annotations, collections, entrées/sorties).
  • Une des technologies que votre projet utilise n'est pas celle requise pour votre binome
  • 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é.
  • Le principe d'encapsulation et la programmation par contrat doivent être respectées.
  • Il ne doit pas y avoir de champs ou méthodes protected.
  • Il ne doit pas y avoir d'instanceof/if...else sur des types là où il est possible d'utiliser le polymorphisme ou le pattern matching.
  • Chaque interface devra être nécessaire.
    Une interface possède 0 ou 1 méthode (sinon justifiée).
  • 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 faire plus de 10 lignes sans une vraie justification.
  • Il est interdit d'utiliser des champs static typés par un objet (pas de variables globales), seules les constantes (static final) de type primitif sont autorisées (et utiliser l'injection de dépendence SVP).
  • Le fichier POM.xml ne doit pas contenir de dépendances non listées dans ce document où ayant une autre version que la version demandée (à part les dépendances de dépendances).