Differences

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

--- 2018_2019:s3:concprogobjet:td:td6 [2018/11/19 22:47] – [Réutilisation par composition et héritage] blay
+++ 2018_2019:s3:concprogobjet:td:td6 [2018/12/10 14:23] (current) – [Rendu] blay
@@ Line 30: / Line 30: @@
     - {{:2018_2019:s3:concprogobjet:td:archivereseausocial.zip|les interfaces à implémenter pour faire passer 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.
@@ Line 80: / Line 81: @@
   - On veut intégrer dans notre réseau social, des membres du réseau ''facebookGhost''. Lisez bien toute la suite avant de commencer.
-        * Vous avez déjà récupéré un "bouchon/proxy". En effet, les classes du package //facebookGhost// s'inspirent très fortement de l'interface fournie par Facebook. En cela, elles se comportent comme un "proxy" 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 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)). ).
-        * 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 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));
-             * le nom du "user" dans le reseau facebookGhost (name) devient le nom du membre dans notre réseau (nom)
+             - 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 notre réseau ne contient pas la description du membre mais à la demande de description, on va la chercher dans le réseau FG ((En résumé, si vous modifiez votre profil dans facebook, vous n'avez pas besoin de de mettre à jour celle-ci dans l'autre réseau))  ;
+             - 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))  ;
-             * on "récupère" dans notre réseau, les relations qui correspondent soit à des relations familiales, soit à des relations d'amitiés 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. 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.
+             - on "récupère" dans notre réseau, les **relations** définies dans le réseau FG lorsque
-                 * 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 :
+                       - les users ciblés sont connus de notre réseau, c'est à dire que nous avons déjà un membre de même nom;
-       * Exemple :  Hercule est connu du réseau FG et se déclare comme membre de notre réseau (''addMember("Hercule", true)'')
+                       - 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.
-                    * On récupère du réseau FG son nom.
+                       - Nous considérons que les relations inverses existent également dans notre réseau.
-                    * On récupère sa famille (Zeus, Alcmène) et ses amis (Admète)
+                       * 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 :
-                    * 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.
+                                 * Exemple :  Hercule est connu du réseau FG et se déclare comme membre de notre réseau (''addMember("Hercule", true)'')
+                                         - 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.
 ===== Réutilisation par observation =====
@@ Line 95: / Line 99: @@
 Le réseau FG évolue. De nouvelles relations sont régulièrement créées et notre propre réseau peut alors devenir obsolète si les membres impliqués font partie de notre réseau et que nous n'enregistrons pas ces changements de relations.  Mais bien sûr, il est impossible de modifier les codes du réseau FG....
-Heureusement, le réseau FG est observable. On peut donc demander à être notifiés des modifications du réseau FG!
+Heureusement, le réseau FG est observable. On peut donc demander à être notifié des modifications du réseau FG!
 Chaque fois qu'une nouvelle relation est ajoutée dans FG on veut vérifier si les "users" mis en relation existent dans notre réseau et si c'est le cas on crée les relations correspondantes dans notre réseau.
-Il suffit donc de déclarer notre réseau comme Observer du réseau FG et à chaque notification d'ajout d'une relation, de mettre à jour notre propre réseau si c'est nécessaire.
+Il suffit donc de déclarer notre réseau comme "Observer" du réseau FG et à chaque notification d'ajout d'une relation, de mettre à jour notre propre réseau si c'est nécessaire.
-<html>
+//Facultatif & Difficile// : Chaque fois qu'un nouveau user est ajouter dans FG, on veut vérifier s'il existe déjà dans notre réseau et si c'est le cas le "connecter" à notre réseau ...  En fait si vous avez utilisé un adaptateur comme étant un extends de Member, vous ne pourrez pas le faire facilement.
-<!-- Plus complexe : Chaque fois qu'un nouveau user est ajouter dans FG, on veut vérifier s'il existe déjà dans notre réseau et si c'est le cas le "connecter" à notre réseau...  --!>
-</html>
-===== Rendu =====
-    - un diagramme UML qui visualise uniquement les classes/interfaces dont votre code dépend directement.
+=====  A vous,  tout seul !  (5mn) =====
+Nous désirons contrôler l'activité de notre réseau.
+A terme nous envisageons de suivre cette activité selon plusieurs aspects (afficheur sous forme de courbes de création des membres dans le temps; lever d'alertes lorsque le nombre de relations sur un membre est important; ...).
+Pour l'instant, nous vous demandons d'afficher chaque fois qu'un nouveau membre ou qu'une relation est créée et bien sûr l'affichage ne se fait pas dans vos codes d'implementation du réseau.
+Voici un exemple de début de trace :
+<code>
+New Member created Member [age=20, description=l'ami, nom =Admete]
+New Member created Member [age=20, description=le dieu ..., nom =Zeus]
+New Member created Member [age=20, description=la femme de zeus, nom =Hera]
+New Relation created (3:Member [age=20, description=le hero, nom =Hercule], Member [age=20, description=l'ami, nom =Admete])
+New Relation created (3:Member [age=20, description=l'ami, nom =Admete], Member [age=20, description=le hero, nom =Hercule])
+New Relation created (2:Member [age=20, description=le hero, nom =Hercule], Member [age=20, description=le dieu ..., nom =Zeus])
+New Relation created (2:Member [age=20, description=le dieu ..., nom =Zeus], Member [age=20, description=le hero, nom =Hercule])
+New Member created Member [age=20, description=le hero, nom =Hercule]
+New Relation created (2:Member [age=20, description=le dieu ..., nom =Zeus], Member [age=20, description=la femme de zeus, nom =Hera])
+New Relation created (2:Member [age=20, description=la femme de zeus, nom =Hera], Member [age=20, description=le dieu ..., nom =Zeus])
+New Member created Member [age=0, description=Asterix, le plus intelligent, nom =Asterix]
+New Member created Member [age=0, description=falbala, la plus jolie, nom =Falbala]
+New Member created Member [age=0, description=Obelix, le plus intelligent, nom =Obelix]
+New Member created Member [age=0, description=Panoramix, le plus magique, nom =Panoramix]
+New Member created Member [age=0, description=Abraracourcix, chef du village, nom =Abraracourcix]
+</code>
+===== Remarque =====
+**[[https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html|Dépréciation]] des Interfaces Observer et Observable en Java 9.**
+//This class and the Observer interface have been deprecated. The event model supported by Observer and Observable is quite limited, the order of notifications delivered by Observable is unspecified, and state changes are not in one-for-one correspondence with notifications.//
+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 attributs faisant référence à des classes/interfaces sont uniquement représentés sous la forme d'associations (rôle, cardinalité, orientée)
+                    * **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.)
-                    * pas de getter et setter
+          * 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.
-                    * pas de classes non directement utilisées par exemple, GrapheX etc.
-                    * les différents patterns apparaissent sous forme d'annotations
-          * le diagramme peut être obtenu par reverse-engineering 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 : 28/11 à 23h45
+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)