:: Enseignements :: Master :: M1 :: 2016-2017 :: Java Avancé ::

Projet de Java de Master 1 / 2016-2017

Exercice 1 - Thaw

Le but de ce projet est d'implanter une application de chat amélioré (comme MatterMost ou Slack) nommé Thaw. Thaw est une application Web qui permet de créer des channels de discussion permanent sur n'importe quelle sujet. Thaw possède un système de plugin de bot qui permet d'aller chercher des informations à divers endroit et de les afficher comme une discussion (commit git, star github, flux RSS, etc). L'idée est que l'ensemble des informations utiles au travail d'une personne dans une entreprise doit être accessible à partir de l'application.
Thaw permet

de se loger en utilisant une authentification Web classique login/password demander par le navigateur
de créer/supprimer des channels accessibles par l'ensemble des participants
de poster des messages sur n'importe quel channel. Le message sera alors visible par l'ensemble des personnes connectés en live
de créer des bots en utilisant une API intuitive (à vous de vous débrouillez) et d'installer de nouveaux bots juste en ajoutant un jar modulaire (jar de Java 9) dans le répertoire bots

Le projet est composé de trois parties, l'application Thaw qui fonctionne en exposant des services REST, un frontal graphique en JavaScript qui affiche/requète les données des services REST et une mini-base de donnée qui permet de stocker les messages d'un channel.

Configuration
Il n'y a pas de configuration de la partie application en elle même, tout est automatique. Pour la partie plugin, chaque bot peut avoir un fichier properties au format java.util.Properties qui contient sous forme de clés/valeurs permettant de configurer un bot. Par convention, le nom du fichier properties contient deux valeurs séparés par un ':', la première valeur est le type de bot, la seconde est un nom indiquant le nom de la configuration, par exemple, git-bot:mlv.properties permet de configurer un bot git-bot avec les informations d'un serveur git hébergé à l'université.
Sécurité
L'ensemble des services REST de l'application sont accessibles sur HTTPS.
Base de donnée
La base de donnée utilisée est SQLite avec une table par channel.
Live Update
Lorsqu'un utilisateur ou un bot post un message dans un channel, celui-ci doit être automatiquement visible par l'ensemble des browsers Web connecté à l'application
Recherche
De façon optionnel, l'interface Web doit être capable d'afficher uniquement les messages d'un channel contenant un mot donné.
API de bots
Vous devez fournir une API de bots sous forme d'un Jar modulaire permettant lorsque l'on crée un bot en ne dépendant que de cette API. De plus, chaque bot doit tourner dans sa propre thread. De façon optionnel, il faut empécher les bots de créer au même d'autres threads (cf Java Security Manager / Java Security guide).
Bots présents par défaut
Par défaut, l'application doit posséder 3 type de bots différents.
- git-bot
  Un bot qui affiche les commits pour un repository particulier (en utilisant la librairie jgit 4.5)
- rss-bot
  Un bot qui affiche les annonces d'un flux RSS, (on ne vous demande que le support de RSS 2).
- github-bot
  Un bot qui affiche les activités d'un projet github particulier.
Pour chaque type de bots, on peut avoir plusieurs instances d'un même bot si l'on veut par exemple avoir deux channels configurés pour afficher deux repository git différents.
Script Python
Pour démontrer que vos services REST sont écrits correctement, et pas uniquement accessible en Java, il vous est demandé de fournir un petit script Python 3 permettant d'afficher les dix derniers messages d'un channel particulier. Le script devra être suffisamment configurable pour que l'on puisse changer le nom de la machine sur laquelle tourne le server, le nom du channel, le nombre de message à afficher etc.

Les channels et les messages dont accessible par le serveur sous forme d'un services REST.
Le serveur Web est imposé, il s'agit de vertx dans une version spéciale Marne la Vallée appelée mini-vertx. Cette version ne contient que les librairies nécessaires et est plus ou moins compatible avec Java 9 si vous ajouter les deux --add-exports suivant lorsque vous exécuté avec la commande java:

 
    --add-exports java.base/sun.nio.ch=ALL-UNNAMED
    --add-exports java.base/sun.net.dns=ALL-UNNAMED

Vous pouvez aussi regarder l'exemple ExampleApp.java fourni dans le répertoire src.
Note: pour exécuter le code vous devez aussi mettre l'ensemble des libraries de vertx (vertx/lib) dans le classpath (ou sous vous avez le courage les transformer en module).

Pour la lecture de XML (pour les flux RSS) vous utiliser les APIs du JDK 9.
Pour la serialization/deserialization JSON des requètes, vous utiliserez la librarie jackson déjà présente dans vertx.
La base de donnée est SQLite dans sa version 3.14, en utilisant l'API Java sqlite-jdbc-3.14.2.1.jar.

Le projet (un seul fichier par binôme) doit être déposé par le binome dont le nom est le premier dans l'ordre alphabétique sur la plateforme elearning avant le 31 décembre 2016 à minuit.
Le livrable est un fichier au format ZIP (avec l'encodage correct si vous utilisez Windows) et devra contenir dans un répertoire principal à vos deux noms

un répertoire src contenant les sources du projet avec autant de sous répertoires que de modules Java 9;
un répertoire docs contenant le manuel de l'utilisateur (user.pdf d'une dizaine de pages) et le rapport qui explique votre architecture (dev.pdf d'une vingtaine de pages diagrammes UML compris) au format PDF;
un répertoire classes vide dans l'archive et qui contiendra les classes une fois compilées
un répertoire libs qui contiendra les jars des libraries externes.
un répertoire demo contenant le script de test Python test-api-rest.py.
un build.xml (écrit à la main, pas illisible car généré par un outil) qui permet de
- compiler les sources (target compile)
- créer le jar exécutable (target jar)
- générer la javadoc dans docs/api (target javadoc)
- nettoyer le projet pour qu'il ne reste plus que les éléments demandés (target clean)

Ce projet est évalué par les enseignants de Java, la deuxièmes semaine de janvier sous forme d'une soutenance de 10 mins (on discutera architecture et code)

Concurrence
L'implantation de l'API des bots doit permettre que chaque instance d'un bot est sa propre thread et que les appels à travers l'API au reste de l'application soit thread-safe.
Le code doit clairement séparer la gestions des threads du reste du programme, utiliser les principes de la programmation objet pour encapsuler la gestion de la concurrence en utilisant les principes et techniques vus en cours.
La présence de classes qui devraient être thread safe mais qui permettent une utilisation non-thread safe de ses méthodes sera très sévèrement sanctionnée.
Java Avancé
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, module et reflection).
Pour vous aider, si vous ne respectez pas les indications de "mort imminente" suivantes, il vous sera retiré 4 points pour chaque non respect d'une indication.
- Il ne doit pas y avoir de warnings lorsque l'on passe findbugs.
- Il ne doit pas y avoir de warnings lorsque l'on charge le code dans Eclipse.
- Il ne doit pas y avoir de warnings lorsque l'on compile avec javac.
- Dans un module, les packages d'implantations 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.
- Chaque classe abstraite doit être non publique et pas utilisé comme un type.
- Chaque méthode devra être appelée (pas de code mort).
- Chaque méthode ne doit pas faire plus de 8 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.