Discussion :

[thebloodyman]

Bonjour,

Etudiant, j'ai un souci concernant un projet UML à réaliser.
Ce dernier concerne la conception.
Je m'explique :

Je dois modéliser un service de jeu en ligne qui propose un jeu d'échec.
La classe principale de l'application contiendra 2 tableaux : un de joueur et un autre de plateau.


C'est pour l'use case : création d'un nouveau plateau que j'ai un probleme.
La classe JOUEUR possédera une méthode pour créer un nouveau plateau. A l'interieur de cette méthode, un nouvel objet de type PLATEAU sera créé.
Mais je dois bien sur ajouter ce nouvel objet créé à mon tableau de plateau.
Et c'est la que se pose mon probleme.
Si c'est l'objet USER qui ordonne d'ajouter le nouveau plateau créé au tableau de plateau, il faudra que le tableau de PLATEAU soit visible pour la classe USER et ca m'a pas l'air tres logique d'un point de vue conception.

J'ai aussi pensé à crééer une classe annexe de type "systeme" qui fera la liaison entre les deux.

Quelqu'un a une idée ??

Je ne sais pas si j'ai été clair. Enfin si quelqu'un a a besoin de précisions, n'hésitez pas.

Merci

[slim]

salut,
je vois pas pourquoi tu veux creer un tableau de plateau dans la classe joueur. Tu crees une classe joeur et une classe plateau, avec un lien entre les deux. Un joueur peut jouer que sur un plateau et un plateau peut etre pris par deux joueurs.
je suis pas sur d'avoir bien compris.

[TheLeadingEdge]

Bonjour,

A quel niveau de ta reflexion en es-tu ?
Tu parles de UC et en même temps de méthodes et de classes ?
Les instantiations se décrivent dans 1 diagramme d'interaction, c'est trop haut dans les UC, tu vas probablement tout compliquer à faire qque chose d'inutilement détaillé.

J'ai aussi pensé à crééer une classe annexe de type "systeme" qui fera la liaison entre les deux.

Ca ressemble à 1 "controleur", non ?
Pour moi c'est la bonne piste. On pourrait l'appeler "partie". C'est elle qui va créer les instances de joueur et de plateau et des sets de pièces (etc..)
Ce n'est pas le joueur qui construit le plateau. Il a juste besoin de connaitre "l'état" du plateau. Donc qd c'est à son tour de jouer il interroge l'instance de contrôleur qui lui retourne 1 'collection' de 64 case avec leur état (libre, occupé par 1 piéce noire ou pièce blanche).

A +

[thebloodyman]

slim,

c'est justement ce que j'ai fait.
Mais mon probleme etait plus dans la visibilité.


TheLeadingEdge,

désolé de répondre que maintenant, apres 3 jours d'absence de réponse, j'ai arrété de consulter mon post.
En tous les cas merci beaucoup pour ta réponse constructive et pertinente.

Je parle d'Use Case mais c'était plus le diagramme de séquence qui a révélé mon souci de conception.

Finalement, j'ai justement élaboré une solution qui utilise une classe intermédiaire de type controleur que j'ai nommé "gestion des parties" et qui est en quelque sorte un intermédiaire entre les deux, comme tu me le préconisais.

Mais dans la mesure ou certains utilisateurs ont certains droits et d'autres en ont des différents. Utiliser le meme controle serait pas adéquate.
J'en ai crééer deux :
- Controleur de partie Responsable (il presente les methodes qu'a le droit d'utiliser l'host; ex : Exclure un utilisateur de sa table).
- Controleur de partie Invité (représente les methodes spécifiques à un invité).

J'ai fait hériter les deux classes controleurs d'une classe abstraite présentant des méthodes communes (ex : jouer un pion, voir le profil de son adversaire ect...) et enfin dans mon diagramme de classe j'ai dit qu'une classe partie était composé d'un controleur de partie Responsable et d'un controleur de partie Invité.

Tu penses que cela est correcte ?