Diagramme de cas d’utilisation

Exercice 1 - Diagramme de cas d'utilisation d'un GAB

Question 1 - Identification des acteurs

Dans le contexte de ce Guichet Automatique de Banque (GAB), les acteurs (entités externes interagissant avec le système) sont :

1. Porteur de carte : Acteur principal général qui interagit avec le GAB pour retirer de l'argent.
2. Client de la banque : Acteur principal spécialisé (héritant de "Porteur de carte") qui possède une carte spécifique de la banque et peut accéder à des fonctionnalités supplémentaires (solde, dépôts).
3. Opérateur de maintenance (ou Mainteneur) : Acteur principal intervenant pour recharger le GAB et effectuer la maintenance.
4. Système d'autorisation bancaire (implicite mais essentiel) : Acteur secondaire sollicité par le GAB pour vérifier la validité de la carte et le solde disponible. (Note : L'énoncé précise que le code est vérifié sur la puce, mais les transactions bancaires sécurisées nécessitent généralement un système central).

Question 2 - Identification des différents cas d'utilisation

À partir du texte, on déduit les cas d'utilisation (CU) suivants :

• Retirer de l'argent (déclenché par le Porteur de carte)
• Consulter le solde (déclenché par le Client de la banque)
• Déposer du numéraire (déclenché par le Client de la banque)
• Déposer des chèques (déclenché par le Client de la banque)
• S'authentifier (Vérifier le code PIN) : Ce cas est inclus (<<include>>) par toutes les transactions sécurisées.
• Recharger le GAB (déclenché par l'Opérateur de maintenance)
• Effectuer la maintenance (déclenché par l'Opérateur de maintenance)

Question 3 - Représentation du diagramme

Puisque le rendu final est textuel, voici la représentation du diagramme sous forme de code PlantUML (qui peut être compilé pour générer le diagramme visuel) illustrant la structure et les relations :

@startuml
left to right direction
actor "Porteur de carte" as Porteur
actor "Client de la banque" as Client
actor "Opérateur de maintenance" as Operateur

Client -|> Porteur : <<héritage>>

package "Système GAB" {
  usecase "Retirer de l'argent" as UC_Retrait
  usecase "Consulter le solde" as UC_Solde
  usecase "Déposer du numéraire" as UC_DepotNum
  usecase "Déposer des chèques" as UC_DepotCheque
  usecase "S'authentifier" as UC_Auth
  usecase "Recharger le GAB" as UC_Recharge
  usecase "Effectuer la maintenance" as UC_Maint
}

Porteur --> UC_Retrait
Client --> UC_Solde
Client --> UC_DepotNum
Client --> UC_DepotCheque

Operateur --> UC_Recharge
Operateur --> UC_Maint

UC_Retrait ..> UC_Auth : <<include>>
UC_Solde ..> UC_Auth : <<include>>
UC_DepotNum ..> UC_Auth : <<include>>
UC_DepotCheque ..> UC_Auth : <<include>>
@enduml

Exercice 2 - Calculette/Convertisseur

Question 1 - Identification des deux acteurs

L'énoncé stipule l'identification de deux acteurs.

1. L'Utilisateur : C'est l'acteur principal qui saisit les nombres, demande les opérations arithmétiques et les conversions.
2. Le Fournisseur de devises (Système externe) : Bien que l'énoncé mentionne "en indiquant le cours d'une devise", ce qui pourrait être une action manuelle de l'utilisateur, la modélisation UML de systèmes de conversion exige souvent de représenter la source des taux de change comme un acteur secondaire. Si l'on s'en tient strictement au texte, l'utilisateur indique le cours, mais pour satisfaire la contrainte "deux acteurs", on identifie le système externe (ou la source d'information) qui fournit ce cours au système.

Question 2 - Identification de trois cas d'utilisation

1. Effectuer une opération arithmétique (couvre l'addition, la soustraction, la multiplication, et la division).
2. Convertir des francs en euros (et inversement).
3. Convertir un montant en devise étrangère.

Question 3 - Représentation du diagramme

@startuml
left to right direction
actor "Utilisateur" as User
actor "Fournisseur de devises\n(Système externe)" as Fournisseur

package "Système Calculette/Convertisseur" {
  usecase "Effectuer une opération arithmétique" as UC_Calcul
  usecase "Convertir Francs/Euros" as UC_ConvEuro
  usecase "Convertir Euros/Devise étrangère" as UC_ConvDevise
}

User --> UC_Calcul
User --> UC_ConvEuro
User --> UC_ConvDevise
UC_ConvDevise <-- Fournisseur
@enduml

Question 4 - Description textuelle du cas d'utilisation d'un calcul simple

Cas d'utilisation : Effectuer une opération arithmétique Acteur principal : Utilisateur Pré-condition : La calculette est allumée et prête à l'emploi. Post-condition : Le résultat du calcul est affiché à l'écran.

Scénario nominal :

1. L'utilisateur saisit un premier nombre (opérande).
2. Le système affiche le nombre saisi.
3. L'utilisateur sélectionne un opérateur (+, -, ×, ÷).
4. Le système enregistre l'opérateur.
5. L'utilisateur saisit un second nombre.
6. Le système affiche le second nombre saisi.
7. L'utilisateur demande l'exécution du calcul (touche "égale").
8. Le système calcule le résultat de l'opération et l'affiche.

Scénario alternatif / d'exception :

• Division par zéro : À l'étape 8, si l'opérateur est "÷" et le second opérande est "0", le système affiche un message d'erreur ("Erreur" ou "Division par zéro impossible") au lieu du résultat.

Exercice 3 - Le Système d'Information du Libraire

Question 1 - Acteurs du SI du libraire et leurs types

1. Le Libraire (Ali) : Acteur principal. C'est lui qui interagit directement avec le SI pour scanner les articles, enregistrer les commandes, éditer les factures et lancer l'état des stocks.
2. Le Client : Acteur principal (par procuration). Bien qu'il n'utilise pas le clavier de la caisse, il est le déclencheur direct des processus métier (achat, commande) et le bénéficiaire final de la facture.
3. Le Fournisseur : Acteur secondaire. Il reçoit les commandes générées par le SI et les courriels de relance. Il ne déclenche pas les cas d'utilisation mais participe à leur achèvement.
4. Le Lecteur optique (Code-barres) : Acteur secondaire (matériel). Il fournit les données (référence de l'article) au SI lors de l'achat.
5. L'Horloge / Planificateur de tâches : Acteur secondaire. Déclenche de manière autonome la vérification du dépassement du délai de 3 jours pour l'envoi du mail de relance.

Question 2 - Représentation du diagramme

@startuml
left to right direction
actor "Libraire" as Lib
actor "Client" as Client
actor "Fournisseur" as Fournisseur
actor "Lecteur Optique" as Lecteur
actor "Horloge" as Horloge

package "SI Librairie" {
  usecase "Enregistrer un achat" as UC_Achat
  usecase "Enregistrer une commande client" as UC_CmdClient
  usecase "Retirer des articles commandés" as UC_Retrait
  usecase "Gérer l'état du stock" as UC_Stock
  
  usecase "Éditer une facture" as UC_Facture
  usecase "Enregistrer les infos client" as UC_InfoClient
}

Client --> UC_Achat
Lib --> UC_Achat
UC_Achat <-- Lecteur
UC_Achat ..> UC_Facture : <<include>>

Client --> UC_CmdClient
Lib --> UC_CmdClient
UC_CmdClient ..> UC_Facture : <<include>>
UC_CmdClient ..> UC_InfoClient : <<include>>

Client --> UC_Retrait
Lib --> UC_Retrait

Lib --> UC_Stock
Horloge --> UC_Stock : "Déclenche relance après 3 jours"
UC_Stock --> Fournisseur : "Envoi commande / Relance mail"

@enduml

(Note de correction : L'énoncé mentionne des sous-systèmes comme la "gestion de stock", "facturation", "gestion de commandes". En UML, ce sont des composants internes du SI, ils ne doivent pas être modélisés comme des acteurs).

Exercice 4 - Site web gastronomique

Question 1 - Acteurs du site web et justifications

1. Consommateur (Internaute) : Acteur principal. Il navigue librement sur le site pour consulter les informations.
2. Consommateur inscrit : Acteur principal. Il s'agit d'un acteur spécialisé qui hérite des droits du Consommateur simple, avec des privilèges supplémentaires (évaluer, réserver).
3. Restaurateur : Acteur principal. Il interagit avec le système pour s'inscrire, proposer un restaurant et valider/annuler des réservations.
4. Équipe de rédaction : Acteur principal. Elle interagit avec le système pour accepter ou conditionner l'acceptation des propositions de restaurants.
5. Système de messagerie (Serveur Mail) : Acteur secondaire. Le composant interne du système de réservation l'utilise pour acheminer les e-mails de confirmation aux clients.

Question 2 - Représentation du diagramme

L'énoncé exige au moins deux <<include>>, une relation d'héritage, et un <<extend>>, avec un maximum de 9 cas.

@startuml
left to right direction
actor "Consommateur" as Conso
actor "Consommateur Inscrit" as ConsoInscrit
actor "Restaurateur" as Resto
actor "Équipe de rédaction" as Equipe

ConsoInscrit -|> Conso : <<héritage>>

package "Site Web Gastronomique" {
  usecase "Consulter les informations" as UC_Consulter
  usecase "S'inscrire sur le site" as UC_Inscrire
  usecase "Évaluer un restaurant" as UC_Evaluer
  usecase "Demander une réservation" as UC_Reserver
  usecase "S'authentifier" as UC_Auth
  
  usecase "Proposer un restaurant" as UC_Proposer
  usecase "Valider une réservation" as UC_ValiderResa
  
  usecase "Accepter un restaurant" as UC_Accepter
  usecase "Visiter le restaurant" as UC_Visiter
}

Conso --> UC_Consulter
Conso --> UC_Inscrire
Resto --> UC_Inscrire

ConsoInscrit --> UC_Evaluer
ConsoInscrit --> UC_Reserver

Resto --> UC_Proposer
Resto --> UC_ValiderResa

Equipe --> UC_Accepter

UC_Evaluer ..> UC_Auth : <<include>>
UC_Reserver ..> UC_Auth : <<include>>

UC_Accepter <.. UC_Visiter : <<extend>> (si suspect)
@enduml

Question 3 - Scénarios du cas "demander une réservation de table"

Scénario nominal (La demande est traitée et acceptée avec succès) :

1. Le consommateur inscrit sélectionne un restaurant et choisit l'option de réservation.
2. Le système lui présente un formulaire de demande.
3. Le consommateur remplit la date, l'heure et le nombre de personnes, puis valide.
4. Le système transmet la demande et la met en attente de validation.
5. Le restaurateur consulte la demande via son interface.
6. Le restaurateur confirme la réservation.
7. Le système (via le composant de gestion) enregistre la réservation définitive.
8. Le système envoie un e-mail de confirmation au consommateur.

Scénario exceptionnel (Le restaurateur annule/refuse la demande) : 1 à 5 : Identiques au scénario nominal. 6. Le restaurateur décide d'annuler (ou refuser) la réservation (par exemple, par manque de place). 7. Le système supprime la demande ou la marque comme refusée. 8. Le système informe le consommateur (par affichage ou par e-mail) que la réservation n'a pas pu être honorée. Le cas d'utilisation se termine sans réservation enregistrée.

Exercice 5 - Logiciel de gestion des réparations

Question 1 - Diagramme de cas d'utilisation et éléments associés

a. Les autres acteurs et leurs types

Outre le Chef d'atelier (Principal), on identifie :

• Magasinier : Acteur principal (interagit pour fournir des pièces, changer les statuts, saisir dans la fiche).
• Comptable : Acteur principal (importe les fiches fermées).
• Logiciel de gestion des commandes : Acteur secondaire (reçoit les commandes du magasinier).
• Logiciel comptable : Acteur secondaire (reçoit les données importées).

b. Quatre autres cas d'utilisation

L'énoncé demande de relever quatre autres cas pertinents :

1. Fournir des pièces de rechange (par le magasinier).
2. Commander des pièces manquantes (par le magasinier).
3. Essayer la voiture et fermer la fiche (par le chef d'atelier).
4. Importer les fiches de réparation (par le comptable).

c. Représentation du diagramme avec relations

@startuml
left to right direction
actor "Chef d'atelier" as Chef
actor "Magasinier" as Magasinier
actor "Comptable" as Comptable
actor "Logiciel Gestion Commandes" as SI_Cmd
actor "Logiciel Comptable" as SI_Compta

package "Logiciel Gestion Réparations" {
  usecase "Créer une fiche de réparation" as UC_Creer
  usecase "Fournir des pièces de rechange" as UC_Fournir
  usecase "Commander des pièces manquantes" as UC_Cmd
  usecase "Saisir l'utilisation d'une pièce" as UC_SaisirPiece
  usecase "Fermer la fiche de réparation" as UC_Fermer
  usecase "Importer les fiches de réparation" as UC_Importer
}

Chef --> UC_Creer
Chef --> UC_Fermer

Magasinier --> UC_Fournir
Magasinier --> UC_Cmd

Comptable --> UC_Importer

UC_Cmd --> SI_Cmd
UC_Importer --> SI_Compta

UC_Fournir ..> UC_SaisirPiece : <<include>>
@enduml

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

Cas d'utilisation : Créer une fiche de réparation Acteur principal : Chef d'atelier

Scénario nominal :

1. Le chef d'atelier saisit les critères de recherche d'une voiture dans le logiciel.
2. Le système affiche la liste des voitures correspondantes.
3. Le chef sélectionne la voiture concernée (la voiture existe déjà).
4. Le système fournit les informations du véhicule.
5. Le chef saisit la date de réception et la date de restitution prévue.
6. Le système enregistre la nouvelle fiche de réparation.

Variantes et exceptions :

• Voiture sous garantie : À l'étape 4, si le véhicule est sous garantie, le chef doit saisir en plus la date de demande de réparation.
• Voiture inexistante : À l'étape 2, si aucune voiture ne correspond, le chef sélectionne l'option de création. Il saisit les informations du nouveau véhicule avant de passer à l'étape 5.
• Paiement par assurance : Lors de l'étape 5, si le dommage est pris en charge par l'assurance, le logiciel affiche une liste. Le chef sélectionne l'assurance appropriée avant que la fiche ne soit enregistrée.

Exercice 6 - Gestion de cours en ligne

Question 1 - Identification et justification des acteurs

Noms	Type	Justifications
a. Administrateur	Acteur principal	Oui. Il enregistre/supprime les cours et gère les inscriptions (actions directes sur le SI).
b. Horloge	Acteur secondaire	Oui. L'énoncé précise : "l'application gère de manière interne une horloge" qui déclenche l'écoulement d'une heure ou les délais de remise. Bien qu'interne informatiquement, elle agit comme un déclencheur temporel autonome en UML.
c. email	Acteur secondaire	(Accepté sous l'appellation "Système de messagerie"). L'email en soi est un flux/objet, mais le système qui l'envoie agit comme acteur secondaire appelé par l'application.
d. Cours	Non retenu	C'est une entité métier (objet de la base de données), pas un acteur interagissant avec le système.
e. test	Non retenu	Objet passif créé par l'enseignant et passé par l'étudiant, pas un acteur.
f. Informaticien	Non retenu	Ce terme n'est pas utilisé dans le texte. Son rôle est couvert par "Administrateur".
g. Intervenant	Acteur abstrait	Oui (selon les conventions UML courantes). Il sert de super-classe (généralisation) pour factoriser les cas communs (comme "S'identifier") d'Enseignant et d'Étudiant.
h. L'application	Non retenu	C'est la frontière du système que l'on est en train de modéliser. Le système n'est jamais son propre acteur externe.
i. Enseignant	Acteur principal	Oui. Il prépare des tests, attribue des notes et dépose des documents.
j. Web	Non retenu	C'est le réseau/canal de transmission technique, pas une entité métier.
k. Etudiant	Acteur principal	Oui. Il consulte, dépose des travaux et passe des tests.

Question 2 - Complétion du diagramme de cas d'utilisation

a. Choix de 4 autres cas d'utilisation pertinents : Parmi la liste fournie, nous retenons les actions constituant de véritables objectifs métier pour les acteurs :

1. Attribuer notes (Enseignant)
2. Déposer travail (Étudiant)
3. Quitter test (Extension possible lors de la passation d'un test)
4. Reprendre test (Extension possible suite à l'abandon prématuré)

b. et c. Représentation textuelle du diagramme avec liens :

@startuml
left to right direction
actor "Administrateur" as Admin
actor "Enseignant" as Prof
actor "Etudiant" as Etu
actor "Intervenant" as Interv
actor "Horloge" as Horloge

Prof -|> Interv
Etu -|> Interv

package "gestion_cours_en_ligne" {
  usecase "S'identifier" as UC_Id
  usecase "Inscrire étudiant" as UC_Inscrire
  usecase "Déposer un document" as UC_DepotDoc
  usecase "Passer un test" as UC_Test
  usecase "Attribuer notes" as UC_Notes
  usecase "Déposer travail" as UC_DepotTravail
  usecase "Quitter test" as UC_Quitter
  usecase "Reprendre test" as UC_Reprendre
}

Interv --> UC_Id

Admin --> UC_Inscrire

Prof --> UC_DepotDoc
Prof --> UC_Notes
UC_DepotDoc ..> UC_Id : <<include>>
UC_Notes ..> UC_Id : <<include>>

Etu --> UC_Test
Etu --> UC_DepotTravail
UC_Test ..> UC_Id : <<include>>
UC_DepotTravail ..> UC_Id : <<include>>

UC_Quitter .> UC_Test : <<extend>>
UC_Reprendre .> UC_Test : <<extend>>

Horloge --> UC_Test : "Gère le délai d'une heure"
@enduml

Question 3 - Analyse du cas "Passer un test"

a. Pré-condition : L'étudiant est correctement identifié (authentifié), il est inscrit au cours de l'enseignant concerné, et le moment actuel respecte la période horaire fixée par l'enseignant pour ce test.

b. Post-condition : Soit le test est complété et les notes sont enregistrées dans la base de données (correction auto/manuelle) ; soit le test est définitivement bloqué (si délai dépassé après avoir quitté) et l'étudiant est déconnecté.

c. Acteurs principaux : Étudiant (déclencheur principal). L'Horloge intervient comme acteur secondaire pour contraindre le temps d'exécution.

d. Variantes de scénarios pour "Passer un test" :

1. Scénario nominal (Déroulement normal) : L'étudiant démarre le test sur sa page. Il répond à toutes les questions posées dans le temps imparti. Il soumet le test. Le système corrige automatiquement les réponses grâce aux données de l'enseignant, puis enregistre les notes de l'étudiant directement dans la base de données.
2. Scénario alternatif 1 (Abandon et blocage) : L'étudiant démarre le test mais décide de le quitter avant d'avoir répondu à toutes les questions. Le système envoie immédiatement un e-mail à l'enseignant (précisant le nom et les questions répondues) et déconnecte systématiquement l'étudiant. L'étudiant ne tente pas de se reconnecter avant l'écoulement d'une heure. Le test devient indisponible et devra être corrigé manuellement.
3. Scénario alternatif 2 (Reprise avant expiration du délai) : L'étudiant quitte le test en cours de route (entraînant l'envoi de l'e-mail et la déconnexion). Il se reconnecte et demande à reprendre le test avant l'écoulement de la limite stricte d'une heure. Le système l'autorise à terminer ses réponses. Le scénario rejoint alors la fin du scénario nominal pour la soumission.

Méthode

Face à une épreuve portant sur les diagrammes de cas d'utilisation (UML) :

1. Recherche des Acteurs : Repérez dans le texte tous les noms désignant des personnes (utilisateurs, rôles professionnels) ou des systèmes externes autonomes communiquant avec l'application. Ne confondez pas un acteur (externe) avec un composant logiciel du système étudié.
2. Identification des Cas d'Utilisation : Traquez les verbes d'action à l'infinitif. Un cas d'utilisation doit toujours représenter un objectif complet apportant une valeur ajoutée à un acteur.
3. Gestion des relations <<include>> et <<extend>> : Utilisez l'inclusion (<<include>>) lorsqu'une étape est obligatoire et partagée (comme l'authentification). Utilisez l'extension (<<extend>>) pour décrire un comportement optionnel ou une exception (ex: "vérifier la solvabilité" étendu par "rejeter l'opération" si le solde est nul).
4. Justification par l'énoncé : Utilisez exclusivement le texte fourni. Ne rajoutez pas de fonctionnalités que vous jugeriez pratiques dans la vie réelle si le document source n'en fait pas mention. La rigueur conceptuelle prime sur l'imagination.