Gestion de Championnat d'Échecs

Identification des acteurs

Pour identifier les acteurs d'un système en UML, il faut rechercher les entités externes (personnes, autres systèmes, matériels) qui interagissent directement avec l'application.

À partir de la liste fournie et du texte, voici les acteurs retenus :

• a. Administrateur : Personne responsable de la gestion (création des championnats, génération des parties et des classements).
• f. Joueur : Personne qui joue les parties et consulte le calendrier.
• i. Logiciel Graphique De Jeu D'échecs : Le texte précise explicitement qu'il s'agit d'un logiciel « ne faisant pas partie de l'application en question » et qui interagit avec elle lors d'une connexion à une partie. C'est donc un acteur externe (système).
• j. Participant : Personne s'inscrivant sur le web pour devenir membre. Il est possible de considérer que « Joueur » est une spécialisation de « Participant ».

Les éléments non retenus et leurs justifications, telles que définies dans le corrigé de la source :

• h. L'application 'GestionChampionnat' : C'est le système informatique lui-même que l'on modélise. Un système n'est jamais son propre acteur.
• b, c, d, e, g, k et l (Calendrier, Câble Réseau, Coup, Informaticien, Horloge, Partie, Web) : Ces éléments ne sont pas des acteurs de l'application. Ils ne renferment aucun rôle et ne participent à aucun service. Ce sont soit des objets internes au système (Calendrier, Partie, Coup), soit des moyens de communication (Web, Câble Réseau), soit des éléments temporels gérés en interne (Horloge), soit des personnes hors du périmètre d'utilisation directe défini par le sujet (Informaticien).

Identification des cas d'utilisation

Un cas d'utilisation représente un service rendu par le système à l'un de ses acteurs. Sur la base du texte et des fonctionnalités attendues, voici l'analyse de la liste d'actions proposée :

Cas d'utilisation principaux retenus :

• c. Consulter le planning des parties
• e. Dérouler partie
• i. Générer classement

Justification : Ces trois actions représentent des cas d'utilisation complémentaires aux trois déjà fournis. En effet, ils représentent les fonctionnalités de base de l'application regroupant un ensemble de scénarios.

Cas d'utilisation de type inclusion (stéréotype <<include>>) :

• b. Connecter
• d. Déconnecter

Justification : Ce sont des cas d'utilisation encapsulant un comportement complexe. Ils sont exécutés de manière obligatoire au sein du déroulement d'une partie.

Cas d'utilisation de type extension (stéréotype <<extend>>) :

• h. Gagner une partie
• k. Perdre une partie

Justification : Ce sont des cas d'utilisation qui ne sont pas nécessairement exécutés, représentant des scénarios secondaires complexes lors du déroulement d'une partie (tout dépend de l'issue de celle-ci ou de l'épuisement du temps).

Note sur les autres actions : « Connaître les modalités » (a) est redondant avec la consultation du planning. « Développer l'application » (f) est hors contexte. « Épuiser son temps » (g), « Jouer un coup » (j) et « Récupérer identifiant » (l) sont de simples étapes à l'intérieur des scénarios des cas d'utilisation principaux, et non des cas d'utilisation à part entière.

Diagramme de cas d'utilisation

Voici la modélisation en langage PlantUML regroupant les acteurs et les cas d'utilisation identifiés aux questions 1 et 2. Le code ci-dessous est valide et peut être exécuté dans n'importe quel générateur PlantUML.

@startuml
left to right direction

actor Administrateur
actor Participant
actor Joueur
actor "Logiciel Graphique\nDe Jeu D'échecs" as Logiciel

Participant <|-- Joueur : "s'inscrit comme"

package GestionChampionnat {
    usecase "Créer un championnat" as UC1
    usecase "S'inscrire à un championnat" as UC2
    usecase "Créer l'ensemble des parties\ndu Championnat" as UC3
    usecase "Consulter le planning\ndes parties" as UC4
    usecase "Dérouler partie" as UC5
    usecase "Générer classement" as UC6
    
    usecase "Connecter" as UC7
    usecase "Déconnecter" as UC8
    usecase "Gagner une partie" as UC9
    usecase "Perdre une partie" as UC10

    Administrateur --> UC1
    Administrateur --> UC3
    Administrateur --> UC6

    Participant --> UC2
    Joueur --> UC4
    Joueur --> UC5
    
    Logiciel --> UC5

    UC5 ..> UC7 : <<include>>
    UC5 ..> UC8 : <<include>>
    
    UC9 .> UC5 : <<extend>>
    UC10 .> UC5 : <<extend>>
}
@enduml

Scénarios pour s'inscrire à un championnat

Un cas d'utilisation se décline en plusieurs scénarios. Le scénario nominal décrit le déroulement normal et sans erreur, tandis que les scénarios alternatifs et exceptionnels gèrent des situations différentes ou des cas d'erreur.

Scénario Nominal :
Un joueur non inscrit à des championnats, choisit un championnat pour lequel il vérifie la condition du classement et s'y inscrit.

Scénario Alternatif :
Un joueur déjà inscrit à d'autres championnats s'inscrit à un championnat (pour lequel il vérifie la condition de classement).

Scénario Exceptionnel :
Un joueur s'inscrit à un championnat qui démarre en même temps qu'un championnat auquel il est déjà inscrit. (Bien que le texte indique que l'application ne prend pas en considération le risque de parallélisme, la détection de cette situation lors de l'inscription constitue un cas d'exception classique dans le flux).

Créer l'ensemble des parties du Championnat

Pré-condition

Une pré-condition est un état du système qui doit obligatoirement être vrai avant le déclenchement du cas d'utilisation. Pour ce cas précis, la pré-condition est : Championnat existant avec suffisamment de joueurs inscrits.

Variantes de scénarios

Scénario Nominal :

1. L'administrateur choisit un championnat.
2. L'application demande le mode de répartition des parties.
3. L'administrateur choisit le mode de répartition en fonction de l'ordre d'inscription des joueurs.
4. L'application demande s'il y a ajout de contraintes.
5. L'administrateur n'ajoute pas de contraintes.
6. L'application génère l'ensemble des parties. (Il y aura n×(n-1)÷2 parties générées, n étant le nombre de joueurs).
7. L'application génère le calendrier complet du championnat.

Scénario Alternatif (Proposition 1 - Répartition aléatoire) :
Les étapes 1 et 2 sont identiques au scénario nominal.
3.1. L'administrateur choisit le mode de répartition de manière aléatoire.
4. L'application demande s'il y a ajout de contraintes.
5. L'administrateur n'ajoute pas de contraintes pour forcer l'ordre des parties.
6. L'application génère l'ensemble des parties.
7. L'application génère le calendrier complet du championnat.

Scénario Alternatif (Proposition 2 - Ajout de contraintes) :
Les étapes 1 à 4 sont identiques au scénario nominal ou à la proposition 1.
5.1. L'administrateur ajoute des contraintes pour forcer l'ordre des parties.
6. L'application génère l'ensemble des parties. (L'étape de la source numérotée « 5. L'application génère... » correspond bien à la suite logique après l'action 5.1).
7. L'application génère le calendrier complet du championnat.

Méthode

Pour réussir ce type de sujet en modélisation UML (diagramme de cas d'utilisation) :

1. Souligner les noms et les verbes : À la lecture du cahier des charges, soulignez les noms représentant des personnes, des rôles ou des systèmes externes pour trouver les acteurs. Soulignez les verbes d'action pour identifier les cas d'utilisation.
2. Filtrer rigoureusement : Un acteur n'est jamais le système lui-même, ni une donnée passive (comme une partie, un coup, ou un calendrier). C'est une entité active qui donne ou reçoit des informations du système. Un acteur peut tout à fait être un logiciel externe.
3. Structurer les relations : Utilisez <<include>> uniquement pour les sous-fonctions obligatoires ou communes à plusieurs cas (comme s'authentifier/se connecter). Utilisez <<extend>> pour les comportements optionnels, les cas particuliers ou les issues conditionnelles (comme gagner, perdre, ou une erreur de saisie).
4. Détailler les scénarios de bout en bout : Ne confondez pas un cas d'utilisation global (ex: « S'inscrire ») avec ses étapes internes (ex: « Cliquer sur valider »). Les descriptions textuelles des scénarios doivent faire apparaître un dialogue clair : « L'utilisateur fait X », « Le système répond Y ».