Corrigé Série N°1 –Use case

Exercice n°1 - Analyse d'un diagramme de l'agence de voyage

Dans cet exercice, il vous est demandé de faire la critique d'un diagramme de cas d'utilisation existant, afin de relever les défauts de modélisation.

Question 1 - Commentaires sur les acteurs

L’acteur Client représente les clients de l’agence et l’acteur Voyageur représente les voyageurs physiques. L'erreur principale du diagramme initial est la relation d'héritage entre ces deux acteurs. Comme il s’agit d’entités externes à l’application, rien ne garantit qu’un voyageur soit obligatoirement un client de l’agence (il peut s'agir d'un enfant accompagnant ses parents, par exemple). Ainsi, même si certains voyageurs peuvent être clients de l’agence, il ne faut pas mettre de relation d’héritage entre ces deux classes.

Question 2 - Commentaires sur les cas d'utilisation

Plusieurs points sont à corriger dans les cas d'utilisation présentés :

1. Le périmètre du système : Le diagramme initial laisse croire que c’est l’agence de voyage qui s’occupe de la réalisation du voyage (cas "Faire voyage"), ce qui n’est généralement pas le cas. L’agence se charge normalement de vendre des voyages réalisés par d’autres prestataires. Il n’est dès lors pas souhaitable d’associer ce cas d’utilisation à l’application "agence de voyage". Ce cas doit être supprimé, ce qui entraîne également la suppression de l’acteur Voyageur (qui n’est plus relié à aucun cas d’utilisation).
2. Le niveau de détail (besoin vs conception) : Un diagramme de cas d'utilisation doit décrire les fonctionnalités de l’application au niveau du besoin (quels services rend le système ?) sans donner d'information sur la façon dont ces fonctionnalités sont réalisées (comment les services sont rendus ?).
   • Les relations d’inclusion (<<include>>) vers "Annuler Reservation" et "Payer Voyage" depuis "Reserver Voyage" représentent une découpe fonctionnelle interne. Ces informations relèvent du niveau conceptuel et n'ont rien à faire dans le diagramme initial des besoins.
   • Il en va de même des relations d’inclusion entre "Payer Voyage" et le détail des moyens de paiement ("Donner Cheque" et "Donner CB").
3. L'utilisation de la relation d'extension : La relation d’extension (<<extend>>) représente l’ajout d’une fonctionnalité non prévue initialement ou conditionnelle. Dans le cas du "Paiement Web", cette extension n’est pas justifiée. Il ne s'agit pas d'une extension de comportement conditionnelle, mais simplement d'un troisième moyen de paiement, qui n'a pas davantage sa place ici que les chèques ou la carte bancaire.

En résumé, l’application doit offrir au client quatre cas d'utilisation fondamentaux : Faire une réservation, Payer une réservation, Annuler une réservation et Obtenir un devis.

Exercice n°2 - Guichet Automatique de Banque (GAB)

Question 1 - Identification des acteurs

Les acteurs sont les entités externes qui interagissent directement avec le GAB. D'après l'énoncé, nous pouvons identifier :

• Porteur de carte de la banque : Utilisateur principal disposant d'un compte dans cette banque.
• Porteur de carte VISA : Utilisateur disposant d'une carte d'une autre institution.
• Système d'Information de la banque : Acteur système externe sollicité pour les autorisations des clients de la banque.
• Système d'Autorisation VISA : Acteur système externe sollicité pour les autorisations des porteurs VISA.
• Opérateur de maintenance : Personne chargée de recharger le GAB et d'effectuer la maintenance.

Note pédagogique : On peut regrouper les deux types de porteurs sous un acteur abstrait "Client GAB" pour simplifier le diagramme.

Question 2 - Identification des cas d'utilisation

Les services rendus par le système sont :

• Retirer de l'argent (accessible à tous les porteurs).
• Consulter le solde (réservé aux porteurs de la banque).
• Déposer du numéraire (réservé aux porteurs de la banque).
• Déposer des chèques (réservé aux porteurs de la banque).
• S'authentifier (cas d'utilisation inclus systématiquement dans toutes les transactions bancaires pour vérifier le code PIN).
• Recharger le GAB (pour l'opérateur).
• Effectuer la maintenance (pour l'opérateur).

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

L'énoncé demande un diagramme visuel. N'ayant pas de capacité de dessin matriciel, voici la traduction textuelle exacte de la structure du diagramme attendu :

Relations Acteurs -> Cas d'utilisation :

• Le Porteur de carte de la banque est associé à : Retirer de l'argent, Consulter le solde, Déposer du numéraire, Déposer des chèques.
• Le Porteur de carte VISA est associé à : Retirer de l'argent.
• L'Opérateur de maintenance est associé à : Recharger le GAB, Effectuer la maintenance.
• Le cas "Retirer de l'argent" est associé aux acteurs secondaires : Système d'Information de la banque et Système d'Autorisation VISA.

Relations entre cas d'utilisation :

• Tous les cas d'utilisation transactionnels (Retirer de l'argent, Consulter le solde, Déposer du numéraire, Déposer des chèques) pointent vers le cas S'authentifier avec une relation <<include>>.

Exercice n°3 - Calculette et convertisseur

Question 1 - Identification des deux acteurs du système

D'après le texte, l'application est utilisée par un être humain et nécessite l'indication d'un cours de devise pour certaines opérations. Les deux acteurs sont donc :

• L'utilisateur : Celui qui manipule la calculette.
• Le fournisseur de taux de change : L'entité (système externe ou utilisateur effectuant une action de paramétrage spécifique) qui fournit le cours de la devise.

Question 2 - Identification de trois cas d'utilisation

1. Effectuer une opération arithmétique (addition, soustraction, multiplication, division).
2. Convertir Francs/Euros (conversion à taux fixe interne).
3. Convertir selon une devise (conversion à taux variable nécessitant le cours).

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

Structure du diagramme :

• Utilisateur est relié à : Effectuer une opération arithmétique, Convertir Francs/Euros, Convertir selon une devise.
• Fournisseur de taux de change est relié à : Convertir selon une devise.

Question 4 - Description textuelle des cas d'utilisation

Cas : Effectuer un calcul simple

• Acteur : Utilisateur
• Déroulement nominal :
  1. L'utilisateur saisit un premier nombre.
  2. L'utilisateur sélectionne un opérateur (+, -, ×, ÷).
  3. L'utilisateur saisit un second nombre.
  4. L'utilisateur demande le résultat (touche égale).
  5. Le système calcule et affiche le résultat.
• Exception : Si l'opérateur est une division (÷) et le second nombre est 0, le système affiche une erreur de division par zéro.

Cas : Conversion dans une monnaie quelconque

• Acteurs : Utilisateur, Fournisseur de taux de change
• Déroulement nominal :
  1. Le fournisseur de taux transmet le cours de la devise sélectionnée au système.
  2. L'utilisateur saisit un montant en euros.
  3. L'utilisateur sélectionne la fonction de conversion vers la devise.
  4. Le système multiplie le montant par le cours de la devise et affiche le résultat.

Exercice n°4 - Processus de formation (Partie 1)

Note : La source contient deux exercices numérotés 4. Celui-ci est le premier, traitant du processus de formation.

Question 1 - Identification des acteurs

• Employé : Celui qui demande la formation et suit le stage.
• Responsable formation : Celui qui valide, cherche, inscrit et contrôle.
• Organisme de formation : Entité externe (agréée) qui fournit le catalogue, assure la session et envoie la facture.

Question 2 - Identification des cas d'utilisation

En se basant sur les verbes d'action du texte liés au système informatisé :

• Demander une formation (Employé)
• Consulter le catalogue des formations (Employé, Responsable)
• Traiter une demande de formation (Responsable) - Inclut l'acceptation/refus et la recherche.
• Inscrire un employé (Responsable)
• Annuler une inscription (Responsable)
• Saisir une appréciation de stage (Employé)
• Contrôler la facture (Responsable)

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

Structure du diagramme :

• Employé est associé à : Demander une formation, Consulter le catalogue des formations, Saisir une appréciation de stage.
• Responsable formation est associé à : Consulter le catalogue des formations, Traiter une demande de formation, Inscrire un employé, Annuler une inscription, Contrôler la facture.
• Organisme de formation est associé (en tant qu'acteur secondaire) à : Inscrire un employé, Annuler une inscription, Contrôler la facture.

Exercice n°4 - Robot nettoyeur (Partie 2)

Note : Ceci est le second exercice n°4 de la source.

Question 1 - Identification des acteurs

Dans un système embarqué comme un robot, les acteurs sont les entités physiques ou logiques externes qui interagissent avec lui. L'énoncé mentionne explicitement que "L'unité de contrôle ne fait pas partie du système".

• L'unité de contrôle (interface infrarouge) : Acteur principal envoyant les commandes.
• L'environnement (Obstacle) : Acteur physique qui interagit via les amortisseurs lors d'une collision.

(Les capteurs, moteurs et l'aspirateur font partie du système, ils ne sont donc pas des acteurs).

Question 2 - Identification de trois cas d'utilisation élémentaires

Les commandes évoquées dans le texte correspondent aux services directs :

1. Se déplacer (en avant ou en arrière).
2. Tourner (sens des aiguilles d'une montre ou sens contraire).
3. Nettoyer (allumer ou éteindre l'aspirateur). Un quatrième cas, réactif, est Gérer une collision.

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

Structure du diagramme :

• Unité de contrôle est reliée à : Se déplacer, Tourner, Nettoyer.
• Environnement (Obstacle) est relié à : Gérer une collision.
• Optionnel mais recommandé : Le cas "Se déplacer" peut posséder une relation <<extend>> vers "Gérer une collision" (la collision survient lors d'un déplacement).

Question 4 - Description des scénarios possibles

Cas : Se déplacer

• L'unité de contrôle envoie la commande de déplacement (direction avant ou arrière).
• Le robot active ses moteurs électriques dans la direction demandée.

Cas : Tourner

• Le robot s'arrête (pré-condition stipulée par l'énoncé : "ne peut changer de direction que lorsqu'il s'arrête").
• L'unité de contrôle envoie la commande de rotation (sens).
• Le robot fait tourner ses moteurs séparément pour pivoter.

Cas : Nettoyer

• L'unité de contrôle envoie la commande de nettoyage.
• L'unité de contrôle bascule l'état de l'aspirateur (marche vers arrêt, ou arrêt vers marche).

Cas : Gérer une collision (Scénario d'exception lors du déplacement)

• Un contact avec un obstacle appuie sur un interrupteur d'amortisseur.
• Le robot s'arrête immédiatement.
• Le robot entreprend une manœuvre de dégagement (ex: reculer et tourner) pour s'éloigner de l'obstacle.

Exercice n°5 - Bibliothèque universitaire

Question 1 - Identification des acteurs du système

L'énoncé (et sa solution intégrée) identifie cinq types d’acteurs :

• étudiant
• externe
• emprunteur (acteur abstrait regroupant étudiant, enseignant et externe)
• gestionnaire
• bibliothécaire

Question 2 - Identification des cas d’utilisation

Six cas d’utilisation sont identifiés par le corrigé de la source :

• inscription à la bibliothèque
• consultation du catalogue
• emprunt d’ouvrages
• restitution d’ouvrages
• approvisionnement d’ouvrages
• relance emprunteur

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

Structure du diagramme :

• Généralisation : Les acteurs étudiant et externe (ainsi que les enseignants) héritent de l'acteur générique emprunteur.
• Emprunteur est associé à : consultation du catalogue.
• Gestionnaire est associé à : inscription à la bibliothèque, relance emprunteur.
• Bibliothécaire est associé à : emprunt d’ouvrages, restitution d’ouvrages, approvisionnement d’ouvrages.
• Note : L'emprunteur interagit avec le bibliothécaire pour l'emprunt et la restitution, l'emprunteur est donc un acteur secondaire sur ces deux cas.

Question 4 - Description des scénarios possibles en langage naturel

L'énoncé initial ne fournit pas le corrigé de cette question. Voici les scénarios standards déduits des règles de gestion du texte.

Cas : Emprunt d'ouvrages

• Déroulement nominal :
  1. L'emprunteur présente ses ouvrages au bibliothécaire.
  2. Le bibliothécaire vérifie l'identité de l'emprunteur.
  3. Le système vérifie que l'emprunteur possède moins de 3 ouvrages en cours.
  4. Le système enregistre l'emprunt pour une durée de 3 semaines.
• Exception (Quota atteint) : Si l'emprunteur a déjà 3 ouvrages, le système refuse l'enregistrement du nouvel emprunt.

Cas : Relance emprunteur

• Déroulement nominal :
  1. Le gestionnaire demande au système la liste des retards.
  2. Le système liste les emprunts dépassant la durée autorisée (3 semaines, ou 5 semaines si prolongation exceptionnelle accordée).
  3. Le gestionnaire édite et envoie les relances.

Exercice n°6 - Association Locagite

Question 1 - Identification des acteurs du système

La solution fournie par la source identifie :

• Le propriétaire
• Le propriétaire adhérent (qui met en location son gîte)
• Le client réservataire
• Le client locataire
• Le gestionnaire Catalogue-Propriétaire
• Le gestionnaire Réservation-Location

Question 2 - Identification des cas d’utilisation

• Gestion annuelle du catalogue
• Publication du catalogue
• Contrôle annuel de l’état du gîte
• Gestion propriétaire
• Authentification propriétaire
• Gestion des réservations
• Authentification client
• Gestion des locations
• Gestion des annulations

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

Structure du diagramme :

• L'acteur gestionnaire Catalogue-Propriétaire est lié à : Gestion annuelle du catalogue, Publication du catalogue, Contrôle annuel de l'état du gîte, Gestion propriétaire.
• L'acteur gestionnaire Réservation-Location est lié à : Gestion des réservations, Gestion des locations, Gestion des annulations.
• Les acteurs propriétaire et client interagissent avec les cas de gestion qui les concernent et incluent des procédures d'Authentification (<<include>>).

Question 4 - Description des scénarios possibles en langage naturel

La source originale fournit la solution détaillée pour les trois premiers cas d'utilisation. Note : La résolution de l'ensemble des scénarios restants nécessiterait l'invention de données hors de la source, ce qui est évité ici. Les solutions fournies par le document de référence sont fidèlement reproduites ci-dessous.

Cas d’utilisation 1.1 : Gestion annuelle du catalogue

Scénario 1.1.1 "Création gîte"

• Objectif : Permettre l’ajout d’un gîte dans le catalogue.
• Acteurs concernés : Gestionnaire catalogue.
• Pré conditions : Aucune.
• Scénario nominal :
  1. Créer un nouveau propriétaire s’il n’existe pas.
  2. Créer un gîte.
  3. Ajouter le gîte créé au catalogue.
• Scénarios alternatifs :
  • 1-a : Erreurs détectées dans la saisie du propriétaire : Le système réaffiche le formulaire de saisie en indiquant les erreurs détectées. Le gestionnaire corrige les erreurs. Le cas d’utilisation reprend à l’action 1.
  • 2-a : Erreurs détectées dans la saisie du gîte : Le système réaffiche le formulaire de saisie en indiquant les erreurs détectées. Le gestionnaire corrige les erreurs. Le cas d’utilisation reprend à l’action 2.

Scénario 1.1.2 "Modification gîte"

• Objectif : Permettre la modification d’un gîte déjà présent.
• Acteurs concernés : Gestionnaire catalogue.
• Pré conditions : Aucune.
• Scénario nominal :
  1. Saisie et contrôle d’existence du gîte.
  2. Saisie et contrôle d’existence du propriétaire.
  3. Modification des données du gîte.
  4. Modification éventuelle des activités du gîte.
• Scénarios alternatifs :
  • 1-a : Erreur de saisie du gîte : Réaffichage avec erreur. Correction par le gestionnaire. Reprise à l'action 1.
  • 2-a : Erreurs de saisie du propriétaire : Réaffichage avec erreur. Correction par le gestionnaire. Reprise à l'action 2.

Cas d’utilisation 1.2 : Publication du catalogue

Scénario "Publication du catalogue"

• Objectif : Permettre l’édition du catalogue.
• Acteurs concernés : Gestionnaire catalogue.
• Pré conditions : Aucune.
• Scénario nominal : Pour chaque gîte :
  1. Rechercher les informations sur le propriétaire.
  2. Afficher les tarifs de location à la semaine.
  3. Afficher les activités disponibles.

Cas d’utilisation 1.3 : Mise à jour annuelle du gîte (Correspond au contrôle annuel)

Scénario "Mise à jour annuelle du gîte"

• Objectif : Permettre la mise à jour du nombre d’étoiles d’un gîte donné.
• Acteurs concernés : Gestionnaire catalogue.
• Pré conditions : Aucune.
• Scénario nominal :
  1. Saisir le code propriétaire, le code du gîte et le nombre d’étoiles.
  2. Mettre à jour le nombre d’étoiles.
• Scénarios alternatifs :
  • 1-a : le propriétaire ou le gîte n’existe pas : Le système réaffiche le formulaire de saisie en indiquant l’erreur détectée. Le gestionnaire corrige les erreurs. Le cas d’utilisation reprend à l’action 1.

Méthode

Face à une épreuve de modélisation orientée objet (UML, Diagrammes de cas d'utilisation), adoptez la démarche suivante :

1. Tracez la frontière du système : C'est l'étape la plus critique. Ce qui est à l'intérieur du système informatisé se modélise sous forme de cas d'utilisation (les fonctionnalités informatiques). Ce qui est à l'extérieur se modélise sous forme d'acteurs (les humains, les capteurs de l'environnement physique ou les systèmes externes).
2. Identifiez les acteurs par les rôles : Ne listez pas des individus, mais les fonctions qu'ils occupent face au système. Cherchez qui initialise une action et qui en reçoit les conséquences. Un acteur physique externe à informatiser (comme l'unité de contrôle d'un robot) reste un acteur.
3. Nommez les cas d'utilisation avec des verbes d'action : Un cas d'utilisation décrit un but atteignable pour un acteur (ex: Retirer de l'argent, Demander une formation). Ne modélisez pas la navigation technique de l'interface graphique (ex: Cliquer sur le bouton valider).
4. Évitez la sur-modélisation (le piège conceptuel) : Le diagramme de cas d'utilisation est un outil de définition du besoin, pas de l'architecture. N'abusez pas des relations <<include>> ou <<extend>> pour décomposer techniquement le système (cf. Exercice 1). Utilisez-les uniquement pour factoriser un comportement métier commun (comme l'authentification bancaire).
5. Soignez les scénarios nominaux : Lors de la description textuelle, restez séquentiel et factuel. Précisez toujours l'objectif, les pré-conditions et listez le chemin de réussite (scénario nominal) avant de lister les chemins d'échec (scénarios alternatifs).