Use Case Analysis for a Calculator and Recovery System

Ce document présente une série d’exercices d’analyse de cas d’utilisation dans différents contextes informatiques. Il s’agit d’évaluer la capacité à identifier acteurs et cas d’utilisation, à modéliser des diagrammes, et à décrire des scénarios fonctionnels en langage naturel.

Exercice n°1

Il s'agit d'analyser un système informatique de calculette/convertisseur à l’aide de diagrammes de cas d’utilisation.

1) Identifier les deux acteurs du système

Le système est une calculette/convertisseur. Les acteurs sont :

• Utilisateur : acteur principal qui utilise la calculette pour effectuer des opérations ou des conversions.
• Système externe (optionnel) : dans le cas de la conversion avec un cours de devise, il pourrait y avoir une source externe pour le cours, mais ce n’est pas explicitement mentionné. Ici, seul l’utilisateur est clairement un acteur.

Réponse : Les deux acteurs sont l’Utilisateur (principal) et éventuellement un acteur Système (secondaire) si on considère la saisie du cours de la devise.

2) Identifier trois cas d’utilisation

• Effectuer une opération arithmétique (addition, soustraction, multiplication, division)
• Convertir des francs en euros et des euros en francs
• Convertir un montant exprimé en euros en une autre devise selon un cours donné, et vice versa

Réponse : Les trois cas d’utilisation sont : Calculer, Convertir francs/euros, Convertir selon un cours de devise.

3) Représenter le diagramme de cas d’utilisation de la calculette

Le diagramme comporte un acteur unique "Utilisateur" lié aux trois cas d’utilisation identifiés :

• Calculer
• Convertir francs/euros
• Convertir selon un cours de devise

Les cas d’utilisation sont indépendants et directement accessibles par l’utilisateur.

4) Description textuelle des cas d’utilisation

Calcul simple : L’utilisateur saisit deux nombres et choisit une opération parmi addition, soustraction, multiplication ou division. La calculette effectue l’opération et affiche le résultat.

Conversion dans une monnaie quelconque : L’utilisateur saisit un montant en euros et indique le cours de la devise cible. La calculette calcule le montant équivalent dans la devise étrangère en multipliant ou divisant selon le sens de conversion, puis affiche le résultat.

Exercice n°2

Il s'agit d’analyser un système de récupération d’emballages (bouteilles et canettes) dans un magasin.

1) Identifier les acteurs du système et leur type

• Client : acteur principal, il dépose les articles et demande un reçu.
• Opérateur : acteur principal, il retire les articles en fin de journée et imprime le reçu global, ainsi que configure les paramètres.
• Système de récupération : acteur secondaire, il mesure, identifie, stocke les articles et imprime les reçus.

Réponse : Les acteurs sont Client (principal), Opérateur (principal), Système de récupération (secondaire).

2) Diagramme de cas d’utilisation avec au moins deux relations « include »

Cas d’utilisation principaux :

• Déposer un article
• Imprimer reçu client
• Retirer articles en fin de journée
• Imprimer reçu global
• Configurer paramètres

Relations « include » possibles :

• « Imprimer reçu client » inclut « Calculer total par type d’article »
• « Imprimer reçu global » inclut « Calculer total global de la journée »

Le client dépose des articles un par un. Le système mesure et identifie chaque article. Si accepté, il est comptabilisé. Sinon, il est mis en lumière jusqu’à retrait.

3) Description sommaire des scénarios pour chaque cas d’utilisation

• Déposer un article : Le client dépose un article, la machine le mesure et l’identifie. Si accepté, l’article est absorbé et comptabilisé, sinon il est mis en lumière.
• Imprimer reçu client : Le client appuie sur « Reçu », le système imprime un reçu détaillant les articles déposés, leur nombre, montant unitaire et total, ainsi que le total global.
• Retirer articles en fin de journée : L’opérateur appuie sur « Init », retire les articles, et le système imprime un reçu global récapitulant tous les dépôts de la journée.
• Configurer paramètres : L’opérateur modifie les caractéristiques des canettes et bouteilles acceptées par la machine.

Exercice n°3

Analyse d’une application de vote électronique « Sys_Vote » utilisée avant, pendant et après les élections.

1) Identifier les acteurs parmi la liste donnée

Nom	Type	Justification
Appareil	Secondaire	Objet technique utilisé par l’électeur, pas un acteur humain.
Administrateur	Principal	Gère la préparation des élections (ajout, modification des partis).
Serveur Central	Secondaire	Composant technique pour validation et stockage, pas un acteur humain.
Directeur Général Des Élections	Secondaire	Fournit les données, mais n’interagit pas directement avec le système.
Electeur	Principal	Utilise le système pour voter.
Partie Politique	Non acteur	Objet du vote, pas un acteur.
Employé	Principal	Vérifie l’identité des électeurs et remet les bulletins.
Bulletin	Non acteur	Objet manipulé, pas un acteur.
Lecteur De L’appareil De Vote	Secondaire	Composant technique, pas un acteur humain.
Horloge	Non acteur	Composant technique, pas un acteur.
Scrutateur	Principal	Utilise le système pour comptabiliser les votes après le scrutin.

2) Identifier les cas d’utilisation complémentaires parmi les actions proposées

Action	Justification	Retenu
Consulter liste des partis politiques	Permet à l’électeur de voir les options de vote.	Oui
S’identifier	Étape nécessaire avant de voter.	Oui
Compléter le bulletin	Action directe du vote.	Oui
Modifier les informations sur un parti politique	Fait partie de la gestion, pas du vote.	Non
Ajouter un nouveau parti politique	Gestion, pas vote.	Non
Récupérer le résultat du vote	Action post-vote pour les scrutateurs.	Oui
Accéder aux données globales	Permet d’obtenir les résultats globaux.	Oui
Enlever un parti politique existant	Gestion, pas vote.	Non

3) Diagramme partiel des cas d’utilisation

Acteurs : Electeur, Administrateur, Scrutateur

• Voter pour un parti politique (Electeur)
• Comptabiliser les votes (Scrutateur)
• Consulter liste des partis politiques (inclus dans voter pour un parti)
• S’identifier (inclus dans voter pour un parti)
• Récupérer le résultat du vote (inclus dans comptabiliser les votes)
• Accéder aux données globales (inclus dans comptabiliser les votes)

4) Cas d’utilisation « voter pour un parti politique »

a. Pré-condition : L’électeur doit être enregistré et son identité validée par le système.

b. Variantes de scénarios :

• Nominal : L’électeur s’identifie, consulte la liste des partis, choisit un parti, complète le bulletin, insère le bulletin dans le lecteur, le vote est enregistré et confirmé par un son.
• Alternatif : L’électeur change d’avis avant d’insérer le bulletin et modifie son choix, puis insère le bulletin et le vote est enregistré.
• Exceptionnel : La carte d’identité est invalidée (déjà utilisée), le système refuse le vote et bloque l’accès.

5) Cas d’utilisation « comptabiliser les votes »

• Nominal : Le scrutateur vérifie la correspondance des données locales et serveur, récupère les résultats par comté et parti, et les affiche.
• Alternatif : En cas de non-correspondance des données, une alerte est générée pour enquête avant la récupération des résultats.

Exercice n°4

Analyse d’une application ‘GestionChampionnat’ pour gérer un championnat d’échecs en ligne.

1) Identifier les acteurs parmi la liste donnée

Nom	Type	Justification
Administrateur	Principal	Gère la création des championnats, parties, et classements.
Calendrier	Non acteur	Objet de données, pas un acteur.
Câble Réseau	Non acteur	Composant technique, pas un acteur.
Coup	Non acteur	Action dans le jeu, pas un acteur.
Informaticien	Non acteur	Pas mentionné comme utilisateur du système.
Joueur	Principal	Participant au championnat, joue les parties.
Horloge	Non acteur	Composant technique pour la gestion du temps.
L’application ‘GestionChampionnat’	Non acteur	Objet étudié, pas un acteur.
Logiciel Graphique De Jeu D’échecs	Non acteur	Logiciel externe utilisé par le joueur, pas un acteur du système.
Participant	Principal	Synonyme de joueur, acteur principal.
Partie	Non acteur	Objet métier, pas un acteur.
Web	Non acteur	Support technique, pas un acteur.

2) Identifier les cas d’utilisation complémentaires parmi les actions proposées

Action	Justification	Retenu
Connaître les modalités concernant les parties	Permet aux joueurs de consulter les règles et horaires.	Oui
Connecter	Action technique, pas un cas d’utilisation métier.	Non
Consulter le planning des parties	Permet aux joueurs de voir leur calendrier.	Oui
Déconnecter	Action technique, pas un cas métier.	Non
Dérouler partie	Action du jeu, mais gestion hors application.	Non
Développer l’application ‘GestionChampionnat’	Activité de développement, pas un cas d’utilisation.	Non
Épuiser son temps	Condition de fin de partie, pas un cas d’utilisation.	Non
Gagner une partie	Résultat du jeu, pas un cas d’utilisation.	Non
Générer classement	Action réalisée par l’administrateur pour finaliser le championnat.	Oui
Jouer un coup	Action de jeu, hors application.	Non
Perdre une partie	Résultat du jeu, pas un cas d’utilisation.	Non
Récupérer identifiant	Action technique, pas un cas métier.	Non

3) Diagramme partiel des cas d’utilisation

Acteurs : Administrateur, Joueur (Participant)

• Créer un championnat (Administrateur)
• S’inscrire à un championnat (Joueur)
• Créer l’ensemble des parties du championnat (Administrateur)
• Consulter le planning des parties (Joueur) – inclus dans s’inscrire à un championnat
• Connaître les modalités concernant les parties (Joueur) – inclus dans s’inscrire à un championnat
• Générer classement (Administrateur) – inclus dans créer l’ensemble des parties ou en fin de championnat

4) Cas d’utilisation « s’inscrire à un championnat »

• Nominal : Le joueur s’identifie, choisit un championnat disponible, vérifie qu’il remplit les conditions (classement minimum, nombre de places), puis valide son inscription.
• Alternatif : Le joueur souhaite s’inscrire à plusieurs championnats, il répète la procédure pour chaque championnat.
• Exceptionnel : Le championnat est complet ou le joueur ne remplit pas les conditions, l’inscription est refusée et un message est affiché.

5) Cas d’utilisation « Créer l’ensemble des parties du Championnat »

a. Pré-condition : Le championnat doit avoir un nombre suffisant de joueurs inscrits.

b. Variantes de scénarios :

• Nominal : L’administrateur choisit un mode de répartition (ordre d’inscription, aléatoire, etc.), éventuellement ajoute des contraintes, puis le système génère automatiquement le calendrier complet des parties.
• Alternatif : L’administrateur modifie manuellement certaines parties ou contraintes après génération automatique avant validation finale.

Méthode

Ce type d’épreuve valorise la capacité à :

• Identifier clairement les acteurs en distinguant acteurs humains principaux et composants techniques secondaires.
• Extraire les cas d’utilisation pertinents en fonction des fonctions métier décrites, sans inclure d’éléments techniques ou objets métier comme acteurs.
• Représenter les diagrammes de cas d’utilisation en respectant les relations « include » ou « extend » lorsque des cas sont inclus dans d’autres.
• Décrire les scénarios en langage naturel, en distinguant les variantes nominales, alternatives et exceptionnelles, ce qui montre la compréhension des différentes situations possibles.
• Respecter les pré-conditions qui conditionnent le déclenchement des cas d’utilisation.

Les erreurs fréquentes pénalisées sont :

• Confondre acteurs et objets ou composants techniques.
• Omettre des cas d’utilisation essentiels ou inclure des actions techniques non métier.
• Ne pas expliciter les scénarios ou ne pas distinguer les variantes.
• Ne pas justifier les choix d’acteurs ou de cas d’utilisation.