Série N°1 – Diagramme de cas d’utilisation

Exercice 1 : GAB (Guichet Automatique de Banque)

Question 1 - Identification des acteurs

Un acteur représente un rôle joué par une entité externe (humain, matériel ou un autre système) qui interagit directement avec le système étudié. En lisant l'énoncé, on identifie :

• Porteur de carte : Acteur principal. Il représente toute personne insérant une carte pour retirer de l'argent.
• Client de la banque (Possesseur d'une carte de la banque) : Acteur principal. Il s'agit d'un porteur de carte spécifique qui a accès à des fonctionnalités supplémentaires (solde, dépôt). Il hérite de l'acteur « Porteur de carte ».
• Maintenancier (ou Opérateur) : Acteur principal responsable du rechargement et des opérations de maintenance.
• Système d'autorisation (ou Puce) : Acteur secondaire (système externe). L'énoncé précise que le code est « vérifié avec le code enregistré sur la puce ». Bien que la puce soit physiquement sur la carte, du point de vue du système du GAB, c'est une entité externe interrogée pour valider la transaction.

Question 2 - Identification des cas d'utilisation

Les cas d'utilisation représentent les fonctionnalités offertes par le système à ses acteurs :

• Retirer de l'argent (accessible à tout porteur).
• Consulter le solde (accessible au client de la banque).
• Déposer du numéraire (accessible au client de la banque).
• Déposer des chèques (accessible au client de la banque).
• S'authentifier (cas inclus systématiquement dans toutes les transactions sécurisées).
• Recharger le GAB (accessible au maintenancier).
• Effectuer la maintenance (accessible au maintenancier).

Question 3 - Représentation du diagramme de cas d'utilisation

Note : La restitution d'un diagramme UML se fait ici sous forme de description textuelle structurée.

Acteurs et leurs associations aux cas :

• Porteur de carte est associé à :
  • « Retirer de l'argent »
• Client de la banque (hérite de Porteur de carte) est associé à :
  • « Consulter le solde »
  • « Déposer du numéraire »
  • « Déposer des chèques »
• Maintenancier est associé à :
  • « Recharger le GAB »
  • « Effectuer la maintenance »
• Puce (Système d'autorisation) est associé à :
  • « S'authentifier »

Relations entre les cas d'utilisation :

• « Retirer de l'argent » << include >> « S'authentifier »
• « Consulter le solde » << include >> « S'authentifier »
• « Déposer du numéraire » << include >> « S'authentifier »
• « Déposer des chèques » << include >> « S'authentifier »

Exercice 2 : Calculette et Convertisseur

Question 1 - Identification des deux acteurs

L'énoncé demande explicitement deux acteurs :

1. Utilisateur : Acteur principal, qui manipule la calculette pour faire des opérations ou des conversions.
2. Fournisseur de cours de devise (ou Horloge/Serveur financier) : Acteur secondaire. L'énoncé précise « en indiquant le cours d'une devise, elle permet de convertir ». Bien que l'utilisateur puisse le saisir manuellement, dans un SI moderne de convertisseur, ce cours est souvent fourni par un système externe. Si l'on considère que c'est l'utilisateur qui saisit le taux, le second acteur n'existe pas physiquement dans l'énoncé. Toutefois, la question exigeant deux acteurs, la modélisation la plus rigoureuse d'un SI est d'identifier le Système de Bourse / Taux de change comme acteur secondaire fournissant les données de conversion.

Question 2 - Identification de trois cas d'utilisation

1. Effectuer une opération arithmétique (addition, soustraction, multiplication, division).
2. Convertir des Francs en Euros (et vice-versa).
3. Convertir une devise étrangère (nécessite l'indication du cours).

Question 3 - Diagramme de cas d'utilisation

Associations :

• Utilisateur interagit avec :
  • « Effectuer une opération arithmétique »
  • « Convertir Francs/Euros »
  • « Convertir devise étrangère »
• Fournisseur de cours de devise interagit avec :
  • « Convertir devise étrangère » (lui fournit le taux)

Question 4 - Description textuelle du cas « Effectuer un calcul simple »

• Titre : Effectuer une opération arithmétique
• Acteur principal : Utilisateur
• Pré-condition : La calculette est allumée et prête à l'emploi.
• Scénario nominal :
  1. L'utilisateur saisit un premier nombre.
  2. Le système affiche ce nombre.
  3. L'utilisateur sélectionne un opérateur (+, -, ×, ÷).
  4. Le système mémorise l'opérateur.
  5. L'utilisateur saisit un second nombre.
  6. L'utilisateur valide l'opération (touche =).
  7. Le système calcule et affiche le résultat de l'opération.
• Post-condition : Le résultat est affiché à l'écran.
• Scénario d'exception : Si l'utilisateur tente une division par zéro à l'étape 6, le système affiche un message d'erreur (ex: « Erreur » ou « Infini ») et annule le calcul.

Exercice 3 : Système d'Information d'un libraire

Question 1 - Identification des acteurs

• Libraire : Acteur principal. C'est lui qui interagit directement avec le logiciel (il fait lire le code, édite la facture, lance l'état des stocks, saisit les informations client). Attention : le Client physique n'interagit pas avec le clavier ou l'écran du système de la boutique, il n'est donc pas un acteur du SI, c'est le Libraire qui agit pour lui.
• Lecteur optique (Code-barres) : Acteur secondaire. Il transmet automatiquement la référence de l'article au système.
• Fournisseur : Acteur secondaire. Il est le destinataire des commandes et des relances générées par le système.
• Système de messagerie (Serveur Mail) : Acteur secondaire (optionnel mais recommandé). Utilisé par le SI pour relancer le fournisseur ou prévenir le client par mail.

Question 2 - Diagramme de cas d'utilisation

Acteurs et associations :

• Libraire est associé à :
  • « Enregistrer un achat »
  • « Gérer une commande client »
  • « Éditer une facture »
  • « Éditer un bon de livraison »
  • « Lancer un état du stock »
  • « Commander auprès du fournisseur »
• Lecteur optique est associé à :
  • « Enregistrer un achat » (fournit le code)
• Fournisseur est associé à :
  • « Commander auprès du fournisseur »
  • « Relancer fournisseur »

Relations entre les cas :

• « Enregistrer un achat » << include >> « Décrémenter le stock »
• « Gérer une commande client » << include >> « Éditer une facture »
• « Éditer une facture » << include >> « Saisir les informations client » (le texte précise que pour l'édition, le client donne son nom et le libraire saisit l'information).
• « Lancer un état du stock » peut être étendu par « Commander auprès du fournisseur » : « Commander auprès du fournisseur » << extend >> « Lancer un état du stock » (condition : quantité < stock minimum).
• « Relancer fournisseur » << extend >> « Commander auprès du fournisseur » (condition : pas de livraison dans les 3 jours).

Exercice 4 : Site web gastronomique

Question 1 - Identification des acteurs

• Consommateur : Acteur principal. Il navigue librement pour consulter les informations.
• Consommateur inscrit : Acteur principal. Il hérite de « Consommateur » et possède des droits étendus (évaluer, réserver).
• Restaurateur : Acteur principal. Il s'inscrit, propose des restaurants et valide les réservations.
• Équipe de rédaction : Acteur principal. Valide l'ajout des restaurants.
• Serveur de messagerie (Mail) : Acteur secondaire. Chargé d'envoyer la confirmation de réservation au client de façon asynchrone.

Question 2 - Diagramme de cas d'utilisation (Contraintes spécifiques)

Contraintes à respecter : max 9 cas, 2 includes, 1 héritage, 1 extend.

Acteurs et Héritage (1 relation d'héritage) :

• L'acteur Consommateur inscrit hérite de l'acteur Consommateur.

Cas d'utilisation (9 maximum) :

1. Consulter les informations (Consommateur)
2. S'inscrire sur le site (Consommateur, Restaurateur)
3. S'authentifier / Se connecter (Consommateur inscrit, Restaurateur)
4. Évaluer un restaurant (Consommateur inscrit)
5. Demander une réservation de table (Consommateur inscrit)
6. Gérer les réservations / Valider (Restaurateur)
7. Proposer un restaurant (Restaurateur)
8. Accepter un restaurant (Équipe de rédaction)
9. Visiter le restaurant (Équipe de rédaction)

Relations entre les cas :

• Include 1 : « Évaluer un restaurant » << include >> « S'authentifier »
• Include 2 : « Demander une réservation de table » << include >> « S'authentifier »
• Extend 1 : « Visiter le restaurant » << extend >> « Accepter un restaurant » (Condition d'extension : le restaurant proposé paraît suspect).

Question 3 - Scénarios pour « Demander une réservation de table »

• Scénario Nominal : Réservation validée
  1. Le consommateur inscrit s'authentifie et sélectionne un restaurant.
  2. Il remplit le formulaire de réservation (date, heure, nombre de personnes) et valide.
  3. Le système transmet la demande au restaurateur.
  4. Le restaurateur consulte la demande et la confirme.
  5. Le composant de gestion enregistre la réservation dans la base de données.
  6. Le système demande au serveur de messagerie d'envoyer un e-mail de confirmation au client.
• Scénario Exceptionnel : Réservation refusée/annulée par le restaurateur
  1. Le consommateur inscrit s'authentifie et valide sa demande de réservation.
  2. Le système transmet la demande.
  3. Le restaurateur consulte la demande, constate un manque de place et choisit de l'annuler.
  4. Le système supprime la demande en cours et notifie le client de l'annulation (affichage ou mail de refus), la réservation n'est pas enregistrée.

Exercice 5 : Logiciel de gestion des réparations

Question 1 - Modélisation pour le cas « Créer une fiche de réparation »

a. Les autres acteurs et leurs types :

• Magasinier : Acteur principal. Saisit les pièces fournies, modifie les états de commande.
• Logiciel de gestion des commandes : Acteur secondaire. Reçoit les requêtes de commandes de pièces.
• Logiciel comptable : Acteur secondaire. Importe les fiches de réparation fermées. (Note : Les mécaniciens n'interagissent pas avec le logiciel, ils ne sont donc pas des acteurs du SI. L'assurance est ici traitée comme une simple liste de données interne, pas comme un acteur externe).

b. Quatre autres cas d'utilisation :

1. Gérer les pièces de rechange (Saisir pièces fournies / Changer mention)
2. Commander une pièce manquante
3. Fermer une fiche de réparation
4. Importer les fiches fermées (ou Exporter vers la comptabilité)

c. Relations :

• Chef d'atelier communique avec « Créer une fiche de réparation » et « Fermer une fiche de réparation ».
• Magasinier communique avec « Gérer les pièces de rechange » et « Commander une pièce manquante ».
• Logiciel de gestion des commandes communique avec « Commander une pièce manquante ».
• Logiciel comptable communique avec « Importer les fiches fermées ».
• Dépendances entre cas : « Créer une fiche de réparation » << include >> « Rechercher une voiture » (si l'on veut détailler le processus interne décrit dans l'énoncé).

Question 2 - Description du cas « Créer une fiche de réparation »

• Titre : Créer une fiche de réparation
• Acteur principal : Chef d'atelier
• Scénario nominal :
  1. Le chef d'atelier demande la création d'une fiche.
  2. Le système lui demande des critères de recherche de voiture.
  3. Le chef saisit les critères.
  4. Le système affiche la liste des véhicules correspondants.
  5. Le chef sélectionne la voiture existante.
  6. Le système fournit les informations du véhicule.
  7. Le chef saisit la date de réception et la date de restitution prévue.
  8. Le chef saisit le travail à effectuer par les employés.
  9. Le système enregistre la fiche de réparation.
• Scénarios alternatifs :
  • Alternative A (Voiture non existante) : À l'étape 4, la voiture n'est pas trouvée. Le chef saisit les informations du nouveau véhicule. Le scénario reprend à l'étape 7.
  • Alternative B (Voiture sous garantie) : Après l'étape 6, si la voiture est sous garantie, le chef doit obligatoirement saisir la date de demande de réparation.
  • Alternative C (Dommage payé par assurance) : À l'étape 8, le chef indique une prise en charge par assurance. Le système fournit la liste des assurances. Le chef en sélectionne une. Le scénario reprend à l'étape 9.

Exercice 6 : Application ‘gestion_cours_en_ligne’

Question 1 - Justification des acteurs

Noms	Type	Justifications
a. Administrateur	Acteur principal	Interagit avec le système pour gérer les cours et les utilisateurs.
b. Horloge	Non acteur	Composant interne. L'énoncé indique « l'application gère de manière interne une horloge ».
c. email	Acteur secondaire	C'est le système de messagerie externe qui distribue les mails.
d. Cours	Non acteur	C'est un objet/concept métier manipulé par le système, pas une entité active.
e. test	Non acteur	Concept métier manipulé, au même titre que le cours.
f. Informaticien	Non acteur	N'est pas mentionné dans l'énoncé du problème.
g. Intervenant	Non acteur (ou abstrait)	L'énoncé parle explicitement d'Enseignant et d'Étudiant. Le terme Intervenant n'apparaît pas.
h. L'application...	Non acteur	C'est le système informatique lui-même (la frontière de l'étude).
i. Enseignant	Acteur principal	Interagit pour déposer documents, QCM et notes.
j. Web	Non acteur	C'est l'interface de communication (le réseau), pas une entité fonctionnelle.
k. Etudiant	Acteur principal	Interagit pour consulter, déposer et passer des tests.

Question 2 - Complétion du diagramme

a. Choix de 4 autres cas d'utilisation pertinents :

1. Supprimer un cours
2. Retirer un étudiant
3. Quitter le test
4. Reprendre le test

b. Acteurs et liaisons :

• Administrateur est lié à : « Inscrire étudiant », « Supprimer un cours ».
• Enseignant est lié à : « Déposer un document », « S'identifier ».
• Étudiant est lié à : « Passer un test », « S'identifier ».

c. Liaisons (include / extend) :

• « Passer un test » << include >> « S'identifier »
• « Déposer un document » << include >> « S'identifier »
• « Supprimer un cours » << include >> « Retirer un étudiant » (L'énoncé dit : « quand il supprime un cours, il doit aussi retirer tous les étudiants »).
• « Quitter le test » << extend >> « Passer un test »
• « Reprendre le test » << extend >> « Passer un test »

Question 3 - Cas d'utilisation « Passer un test »

a. Pré-condition : L'étudiant s'est authentifié sur l'application et l'heure actuelle correspond à la période horaire fixée par l'enseignant pour ce test. b. Post-condition : Le test est clôturé (soit corrigé automatiquement et stocké dans la BDD, soit marqué pour correction manuelle), et l'étudiant ne peut plus y accéder de nouveau de façon vierge. c. Acteurs principaux : Étudiant (et secondairement l'email pour l'alerte de sortie prématurée). d. Scénarios :

• Scénario Nominal (Réussite) : L'étudiant démarre le test. Il répond successivement à toutes les questions présentées avant la fin du chronomètre. Il valide son test. Le système corrige automatiquement les réponses grâce aux choix de l'enseignant et enregistre la note dans la base de données.
• Scénario Alternatif 1 (Abandon définitif) : L'étudiant choisit de quitter le test en cours de route. Le système le déconnecte immédiatement et envoie un e-mail automatique à l'enseignant listant les réponses partielles. L'étudiant ne se reconnecte pas dans l'heure. Le test est clôturé et marqué pour une correction manuelle.
• Scénario Alternatif 2 (Reprise avec succès) : L'étudiant quitte le test en cours (ce qui déclenche la déconnexion et l'e-mail). Toutefois, l'étudiant se reconnecte à l'application et demande à reprendre le test avant l'écoulement d'une heure. Le système lui restitue le test dans l'état précédent. L'étudiant termine de répondre à toutes les questions et valide. Le système procède à la correction automatique.

Méthode

Face à un sujet de conception UML orienté Cas d'Utilisation, la rigueur repose sur la capacité à ne modéliser que ce que contient l'énoncé, sans surinterpréter le monde réel :

1. Distinguer le Métier du Système : Le piège le plus fréquent consiste à confondre un rôle de l'entreprise (ex: le client qui achète un livre physiquement) et un acteur du Système d'Information. Ne retenez comme acteurs que les entités qui interagissent directement avec la frontière du logiciel (clavier, écran, flux de données).
2. Repérer les mots-clés d'inclusion et d'extension :
   • Si le texte dit « nécessite », « doit absolument » ou « systématiquement », c'est une relation << include >>.
   • Si le texte dit « peut », « dans le cas où », « si (condition) », c'est une relation << extend >>.
3. Les scénarios justifient le diagramme : La description textuelle n'est pas un résumé vague. C'est un algorithme métier étape par étape. Chaque scénario alternatif (condition d'échec ou bifurcation) doit trouver son origine dans une phrase de l'énoncé. Ne modélisez pas des exceptions que le texte ignore.