Discussion :

[Matthieu Vergne]

Pour ma part j'ai bien reçu une formation, mais comparé à ce que je sais aujourd'hui, je peux dire que je n'ai pas été formé que ça ne serait pas tout à fait faux {'^_^}. C'est plus ce que j'ai appris par moi-même en faisant de la recherche que je synthétise maintenant. La structure du doc oui, je pourrais te sortir ce que j'ai appris (enfin faudrait que je ressorte mes "cours"... hum) mais comment construire un CdC bien ficelé... quand on en était à te vanter la toute puissance du cycle en V... {'^_^}

J'ai eu un cours sur les méthodes agiles, bien plus informatif, cela dit. Pas de cahier des charges mais des idées qui ont surement mieux prit. Mais de toute façon, l'étude des besoins, au jour d'aujourd'hui, ça dépend beaucoup de l'expertise de l'analyste encore (plutôt que de parler de feeling). Et je ne doute pas que ton boulot d'ambulancier ait été particulièrement formateur {^_^}.

[Neckara]

J'ai commencé à faire une petite "présentation".

LD::Salon est une des bibliothèques de Last Dungeon. Le but de cette bibliothèque est de fournir un salon de jeu générique.
Un salon de jeu est un lieu qui permet lors de jeux multijoueurs de monter une ou plusieurs équipes ainsi que de choisir une «*carte*» à laquelle les équipes pourront jouer toutes ensemble ainsi que de spécifier diverses options relatives à cette carte.
Les «*cartes*» sont le plus souvent des espaces dont les décors ainsi que la présence et disposition de certains éléments (ex. objets à récupérer/détruire/protéger/éviter) changent d'une carte à l'autre. Dans les cartes s'applique souvent des règles communes à toutes mais certaines cartes peuvent se distinguer grâce à des options ou des règles différentes (par exemple, régler la difficultés de certaines IA, autoriser ou non certaines actions, …).

J'essayerais de faire le reste demain.

[Matthieu Vergne]

Attention aux phrases à rallonge :

Un salon de jeu est un lieu qui permet lors de jeux multijoueurs de monter une ou plusieurs équipes ainsi que de choisir une «*carte*» à laquelle les équipes pourront jouer toutes ensemble ainsi que de spécifier diverses options relatives à cette carte.

Un salon de jeu est un lieu qui permet lors de jeux multijoueurs de monter une ou plusieurs équipes ainsi que de choisir une «*carte*» à laquelle les équipes pourront jouer toutes ensemble ainsi que de spécifier diverses options relatives à cette carte.

(séparation des différentes parties)

Un salon de jeu est un lieu qui permet lors de jeux multijoueurs de monter une ou plusieurs équipes.
Un salon permet de choisir une «*carte*» à laquelle les équipes pourront jouer toutes ensemble.
Un salon permet de spécifier diverses options relatives à cette carte.

(on fusionne et réduit les deux dernière qui parlent toutes deux de la relation salon-carte, la dernière phrase pouvant se résumer avec un terme commun comme "configurer" ou "paramétrer")

Un salon de jeu est un lieu qui permet lors de jeux multijoueurs de monter une ou plusieurs équipes.
Un salon permet de choisir et configurer une «*carte*» à laquelle les équipes pourront jouer toutes ensemble.

(la carte me semblant plus importante, j'inverse le sens)

Un salon permet de choisir et configurer une «*carte*» à laquelle les équipes pourront jouer toutes ensemble.
Un salon de jeu est un lieu qui permet lors de jeux multijoueurs de monter une ou plusieurs équipes.

(l'information importante dans la seconde phrase est qu'on peut avoir une ou plusieurs équipes, le fait que le salon permette de monter les équipes est peu clair : un salon ne fait rien par lui-même + on n'a pas besoin d'outils pour monter une équipe en général -> si ça a un sens particulier il doit être définit dans le CdC et utilisé dans le CdC, mais comme introduction -qui vise à introduire et donc doit rester le moins technique que possible- ça alourdit la phrase inutilement)

Un salon permet de choisir et configurer une «*carte*» à laquelle une ou plusieurs équipes pourront jouer toutes ensemble.

(comme on parle d'une unique carte, "toutes ensemble" me semble évident)

Un salon permet de choisir et configurer une «*carte*» à laquelle une ou plusieurs équipes pourront jouer.

(c'est pas mieux comme ça ? {^_^})

NB : évite d'utiliser les citations si ce n'est pas pour citer un post précédent, parce que quand on te cite (bouton "citer") le contenu que tu as mis en citation disparait. Donc au final on n'a rien à citer {'^_^}.

[Neckara]

J'ai essayé de faire le reste mais vous le verrez, c'est assez

[koala01]

Tu as peut etre pris mon intervention un peu trop "à la lettre"...

Quand je présentais la forme que ton document finirait sans doute par prendre, je ne voulais pas forcément que tu précises les différentes sections en tant que telles, je voulais surtout donner "un ordre d'idée" de l'ordre dans lequel on retrouverait les différents concepts
[EDIT]En fait, les trois parties incontournables seront la description du projet, l'analyse en elle-même et les évolutions probables.

En respectant plus ou moins ce qui suit, tu en arriveras "fatalement" a organiser ta section "analyse" en respectant à peu près l'ordre que j'avais donné
[/EDIT]
Par contre, c'est bien, tu commences tout doucement à "rentrer dans le bain" et à comprendre l'idée.

Il y a cependant encore quelques détails :

La présentation, c'est celle du projet : son nom (l'explication du nom choisi ), pourquoi tu lances le ce projet, au lieu d'utiliser "ce qui existe", etc.

Vu que tu parles de Last Dungeon, tu pourrais sans doute expliquer ce que c'est (en quelque mots), puis faire un "état des lieux" de l'existant en disant ce que tu "reproches" à l'existant.

La notion de Last Dungeon étant totalement "extérieure au projet", il ne faut pas en faire un roman : tu pourrais te contenter d'expliquer que c'est un jeu, d'en donner le type ( (MMO)RPG, stratégie, ou autre), et toute information que tu pourrais juger "utile et pertinente" dans le cadre de ton projet.

Comprends par là qu'on s'en fout de savoir la trame exacte du jeu (de savoir si ce sont des orques, des elfes et des nains qui jouent ou est-ce des extra-terrestres plus immondes les uns que les autres), un lien vers le site (s'il y en a un) peut amplement suffire, du moment que l'on sait de quel type de jeu on parle

En gros, le but de la présentation a pour objectif de répondre à deux grandes questions:

• C'est quoi
• Pourquoi (ce projet ci et pas un autre, qui est peut etre déjà utilisé par des milliers de gens)

Le deuxième paragraphe (ainsi que les suivants) de ta présentation expose(nt) déjà un premier concept, ce qui fait que ta présentation s'arrête normalement à "<snip> est de fournir un salon de jeu générique.)

Ce que j'aime faire, mais ce n'est pas du tout une obligation, c'est de commencer par créer le "Who's who" du projet : dresser la liste des différents concepts, en en donnant une description (un définition digne du dictionnaire).

Je crois que le meilleur moyen d'y arriver est de partir du concept qui aura été mis en avant dans la description, vu que, comme il s'agit du résultat à obtenir, il y a de grandes chances que ce soit, en tous cas, un concept "central" de ton projet.

En effet, tu as introduit la notion de "salon de jeu" dans la description.

Il y donc de fortes chances pour que tout s'articule d'une manière ou d'une autre autour de cette notion

Sa description correspond à quelque chose comme (je cite ton document):"

Un salon de jeu est un lieu qui permet lors de <rajout: sessions de ?>jeux multijoueurs de monter une ou plusieurs équipes."

Il fait apparaitre trois nouveaux concepts : celui de (session de) jeu, celui de "montage" d'équipe et celui d'équipe.

Je subodore cependant que sa description devrait sans doute ressembler à quelque chose comme

Un salon de jeu est un lieu qui permet lors de sessions de jeu multijoueurs de mettre en présence une ou plusieurs équipes pour leur permettre d'évoluer sur une carte spécifique.

Le terme "mettre en présence" me semble plus adapté que monter dans le sens où

• il est plus précis
• il indique clairement que les équipes doivent être là, quelque soit la manière dont elles se sont formées
• Le terme "monter" dans le sens où tu l'emploies ici fait plus penser à l'assemblage de différentes pièces d'un objet/ d'un ustensile qu'à la formation d'une équipe (avis perso )

De même, je préfère la notion de "session de jeu", non seulement parce qu'elle est plus précise (elle implique clairement qu'il y a un début et une fin ! ) mais parce que le jeu en lui-même c'est Last Dungeon, et qu'ici on parle des gens qui y jouent
Cette description introduit trois nouvelles notions "de type":

• la notion de "session de jeu"
• la notion "d'équipe"
• la notion de "carte"

et deux notions "comportementales"

• la notion de "mise en présence"
• la notion d'évolution sur la carte"

La notion de "session de jeu" a ici son importance parce que c'est une notion qui fera le lien avec l'extérieur de ton projet, mais je vais en parler un peu plus tard.

On écrit donc sur un morceau de serviette : "définir session de jeu, mise en présence et évolutions sur la carte", histoire d'éviter d'oublier d'en parler.

Il nous reste donc deux notions à définir : la notion d'équipe et la notion de carte
La notion d'équipe pourrait se définir comme suit (on te l'as déjà dit: essaye d'être complet tout en restant succinct dans tes descriptions )

L'équipe est un ensemble de joueurs qui s'allient à l'occasion d'une session de jeu (tiens donc ) afin d'atteindre un but commun

Une petite question au passage: Fait on une distinction entre le joueur (la personne "physique" qui est derrière son clavier) et son avatar (le personnage qu'il incarne dans le jeu) ou pas

Je ne connais pas la réponse à cette question, mais elle risque de prendre toute son importance lorsque tu voudras gérer les accès aux différents salon:
Si ce sont les avatars qui sont pris en compte, une personne disposant de plusieurs avatars peut, potentiellement, se retrouver dans plusieurs salons (un par avatar dont il dispose), voir, en "plusieurs exemplaires" (de nouveau un par avatar) dans un même salon, alors que si l'on prend le joueur en compte, il ne pourra, à un instant donné, se trouver que dans un seul salon, quel que soit le nombre d'avatar qu'il aura créé.

Je ne m'intéresse pas vraiment à la réponse ici, car mon but est de t'aider à te poser les bonnes questions au bon moment, en te donnant les outils qui te permettront de trouver la bonne réponse.

Mais il faut savoir que la manière dont tu vas envisager les choses (surtout au niveau de l'implémentation) dépendra énormément de la réponse à cette question que tu te sera déjà surement posée depuis belles lurettes

Ici, je vais parler du joueur (de la personne physique), mais n'oublies pas, si tu décides de répondre "l'avatar" à cette question, qu'il faudra adapter ton analyse en conséquence (à commencer par noter le fait qu'un avatar est le personnage qui représente un joueur "physique" qui se trouve "quelque par dans le monde").

Cette notion représente de nouveau un concept permettant à ton projet de communiquer avec l'extérieur.

Rajoutons donc sur le bout de serviette "introduire la notion de joueur (d'avatar, selon le cas)"

Puis nous nous intéressons à la carte :

La carte est un(e partie du ) monde dans lequel les joueurs peuvent se déplacer et interagir avec certains éléments du décors ou avec d'autres joueurs.

Chaque élément d'une carte est identifiable par la position qu'il occupe

tu l'auras remarqué, il y a de nouveau trois nouveaux concepts :

• l'interaction
• les éléments du décors
• la position.

L'interaction, c'est du "comportemental", on va donc attendre un peu d'en parler et on écrit donc sur notre bout de serviette (qui commence à être bien rempli) "expliquer le concept d'interaction".

Le concept d'éléments de décors pourrait se définir comme

Un élément de décors est n'importe quel élément susceptible d’apparaitre sur la carte qui ne soit pas un joueur.

Cela regroupe :

• différents types d'obstacles (ex : mur, différence de niveau, rivière, bancs, ...)
• des "personnage non joueurs" (PNJ)
• des éléments susceptibles d'offrir un bonus au joueur qui les manipule

Quant à la position, elle pourrait se définir comme

La position représente la coordonnée dans notre référentiel (2D / 3D, biffer la mention inutile ) permettant de localiser les différents éléments les uns par rapport aux autres sur la carte afin de les afficher ou de permettre une interaction de la part du joueur se trouvant à leur portée

Généralement, quand tu en viens à parler d'un référentiel, d'un identifiant ou, de manière générale, de notions qui ne représente que des données brutes (comprends : tout à fait susceptibles d'être représentées par un type primitifi, une structure C style, une énumération, une union, un typedef ou une chaine de caractères), tu peux te dire que tu es arrivé à un concept de base: le genre de concept que tu utiliseras sans doute "à toutes les sauces" et que tu pourras le plus souvent représenter sous la forme d'un type que tu pourrais très bien considérer comme "primitif" (dans le sens où il ne sert à rien d'essayer de le subdiviser d'avantage) dans le cadre de ton projet.

Je ne vais pas continuer sur ma lancée, je crois que tu devrais arriver à comprendre le principe de base qui est de fournir en quelques phrases simples et explicite une explication qui ne laisse aucun doute quant à l'idée que l'on peut se faire des différents concepts

Tu remarqueras que j'ai introduit la notion d'obstacle, il t'appartient de savoir si certains sont franchissables ou non.

Selon le cas, il t'appartiendra de faire la distinction entre les obstacles franchissables et les obstacles infranchissables, voire -- qui sait -- faire la distinction entre les obstacles franchissables par destruction (un tronc que l'on détruit à coup d'épée, ou un bloc de je ne sais quoi pouvant être détruit par un sort particulier par exemple) et les obstacles franchissable par (escalade, saut, ...).

Pour les obstacles infranchissables, il s'agit d'obstacles qui obligent le joueur à faire un détour .

Enfin, l'idée est de descendre " de proche en proche" dans la complexité des différentes notions que tu introduis, jusqu'à ce que tu te rendes compte que toutes les notions introduites se suffisent à elles-même (ex la coordonnée dont j'ai parlé plus haut) ou font référence à des notions qui ont été expliquées (parfois de manière plus ou moins circulaire )

Quand tu as atteint ce stade, il est temps de reprendre ta serviette et de voir les notions qui manquent, et là, tu te rendras compte qu'il manque les notions de joueur et de session de jeu, par exemple.

Si j'ai attendu jusqu'à maintenant pour en parler, c'est parce que ces deux notions (mais d'autres sont sans doute dans le cas) ont une particularité intéressante : elles interviennent dans un système que l'on pourrait qualifier de "communication avec l'extérieur" de ton projet.

En effet, ton projet se base sur un jeu existant et tend à venir se "greffer" dans le jeu.

Il y a donc, de toute évidence un "système" (méfie toi de ce terme -- ou de tout terme similaire -- car c'est souvent l'indice qu'il y a énormément d'intérêt à le préciser ) à mettre en place de manière à permettre la communication entre le jeu et ton projet (et ce, sans doute dans les deux sens ).

Ce système prendra, très certainement des notions comme celle de joueur et session de jeu en charge, mais ce ne seront très certainement pas les seules : il y a de fortes chances que c'est au travers du jeu que tu auras la possibilité de récupérer certaines ressources dont tu as besoin ( comme les éléments d'inventaire que les joueurs peuvent ramasser, certains PNJ type, ou que sais-je).

Tu l'auras compris, il semble particulièrement important de savoir ce que tu peux envoyer comme information au jeu et celles que tu peux recevoir de sa part pour éviter un grand nombre de problème comme une ressource impossible à afficher ou à traduire parce qu'inconnue du jeu lui-même )

Et, bien sur, il ne faut pas oublier toutes les notions "comportementales" que l'on a pu introduire et qu'il s'agit d'expliquer

Mon avis personnel (mais bon, il n'engage que moi ) est qu'il est sans doute préférable de s'intéresser en priorité au notions comportementales avant de s'intéresser au "système de communication avec l'extérieur", et ce, pour une raison bien simple: l'analyse des notions comportementales peut très bien avoir pour résultat de rajouter des notions dans le système de comm.

Cela nous évitera donc d'avoir à "revenir" sur ce "système plus ou moins indépendant"

La première notion comportementale que j'ai mise en avant est celle qui consiste à "mettre en présence une ou plusieurs équipe(s)", tu te souviens

Cette notion est tout à la fois primordiale et particulièrement imprécise.

Elle est primordiale parce que c'est d'elle que découleront (peut être indirectement ) de nombreuses notions qui ne seront pas apparues jusqu'à présent.

C'est en effet de cette notion (ou de notions indirectement liées à la mise en présence d'équipe) qu'apparaitront le besoin d'imposer certaines règle de "bienséance" sur le salon, et donc la nécessité de disposer d'un "Maître de salon" et de "modérateur(s)" afin de faire respecter ces règles

C'est sans doute de manière indirecte par cette notion qu'apparaitra la distinction entre les joueurs d'une part et les visiteurs de l'autre.

Une deuxième question au passage : le maitre de salon et/ou un modérateur doit-il être considéré comme un joueur ou comme une personne extérieure à ce qui se passe sur la carte

On ne peut exclure le risque d'arbitraire si le maitre de salon et / ou les modérateurs sont parties prenantes sur ce qui se passe sur la carte: ils y a des chances pour qu'il décident d'(ab)user de leur pouvoir pour exclure une équipe ou un joueur qui s'avérerait être trop fort, afin de privilégier leur propre équipe

Toi seul peux donner la réponse à cette question, mais elle influera également très fort sur la suite du programme

Il est sans doute bon de préciser dans ton analyse que tu as réfléchi à ce problème et d'indiquer clairement la réponse (éventuellement en la justifiant )

Une fois que ton "Who's who" est complet, tu peux t'intéresser à l'étape suivante qui est le "Qui fait quoi".


Tu connais l'importance que j'apporte au respect stricte de l'acronyme SOLID et en particulier (pour ce qui nous intéresse ici du moins) au respect du principe de la responsabilité unique.

Dans cette étape, on va s'intéresser à la responsabilité que vont prendre les différents concepts mis en avant dans le who's who.

Le fait de définir clairement "qui est responsable de quoi" te facilitera énormément la tâche par la suite, car l'étape d'après consiste à se poser la question de "quels services suis-je en droit d'attendre de la part de tel ou tel concept ".

Evidemment, tu te retrouveras très certainement avec des responsabilités complexes comme "gérer le salon de jeu" ou "gérer les équipes" et d'autres beaucoup moins complexes comme permettre à un joueur de s'inscrire dans une équipe".

Je t'ai mis en garde contre le terme "système de", je te mets maintenant en garde contre le terme "gérer" (et autres termes similaires) : la gestion en elle-même peut prendre de nombreuses forme comme la création, le maintient en mémoire, la recherche ou la décision de détruire des éléments.

Les notions qui contiennent ce genre de terme méritent amplement d'être précisées

Bien sur, il n'est pas impossible que tu te retrouves avec des notions "collatérales" lorsque tu en viendra à expliquer les notions comportementales, les responsabilités de chacun et / ou les services que tu estimes être en droit d'attendre de la part d'une notion particulière.

Tu devras évidemment penser à les inscrire sur ton bout de serviette pour être sur de ne pas oublier d'en parler par la suite

NOTA:
- Lorsque tu en arriveras aux notions collatérale (très certainement, mais peut être aussi à d'autres niveaux ), il y en aura très certainement qui seront primordiales (comprends: sans lesquelles ton projet ne fonctionnera pas) et d'autres qui rentre assez facilement dans la catégorie du "ce serait pas mal si...".

- N'hésites pas à faire preuve d'imagination dans ta liste d'évolutions probables / potentielles (tu remarqueras que je n'utilises pas le terme d'évolution futures ) : Chaque fois que tu penses à quelque chose qui n'est pas forcément indispensable, tu peux vraiment te sentir totalement libre de rajouter un paragraphe du genre de "Nous pouvons envisager de..." ou de "Il serait peut etre intéressant de...".

C'est pour cela que j'utilise le terme d'évolutions probables ou d'évolutions potentielles : il s'agit d'évolutions que " nous pourrions peut-être, si l'on a le temps, si le succès est au rendez-vous, si les joueurs le demandent et si l'on trouve le moyen de s'y prendre, d'ajouter telle ou telle fonctionnalité".

On se contente de présenter une solution que l'on reste libre d'utiliser ou non, dont on peut décider "à n'importe quel moment" que c'est le moment de s'y réfléchir, alors que, lorsque l'on parle d'évolutions futures, on indique très clairement que ce ne sera peut être pas implémenté dans première version, mais que cela devra, quoi qu'il en soit, être implémenté dans la version suivante.

En un mot comme en cent, cela nous permet d'ouvrir des portes sans nous forcer à aller voir d'office ce qu'il y a derrière

Je vais m'en tenir là pour ce soir.

J'espère t'avoir donné quelques pistes intéressantes et que tu arriveras à les exploiter

[Neckara]

Même après plusieurs lectures, mon cerveau me fait toujours aussi mal
Huit pages, tu n'as donc aucune pitié

Je vais reprendre tout cela petit à petit.

Il y a cependant encore quelques détails :

La présentation, c'est celle du projet : son nom (l'explication du nom choisi ), pourquoi tu lances le ce projet, au lieu d'utiliser "ce qui existe", etc.

Vu que tu parles de Last Dungeon, tu pourrais sans doute expliquer ce que c'est (en quelque mots), puis faire un "état des lieux" de l'existant en disant ce que tu "reproches" à l'existant.

En gros, le but de la présentation a pour objectif de répondre à deux grandes questions:

• C'est quoi
• Pourquoi (ce projet ci et pas un autre, qui est peut etre déjà utilisé par des milliers de gens)

Fait.

Le deuxième paragraphe (ainsi que les suivants) de ta présentation expose(nt) déjà un premier concept, ce qui fait que ta présentation s'arrête normalement à "<snip> est de fournir un salon de jeu générique.)

Ce que j'aime faire, mais ce n'est pas du tout une obligation, c'est de commencer par créer le "Who's who" du projet : dresser la liste des différents concepts, en en donnant une description (un définition digne du dictionnaire).

En gros, mettre en avant les concepts lors de la descriptions plutôt que décrire LD::Salon sans se soucier des concepts ?
Et ensuite dresser la liste des concepts après la description ?

Le terme "mettre en présence" me semble plus adapté que monter dans le sens où

• il est plus précis
• il indique clairement que les équipes doivent être là, quelque soit la manière dont elles se sont formées
• Le terme "monter" dans le sens où tu l'emploies ici fait plus penser à l'assemblage de différentes pièces d'un objet/ d'un ustensile qu'à la formation d'une équipe (avis perso )

De même, je préfère la notion de "session de jeu", non seulement parce qu'elle est plus précise (elle implique clairement qu'il y a un début et une fin ! )

Par contre trouver le "terme le plus juste" n'est pas vraiment facile, tu as des conseils pour trouver le "bon mot" ou c'est plus une question d'expérience ?

Une petite question au passage: Fait on une distinction entre le joueur (la personne "physique" qui est derrière son clavier) et son avatar (le personnage qu'il incarne dans le jeu) ou pas

Il faut donc répondre à cette question dans la description plutôt que lors de l'explication des différents concepts ?

Généralement, quand tu en viens à parler d'un référentiel, d'un identifiant ou, de manière générale, de notions qui ne représente que des données brutes (comprends : tout à fait susceptibles d'être représentées par un type primitifi, une structure C style, une énumération, une union, un typedef ou une chaine de caractères), tu peux te dire que tu es arrivé à un concept de base: le genre de concept que tu utiliseras sans doute "à toutes les sauces" et que tu pourras le plus souvent représenter sous la forme d'un type que tu pourrais très bien considérer comme "primitif" (dans le sens où il ne sert à rien d'essayer de le subdiviser d'avantage) dans le cadre de ton projet.

Donc si je comprend bien, il faut aller de notion en notion et continuer à creuser tant qu'on n'atteint pas une "notion primaire" ?

Tu remarqueras que j'ai introduit la notion d'obstacle, il t'appartient de savoir si certains sont franchissables ou non.

Ce n'est pas au salon de s'occuper de cela. Le salon est un salon "générique", le reste, ce n'est pas son travail.

Si j'ai attendu jusqu'à maintenant pour en parler, c'est parce que ces deux notions (mais d'autres sont sans doute dans le cas) ont une particularité intéressante : elles interviennent dans un système que l'on pourrait qualifier de "communication avec l'extérieur" de ton projet.

Je vois, donc il faut parler des concepts qui s'interfaceront avec l'extérieur en dernier lieu.

Il y a donc, de toute évidence un "système" (méfie toi de ce terme -- ou de tout terme similaire -- car c'est souvent l'indice qu'il y a énormément d'intérêt à le préciser ) à mettre en place de manière à permettre la communication entre le jeu et ton projet (et ce, sans doute dans les deux sens ).

N'est-ce pas plutôt une question d'implémentation?
Le salon est générique or si je commence à réfléchir à une interface entre mon jeu et le salon, je me place dans un cas particulier non?
Ne vaut-il pas mieux ne se soucier que des données qui seront utiles au salon et laisser le jeu prendre le soin de se débrouiller pour le reste ?

Tu l'auras compris, il semble particulièrement important de savoir ce que tu peux envoyer comme information au jeu et celles que tu peux recevoir de sa part pour éviter un grand nombre de problème comme une ressource impossible à afficher ou à traduire parce qu'inconnue du jeu lui-même )

Ce n'est pas le rôle du salon.

Une deuxième question au passage : le maitre de salon et/ou un modérateur doit-il être considéré comme un joueur ou comme une personne extérieure à ce qui se passe sur la carte

On ne peut exclure le risque d'arbitraire si le maitre de salon et / ou les modérateurs sont parties prenantes sur ce qui se passe sur la carte: ils y a des chances pour qu'il décident d'(ab)user de leur pouvoir pour exclure une équipe ou un joueur qui s'avérerait être trop fort, afin de privilégier leur propre équipe

Le maître de salon ne devrait normalement pas pouvoir abuser de son pouvoir (sauf à la sélection des équipes mais si les joueurs n'aiment pas le maître de salon, ils peuvent aller monter leur propre salon ailleurs). Pour le modérateur, il est censé être "digne de confiance" et je ne vois pas pourquoi on l'empêcherait de jouer contre d'autre modérateurs par exemple.

Dans le CdC, je n'ai jamais dit qu'ils ne pouvaient pas être des joueurs.

Il est sans doute bon de préciser dans ton analyse que tu as réfléchi à ce problème et d'indiquer clairement la réponse (éventuellement en la justifiant )

Il faut vraiment dire autant de choses ?

Dans cette étape, on va s'intéresser à la responsabilité que vont prendre les différents concepts mis en avant dans le who's who.

Le fait de définir clairement "qui est responsable de quoi" te facilitera énormément la tâche par la suite, car l'étape d'après consiste à se poser la question de "quels services suis-je en droit d'attendre de la part de tel ou tel concept ".

Mais les responsabilités n'ont-elle pas déjà été mises en avant avec les définition ?


Merci pour tes réponses mais je crains que tu ne m'aie un peu perdu, c'est un peu trop pour moi
Est-ce que tu n'aurais pas un exemple d'un court CdC que je visualise un peu la "forme finale" ?

Le bon côté des choses c'est qu'après le diagramme de classe et l'implémentation sera triviale comparé au CdC

[Matthieu Vergne]

Par contre trouver le "terme le plus juste" n'est pas vraiment facile, tu as des conseils pour trouver le "bon mot" ou c'est plus une question d'expérience ?

Il y a évidemment une question d'expérience. À force d'utiliser les mots avec différentes personnes, tu finis par identifier quel vocabulaire colle mieux à quel contexte. C'est indéniable. Cela dit, même si ça se construit au fur et à mesure, il y a tout de même quelques outils/indices que tu peux exploiter :
- Quand tu utilises un terme, c'est pour représenter quelque chose de précis : commence par identifier un ou plusieurs termes que tu connais qui semblent représenter ce dont tu veux parler puis cherche leurs synonymes. Tu peux utiliser un dictionnaire en ligne (e.g. synonymes.com) qui te permet, quand tu as un mot, d'avoir la liste de ses synonymes et de pouvoir cliquer sur chaque mot pour voir les synonymes de ce mot, et ainsi de suite. Cela te permet de raffiner au fur et à mesure tes concepts. Tu n'as qu'à lister ceux qui te semblent pertinent puis chercher les définitions de chacun d'entre eux pour choisir le bon.
- Prendre un terme qui "fait bien" est un bon moyen de prendre un terme qui porte à confusion. Si tu as un terme "cool", demande-toi si c'est le plus adapté en cherchant toutes les définitions qui lui correspondent (petit tour sur Wiktionnaire et Wikipédia pour bien comprendre le terme).
- Chaque communauté a son vocabulaire propre. Si tu établis un projet qui cible un domaine particulier, tâche de réutiliser au maximum le vocabulaire de ce domaine. Par exemple, tu peux aller sur Wikipédia pour voir une description du domaine en question (version anglaise si tu veux les termes anglais) et voir les autres sujets qui s'y rapportent pour bien savoir quels sont les termes communs utilisés dans le domaine. Par exemple en Go, on parle de pierre et non de pion ou de pièce, il sera donc préférable d'utiliser le premier terme plutôt que les autres. Si tu utilises un terme qui ne se rapporte pas à ton domaine, c'est probablement que tu touches à un autre domaine, qu'il te faut alors identifier et faire le même processus de recherche de termes communs.

Une petite question au passage: Fait on une distinction entre le joueur (la personne "physique" qui est derrière son clavier) et son avatar (le personnage qu'il incarne dans le jeu) ou pas ?

Il faut donc répondre à cette question dans la description plutôt que lors de l'explication des différents concepts ?

Description ? Tu veux dfire introduction ? A priori c'est du détails de conception, donc il n'est pas nécessaire de le faire apparaître dans l'intro à moins que ce ne soit une fonctionnalité importante de ton application. Ce qui doit apparaitre dans ton intro est ce qui permet de savoir en quoi consiste ton projet, grace à des termes simples et des phrases concises. Une fois qu'on a lu l'intro, on doit pouvoir répondre à la question "est-ce que ça m'intéresse d'aller plus loin ?". Si ton intro est mal faite, typiquement la réponse sera du style "je sais pas, j'ai pas tout compris" ou "ça dépend de ce qu'il veut dire par...".

Donc si je comprend bien, il faut aller de notion en notion et continuer à creuser tant qu'on n'atteint pas une "notion primaire" ?

Oui et non. Si tu fais quelque chose à partir de rien, alors oui car tu dois définir l'intégralité des concepts. Mais si tu comptes utiliser des outils externes à ton projet (librairies ou autre programmes), tu n'as pas besoin d'aller dans les détails pour les concepts de ces outils. Par exemple, si tu dépend de Dungeon and Dragon, tu n'as pas besoin d'aller dans les détails des concepts de ce jeu, sauf si tu tentes de les redéfinir dans ton projet (auquel cas tu utilises tes propres concepts et non ceux du jeu original).

Je vois, donc il faut parler des concepts qui s'interfaceront avec l'extérieur en dernier lieu.

Ça dépend de l'approche que tu prends, le tout étant d'être cohérent:
- coeur->surface->extérieur : on part de la base et on construit dessus, généralement on part des concepts les plus simples mais plus techniques aux plus complexes mais haut niveau. C'est bien pour les documents techniques comme le CdC.
- coeur<-surface<-extérieur : approche inverse. C'est bien pour les intros (y compris celle du CdC), tutos et autres descriptions visant à entrer doucement dans le sujet.
- coeur->surface<-extérieur : on parle d'abord de ce qui doit intéragir, puis de l'interface entre les deux. Bien quand tu as deux domaines très différents à interfacer, tu t'assures ainsi que les bases de chaque domaine sont comprises avant d'entrer dans la complexité de l'interface.
- coeur<-surface->extérieur : on parle de l'interface avant de parler de ce qui l'utilise. Bien quand tu développes une interface générique, généralement basée sur de la théorie de haut niveau avec des concepts très abstraits, et que tu passes ensuite à l'application sur des cas concrets -coeur et extérieur bien spécifiques- pour illsutrer son utilisation.

Le salon est générique or si je commence à réfléchir à une interface entre mon jeu et le salon, je me place dans un cas particulier non?
Ne vaut-il pas mieux ne se soucier que des données qui seront utiles au salon et laisser le jeu prendre le soin de se débrouiller pour le reste ?

Tout dépend des besoins et connaissances à ta disposition : si tu veux faire un salon générique, tu dois avant tout savoir à quel point être générique. Si tu ne connais qu'un seul exemple de jeu, tu en seras incapable. Dans ce cas, en pratique, mieux vaut commencer par un projet spécifique à ton jeu et le raffiner quand un nouveau type de jeu doit y être intégré (en généralisant progressivement). Quand tu auras eu suffisamment de cas différents, tu pourras établir une généralisation, refaire une conception et voir si tu peux l'appliquer à ton projet (s'il est suffisamment flexible) ou en refaire un autre. Si tu as déjà suffisamment de connaissances pour établir une généralisation, alors oui tu peux partir directement sur le second projet, mais ta généralisation doit être robuste.

Dans le CdC, je n'ai jamais dit qu'ils ne pouvaient pas être des joueurs.

L'important n'est pas ce que tu n'y met pas, mais ce que tu y met. Si tu ne dis pas le contraire non plus, alors tu laisses le choix implicite, ce qui est une erreur.

Il faut vraiment dire autant de choses ?

Plus ton CdC sera complet, moins tu auras de problèmes sur la suite du projet. L'objectif n'est pas d'avoir une réponse à toutes les questions possibles et imaginables, sinon il n'y aurait pas de fin, mais de pouvoir soit donner une réponse claire et précise, soit dire que ce n'est pas ton problème et de le justifier. Par exemple, parfois tu dis "ce n'est pas le rôle du salon". Si c'est vrai, alors dans ton CdC on doit pouvoir retrouver la raison (claire et précise) qui fait que ce n'est pas son rôle.

Mais les responsabilités n'ont-elle pas déjà été mises en avant avec les définition ?

Dans les définitions tu donnes le sens du terme, éventuellement ses relations avec d'autres termes. Cela dit, ça ne veut pas dire qu'il y aura nécessairement une classe représentant ce terme et, si c'est le cas, que la classe aura la responsabilité de vérifier les propriétés données dans la définition. Cela dit, c'est effectivement un gage de clarté. Mais par exemple, quand tu as des concepts qui se retranchent (e.g. une pierre de go est soit noire soit blanche, comme tu as le joueur noir et le joueur blanc) tu peux décider de centraliser la responsabilité des concepts en commun à une entité spécifique (e.g. un PlayerManager qui désignera quel joueur a quelle couleur, puis la classe Player et la classe Stone qui auront une méthode getColor() qui utilise le PlayerManager pour la déterminer). Tu peux (et ça peut-être préférable) avoir les méthodes correspondantes à tes définitions (e.g. Stone.isBlack() + Stone.isWhite()) mais ce ne seront que des méthodes chapeaux (qui utilisent juste une autre méthode, des raccourcis donc). La responsabilité sera néanmoins déléguée.

Le bon côté des choses c'est qu'après le diagramme de classe et l'implémentation sera triviale comparé au CdC

C'est là tout l'objectif d'un CdC.

[koala01]

En gros, mettre en avant les concepts lors de la descriptions plutôt que décrire LD::Salon sans se soucier des concepts ?

exactement

Et ensuite dresser la liste des concepts après la description ?

Est-ce que ce sera encore nécessaire, vu que tu les auras tous décrits

Par contre trouver le "terme le plus juste" n'est pas vraiment facile, tu as des conseils pour trouver le "bon mot" ou c'est plus une question d'expérience ?

Sur ce coup l'expérience joue quand même énormément

Mais en plus de Nicolas Boileau, que tu connais déjà, on pourrait citer le film Eragon:

Blisinger singifie le feu. C'est le feu. Connait le nom et tu maitrises la chose

Il faut donc répondre à cette question dans la description plutôt que lors de l'explication des différents concepts ?

J'ai posé la question parce que ce n'est pas clair.

Si tu fais la distinction entre le joueur et l'avatar, les deux concepts seront présents dans ton analyse.

Si tu ne fais pas la distinction, tu ne parleras que de joueur.

Une petite note du genre de

NOTA: On ne s'intéresse qu'aux joueurs, à la personne qui se trouve derrière son clavier, et non à l'avatar qui représente le joueur (mais dont un joueur peut avoir plusieurs exemplaires)

si le doute subsiste peut très bien apparaitre au moment de la description

Donc si je comprend bien, il faut aller de notion en notion et continuer à creuser tant qu'on n'atteint pas une "notion primaire" ?

C'est le plus facile pour être sûr de ne rien oublier.

En plus, cela permet d'avoir une vue beaucoup plus précise des relations qui existent entre les différents concepts.

Ne serait-ce que parce que deux concepts pour lesquels il existe une relation importante ont de grandes chances de se retrouver l'un après l'autre dans le document

Ce n'est pas au salon de s'occuper de cela. Le salon est un salon "générique", le reste, ce n'est pas son travail.

Mais il devra fournir la carte. Cette carte, elle vient d'où elle est générée de quelle manière

S'il se "contente" d'un appel "file moi telle carte" au système, je suis très clairement allé trop loin.

Si le maitre de salon peut décider de la forme et des éléments qui sont présents sur la carte, ces concepts doivent très certainement apparaitre, quitte à ce qu'il s'agisse de "proxy" vers des éléments qui existent au niveau de Last Dungeon

Je vois, donc il faut parler des concepts qui s'interfaceront avec l'extérieur en dernier lieu.

Disons que, quel que soit le projet, tu te retrouves souvent avec plusieurs ensembles d'éléments qui "vont bien ensembles", par exemple (de manière non exhaustive):

• l'ensemble des données métiers : les données que tu manipuleras par toi meme et qui ne dépendent que de toi
• le "système" d'entrée / sorties : tout ce qui a trait avec l'interactivité dont tu as besoin
• l'ensemble des éléments qui permettent la communication avec "le système de base" (il faudra bien envoyer des informations directement à Last Dungeon, non
• Peut être un ensemble d'éléments permettant la communication avec une base de donnée, avec un serveur, avec... que sais-je (en fait, ce seraient plusieurs ensembles, tu l'auras surement compris )

Tous ces ensembles pourraient mériter -- étant donné que tu est un C++iste, je vais parler un langage que tu connais -- de se retrouver dans des espaces de noms imbriqués qui leur sont propres.

Tu auras, très clairement, plus facile de t'y retrouver si les concepts qui correspondent à ces différents groupe sont "naturellement" regroupés en fonction des groupes

N'est-ce pas plutôt une question d'implémentation?

Hum... Oui, en partie, mais non en général.

Le terme "système" représente, par définition un ensemble de concpets "qui travaillent bien ensemble".

Par exemple un système "d'entrées / sorties" sera forcément indispensable : il faut que l'utilisateur puisse introduire des commandes d'un coté et obtenir un résultat "visible" (par du texte, un message box ou une réaction quelconque au niveau de ce qu'il voit à l'écran).

On peut très bien se foutre pas mal, dans un premier temps, de savoir si l'utilisateur utilisera la souris ou le clavier pour introduire les différentes commandes, mais, ce dont on est sur, c'est qu'il devra être en mesure d'en introduire!

De la même manière, on se fout pas mal, dans un premier temps, de savoir comment l'application montrera qu'elle a bien compris la commande, mais une chose est sure, c'est qu'il devra y avoir un "élément visuel quelconque" qui permettra à l'utilisateur de savoir que sa commande a été correctement traitée.

Comme tu peux le remarquer, j'ai commencé à parler d'un système et, en grattant un peu, je me suis rendu compte qu'il utilisait un nouveau concept: celui de commande.

Si je devais aller jusqu'au bout, la question suivante serait: quelles sont les commandes possibles:

• pour le maitre de jeu
• pour les modérateurs
• pour les joueurs
• pour les visiteurs

et la question juste après serait "pour quel résultat"

je ne parle pas du résultat "visuel" ici, mais du résultat au niveau des données métier en elles-mêmes

Le salon est générique or si je commence à réfléchir à une interface entre mon jeu et le salon, je me place dans un cas particulier non?

Non, tu te places dans une situation dans laquelle tu es capable de réfléchir aux différents "signaux" qui seront émis ou reçus.

Tu n'as pas à t'inquiéter (dans un premier temps du moins) de la manière dont tel ou tel signal est émis ni de la réaction qu'il faut avoir face à tel ou tel autre signal, tu dois juste être conscient que ton projet devra être en mesure d'envoyer certaines informations (lesquelles ) au système et d'en recevoir d'autres (lesquelles, toujours ) de la part du système

A partir de là, tu en arriveras "fatalement" à la conclusion que tu as besoin "quelque part" d'une fonction void emettre(Signal const &); et "ailleurs" (comprends: pas forcément dans la même classe, mais ca reste à voir) d'une fonction Signal recevoir(Emetteur const &), ainsi qu'une fonction qui te permette de "mettre tes messages en forme" pour transmettre les bonnes informations dans le bon ordre

L'idée est vraiment de créer une interface au sens "java" du terme: quelque chose qui expose un certain nombre de comportements dont on ne sait a priori rien, mais qui permet "au monde extérieur" de communiquer facilement avec "tout ce qui est susceptible de répondre à un signal donné".

Ne vaut-il pas mieux ne se soucier que des données qui seront utiles au salon et laisser le jeu prendre le soin de se débrouiller pour le reste ?

Peut être, même très certainement sans doute.

Mais, pour que cela puisse marcher, il faudra de toutes manières que ton salon soit en mesure de communiquer, d'une manière ou d'une autre.

Autrement, il se retrouvera seul, perdu dans son coin, à attendre des informations (auxquelles il est parfaitement en mesure de réagir exactement comme il le faut ! ) qui ne viendront pas ... parce qu'il est incapable de les demander.

Ce n'est pas le rôle du salon.

Peut être pas du salon en lui-même, mais de tout ce qui tourne autour!

Si ton projet, de manière générale, est incapable de communiquer avec le reste, ton projet dans son ensemble ne servira strictement à rien, parce qu'il ne sera pas utilisable et donc pas utilisé

Il existe très certainement des "protocoles" de discussions, des classes que tu peux utiliser afin de "formater" correctement tes messages, et tout ce que tu veux, mais si ton salon ne s'occupe pas du formatage de ses messages (quitte à utiliser ces classes et ces fonctions qui existent par ailleurs), comment fera-t-il pour communiquer

Le maître de salon ne devrait normalement pas pouvoir abuser de son pouvoir (sauf à la sélection des équipes mais si les joueurs n'aiment pas le maître de salon, ils peuvent aller monter leur propre salon ailleurs). Pour le modérateur, il est censé être "digne de confiance" et je ne vois pas pourquoi on l'empêcherait de jouer contre d'autre modérateurs par exemple.

Voilà un raisonnement tout à fait logique

Mais il n'apparait nulle part dans ton document et la question reste donc ouverte.

La clé de la réussite réside dans le fait que ton document doit être "suffisamment général" pour permettre de choisir l'implémentation, mais "suffisamment précis" pour ne laisser la place à aucune interprétation quant à ce que peuvent (ou ne peuvent pas) faire les différents éléments.

Prends peut être le temps de réfléchir à deux nouvelles phrases:

La question la plus idiote est celle que l'on n'aura pas posé.

et

L'information qui manquera sera toujours celle que l'on n'a pas donnée

Jacques II de Chabannes, seigneur de La Palice, maréchal de François Ier, n'aurait sans doute pas fait mieux, je te l'accorde

Mais ce qu'il est important de comprendre, c'est que pour chaque question que l'on est en droit de se poser, il y a une réponse qui convient et "un certain nombre" qui ne conviennent pas.

Si ton document n'apporte pas toutes les réponses qui conviennent, tu laisses la place à l'interprétation par la suite, et tu risques de te retrouver avec quelque chose qui ne correspond absolument plus à tes besoins

Dans le CdC, je n'ai jamais dit qu'ils ne pouvaient pas être des joueurs.

C'est bien pour cela que je t'ai posé la question, en justifiant (par l'absurde, je te l'accorde ) la raison pour laquelle je te la posais

Il faut vraiment dire autant de choses ?

Même si c'est sous la forme d'une note à la fin de la description d'un concept donné, ce sont des informations qui doivent apparaitre.

C'est toujours la même chose: si l'information "le maitre de salon (le modérateur) peut parfaitement participer à la partie" n'apparait noir sur blanc dans ton document, tu laisses le choix à celui qui devra implémenter le concept de décider.

Et tu dois donc t'attendre à ce que le type qui implémentera le concept se dise "ouhlàlà, risque d'arbitraire, je l'interdis".

Mais les responsabilités n'ont-elle pas déjà été mises en avant avec les définition ?

En partie, du moins, très certainement.

Mais la description du concept a pour but de répondre à la question "c'est quoi "

Ici, je te propose de répondre précisément à la question "il fait quoi "

Cela te permettra de déterminer plus clairement si un service (une fonction publique) ou un comportement (une fonction interne) donné correspond bien à ce que l'on est en droit d'attendre de la part du concept envisagé.

Il est très facile, sur base de la seule description d'un concept, de se dire que "bah, tel service entre dans la description de tel concept" parce que ca "marche à peu près".

Le problème, c'est que, à force de se dire cela, tu vas te retrouver avec des classes "mégalithiques", qui ont trois, cinq ou quinze responsabilités différentes et auxquelles tu n'oseras plus toucher tellement tu auras peur de "casser quelque chose".

Par contre, si tu indiques très clairement et de manière non ambigue "la responsabilité de tel concept est de <blah, blah>", la question ne se pose pas : soit un service (un comportement) entre dans le cadre de cette responsabilité, et tu peux donc (éventuellement) en faire une fonction membre, soit ce comportement, ce service n'entre pas dans la responsabilité de ton concept, et il faut donc trouver le concept dont la responsabilité correspond à ce comportement ou à ce service.

Quitte, à rajouter un concept pour l'occasion

Merci pour tes réponses mais je crains que tu ne m'aie un peu perdu, c'est un peu trop pour moi

Mais non!

Je te crois suffisamment intelligent pour arriver à faire cette "gymnastique de l'esprit"

Mais le principe de base reste toujours le même: tu ne dois laisser aucune place à l'interprétation.

Tu connais, très certainement, le jeu du "téléphone sans fil" : ce jeu où quelqu'un dit une phrase dans l'oreille d'un autre qui la répète à un autre, et ainsi de suite

Poses toi peut être la question de savoir dans quel état te reviendrait ce document si tu le faisais traduire en anglais, puis de l'anglais à l'espagnol, puis de l'espagnol à l'allemand, avant de faire traduire l'allemand en portugais et le portugais en français, sachant que chaque traducteur apporterait sans doute sa propre interprétation pour ce qui n'est pas écrit noir sur blanc.

Crois tu que le document qui te reviendrait dans les mains après avoir joué au téléphone sans fil avec serait

1. très éloigné de ton document original
2. éloigné, de ton document original
3. relativement proche de ton document original
4. très proche de ton document original
5. la copie conforme de ton document original

L'idéal (dans un monde de bisounours) est d'atteindre la "cote" de 5... Mais il ne faut peut etre pas trop rêver non plus.

Avec une note de 3 ou de 4, ton document est assez précis pour passer à l'étape suivante, en sachant qu'il faudra sans doute revenir dessus pour certains points.

Avec un note inférieure à 3, il est vraiment nécessaire de l'améliorer avant d'espérer passer à l'étape suivante

Je n'ai lu ton document qu'en diagonale, mais, selon toi, quelle serait la note qu'il mérite

Est-ce que tu n'aurais pas un exemple d'un court CdC que je visualise un peu la "forme finale" ?

Moi, non... Mathieux, peut-être

Le bon côté des choses c'est qu'après le diagramme de classe et l'implémentation sera triviale comparé au CdC

Mais c'est le but recherché : chaque étape ne sert qu'à préparer le terrain en vue de l'étape suivante

Plus tu auras été "au fond des choses" avec ton papier et ta feuille (pardon, avec ton crayon et ta feuille) dans l'expression et l'explication des concepts qu'il faudra mettre en oeuvre, plus tu auras facile à représenter cela sous la forme d'un diagramme

Par contre, si tu laisses des "zones d'ombres", si tu laisses la place à l'interprétation, tu laisses la possibilité à "celui qui viendra après toi" de choisir ce qui l'arrange le mieux (ou du moins ce qui est le plus en accord avec ses propres hantises)

[Neckara]

Je commence à saisir un peu l’esprit.

Mais ce n'est que mon premier "vrai" CdC et je ne pense pas que je puisse réussir à suivre toutes vos indications (il y en a quand même quelques page) pour créer un super CdC en un seul coup


Si j'ai bien compris les grandes étapes :
1) écrire la description du projet (quoi/pourquoi) ;
2) dégager les concepts important de la description (qu'est-ce);
3) décrire les concepts et noter sur un papier ceux qui n'ont pas encore été décris
4) répété l'étape 3 jusqu'à ce qu'il n'y ai plus de concepts sur la feuille
5) Associer à chaque concept une responsabilité (que doit-il faire ?)

En faisant attention à :
- être précis sur les mots
- ne pas laisser d'ambiguïté
- tenter de répondre à toutes les questions, même les plus "idiotes"

Je pense qu'il faudrait sûrement que je reprenne le CdC en suivant les étapes petit à petit mais cela me gène vraiment de ne pas avoir un modèle/une référence, je n'arrive pas à visualiser la "forme finale"
Il n'y a pas de CdC que vous considéreriez comme "bon" sur internet ?

[Matthieu Vergne]

Un exemple de CdC ? Dans l'absolu oui, mais qui puisse jouer le rôle de référence... aucune chance {'^_^}. Ou tout du moins pas de mon point de vue.

Le fait est que, comme les bonnes pratiques en programmation, ce qu'on te donne là sont des bonnes pratiques pour établir un CdC. Mais ça ne reste que des bonnes pratiques et non des règles à proprement parler. Tout comme en programmation, quand on en vient à la pratique, il faut toujours être prêt à passer outre une bonne pratique du fait des contraintes spécifiques du contexte (comme une convention de nommage avec des noms explicites n'aurait pas beaucoup d'intérêt avec un environnement de programmation qui n'autorise que des noms de 10 caractères maxi). Par exemple, si tu as un projet perso où tu veux implémenter un jeu de go pour 2 joueurs mais que tu as plus de connaissances en prog qu'en go, tu seras bien incapable d'établir un cahier des charges complet, et il te restera donc des zones d'ombres que tu seras bien incapable de combler, voire même d'identifier sans passer au codage et tomber dessus. Et là c'est parti pour une chaîne habituelle :
- Comment y remédier ? En apprenant plus de choses sur le go.
- Quand s'arrêter ? Quand tu n'auras plus de zones d'ombres.
- Quand est-ce qu'on en a plus ? Quand l'intégralité de la suite du projet s'en déduit logiquement.
- Quand est-ce que c'est le cas ? ...Quand l'intégralité de la suite du projet s'en déduit logiquement.

Un CdC, de manière générale, a toujours ce problème. En fin de compte, il est parfait quand, à partir de celui-ci, tu es capable de faire toute la chaîne "diagramme->implémentation->tests" de manière, si ce n'est automatique, au moins triviale et sans ambiguité. Mais ça, tu ne le sais que quand tu as terminé le projet, jamais avant. Et en pratique, ce n'est jamais le cas, sauf parfois pour des cas d'écoles et projets "one-shot" (tu utilises et puis tu jettes), donc rien de bien sérieux. Ce qui te permet de prévoir qu'un CdC n'est pas suffisant, c'est quand tu sais que, avec ce que tu y as mis, un autre projet (que tu connais ou imagines) ne pourrait pas s'en sortir. Autrement dit c'est parce que tu as les connaissances sur d'autres cas.

La qualité d'un CdC se résume généralement aux connaissances et à la rigueur de son rédacteur. Il n'existe pas de bon CdC écrit simplement. Un bon rédacteur de CdC est quelqu'un qui doit se poser plus de questions que tous ceux qui suivent. Et tu imagines bien qu'un tel être pluri-disciplinaire et expert sur chacun de ces domaines n'existe probablement pas.

Bien entendu il y a des solutions pour y remédier, mais ça devient encore plus complexe et lourd à gérer, donc c'est bon pour les gros projets avec des responsabilités critiques. C'est mon domaine de recherche donc je pourrais te faire un long speech là dessus, mais je pense que ça sort de la perspective qu'il te faut prendre sur ce projet. Aller plus loin te démotiverai sûrement plus qu'autre chose.

[Matthieu Vergne]

J'oubliais. Malgré tout, ce qui faut retenir c'est ce qui a déjà été dit plusieurs fois, la règle d'or d'un bon CdC : 1 seule interprétation.

Donc si par chance, par expérience ou par le retour de quelqu'un, tu identifies une interprétation différente (qui ne colles pas à ce que tu veux exprimer), alors tu as du raffinage à faire. On ne sait jamais quand il n'y en a plus, mais il est facile d'en trouver d'autres : se relire et faire relire par quelqu'un d'autre.

Ce qui peut t'aider aussi, c'est de te mettre à la place du lecteur du CdC. C'est vrai pour toute rédaction de document : si tu sais à quoi doit servir ton document, tu dois pouvoir identifier ce qu'il doit contenir. À ta charge ensuite de faire pour que chaque question y trouve facilement une réponse, et ça c'est la structure du contenu qui te permet de le faire.

[Neckara]

D'accord je vois.

Mais j'aimerais bien avoir un exemple ne serait-ce que pour la structure et la mise en forme. Par exemple, pour mes concepts, est-ce qu'il vaut mieux faire une phrase ou faire comme j'ai fait :
concept : description du concept
?

Sinon, si un CdC n'est jamais "parfait", où se situe le mien? largement insuffisant ? pas mal pour un début ? plus ou moins correct?

[Matthieu Vergne]

C'est une des questions les plus importantes : pour qui écris tu ce CdC ?

Quand tu as identifié ton public, prend sa place et regarde ton CdC. Est-ce que la structure utilisée lui permettra de comprendre son contenu du premier coup d'oeil ? Est-ce que l'introduction lui permettra d'avoir une vue globale du projet ? Est-ce que la formulation de ton contenu (que ce soit des phrases, des listes, des tables ou des dessins) lui permettra de comprendre ce que tu veux dire ?

Pour ma part, ça commence très mal car je ne connais pas Last Dungeon. Donc dès l'intro je ne sais pas de quoi tu parles. Mais cet avis n'a aucun intérêt si ton CdC vise une audience de joueurs de LD.

Commence par identifier ton public. Ensuite regarde du niveau le plus haut (CdC, chapitres) au plus bas (paragraphes, phrases). À chaque niveau ton public doit identifier aisément l'objectif de chaque sous partie en connaissant uniquement l'objectif des niveaux au dessus (le niveau le plus haut étant le CdC, dont l'objectif est de présenter les besoins d'un projet). Et l'ordre entre chaque sous-partie doit être pertinent (la partie précédente doit permettre de comprendre la partie suivante, à moins que l'objectif du conteneur soit de lister un ensemble d'éléments, mais ça doit être clair au niveau au dessus). Si tu as deux éléments (chapitres, sections, paragraphes, phrases, peu importe) qui se suivent sans lien évident entre les deux, c'est probablement qu'ils doivent apparaitre dans des éléments parents différents (redécoupage).

Tu peux utiliser plein de structures différentes. Il y en a des classiques et des moins classiques. Celles que koala01 t'as donné, ce n'est pas celle avec laquelle je suis la plus familière, mais ce qui importe c'est ce que tu arrives à exprimer avec ta structure. Il n'y a pas de bonne structure en soi, seulement de bonnes utilisations.

Si on voulait te sortir un CdC bien fait, il faudrait t'en sortir un de l'armée par exemple, qui sont très méthodiques, mais je pense pas qu'un CdC de plusieurs dizaines voire centaines de page soit un bon exemple pour un petit projet comme le tien. C'est toujours beaucoup d'effort, mais il n'y a pas de CdC parfait. Il faut arriver à trouver le bon compromis entre suffisamment de précision et suffisamment de simplicité.

[Neckara]

En fait le CdC est surtout fait pour moi-même ainsi que d'éventuels (?) programmeurs qui souhaiteraient m'aider.

Le problème c'est que je n'ai aucun moyen pour déterminer si mon CdC me permet de commencer le diagramme de classe ou s'il faut que je continu à travailler dessus.

Je vais essayer de refaire une dernière version je pense.

[Matthieu Vergne]

Et comme dit plus haut, tu ne le sauras que quand tu auras fait ton diagramme de classe {^_^}. Après c'est l'expérience qui te permet de faire la différence.

C'est pour ça que c'est pas un mal de faire ce diagramme par toi-même pour identifier les parties du CdC à revoir.

[koala01]

D'accord je vois.

Mais j'aimerais bien avoir un exemple ne serait-ce que pour la structure et la mise en forme. Par exemple, pour mes concepts, est-ce qu'il vaut mieux faire une phrase ou faire comme j'ai fait :
concept : description du concept
?

Dis toi que ton document doit servir comme une "bible" de ce qui doit être fait.

C'est en effet à ton document que l'on fera référence à chaque fois que l'on se posera une question

A partir de là, ta responsabilité en tant que rédacteur de la bible est de permettre au gens de trouver la réponse à leur question "le plus facilement possible".

Personnellement, j'apprécie lorsqu'il est vraiment facile de savoir de quoi l'on parle. je serais donc plutôt du genre à créer:

1. une section par "système" (données métiers, système d'entrée/ sortie, système de communication avec l'extérieur, ...)
2. Un titre par concept
3. Des sous-titres éventuels

le tout idéalement repris dans un index permettant de s'y retrouver facilement.

N'hésites pas à placer une petite introduction pour justifier la présence d'un concept s'il donne l'impression de "tomber du ciel" (comprends: qu'il n'est pas apparu dans les explications fournies pour d'autres concepts) : pourquoi introduit-on ce nouveau concept, quel problème il est sensé résoudre, etc.

En gros, l'idée est toujours la même : ton document devrait, idéalement, répondre sans ambiguité à toutes les questions qu'un lecteur pourrait se poser : quoi , pourquoi , comment , restrictions éventuelles , avec qui ou avec quoi (j'en passe et de meilleures ), et, fin du fin, lui permettre de trouver facilement la réponse

Ceci dit, n'oublies pas que la méthode agile de manière générale se essentiellement sur un grand nombre de petits objectifs clairement déterminés.

Rien ne t'empêche de partir d'un document général qui contient la description du projet, les grands axes qui devront être abordés (données métier en priorité, entrées/sorties, communication), les évolutions futures "globales" à l'ensemble du projet, puis de rajouter un document qui présentera essentiellement les données métier (car, sans elles, tout le reste ne sert à rien) faisant référence de manière générale aux autres système, afin de post poser la réflexion sur le système d'entrées/sorties ou sur le système de communication avec l'extérieur jusqu'à ce qu'il soit nécessaire de s'y intéresser (ou jusqu'à ce qu'il y ait "quelqu'un" qui soit disposé à y réfléchir et qui ait le temps de le faire )

Cela te permettra de te "focaliser" sur un aspect particulier, quitte à ce qu'il fasse référence à "d'autres aspects" tout aussi particulier qui sont traités "par ailleurs" (avec une petite note en bas de page permettant de savoir où aller chercher des informations sur cet aspect extérieur, c'est toujours utile )

Cela évitera très certainement d'avoir des diagrammes surchargés sur lesquels les grands systèmes s'entremêlent sans cesse et mettra très certainement l'accent sur la nécessité d'avoir un "interface générale" qui permet les communications entre deux modules

Sinon, si un CdC n'est jamais "parfait", où se situe le mien? largement insuffisant ? pas mal pour un début ? plus ou moins correct?

Je dirais "pas mal pour un début" mais "très certainement perfectible".

On en revient, décidément, toujours au même point : il doit être complet, sans ambiguité, et te permettre d'organiser ton travail sous la forme de "modules".

L'idée est que certains modules (celui qui concerne les données métier en priorité) sont indispensables car les autres se baseront dessus pour prendre "une partie de ton projet" en charge (toujours le même exemple: le système "d'entrées / sortie" ou le système de "communication avec l'extérieur" ).

Dans les projets de grande ampleurs, on peut parfaitement avoir des modules qui s'appuient sur des modules qui s'appuient sur un module qui s'appuie sur le module des données métiers, et l'on peut donc avoir des modules dont il faut impérativement avoir fini l'implémentation afin de pouvoir ne serait-ce qu'envisager sereinement de commencer l'analyse d'un (ou de plusieurs) autres modules .

Encore une fois, j'en reviens au principe des légo : tu as besoin des "briques de base" que sont les données que tu vas manipuler en propre (les données métiers propres à ton projet).

Tant que tu n'as pas ces "briques de base", il te sera particulièrement difficile de savoir comment devront réagir les différentes commandes introduites par l'utilisateur, même si tu en a déjà dressé la liste exhaustive!

Et l'on tourne en rond parce que, pour être sur de dresser la liste exhaustive de toutes les commandes qu'un utilisateur (de manière tout à fait générale ici) peut lancer, il faut avoir déterminé avec précision la responsabilité de chacun

C'est pour cela que l'idée principale est que ton document puisse répondre à "toutes les questions que tu t'es déjà posé".

Quitte à ce que tu viennes rajouter une information au moment où tu te poses une nouvelle question à laquelle le document ne répond pas

[Matthieu Vergne]

Tu es le seul à pouvoir certifier quels sont les besoins qui t'intéressent et ceux que tu ne comptes pas considérer dans ton projet. Cela passe cela dit par une compréhension en profondeur du projet en question, que tu n'as en fait qu'une fois le projet terminé. Il te faudra donc toujours faire face à des zones d'ombres (c'est plus ou moins les conclusions tirées du cycle en V et ce pour quoi les méthodes agiles sont sorties).

En ce sens, un CdC ne peut avoir pour objectif que de débroussailler au maximum. Le tout étant de décider quand est-ce qu'on s'arrête. Les méthodes agiles n'ont pas de CdC tel qu'on le voit ici. Elles ont plus un mini-CdC pour chaque itération, et si tu les combines tous (en remplaçant les zones d'ombres des précédents par les clarifications de suivants), à la fin du projet tu obtiens un CdC complet. Si tu veux établir quelque chose le plus complet que possible dès le début, il te faudra arriver à discerner quand est-ce que tu es incapable d'aller plus loin, justement parce que tu n'as pas la "mise en pratique" derrière pour te donner les informations nécessaires. Quelqu'un qui est capable d'aller plus loin est quelqu'un qui sait déjà grâce à un autre projet déjà fait.

Les techniques plus évoluées dont je parlais sont majoritairement basées sur l'obtention de ces informations complémentaires à partir d'autres personnes (e.g. forums et mailing list, réseaux sociaux au sens large) voire documents (e.g. data mining).

[Neckara]

J'ai essayé de refaire le CdC comme je pense que vous visualisez un CdC mais je ne pense pas avoir suivie parfaitement toutes vos recommandations

Je pense qu'il faudra que je le relise vite fait mais qu'en pensez-vous ?
C'est mieux ou c'est pire ?

Est-ce qu'il y a des points où je m'en suis mieux sortit que la dernière fois et d'autres points où le précédent CdC était "mieux" ?

Si vous pensez qu'il est "acceptable", je l'enverrais à une de mes connaissances pour avoir son avis et je pense que je m'arrêterais là

[Matthieu Vergne]

Niveau structure déjà, c'est beaucoup plus évident. Éventuellement, quand tu as beaucoup d'éléments (plus de 5-6) dans une même section, tu peux rajouter un niveau pour faire des groupements intermédiaires. Par exemple :

B Définitions métiers
B.I Salon
B.II Carte
B.III Description de carte
B.IV Session de jeu
B.V Équipes de joueurs
B.VI Joueur
B.VII Visiteur
B.VIII Maître de salon
B.IX Modérateur
B.X Personne

Je verrai bien :
B Définitions métiers
B.I Salon
B.II Carte
B.II.1 Concept de base
B.II.2 Description de carte
B.III Session de jeu
B.IV Personne
B.V Joueurs
B.V.1 Concept de base
B.V.2 Équipes de joueurs
B.VI Non-joueurs
B.VI.1 Visiteur
B.VI.2 Maître de salon
B.VI.3 Modérateur

J'ai volontairement réutilisé des titres pour me simplifier la tâche, mais l'important c'est de comprendre l'idée. Dans le cas des actions, ça me semble particulièrement pertinent de rajouter (ou redécouper) les différentes sections. Voire de virer les sections de plus bas niveaux pour en faire de simples listes (cf. mon commentaire plus loin sur les sections vides). Cela dit, ça peut se rapporter plus à un critère esthétique que pratique, donc à méditer.

Il y a aussi des trucs qui ne font pas très naturel, comme le fait de définir une équipe de joueur avant de dire ce qu'est un joueur, ou le fait que la seule action spécifique du joueur soit d'abandonner (pas très productif tout ça {'^_^}), ou encore le fait "d'ouvrir un joueur" (je m'imagine déjà avec le scalpel {^o^}).

Dans l'ensemble c'est pas mal. J'ai lu le contenu en diagonale (pas vérifié la cohérence, mais la tournure des phrases semble pas mal). Ce qui me choque :

- Last Dungeon*: notre projet de RPG en ligne. Le nom «*Last Dungeon*» vient du scénario de ce jeu mais nous ne pouvons pas vous en dire plus sous peine de vous «*spoiler*».

Un CdC vise à donner les informations suffisantes pour pouvoir implémenter. Si tu n'as pas besoin de certaines informations, ne les donne pas, sinon donne-les. Si ça spoil, alors spoil. Dans un CdC, on n'a pas affaire à des joueurs, mais à ceux qui vont faire le jeux (ou quelque chose qui s'y rattache). Il n'y a pas de "spoil" dans un CdC, il n'y a que des informations utiles ou inutiles.

L'utilisation de «*...*» : si tu veux mettre en évidence les termes important, préfère utiliser l'italique, c'est moins lourd à lire et à écrire, voire le gras pour les informations auxquelles il faut faire particulièrement attention (qu'on aurait vite tendance à oublier ou à ne pas comprendre à première lecture). Cependant, si tu décides de mettre en avant les termes important, fait-le dans tout ton document, sinon ne le fait pas du tout (reste cohérent).

L'utilisation des abréviations dans "D Liste des actions possibles" : peu clair. Les abréviations permettent de réduire le place prise, pas d'expliquer clairement quelque chose. Préfère décrire chacune de tes actions et à la fin faire un tableau récapitulatif ou tu auras une action par ligne et un "cas" par colonne (ce que tu mets en abréviation). Avec une croix dans chaque case qui s'applique, ça sera beaucoup plus clair. Tu peux utiliser tes abréviations ou des termes complets dans les colonnes, vu que la description est juste au dessus de la table (a priori) y'a pas de soucis.

N'utilise pas des sections quasiment vides, D.II.1 à D.II.4 par exemple. Préfère avoir une section pour tous les points décris succinctement, inutiles de charger la structure à ce point. Autrement assure-toi de donner une description, même si évidente. Soi tu en fais une section parce que tu as quelque chose à dire, soit tu n'en fais pas une section parce que ça te sert seulement à parler d'autre chose. Une fonctionnalité sans description c'est louche.

"multi-incarnage" et son copyright : en France on parle de marque (déposée ou non) et non de copyright (concept de Common Law si je ne m'abuse). De plus, tu ne peux déposer une marque que pour en faire le symbole d'un produit ou service particulier, pas juste un concept. Enfin bon, ça c'est pour la leçon du jour {^_^}.

[Neckara]

Voici ma nouvelle version

Je l'envoie à une de mes connaissance pour avoir son retour.

"multi-incarnage" et son copyright : en France on parle de marque (déposée ou non) et non de copyright (concept de Common Law si je ne m'abuse). De plus, tu ne peux déposer une marque que pour en faire le symbole d'un produit ou service particulier, pas juste un concept. Enfin bon, ça c'est pour la leçon du jour {^_^}.

C'était pour plaisanter en soulignant le fait que "multi-incarnage" n'est pas français