EXERCICES UML

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

Compréhension du problème

Le système doit gérer deux grands types de fonctionnalités : la consultation (du planning et des récapitulatifs) et la réservation (de salles et de matériel). La clé de cet exercice réside dans l'identification de la hiérarchie des acteurs et de la factorisation des cas d'utilisation via l'héritage et l'inclusion.

• Acteurs : "Tout le monde" se traduit par un acteur générique Utilisateur salle. L'Enseignant est un acteur spécifique avec plus de droits (réserver, consulter son récapitulatif). Le Responsable formation est un enseignant avec un rôle supplémentaire (éditer le récapitulatif global).
• Héritage de cas d'utilisation : La réservation se décline en salle et matériel, et le matériel en vidéo-projecteur ou portable. Cela se modélise parfaitement avec des relations d'héritage (généralisation/spécialisation).
• Inclusion : Toute réservation nécessite de vérifier la disponibilité. C'est une relation <<include>> car l'action est systématique et indispensable.

Code PlantUML de la solution

@startuml
left to right direction
skinparam packageStyle rectangle

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

Ens -|> US
Resp -|> Ens

rectangle "Système de réservation" {
  usecase "Consulter planning" as UC_Consulter
  usecase "Consulter récap horaire enseignant" as UC_Recap_Ens
  usecase "Editer récap formation" as UC_Recap_Form
  
  usecase "Réservation" as UC_Resa
  usecase "Vérification disponibilité" as UC_Verif
  
  usecase "Réservation salle" as UC_Resa_Salle
  usecase "Réserver matériel" as UC_Resa_Mat
  usecase "Réserver vidéo" as UC_Resa_Video
  usecase "Réserver portable" as UC_Resa_Port
}

US --> UC_Consulter
Ens --> UC_Recap_Ens
Ens --> UC_Resa
Resp --> UC_Recap_Form

UC_Resa ..> UC_Verif : <<include>>

UC_Resa_Salle -|> UC_Resa
UC_Resa_Mat -|> UC_Resa
UC_Resa_Video -|> UC_Resa_Mat
UC_Resa_Port -|> UC_Resa_Mat
@enduml

Note : L'énoncé original présente les acteurs indépendamment, mais la relation logique veut que le Responsable soit un Enseignant, qui est lui-même un Utilisateur. J'ai explicité cet héritage d'acteurs pour une conception plus robuste, bien que le schéma source relie directement les acteurs à leurs cas sans montrer l'héritage entre eux.

Exercice 2 - Projet de recherche en viticulture

Cet exercice est riche et aborde trois vues différentes du système : les cas d'utilisation (fonctionnalités), la cinématique (qui fait quoi et quand, souvent modélisé par un diagramme d'activité ou de flux), et les classes (données statiques).

Question 2.1 - Diagramme de cas d'utilisation

Ce diagramme se concentre sur l'application web (BDD). L'Ouvrier Agricole est un acteur indirect du système informatique (il utilise un cahier), mais son action déclenche la chaîne.

• Extension (<<extend>>) : La correction de la base de données n'arrive que si une erreur est détectée, d'où la relation <<extend>>.
• Inclusion (<<include>>) : Pour saisir dans la BDD, le chef d'exploitation doit obligatoirement s'identifier.

@startuml
left to right direction

actor "Ouvrier Agricole" as OA
actor "Chef exploitation" as CE
actor "Chercheur" as CH

rectangle "Système Viticulture (BDD)" {
  usecase "Consultation du glossaire" as UC_Glossaire
  usecase "Vérification saisie cahier" as UC_Verif_Cahier
  usecase "Saisie opération" as UC_Saisie_Op
  usecase "Saisie BDD" as UC_Saisie_BDD
  usecase "Identification" as UC_Ident
  usecase "Opération phyto" as UC_Phyto
  usecase "Autre opération" as UC_Autre
  usecase "Correction éventuelle" as UC_Correction
  
  usecase "Notification saisie ok" as UC_Notif
  usecase "Vérification données BDD" as UC_Verif_BDD
  usecase "Correction données BDD" as UC_Corr_BDD
  usecase "Etat terravitis" as UC_Terravitis
  usecase "Analyse résultats" as UC_Analyse
  usecase "Rédaction synthèse" as UC_Redaction
}

OA --> UC_Glossaire

CE --> UC_Verif_Cahier
CE --> UC_Saisie_BDD
CE --> UC_Terravitis

CH --> UC_Verif_BDD
CH --> UC_Analyse
CH --> UC_Redaction

UC_Saisie_BDD ..> UC_Ident : <<include>>
UC_Saisie_Op ..> UC_Verif_Cahier : <<include>>
UC_Correction .> UC_Saisie_Op : <<extend>>

UC_Phyto -|> UC_Saisie_Op
UC_Autre -|> UC_Saisie_Op

UC_Corr_BDD .> UC_Verif_BDD : <<extend>>
UC_Notif ..> UC_Verif_BDD : <<include>>
@enduml

Question 2.2 - Diagramme de flux / d'activité

Le document source fournit un logigramme en colonnes. En UML, cela se modélise via un diagramme d'activité avec des partitions (swimlanes).

@startuml
|Ouvrier Agricole|
start
:saisie temps de travaux;
:saisie temps de travaux;

|Chef Exploitation|
:Fin de mois;
:Vérification;
:Correction éventuelle;
:Saisie BDD;

|Chercheur|
:Mail;
:Vérification;
if (Erreur ?) then (oui)
  :Correction;
else (non)
endif
:Notification saisie ok;

|Chef Exploitation|
:consulter;
fork
  :Impression Fiche mensuelle;
  :Transmission à l'Ouvrier;
fork again
  :Impression Etat phyto;
end fork

|Chercheur|
:Fin d'année;
:Analyse BDD;
:Rédaction Synthèse;
:Transmission;

|Chef Exploitation|
:Réception Synthèse;
stop
@enduml

Question 2.3 - Diagramme de classes

La modélisation des données traduit le vocabulaire métier. Une "Intervention phyto" est un type particulier d'"Intervention", d'où l'héritage.

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

class Fonction_personne {
  - 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 MALADIES {
  - Code maladie : varchar(5)
  - Libellé maladie : varchar(50)
}

class Intervention_phyto {
  - Observation phyto : text
}

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

class STADE_PHENOLOGIQUE {
  - Code stade : varchar(5)
  - Libellé stade : varchar(50)
}

PERSONNE "0..*" -- "1..1" Fonction_personne
Exploitation "1..1" -- "1..*" PERSONNE
Exploitation "1..1" -- "1..*" PARCELLES
PARCELLES "1..1" -- "0..*" Intervention
Intervention <|-- Intervention_phyto
Intervention_phyto "0..*" -- "0..*" MALADIES
Intervention "0..*" -- "1..1" OPERATION
Intervention_phyto "0..*" -- "1..1" STADE_PHENOLOGIQUE

@enduml

Exercice 3 - Diagramme de cas d'utilisation : Magasin

Ici, il faut bien maîtriser les relations d'extension (<<extend>>). Une extension traduit une option ou une alternative qui n'est pas toujours exécutée.

• Le client prospecte. Parfois, il demande des renseignements ou essaie des articles. Ce sont des extensions de "Prospecter".
• S'il achète, cela inclut obligatoirement de payer.
• Payer par CB, par chèque ou en liquide sont des spécialisations (héritage) du cas d'utilisation abstrait "Payer".

@startuml
left to right direction

actor Client as C
actor Vendeur as V
actor Caisse as Ca
actor "Groupement des banques" as GB

rectangle Magasin {
  usecase "Prospecter" as UC_Prosp
  usecase "Renseigner" as UC_Rens
  usecase "Essayer" as UC_Essai
  
  usecase "Acheter" as UC_Achat
  usecase "Vérification stock" as UC_Stock
  usecase "Payer" as UC_Payer
  usecase "Bénéficier réduction" as UC_Reduc
  
  usecase "Payer CB" as UC_PCB
  usecase "Payer chèque" as UC_PCheque
  usecase "Payer liquide" as UC_PLiq
}

C --> UC_Prosp
C --> UC_Achat

UC_Rens .> UC_Prosp : <<extend>>
UC_Essai .> UC_Prosp : <<extend>>

V --> UC_Rens
Ca --> UC_Payer
GB --> UC_PCB

UC_Achat ..> UC_Stock : <<include>>
UC_Achat ..> UC_Payer : <<include>>

UC_Reduc .> UC_Payer : <<extend>>

UC_PCB -|> UC_Payer
UC_PCheque -|> UC_Payer
UC_PLiq -|> UC_Payer
@enduml

Exercice 4 - Diagramme de cas d'utilisation : Distributeur (DAB)

La difficulté réside dans les différents systèmes d'information (SI) interrogeables en fonction du type de carte. Note : Dans le document source, il y a quelques fautes de frappe ("Opératuer maintenance", "récpération billets") que j'ai corrigées ici pour garantir un code propre et lisible.

@startuml
left to right direction

actor "Porteur de visa" as PV
actor "Client banque" as CB
actor "Opérateur maintenance" as OM
actor "SI gestion CB" as SIG
actor "SI banque" as SIB

rectangle "Gestion d'un DAB" {
  usecase "Retirer argent" as UC_Retrait
  usecase "S'authentifier" as UC_Auth
  
  usecase "Retirer argent avec visa" as UC_Ret_Visa
  usecase "Consulter solde" as UC_Solde
  usecase "Déposer argent" as UC_Depot
  usecase "Déposer numéraire" as UC_Dep_Num
  usecase "Déposer chèques" as UC_Dep_Cheq
  
  usecase "Recharger DAB" as UC_Recharge
  usecase "Récupérer cartes avalées" as UC_Recup_Carte
  usecase "Récupérer chèque" as UC_Recup_Cheq
}

PV --> UC_Ret_Visa
CB --> UC_Solde
CB --> UC_Depot

OM --> UC_Recharge
OM --> UC_Recup_Carte
OM --> UC_Recup_Cheq

UC_Ret_Visa -|> UC_Retrait

UC_Retrait ..> UC_Auth : <<include>>
UC_Solde ..> UC_Auth : <<include>>
UC_Depot ..> UC_Auth : <<include>>

UC_Dep_Num -|> UC_Depot
UC_Dep_Cheq -|> UC_Depot

UC_Ret_Visa --> SIG
UC_Solde --> SIB
UC_Depot --> SIB
@enduml

Exercice 5 - Diagramme de cas d'utilisation : Gestion de stock

L'énoncé stipule que l'ajout d'un nouvel article entraîne l'édition automatique de la fiche fournisseur. C'est donc une inclusion (<<include>>). En revanche, l'ajout du fournisseur n'est fait que s'il n'existe pas, c'est une extension (<<extend>>).

@startuml
left to right direction

actor Commerçant as C

rectangle "Système de gestion de stock" {
  usecase "Affichage inventaire" as UC_Aff_Inv
  usecase "Impression inventaire" as UC_Imp_Inv
  usecase "Effacement article" as UC_Eff_Art
  usecase "Edition article" as UC_Ed_Art
  usecase "Ajouter article" as UC_Aj_Art
  
  usecase "Edition fournisseur" as UC_Ed_Fourn
  usecase "Ajout fournisseur" as UC_Aj_Fourn
}

C --> UC_Aff_Inv
C --> UC_Ed_Fourn
C --> UC_Aj_Art

UC_Imp_Inv .> UC_Aff_Inv : <<extend>>
UC_Eff_Art .> UC_Aff_Inv : <<extend>>
UC_Ed_Art .> UC_Aff_Inv : <<extend>>

UC_Aj_Art ..> UC_Ed_Fourn : <<include>>
UC_Aj_Fourn .> UC_Ed_Fourn : <<extend>>
@enduml

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

Un diagramme de séquence montre la chronologie des échanges (messages) entre les objets/acteurs. Ici, nous devons utiliser une boucle (loop) pour représenter 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
Caissier -> Client : Total à payer

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

Caisse -> Caissier : Ticket
Caissier -> Client : Monnaie
Caissier -> Client : Ticket
@enduml

Exercice 7 - Diagramme de séquence : DAB (Scénario nominal)

On modélise ici le scénario où tout se passe bien. L'énoncé demande d'identifier les points de défaillance potentiels (scénarios d'exception) avec des commentaires, ce que nous traduisons par des notes (note) attachées aux messages critiques.

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

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

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

DAB -> Banque : Demande autorisation
Banque --> DAB : Autorisation solde

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

DAB --> Client : demande ticket
Client -> DAB : ok
note right : Voir cas ticket refusé

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

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

Exercice 8 - Diagrammes de séquence et de collaboration : Magasin de fleurs

L'exercice demande deux vues pour le même processus.

1. Le diagramme de séquence met en avant l'axe du temps (vertical).
2. Le diagramme de collaboration (appelé diagramme de communication en UML 2.x) met en avant le réseau d'objets et numérote les messages chronologiquement.

Diagramme de séquence

@startuml
actor Client
actor Vendeur
actor Ouvrier
participant "Bon de fabrication" as Bon
participant "Composition" as Comp
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
Vendeur -> Facture : 6: Editer facture
Vendeur -> Facture : 7: Impression facture
Ouvrier -> Comp : 8: Créer
Ouvrier -> Bon : 9: Archivage
Ouvrier -> Vendeur : 10: livrer
Vendeur -> Client : 11: remettre facture
Client -> Vendeur : 12: régler
Vendeur -> Client : 13: remettre bouquet
@enduml

Diagramme de collaboration (Communication)

En PlantUML, la façon la plus claire de générer l'équivalent topologique du schéma source est d'utiliser un diagramme d'objets où chaque association porte les numéros de séquence des échanges.

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

Client <--> Vendeur : "1 : Demande renseignements\n2 : Fournir informations\n3 : Commande\n11 : remettre bouquet\n12 : remettre facture\n13 : régler facture"
Vendeur --> Bon : "4 : créer"
Vendeur --> Ouvrier : "5 : Transmettre"
Vendeur --> Facture : "6 : Editer\n7 : Imprimer"
Ouvrier --> Composition : "8 : créer"
Ouvrier --> Bon : "9 : Archiver"
Ouvrier --> Vendeur : "10 : Livrer"
@enduml

Note : Dans un diagramme de collaboration formel, on trace un lien entre chaque instance, et on pose une flèche directionnelle avec le numéro du message le long de ce lien.

Exercice 9 - Diagramme de classes : Associations simples

Il s'agit de trouver la nature exacte des relations entre les concepts donnés :

• Un répertoire et des fichiers : Agrégation (un fichier peut exister sans répertoire, ou être déplacé).
• Une pièce et des murs : Composition (si on détruit la pièce, le mur n'a conceptuellement plus de raison d'être dans ce contexte strict).
• Modems/Claviers et Périphériques : Héritage (Un modem est un périphérique).
• Achat/Vente et Transaction : Héritage.
• Compte et Personnes : Association simple et héritage pour factoriser "Client" (ou Personne).

@startuml
class Répertoire
class Fichier
Répertoire "1..1" o-- "0..*" Fichier : Contenir >

class Pièce
class Mur
Pièce "1..*" *-- "1..*" Mur : composer >

class Périphérique
class Modem
class Clavier
Périphérique <|-- Modem
Périphérique <|-- Clavier

class "Transaction boursière" as Transac
class Achat
class Vente
Transac <|-- Achat
Transac <|-- Vente

class "Compte bancaire" as Compte
class Client
class "Personne morale" as PM
class "Personne physique" as PP

Compte "0..*" -- "1..1" Client : Appartenir >
Client <|-- PM
Client <|-- PP
@enduml

Note : Comme précisé dans l'énoncé source, on a modélisé l'appartenance avec une super-classe abstraite "Client" plutôt qu'une contrainte d'exclusion {OU} entre deux relations distinctes, ce qui rend le schéma beaucoup plus propre.

Exercice 10 - Diagramme de classes : Académie

Une des bonnes pratiques de modélisation orientée objet appliquée ici est la création d'une super-classe PERSONNE qui regroupe les attributs partagés par ENSEIGNANT et ETUDIANT (Nom, prénom, mail, etc.), allégeant ainsi le diagramme.

@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 >
ENSEIGNANT "1..1" -- "0..1" DEPARTEMENT : Etre chef de >

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

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

Explication de la relation Note : La note n'appartient ni à l'étudiant seul (il en a plusieurs), ni au cours seul (qui note plusieurs étudiants). Elle est portée par l'association "Suivre" entre l'Étudiant et le Cours. C'est ce qu'on appelle une classe d'association.

Exercice 11 - Diagramme de classes : Agence de voyages

Le point d'attention de cet exercice est la distinction entre un "Vol générique" (ex: Le vol Air France AF123 qui a lieu tous les jours) et un "Vol" physique à une date donnée (ex: Le AF123 du 12 Décembre). C'est un grand classique des sujets de modélisation.

@startuml
class "Compagnie aérienne" as Compagnie {
  + 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 {
  + heure départ : Date
  + heure arrivée : date
  + no escale : int
  + 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
}

Compagnie "1..1" -- "1..*" VolGen : Gérer >
VolGen "1..1" -- "0..*" Vol : décrire >

Vol "0..*" -- "1..1" Aeroport : départ >
Vol "0..*" -- "1..1" Aeroport : arrivée >

Vol "1..1" -- "0..*" ESCALE : concerne >
ESCALE "0..*" -- "1..1" Aeroport : concerne >

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

individu <|-- Client
individu <|-- passager

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

Méthode

Face à une épreuve de modélisation UML (ou tout exercice d'analyse informatique), la rigueur de lecture est votre meilleure alliée. Voici comment procéder systématiquement :

1. L'analyse des substantifs et verbes : Dans l'énoncé, surlignez les noms communs (ils deviendront vos acteurs ou vos classes) et les verbes d'action (ils deviendront vos cas d'utilisation ou vos méthodes).
2. La règle du "Qui fait quoi ?" : Pour les diagrammes de cas d'utilisation, posez-vous toujours la question de l'initiateur de l'action. Un acteur n'est pas forcément un humain, cela peut être un système externe (comme la Banque pour le DAB).
3. L'identification des relations :
   • Si la phrase dit "B ne se fait que si A est fait", c'est une inclusion (<<include>>).
   • Si la phrase dit "B peut parfois arriver lors de A", c'est une extension (<<extend>>).
   • Si l'énoncé dit "Un étudiant et un professeur ont tous les deux un nom", cherchez immédiatement à créer une classe mère (héritage).
4. Chronologie et Cas Limites : Pour les diagrammes de séquence, tracez d'abord le cas idéal (le "Happy Path"). Une fois terminé, relisez l'énoncé en cherchant ce qui peut mal se passer (carte bloquée, pas de stock, etc.) et insérez ces alternatives.
5. Multiplicités : Sur un diagramme de classes, lisez la relation dans les deux sens pour ne pas vous tromper sur les cardinalités. (ex: Un cours a lieu dans combien de salles simultanément ? 1 seule (1..1). Une salle peut accueillir combien de cours ? Plusieurs (0..*)).