Outils et Méthodes - Réseau social professionnel

Dimension: px

Commencer à balayer dès la page:

Download "Outils et Méthodes - Réseau social professionnel"

Heloïse Boutin
il y a 8 ans
Total affichages :

1 Outils et Méthodes - Réseau social professionnel Franck Sajous - CLLE-ERSS Ce document est disponible à l'adresse : 1 Diagramme de classes 1.1 Membres et connexions Premier point délicat : dénir ce qu'est une connexion! Si le membre M 1 est connecté au membre M 2, on dit que M 2 est une connexion de M 1. On pourrait dire que (donc) une connexion est un membre. Par ailleurs, on veut identier 3 types de connexions diérents. On peut alors : soit créer 3 classes dérivées de la classe Connexion (g. 1(a)), soit ajouter un attribut à 3 valeurs possibles dans la classe Connexion (g. 1(b)). Les deux modélisations sont équivalentes. Membre -nom: String Membre -nom: String Connexion ConnexAmi ConnexCollègue ConnexPromo (a) Typage des relations par dérivation Connexion -type = {ami,collègue,promo} (b) Typage des relations par attribut Figure 1 Modélisation de Connexion comme une spécialisation de Membre Enn, on peut modéliser le fait qu' un membre peut avoir des connexions par une relation d'agrégation (g. 2). Figure 2 Relation entre un membre et ses connexions

Si le membre M 1 est connecté au membre M 2, on dit que M 2 est une connexion de M 1. On pourrait dire que (donc) une connexion est un membre.

2 Or cette modélisation pose un problème (on s'en rend compte dès que l'on tente de créer un diagramme d'objets). Si l'on s'intéresse à un membre, John Doe, et que l'on veut modéliser qu'il a une connexion (amie) Jane Doe, on crée une instance de ConnexionAmi (dans le cas de la modélisation 1(a)) ou une instance de Connexion, avec ami comme valeur du paramètre type dans le cas de la modélisation 1(b). Dans ce cas, comment modéliser le fait que Jane Doo est également une connexion, de type collègue, d'un autre membre M x? C'est impossible... et c'est tant mieux! En eet, ami de John Doe n'est pas une propriété intrinsèque de qui que ce soit. D'ailleurs, lorsqu'un membre crée son prol, il ne gure encore encore parmi les connexions d'aucun autre membre et n'en est pas moins un membre lui-même. Il faut repenser la notion de connexion comme lien entre deux membres. Dire qu'un membre M 1 est une connexion d' un membre M 2 signigie alors qu'il existe un lien entre ces deux membres. Mais ici est-une est un indicateur non pertinent (et trompeur) d'une relation d'héritage. En renvanche, existe un lien entre pourrait être un indicateur de relation. Membre -nom: String * * connecté à Figure 3 Modélisation des connexions par une relation réexive sur Membre Le modélisation présentée en gure 3 est bonne, si ce n'est qu'elle ne permet pas de préciser le type de relation. Dans ce cas, optez pour une classe. Les deux modélisations présentées en gure 4 reprennent celles vues en gure 1 en changeant la nature de la relation entre Connexion et Membre et en spéci- ant les multiplicités. Une connexion n'est plus un membre (changement de la relation d'héritage en relation classique), mais un objet relié à deux instances de Membre (revoir la relation sépare entre les classes Frontière et Pays dans l'exercice Voyageur de Commerce). (a) (b) Figure 4 Modélisation de Connexion par une classe dont chaque instance relie 2 instances de la classe Membre 1.2 Compétences et approbations La gure 5 illustre deux manières de modéliser qu'un membre possède ou déclare des (aucune à plusieurs) compétences. On ajoute le fait qu'un 2

de Connexion, avec ami comme valeur du paramètre type dans le cas de la modélisation 1(b).

3 membre donné puisse approuver une compétence déclarée par un autre membre (g. 6). (a) (b) Figure 5 Compétences déclarées par un membre (a) (b) Figure 6 Approbation des compétences Notez dans les gures 5 et 6 que seule une multiplicité (*) de la relation déclare/possède a été renseignée : elle signie qu'une instance de Membre donnée (un membre, donc) peut déclare 0 ou plusieurs compétences. Mais à une instance donnée de Compétence, combien d'instances de Membre peut-on associer par cette relation? C'est-à-dire combien de membres peuvent déclarer une relation donnée?. Cela dépend de ce que l'on modélise à travers la classe Compétence. En eet, si John Doe et Jane Doe déclarent posséder la compétence Java, combien d'instances de la classe Compétence sont censées apparaître dans le diagramme d'objets correspondant? Si l'on ne considérait pas la notion d'approbation, on pourrait concevoir qu'une seule instance est susante : si 100 personnes déclarent avoir une compétence en Java (ou plutôt la compétence Java), on peut relier 100 instances de la classe Membre à une seule instance de la classe Compétence (dont l'attribut nomcompétence vaut Java ). Si l'on considère la notion d'approbation, comment modéliser dans ce cas le fait que John Doe conrme que Jane Doe possède bien la compétence Java? Il faut considérer qu'une instance de Compétence donnée est liée à une instance de Membre donnée, par exemple la compétence Java de Jane Doe, qui n'est pas la même que la compétence Java de MisterX. La mulitplicité de la relation déclare est donc, côté Membre, 1. Une illustration est donnée dans le diagramme d'objets représenté gure 10. L'élément de spécication que l'on ne retrouve pas dans ce diagramme est le fait que pour qu'un membre m 1 approuve une compétence déclarée par un membre m 2, m 1 et m 2 doivent être connectés. Cela relève plutôt d'un contrôle eectué dans l'implémentation. 1.3 Premier diagramme En assemblant les diérentes parties étudiées plus haut, on obtient un premier diagramme intermédiaire, comme présenté en gure 7. 3

renseignée : elle signie qu'une instance de Membre donnée (un membre, donc) peut déclare 0 ou plusieurs compétences.

4 Figure 7 Premier diagramme de classes réseau social professionnel 1.4 Groupe de discussion/messages/modérateurs Cette partie n'est pas commentée en détail. La modélisation se rapproche de celle de l'ent. Deux variantes sont données en gures 8 et 9. Dans le premier (gure 8), on retrouve le fait qu'un membre puisse déclarer une/des compétence(s) et qu'un membre puisse approuver une/des compétence(s). Si l'on imagine que l'on veuille faire apparaître, dans le prol d'un membre, la date à laquelle tel autre membre a approuvée une compétence donnée, la simple relation approuve ne sut plus. On peut alors créer une classe Approbation (diagramme de la gure 9) comportant un attribut date et qui relie (à travers deux relations, réalise et concerne), les classes Membre et Compétence. 2 Diagramme d'objets Le diagramme représenté gure 10 est un diagramme d'objets 1 illustrant diérents cas de gure, et notamment le fait que : un membre peut être connecté à d'autre membres via diérents types de connexion ; un même membre peut approuver plusieurs compétences d'un autre membre (Matthieu T approuve les compétences Java et NLP et Machin) ; une compétence donnée peut être approuvée par plusieurs membres diérents (compétence Java de Machin approuvée par Matthieu T et Aurélie) ; qu'une compétence peut ne pas être approuvée (e.g. compétence Corpus Linguistics de Machin) ; qu'une compétence donnée est bien la compétence d'un membre donné : on fait pour cela gurer deux instances de compétence portant le même nom (la compétence Java de Matthieu T et la compétence Java de Machin) ; 1. Ce diagramme correspond aux choix de modélisation présenté dans le diagramme de classes de la gure 8. 4

Dans le premier (gure 8), on retrouve le fait qu'un membre puisse déclarer une/des compétence(s) et qu'un membre puisse approuver une/des compétence(s).

5 Figure 8 Diagramme de classes réseau social prodessionnel Figure 9 Diagramme d'objets réseau social prodessionnel, variante 5

6 qu'un membre peut être inscrit à un groupe de discussion, y compris lorsqu'il est modérateur ; qu'un groupe de discussion peut contenir plusieurs messages. Figure 10 Diagramme d'objets réseau social professionnel 6

Documents pareils

Recherche dans un tableau

Chapitre 3 Recherche dans un tableau 3.1 Introduction 3.1.1 Tranche On appelle tranche de tableau, la donnée d'un tableau t et de deux indices a et b. On note cette tranche t.(a..b). Exemple 3.1 : 3 6