Projet d'IR2/IG2

Exercice 1 - IRGMail

1. Configuration
   La configuration, serveur de mail, protocol, login, password, plugins, etc. se fait par un fichier properties unique qui réside sur le serveur (et bien sûr pas accessible à partir d'un browser).
2. Sécurité
   IRGMail ne propose pas par défaut de sécurité à part vérifier que le(s) browser(s) Web qui se connecte(nt) possède(nt) la même adresse IP que le serveur Web, c-a-d vérifier que le serveur et le browser web tournent sur la même machine.
3. Récupération des mails
   IRGMail ne stocke pas lui-même les mails mais doit être capable de récupérer les mails auprès d'un fournisseur de mails en utilisant les protocoles IMAP et POP et leurs versions sécurisées (IMAPS, POPS).
   La récupération des mails doit être asynchrone et se faire en tâche de fond dans une ou plusieurs threads dediées.
4. Stockage des mails
   IRGMail n'utilise pas de base de donnée relationelle/NoSQL pour stocker les messages, ceux-ci restent stockés sur le serveur ayant recu le mail. Bien sûr, pour des questions de performance, une partie des mails peuvent être stockées en mémoire tant que cela reste raisonnable (1 Giga n'est pas raisonnable).
   Le programme doit donc avoir un algorithme spécifique permettant de garder en mémoire uniquement la partie intéressante des mails, qui sont eux mêmes composés d'un entête, d'un corps de message et d'attachement(s).
5. Affichage des mails
   IRGMail doit être capable d'afficher les mails ainsi que leur contenu et afficher automatiquement les nouveaux mails arrivant sans que l'utilisateur n'ait à effectuer d'action.
   De plus, l'affichage doit distinguer les mails qui sont lus des mails qui ne sont pas lus (cet état doit être synchronisé avec le fournisseur de mails).
6. La recherche de mails
   L'application doit permettre de rechercher/filtrer des messages par les valeurs des champs présents dans l'entête. La recherche doit fonctionner comme Google: on tape un truc dans la barre de recherche et ça marche (pas d'option pour dire s'il s'agit d'un mot du titre, du nom de la personne qui a envoyé le mail, etc).
   Pour accélérer les choses, l'application doit maintenir un index sans utiliser de blibliothèque externe.
7. Plugins
   L'application doit être developpée au maximum en utilisant un système de plugins permettant à un utilisateur de configurer son application on ajoutant ou non des plugins (par exemple, pour activer ou non la recherche de mails).
   Ce qu'est un plugin, ainsi que le format de description choisi, sont laissés à votre convenance.
   De plus, on vous demande de développer un plugin spécifique ajoutant une fonctionnalité qui n'est pas listée ci-dessus (ni développée par vos camarades).

• Concurrence
  Le programme doit être permettre à plusieurs clients WEB (browsers) de se connecter en même temps, dans ce cas, les recherches/filtrages seront spécifiques à un client. La récupération des mails doit se faire de façon asynchrone et treadsafe indépendamment du fait qu'un client fasse ou non une requête.
  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 sévèrement sanctionnée.
• Design Pattern
  Le programme doit être architecturé en utilisant les principes de la POO et utilisant quand cela est nécessaire les design patterns (vu ou non en cours).
  Il vous est demandé de fournir un rapport de design (dev.pdf) indiquant comment vous avez architecturé votre pogramme avec des diagrammes de classes UML ainsi que la responsabilité de chaque classe. Mais aussi pourquoi vous avez architecturé votre programme de cette façon plutôt que d'une autre et ce pour chaque décision de design que vous avez prise.
  Pour chaque classe mutable, il vous faut justifier pourquoi cette classe est mutable.
  Il vous est de plus demandé une javadoc complète pour toute les méthodes publiques, écrite en anglais (il vous sera retiré 2 points pour chaque manquement).
• 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 et reflection).
  Pour vous aider, si vous ne respectez pas les indications de "mort imminente" suivantes, il vous sera retiré la moitié des points (10 points, puis 5 points, puis 2 points, puis 1 points) pour chaque non respect des indications.
  • 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.
  • Il ne doit pas y avoir de raw types, de @SuppressWarning non justifié, de cast non justifié.
  • 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.