Discussion :

[Neckara]

Bonjour,

J'ai un peu de mal à identifier clairement les concepts et à leurs attribuer une responsabilité unique.

Actuellement j'ai codé rapidement une unique classe "Salon" mais j'essaye de la réécrire correctement en respectant le principe de la "responsabilité unique".

J'ai essayé de suivre les conseils d'un membre du forum et d'écrire ce que j'attendais de mon "bout de code"/"module".

J'ai ensuite souligné ce qui me paraissait important, ce qui me paraissait être des "concepts".
J'ai ensuite tenté de décrire rapidement les concepts principaux en mettant en gras des noms de classes qui je pense créer.

Et j'ai finalement fait un rapide diagramme de classe, j'aimerais donc savoir ce que vous en pensiez.

[Matthieu Vergne]

Déjà choisit si tu nommes en français ou en anglais dans tes diagrammes. Ca sert à rien d'avoir les deux, surtout que certaines de tes traductions sont fausses {'^_^} : "description carte" = "map description" et non "description map" (carte de description). Si tu comptes nommer tes classes en anglais, tu peux te faire un index dans la version textuelle où tu fais correspondre les termes français aux termes anglais (ou marquer entre parenthèse quand tu introduis le terme la première fois).

Si la version textuelle est juste un brouillon pour poser tes idées et le modèle est ta référence propre, alors tu peux avoir un modèle différent du texte (a priori mieux) et le raffiner encore par la suite. Si tu veux que ta référence soit le texte et que le modèle t'aide à en identifier les problèmes, là il faut être le plus fidèle que possible au texte et voir où le modèle pose problème au fur et à mesure de sa construction, de façon à identifier les parties du texte à revoir. C'est cette seconde approche que j'ai pris. Donc pour ma part, je traduis chaque phrase en interprétant le moins que possible et à partir de là j'en tire le modèle. C'est donc une modélisation "bête et méchante" de ce qui est écrit.

Mon modèle (qui ne représente que les 2 premiers paragraphes, tout simplement parce qu'aller plus loin n'aurait pas été une sage décision) est attaché à ce post et en voici les commentaires (tirés au fur et à mesure de la construction du modèle). Ces commentaires sont sur les 3 premiers paragraphes (le 3e étant donc celui qui m'a empêché d'aller plus loin dans la modélisation) : (les notations comme visiteur.afficher déroulement(j:jeu) font référence au modèle joint)

• "jouer à la carte indiquée par le maître de salon." -> il me semble normal de l'interpréter comme "un salon n'a qu'une seule carte à la fois" mais ce n'est pas écrit explicitement, donc je considère le cas le plus ouvert et donc le joueur peut jouer une carte spécifique dans le salon : le salon peut en avoir plusieurs, mais le maître de salon n'en autorise le jeu que sur une à la fois, et donc il faut demander la bonne.
• visiteur.afficher déroulement(j:jeu) -> le concept de jeu n'est pas souligné dans ton texte, donc j'imagine que tu ne le considère pas comme un concept important à ce niveau là, mais sans ça on ne sait pas qu'est-ce qu'on affiche. Comme c'est utilisé uniquement dans écran de jeu, j'imagine que tu parles du salon : est-ce qu'on affiche le salon ? Auquel cas est-ce que ça devrait être visiteur.afficher déroulement(s:salon) ? Quelle est alors la différence entre accéder au salon et afficher son déroulement ? Tu dis aussi "Pour rentrer dans un salon" -> accéder ? afficher ? rentrer ? Le français moyen aime bien montrer son vocabulaire (c'est ce qu'on nous apprends à l'école après tout), mais quand tu écris un CdC (cahier des charges), n'en fais pas un roman : réutilise les termes que tu as choisit, sinon ça peut porter à confusion.
• maître de salon.interdire accès... -> est-ce qu'on interdit l'accès de certains visiteurs ou on interdis globalement l'accès à tout visiteur ? La formulation textuelle est ambigüe. En lisant la suite il me semble que tu parles d'interdiction globale (j'ai donc pris cette approche dans mon modèle), mais ce n'est pas écrit explicitement et donc peut être modélisé de différentes façons.
• la différence entre modérateur et visiteur est confuse ("les modérateurs pourront accéder à un salon qui interdit les visiteurs en tant que visiteurs.") : si on définit un visiteur comme "quelqu'un qui ne peux qu'afficher le salon à condition que le salon l'autorise", on ne peut pas appeler un modérateur (qui peut passer outre cette autorisation) un visiteur. Je pense que tu mélanges 2 concepts : "quelqu'un qui ne peux qu'afficher le salon à condition que le salon l'autorise" (le visiteur) et "quelqu'un qui ne peux qu'afficher le salon". Le premier -visiteur- est un cas particulier du second, et le modérateur est un autre cas particulier du second, ce n'est donc pas un visiteur. Autrement il faut réassigner tes termes aux bonnes définitions.
• "un mot de passe pourra être demandé" -> là, la formulation montre que le besoin n'est pas clairement identifié (on pourrait le dire sur d'autres phrases qui précèdent, mais c'est là que ça me semble le plus évident). Soit il faut un mot de passe, soit il n'en faut pas, soit il faut choisir selon un critère donné. Là tu sembles être sur le dernier cas mais tu ne donnes pas le critère qui définit si on doit utiliser un mot de passe ou non. Avec une telle formulation, on peut le modéliser de plusieurs manières : une seule fonction qui considère un mot de passe qui peut être null ou une fonction avec et une autre sans mot de passe par exemple. Le premier cas est moins expressif (le fait de ne pas avoir besoin de mot de passe n'apparaît plus clairement), et donc de l'information est perdue, c'est donc à éviter. Mais ce sera le choix typique d'un développeur qui cherche à réduire son code (ce qui est une très bonne habitude, mais mal utilisée ici). Le second cas est plus fidèle au texte, mais quand on en arrive à identifier l'utilité de ces fonctions, on se doute bien qu'il faudra choisir entre les deux, et là tu laisses le choix du critère de sélection au développeur. Pour ma part... je demanderai de clarifier, mais si je ne peux pas le faire je ferais une fonction salon.utilise mot de passe() qui me dit si oui ou non il faut un mot de passe pour ledit salon, et utiliser la fonction en conséquence. Cela dit, c'est parce que je suis conscient que l'accès se fait sur le salon, et donc le salon est, pour moi, le plus à même d'avoir cette information. Maintenant on pourrait imaginer des choses plus complexes, comme déléguer cette fonction au maître de salon (après tout ce n'est pas le salon qui définit lui-même son mot de passe ni même s'il en a besoin d'un) ou à une autre entité qui gère les droits d'accès. Je me contente de ce qui me semble le plus logique avec ce que j'ai lu, mais du reste, on ne sait pas ce qui se passe dans la tête d'un autre dév.
• Dans la même veine "le mot de passe pourra être différent selon si on tente de rejoindre le salon en tant que visiteur ou en tant que joueur." -> encore une autre ambigüité qui peut être modélisée de diverses manières. Même remarque que le point précédent : si choix il y a, critère il faut donner. Tout doit être contrôlé (c'est un programme que tu fais, pas une équipe de personne à qui on délègue des tâches, le programme ne fait pas de choix tout seul).

En ce qui concerne ce qui est part de mon interprétation et ce qui n'est que simple déduction du texte, j'ai essayé de réduire le premier au minimum et d'expliciter le peu qu'il contient dans mes remarques ci-dessus (on pourrait débattre de ce qu'est une interprétation mais c'est pas le sujet, je m'appuie sur un minimum de sens commun). Maintenant c'est sûr qu'il y a au moins le fait que, quand une opération est décrite (e.g. "Un salon est un écran de jeu ou les joueurs peuvent choisir leurs équipes"), elle est assignée à un des acteurs et les autres sont placés en argument (e.g. joueur.choisir équipe(s:salon, e:équipe)). Le choix de l'acteur qui détient la fonction est aussi une part de mon interprétation, on pourrait donc les assigner autrement (e.g. salon.assigner équipe(j:joueur, e:équipe) ou équipe.enregistrer joueur(j:joueur, s:salon)).

Pour ton modèle, ce que je vois c'est que bien que tu identifies des concepts importants dans ton texte (salon, écran de jeu, joueur, équipe) tous n'apparaissent pas dans ton modèle (e.g. écran de jeu) ou apparaissent de manière subtile (e.g. on n'a pas de joueur, mais on a des personnes qui sont données à des fonctions qui les interprètent comme étant des joueurs). Bref, tu me sembles prendre cette approche (typique pour un étudiant dévelopeur) : CdC -> idée partielle du programme -> modèle du programme (et non du CdC). Il y a des détails qui ne trompent pas : pourquoi une politique devrait être un entier ? Pourquoi une équipe devrait avoir un identifiant ? Pourquoi un proxy ? Pourquoi un GUI ? Une meilleure approche me semble être : CdC -> modèle du CdC -> programme qui correspond au modèle, cela permet d'éviter d'intégrer dès le départ des choix d'implémentation arbitraires dont on n'a aucune idée si ce sont les bons. Le fait d'être le plus fidèle que possible au texte quand tu fais ton modèle permet de s'assurer de faire la seconde approche.

Dans ton CdC, tu as une partie pure texte (1), puis une autre ou tu commences à assigner des noms de classe et des propriétés à tes concepts (2), après quoi tu as ton modèle de classes (3). Le simple fait de faire (2) fait que tu prend déjà une approche "description de classes", donc autant le réduire à (3). Notamment, ta description de "joueur" dans (2) correspond exactement à ce qui est écrit dans (3) en version graphique. Pourquoi ne pas te contenter de (3) ? Tu pourrais me dire "parce que je n'ai pas de classe joueur et donc il faut que je dise qu'est-ce qui correspond à quoi", mais alors dans ce cas pourquoi ne pas avoir de classe "joueur" ? Après tout, dans (2) tu défini un joueur comme une classe EmplacementDeJoueur, rien d'autre (cette classe dispose de différentes choses, mais tu ne définis pas un joueur comme un ensemble ou une interaction entre classes, seulement cette classe). Et donc là je ne vois pas de raison d'appeler cette classe autrement que Joueur. De plus, que veut dire un emplacement qui est prêt ? Prêt à être occupé ? C'est pas le joueur à cet emplacement qui est prêt à jouer ? Un emplacement ne joue pas jusqu'à preuve du contraire. Bref, tu as fait (2) mais ça te donne juste plus de possibilité de rajouter de la variance qui rend le tout confus. Plutôt que de faire un mapping (2) dont on ne sait pas d'où ça vient, préfère utiliser directement ce que tu définis dans (1) pour le modéliser dans (3). C'est aussi comme ça que tu peux voir que ton (1) doit être raffiné.

Dans ton modèle, il y a encore des choses qui n'apparaissent pas comme la délégation du titre de maître de salon. On a juste une fonction pour assigner une personne à un salon. Du coup, de mon point de vue, ton modèle ne tient pas compte du texte. C'est plus une autre tentative de CdC en passant par un diagramme de classe, à la suite de quoi le mapping à la fin de ton CdC permet de faire le lien entre la version texte et la version graphique. Donc 2 CdC qui disent deux choses différentes sur le même sujet.

[Neckara]

Merci pour vos indications.

Si je comprend, bien, il faut que je sois le plus précis possible, sans laisser la moindre ambiguïté dans le CdC.

Pour le Joueur que je désigne par EmplacementDeJoueur, j'ai pensé que comme une Personne peut jouer plusieurs "joueur", le joueur était en fait défini par sa "place" dans le salon (équipe + n° dans l'équipe) donc par l'(es)emplacement(s) où la Personne se positionnera.

Pour votre diagramme de classe, je ne pense pas qu'on puisse créer une classe Maître de salon, en effet, le Maître de salon est un rôle qui peut être transféré d'un Joueur (maître de salon) à un autre Joueur.
Or si on a une classe Maître de salon, on perd cette notion de "transfert" du rôle.

[Matthieu Vergne]

Si je comprend, bien, il faut que je sois le plus précis possible, sans laisser la moindre ambiguïté dans le CdC.

C'est ça. Pas forcément donner tous les détails, mais ne pas laisser de choix implicite. Le CdC est censé donner les contraintes de haut niveau, par exemple il n'a pas pour vocation de donner les détails d'implémentation. Quand tu en arrives à parler d'implémentation dans le CdC, ça se limite a priori à un ensemble de technologies autorisées du fait d'un environnement de production déjà en place par exemple. Il y a donc un point à partir duquel tu es obligé de laisser le choix, mais ça doit être au niveau ou tu laisses explicitement le choix à ceux qui prennent la suite (e.g. les développeurs). Si un dév te pose une question sérieuse sur ton cahier des charges, tu dois pouvoir lui répondre grosso-modo une de ces réponses :
- c'est écrit là noir sur blanc
- à toi de voir au mieux

Pour le Joueur que je désigne par EmplacementDeJoueur, j'ai pensé que comme une Personne peut jouer plusieurs "joueur", le joueur était en fait défini par sa "place" dans le salon (équipe + n° dans l'équipe) donc par l'(es)emplacement(s) où la Personne se positionnera.

Là on en arrive à des détails ontologiques, mais il est important de bien clarifier tes concepts. Ton choix peut-être pertinent, le tout étant que l'ensemble s'accorde. Mais du point de vue du CdC, les concepts et leur définition doivent être le plus clair que possible.

Par exemple, un passager du point de vue de la SNCF ou d'AirBus, ce n'est pas une personne, c'est une personne qui prend un train/vol à un temps donné. Plusieurs passagers peuvent donc correspondre à la même personne (si tu fais un aller-retour direct Marseille-Paris, tu équivaut à 2 passagers, un pour chaque trajet). Il faut savoir de quoi on parle, il n'y a pas de mieux, il faut "juste" s'accorder sur les concepts et les utiliser à bon escient (c'est généralement parmi les tâches les plus difficiles {'^_^}).

Pour votre diagramme de classe, je ne pense pas qu'on puisse créer une classe Maître de salon, en effet, le Maître de salon est un rôle qui peut être transféré d'un Joueur (maître de salon) à un autre Joueur.
Or si on a une classe Maître de salon, on perd cette notion de "transfert" du rôle.

Sûr ? Comme je l'ai dit ce diagramme se contente de traduire les 2 premiers paragraphes. Et là tu ne parles que d'une entité "Maître de salon". Ce n'est que quand tu parles effectivement de "transférer le titre" que là on fait la différence entre la personne et le titre. Mais je pourrais tout aussi bien avoir une classe "maitre de salon" qui identifie le titre en question et auquel j'assigne un salon et une personne, comme ce que tu fais avec l'emplacement de joueur si j'ai bien compris. A ce moment ce serait un classe qui identifie une relation entre un salon et son maître.

Une autre solution serait que chaque salon dispose d'une instance "badge de maître de salon" qui lui est propre (et donc ne disparaît pas quand le maître de salon change, contrairement à une simple relation qui disparaît au profit d'une autre), et une personne ayant le badge d'un salon donné est donc le maître de ce salon. Donc à partir du salon, tu peux obtenir cette seule instance qui est liée au salon, et une personne pourrait avoir les badges de plusieurs salons. On aurait donc des choses comme :

badge maître de salon
salon.obtenir badge maître de salon()
personne.assigner badge maître de salon(b:badge maître de salon)

Tu as plein de façons de modéliser une même situation, le tout étant de savoir ce que tu veux mettre en avant. Mais ça ce n'est qu'au fur et à mesure de ton analyse que tu le découvres.

NB : Il y a d'ailleurs des débats sur ce processus d'identification des besoins, modélisation incluse. Est-ce qu'on se contente vraiment d'expliciter et de reformuler les besoins des utilisateurs, où est-ce que c'est une part intégrante de leur découverte (donc à la base ces besoins sont inconnus et se "créent" au fur et à mesure qu'on les analyse) ? Moi je suis plutôt sur la seconde approche (les détails se discutent cela dit).

[Neckara]

J'ai essayé de réécrire le CdC en utilisant des phrases assez courtes.
Est-ce que c'est "mieux" ? Est-ce qu'il y a encore beaucoup d'ambiguïté ?

[Matthieu Vergne]

Le mieux c'est que ce soit toi qui le détermine {^_^}. Essaye de modéliser ce qui est écrit en restant le plus proche possible du texte (traduction bête et méchante du texte en version graphique). Si tu vois que quelque chose n'est pas bon au niveau du modèle (tu te poses des questions sur comment le modéliser ou le modèle que tu crées te semble inadapté) c'est qu'il te faut reformuler le texte. Certes tu es biaisé parce que tu as déjà ton idée en tête, mais la c'est une question de rigueur : est-ce que tu est capable de faire ton modèle en suivant "bêtement" le texte ? Si tu arrives à switcher entre "modéliser bêtement" et "reformuler le texte intelligemment" alors tu devrais pouvoir combler la plupart des brèches de ton CdC. C'est une question de pratique après.

Et oui ça demande du temps, le tout étant de savoir si tu le prends ou pas ce temps {^_^}.

Edit: En soit, le modèle et le CdC n'ont pas de raison d'être différents. Ce sont deux approches différentes pour exprimer la même chose. Faire les deux et chercher à les aligner est donc un bon moyen de vérifier que l'autre formulation est bien faite.

Edit 2: Le piège classique de cette approche est d'avoir une idée de comment on veut modéliser une chose et de formuler le texte pour pouvoir le modéliser de cette manière. Essaye de ne pas tomber dedans : le texte ne doit pas dépendre du modèle, seulement des besoins que tu as identifié.

[Neckara]

Le mieux c'est que ce soit toi qui le détermine {^_^}.

Ben voilà, déjà qu'on ne peut pas faire faire son travail par d'autres sur le forum maintenant faut répondre à nos propre questions

J'ai refait un diagramme (cf pièce-jointe).

Par contre, pour l'implémentation, je pense qu'il serait bien de fusionner Player et Place. Mettre la relation Salon-DescriptionMap plutôt que Salon-Map.
Mais je pense que ça ne pose pas trop de problèmes ?

Ainsi que d'avoir une seule instance pour stocker tous les emplacements d'un salon.

[Matthieu Vergne]

Ba écoute, donne un poisson à un homme et il aura à manger pour la journée. Donne-lui une canne à pêche et il aura à manger pour la vie. De la même manière je préfère te donner les moyens d'y répondre toi-même plutôt que la réponse. Un forum n'est pas là pour te donner des réponses, mais t'aider à les obtenir. Donner directement la réponse est un moyen de le faire, mais ce n'est pas mon approche.

De plus, tant que je serai le seul à répondre, tu n'auras pas de quoi croiser les avis, et je n'ai pas envie que tu sois biaisé par ma propre vision des choses. Si quelqu'un d'autre pouvait participer ça serait mieux, on aurait de quoi comparer.

[Matthieu Vergne]

je pense qu'il serait bien de fusionner Player et Place.

Si tu n'as pas de raison de le faire, ne le fais pas. Si tu sais que conceptuellement ça correspond à deux choses différentes, laisse-les séparés. Tu ne sais pas si dans le futur tu n'auras pas besoin de cette séparation pour implémenter des choses spécifiques. Si dans ton CdC tu peux tout reformuler en faisant cette fusion, alors ça a du sens de le faire, sinon non.

Mettre la relation Salon-DescriptionMap plutôt que Salon-Map.

Pareil, si dans ton CdC tu parles de Map pour parler en fait de MapDescription alors oui, sinon non.

Ainsi que d'avoir une seule instance pour stocker tous les emplacements d'un salon.

Tu parles de Place ? Dans ce cas tu ne parles plus du même concept : tu parles d'un ensemble de places et non d'une place. Typiquement PlaceSet (non ordonné) ou PlaceList (ordonné). Revois ton CdC en conséquence et si ça passe c'est bon.

[Neckara]

Ba écoute, donne un poisson à un homme et il aura à manger pour la journée. Donne-lui une canne à pêche et il aura à manger pour la vie. De la même manière je préfère te donner les moyens d'y répondre toi-même plutôt que la réponse. Un forum n'est pas là pour te donner des réponses, mais t'aider à les obtenir. Donner directement la réponse est un moyen de le faire, mais ce n'est pas mon approche.

C'était une petite phrase d'humour

Si tu n'as pas de raison de le faire, ne le fais pas. Si tu sais que conceptuellement ça correspond à deux choses différentes, laisse-les séparés. Tu ne sais pas si dans le futur tu n'auras pas besoin de cette séparation pour implémenter des choses spécifiques. Si dans ton CdC tu peux tout reformuler en faisant cette fusion, alors ça a du sens de le faire, sinon non.

Je pense que c'est le modèle qui n'est pas tout à fait juste. Je pense que Player est une classe de la relation (faudrait que je retrouve le terme exact) entre Personn et Place or comme une Place ne pourra avoir que de 0 à 1 relation avec une Personn dans l'implémentation on peut décider de mettre le Player dans la Place ?
Sinon, peut-être qu'en renommant Player et Place, ce serait plus simple pour comprendre l'idée, je vais continuer à chercher.

EDIT : Je pense à une classe du type "place à jouer", "jeton pour jouer" pour fusionner la classe Place et la classe Player qui n'a pas grande utilité.

Pareil, si dans ton CdC tu parles de Map pour parler en fait de MapDescription alors oui, sinon non.

Disons que dans le langage français, on dira plutôt qu'on choisit une Map mais en fait on fait ce choix qu'en fonction de la MapDescription.

Tu parles de Place ? Dans ce cas tu ne parles plus du même concept : tu parles d'un ensemble de places et non d'une place. Typiquement PlaceSet (non ordonné) ou PlaceList (ordonné). Revois ton CdC en conséquence et si ça passe c'est bon.

Dans le CdC, on a pas vraiment besoin d'une PlaceSet/PlaceList mais dans l'implémentation, cela me parait indispensable.
Je vais creuser.

EDIT : Le problème, c'est que je suis obligé de penser à l'implémentation pour ce cas là car si je ne crée pas une classe pour "gérer" les accès aux places, je vais soit me retrouver avec une classe ayant sa responsabilité d'origine ainsi que la responsabilité de "gérer les accès aux places".

[Matthieu Vergne]

C'était une petite phrase d'humour

L'émoticône était pas assez explicite {^_^}.

Dans le CdC, on a pas vraiment besoin d'une PlaceSet/PlaceList mais dans l'implémentation, cela me parait indispensable.
Je vais creuser.

EDIT : Le problème, c'est que je suis obligé de penser à l'implémentation pour ce cas là car si je ne crée pas une classe pour "gérer" les accès aux places, je vais soit me retrouver avec une classe ayant sa responsabilité d'origine ainsi que la responsabilité de "gérer les accès aux places".

Tu n'est pas obligé. Tu as juste du mal à abstraire. Ça vient avec l'expérience, donc c'est pas quelque chose qu'on peut te reprocher directement. Tu viens juste de le dire : "si je ne crée pas une classe pour "gérer" les accès aux places, ..." mais cela traduit uniquement le fait que tu ais besoin de gérer les places (appliquer une politique de gestion) et non que le concept même de place est inutile. Après tu fais probablement tout de suite le même raisonnement qu'avec Player et Place : tu ne vois pas la différence au niveau fonctionnel et du coup tu te dis qu'un seul est suffisant. Résultat des courses : autant remplacer l'un par l'autre.

Quand tu passes du CdC à l'implémentation, tu as évidemment besoin de rajouter des choses vu que tu vas plus loin dans les détails, mais de là à modifier l'existant... si vraiment tu en as besoin, ça traduit que ton CdC n'est pas bon. Le CdC doit te donner l'ensemble des concepts (et leurs relations) pour un niveau donné. L'implémentation peut rajouter des choses mais à un niveau en dessous. C'est un peu comme un framework MVC (modèle-vue-contrôleur) si tu connais : le modèle et la vue ne s'occupent pas de la même chose (et ne sont donc pas censés s'influencer l'un l'autre) alors que les même données s'appliquent aux deux. Le CdC et l'implémentation pareil : tu as des points communs, mais chacun a sa propre responsabilité. S'ils se marchent dessus c'est qu'il y en a un qui ne s'occupe pas de ses propres affaires.

L'implémentation peut effectivement aider à identifier de nouveaux concepts qu'on devrait retrouver dans le CdC (pas tous, mais certains peuvent être nécessaires), mais ce n'est pas au niveau de l'implémentation que ces concepts doivent prendre leur sens. C'est au niveau du CdC. Si au niveau du CdC le concept n'a pas lieu d'être (il ne te permet pas de définir ou préciser tes besoins) alors c'est un détail d'implémentation, et il n'a pas l'autorité pour redéfinir un concept donné par le CdC. Si tu dois retoucher un concept du CdC, ça doit se faire au sein du CdC, et l'implémentation doit suivre.

[Neckara]

Mais le problème c'est qu'en français, on peut dire ou voir les choses de manières différentes ce qui permet d'avoir un modèle différent.

Par exemple, je pense dire que :

Une personne peut choisir d'incarner des joueurs

.
Ainsi le concept de place devient alors :
- place = joueur ;
- place libre = joueur non-incarné ;
- place prise = joueur incarné ;
- place fermée = joueur qu'il est possible de rajouter ;
- changer de place = échanger sa "place" (équipe + n° dans l'équipe) avec un autre joueur ;

Or cette nouvelle vision va très sûrement simplifier l'implémentation.

Pour la "gestion des places", je ne l'ai pas mis dans le diagramme de classe mais un salon possédera plusieurs "places". De là dans l'implémentation, je peux décider de créer une classe PlaceManager qui me servira d'ensemble pour les "places" et je pourrais lui donner la responsabilité de créer/détruire les "places", d'autoriser une personne à incarner la "place" ainsi que de compter le nombre de "prêt" ?

[Matthieu Vergne]

Mais le problème c'est qu'en français, on peut dire ou voir les choses de manières différentes ce qui permet d'avoir un modèle différent.

Pas seulement en français. C'est pareil dans toutes les langues naturelles, justement parce qu'elles autorisent l'ambigüité. Les langages formels n'ont pas ce "problème", et un diagramme de classe est un de ces langages formels (en dehors des noms des labels où tu mets ce que tu veux, mais le diagramme n'en dépend pas). C'est pour ça que le fait de traduire ton CdC en diagramme de classe te force à déceler et corriger les ambigüités, et en ce sens c'est ce qui rend utile le fait de faire les deux en même temps.

Par exemple, je pense dire que : Une personne peut choisir d'incarner des joueurs.

Ainsi le concept de place devient alors :
- place = joueur ;
- place libre = joueur non-incarné ;
- place prise = joueur incarné ;
- place fermée = joueur qu'il est possible de rajouter ;
- changer de place = échanger sa "place" (équipe + n° dans l'équipe) avec un autre joueur ;

Or cette nouvelle vision va très sûrement simplifier l'implémentation.

Certes le langage a sa propre influence, mais quand tu écris un CdC c'est à toi à fournir les définitions. Et à les fournir clairement. Si tu commences à utiliser des mots hésotériques ce n'est plus un CdC, c'est de la littérature {'^_^}. En ce sens le terme "incarner" ne me plait pas beaucoup. Cela dit, ce que tu décris ensuite et pour moi la base de ton CdC : définir tes concepts. Ensuite il te faut les utiliser pour en définir les relations.

Avec ton exemple on peut voir une certaine cohérence :

joueur
- incarné VS non-incarné

place
- libre VS prise

Là tu as un mapping cohérent entre les concepts. Cela permet effectivement de choisir d'utiliser soit l'un soit l'autre, inutile d'avoir les deux. Maintenant, si tu arrives à raffiner ces définitions pour ne pas avoir :

concept = concept

mais

concept = définition simple, claire et précise utilisant des termes de sens commun ET qui ne sont pas trop proches du domaine que tu tentes de représenter avec ledit concept (pour éviter toute confusion).

Là tu pourras avoir quelque chose de robuste. Par exemple, le terme "joueur" est un concept familier dans le domaine que tu considères, donc tenter de représenter "place" en utilisant ce terme est dangereux (pour la compréhension de ta définition) car on peut se poser la question "pourquoi tu définis place et pas joueur ?". Si tu as par exemple :
- place = emplacement qu'une seule personne à la fois peut occuper.
- place libre = emplacement non occupé.
- place prise = place qui n'est pas libre.

Tous les termes utilisés dans les 2 premières définitions sont hors du domaine qui t'intéresses. Donc tu peux te fier à un sens commun qui ne marche pas sur tes plates bandes. La dernière définition utilise exprès les termes définis précédemment pour mettre en avant leurs relations. Le côté complémentaire entre place libre et place prise devient donc évident (peu importe la définition de place libre, une place prise est son complémentaire). Cette dernière définition permet donc de savoir que si place se spécialise en place libre, alors:
- place se spécialise aussi en place prise
- ces deux spécialisations sont disjointes et suffisantes pour représenter tous les cas de place (donc place ne se spécialise pas en autre chose sans avoir des chevauchements avec les concepts déjà définis).

Pour la "gestion des places", je ne l'ai pas mis dans le diagramme de classe mais un salon possédera plusieurs "places". De là dans l'implémentation, je peux décider de créer une classe PlaceManager qui me servira d'ensemble pour les "places" et je pourrais lui donner la responsabilité de créer/détruire les "places", d'autoriser une personne à incarner la "place" ainsi que de compter le nombre de "prêt" ?

Choix pertinent. Mais si tu définis des relations dans ton diagramme (et donc avant tout dans le CdC) entre salon et place, ces relations doivent apparaitre dans ton code. Elles peuvent apparaitre au moyen de nouvelles classes ou en plus de nouvelles classes, mais elles ne peuvent pas être absentes (sinon tu ne respecte pas ton CdC).

Par exemple, dans ton diagramme tu peux mettre une relation 1-N de salon vers place, et dans ton code ça peut se traduire par :
- un ensemble de N membres (variables de classe) qui représentent chacune des places
- un tableau de places de taille N
- un manageur de place qui contient une propriété tailleMax qui vaut N (et qui peut être configurable ou constant)

Le fait de choisir le manageur est un choix d'implémentation qui n'influe pas sur ton CdC/modèle. C'est les contraintes posées par ton CdC/modèle qui te permettent d'utiliser un manageur (choix d'implémentation compatible avec le CdC).

[Neckara]

Merci pour ta réponse.

J'aurais bien aimé avoir l'avis de Koala01 mais je ne sais pas s'il visite bien ce forum

Je pense que je commencerais l'implémentation d'ici peu et je le posterais partie C++ pour voir si vous le pensez "propre" et "respectueux des bon principes de programmation". Comme cela si j'arrive à faire au moins un bout de code "correct", je pourrais le refaire pour d'autre code tout seul.

[Matthieu Vergne]

Demande-lui directement de passer, ça sera plus efficace (par MP ou au pire sur un sujet qu'il suit).

[koala01]

Salut,

Il parrait qu'on me demande, alors, bah, pour une fois je viens un peu trainer mes basques par ici

Je vais lire attentivement le document que tu présentes, et je viendrai en faire le commentaire par la suite, mais, d'ici là, tu peux dores et déjà te dire que je soutiens totalement Matthieu dans ses explications

Mais pour ne pas te laisser sur ta faim, ce qu'il faut comprendre, c'est que les concepts (de manière générale) sont un peu comme les briques des légos : tu en as de différentes formes et de différentes couleurs, et tu peux les assembler "à ta guise" pour obtenir quelque chose de plus complexe que tu pourras utiliser par la suite.

Généralement, on va partir d'un idée ("tiens, ce serait pas mal si on avait une application qui... ") pour définir un "méga concept super complexe".

Le role de l'analyse fonctionnelle et technique est alors de trouver l'ensemble des concepts qui permettent de rendre ce méga concept possible, et de "détacher" toutes les briques de base qui le composent.

Pour ce faire, on peut partir de la définition qu'on donne à ce méga concept :
C'est le fait de (... ).

Evidemment, cette définition a de fortes chances d'introduire d'autres concepts, qu'il s'agira alors de préciser.

En ne me basant que sur la discussion (oui oui, j'ai pris la peine de la lire intégralement ), et sans avoir encore lu le document, j'ai envie de dire qu'il s'agit au minimum de préciser:

• qu'est ce qu'un salon,
• qu'est ce qu'un maitre de salon
• qu'est ce qu'une place,
• qu'est ce qu'un modérateur
• qu'est ce qu'un joueur,
• qu'est ce qu'une personne
• j'en ai peut etre oublié

parce que je présumes que, dans l'analyse, on a de fortes chances d'avoir trouvé les concepts "maitre de salon", "place" et de "joueur" dans la définition du concept du concept "salon", et que les notion de "personne" et de "modérateur" sont sans doute très clairement apparues lorsqu'il a été question d'exprimer la manière dont le salon s'organisait.

Parce que, donner une définition claire aux différents concepts est, forcément, très important, mais il faut aussi jouer le jeu du "qui fait quoi" et du "comment ca fonctionne"

Et comme tu as de grandes chances d'introduire de nouveaux concepts à chaque étape (définition, qui fait quoi, comment ca fonctionne), il faut juste que tu veilles à jouer le jeu de ces trois étapes pour chaque nouveau concept introduit.

Finalement, un concept est souvent très proche d'un gros oignon : chaque fois que tu en retires une couche, tu en découvres une nouvelle (et tu as les yeux qui pleurent ). Le but est, simplement, d'arriver à atteindre le coeur

Allez, je m'arrête là et je lis ton document d'analyse..

I'll be back

[koala01]

Bon, après une première lecture en diagonale, je ne résiste pas à l'envie de livrer mes premières impressions :

Un document se doit d'être un minimum structuré si on veut que les gens sachent de quoi l'on parle.

Par exemple, tu arrives directement avec la définition d'un salon, alors que l'on ne sait même pas quel est le but de l'application que tu veux créer.

Une petite introduction indiquant ce que tu peux faire représente une attention sympa pour le lecteur, ne serait-ce que pour lui indiquer le contexte général

Par exemple, je viens de me lancer dans un nouveau projet et les premières lignes de l'analyse sont

Attac, encore un autre compilateur (Another Try To get A Compiler)

J'ai lancé pour me permettre de mettre en pratique des notions d'ingénieurie logicielle que je n'avais, jusqu'à présent, pu abroder que de manière trop théorique, à savoir tout ce qui a trait à l'analyse lexicale et syntaxique du code et, de manière générale, la "machinerie interne" qui permet au compilateur de fournir un exécutable.

Je regrettais jusqu'à présent de n'avoir pas eu l'occasion d'améliorer mes connaissances sur ces deux aspect.

Les pages qui suivent reprendront à l'ensemble des réflexions, des recherches et des essais menés pour arriver à créer un "compilateur de compilateur".

Au moins, celui qui lira cela sait que je ne suis pas occupé à écrire un livre de recettes de cuisine

Ensuite, j'ai l'impression que tu pars un peu trop dans tous les sens, sans savoir exactement ce que tu veux dire!

Tu commences par une définition ce qui est très bien : un tableau est un salon de jeu.

Mais, après, tu pars dans des explications qui nous parlent de personnes qui peuvent entrer ou sortir, de joueur et de visiteurs de maitre de salon et de déléguer son role dans un désordre tel que l'on a vraiment du mal à se faire une idée globale de la situation

Commences peut être par définir (au sens de "définition digne d'un dictionnaire") ce qu'est un tableau de jeu.

Par exemple

Un tableau de jeu est un espace créé par un maitre de jeu auquel des joueurs peuvent s'inscrire afin de participer à une partie de (une partie de quoi en sommes, on ne sait meme pas à quoi on joue )

Aaah, là, on peut commencer à réfléchir

Mais il faut le faire avec méthode! On rencontre en effet deux grandes catégories de concepts : des noms (groupes nominaux) et des verbes (groupes verbaux).

Les noms (groupes nominaux) correspondent à des concepts qui devront sans doute être représentés sous la forme de types clairement définis, les verbes (groupes verbaux) correspondent à des concepts que je vais qualifier de "comportementaux".

Commençons donc donc par définir les concepts "de types" mis en avant par cette simple définition et refaisons le travail. Le but est de répondre aux questions:

• qu'est ce qu'un maitre de jeu
• qu'est ce qu'un joueur
• qu'est ce qu'une partie de...
• qu'est ce que le jeu de ...

Je le répète, je veux juste savoir pour l'instant ce que c'est que tout ce beau monde, avoir la définition (digne du dictionnaire encore une fois ) que tu donnes de ces différents concepts . Tu peux citer les concepts comportementaux, mais il n'est pas question de commencer à les expliquer. Ca, ce sera pour plus tard

Chacune de ces définitions étant susceptible d'introduire de nouveaux concepts, il faudra bien sur veiller donner une définition de ceux ci

Ne t'inquiète pas trop d'avoir d'éventuelles références croisées (une case d'échiquier par exemple a de fortes chances de faire référence au concept d'échiquier qui fera référence au concept de case d'échiquier), cela arrive régulièrement et te donne d'ailleurs souvent une idée de certaines relations qui existent entre tes différents concepts

Ce ne sera que lorsque tu auras atteint "le coeur de l'oignon" que tu pourras commencer à t'intéresser au concepts comportementaux, de préférence dans une section spécifique de ton document.

Et c'est à ce moment là que tu exprimeras clairement ce que cela signifie de s'inscrire à un tableau de jeu, quelles sont les éventuelles contraintes à respecter, etc

N'oublions pas, étant donné que l'on a parlé d'un jeu, que tu auras surement introduit quelque part la notion de "règles du jeu".

Ces règles méritent amplement de se retrouver dans une section spécifique de ton document, car on peut imaginer que de nombreuses règles sont "inter dépendantes"

Une fois que tu as fait (dans un premier temps du moins) le tour de tout cela, il est souvent intéressant d'écrire une dernière section dans lequel tu prévois les éventuelles évolutions qui pourront être apportées dans les versions suivantes.

Le fait de prévoir une évolution à ce niveau ne veut pas forcément dire qu'elle sera mise en oeuvre, cela veut juste dire que, peut-être, si tu as le temps, si le projet arrive jusque là, et si les gens le demande, bah, peut etre que tu vas envisager de rajouter telle ou telle fonctionnalité

Cette section est, à mon sens, la plus importante du document (en sachant que c'est peut être celle qui évoluera le plus vite, car tu n'est jamais à l'abri d'une idée d'évolution future supplémentaire ), parce qu'elle te permet, de manière générale, de savoir où il est peut être intéressant de prévoir un "point de variation" afin d'éviter de devoir tout casser lorsque tu voudras implémenter cette évolution (si tant est que tu décides de le faire, évidemment )

Au final, tu devrais pouvoir avoir un document qui aura une structure plus ou moins proche de

• Présentation du projet
• les concepts "de types"
  
  • les concepts généraux en tete
  • les concepts intermédiaires
  • les concepts très spécialisés
• les concepts "comportementaux"
  
  • les concepts généraux en tete
  • les concepts intermédiaires
  • les concepts très spécialisés
• les règles
  
  • les règles générales
  • les règles particulières
  • les exceptions aux exceptions
• D'autres considérations plus ou moins transversales
  
  • les relations entre tout ce beau monde
  • les responsabilités de chacun
  • ...
• les évolutions futures

Une fois que tu as cela, tu as déjà pour ainsi dire "toutes les informations" qui seront nécessaires pour créer la plupart des diagrammes UML que tu pourras souhaiter :

• La première partie servira pour les CdC
• La deuxième pourra très certainement être utile pour créer les diagrammes de transition, de séquence, d'activité et autres,
• j'en passe et de meilleures

Evidemment, lorsque tu commenceras à créer tes diagrammes, il se peut très bien que tu te dise "tiens, j'ai fait la distinction entre deux concepts alors que je n'aurais pas du" ou (plus souvent encore) "tiens, il me manque un concept pour la relation entre telle et telle classe".

Il sera sans doute alors très intéressant de reprendre ton document pour y faire figurer les différences, et ce en essayant toujours d'exprimer clairement (et dans l'ordre) les nouveaux besoins qui sont apparus

Et, une fois que tes diagrammes seront faits, il faudra quand même finir par écrire le code

Et, encore une fois, il est tout à fait possible que tu te rendes compte que la manière dont les choses ont été modélisées pose problème (parce qu'il "manque quelque chose" ou parce que le langage pose une restriction importante, ou ... va savoir quoi...)

Tu repasseras donc sans doute par la case "analyse des besoins" pour mettre ton document à jour, puis par la case "formalisation" pour traduire ces nouveaux besoins, avant de revenir à la case "pissage de code"

PS: autrement dit, inspires toi très fort de la deuxième ligne de ma signature, ca aide énormément

[Neckara]

Merci pour ta réponse.
J'essayerais de refaire une autre version du CdC mais cela ne semble vraiment pas facile

Après, je pense qu'il vaut mieux pour le moment que je ne fasse que CdC -> diagramme de classe -> implémentation + documentation.
En effet, je pense que ce n'est pas réaliste de passer trop de temps à multiplier les diagrammes UML pour un module aussi "simple".

Au pire il faudra soit que je délègue/sous-traite à partir du CdC et du diagramme de classe mais si j'arrive déjà à faire un CdC, il me sera beaucoup plus facile de déléguer le travail (ce qui m'a beaucoup fait défaut pendant deux années ).

[Matthieu Vergne]

J'essayerais de refaire une autre version du CdC mais cela ne semble vraiment pas facile

Lol {^_^}. Certains sont formés pour ça et c'est leur job. Moi c'est mon domaine de recherche (je suis doctorant en ingénierie des exigences, donc étude des besoins et tout ce qui va avec). Si ça avait été facile je me serait senti bien con {^o^}.

Cela dit, c'est comme tout. Ça devient difficile quand on cherche à bien faire (condition nécessaire mais pas suffisante cela dit). Si ce n'est pas difficile, c'est qu'on reste superficiel dans ce qu'on fait. Et le fait que ce soit difficile maintenant te permet au moins de te dire que la prochaine fois ça le sera moins. Mieux vaut que ce soit le plus dur sur un projet perso que quand tu dois le faire pour quelqu'un d'autre.

Et petit topo des phrases phares dans mon domaine de recherche :
- si le taux d'échec des projets est aussi important, c'est parce qu'on manque encore de méthodes adaptées pour identifier les besoins.
- de gros problèmes durant le projet peuvent venir de petites erreurs lors de l'étude des besoins.

En bref, on n'a jamais trop analysé les besoins. Tout ce que tu peux identifier au plus tôt, c'est ce sur quoi tu n'auras pas besoin de faire marche arrière avec des modifications couteuses.

Après, je pense qu'il vaut mieux pour le moment que je ne fasse que CdC -> diagramme de classe -> implémentation + documentation.
En effet, je pense que ce n'est pas réaliste de passer trop de temps à multiplier les diagrammes UML pour un module aussi "simple".

La simplicité/complexité du système vient de la simplicité/complexité des besoins. Si tu te mets à penser que parce que tu aimerais un système simple l'analyse doit être tout aussi simple, tu marche à l'envers (le modèle dépend du CdC, pas l'inverse). Si l'ensemble de tes besoins son simples, et si tu les formules correctement, le système sera simple. Cela dit, rares sont les systèmes simples {'^_^}. Même pour un cas d'école ça peut vite devenir complexe. Tu sauras si c'est simple ou non quand tu auras terminé ton projet, pas avant.

Au pire il faudra soit que je délègue/sous-traite à partir du CdC et du diagramme de classe mais si j'arrive déjà à faire un CdC, il me sera beaucoup plus facile de déléguer le travail (ce qui m'a beaucoup fait défaut pendant deux années ).

C'est sûr, ça aide énormément. Cela dit, si tu travailles en équipe il faut y mettre d'autant plus d'effort, car ceux à qui tu délègues n'ont pas ton idée en tête, et donc les confusions arrivent très vite (surtout s'ils en sont pas expérimentés dans le domaine considéré). Le CdC doit donc être d'autant plus robuste.

C'est bien d'ailleurs que Koala01 soit passé sur la structure du document. Moi je me suis contenté de voir le côté "fait-main" en me réduisant aux principes des base, mais un document bien structuré est impératif si tu travailles en groupe. Ça fait une bonne continuité dans l'explication {^_^}.

[koala01]

Il ne faut pas oublier non plus que la complexité d'un projet est à peu près proportionnelle au nombre de ligne de code, mais qu'elle est exponentielle au nombre d'intervenants, parce que, plus tu auras d'intervenant, plus tu risques une mauvaise compréhension, une vision différente des choses ou un mauvais passage de l'information (le coup du téléphone sans fil, tu connais )

Mais, de manière générale, le simple fait de structurer ton document t'obligera à structurer ton "système de pensée" (du genre : "oui, je pense à telle chose, mais je suis pas sur ce problème pour l'instant, je le marque sur un bout de serviette et j'y reviens plus tard" ), et ce n'est qu'en structurant correctement ton système de pensée que tu arriveras à avoir la garantie d'avoir (plus ou moins) pensé à tout. Quitte à, comme je te le dis, marquer les points auxquels tu penses sur une feuille et à les cocher à chaque fois qu'ils sont exprimés

@Matthieu, personnellement, bien que n'ayant pas été formé à cela à la base, j'ai toujours eu "le chic" pour "sentir" ce qu'il y avait derrière certaines demandes.

Mais c'est peut etre simplement l'habitude d'écouter et de décrypter les appels au secours que j'ai gardée de quand j'étais ambulancier