Discussion :

[akito]

Bonjour,

Pour un projet, je dois développer un jeu de carte simple (type memory).

Je travaille sur l'analyse UML et j'ai donc fais des diagrammes de séquences, de cas etc.

J'essaye d'établir un diagramme de classe mais je bloque un peu.

En effet, je me mélange un peu les pinceaux entre un diagramme simple décrivant les relations entre des classes simples, abstrait, et un diagramme plus technique avec fenêtre, bouton etc...

Doit-on tout mettre dans le même diagramme de classe ou en faire deux?

Par exemple, un diagramme ou j'aurai les classes : joueurs, ordinateur, plateau, carte, niveau, contrôleur etc.

Et un diagramme avec : Fenetre, Bouton, Image, etc.

On m'a conseillé de d abord faire un DS boite noir mais je ne comprends pas très bien.

Merci pour votre aide

[hed62]

Tu ne devrais jamais avoir de classe Fenetre / bouton etc.. cela relève de l'implémentation et sors du cadre de la conception.

Le seul type de DC à faire ( tu peux en avoir plusieurs) contiendra forcément des " joueurs, ordinateur, plateau, carte, ... "

En ce qui concerne les diagramme de séquence, DS, oui on les fait généralement en deux temps. Le premier DS est proche de l'UC, et reprend les échanges de messages entre l'acteur et le système sans montrer la mécanique interne (ni parler d'action telles que 'clic sur le bouton' mais plutôt 'validation') . Le deuxième DS montrera les échanges et la mécanique interne de l'application.

[akito]

Salut et merci pour ta réponse!

Tu as mis le doigt exactement sur ce qui me pose probleme.

J'ai du mal a faire la différence entre l'analyse UC et l'analyse de la "mecanique interne" comme tu le dis.

Je n'arrive pas bien a identifier ce qui ne vas pas dans l'analyse UC...

Par exemple, lors de mon analyse j'ai dégagé les classes : jeu, joueur, ordinateur, controlleur, plateau, case et carte.

Est-ce que ces classes relevent bien de l'analyse UC?

Comment ensuite détailler la "mecanique interne"?

Merci pour ton aide!

[hed62]

Est-ce que ces classes relevent bien de l'analyse UC?

Il me semble, oui.

Pour détailler la mécanique interne, généralement on procède par étapes : d'abord on détaille les UC par une description textuelle (en banissant les choix d'implémentation). Puis on établit les diagramme de séquence système (globalement la traduction de la description textuelle en DS). Puis on fait le diagramme de séquence complet en parralèle avec un diagramme de classes candidates.

Plus tu rafine, plus tu te rapproche du DC complet.

Jusqu'ici, il faut pouvoir utiliser la conception/analyse pour ton projet, qu'il soit réalisé en php ou en vb ou en java etc...

[akito]

Merci pour ta réponse.

Mais comment passer des mes UC à un diagramme de séquence système?

Par exemple, est ce que je dois mettre dedans les classes type "action event"? est ce que je dois parler de fenetre?
Ou alors, je vais avoir un algorithme qui melange les cartes lors de la distribution. Comment l'intégrer à mes diagrammes?

J'essaye d'appliquer le design MVC donc j'aurai une classe vue (le plateau), un controleur, et le modele (classe jeu).

J'ai donc fais un diagramme de classe mais je ne vois pas comment le détailler plus sans rentrer dans les détails type bouton, fenêtre, panel etc.

J'ai dejà rendu un dossier de "pré-analyse" (quelques pages) Uml avec différent diagramme mais c'est apparement pas suffisant... Je peux te l'envoyer sur ton mail yahoo pour avoir ton avis?

Encore merci pour ton aide

[hegros]

Mais comment passer des mes UC à un diagramme de séquence système?

Il faut découper le UC en opérations pour atteindre le but fixé par le UC. Dans le ds cela se traduit par une fléche entre utilisateur<->systeme, à proprement dit un message entre l'utilisateur et le système qui peut porter des informations(les paramètres)...

Si tu avais proposé un UC la traduction viendrait plus facilement

Par exemple, est ce que je dois mettre dedans les classes type "action event"? est ce que je dois parler de fenetre?

Cela dépend des ds cela varie en fonction de ce que tu souhaites modéliser

Ou alors, je vais avoir un algorithme qui melange les cartes lors de la distribution. Comment l'intégrer à mes diagrammes?

L'algorithme c'est encore autre chose, un ds présente une suite d'opérations à réaliser pour atteindre un objectif tout dépend du niveau de détail que tu souhaites, un diagramme d'état en complétion cela fait plaisir.

J'essaye d'appliquer le design MVC donc j'aurai une classe vue (le plateau), un controleur, et le modele (classe jeu).

J'ai donc fais un diagramme de classe mais je ne vois pas comment le détailler plus sans rentrer dans les détails type bouton, fenêtre, panel etc.

Puisque tu penses avoir toutes les classes alors range les dans des packages selon MVC. Un diagramme de package peut aider.

J'ai dejà rendu un dossier de "pré-analyse" (quelques pages) Uml avec différent diagramme mais c'est apparement pas suffisant... Je peux te l'envoyer sur ton mail yahoo pour avoir ton avis?

Je te conseille plutôt de poster tes diagrammes à la suite de ce post...

[akito]

Bonsoir et merci beaucoup pour ton aide.

Comme tu me le conseils je poste les différents diagramme que j'ai pu faire et les remarques que j'ai eut de mon prof.

Cas d'utilisation «Jouer une partie seul »

But : Le joueur essaye de trouver un maximum de paires de cartes en un minimum d'essais.

Acteurs : Joueur

Pré conditions :

Opérations :
1. Le joueur lance une partie seul
2. Le joueur choisi le niveau de difficulté
3. Le joueur choisi une première carte
4. Le joueur choisi une deuxième carte

Extensions :
4. La deuxième carte forme-t 'elle une pair avec la première?
4.1 Si oui, ajouter 1 au compteur de paires du joueur, enlever les deux cartes du plateau, le joueur peut rejouer, réexécuter l'étape 3
4.2 Si non ajouter 1 au compteur de coup, passer à l'étape 3

Ce cas d'utilisation se termine lorsque :
Le joueur à pris la dernière paire.
Le joueur quitte la partie.


2.4 Cas d'utilisation «Charger une partie »

But : Permettre au joueur de reprendre une partie entamé précédemment

Acteurs : Joueur

Pré conditions :
Au moins une partie doit être enregistré

Opérations :
1. Le joueur sélectionne la partie à charger
2. Le système importe les paramètres de la partie (score en cours, cartes restantes...)
3. Le joueur reprend la partie

Extensions :
3. Le joueur est-il seul?
3.1 Si oui, exécuter le cas d'utilisation 2.3
3.2 Si non et si il y a un deuxième joueur, exécuter le cas d'utilisation 2.2
3.3 Si non et si il y a un deuxième joueur, exécuter le cas d'utilisation 2.1

Ce cas d'utilisation se termine lorsque :
Le joueur partie est chargé.
----------------------------------------------------------------------
Voilà ce que le prof m'a dit sur cet UC :

ce que vous décrivez comme extensions n'en sont pas.
Une extension est une sorte d'alternative optionnelle sporadique pour l'utilisateur.ce n'est pas du tout le cas ici, puisqu'il s'agit d'alternative dans le déroulement du programme ne dépendant nullement des choix de l'utilisateur.

Que dois-je mettre à la place des extensions alors?
----------------------------------------------------------------------
Cas d'utilisation «Jouer une partie à deux joueurs»

But : Chaque joueur essaye de trouver un maximum de paires de cartes. Le gagnant est celui qui obtient le nombre le plus grand de paires.

Acteurs : Joueur1, Joueur2

Pré conditions :


Opérations :
1. Le joueur lance une partie à deux joueurs
2. Le joueur choisi le niveau de difficulté
3. Le système définit l'ordre de jeu
4. Le joueur1 choisi une première carte
5. Le joueur1 choisi une deuxième carte
6. Le joueur2 choisi une première carte
7. Le joueur2 choisi une deuxième carte

Extensions :
5. La deuxième carte forme-t 'elle une paire avec la première?
5.1 Si oui, ajouter 1 au compteur de paires du joueur1, enlever les deux cartes du plateau, le joueur1 peut rejouer, réexécuter l'étape 4
5.2 Si non, passer à l'étape 6
7.La deuxième carte forme t 'elle une paire avec la première?
7.1 Si oui, ajouter 1 au compteur de paires du joueur2, enlever les deux cartes du plateau, le joueur2 peut rejouer, réexécuter l'étape 6
7.2 Si non, passer à l'étape 4

Ce cas d'utilisation se termine lorsque :
Le joueur1 à pris la dernière paire.
Le joueur2 à pris la dernière paire.
L'un des deux joueurs quitte la partie.
----------------------------------------------------------------------
Voilà ce que le prof m'a dit sur cet UC :

le cas d'utilisation jouer à deux joueurs devrait factoriser une partie des échanges avec le cas d'utilisation jouer à un joueur.

Je ne vois pas quoi et comment factoriser?


En pièce jointe le diagramme séquence qui en découle. Pour moi c'est un diagramme systeme. Je détail peut etre un peu trop le MVC car j'ai mis la classe contrôleur et plateau, mais je ne vois pas l'intérêt de mettre à la place "systeme" et refaire juste aprés ce diagramme. Est-ce que c'est bon?

tu dis :

Puisque tu penses avoir toutes les classes alors range les dans des packages selon MVC. Un diagramme de package peut aider.

Je n'ai pas vu en cours le diagramme de package. C'est définir à quel package appartient une classe? Par exemple la classe plateau appartient à la classe vue?
Quel est le but d'un diagramme de package?

Encore merci beaucoup pour ton aide précieuse!

[hegros]

Un diagramme de séquence est une vue de face, il est préférable d'utiliser un diagramme de communication (vue de haut) quand on numérote l'ordre des messages. Il y a des choses un peu bizarre dans ton diagramme comme le joueur qui s'envoi un message à lui même pour tirer une carte au sort(c'est normalement le JeuDeCarte qui devrait le faire ?) Choisir carte est un message à envoyer au controleur pas au joueur lui même

Pour le diagramme de package j'appelle cela aussi l'architecture logique du système. Tu as bien un package Presentation (qui contient les classes fenetres, boutons etc....), Modele (qui contient les classes représentant les concepts du domaine comme une carte) et Controleur (qui contient les classes de controle entre la presentation et le modele) Chaque paquet peut être découpé en plus petit paquet ce qui donne souvent des sous-package. Ne pas oublier de mettre les dépendances entre package.

Voilà ce que le prof m'a dit sur cet UC :

ce que vous décrivez comme extensions n'en sont pas.
Une extension est une sorte d'alternative optionnelle sporadique pour l'utilisateur.ce n'est pas du tout le cas ici, puisqu'il s'agit d'alternative dans le déroulement du programme ne dépendant nullement des choix de l'utilisateur.

Que dois-je mettre à la place des extensions alors?

Je vais te donner un exemple d'extension

2.a L'importation a échoué
1. Le Système avertit l'utilisateur et retourne à l'écran de sélection de partie

Une extension c'est quand tu arrives à détecter quelque chose. Du coup je formulerais "Il s'agit d'une partie à 2" plutôt que "Le joueur est-il seul ?"

Voilà ce que le prof m'a dit sur cet UC :

le cas d'utilisation jouer à deux joueurs devrait factoriser une partie des échanges avec le cas d'utilisation jouer à un joueur.

Je ne vois pas quoi et comment factoriser?

Oui tu vois bien que les 2 UC se ressemblent sur certaines parties (choisir une carte, choisir un niveau....) Tu peux peut-être regrouper en 1 UC "Jouer Partie" et expliciter le reste dans les extensions.

Ensuite dans ton diagramme de séquence quel scénario tu modéliser ? J'ai du mal à le voir puisque verifcarte n'apparait nul part dans les UC... C'est un diagramme de séquence par scénario possible surtout ne pas essayer de tout rentrer dans un seul.

[akito]

Salut et merci pour ta réponse!

Choisir carte est un message à envoyer au controleur pas au joueur lui même

Oui, tu as raison. Je l'avais vu dans le sens "le joueur reflechi quelle carte il va choisir" lol mais ça n'a pas d'intérêt, il faut comme tu le dis envoyer le message au système.
Mais je l'envoie plutôt au plateau, qui lui l'envoie à la vue non? Le joueur n'interagit pas directement avec le contrôleur mais par l'intermédiaire du plateau, non?

Une extension c'est quand tu arrives à détecter quelque chose. Du coup je formulerais "Il s'agit d'une partie à 2" plutôt que "Le joueur est-il seul ?"

Ok je comprends mieux le but de l'extension.
Mais alors comment intégrer mes extensions autrement? :

4. La deuxième carte forme-t 'elle une pair avec la première?
4.1 Si oui, ajouter 1 au compteur de paires du joueur, enlever les deux cartes du plateau, le joueur peut rejouer, réexécuter l'étape 3
4.2 Si non ajouter 1 au compteur de coup, passer à l'étape 3

Je les mets directement dans les operations?

Oui tu vois bien que les 2 UC se ressemblent sur certaines parties (choisir une carte, choisir un niveau....) Tu peux peut-être regrouper en 1 UC "Jouer Partie" et expliciter le reste dans les extensions.

Ok donc je fais un seul UC "jouer partie". Et je fais une extension pour le cas ou il y ait deux joueurs?

Ensuite dans ton diagramme de séquence quel scénario tu modéliser ? J'ai du mal à le voir puisque verifcarte n'apparait nul part dans les UC... C'est un diagramme de séquence par scénario possible surtout ne pas essayer de tout rentrer dans un seul.

Mon diagramme de séquence modélise "jouer une partie à 2 joueurs".
En fait verifcarte est présent dans l'UC par l'extension "5. La deuxième carte forme-t 'elle une paire avec la première?". Donc verifcarte verifie cette condition.

Encore merci pour ton aide

[hegros]

Juste pour te donner un exemple ne pas le prendre comme quelque chose d'exhautive c'est plus pour l'idée sinon cela me prendrait plus de temps

Tu as 1 diagramme de séquence système qui reprends 1 scénario de ce que tu as décrit textuellement dans ton UC

Tu as 1 contrat d'opération (surement pas complet)

Un contrat d'opération c'est en fait un événement système vu avec une boite blanche (on détaille derriére ce qu'il se passe)

Pour le MVC le modéle c'est clairement le plateau la carte(qui n'apparait pas ici d'ailleurs) la vue c'est la fenetre de jeu et le controleur c'est le controleur

[akito]

Salut et merci pour ta réponse!

C'est sympa d'avoir pris le temps de faire des ptits diagramme pour illustrer tes propos

En ce qui concerne le contrat d'opération, je voyais pas les choses comme ça.

Pour moi le plateau et la carte sont les elements que l'on voit, donc je pensais que ça faisait partie plutôt du package Vue, pour le contrôleur, contrôleur, et pour le Modele une classe JeuMemory (classe qui contient en gros les regles du jeux).

Ca me fait bizarre de considérer le plateau comme modele, mais tu as peut etre raison.

Pour le scénario jouer une partie le "cadre" loop est judicieux. Par contre, je peux mettre ça comment dans l'UC? Je fais comme dans mes extensions, je renvoie à une opération précédente?

Merci de prendre de ton temps pour m'aider

[hegros]

Pour moi le plateau et la carte sont les elements que l'on voit, donc je pensais que ça faisait partie plutôt du package Vue, pour le contrôleur, contrôleur, et pour le Modele une classe JeuMemory (classe qui contient en gros les regles du jeux).

Ca me fait bizarre de considérer le plateau comme modele, mais tu as peut etre raison.

Quand on parle de Vue dans le modèle MVC ce sont bien des fenetres ou alors des boutons en tout cas des éléments graphiques. Tu dois penser à un élément comme une ImageBox qui contiendrait l'image d'une carte ou alors un plateau et tu as totalement raison ces classes font bien parties de la vue.

Tu me mets un peu le doute mais réfléchit bien parce que tu pourrais bien avoir une VuePlateau (pour permettre d'avoir une vue de face ou de haut ou en 2D par exemple en tout cas quelque chose de graphique) et un ModelePlateau (pour permettre de définir sa structure ou encore d'interagir avec lui comme demander de tirer une carte en tout cas pas quelque chose de graphique)

Les régles du jeu devraient bien se positionner dans le package Modele.

Le controleur il faut le voir comme une classe qui joue l'interface entre les fenetres graphiques et les objets du modele. C'est un peu la couche applicative.

Pour le scénario jouer une partie le "cadre" loop et judicieux. Par contre, je peux mettre ça comment dans l'UC? Je fais comme dans mes extensions, je renvoie à une opération précédente?

Tu peux le mettre en italique dans la description textuelle exemple:

1-Le Joueur choisit une première carte
2-Le Système affiche la première carte tirée au sort
3-Le Joueur choisit une seconde carte
4-Le Système affiche la seconde carte tirée au sort
tant qu'il reste des pairs répétez les séquences à partir de 1

[akito]

Oki, merci pour tous ces conseils, j'y vois plus clair

Je connaissais pas les boucles avec les textes en italique. C'est normalisé? Uml1? Uml2?

Une autre question : Les classes qui étende AbstractAction donc pour gérer les evenements (clique sur un bouton), font partie du package controleur c'est ça?

Encore merci pour ton aide

[hegros]

Je connaissais pas les boucles avec les textes en italique. C'est normalisé? Uml1? Uml2?

C'est comme cela que j'ai vu dans un bouquin UML 2 maintenant pour UML 1...

Une autre question : Les classes qui étende AbstractAction donc pour gérer les evenements (clique sur un bouton), font partie du package controleur c'est ça?

Du tout. C'est dans la Vue. Voilà un exemple minimal. Les packages se déduisent plus ou moins des classes que tu as identifiés en fait c'est un regroupement/organisation logique de classes.

[akito]

Oki super! Merci pour ce schéma.

Donc les évènements sont les liens entre la vue et le controleur mais font parties de la vue.

Donc je pense qu'il faut mettre un minimum de code dans les évènements, juste de quoi appeler le contrôleur adéquate, c'est ça?

Encore merci pour tes lumières qui me donne une vision d'ensemble plus juste!

[hegros]

Donc les évènements sont les liens entre la vue et le controleur mais font parties de la vue.

On parle bien des événements de fenetre comme clic, double-clic etc... ? Si oui ces événements sont spécifiques à la Vue il ne faut surtout pas les mettre dans le modele ou le controleur.

Donc je pense qu'il faut mettre un minimum de code dans les évènements, juste de quoi appeler le contrôleur adéquate, c'est ça?

Un exemple en Java, ActionListener est l'interface qui permet de gérer des événements grahiques (notamment ici le clic d'un bouton)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public class Fenetre extends JFrame implements ActionListener
{
private JButton monBouton;
public void Fenetre()
{
  monBouton = new JButton("cliquez ici");
  monBouton.addActionListener(this); //maintenant à chaque clic la méthode actionPerformed est executée
}
public void actionPerformed(Event e)
{
   if(e.getSource()==monBouton)
   {
       Controleur.boutonPresser();
   }
}

public void changeDeVue()
{
//du code (voir en bas l'appel à la méthode)
}
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class Controleur 
{
private Fenetre fen;
public Controleur(Fenetre f)
{
   this.fen = f;
}
public void   boutonPresser()
{
   System.out.println("Yes I do");
  //ou plus réel
  this.fen.changeDeVue();
}
}

Pour le MVC il faut le voir comme c'est dit dans le livre head first pattern : un pattern de pattern.

Pour la Vue c'est le pattern Composite, le Modele c'est le pattern Observateur et pour le controleur le pattern stratégie, tu peux faire des recherches sur ces patterns si tu t"intéresses au MVC qui est un pattern d'architecture contrairement à ceux cités qui sont de conception.

Tu remarqueras ne pas voir la couche Modele en fait imagine que dans boutonPresser() tu fasses

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Carte c = ControleurModele.TireCarte();

[akito]

Oki c'est ce que j'avais compris.

Je parlais bien d'evenement clique fenetre/bouton etc.

Donc les objets visuels (fenetre,bouton, plateau visuel etc.) font partie de Vue, l'évènement fait partie de Vue et appel le Controleur qui se charge d'appeler le Modele.

Je pense avoir une vue plus globale du MVC même si je suis loin d'en cerner toute les subtilités

Je vais essayé de faire de mon mieux avec tous ces elements

Encore merci pour le temps que tu m'as accordé.

[akito]

Alors j'ai essayé de réécrire les cas d'utilisation.

Pour le cas Jouer contre l'ordinateur je pense que ça va à peut près :

Cas d'utilisation «Jouer une partie contre l'ordinateur »

But : Le joueur essaye de trouver un maximum de paires de cartes contre l'ordinateur. Le gagnant est celui qui obtient le nombre le plus grand de paires.

Acteurs : Joueur

Pré conditions :


Opérations :
1. Le joueur lance une partie contre l'ordinateur
2. Le joueur choisi le niveau de difficulté
3. Le joueur choisi une première carte
4. Le joueur choisi une deuxième carte
5. Exécuter l'étape 3 tant que le joueur trouve une paire
6. L'ordinateur choisi une première carte
7. L'ordinateur choisi une deuxième carte
8. Exécuter l'étape 7 tant que l'ordinateur trouve une paire
9. Exécuter l'étape 4 tant qu'il a au moins une paire sur le plateau
10. Afficher le score

Ce cas d'utilisation se termine lorsque :
Le joueur à pris la dernière paire.
L'ordinateur à pris la dernière paire.
Le joueur quitte la partie.

----------------------------------------------------

Par contre, pour le cas Jouer une partie, je suis pas satisfait :

Cas d'utilisation «Jouer une partie»

But : Le joueur trouve les paires de cartes.

Acteurs : Joueur

Pré conditions :


Opérations :
1. Le joueur lance une partie
2. Le joueur choisi le niveau de difficulté
3. Le joueur choisi une première carte
4. Le joueur choisi une deuxième carte
5. Le joueur prend la pair de carte
6. Retourner à l'étape 3 jusqu'à qu'il n'y ait plus de paire sur le plateau
7. Afficher le score

Extensions :
1. Le joueur lance une partie à deux, créer deuxième joueur
6. Le joueur est-il seul?
6.1 Si oui, exécuter l'étape 3 pour le joueur
6.2 Si non, exécuter l'étape 3 pour le deuxième joueur

Ce cas d'utilisation se termine lorsque :
Le joueur à pris la dernière paire.
Le quitte la partie.
---------------------
Donc j'ai modifié les deux cas d'utilisation Jouer Seul et Jouer à Deux en un seul cas Jouer une partie comme tu me l'avais conseillé.

Mais je n'arrive pas à mettre en place le fait que si un joueur trouve une paire, alors il rejoue... Vue qu'il ne faut pas le mettre dans les extensions je vois pas comment le mettre.
Pour les extensions que j'ai mis, 1. et 6,. tu es d'accord ?

Merci par avance

[hegros]

Mais je n'arrive pas à mettre en place le fait que si un joueur trouve une paire, alors il rejoue... Vue qu'il ne faut pas le mettre dans les extensions je vois pas comment le mettre.

C'est ce que je t'ai montré juste avant et que tu as fais

Le joueur lance une partie contre l'ordinateur
2. Le joueur choisi le niveau de difficulté
3. Le joueur choisi une première carte
4. Le joueur choisi une deuxième carte
5. Exécuter l'étape 3 tant que le joueur trouve une paire

Cependant on ne numérote pas une boucle (le 5 n'a pas raison d'être) et on utilise une écriture en italique pour mieux le voir.

Pour les extensions que j'ai mis, 1. et 6,. tu es d'accord ?

Pour la 1 j'écrirais

1.a- C'est une partie à 2 joueurs
1.Le Système crée un deuxième joueur

Pour le 6 déja je reformule un peu le cas tu me diras si cela te convient

1. Le joueur lance une partie
2. Le joueur choisi le niveau de difficulté
3. Le joueur choisi une première carte
4. Le joueur choisi une deuxième carte
5. Le joueur prend la pair de carte
Le joueur continue à jouer tant qu'il trouve une pair
Retourner à l'étape 3 jusqu'à qu'il n'y ait plus de paire sur le plateau

[akito]

Mais je n'arrive pas à mettre en place le fait que si un joueur trouve une paire, alors il rejoue... Vue qu'il ne faut pas le mettre dans les extensions je vois pas comment le mettre.

C'est ce que je t'ai montré juste avant et que tu as fais

Non, en fait dans le cas "jouer une partie", je n'ai pas bouclé sur un joueur tant qu'il trouve des paires, mais seulement tant qu'il y en a sur le plateau.

La solution que tu proposes est intéressante :

1. Le joueur lance une partie
2. Le joueur choisi le niveau de difficulté
3. Le joueur choisi une première carte
4. Le joueur choisi une deuxième carte
5. Le joueur prend la pair de carte
Le joueur continue à jouer tant qu'il trouve une pair
Retourner à l'étape 3 jusqu'à qu'il n'y ait plus de paire sur le plateau

C'est bien la boucle sur le joueur faisant des paires, mais ça n'indique pas de passer au joueur 2 en cas d'échec.

Moi ça m'aurait paru plus clair (visuellement) de faire une extension comme je l'avais fais mais apparemment c'est pas bon puisque ce n'est pas un fonctionnement à part du programme mais juste une condition.

Même un petit jeu de carte, c'est pas simple a modéliser

Merci pour ton aide