Comment représenter cette idée en UML ?

Version imprimable

26/09/2006, 15h11
RatavasAlucard

Comment représenter cette idée en UML ?

Bonjour,

malgré l'usage de littérature (UML 2 et les design patterns
analyse et conception orientées objets et développement itératif) et les faqs/tuto de développez.com, je n'arrive pas à trouver la représentation à utiliser dans mon cas d'étude.

Pour ne pas rentrer dans les détails "biologiques" de mon exemple, je vais essayer de le formuler différemment. Pardon d'avance si ç'en devient obscur.

Je souhaite en UML représenter une classe "hiérarchie" qui comporte les références suivantes :
- nom du noeud (nom de la personne qui s'y trouve)
- rang du noeud (capitaine, caporal ; chef, sous-chef)
- contexte (administration, privé)
- nom du noeud surordonné (nom du supérieur de ce noeud par exemple)

Chacunes de ces références pointent vers une classe du même nom soit :
- la liste des noms que peut prendre un noeud
- la liste des rangs
- la liste des contextes

Voici mes conclusions :
Ce n'est une composition car si on ne spécifie pas le rang, on peut
tout de même reconstruire la hiérarchie (on peut reconstruire l'arbre).
Je penser que c'était une aggrégation mais comme ma classe hiérarchie pointe deux fois sur la classe nom du noeud, comment représente-on ce "double pointage" ?
Serait-ce une simple association ?
Mon chef m'a suggéré deux choses : de poster sur un forum, puisque je ne trouve pas la réponse à ma question dans le livre, et de regarder un objet UML en forme de triangle qui bien sûr en UML à un sens particulier et là pareil, je n'ai pas trouvé le triangle en UML.

Je serais plus que reconnaissant à toute forme d'aide donc merci d'avance.
29/09/2006, 13h36
ego

si je comprend bien ton truc, tes listes sont des ensembles de valeurs possibles pour les données dont tu parles avant.
On ne représente pas les intervalles de valeur en UML, en général.

Cependant, tu peux éventuellement définir une classe que tu stéréotypes "enum" et dont le nom des attributs seront les valeurs que peuvent prendre les données typées avec cette classe.

Ex :
Classe "enum" : RANG_VALUES
avec les attributs suivant : CAPORAL, CAPITAINE

Classe Noeud
avec entre autres l'attribut rang de type RANG_VALUES

J'espère que cela répond à ta question
29/09/2006, 15h33
RatavasAlucard

1 pièce(s) jointe(s)

En fait, non.
Mais je pense que j'ai mal exposé ma question.:aie:
Pièce jointe 5248
Mon gros sushi là c'est de savoir si j'utilise bien l'aggrégation et la composition. :?
Et pour l'exemple de la liste de noms, je me demande aussi si je représente bien le double lien qu'il y a avec la hiérarchie.:roll:
Néanmoins merci pour la réponse.:D
29/09/2006, 18h50
ego

Pour l'aggrégation, il faut te demander si la liste est une partie de la hiérarchie et pour la composition, tu dois te poser la même question avec en plus, tu dois détruire la liste de nom quand tu "tue" la hiérarchie.

Je n'ai pas l'impression que l'aggrégation et la composition soient adaptées.

Autre point, c'est en général louche d'avoir des classes "Liste de XXX" en UML. On a plutôt une association avec multiplicité > 1 vers un XXX (et non liste de XXX)

Je pense que tu devrais exposer ton problème sans parler d'UML, cela serait plus clair car je ne comprend pas ton modèle UML
29/09/2006, 19h22
RatavasAlucard

Pour l'aggrégation et la composition, c'est ce que j'avais lu.
Le niveau de mes connaissances en UML aujourd'hui fait que :
- le nom (pour ne plus dire la liste, j'ai compris ce que tu voulais dire) fait partie de la hiérarchie
- une hiérarchie sans indication du rang reste une hiérarchie donc on peut tuer la classe rang sans détruire automatiquement la classe hiérarchie
- une hiérarchie sans nom et sans avoir le nom du supérieur, c'est plus une hiérarchie donc si on tue la classe nom, on tue la hiérarchie

au final, c'est peut être ces trois points qui sont faux : on a bien lu la même chose mais je l'ai interprété complètement différemment

mais pour reprendre ton exemple, entre la classe noeud et la classe enum, le lien est de quel type ? association ? aggrégation ?

quant à exposer mon problème sans parler d'UML, j'adorerais mais j'ai besoin de ce moyen d'expression universel pour présenter mon modèle, justement parce que un losange aura pour tout le monde la même signification. après je reconnais totalement que je suis newby.

en tout cas merci pour les éclaircissements
03/10/2006, 20h55
ego

Pas lien avec l'enum, tu utilises l'enum comme type d'un attribut. Tu considères ainsi l'enum comme un type "basic / primitif" au même titre que int, float,...
04/10/2006, 14h49
atome

Salut,

Selon moi, tu devrais te libérer de la notion de "node", et raisonner objet. Conceptuellement, un noeud est une personne intégrée dans une structure hierarchique. Je l'appelle ici "militaire", mais ça importe peu.

Cette personne possède un grade, et est rattachée à un domaine. Son nom l'identifie. Une personne a juste à connaître ses subordonnés. C'est la raison de l'auto agrégation. On pourrait choisir de ne connaitre que le supérieur, il faudrait alors changer la cardinalité.

Je modéliserais ton système comme ça :

http://g.e.c.k.o.o.free.fr/militaire.JPG
05/10/2006, 13h50
RatavasAlucard

Afin de tirer parti / leçon de vos deux réponses :
je peux très bien remplacer ta classe "grade" atome par une classe :
grade
nom_grade : text
n'est-ce pas ?
de plus, j'ai d'autres classes à intégrer :
- une classe commentaire (pour des blâmes par ex) et je sais que les commentaires seront uniques (pas de répétitions) donc en fait je peux rajouter dans la classe militaire un attribut "commentaire : text"
- j'ai une classe état (retraité, arrêt maladie, etc.) : un nom de militaire a un état et parfois cet état le lie à un autre nom de militaire donc au final, j'ai sur la table militaire une auto-aggrégation dans le cadre de la hiérarchie et j'ai une auto-aggrégation pour l'état ?

en tout cas merci pour vos éclaircissements et précisions !
"avamieuparlélUML maintenant le petit D."
05/10/2006, 16h11
RatavasAlucard

1 pièce(s) jointe(s)

Pour peaufiner mes légendes de schéma, je suis retourné sur :
http://laurent-piechocki.developpez....urs/i-p15.html

au final, même si ça ne rend pas bien compte de l'importance de la classe "nom", je me demandais si le schéma suivant ne représentait aussi une hiérarchie:

Pièce jointe 5448

pas tapé, j'ai compris ce que vous exposiez dans les mess. précédents mais du coup je me pose la question !

merci !
05/10/2006, 18h13
atome

Citation:

Envoyé par RatavasAlucard

Afin de tirer parti / leçon de vos deux réponses :
je peux très bien remplacer ta classe "grade" atome par une classe :
grade
nom_grade : text
n'est-ce pas ?

Oui, tu peux. Ma classe n'est pas une classe au sens objet, mais une énumération. En UML ca se représente comme une classe stéréotypée. Ce que tu vois sur mon diagramme ne représente donc pas une classe avec 4 membres, mais un type énuméré pouvant prendre une valeur parmi 4 possibles.

Rien ne t'empêche d'avoir une classe "grade", avec un seul membre "nom_grade", et de conserver un membre dans ta classe militaire, de type "grade".

Seulement, ici, ça sent l'énumération. Assez instinctivement, on garderait la modélisation que j'ai faite, puisque un grade en soit n'a pas d'état ni de comportement, et n'expose aucun service.

Citation:

Envoyé par RatavasAlucard

de plus, j'ai d'autres classes à intégrer :
- une classe commentaire (pour des blâmes par ex) et je sais que les commentaires seront uniques (pas de répétitions) donc en fait je peux rajouter dans la classe militaire un attribut "commentaire : text"

Ici, définitivement, tu ne dois pas faire de classe. Un commentaire est un membre de ta classe militaire, de type texte. Si tu dois gérer plusieurs commentaires, alors ton membre sera une simple collection de strings. La définition d'une classe se justifierait si tu devais associer des informations supplémentaires à un commentaire.

Ex :

------------------------
Classe Commentaire

- Title : string
- Comment : string
- Author : Militaire
- Date : DateTime
-------------------------

Il faudra garder une composition dans tous les cas, entre le Militaire et ses commentaires. Par contre, dans la classe commentaire, le membre author de type "Militaire" sera représenté par une agrégation vers la classe militaire.

Citation:

Envoyé par RatavasAlucard

- j'ai une classe état (retraité, arrêt maladie, etc.) : un nom de militaire a un état et parfois cet état le lie à un autre nom de militaire donc au final, j'ai sur la table militaire une auto-aggrégation dans le cadre de la hiérarchie et j'ai une auto-aggrégation pour l'état ?

Pour l'état, je te conseille une énumération (ex : Etat), une fois de plus. Et ta classe militaire possède un membre de plus, de type Etat. Si tu tiens à en faire une classe, tu n'as aucune auto agrégation à faire. Tu as une simple agrégation (et non pas une composition) entre Militaire et Etat, avec les cardinalités respectives "0..*" et "1".

Cela signifie que plusieurs militaires peuvent référencer la même instance d'Etat (ex : plusieurs retraités).

Voilà ce que ça donnerait :

http://g.e.c.k.o.o.free.fr/militaire2.JPG
05/10/2006, 18h55
RatavasAlucard

Pour les commentaires, je garde ta suggestion sous le coude. Je suis convaincu de l'unicité du commentaire pour un militaire (ça fait un peu parti du cahier des charges on va dire). Dans le cas contraire, j'aurais effectivement opté pour une classe comme tu le proposes.

Ok pour les énumérations : c'est mieux défini maintenant dans ma tête.

Par contre (bah vi sans points négatifs, ça serait pas drôle), pour état, je bute :
si j'ai un état "remplacé", ce n'est dans ton exemple qu'une énumération de plus. ok pas de pb ! mais si je veux signifier que M1 est "remplacé" par M2, avec seulement le lien d'aggrégation, ce n'est pas retranscris ?

En dehors de cette nouvelle question, encore merci !

Citation:

Envoyé par RatavasAlucard

Pour les commentaires, je garde ta suggestion sous le coude. Je suis convaincu de l'unicité du commentaire pour un militaire (ça fait un peu parti du cahier des charges on va dire). Dans le cas contraire, j'aurais effectivement opté pour une classe comme tu le proposes.

Ok pour les énumérations : c'est mieux défini maintenant dans ma tête.

Par contre (bah vi sans points négatifs, ça serait pas drôle), pour état, je bute :
si j'ai un état "remplacé", ce n'est dans ton exemple qu'une énumération de plus. ok pas de pb ! mais si je veux signifier que M1 est "remplacé" par M2, avec seulement le lien d'aggrégation, ce n'est pas retranscris ?

En dehors de cette nouvelle question, encore merci !

Le fait qu'un certain type "d'état" doive obéir à une règle de gestion telle que celle que tu viens d'exprimer t'oblige à considérer plusieurs choses :

Tu ne peux pas mettre au même niveau des états comme "malade" ou "en congés", qui sont informatifs et se suffisent à eux même, avec un état comme "remplacé par", qui représente en fait une règle d'association entre deux militaires.

Il s'agit donc d'une autre notion, que tu devras gérer indépendamment du reste, indépendamment de l'état.

Pour modéliser ça, il y a plusieurs façons de faire. J'aurais tendance à dire qu'un militaire qui est remplacé, l'est parce qu'il inactif. Il peut être inactif pour plusieurs raisons : maladie, mission, congés, etc. Et il peut être inactif sans forcément être remplacé.

Si tu considères que c'est l'état qui est porteur de l'info "remplaçant", alors tu perds déjà une autre information importante : tu ne sais pas pourquoi il est remplacé. Si je suis ta représentation, on sait juste que le militaire M1 est remplacé par le militaire M2, sans savoir si le militaire M1 est en mission, s'il est malade, en congés, etc.

J'adopterais donc la modélisation suivante :

L'état du militaire reste tel que tu le décrivais initialement : une info indiquant l'état du militaire : en congés, malade, en mission, etc. Cette notion reste purement informationnelle.
On ajoute l'information "actif" au militaire, qui peut prendre pour valeur vrai ou faux. Cette info a une valeur fonctionnelle, on peut savoir en la testant si le militaire est en service ou pas, ce qui est finalement la seule chose qui intéressera un supérieur cherchant à connaitre les disponibilités par exemple. Techniquement, il s'agit d'un membre de ta classe militaire, de type booléen.
On ajoute une nouvelle auto agrégation, de militaire vers militaire :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 ------------ |Militaire | |----------| | |remplaçé | |<>---------- | |1 | | | | |__________| | 0..1| | |_________________| remplaçant
En gros, un militaire peut avoir ou non un remplaçant. En t'aidant de la nouvelle info "actif" de la classe militaire, qui a une valeur fonctionnelle, tu devrais pouvoir répondre à ton besoin.

Encore une fois, c'est une façon de faire. Il y en a d'autres. Tu pourrais par exemple te passer de l'info actif/inactif, et simplement tester sur l'existence d'un remplaçant. Tu peux aussi implémenter la gestion des remplacements en imaginant une classe d'association entre deux militaires, ayant un attribut qui indique la raison du remplacement. Etc.

Là, c'est à toi de voir. J'ai tendance à préférer les solutions simples : dans ce contexte tu pourras toujours faire évoluer ton modèle sans trop peiner.

05/10/2006, 20h22
RatavasAlucard

Je prends bien note de tout ça !
Compte tenu de mon cas, je vais pencher pour la classe d'association entre deux militaires avec un attribut !
Mon diagramme n'a déjà plus du tout la même gueule !
'Vont être content à la réunion du 11 !
Je mets ce sujet en résolu, car je commence à m'éloigner de ma question initiale et je veux pas me faire taper sur les doigts.
Merci beaucoup et sûrement à bientôt car j'ai comme dans l'idée que je vais encore mélanger relationnel et UML !

:aie: