Differences

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

--- 2019_2020:s3:concprogobjet:td:tdreutilisation [2019/11/08 16:19] – [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 18: / 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 |}}
-{{ :2016_2017:s3:concprogobjet:td:capture_d_e_cran_2016-10-16_a_22.42.15.png?direct&300 |}}
 ===== Réutilisation par composition et héritage =====
@@ Line 50: / Line 45: @@
 </note>
-<note warning>Personne n'écrit la moindre ligne de code sans avoir réfléchit 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>
+<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>
@@ Line 56: / Line 51: @@
   - Vous devez construire un réseau social dont les spécifications sont les suivantes (cf. Interfaces //SocialNetworkInterface// et //MemberInterface//):
        * un réseau social est un ensemble de membres qui sont en relation;
-       * un membre a un nom, une localisation (String) et une introduction (String);
+       * un membre a un nom, une localisation (String) <del>et une introduction (String)</del>;
        * 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//!
@@ Line 74: / Line 69: @@
-<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>
+<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>
 ===== Réutilisation par adaptation =====
@@ Line 81: / Line 76: @@
         * 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//)
-             - l'accès à son introduction ou à sa localisation correspondent respectivement à son profil et à sa Home dans FG. Ces dernières informations peuvent é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.
+             - 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 garde la référence sur le "User" pour avoir toujours une **introduction** à jour qui correspond au //profil//. Ainsi les membres de notre réseau qui sont associés à un User de FG ne contiennent pas de //introduction//. La demande de introduction 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))  ;
              - 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 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 141: / 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