EXERCICES UML

Exercice 1 - Diagramme de cas d'utilisation : Réservation de salles

L'objectif de cet exercice est d'identifier les acteurs interagissant avec le système de réservation et de structurer les cas d'utilisation (fonctionnalités) en respectant les droits d'accès décrits dans l'énoncé.

Analyse des acteurs et de leurs droits :

1. Utilisateur salle : C'est l'acteur le plus général. Il peut uniquement "Consulter planning" (accessible à tout le monde : enseignants et étudiants).
2. Enseignant : Il hérite des droits de l'utilisateur de base. Il peut en plus effectuer une "Réservation" et "Consulter récap horaire enseignant".
3. Responsable formation : Il s'agit d'un enseignant avec des droits étendus (héritage). Il est le seul à pouvoir "Editer récap formation".

Analyse des cas d'utilisation et de leurs relations :

• La "Réservation" nécessite obligatoirement de vérifier si la salle ou le matériel est libre. On utilise donc une relation d'inclusion (<<include>>) vers le cas "Vérification disponibilité".
• La réservation peut être spécialisée en "Réservation salle" ou "Réserver matériel". Ce dernier se spécialise à son tour en "Réserver vidéo" et "Réserver portable". On modélise cela par des relations de généralisation (héritage de cas d'utilisation).

Note : La hiérarchie exacte des inclusions et spécialisations a été restaurée logiquement à partir du texte extrait.

@startuml
left to right direction
skinparam packageStyle rectangle

actor "Utilisateur salle" as User
actor "Enseignant" as Ens
actor "Responsable formation" as Resp

User <|-- Ens
Ens <|-- Resp

rectangle "Système de Réservation" {
  usecase "Consulter planning" as UC_Planning
  usecase "Consulter récap horaire enseignant" as UC_Recap
  usecase "Editer récap formation" as UC_Editer_Recap
  
  usecase "Réservation" as UC_Resa
  usecase "Vérification disponibilité" as UC_Verif
  
  usecase "Réservation salle" as UC_ResaSalle
  usecase "Réserver matériel" as UC_ResaMat
  usecase "Réserver vidéo" as UC_ResaVideo
  usecase "Réserver portable" as UC_ResaPort
}

User --> UC_Planning
Ens --> UC_Recap
Ens --> UC_Resa
Resp --> UC_Editer_Recap

UC_Resa ..> UC_Verif : <<include>>

UC_ResaSalle -up-|> UC_Resa
UC_ResaMat -up-|> UC_Resa
UC_ResaVideo -up-|> UC_ResaMat
UC_ResaPort -up-|> UC_ResaMat
@enduml

Exercice 2 - Projet de recherche en viticulture

Cet exercice très complet demande de modéliser le système sous trois angles : les cas d'utilisation, le processus métier (diagramme d'activité), et les données (diagramme de classes).

Question 2.1 - Diagramme de cas d'utilisation

Acteurs :

• Ouvrier Agricole : Saisit sur un cahier (hors système informatique direct, mais il interagit avec le glossaire).
• Chef exploitation : Vérifie, corrige et saisit les données dans le système.
• Chercheur : Reçoit les notifications, vérifie, analyse et rédige la synthèse.

@startuml
left to right direction
actor "Ouvrier Agricole" as OA
actor "Chef exploitation" as CE
actor "Chercheur" as CH

rectangle "Application Internet Viticulture" {
  usecase "Consultation du glossaire" as UC_Glossaire
  usecase "Vérification saisie cahier" as UC_VerifCahier
  usecase "Correction éventuelle" as UC_CorrectionCahier
  usecase "Saisie opération" as UC_SaisieOp
  usecase "Identification" as UC_Id
  usecase "Saisie BDD" as UC_SaisieBDD
  usecase "Notification saisie ok" as UC_Notif
  usecase "Opération phyto" as UC_Phyto
  usecase "Autre opération" as UC_Autre
  usecase "Etat terravitis" as UC_Etat
  
  usecase "Vérification données BDD" as UC_VerifBDD
  usecase "Correction données BDD" as UC_CorrectionBDD
  usecase "Analyse résultats" as UC_Analyse
  usecase "Rédaction synthèse" as UC_Synthese
}

OA --> UC_Glossaire
CE --> UC_VerifCahier
UC_CorrectionCahier .up.> UC_VerifCahier : <<extend>>

CE --> UC_SaisieOp
UC_SaisieOp ..> UC_Id : <<include>>
UC_SaisieOp ..> UC_SaisieBDD : <<include>>
UC_SaisieOp ..> UC_Notif : <<include>>

UC_Phyto -up-|> UC_SaisieOp
UC_Autre -up-|> UC_SaisieOp

CH --> UC_VerifBDD
UC_CorrectionBDD .up.> UC_VerifBDD : <<extend>>
CH --> UC_Analyse
CH --> UC_Synthese

CE --> UC_Etat
@enduml

Question 2.2 - Diagramme d'activité (Processus)

L'énoncé décrit une chronologie stricte. Le diagramme d'activité avec couloirs (swimlanes) montre qui fait quoi et à quel moment.

@startuml
|Ouvrier Agricole|
start
:Saisie temps de travaux sur cahier;
|Chef Exploitation|
:Fin de mois;
:Vérification saisie cahier;
if (Erreur ?) then (oui)
  :Correction éventuelle;
else (non)
endif
:Saisie sur application (BDD);
|Chercheur|
:Réception Mail de notification;
:Vérification;
if (Erreur ?) then (oui)
  :Correction;
else (non)
endif
:Notification saisie ok;
|Chef Exploitation|
:Impression Fiche mensuelle;
:Impression Etat phyto;
:Transmission salariés;
|Chercheur|
:Fin d'année;
:Analyse;
:Rédaction Synthèse;
:Transmission;
|Chef Exploitation|
:Consultation Synthèse;
stop
@enduml

Question 2.3 - Diagramme de classes

Ce diagramme structure les entités décrites dans le cahier et la base de données : personnes, exploitations, parcelles, opérations, et spécificités phytosanitaires.

@startuml
class PERSONNE {
  - Code personne : int
  - Nom personne : varchar(50)
  - Prénom personne : varchar(50)
  + Editer relevé mensuel() : int
}

class "Fonction personne" as Fonction {
  - Code fonction : varchar(5)
  - Libellé fonction : varchar(50)
}

class Exploitation {
  - Code exploitation : varchar(5)
  - Nom exploitation : varchar(50)
  + Editer état terravitis() : int
}

class PARCELLES {
  - Code parcelle : varchar(5)
  - Nom parcelle : varchar(50)
}

class Intervention {
  - No intervention : number
  - Date intervention : date
  - Nb heures : number
  + Editer fiche intervention() : int
}

class "Intervention phyto" as IntPhyto {
  - Observation phyto : text
}

class OPERATION {
  - Code opération : varchar(5)
  - Libellé opération : varchar(50)
}

class MALADIES {
  - Code maladie : varchar(5)
  - Libellé maladie : varchar(50)
}

class "STADE PHENOLOGIQUE" as Stade {
  - Code stade : varchar(5)
  - Libellé stade : varchar(50)
}

PERSONNE "1..1" -- "1..1" Fonction
PERSONNE "1..*" -- "1..1" Exploitation
Exploitation "1..1" -- "1..*" PARCELLES
PARCELLES "1..1" -- "0..*" Intervention
PERSONNE "1..1" -- "0..*" Intervention
OPERATION "1..1" -- "0..*" Intervention

Intervention <|-- IntPhyto
IntPhyto "0..*" -- "1..1" Stade
IntPhyto "0..*" -- "0..*" MALADIES
@enduml

Exercice 3 - Magasin : Processus de vente (Cas d'utilisation)

Dans ce diagramme, l'action centrale pour le client est l'achat. Les autres actions (essayer, se renseigner) sont optionnelles par rapport à sa visite (prospection). Le paiement propose des alternatives.

@startuml
left to right direction
actor Client
actor Vendeur
actor Caisse
actor "Groupement des banques" as Banque

usecase "Prospecter" as UC_Prospecter
usecase "Renseigner" as UC_Renseigner
usecase "Essayer" as UC_Essayer
usecase "Acheter" as UC_Acheter
usecase "Vérification stock" as UC_VerifStock
usecase "Payer" as UC_Payer
usecase "Bénéficier réduction" as UC_Reduc
usecase "Payer CB" as UC_CB
usecase "Payer chèque" as UC_Cheque
usecase "Payer liquide" as UC_Liquide

Client --> UC_Prospecter
Client --> UC_Acheter

UC_Renseigner .up.> UC_Prospecter : <<extend>>
Vendeur --> UC_Renseigner
UC_Essayer .up.> UC_Prospecter : <<extend>>

UC_Acheter ..> UC_VerifStock : <<include>>
UC_Acheter ..> UC_Payer : <<include>>

UC_Reduc .up.> UC_Payer : <<extend>>

UC_CB -up-|> UC_Payer
UC_Cheque -up-|> UC_Payer
UC_Liquide -up-|> UC_Payer

Caisse --> UC_Payer
UC_CB <-- Banque
@enduml

Exercice 4 - Distributeur Automatique de Billets (DAB)

L'énoncé distingue deux types de clients : le porteur de carte lambda (qui ne peut que retirer) et le client de la banque (qui a des droits supplémentaires). Le retrait nécessite toujours une authentification (inclusion).

@startuml
left to right direction
actor "Porteur de visa" as PorteurVisa
actor "Client banque" as ClientBanque
actor "Opérateur maintenance" as Operateur
actor "SI gestion CB" as SIGestion
actor "SI banque" as SIBanque

ClientBanque -up-|> PorteurVisa

usecase "S'authentifier" as UC_Auth
usecase "Retirer argent" as UC_Retrait
usecase "Retirer argent avec visa" as UC_RetraitVisa
usecase "Consulter solde" as UC_Solde
usecase "Déposer argent" as UC_Depot
usecase "Déposer numéraire" as UC_DepotNum
usecase "Déposer chèques" as UC_DepotCheque

usecase "Recharger DAB" as UC_Recharger
usecase "Récupérer cartes avalées" as UC_RecupCartes
usecase "Récupérer chèque" as UC_RecupCheque

PorteurVisa --> UC_Retrait
UC_Retrait ..> UC_Auth : <<include>>
UC_RetraitVisa -up-|> UC_Retrait
UC_RetraitVisa <-- SIGestion

ClientBanque --> UC_Solde
ClientBanque --> UC_Depot
UC_Solde <-- SIBanque
UC_Depot <-- SIBanque

UC_DepotNum -up-|> UC_Depot
UC_DepotCheque -up-|> UC_Depot

Operateur --> UC_Recharger
Operateur --> UC_RecupCartes
Operateur --> UC_RecupCheque
@enduml

Exercice 5 - Magasin : Gestion de stock

Le commerçant gère un inventaire. L'ajout d'un article force l'édition de la fiche fournisseur (qui est donc incluse). Si le fournisseur n'existe pas, on l'ajoute (extension, car c'est un cas optionnel déclenché sous condition).

@startuml
left to right direction
actor Commerçant

usecase "Affichage inventaire" as UC_Affichage
usecase "Impression inventaire" as UC_Impression
usecase "Effacement article" as UC_Effacement
usecase "Edition article" as UC_EditArt

usecase "Ajouter article" as UC_AjoutArt
usecase "Edition fournisseur" as UC_EditFourn
usecase "Ajout fournisseur" as UC_AjoutFourn

Commerçant --> UC_Affichage
Commerçant --> UC_AjoutArt
Commerçant --> UC_EditFourn

UC_Impression .up.> UC_Affichage : <<extend>>
UC_Effacement .up.> UC_Affichage : <<extend>>
UC_EditArt .up.> UC_Affichage : <<extend>>

UC_AjoutArt ..> UC_EditFourn : <<include>>
UC_AjoutFourn .up.> UC_EditFourn : <<extend>>
@enduml

Exercice 6 - Diagramme de séquence : Caisse supermarché

L'énoncé demande de se limiter au paiement en liquide (cas nominal simple). Une boucle (loop) modélise le passage successif des articles.

@startuml
actor Client
actor Caissier
participant Caisse

Client -> Caissier : dépôt articles
loop Pour chaque article
    Caissier -> Caisse : Saisie article (no et quantité)
    Caisse --> Caissier : Prix et description
    Caisse --> Client : Prix et description
end

Caissier -> Caisse : Fin de vente
Caisse --> Caissier : Total
Caisse --> Client : Total à payer

Client -> Caissier : Liquide
Caissier -> Caisse : Saisie montant
Caisse --> Caissier : A rendre
Caisse --> Client : A rendre

Caisse -> Caisse : Enregistrement et impression
Caisse --> Caissier : Ticket et Monnaie
Caissier --> Client : Ticket et Monnaie
@enduml

Exercice 7 - Diagramme de séquence : Utilisation DAB

Le scénario nominal (tout se passe bien) est modélisé ici. Les cas d'erreurs, stipulés dans l'énoncé, sont matérialisés par des notes (commentaires) aux points de vérification critiques.

@startuml
actor "Porteur de carte" as Client
participant DAB
participant "Groupement de banques" as Banque

Client -> DAB : Introduction carte
note right: Voir cas carte non valide
DAB -> DAB : Vérification carte
DAB --> Client : Demande code

Client -> DAB : Entrée valeur code
note right: Voir cas code erroné
DAB -> DAB : Vérification code locale

DAB -> Banque : Demande autorisation de prélèvement
Banque --> DAB : Autorisation solde

DAB --> Client : Demande montant retrait
Client -> DAB : Entrée valeur retrait
note right: Voir cas montant > solde
DAB -> DAB : Contrôle montant demandé

DAB --> Client : Demande ticket
Client -> DAB : Réponse (oui)
note right: Voir cas ticket refusé

DAB --> Client : Ejection carte
note right: Voir cas carte non rendue
Client -> DAB : Récupération carte

DAB --> Client : Ejection billets et ticket
note right: Voir cas billets non repris
Client -> DAB : Récupération billets et ticket
@enduml

Exercice 8 - Diagrammes d'interaction : Magasin de fleurs

Cet exercice montre la dualité entre le diagramme de séquence (qui met l'accent sur la chronologie) et le diagramme de collaboration / communication (qui met l'accent sur la structure des liens spatiaux entre les objets).

Diagramme de séquence

@startuml
actor Client
actor Vendeur
actor Ouvrier
participant "Bon de fabrication" as Bon
participant Composition
participant Facture

Client -> Vendeur : 1: Demande renseignements
Vendeur --> Client : 2: Fournir informations
Client -> Vendeur : 3: Commande
Vendeur -> Bon ** : 4: Créer
Vendeur -> Ouvrier : 5: Transmettre bon
Vendeur -> Facture ** : 6: Editer
Vendeur -> Facture : 7: Impression facture
Ouvrier -> Composition ** : 8: Créer
Ouvrier -> Bon : 9: Archivage
Ouvrier -> Vendeur : 10: Livrer composition
Vendeur -> Client : 11: Remettre facture
Client -> Vendeur : 12: Régler
Vendeur -> Client : 13: Remettre bouquet
@enduml

Diagramme de collaboration (Communication)

La numérotation stricte des messages correspond à la chronologie définie dans le diagramme de séquence.

@startuml
allowmixing

actor Client
actor Vendeur
actor Ouvrier
object "Bon de fabrication" as Bon
object Composition
object Facture

Client -right- Vendeur : 1: Demande renseignements\n2: Fournir informations\n3: Commande\n11: Remettre facture\n12: Régler\n13: Remettre bouquet
Vendeur -down- Bon : 4: Créer
Vendeur -right- Ouvrier : 5: Transmettre bon\n10: Livrer composition
Vendeur -up- Facture : 6: Editer\n7: Imprimer
Ouvrier -down- Bon : 9: Archiver
Ouvrier -up- Composition : 8: Créer
@enduml

Exercice 9 - Diagrammes de classes de base

Cet exercice teste la compréhension des différents types d'associations : composition spatiale/physique, héritage (spécialisation), et association classique.

@startuml
package "Phrase 1 : Répertoire / Fichiers" {
  class Répertoire
  class Fichier
  Répertoire "1..1" *-- "0..*" Fichier : Contenir >
}

package "Phrase 2 : Pièce / Murs" {
  class Pièce
  class Mur
  Pièce "1..*" *-- "1..*" Mur : Composer >
}

package "Phrase 3 : Périphériques" {
  class Périphérique
  class Modem
  class Clavier
  Périphérique <|-- Modem
  Périphérique <|-- Clavier
}

package "Phrase 4 : Transactions" {
  class "Transaction boursière" as Transaction
  class Achat
  class Vente
  Transaction <|-- Achat
  Transaction <|-- Vente
}

package "Phrase 5 : Comptes bancaires" {
  abstract class Client
  class "Personne physique" as PP
  class "Personne morale" as PM
  class "Compte bancaire" as Compte
  
  Client <|-- PP
  Client <|-- PM
  Compte "1..*" -- "1..1" Client : Appartenir >
}
@enduml

Note : Dans la phrase 5, la modélisation a factorisé la notion de client pour éviter une contrainte XOR complexe sur deux associations distinctes. Le compte appartient à un Client, qui est soit une personne physique, soit une personne morale.

Exercice 10 - Académie et Collège (Diagramme de classes)

On modélise ici la structure organisationnelle (Collège -> Département -> Enseignant) et la structure pédagogique (Etudiant -> Cours -> Salle). La classe NOTE est une classe d'association, car une note n'existe que par la rencontre entre un étudiant et un cours.

@startuml
class COLLEGE {
  - code college
  - nom
  - adresse site
}

class DEPARTEMENT {
  - code département
  - nom
  + Calculer moyenne() : void
}

class PERSONNE {
  - No personne
  - Nom
  - prénom
  - tel
  - mail
  + Afficher fiche signalétique() : void
}

class ENSEIGNANT {
  - date prise de fonction
  - Indice
}

class ETUDIANT {
  - Année entrée
  + Calculer moyenne() : void
  + Afficher mat sans note() : void
}

class COURS {
  - No cours
  - libellé cours
  + Calculer moyenne() : void
}

class SALLE {
  - No salle
  - nom
  - capacité
}

class NOTE {
  - Note contrôle
}

PERSONNE <|-- ENSEIGNANT
PERSONNE <|-- ETUDIANT

COLLEGE "1..1" -- "1..*" DEPARTEMENT : Constituer >
DEPARTEMENT "1..1" -- "1..*" ENSEIGNANT : Appartenir <
DEPARTEMENT "0..1" -- "1..1" ENSEIGNANT : Etre chef de <

ENSEIGNANT "1..*" -- "1..1" COURS : Enseigner >
COURS "1..1" -- "0..*" SALLE : Dérouler >

ETUDIANT "0..*" -- "1..*" COURS : Suivre >
(ETUDIANT, COURS) .. NOTE
@enduml

Exercice 11 - Réservation de vols (Diagramme de classes)

L'énoncé stipule des vols "génériques" (ex: "Le vol AF123 Paris-NewYork du lundi") et des vols instanciés pour une date précise ("Le vol AF123 du 12 mai").

@startuml
class "Compagnie aérienne" as Cie {
  + Code cie : char
  + Nom cie : char
}

class "Vol générique" as VolGen {
  + no vol générique : int
  + jour : date
  + heure depart : date
  + heure arrivee : date
  + Calculer durée() : void
}

class Vol {
  + No vol : int
  + date depart : date
  + date arrivée : date
}

class Aeroport {
  + No aeroport : int
  + Nom aeroport : char
}

class ESCALE {
  + no escale : int
  + heure départ : Date
  + heure arrivée : date
  + calculer durée() : void
}

class Ville {
  + no ville : int
  + Nom ville : char
}

class Réservation {
  + Numéro : long
  + Date : Date
}

class Individu {
  + No individu : long
  + Nom : char
  + prénom : char
  + Adresse : char
  + code postal : char
  + Ville : char
}

class Client {
  + Code client : char
}

class passager {
  + Code passager : int
  + nb points : int
}

Individu <|-- Client
Individu <|-- passager

Cie "1..1" -- "1..*" VolGen : Gérer >
VolGen "1..1" -- "0..*" Vol : Décrire >

Vol "0..*" -- "1..1" Aeroport : Concerne (départ) >
Vol "0..*" -- "1..1" Aeroport : Concerne (arrivée) >
Vol "1..1" -- "0..*" ESCALE : Concerne >
ESCALE "0..*" -- "1..1" Aeroport : Concerne >

Aeroport "1..*" -- "1..1" Ville : dessert >

Client "1..1" -- "0..*" Réservation : Effectuer >
Réservation "0..*" -- "1..1" Vol : Concerne >
Réservation "0..*" -- "1..1" passager : Concerne >
@enduml

Méthode

Face à une épreuve d'UML (notamment pour l'élaboration de diagrammes à partir de texte), la démarche la plus sûre est de procéder par étapes :

1. Lire l'intégralité du sujet avant de tracer la moindre ligne. Les exceptions ou les règles qui modifient la structure de base (comme "Finalement, le client de la banque peut faire plus qu'un porteur de carte classique") sont souvent précisées en fin de paragraphe.
2. Identifier les acteurs et les entités au brouillon : Soulignez les noms (candidats pour les classes ou acteurs) et les verbes (candidats pour les cas d'utilisation ou les méthodes).
3. Distinguer <<include>> et <<extend>> dans les cas d'utilisation :
   • <<include>> : Le cas de base est incomplet sans le cas inclus. Le comportement est obligatoire (ex: la réservation implique toujours une vérification de disponibilité).
   • <<extend>> : Le comportement ajouté est optionnel et s'exécute sous une condition particulière (ex: l'impression n'a lieu que si l'utilisateur le demande).
4. Vérifier les multiplicités (1..1, 0..*) pour chaque association en vous posant systématiquement la question dans les deux sens : "Combien de [Classe B] au minimum et au maximum pour une instance de [Classe A] ?" et vice versa.
5. Gérer l'héritage intelligemment : Si deux entités partagent 80% de leurs attributs (comme Client et Passager, ou Enseignant et Etudiant), factorisez ces attributs dans une classe mère abstraite (Individu ou Personne). C'est le cœur de la conception orientée objet.