Devoir à la maison n°1

Identification des acteurs

Dans la modélisation UML, un acteur représente toute entité externe (personne, système, équipement) qui interagit directement avec le système étudié.

Voici l'analyse pour chaque nom proposé. Les acteurs retenus sont marqués d'un [OUI], les autres d'un [NON] avec leur justification.

• a. Administrateur [OUI]
• b. Calendrier [NON]
  • Justification : Le calendrier est une information (ou un concept métier) produite et gérée par le système, et non une entité externe qui interagit avec lui.
• c. Câble Réseau [NON]
  • Justification : Il s'agit d'un élément d'infrastructure matérielle. Le réseau est le support de transmission, il est transparent pour la logique de l'application et n'est pas un acteur.
• d. Coup [NON]
  • Justification : Un coup est une donnée ou une action interne au déroulement d'une partie d'échecs, ce n'est pas un utilisateur du système.
• e. Informaticien [NON]
  • Justification : L'informaticien maintient ou développe le système, mais selon le texte, il n'utilise pas l'application dans son fonctionnement métier normal (contrairement à l'administrateur).
• f. Joueur [OUI]
• g. Horloge [NON]
  • Justification : Le texte précise que "La gestion du temps est à la charge de l'application". L'horloge est donc un mécanisme interne au système et non un équipement externe autonome.
• h. L'application ‘GestionChampionnat’ [NON]
  • Justification : C'est le système informatique étudié lui-même. Un système ne peut pas être acteur de lui-même.
• i. Logiciel Graphique De Jeu D’échecs [OUI]
  • (Note : Bien qu'il s'agisse d'un logiciel, le texte précise qu'il "ne fait pas partie de l'application en question". C'est donc un système externe qui interagit avec notre application).
• j. Participant [OUI]
  • (Note : Le participant et le joueur désignent la même personne physique à des étapes différentes du processus. Tous deux sont des acteurs valides).
• k. Partie [NON]
  • Justification : C'est une entité métier (une classe du domaine), pas un intervenant externe.
• l. Web [NON]
  • Justification : Le Web est une interface ou un canal de communication, pas un acteur qui initie des cas d'utilisation.

Identification des cas d'utilisation complémentaires

Un cas d'utilisation décrit une séquence d'actions qui apporte une valeur observable à un acteur.

• a. Connaître les modalités concernant les parties [NON]
  • Justification : C'est l'objectif global de l'action, mais "Consulter le planning des parties" décrit plus précisément l'interaction avec le système.
• b. Connecter [OUI]
  • Justification : Le texte indique "chaque joueur doit se connecter à la partie". Bien que technique, ce sous-cas d'utilisation peut être retenu car il sera inclus (<<include>>) systématiquement dans le déroulement d'une partie.
• c. Consulter le planning des parties [OUI]
  • Justification : C'est une fonctionnalité majeure et un objectif métier direct pour l'acteur Joueur via le web.
• d. Déconnecter [NON]
  • Justification : La déconnexion est une opération technique triviale qui n'apporte pas de valeur métier autonome justifiant un cas d'utilisation principal.
• e. Dérouler partie [OUI]
  • Justification : C'est le cœur du système. Les joueurs jouent et l'application gère le temps et enregistre les résultats.
• f. Développer l’application ‘GestionChampionnat’ [NON]
  • Justification : Action située hors du périmètre fonctionnel du système en production.
• g. Épuiser son temps [NON]
  • Justification : Ce n'est pas un cas d'utilisation, mais une règle de gestion ou l'issue d'un scénario alternatif au sein du cas d'utilisation "Dérouler partie".
• h. Gagner une partie [NON]
  • Justification : Il s'agit d'une post-condition ou du résultat de l'exécution d'une partie, pas d'une interaction que l'utilisateur peut initier à volonté.
• i. Générer classement [OUI]
  • Justification : Action spécifique et majeure déclenchée par l'administrateur en fin de championnat.
• j. Jouer un coup [NON]
  • Justification : Le texte précise explicitement que l'application ne gère pas les coups (ils sont joués sur le logiciel graphique externe).
• k. Perdre une partie [NON]
  • Justification : Résultat de la partie, au même titre que "Gagner".
• l. Récupérer identifiant [NON]
  • Justification : C'est une étape interne au scénario du cas d'utilisation "Connecter" ou "Dérouler partie", pas un cas d'utilisation autonome.

Diagramme de cas d'utilisation

Puisque nous représentons le diagramme sous format texte, voici les éléments qui le composent de manière structurée :

Acteurs présents :

• Administrateur
• Participant / Joueur (l'acteur Participant se généralise en Joueur une fois inscrit)

Cas d'utilisation principaux et associations :

• L'Administrateur est associé aux cas d'utilisation suivants :
  • Créer un championnat
  • Créer l'ensemble des parties du Championnat
  • Générer classement
• Le Participant / Joueur est associé aux cas d'utilisation suivants :
  • S'inscrire à un championnat
  • Consulter le planning des parties
  • Dérouler partie

Relations de dépendance (Stéréotypes) :

• <<include>> :
  • Le cas Dérouler partie contient un <<include>> vers le cas Connecter (car le texte impose : "chaque joueur doit se connecter à la partie").
• <<extend>> :
  • Nous pouvons introduire un cas Déclasser un joueur qui possède une relation <<extend>> vers Générer classement (car l'administrateur génère le classement automatiquement, mais peut, éventuellement, déclasser de manière semi-automatique des joueurs défaillants).
  • De même, un cas Ajouter des contraintes d'ordre possède une relation <<extend>> vers Créer l'ensemble des parties du Championnat (car l'ajout de contraintes est une possibilité "éventuelle" mentionnée dans le texte).

Scénarios pour "S'inscrire à un championnat"

Voici trois scénarios détaillant ce cas d'utilisation du point de vue du participant.

Scénario Nominal :
Le participant consulte la liste des championnats ouverts. Il sélectionne un championnat pour lequel il possède le classement minimum requis (par exemple, 1500). Il valide son inscription. Le système enregistre l'inscription du participant à ce championnat et confirme l'opération.

Scénario Alternatif :
Le participant sélectionne un championnat, mais s'aperçoit qu'il souhaite modifier ses préférences de participation (matin ou après-midi) avant de finaliser. Il modifie ses paramètres de disponibilité dans son profil, puis revient sur la page du championnat et valide avec succès son inscription.

Scénario Exceptionnel :
Le participant tente de s'inscrire à un championnat d'élite (ex : classement minimum requis 2400). Le système vérifie le classement actuel du participant et constate qu'il est inférieur au prérequis (ex : 1800). Le système refuse l'inscription, affiche un message d'erreur expliquant que le niveau est insuffisant, et annule l'opération.

Scénarios pour "Créer l’ensemble des parties du Championnat"

Pré-condition :
Il y a suffisamment de joueurs inscrits au championnat (le quota minimum ou la limite fixée par l'administrateur a été atteinte).

Variantes de scénarios :

Scénario Nominal :
L'administrateur sélectionne un championnat dont les inscriptions sont closes. Il choisit un mode de répartition standard pour les parties (par exemple, de manière aléatoire). Il valide la création. Le système génère automatiquement le calendrier complet des parties (n × (n - 1) ÷ 2 parties), s'assure qu'aucun joueur ne joue plus d'une partie par jour, et enregistre le calendrier complet.

Scénario Alternatif :
L'administrateur sélectionne le championnat et choisit le mode de répartition par ordre d'inscription. Avant de générer le calendrier, il décide d'ajouter des contraintes manuelles pour forcer l'ordre de certaines parties (par exemple, programmer la partie entre les deux favoris à la dernière date). Il saisit ces contraintes. Le système prend en compte ces exigences, génère le reste du calendrier autour de ces contraintes sans violer la règle d'une partie par jour et par joueur, et enregistre le planning.

Méthode

Pour aborder efficacement un exercice d'analyse UML basé sur un cahier des charges textuel :

1. Traque des substantifs et des verbes : Dès la première lecture, soulignez les noms (candidats pour les classes ou les acteurs) et les verbes d'action (candidats pour les cas d'utilisation).
2. Test d'externalité pour les acteurs : Posez-vous toujours la question "Est-ce que cette entité est à l'extérieur du système informatique que je suis en train de concevoir ?". Si la réponse est non (comme pour l'horloge ou le calendrier), ce n'est pas un acteur, mais un composant interne.
3. Test de la valeur métier pour les cas d'utilisation : Un cas d'utilisation n'est pas une simple fonction technique (comme "Cliquer sur un bouton"). Il doit correspondre à une intention réelle de l'utilisateur ("S'inscrire", "Générer un classement").
4. Justification par le texte : Ne supposez jamais le fonctionnement de l'application. Si le texte stipule que "l'application ne prend pas en considération le risque de parallélisme", aucune exception ne doit être créée pour gérer les conflits d'horaires inter-championnats. Vos justifications doivent toujours s'appuyer sur des citations directes ou déductions logiques des règles énoncées.