Differences

This shows you the differences between two versions of the page.

--- 2019_2020:s3:concprogobjet:td:tdreutilisation [2019/11/04 20:36] – [Réutilisation par composition et héritage] blay
+++ 2019_2020:s3:concprogobjet:td:tdreutilisation [2019/11/13 10:08] (current) – [Réutilisation par composition et héritage] blay
@@ Line 1: / Line 1: @@
-/*
+====== TD Introduction aux "Design Patterns" et Réutilisation ======
-====== Réutilisation ======
-Nous voulons gérer un réseau routier.
-Un ''réseau Routier'' est composé de ''PointRoute'' et d'''Arcs Routiers''.
-On veut savoir pour un réseau routier les chemins possibles entre deux points routes.
-La modélisation initiale imaginée est celle du diagramme ci-dessous.
-{{ :2014_2015:s3:concprogobjet:td:reseauroutier.jpg?direct&300 |}}
-Voici le jeu de données à utiliser :
-<code>
-        AR[A8-23:[ Villeneuve:]->[ Sophia:]]
-	AR[N7-14:[ Villeneuve:]->[ Sophia:]]
-	AR[A8-7:[ Villeneuve:]->[ Cagnes:]]
-	AR[N7-14:[ Sophia:]->[ Villeneuve:]]
-	AR[A8-23:[ Sophia:]->[ Villeneuve:]]
-	AR[A8-7:[ Cagnes:]->[ Villeneuve:]]
-	AR[A8-13:[ Cagnes:]->[ Nice:]]
-	AR[A8-13:[ Nice:]->[ Cagnes:]]
-</code>
-Voici des exemples de chemins :
-**de Nice a Sophia :**
-  - [dist.=34, paths=[AR[A8-13:[ Nice:]->[ Cagnes:]], AR[A8-7:[Cagnes:]->[ Villeneuve:]], AR[N7-14:[ Villeneuve:]->[ Sophia:]]]]
-  - [dist.=43, paths=[AR[A8-13:[ Nice:]->[ Cagnes:]], AR[A8-7:[ Cagnes:]->[ Villeneuve:]], AR[A8-23:[ Villeneuve:]->[ Sophia:]]]]
-**de Sophia a Nice :**
-  - [dist.=34, paths=[AR[N7-14:[ Sophia:]->[ Villeneuve:]], AR[A8-7:[ Villeneuve:]->[ Cagnes:]], AR[A8-13:[ Cagnes:]->[ Nice:]]]]
-  - [dist.=43, paths=[AR[A8-23:[ Sophia:]->[ Villeneuve:]], AR[A8-7:[ Villeneuve:]->[ Cagnes:]], AR[A8-13:[ Cagnes:]->[ Nice:]]]]
-**de Sophia a villeneuve :**
-  - [dist.=14, paths=[AR[N7-14:[ Sophia:]->[ Villeneuve:]]]]
-  - [dist.=23, paths=[AR[A8-23:[ Sophia:]->[ Villeneuve:]]]]
-**de Sophia a Cagnes :**
-  - [dist.=21, paths=[AR[N7-14:[ Sophia:]->[ Villeneuve:]], AR[A8-7:[ Villeneuve:]->[ Cagnes:]]]]
-  - [dist.=30, paths=[AR[A8-23:[ Sophia:]->[ Villeneuve:]], AR[A8-7:[ Villeneuve:]->[ Cagnes:]]]]
-Pour cela on vous donne les classes suivantes :
-     - Le package {{ :2014_2015:s3:concprogobjet:td:graphex.zip?direct&300 |grapheX}} duquel ont été extraits les classes utiles à notre problème; ce package a été récupéré sur le web à l'"X"
-     - Le package {{:2014_2015:s3:concprogobjet:td:parcours.zip|parcours}} a été créé pour vous simplifier la tâche et vous permettre de gérer des graphes comportant des sommets reliés par plusieurs arcs.
-Les 2 diagrammes suivants ont été obtenus par reverse Engineering:
-{{ :2014_2015:s3:concprogobjet:td:graphex.jpg?direct&300 |}}
-{{ :2014_2015:s3:concprogobjet:td:parcours.jpg?direct&300 |}}
-*/
-/*
-===== Questions =====
-   - Imaginer comment vous pourriez définir un réseau routier comme un graphe : quels sont les sommets? quels sont les arcs? etc. Compléter/Modifier le diagramme de classe donné au début pour réseau routier avec ces informations. Faire cet exercice sur papier.
-   - Dessiner le diagramme de séquence qui, à partir d'un réseau, vous permet d'obtenir tous les chemins entre deux points routes ordonnés sur la distance entre les noeuds. Faire cet exercice sur papier.
-   - Ecrivez les tests et les codes correspondants. Vous avez comme hypothèse qu'il n'existe pas deux arcs différents entre deux même points qui ont exactement la même distance.
-   - Nous voulons prendre en compte dans notre modélisation, les faits suivants, que devons-nous modifier?
-         - un point route est en ville ou à la campagne,
-         - un point route est déterminé par une coordonnée GPS
-   - Nous voulons calculer les distances entre deux points routes à partir des coordonnées GPS pour associer une distance à un arcRoutier, que devez-vous faire?
-   - Nous voulons à présent utiliser cette modélisation pour obtenir les chemins les plus courts, les chemins qui ne passent pas par l'autoroute, .... A vous !
-<box round rgb(150,290,190) rgb(198,226,150) 75%|Rendu en fonction du groupe de TD Pour le Groupe 2 le 30/11 à 23h59 (Pour S3D: pas de rendu, notation en TD) >
-  * Mettez un mail à votre encadreur avec soit l'adresse où récupérer le TD soit le TD lui-même
-  * Dans votre répertoire de projet, sous TD6, se trouvent (s'il y a des doutes sur le répertoire de livraison, mettez un mail à votre encadreur) :
-       - Un document contenant
-             * votre modèle final (Tout le monde n'aboutit pas au même modèle, c'est certain) (merci de l'intégrer dans un document pour que nous n'ayons pas à ouvrir différents modèles dans différentes versions de l'outil).
-             * des explications sur les raisons de ce modèle (dont vous êtes très fiers) et les leçons apprises.
-       - Les codes et les tests.
-</box>
-*/
-<html>
-<!--
-====== Polymorphisme ======
-Le bus supporte à présent différents types de messages : Rémanent, Ephemere, Fondamental, Protegé, Intelligent ...
-Chacun de ces types de messages répond aux exigences suivantes concernant leur cycle de vie.
-^  ^ Création ^ Lecture ^ MiseAJour ^ Destruction^
-^ Rémanent| Il connait son créateur | --- | Peut être mis à jour par son créateur| Ne peut être détruit que pas son créateur|
-^ Ephemere| --- | Est automatiquement retiré de sa boîte dès qu'il est lu| Ne peut pas être mis à jour| Ne peut être détruit que s'il n'est plus dans une boite|
-^Temporel|Il connait la date où il a été créé et sa durée |Il ne peut être lu que s'il n'est pas périmé. S'il est périmé, il est détruit lorsque l'on demande à le lire|Peut être mis à jour| Est automatiquement détruit quand il est périmé|
-^ Intelligent|Il connait son créateur|N'est proposé qu'à ceux qui ne l'ont pas encore lu| Ne peut pas être mis à jour|Ne peut être détruit que si il a été lu au moins une fois||
-^ Re-armable | --- | --- | Il peut être réactivé | Il disparait en lecture au bout d'un temps donné, il doit alors être réactivé et s'il n'est pas re-armé, au bout d'un certain temps il est détruit|
-**A FAIRE**
-  - Proposer un modèle de classes en conception
-  - Vérifier que tous les scénarios sont "faisables"...
-  - Vérifier les propriétés vues en cours
-  - Implémenter et tester votre code sur les scénarios donnés.
-  - Vérifier que tous vos scénarios précédents sont toujours fonctionnels, en utilisant les tests. Si ce n'est pas le cas, mettez vos codes à jour pour satisfaire les tests.
-  - Quel impact sur le calcul du nombre de messages dans une boîte ?
-Proposer un modele d'IHM de reception des messages pour les aider à comprendre... ou les laisser faire?
-ou la leur donner et les laisser la connecter?
-===== Responsabilités =====
-En fonction des mots clefs qui constituent le contenu des messages, ils sont automatiquement associés à une boîte de message. Si aucune correspondance n'est détectée une boîte "Divers" est utilisée.
-Exemples :
-     - "Accident " conduit à poster le message dans la boite "URGENCE"
-     - "Danger " conduit à poster le message dans la boite "URGENCE"
-     - "photo " conduit à poster le message dans la boite "SNAPCHAT"
-**A FAIRE**
-    - Qui crée les messages?
-    - Qui est responsable de filtrer les mots clefs?
-    - Quel est la complexité du filtrage?
-    - Déterminer le couplage de vos classes
-===== Abstraction =====
-Si maintenant, on veut créer une nouvelle boîte qui reçoit les messages contenant contenant "photo", que faut-il faire pour que votre système le prenne en compte?
-Si maintenant on veut que tout message dans la boite SNAPCHAT soit ephemere ?
-===== Estimation de performance =====
-Une route est définie par des Tronçons. Un tronçon est défini par deux Positions et une longueur. Une Position est définie par un nom.
-Calculer le plus cours chemin entre deux positions.
-Déterminer la complexité de votre algorithme.
-=> Outils de recherche de code dupliqué?
-===== Suites prévues pour ce projet =====
-  * //Objectifs  : refactoring, incrémentalité et agilité// : Le bus est maintenant composée de boîtes à messages :
-Le bus gère des "boîtes à message". Plusieurs producteurs peuvent émettre des messages vers une même boîte, plusieurs consommateurs peuvent lire les messages dans une boite.
-Dans le scénario de base, la voiture A a choisi d'émettre son message vers la queue "Etat Des Routes". Les consommateurs déclarent les boîtes qui les intéressent. Ils peuvent lire les messages qui les intéressent sur une boîte donnée ou obtenir tous les messages qui les intéressent indépendamment des boîtes.  Plusieurs types de messages? Qui est responsable de créer les messages? Qui connait les boîtes de messages ?
-  * //Objectifs : Apprentissage d'une famille courante de patterns (fabrique, builder) mais uniquement par l'usage, la formalisation se fera en S4//: Les messages pouvant être de différentes natures, un bus devient "porteur" d'une fabrique à messages.
-  * //Objectifs : Prise en compte des IHMs et mise en place du pattern MVC à tous les niveaux// : Définir les interfaces graphiques qui nous permettraient d'accéder "simplement" à un bus pour émettre, lire et effacer des messages uniquement.
-  * //Objectifs : Prise en considération des responsabilités uniques// : Routage en fonction des messages : La voiture A emet un message et le bus décide de la ou des boîtes à messages concernées.
-  * //Objectifs : mise en oeuvre du pattern DAO + différents modèles de persistance + intégration par les interfaces + travail en équipe// : Les messages seront rendus persistants. Pour certaines boîtes les messages sont persistants, pour d'autres non :
-  * Il est assez surprenant d'effacer les messages au bout d'un certain temps alors que certains consommateurs ne les ont pas lu et de redonner le même message au même consommateur qui l'a déjà lu. Que feriez-vous pour : a) ne pas redonner le même message au même consommateur; b) donner les messages aux consommateurs qui ne les ont pas encore lu? quel écueil( le bus ne connait pas ses consommateurs!) ? quelle solution envisageriez-vous (un consommateur se déclare, une file d'attente par consommateur, et le message est détuit lorsque plus aucune file n'y fait référence)?
-- Il sera possible de définir différentes formes de souscription.
-Nous n'aborderons, hélas, pas les aspects distribués.
-!-->
-</html>
-====== TD Réutilisation ======
 Objectifs :
@@ Line 179: / Line 18: @@
-<box round rgb(135,206,250) rgb(0,191,255) 75%|**Votre défi** >
+<box round rgb(224,255,255) rgb(0,191,255) 75%|**Votre défi** >
 Faire passer les tests sans les modifier si ce n'est la référence à la classe "//SocialNetwork//" qui implémente //SocialNetworkInterface// et en développant un code propre.
 Voici les archives : //((Tips : Prenez chaque archive, déposer la sous Eclipse, dezipper, refresh))//
-    - les {{:2018_2019:s3:concprogobjet:td:archivegraphes.zip|classes de manipulation des graphes}} :
+    - les classes de manipulation des graphes:
-               - les classes du package grapheX, vous en avez besoin pour l'exécution, mais vous n'avez pas besoin de les comprendre.
+               - les classes du package {{:2019_2020:s3:concprogobjet:td:graphex.zip|grapheX,}} vous en avez besoin pour l'exécution, mais vous n'avez pas besoin de les comprendre.
-               - les classes du package grapheSimple vous allez en avoir besoin. Regardez bien **ces classes** et construisez rapidement le modèle de classes correspondant, par exemple avec ObjectAid),
+               - les classes du package {{:2019_2020:s3:concprogobjet:td:graphesimple.zip|grapheSimple}} vous allez en avoir besoin. Regardez bien **ces classes** et construisez rapidement le modèle de classes correspondant, par exemple avec ObjectAid),
-    - les {{:2018_2019:s3:concprogobjet:td:archivetests.zip|classes de tests}} : celle sur les graphes pour vérifier et celle contenant les tests à faire passer. (pensez à la mettre dans un source folder dédié aux tests (ou sous test si vous êtes sous maven); Fixez le setup en ajoutant JUnit 5; exécutez les tests)
+    - les classes définissant le réseau {{:2019_2020:s3:concprogobjet:td:facebookghost.zip|Facebookghost}}
-    - {{:2018_2019:s3:concprogobjet:td:facebookghost.zip|les classes définissant le réseau Facebookghost}}
+    - les {{:2019_2020:s3:concprogobjet:td:corers.zip|interfaces à implémenter}} pour faire passer les tests
-    - {{:2018_2019:s3:concprogobjet:td:archivereseausocial.zip|les interfaces à implémenter pour faire passer les tests,}}
+    - les classes de tests :
+           - celle sur les graphes pour vérifier dans l'archive ''graphesimple''
+           - {{:2019_2020:s3:concprogobjet:td:testsyourcode.zip|celles contenant les tests à faire passer.}}
+    - Fixez le setup en ajoutant JUnit 5; exécutez les tests
-===> Pour ceux qui ont déjà chargé des codes, voici les codes de {{:2018_2019:s3:concprogobjet:td:graphesimple.zip|ParcoursSimple}} corrigés et dans l'archive de tests les codes ont été corrigés en conséquence.
 LOL**Vous n'avez que deux interfaces à implémenter : ''SocialNetworkInterface'' et ''MemberInterface''.
 Ce qui suit est là pour vous aider.** }}
 </box>
-La figure suivante visualise les interfaces et classes fournies pour les tests.
-{{ :2016_2017:s3:concprogobjet:td:capture_d_e_cran_2016-10-16_a_22.07.17.png?direct&300 |}}
+===== Réutilisation par composition et héritage =====
-{{ :2016_2017:s3:concprogobjet:td:capture_d_e_cran_2016-10-16_a_22.42.15.png?direct&300 |}}
+<note tip>Un réseau social peut être vu comme un graphe.
+  * //Rechercher des relations entre ses membres// revient à parcourir le graphe.
+  *  Utilisez la classe ''GrapheSimple''((Ces codes sont basés sur le package GrapheX fournis par l'"X" dans ses cours, pour en savoir plus (page évolutive): https://www.enseignement.polytechnique.fr/informatique/INF431/X06-2007-2008/TD/INF431-td_6-1.php )).
+</note>
-===== Réutilisation par composition et héritage =====
+<note warning>Personne n'écrit la moindre ligne de code sans avoir réfléchi sur papier au modèle UML correspondant à l'implémentation qu'il s'apprête à réaliser. Aucune aide ne sera apportée si ce modèle ne peut pas être montré. </note>
   - Vous devez construire un réseau social dont les spécifications sont les suivantes (cf. Interfaces //SocialNetworkInterface// et //MemberInterface//):
-       * un membre //a// un nom, un âge et des passe-temps;
+       * un réseau social est un ensemble de membres qui sont en relation;
-       * Un membre //a// est en relation avec membre //b// avec une force entre Faible (LOW) et Très forte (STRONG).
+       * un membre a un nom, une localisation (String) <del>et une introduction (String)</del>;
-       * //a// peut se considérer en relation avec //b// à la force 1 et //b// ne pas se considérer en relation avec //a//!
+       * Un membre //a// est en relation avec membre //b// avec une force entre Faible (LOW) et Très forte (STRONG). Plus la relation est forte plus on considère que la distance est courte. La classe //Strength// qui représente cette force vous est donnée.
+       * //a// peut se considérer en relation avec //b// à la force STRONG et //b// ne pas se considérer en relation avec //a//!
        * On veut pouvoir savoir quels sont les membres en relation avec un membre au rang X :
               * exemple : a -> b -> c -> a :
@@ Line 217: / Line 61: @@
                * Méthode : ''relateToRank(MemberInterface member, int rank)''
        * On veut pouvoir calculer la distance entre 2 personnes, en choisissant la plus courte distance :
-             * exemple :  a --1--> b --5--> c et a --2--> d --5-> c :
+             * exemple :  a --STRONG(1)--> b --LOW(4)--> c et a --HIGH(2)--> d --LOW(4)-> c :
-                 * la distance est de 1 entre a et b ;
+                 * la distance est :  de 1 entre a et b ; de 2 entre a et d;
-                 * elle est de 2 entre a et d;
+                 * la distance est de 5 entre a et c (1 + 4 qui est plus court que 2+4 )
-                 * la distance est de 6 entre a et c (1 + 5 qui est plus court que 2+5 )
              * Méthode : ''distance(MemberInterface de, MemberInterface a)'')
+       * D'autres méthodes doivent être définies, il suffit de lire l'interface "SocialNetworkInterface".
-D'autres méthodes doivent être définies, il suffit de lire l'interface "SocialNetworkInterface".
-<note tip>Un réseau social peut être vu comme un graphe.
+<note warning>Cette partie du TD doit être terminée lors de la 1e séance. Si ce n'est pas le cas, vous devez travailler en dehors des heures du TD.Elle correspond aux 2 premières séries de tests.</note>
-//Rechercher des relations entre ses membres// revient à parcourir le graphe.
-Pour vous aider (et c'est aussi obligatoire ;-) ) vous utiliserez **la classe ''GrapheSimple'' et la classe ''ParcoursSimple''** pour calculer des chemins ((Ces codes sont basés sur le package GrapheX fournis par l'"X" dans ses cours, pour en savoir plus (page évolutive): https://www.enseignement.polytechnique.fr/informatique/INF431/X06-2007-2008/TD/INF431-td_6-1.php )).
-La figure suivante visualise une part de ces codes.
-{{ :2018_2019:s3:concprogobjet:td:existant.gif?direct&300 |}}
-Celle-ci les interfaces à implémenter
-{{ :2018_2019:s3:concprogobjet:td:reseau.gif?direct&300 |}}
-</note>
-<note warning>Cette partie du TD doit être terminée lors de la 1e séance. Si ce n'est pas le cas, vous devez travailler en dehors des heures du TD.</note>
 ===== Réutilisation par adaptation =====
   - On veut intégrer dans notre réseau social, des membres du réseau ''facebookGhost''. Lisez bien toute la suite avant de commencer.
-        * Les classes du package //facebookGhost// s'inspirent très fortement de l'interface fournie par Facebook. En cela, elles se comportent comme un "Mock" simplifié qui pourrait être remplacé par le véritable reseau Facebook à terme((Pour cela, il faudrait quand même mettre à jour ce code avec les dernières évolutions de l'interface et le compléter... donc il reste "un peu" de travail)). ).
+        * Les classes du package //facebookGhost// s'inspirent très fortement de l'interface fournie par Facebook. En cela, elles se comportent comme un "Mock" simplifié qui pourrait être remplacé par le véritable réseau Facebook à terme((Pour cela, il faudrait quand même mettre à jour ce code avec les dernières évolutions de l'interface et le compléter... donc il reste "un peu" de travail)). ).
-        * On veut ajouter dans notre réseau des membres qui correspondent à des "Users" du reseau  facebookGhost (FG). Pour cela, il suffit de créer le membre en déclarant qu'il existe dans un autre réseau((Comme vous le feriez en vous demandant à vous connecter par votre compte facebook par exemple));
+        * On veut ajouter dans notre réseau des membres qui correspondent à des "Users" du réseau  facebookGhost (FG). Pour cela, il suffit de créer le membre en déclarant qu'il existe dans un autre réseau((Comme vous le feriez en vous demandant à vous connecter par votre compte facebook par exemple));
              - le **nom** du "User" dans le reseau facebookGhost (//name//) devient le nom du membre dans notre réseau (//nom//)
-             - on garde la référence sur le "User" pour avoir toujours une **description** à jour qui correspond au //profil//. Ainsi les membres de notre réseau qui sont associés à un User de FG ne contiennent pas de //description//. La demande de description d'un tel membre dans notre réseau correspond à retourner son profil défini dans le réseau FG ((En résumé, si vous modifiez votre profil dans facebook, vous n'avez pas besoin de le mettre à jour notre réseau))  ;
+             - l'accès à sa localisation correspondent à sa "Home" dans FG. La localisation peut évoluer dans FG. Nous voulons donc qu'elle soit toujours à jour dans notre réseau. Que faire? En tous cas, IL NE FAUT PAS simplement recopier ces valeurs dans le membre de notre réseau.  ;
              - on "récupère" dans notre réseau, les **relations** définies dans le réseau FG lorsque
                        - les users ciblés sont connus de notre réseau, c'est à dire que nous avons déjà un membre de même nom;
-                       - elles correspondent à des relations familiales ou des relations d'amitiés. Par défaut, une relation de famille correspond à une relation de force 2 dans notre réseau et celle d'amitié ont une force 3.
+                       - elles correspondent à des relations familiales ou des relations d'amitiés. Par défaut, une relation de famille correspond à une relation de force HIGH dans notre réseau et celle d'amitié ont une force MEDIUM.
-                       - Nous considérons que les relations inverses existent également dans notre réseau.
+                       - Nous considérons que les relations inverses existent également dans notre réseau. //Donc si Peter est ami avec John dans FG, dans notre réseau Peter est en relation avec John par un lien Medium et John est en relation avec Peter avec un lien Medium//.
-                       * Quand on ajoute dans notre réseau un membre correspondant au réseau FG, on recherche parmi ses relations directes dans FG s'il existe des users connus de notre propre réseau et on lui ajoute les relations si elles n'existaient pas, exemples :
+                       * Quand on ajoute dans notre réseau un membre correspondant au réseau FG, on recherche parmi ses relations directes dans FG s'il existe des "users" connus de notre propre réseau et on lui ajoute les relations si elles n'existaient pas, exemples :
-                                 * Exemple :  Hercule est connu du réseau FG et se déclare comme membre de notre réseau (''addMember("Hercule", true)'')
+                                 * Exemple :  Hercule est connu du réseau FG et se déclare comme membre de notre réseau (''addMember("Hercule", FG)'')
-                                         - On récupère du réseau FG son nom.
                                          - On récupère sa famille (Zeus, Alcmène) et ses amis (Admète)
-                                         - Seuls Zeus et Admete sont connus de notre réseau; la relation de Hercule vers Zeus est ajoutée avec une force de 2 (lien de famille), celle entre Hercule et Admete est ajoutée avec une force de 3 (lien d'amitié); nous mettons également à jour les relations inverses avec la même force.
+                                         - Seuls Zeus et Admete sont connus de notre réseau; la relation de Hercule vers Zeus est ajoutée avec une force HIGH (lien de famille), celle entre Hercule et Admete est ajoutée avec une force MEDIUM (lien d'amitié); nous mettons également à jour les relations inverses avec la même force.
 ===== Réutilisation par observation =====
@@ Line 305: / Line 134: @@
 Ce n'est pas grave. Si vous avez compris les principes du Patron, vous pourrez les retrouver dans d'autres paradigmes tels que les files d’attente (queues), les sémaphores (semaphores ), ou les gestionnaires d'évènements dans ''java.beans'' package.
-===== Rendu =====
-    - un diagramme UML qui visualise uniquement les classes/interfaces dont votre code **dépend directement**.
-          * le diagramme vise à visualiser l'architecture de votre solution
-                    * **les différents patterns apparaissent sous forme d'annotations** si ce n'est pas évident (e.g. si une classe hérite ''d'observable'' c'est évident, mais si ''User'' correspond à l'''<Adaptee>'' cela ne l'est pas.)
-          * le diagramme peut être obtenu par reverse-engineering, c'est même conseillé, mais doit être adapté pour répondre aux points précédents.
-    - les codes sources des classes que vous avez créées ou modifiées exclusivement.
-La date du rendu au plus tard : mardi 4 décembre à 8h (S3T)
-La date du rendu au plus tard : vendredi 14 décembre à 19h (S3A)
-Sur [[http://jalon.unice.fr/cours/blay/Cours-blay-20150930110548/BoiteDepot-blay-20161116105407498020|Jalon]] avec comme nom pour l'archive :  Gr <numeroGroupe> + Nom des étudiants dans le groupe