:: Enseignements :: ESIPE :: E4INFO :: 2018-2019 :: Programmation Orientée Objet - Design Patterns ::

Entraînement TP noté de Design Patterns

Ce TP noté dure environ 3h. (le vrai TP noté durera 4 heures)

Les schéma UML vous permettent d'obtenir des points, n'oubliez pas :

Pas de détail inutile !
- pas de champ private
- en général pas de champ du tout
- pas de méthodes protected
Ne pas oublier ce qui compte !
- les liens entre classes. héritage, implémentation, dépendance, association
- la navigabilité des liens
- la cardinalité des liens
PlantUML
- Utilisez PlantUML pour faire vos schémas.

Exercice 1 - Lancement de ViaLink

On veut lancer un nouveau réseau social professionnel ! Pour le premier prototype, on va démarrer simplement avec les concepts suivants :

des utilisateurs
des groupes : un utilisateur pourra appartenir à plusieurs groupes
des messages postés par un utilisateur sur la page d'un autre utilisateur
des messages postés sur un groupe
un utilisateur doit appartenir à un groupe pour pouvoir poster des messages sur le groupe
des utilisateurs spéciaux, les "robots" qui n'auront pas de page, qui ne pourront pas s'abonner mais qui pourront postés des messages sur la page d'un groupe, mais pas sur celle d'un utilisateur. Par exemple, un robot qui postera automatiquement sur un groupe toutes les dépêches de l'AFP faisant référence à Google, etc...

Nous allons construire ce système par étape.
Un stagiaire a commencé le travail et vous a préparé une première version des classes suivantes :
User.java
Message.java

Dans le but de faciliter la correction, on vous demande de dupliquer le code en le mettant dans un package Java différent pour chaque question, exam1 pour la question 1, exam2 pour la question 2, exam3 pour la question 3, etc.

Ajout de la classe Group
On souhaite ajouter la classe Group. Faites le schéma UML de la solution incluant les classes fournies (que vous avez le droit de modifier) et la nouvelle classe Group
Ecrivez le code correspondant en portant une attention particulière au fait qu'un groupe ne peux pas avoir deux fois le même utilisateur et que l'on veut garder les utilisateurs dans l'ordre d'inscription au groupe.
Pour un Group, seuls les utilisateurs du groupe peuvent poster des messages dans ce groupe.
Ecrivez de plus un test JUnit5 (vous pouvez faire cela en mode TDD) montrant un exemple d'utilisation de votre API.
Horodatage des messages
Il faut que lorsque l'on crée un message, il possède l'heure actuelle, (avec LocalDateTime.now()) et qu'il n'y ait pas de moyen de créer un message non horodaté avec autre chose que l'heure actuelle.
Quelle solution proposez-vous ? Avez-vous mis en place un Design Pattern ? si oui lequel ?
Implémentez la solution retenue.
Modifier le test JUnit5 (vous pouvez toujours faire cela en TDD) pour prendre en compte la nouvelle API.
Statistique et monitoring
Un Group et un User ont une caractéristique commune : ils doivent fournir des fonctions de récupération des derniers messages :
- une fonction donnant la date et l'heure du dernier message
- une fonction donnant le stream des n derniers messages
L'équipe qui est en train de travailler sur les statistiques et le monitoring ne s'intéressent qu'à ces 2 fonctions, elle aimerait donc bien être capable de manipuler les Group et les User de la même manière.
Que proposez-vous ?
Comment évitez-vous la duplication de code ?
Mettez à jour le diagramme UML puis implémenter la solution retenue.
Abonnements
On veut pouvoir être notifié à chaque ajout de message pour un utilisateur ou pour un groupe. Comment allez-vous gérer cette fonctionnalité ? Avez-vous mis en place un Design Pattern ? si oui lequel ? Mettez à jour le diagramme UML et implémenter la solution retenue.
Ajouter un autre test JUnit5 démontrant la nouvelle API en implantant un scénario où lorsque un utilisateur poste un message sur un groupe, le message apparait aussi dans les messages de l'utilisateur.
Note : il s'agit "juste" d'un scénario de test, le code publiant sur l'utilisateur à réception d'une notification doit donc être uniquement dans vos tests JUnit5.
Note: ne compliquer pas les classes existantes pour gérer ce système d'abonnement et de notification. Pensez à la délégation !
Robot
Les Robots sont spéciaux : un robot n'a pas de page avec ses propres messages, mais un robot peut appartenir à des groupes, sur lesquels il sera autorisé à publier des messages. Un Robot ne peut pas poster des messages sur un User : votre conception devra s'assurer que ce n'est pas possible, à la compilation.
Comment allez-vous modifier le design pour prendre en compte les Robots ?
Mettez à jour le diagramme UML puis implémenter la solution retenue.
Verifier avec un autre test JUnit5 qu'un robot peut bien poster un message sur un groupe.
Quota
On veut renforcer les rêgles de sécurité liées à la publication en ajoutant des règles de quota limitant pour un temps donné le nombre de messages qu'un utilisateur ou un robot peut publier.
Le quota d'un utilisateur peut être changé dynamiquement alors que le quota d'un robot est fixe.
On veut aussi pouvoir mettre en place des quotas par utilisateur pour un groupe, ou un quota global à un utilisateur.
Quelles évolutions du design proposez-vous pour prendre en compte ces besoins ? Avez-vous mis en place un Design Pattern ? si oui lequel ?
Mettez à jour le diagramme UML et implémenter la solution retenue. Ecrivez des tests unitaires illustrant les rêgles de quota mises en place.
Conseil : faites d'abord l'implémentation sans les contraintes de temps, et ajoutez-les après.